コンテンツにスキップ

UMDシステム 利用の手引き

UMDシステム利用の手引き

はじめに

UMDシステム概要

本システムではWLCGシステムを実現するために、EGI (European Grid Infrastructure)が中心となって開発しているミドルウェアであるUMDを使用しています。 UMDミドルウェアはgLite 3.2の後継ミドルウェアとなります。 ここでは、UMDミドルウェアを利用した本システムをUMDシステムと呼びます。 ※WLCG (Worldwide LHC Computing Grid) は、LHCのためのGRIDコンピューティング基盤です。

UMDシステムを使用することにより、下記の機能が実現されます。

  • 国内外の研究機関との計算資源の共有
  • 大規模データの管理、共有、利用
  • 資源利用状況の監視
  • ユーザ管理の効率化

本システムにおけるコンポーネント構成を下記に示します。

EMI_ja

  • UI (User Interface)
    ユーザ認証やジョブの投入、データのコピーなど、ユーザのクライアント機能を提供します。 本システムでは、ワークサーバの「/cvmfs/grid.cern.ch/」以下にに格納されているUI機能が利用できます。
  • CE (Computing Element)
    UIから投入されたジョブを管理し、実際に処理を実施するノードに対してジョブを投入する機能を提供します。 UMDシステムではCEとしてARC CEを利用します。 ジョブの割り振りは、LRMS (Local Resource Management System) と連携します。
  • WN (Worker Node)
    CEから割り振られたジョブを実行する機能を提供します。
  • StoRM (STOrage Resource Manager)
    UMDシステムで利用するストレージ資源へアクセスする機能を提供します。 グループごとにストレージエリアを定義します。 ストレージ資源のデータ領域として、GHIファイルシステムと磁気ディスクシステムを提供します。
  • BDII (Berkeley Database Information Index)
    Grid環境にどのような資源があるかの情報を収集し、ユーザやシステムがその情報を参照できるための機能を提供します。 本システムでは次の2種類のBDIIを提供します。
    BDII_site: 本システム内の資源情報を収集する。
    BDII_top: 国内外のLCGシステム内のBDII_siteから情報を収集する。
  • VOMS (Virtual Organization Membership Service)
    VO (Virtual Organization) の所属するユーザを管理する機能を提供します。 また、本システムのVOMSで管理されるVOのジョブ実行をサポートするLCGサイトからのユーザ情報問い合わせ要求を処理する機能を提供します。
  • CVMFS (CernVM File System)
    各研究機関で開発された高エネルギー物理学におけるデータ処理ソフトウェア資源を利用するためのファイルシステムを提供します。

各コンポーネントのホスト名を下記に示します。

UMDシステム コンポーネント ホスト名
UI login.cc.kek.jp
cw.cc.kek.jp
CE kek2-ce01.cc.kek.jp
kek2-ce02.cc.kek.jp
WN cb001.cc.kek.jp~cb063.cc.kek.jp
StoRM kek2-se01.cc.kek.jp
kek2-se02.cc.kek.jp
kek2-se03.cc.kek.jp
BDII kek2-bdii.cc.kek.jp(BDII_top)
kek2-sbdii.cc.kek.jp(BDII_site)
VOMS voms.cc.kek.jp
CVMFSStratum 0 cvmfs-stratum-zero.cc.kek.jp
CVMFSStratum 1 cvmfs-stratum-one.cc.kek.jp

本システム利用の前提条件

  • 利用可能な認証局 本システムの利用はユーザ証明書を取得されていることを前提としています。 UMDシステムで利用可能な証明書を発行する認証局についてはWLCGをご参照ください。
    また、KEKにおいても認証局の機能を電子認証局システムとして提供しています。詳細についてはKEK GRID CAをご参照ください。

  • 利用可能なVO 本システムは利用するVOへの登録が完了していることを前提としています。 VOへの登録に関してはOperation Portalをご参照ください。

Info

上記URLのアクセスには、個人証明書が必要です。

本システムにて利用可能なVOは下記の通りです。 (本システムのVOMSサーバで管理しているVO)

