UMDシステム 利用の手引き

UMDシステム利用の手引き

はじめに

UMDシステム概要

本システムではWLCGシステムを実現するために、EGI (European Grid Infrastructure)が中心となって開発しているミドルウェアであるUMDを使用しています。 UMDミドルウェアはgLite 3.2の後継ミドルウェアとなります。 ここでは、UMDミドルウェアを利用した本システムをUMDシステムと呼びます。 また、UMDシステムとiRODSシステムを併せてGridシステムと呼びます。 ※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) と連携します。 本システムでは、LRMSとしてLSFを利用します。
  • WN (Worker Node)
    CEから割り振られたジョブを実行する機能を提供します。 本システムでは、WNはLSFの計算資源として管理されています。
  • LFC (Logical File Catalog)
    UMDシステムで利用するストレージ資源を管理し、LFN (Logical File Name) というカタログデータを管理する機能を提供します。 LFNを利用することにより、どのサイトのどのディスクに存在するかを意識することなくデータにアクセスすることが可能です。
  • StoRM (STOrage Resource Manager)
    UMDシステムで利用するストレージ資源へアクセスする機能を提供します。 グループごとにストレージエリアを定義します。 ストレージ資源のデータ領域として、GHIファイルシステムと磁気ディスクシステムを提供します。
  • BDII (Berkeley Database Information Index)
    Grid環境にどのような資源があるかの情報を収集し、ユーザやシステムがその情報を参照できるための機能を提供します。 本システムでは次の2種類のBDIIを提供します。
    BDII_site: 本システム内の資源情報を収集する。
    BDII_top: 国内外のLCGシステム内のBDII_siteから情報を収集する。
  • APEL (Accounting Processor for Event Logs)
    ジョブ実行に関する課金情報の収集機能を提供します。
  • ARGUS (Authorization Framework)
    ポリシーベースの認証機構を提供します。
  • VOMS (Virtual Organization Membership Service)
    VO (Virtual Organization) の所属するユーザを管理する機能を提供します。 また、本システムのVOMSで管理されるVOのジョブ実行をサポートするLCGサイトからのユーザ情報問い合わせ要求を処理する機能を提供します。
  • CVMFS (CernVM File System)
    各研究機関で開発された高エネルギー物理学におけるデータ処理ソフトウェア資源を利用するためのファイルシステムを提供します。

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

UMDシステム コンポーネント ホスト名
UI login.cc.kek.jp
ccw.cc.kek.jp
ccx.cc.kek.jp
CE kek2-ce01.cc.kek.jp
kek2-ce02.cc.kek.jp
WN ccb001.cc.kek.jp～ccb296.cc.kek.jp
ccb501.cc.kek.jp～ccb572.cc.kek.jp
LFC kek2-lfc.cc.kek.jp
kek2-lfcb1.cc.kek.jp
kek2-lfcb2.cc.kek.jp
kek2-lfc03.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)
APEL kek2-apel.cc.kek.jp
ARGUS kek2-argus.cc.kek.jp
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
cdfj
g4med
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/umd-c7ui-latest
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-bdii03.cc.kek.jp:2170,kek2-bdii04.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-se01.cc.kek.jp
export VO_T2K_ORG_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_PPJ_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_OPS_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_KAGRA_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_ILC_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_GEANT4_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_G4MED_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_FKPPL_KISTI_RE_KR_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_DTEAM_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_CDFJ_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_CALICE_DEFAULT_SE= kek2-se01.cc.kek.jp
export VO_BELLE_DEFAULT_SE= kek2-se01.cc.kek.jpまたはkek2-se03.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 lfc tag
bdii_site dliLocal lfcLocal vobox
bdii_top fts myproxy voms
ce gridce se voms-admin
closeSE lb sitenames voview
cream lcg-ce space wms

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

#> lcg-infosites --vo ppj ce ↓

実行例2：ppj VOの利用可能なSEの一覧および使用容量・空き容量を表示する

#> lcg-infosites --vo ppj se ↓

実行例3：kagra VOの利用可能なLFCの一覧を表示する

#> lcg-infosites --vo ppj lfc ↓

ジョブの実行

利用可能なキュー

本システムではジョブスケジューラとして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

1
2
3
4
#!/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が終了します。

LFCの操作

環境設定