belle
ppj

(その他本システムがサポートしているVO)

calice
dteam
geant4
ilc
ops
t2k.org
kagra
vo.france-asia.org

本システムで管理しているVOの情報については、KEK VOMS Serverをご確認ください。

Info

上記URLのアクセスには、個人証明書が必要です。

User Interface(UI)ノードの利用

UIへのログイン

本システムのUIは、中央計算機システムのワークサーバから利用できます。 そのため、UIを利用するためには中央計算機システムのユーザアカウントが必要です。
ユーザアカウントの申請については利用申請ページを参照してください。

UIへログインする際にはSSH Version2を使用してください。 UIのホスト名は"login.cc.kek.jp", "ccw.cc.kek.jp" または "ccx.cc.kek.jp" です。このホスト名を用いて下記のようにログインします。

#> ssh -l username ccw.cc.kek.jp ↓

username : ユーザアカウント名

パスワード入力を指示されますので、ユーザアカウントのパスワードを入力します。

UI利用のセットアップ

ワークサーバにおいて、ホームディレクトリ直下にUI用の環境変数セットアップファイルを作成します。

#> cp /cvmfs/grid.cern.ch/etc/profile.d/setup-cvmfs-ui.sh . ↓
#> vi setup-cvmfs-ui.sh ↓

下記の通りに編集します。(KEK内のUMDシステムを利用する例)

変更する環境変数名= 変更後の値
base= /cvmfs/grid.cern.ch/alma9-ui-test
export X509_CERT_DIR= /etc/grid-security/certificates
export X509_VOMS_DIR= /etc/grid-security/vomsdir
export VOMS_USERCONF= /etc/grid-security/vomses
export MYPROXY_SERVER= コメントアウト(行頭に#を付ける)
export LCG_GFAL_INFOSYS= kek2-bdii01.cc.kek.jp:2170,kek2-bdii02.cc.kek.jp:2170,bdii.grid.sinica.edu.tw:2170
export BDII_LIST= コメントアウト(行頭に#を付ける)
export LD_LIBRARY_PATH= ${base}/lib64:${base}/lib:${base}/usr/lib64:${base}/usr/lib:/usr/lib64:/usr/lib
export PERL5LIB= ${base}/usr/lib64/perl5/vendor_perl:${base}/usr/lib/perl5/vendor_perl:${base}/usr/share/perl5
export PYTHONPATH= ${base}/usr/lib64/python2.7/site-packages:${base}/usr/lib/python2.7/site-packages
export JAVA_HOME= /usr/lib/jvm/jre

以下は、すべて または、ご利用になるVOを追加してください。
環境変数名の「VO__DEFAULT_SE」のでご利用のVO名を判断できます。

export 追加する環境変数名= 変更後の値
export VO_VO_FRANCE_ASIA_ORG_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_T2K_ORG_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_PPJ_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_OPS_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_KAGRA_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_ILC_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_GEANT4_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_G4MED_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_FKPPL_KISTI_RE_KR_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_DTEAM_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_CDFJ_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_CALICE_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jp
export VO_BELLE_DEFAULT_SE= kek2-storm01-frontend-2.cc.kek.jpまたはkek2-storm03-frontend-2.cc.kek.jp

また、以下を追加してください。

export 追加する環境変数名= 変更後の値
export GLOBUS_TCP_PORT_RANGE= 20000,25000

環境変数を適用します。

#> . setup-cvmfs-ui.sh ↓

次回ログイン時に自動で環境変数を適用したい場合は、ホームディレクトリの「.bash_profile」または「.bashrc」に環境変数を適用するコマンドを追加してください。

.bash_profile」に追加する例
#> vi $HOME/.bash_profile ↓

最終行に以下の記述を追加してファイルを保存します。
. setup-cvmfs-ui.sh 

ユーザ認証

事前準備

UMDシステムとしてのユーザ認証を行う前提として、ユーザ証明書を指定のディレクトリに配置します。 ここでは、ユーザ証明書は既に認証局より取得していることを前提とします。 認証局からの証明書取得については、こちらを参照してください。 (certreq コマンドはワークサーバの/opt/kek/caclt/bin/certreqに配置されています)

ワークサーバにおいて、ホームディレクトリ直下にディレクトリを作成します。

#> mkdir $HOME/.globus ↓
#> chmod 700 $HOME/.globus ↓

作成した.globusディレクトリに、証明書ファイルであるusercert.pemと秘密鍵ファイルであるuserkey.pemの対を配置してください。

Info

(注意) usercert.pemおよびuserkey.pemはシステム間、サイト間で認証を行うための重要なファイルになります。 特に、userkey.pemは絶対に第三者に取得されないようご注意ください。 そのために、下記のコマンドを実行することでファイルに適切なパーミッションを設定してください。

#> cd $HOME/.globus ↓
#> chmod 644 usercert.pem ↓
#> chmod 400 userkey.pem ↓

プロキシ証明書の取得

本システムでは認証を実施するために、一時的にプロキシ証明書を発行します。 ARC CEの機能を使用する場合は、ARC CE用のコマンドでプロキシ証明書を発行する必要があります。 プロキシ証明書の取得には下記のコマンドを実行します。

#> voms-proxy-init -voms voname ↓

ARC CEの場合
#> arcproxy -S voname ↓

voname : ご利用になるVO名

例)
 voms-proxy-init -voms ppj ↓

ARC CEの場合
 arcproxy -S ppj ↓

コマンドを実行後、ユーザ証明書のパスフレーズを要求されます。 ユーザ証明書発行時に設定したパスフレーズを入力することで、VOMSサーバと通信しプロキシ証明書が発行されます。 これ以降は、プロキシ証明書を利用することでユーザ認証を実施することが可能です。

また、プロキシ証明書取得の際にVOで設定しているグループやRoleを指定することも可能です。 コマンド実行時に下記の通り指定します。

グループの指定

#> voms-prox-init -voms voname:/voname/GROUP ↓

ARC CEの場合
#> arcproxy -S voname:/voname/GROUP

例)
 voms-proxy-init -voms ppj:/ppj/test ↓

ARC CEの場合
 arcproxy -S ppj:/ppj/test

Roleの指定

#> voms-proxy-init -voms voname:/voname/Role=ROLE ↓

ARC CEの場合
#> arcproxy -S voname:/voname/Role=ROLE ↓

例)
 voms-proxy-init -voms ppj:/ppj/Role=production

ARC CEの場合
 arcproxy -S ppj:/ppj/Role=production

上記を組み合わせて、グループとRoleを指定することも可能です。

#> voms-proxy-init -voms voname:/voname/GROUP/Role=ROLE ↓

ARC CEの場合
#> arcproxy -S voname:/voname/GROUP/Role=ROLE ↓

例)
 voms-proxy-init -voms ppj:/ppj/test/Role=production

ARC CEの場合
 arcproxy -S ppj:/ppj/test/Role=production

プロキシ証明書の確認

発行されたプロキシ証明書の情報は下記コマンドで確認できます。

#> voms-proxy-info -all ↓

ARC CEの場合
#> arcproxy -I ↓

出力結果のattributeの列に指定したVOの情報が含まれていること、有効期間が0ではないことを確認してください。

======================================================
$ voms-proxy-info -all
subject   : /C=JP/O=KEK/OU=CRC/CN=TEST USER/CN=proxy
issuer    : /C=JP/O=KEK/OU=CRC/CN=TEST USER
identity  : /C=JP/O=KEK/OU=CRC/CN=TEST USER
type      : full legacy globus proxy
strength  : 1024 bits
path      : /tmp/x509up_u12345
timeleft  : 12:00:00
key usage : Digital Signature, Non Repudiation, Key Encipherment, Data Encipherment
=== VO ilc extension information ===
VO        : ppj
subject   : /C=JP/O=KEK/OU=CRC/CN=TEST USER
issuer    : /C=JP/O=KEK/OU=CRC/CN=host/voms.cc.kek.jp
attribute : /ppj/Role=production/Capability=NULL
timeleft  : 12:00:00
uri       : voms.cc.kek.jp:15023
======================================================