LFCはUMDシステムで作成されるファイルのレプリカカタログを作成し、システム内だけでなくシステム外からもファイルを参照することが可能です。 レプリカファイルはGUIDと呼ばれる識別番号を持っており、さらにこれに対応するLFNと呼ばれる論理ファイル名がつけられています。 ユーザはこの論理ファイル名を指定することで、対象のデータにアクセスために必要な情報を得ることが可能となります。 LFCの論理ファイルカタログは/grid/voname/というディレクトリ構造を持っており、その下にディレクトリやファイルを作成することが可能です。

LFCを利用するためには環境変数の設定が必要です。下記のコマンドを実行することで環境変数の設定を実施します。

#> export LCG_CATALOG_TYPE=lfc ↓
#> export LFC_HOST=lfc_host ↓

例) export LCG_HOST=kek2-lfc03.cc.kek.jp ↓

各VOの利用可能なLFCのホスト名は、前述のlcg-infositesコマンドを用いて確認できます。

ディレクトリの作成

以下では、具体的なメタデータ操作について記載します。 LFCメタデータ上にディレクトリを作成するには下記のコマンドを実行します。

#> lfc-mkdir dir_name ↓
dir_name : ディレクトリ名

例) lfc-mkdir /grid/ppj/testdir ↓

メタデータの確認

LFCメタデータの内容を表示するには下記のコマンドを実行します。

#> lfc-ls path ↓
path : ファイルまたはディレクトリパス

例) lfc-ls /grid/ppj/testdir

オプションとして、-l を指定すると詳細内容を表示します。 また、-R を指定するとディレクトリを再帰的にたどって表示します。

メインで作業するディレクトリを作成しているなら、LFC_HOME変数を設定すると便利です。 例えば、上記コマンドで設定したディレクトリに対して下記のように設定します。

#> export LFC_HOME=/grid/ppj/testdir↓

上記設定後に引数なしでlfc-lsを実行することで、自動的に$LFC_HOMEが選択されます。

ディレクトリの削除

LFCに作成したディレクトリまたはファイルを削除するには、下記のコマンドを実行します。

#> lfc-rm -r dir_name ↓ (ディレクトリの場合)
#> lfc-rm file_name ↓ (ファイルの場合)
dir_name : ディレクトリ名
file_name : ファイル名

例) lfc-rm -r /grid/ppj/testdir

ファイルまたはディレクトリが削除されたかを確認するにはlfc-lsコマンドを使用します。

Info

GridFTPサーバの TURL は動的に割り当てられるアドレスです。 TURL のパスは将来、予告なく変更されることがあります。 TURL を直接指定して転送を行っている場合、将来の成功を保証しません。

データ転送先の確認

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

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 -l lfn_name ↓
file_name : 転送するファイルパス
srm_URI : メタデータのURI
lfn_name : LFCメタデータファイルパス

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

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

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

また、LFNを指定せず、SRMのURIを指定してファイルを転送することも可能です。

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

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

ファイルのダウンロード

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

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

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

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

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

既にSEに転送したファイルのレプリカを、別のSE上に作成することが可能です。 この場合、LFNは同一ですが異なるSRM URIを持つファイルが生成されます。

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

#> gfal-copy src_name dst_name lfn_name ↓
src_name : レプリカ作成元(SRM URIパス、gsiftp URIパス)
dst_name : レプリカ作成先(SRM URIパス、gsiftp URIパス)
lfn_name : レプリカを作成したLFCメタデータファイルパス

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

ファイルの削除

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

#> gfal-rm lfn_name ↓ (LFN指定)
#> gfal-rm srm_URI ↓ (SRM指定)
lfn_name : LFCメタデータファイルパス
srm_URI : SRM URIパス

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

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

LFNからSRM URIの参照

転送したファイルのLFNからSRM URIを確認する方法について記載します。 確認するためには下記コマンドを実行します。

#> gfal-xattr lfn_name user.replicas ↓
lfn_name : 参照するファイルのLFN

例) gfal-xattr lfn:/grid/ppj/testfile user.replicas

結果として下記のような出力を得ることができます。 StoRMの場合

#> gfal-xattr lfn:/grid/ppj/testfile user.replicas ↓
  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領域の利用をお願いします。 領域が枯渇した場合には個別にファイル整理のお願いをさせていただくことがあります。