ARC CEの場合
======================================================
$ arcproxy -I
Subject: /C=JP/O=KEK/OU=CRC/CN=TEST USER/CN=proxy
Issuer: /C=JP/O=KEK/OU=CRC/CN=TEST USER
Identity: /C=JP/O=KEK/OU=CRC/CN=TEST USER
Time left for proxy: HH hours MM minutes SS seconds
Proxy path: /tmp/x509up_u28950
Proxy type: X.509 Proxy Certificate Profile RFC compliant impersonation proxy - RFC inheritAll proxy
Proxy key length: 1024
Proxy signature: sha512
====== AC extension information for VO ppj ======
VO        : ppj
subject   : /C=JP/O=KEK/OU=CRC/CN=TEST USER
issuer    : /C=JP/O=KEK/OU=CRC/CN=host/voms.cc.kek.jp
uri       : voms.cc.kek.jp:15020
attribute : /ppj/Role=production/Capability=NULL
attribute : role = production (ppj)
attribute : /ppj/Role=NULL/Capability=NULL
Time left for AC: HH hours MM minutes SS seconds
======================================================

プロキシ証明書の破棄

不要になったプロキシ証明書を破棄する場合には下記のコマンドを実行します。

#> voms-proxy-destroy ↓

ARC CEの場合
#> arcproxy -r ↓

リソース情報の取得

本システムでジョブの投入やファイルのアップロードなどを実施するためには、計算資源やストレージ資源がどこに存在するのかが必要になります。
VOごとのリソース情報はlcg-infositesコマンドで確認することが可能です。

#> lcg-infosites --vo voname component ↓
voname : 利用VO名
component :対象コンポーネント情報

コンポーネント情報は下記が選択可能です。

all dli tag
bdii_site dliLocal vobox
bdii_top fts voms
ce gridce voms-admin
closeSE lb voview
cream lcg-ce wms

実行例:ppj VOの投入可能なCEのID一覧を表示する

#> lcg-infosites --vo ppj ce ↓

ジョブの実行

利用可能なキュー

本システムではジョブスケジューラとしてLSFを利用します。 LSFでは、UMDシステムのジョブ実行のために複数のキューを用意しています。 利用するVO、またROLEによって利用できるキューが異なりますのでご注意ください。

UMDシステムで利用可能なキューの一覧についてはUMDキュー一覧を参照してください。

ジョブの実行方法

ユーザがジョブを実行するためには下記のステップが必要となります。

ファイルを準備する
ジョブ投入が可能であるCEの情報を取得する
ジョブを投入する
ジョブの状態を確認する
ジョブの結果を出力する

以下では、ジョブ投入方法について手順を示します。

ファイルを準備する

UMDシステムに投入するジョブは、ジョブ記述言語 (xRSL) と呼ばれる言語で記述されたジョブ記述ファイルで表現されます。 したがって、UMDシステムにジョブを投入するためにはxRSLファイルを作成する必要があります。 また、実際に実行する内容を示したスクリプトファイルも作成する必要があります。

ここでは、xRSLファイルとスクリプトファイルのサンプルを示します。

まず、UIノードにおいてxRSLファイルtest.jdlを作成します。

ファイル名: test.xrsl

&
( executable = "/bin/sh" )  # 実行シェル
( arguments = "test.sh" )   # 実行スクリプト
( inputFiles = ( "test.sh" "" ) )   # ジョブへのインプットファイル
( outputFiles = ( "output.txt" "gsiftp://" ) )  # ジョブへのアウトプットファイル及び転送先(※1)
( stdout = "std.out" )  # 標準出力先ファイル
( stderr = "std.err" )  # エラー出力先ファイル
( queue = "gridbelle_middle" )  #実行キュー(※2)

※1:転送先を省略する場合は"( "output.txt" "" )"とします。
※2:実行キューについては後述の"ジョブ投入可能なCEのキュー一覧取得"を参照します。

上記ファイルでは、test.shをインプットとして渡して実行し、結果をstd.out・output.txtおよびstd.errに出力して戻します。

次に、実行スクリプトファイルtest.shを作成します。

ファイル名: test.sh

#!/bin/sh

echo "Hello World!"
echo "I am `hostname`"

test.shには実行させたいコマンド等を記述します。 上記サンプルでは、echoコマンドを利用して簡単な内容を出力しています。

このような2つのファイルをUIノードにて作成してください。

ジョブ投入可能なCEのキュー一覧取得

ジョブを投入する準備として、ジョブを投入可能であるCEのキュー名を確認します。 キュー名を確認するには下記のコマンドを実行します。

#> lcg-infosites --vo ppj ce ↓

コマンドを実行すると下記のような出力が得られます。

#   CPU    Free Total Jobs      Running Waiting ComputingElement
----------------------------------------------------------------
  13936       0          0            0       0 kek2-ce01.cc.kek.jp:2811/nordugrid-LSF-gridbelle_heavy
  13936       0          0            0       0 kek2-ce01.cc.kek.jp:2811/nordugrid-LSF-gridbelle_long
  13936       0          0            0       0 kek2-ce01.cc.kek.jp:2811/nordugrid-LSF-gridbelle_mergejob
  13936       0          0            0       0 kek2-ce01.cc.kek.jp:2811/nordugrid-LSF-gridbelle_middle
  (後略)

上記のComputingElementの列の"nordugrid-LSF-"以降の文字列がキュー名となります。

これらはppj VOで利用可能であるLSFのキューの種類によって分かれております。 例として、kek2-ce01.cc.kek.jp:2811/nordugrid-LSF-gridbelle_middleはLSFキューのgridbelle_middleに紐づいています。 利用したいキューを選択し、xRSLファイルの( queue = "" )パラメータを任意のキュー名に書き換えてください。

UMDシステムで利用可能なキューの一覧についてはUMDキュー一覧を参照してください。

ジョブ投入

利用するCEおよびキューが決まりましたら、ジョブを投入します。

#> arcsub -j joblist.xml -o jobID.txt -c CE -a xRSL.xrsl ↓
joblist.xml : アクティブなジョブに関する情報を保存するファイル
jobID.txt : JobIDの出力先ファイル
xRSL.xrsl : 実行するxRSLファイル

例) arcsub -j jobs.xml -o jobid.txt -c https://kek2-ce01.cc.kek.jp/arex test.xrsl

ジョブの投入に成功すると、-oで指定したファイルにJobIDが出力されます。 このIDはジョブごとに固有であり、JobIDの格納されたファイルは後述のジョブの状態確認や結果出力などに利用します。

  • "-j"オプションを指定しない場合、ユーザホームの"./arc/jobs.dat"に出力されます。
  • ROLEによっては実行できないキューの場合もありますのでご注意ください。

ジョブの状態確認

投入したジョブの状態を確認するには下記のコマンドを実行して確認できます。

#> arcstat -j joblist.xml ↓
joblist.xml : アクティブなジョブに関する情報を保存するファイル

例) arcstat -j jobs.xml ↓

上記コマンドを実行することにより、ジョブの現在の状態とJobIDを確認することが可能です。 また、"-d"オプションを利用することによりさらに詳細な情報を得ることができます。

#>arcstat -j jobs.xml -d 2 ↓

ジョブの状態に関しては下記のものが存在します。

STATUS 説明
Accepted ジョブはクラスターで承認されましたが、まだ処理されていません
Preparing ジョブはバッチシステムへの送信の準備段階です
Submitting バッチシステムとの通信が進行中です
Hold 内部の理由またはユーザーの要求により、ジョブの処理が一時停止されました
Queuing ジョブはバッチシステムに渡されますが、まだ実行されていません
Running ジョブはバッチシステムで実行されています
Finishing 終了フェーズのジョブ
Finished ジョブはすべての処理フェーズを正常に完了しました
Killed ユーザーの要求によりジョブの処理が中断されました
Failed 障害が検出されたため、ジョブの処理が中断されました
Deleted ジョブはクラスターから削除されました
Other その他

ジョブ結果の出力

ジョブの実行結果を得るためには下記のコマンドを実行します。 (arcstatコマンドの結果"Finished"となっていること。)

#> arcget -j jobs.xml JobID ↓
 joblist.xml : アクティブなジョブに関する情報を保存するファイル
 JobID : ジョブ処理毎の固有の識別番号

例) : arcget -j jobs.xml https://kek2-ce01.cc.kek.jp:443/arex/PKSNDmmt8Uxn5W5ySmCfWssoABFKDmABFKDmbDgKDmEBFKDm1Mif6m ↓

コマンド実行後、カレントディレクトリにURL情報を除くJobID名のディレクトリが作成され、出力ファイルが格納されます。

ジョブの強制終了

実行中のジョブを強制終了するためには下記のコマンドを実行します。

#> arckill -j joblist.xml JobID ↓
 joblist.xml : アクティブなジョブに関する情報を保存するファイル
 JobID : ジョブ処理毎の固有の識別番号

例) : arckill -j jobs3.xml https://kek2-ce01.cc.kek.jp:443/arex/qqtLDmN2PVxn5W5ySmCfWssoABFKDmABFKDmbDgKDmLBFKDmRyApun ↓

上記コマンドを実行すると、指定したjobIDの処理は直ちに終了します。 ジョブがキャンセルされたことを確認するには、arcstatを実行します。 キャンセルされたジョブは、StatusがKilledとなります。(終了処理が完了した場合は表示されません。) また、jobIDを指定しない場合はjoblist.xmlに記載されているすべてのjobIDが終了します。

データ転送先の確認

本システムではストレージサービスを利用してデータ転送を実施することが可能です。 転送したデータはメタデータとして参照可能であり、ダウンロード、他のサイトへの転送等を実施できます。

VOで利用可能なストレージを確認する場合には、前述のlcg-infositesコマンドを利用して下記の通り実行します。

#> lcg-infosites --vo vo_name se ↓
vo_name : VO名

上記を実行することで利用可能なストレージのホスト名、空き容量、利用容量を確認できます。

 Avail Space(kB)  Used Space(kB)  Type  SE
------------------------------------------
     79999999998               2  SRM   kek2-se01.cc.kek.jp

本システムでは3種類のストレージを提供しています。

kek2-se01.cc.kek.jp
kek2-se02.cc.kek.jp
kek2-se03.cc.kek.jp

各サービスはSRMと呼ばれるプロトコルでメタデータ領域を保持しています。 いずれのストレージサービスも、実ファイルについてはGHIファイルシステムまたは磁気ディスクシステムに書き込みます。

ストレージメタデータの参照

ストレージサービスのメタデータ参照について記載します。

StoRMのメタデータを参照するには下記コマンドを実行します。

#> gfal-ls srm_URI ↓
srm_URI : メタデータのURI

例) gfal-ls srm://kek2-se01.cc.kek.jp:8444/ppj/testfile ↓

オプションとして、-l を指定すると詳細内容を表示します。 SRM URIはStoRMに格納されたファイルが個別に持つ固有のファイルパスになります。 書式はsrm:////<ファイルパス>となります。

ファイルのアップロード

StoRMサービスに対してファイルをアップロードするには下記のコマンドを実行します。

#> gfal-copy file_name srm_URI ↓
file_name : 転送するファイルパス
srm_URI : メタデータのURI

例) gfal-copy file:///tmp/testfile srm://kek2-se01.cc.kek.jp:8444/ppj/testfile ↓

上記コマンドにより、/tmp/testfileがkek2-se01.cc.kek.jpに転送されます。 また、-vを指定することにより、転送の詳細を出力することが可能です。

実際には、kek2-se01.cc.kek.jpが管理しているFTPサーバを経由して転送されます。 また、転送されたファイルにはシステムが割り振るSRM URIが付与されます。

#> gfal-copy file:///tmp/testfile srm://kek2-se01.cc.kek.jp:8444/ppj/testfile ↓

上記を実行することにより、指定したSRM URIでファイルが転送されます。

ファイルのダウンロード

SEに転送されたファイルをダウンロードするには、下記のコマンドを実行します。

#> gfal-copy srm_URI file_path ↓ (SRM URIを指定)
srm_URI : SRM URIパス
file_path : ダウンロード先ファイルパス

) copy srm://kek2-se01.cc.kek.jp:8444/ppj/testfile file:///tmp/download/ 

上記のように、SRM URIを指定してファイルをダウンロードすることが可能です。

ファイルのレプリカ作成 †

既にSEに転送したファイルのレプリカを、別のSE上に作成することが可能です。

レプリカを実行するには下記のコマンドを実行します。

#> gfal-copy src_name dst_name  ↓
src_name : レプリカ作成元(SRM URIパス、gsiftp URIパス)
dst_name : レプリカ作成先(SRM URIパス、gsiftp URIパス)

例) gfal-copy srm://kek2-se01.cc.kek.jp:8444/ppj/testfile srm://sample.test.org/testfile  ↓

ファイルの削除

ファイルを削除するには下記のコマンドを実行します。

#> gfal-rm srm_URI ↓ (SRM指定)
srm_URI : SRM URIパス

例) gfal-rm srm://kek2-se01.cc.kek.jp:8444/ppj/testfile ↓

ファイルが削除されたかを確認するには、gfal-lsコマンドを使用します。

SRM URIの参照

確認するためには下記コマンドを実行します。

#>  srm://kek2-se01.cc.kek.jp/ppj/testdata ↓

WebDAVインターフェイス

StoRM WebDAVサービスに対してファイルをアップロードするには下記のコマンドを実行します。

#> curl -T file_name WebDAV_URL --cert proxycertificate --key proxycertificate -E proxycertificate --capath ca_path ↓
file_name : 転送するファイル
WebDAV_URL : WebDAVのURL
proxycertificate : プロキシ証明書ファイル
ca_path : CA証明書のパス

例) curl -T /tmp/testfile https://kek2-se01.cc.kek.jp:8443/webdav/ppj/testfile \
      --cert /tmp/x509up_12345 \
      --key /tmp/x509up_12345 \
      -E /tmp/x509up_12345 \
      --capath /etc/grid-security/certificates ↓

上記コマンドにより、/tmp/testfileがkek2-se01.cc.kek.jpに転送されます。

StoRM WebDAVサービスからファイルをダウンロードするには下記のコマンドを実行します。

#> curl WebDAV_URL -o file_name --cert proxycertificate --key proxycertificate -E proxycertificate --capath ca_path ↓
WebDAV_URL : WebDAVのURL
file_name : ダウンロードするファイル
proxycertificate : プロキシ証明書ファイル
ca_path : CA証明書のパス

例) curl https://kek2-se01.cc.kek.jp:8443/webdav/ppj/testfile \
      -o /tmp/testfile \
      --cert /tmp/x509up_12345 \
      --key /tmp/x509up_12345 \
      -E /tmp/x509up_12345 \
      --capath /etc/grid-security/certificates ↓

上記コマンドにより、kek2-se01.cc.kek.jpから/tmp/testfileに転送されます。

ソフトウェア領域

UMDシステムは、各VOのソフトウェアの配置のために、約900GBの共有の領域を提供しています。 共有領域のパスは下記の通りです。

/opt/exp_soft/<VO name>

このディレクトリパスはUI, WN全台で共通となります。 領域の書き込み権限はlcgadminアカウントにのみ付与されております。 それ以外のアカウントでも、ファイルの読み込み・実行をすることが可能です。

ただし、VO全体での共有領域のため、実験データなどの大容量ファイルは格納を控えてください。 大容量ファイルの格納については、GPFSもしくはGHI領域の利用をお願いします。 領域が枯渇した場合には個別にファイル整理のお願いをさせていただくことがあります。