解析関連情報

Atlas Distributed Computing Operation Shift (ADCoS) †

アトラスのプロダクション(シミュレーション、データ解析)はグリッド上で行われます。それらの進行を確認し、問題があれば解決のための手立てを取ることを役割としたアトラスのシフトがあります。ADCoSと呼ばれています。このシフトはCERN現地にいなくても参加できる正式のアトラスのシフトとして位置づけられています。

↑

シフトメンバー †

↑

必要な条件 †

  • アカウント
    • CERNアカウント
      • LXPLUS、NICE、EDHのアカウントが必要です。
    • jabberアカウント。
      • jabberのチャットルームを使用します。部屋はadcvcr、サーバはconference.chat.uio.noです。パスワードはおたずねください。
      • 詳しくはこちら
      • クライアントにはいろいろあります。googletalkではうまくつながりませんでしたがpidginでは簡単につながりました。psiというのもあります。
      • アカウントの発行はxmpp.jp等で発行できます。googleのアカウントはうまくつながらないことがあります。
      • xmpp.jpのサーバーが止まっている場合は代替としてjabber.orgでアカウントが発行できます。
      • 2010年8月30日に新しいサーバconference.chat.uio.noに移行しました。室名やパスワードの変更はありません。
  • 証明書
  • メーリングリスト
    • atlas-project-adc-operations-shiftsアットcern.chが登録時にサブスクライブされます。
↑

予備知識 †

  • コンピューティング
    • アトラスソフトウエア
      • ジョブが落ちる原因を調べるため、athenaのログを読む必要があります。
    • プロダクションシステム
      • pandaプロダクションシステムが使われます。ページ最後にある参考資料のOperations Tutorialをご覧ください。
    • グリッド
      • 場合によっては、LCG/EGEEについてUIから確認のためのコマンドを発行する必要があります。
  • 時差
    • CERNの時刻
      • CEST(欧州中央標準時)で、日本とは夏7時間、冬8時間の差があります。ELOGはこれで書かれていますが+2:00とあるので気がつくと思います。
    • UTC(協定世界時)
      • 昔のGMT(グリニッジ標準時)が置き換わったもの。電子時計版。日本とは常に9時間ずれ。ダッシュボードはUTCに統一されています。
    • JST(日本標準時)
      • GOCDBなどはlocaleを見てローカルタイムを表示します。
    • WEBのモニター画面毎に異なる標準時が使われていますのでご注意ください。
↑

シフト表 †

  • ATLAS Operations Task Planner (OTP)
    • シフトの予約はこちらから行います。
      • CERNのEDHアカウントが必要です。
    • OTPのホームページから予約を行います。
      • Book My Shiftsをクリックし、表示されたカレンダーのうち自分の取りたい部分をクリックします。
      • シフトが割り当てられていない部分はピンク、他人が割り当てられている部分は水色、自分の割り当ては緑色になります。
    • ビームが出ているときはポイント1シフトもアサインされています。ポイント1シフトはTier0からのデータ転送を監視しています。
    • シニアシフターは自分のシフト時間帯にトレイニーシフターがいるかOTPで見ることが出来ます。
      • OTPのホームページ上端にあるメニューバーからBrowseを選びます。
      • テーブルが表示されます。通常、Computing/Softwareのタブのテーブルが表示され、Computing Shiftsの行の数字をクリックするとタスクリストがポップアップします。
      • タスクリストからADCoS Trainee Shiftsを選ぶとトレイニーのシフト表に行きます。
      • 表の緑色が予約されたスロットで、マウスカーソルをロールオーバーすると当番の名前が表示されます。
      • 同様にADCoS Expert ShiftsやAMODも誰が当番か見ることが出来ます。
↑

シフトの目的 †

  • タスクの完了
    • プロダクションタスクの監視
      • 優先順位の高いValidationタスクが正常に完了するか
      • 通常のプロダクションタスクが大量に失敗していないか
    • 失敗の原因の特定と通知
      • サイトによらずタスクが失敗する場合、プロダクションチームに
      • 特定のサイトでのみ失敗する場合、サイトマネージャに
    • タスクの制御
      • 問題のあるタスクを終了させる。該当タスクの担当者に通知。
      • 問題が解決するまでタスクを保留する。通常はタスクは自動的に健康なサイトに転送される。
  • ファイル転送の完了
    • DDM(Distributed Data Management)の監視
      • データセットがクラウド内でよどみなく転送されているか
      • クラウド間でレプリカが正しく作られているか
    • 失敗の原因の特定と通知
      • サイトのサービスに問題がある場合はサイトに通知
      • 中央サービスに問題がある場合はそのサービス担当者に通知
  • Tier0からのデータ送出の確認(新規：Run2)
    • Tier0 Exportをモニターする
      • Tier0でデータがテープに確実に書かれているか
      • Tier0からTier1等へデータが送られているか。
    • これまでComp@P1が見ていた
↑

シフトの作業 †

↑

作業環境 †

  • 計算機端末
    • 主にWEBを見ながら作業します。
      • ページによっては証明書がインストールされている必要があります。GOCDB、GGUS、GSTATなど。
    • メールの送受信が出来る環境で作業します。
    • グリッドにアクセスするためUIにログインできる環境で作業します。DQ2クライアントが使えるようにしておきます。
    • PsiやPidginなどJabberクライアントを使ってチャットに参加します。
  • ADCclock(新規)
    • シフト中の作業を1時間毎に表示してくれるツール
      • シフトはこれを見ながら進めます。
      • １時間毎にその時間にするべき作業が表示されます。
      • 見るべきページへのリンクや、解説のTwiki文書へのリンクも与えられています。
    • 一つ一つのタスクにCompleteボタンがあるので、済ませたらクリック
      • タスクの内容は以下に説明します。
↑

シフトの開始 †

  • シフトの引き継ぎ
    • シフトサマリーを確認します。
      • 直前のシフトのエントリーをクリックします。
    • メーリングリストの最近の記事に目を通します。
    • ATLAS Computer Operation電子ログブックの最近の記事に目を通します。
      • ADCoSシフトの記録に使われます。シフト中に必要事項を記録します。
      • こちらはComputing Operation全般のログブックにもなっています。
      • 2009年2月よりこの電子ログブックに統一されました。
    • 既知の問題を確認
      • すでに知られている問題を確認します。ここに書かれているエラーへの対応方法に従います。
  • サイトの運用状況の確認
    • ATLASのダウンタイムカレンダー
      • ATLAS関係のダウンタイムをまとめてカレンダー表示したものです。
    • GOCDBのダウンタイムディスプレイ
      • ダウンタイムのスケジュールが表示されます。現在だけでなく過去にあったダウンや、将来に予定されているダウンタイムも表示されます。閲覧には証明書が必要です。
    • GStatでサイトの運用状況がわかります。
      • SD(Scheduled Downtime)など、グリッドサイトとしての状況を確認します。
    • PANDAのインシデント表示
      • サイトのステートが変更された履歴が表示されます。最近offlineやonlineにセットされたサイトがわかります。
    • PANDAのサイト表示
      • PANDAの方からサイトをどう見ているかがわかります。offlineにセットされているサイトにはジョブは行きません。
    • PANDAのDaTrIリクエスト
      • グループプロダクションのファイル転送リクエストで、awaiting_subscriptionや、24時間以上subcribedのまま、もしくはpendingのリクエストがないかチェックします。
    • Site Status Board
      • サイトの状況が一目でわかるようにまとめられたものです。
  • Central Services
    • アトラスのプロダクション全体を司る、セントラルサービスにも目を通しましょう。
  • Virtual Control Room
    • ADCoSシフト用チャットルームに参加します。
      • シフトを開始する旨書き込んでください。誰かが見ていると応答してくれるかも。
      • グループチャットルームadcvcr@conference.chat.uio.noに接続します。パスワードが必要です。お問い合わせください。
↑

シフト中の作業 †

  • ATLASダッシュボード-プロダクションデータ転送
    • DDM Dashboard V2
      • Matrix表示が標準で表示されます。横軸に転送元(SRC)、縦軸に転送先(DST)のクラウドが表示されます。
      • クラウドにある+マークをクリックするとサイトが表示されます。さらにサイトの+をクリックするとスペーストークンが表示されます。元に戻すには左上端のコラムの-をクリックします。
      • マトリックスのそれぞれの交点をクリックすると成功した転送と失敗した転送の数が青字(クリック可能)で表示されます。失敗の数字をクリックすると下の方に失敗の原因毎の集計が表示されます。集計に表示された失敗数をクリックすると画面がDetailsに切り替わり、個別の転送の情報が表示されます。個別転送情報の左端の緑色の+をクリックすると詳細が展開表示されます。また、ファイル名をクリックするとそのファイルの転送履歴が表示されます。
      • Details表示のURLは絶対時間で書かれているので、そのままチケットやメールに添付することが出来ます。
      • Transfer Plots等は、その時点で選択されているSRC->DST間の転送履歴がグラフで表示されます。
    • Data Production
      • クラウド毎のデータ転送の失敗の割合を確認します。
      • クラウド名をクリックするとクラウド内のサイト名が表示されます。
      • 転送エラーの多いサイトを確認します。(赤く色づけされています)
    • 転送に失敗している原因とサイトを確認します。
      • 転送エラー数(Transfer Errors)をクリックするとエラーの内容が表示されます。
      • サイト名の左にある+をクリックすると、そこを宛先とする送り元のサイトが表示されます。
      • 転送サービス全体の問題か、送信側もしくは受信側の問題かをエラー内容から判断します。
      • NO_SPACE_LEFTが原因の場合はこちらを見てください。
    • ブラックリスト
  • Pandaモニター
    • Panda Production Operation Dashboard
      • ここでTier1クラウド毎の状況を確認します。
      • サイト毎の情報や過去12時間でアクティブなタスクの状況を確認できます。
      • 問題のあるサイトとタスクを同定します。
      • タスクの詳細は「追加情報」に示す方法で確認できます。
    • クラウドタスクのグラフ
      • クラウド毎にまとめたジョブの統計を状態毎にグラフ表示したものです。
      • 黄緑色が過去12時間に失敗したジョブの数を表しています。これが増加しているとそのクラウドを調べなければなりません。
      • 赤色が転送中のジョブ数を表します。これが他の線に比べて高く上がっているとジョブの出力が保存できない状況が続いていることを示しています。要注意です。
      • ピンクが待機中のジョブ数を表します。これが高く上がったまま継続していると、ジョブの入力となるデータセットがクラウドに送られてきていないことを示します。これも要注意です。
    • タスク中の失敗したジョブ
      • 特定のタスク中の失敗したジョブの詳細を表示します。
      • サンプルで上記URLはTID=279274となっていますが、そこに見たいタスクIDを入れます。
  • Deletion Service
    • DDM Deletion Activity Overviewを見ます。
      • 表の最後の項目「Errors」を確認します。たくさんのエラーが出ているところを報告します。たくさんとは、過去4時間に10個以上です。
      • GGUSチケットをサイトに発行します。このとき、Site CA-VICTORIA-WESTGRID-T2 has more than 18k deletion errors in last 4 hrsなどと記述します。
  • Tier0 Export
    • RUN2 (2015年6月開始)より、ADCoSでTier0 Exportをモニターします。
      • Tier0のテープへの書き込みと、Tier1への転送を監視する必要があります。
      • Tier0 Exportは生データの最初の扱いなので非常に重要です。失敗するとなくなる可能性があります。
    • Tier0のテープへの書き込み
    • Tier1へのデータ転送
  • 問題の報告
    • 問題を特定した場合、その内容により報告先が異なります。
      • サイトの問題の場合　GGUS(Global Grid User Suppoer)経由でチケットを発行。ブラウザに個人証明書をインストールしておく必要があります。2009年春以降米国のサイトの問題もGGUSを使うようになっています。使い方はこちら
      • サイト特定だがatlasの問題に思える場合はatlas-adc-cloud-XXアットcern.chに報告します。ここでXXはクラウドを表す文字で、CA, DE, ES, FR, IT, NL, TW, UK, USのいずれかです。
      • タスクの問題の場合　Jiraバグトラッキングシステム経由でチケットを発行。使い方はこちら
      • タスクの定義はPANDA monitorで見ることができます。
      • タスクの問題で、val1とかval3とかの名前で始まるジョブの場合　バリデーションジョブは別扱いで、問題がある場合はバリデーションJiraに報告します。
      • サイトバリデーションのタスクではタスク定義のコメントでdo not reportと書かれている場合があります。その場合、失敗していても報告の必要はありません。
      • サイトの問題の場合でジョブがどんどん吸い込まれ失敗して行っている状況ではその実行待ち行列をofflineにセットする必要があります。方法は追加情報にあります。
    • わからないときは状況をADC-VCRでシニアシフターに伝えましょう。
    • 誰もいないときはシフトメーリングリストに投げて反応を待ちましょう。
      • atlas-project-adc-operations-shiftsアットcern.chに報告
    • 何か処置をしたら必ず電子ログブックに記述します。
      • 電子ログブックの使い方はこちらを見てください。
↑

シフトの終了 †

  • シフトサマリー
    • シフト作業内容のまとめを書き込みます。
    • 詳細はこちらを見てください。
  • Trainee Shifterの評価
    • 同じシフトスロットにTraineeがいたときは、その人に関するEvaluationを24時間以内に送ります。
    • 報告すべき内容は次の通りです。
      • Active presence。ちゃんとシフトに参加して働いたか。
      • Monitoring tools understanding。モニター画面がちゃんと読めるか。
      • Errors understanding。失敗の原因が理解されているか。
      • Ticket handling。チケットをちゃんと送れるか。
      • Evaluation grade。総合得点。0:シフトが静かで評価をする出来事がなかった。1:初心者で勉強中。2:理解は進んでいるが独り立ちはまだ。3:もう独り立ちできる。シニアに昇格してよい。
↑

追加情報 †

↑

モニターページ †

  • ATLASダッシュボード
    • ダッシュボードの種類(ダッシュボードの一番上のボタンで選択できます。)
    • 個別のデータ転送の確認
      • DDMダッシュボードを見ます。
      • 表を見て、ErrorsのTransferの数字が大きいところを見ます。
      • そのクラウドの名前をクリックします。そのクラウドに含まれるストレージの名前がすべてリストされます。
      • その中でTransfer Errorsの多いストレージを確認します。転送成功率の低いときは赤や黄色で表示されています。
      • Transfer Errorsの数字をクリックするとエラーの統計が表示されます。
      • エラーの種類としてはDESTINATION error、TRANSFER error、SOURCE errorがあります。問題が送りもとと送り先のどちらにあるかがわかります。
      • ストレージ名の前についている+マークをクリックすると転送元のリストが表示されます。
      • エラー統計の表示の右端、エラーの数をクリックすると、失敗した転送の転送要求のリストが表示されます。
      • リストの左端項目である日付時刻をクリックするとその転送の詳細が表示されます。これで表示される情報はその転送を完全に記述しています。そのためGGUSチケットなどで第三者に知らせるときに必要です。
      • 送りもとと送り先のSURLが表示されるので、そのままコピーペーストしてlcg-cpなどコマンドで存在を確認するのに便利です。
      • 転送を何回試みたかも表示されます。ATTEMPT:
      • リストの論理ファイル名をクリックすると、そのファイルに関する転送履歴が表示されます。ものによっては失敗を繰り返しているものもあるし、状況によってはCOPIED、DONEと表示され、最終的には転送に成功している場合もあります。問題がまだ存在するのかどうかを確認できます。
    • 注意点
      • ダッシュボードでは同じジョブシーケンスのジョブのエラーを独立に数えます。失敗と再投入を繰り返すとダッシュボードに表示されるエラーの数はそれだけ増大します。例えば10ジョブを要求されたタスクでも10個が全部失敗して20回再投入されると都合200回のエラーとして報告されることになります。PANDAのタスクパラメータ表示を見て、要求ジョブ数と完了ジョブ数を確認しましょう。
      • 2010年より、T2からT2へのデータ転送が直接行えるようになりました。この場合、タイムアウトなどのエラーが多発する場合がありますが、サイトの問題とはいえない場合が多いため、T2-T2転送のエラーについては報告する必要がありません。
  • PANDAモニター
    • 個別のタスクの確認
      • RUN2では、一連のタスクの流れ、イベント生成からシミュレーション、ディジタイゼーションなどをタスクリクエストとして一括した取り扱いが可能になりました。
      • タスクリクエストは4桁の数字で表されます。
      • Pandaのタスク表示で一覧を見ることが出来ます。
      • reqidの数字はそのリクエストに含まれるタスクの数です。それをクリックするとタスクリクエストに所属するタスクのリストを表示します。
    • 個別のジョブの確認
      • Pandaのジョブ表示で一覧を見ることが出来ます。
      • 最初のサマリーのところでタスク毎のジョブ数やエラータイプ毎のジョブ数が得られます。
      • それぞれの数字をクリックすると該当するジョブリストが表示されます。
  • ジョブの確認
    • あるタスクが失敗しても、そのジョブは自動的に再試行されます。ある程度失敗を繰り返すとあきらめますが、状況によっては再試行により正常に走る場合もあります。タスクが失敗したからと行ってジョブが全部だめだとは限りません。
    • タスク表示でJobsと表示されたテーブルにあるジョブ名(mc08.*.job)をクリックするとそのジョブの履歴が表示されます。再試行を繰り返していても最後のジョブがfisishedであれば問題ありません。
    • ただ、このとき、再試行が別のサイトで行われて成功している場合は、元のサイトの問題は解決していないと考えなければなりません。同様なジョブが次にまたそのサイトに回されたとき失敗すると予想されるときは、資源の無駄遣いになってしまうので問題を解決しておく必要があります。
  • パンダパイロット
    • プロダクションページのクラウド毎の統計表の左から2番目のコラムがそのクラウドで走っているパイロットの数を表しています。
    • パンダではワーカーノード毎にパイロットが走っていて、それがジョブを呼び込む形でジョブが走ります。そのため、パイロットがいないとジョブは走れません。
    • クラウド名をクリックしてサイトを表示させます。そうするとサイト単位で走っているパイロットの数が表示されます。もしパイロットの数が0(空白)だとジョブが走れません。
    • このときはクラウドサポートatlas-support-cloud-xxアットcern.chにメールします。Elogにも記録を忘れずに。
↑

サイト診断のこつ †

  • プロダクションジョブの問題
    • 現在の状況の把握
      • モニターに表示されるのは過去4時間であったり24時間であったりします。
      • エラーが最後に発生した時刻に注目します。ほとんど現在の時刻と同じであればまだ問題は解決していないと考えた方が良いでしょう。一方、例えば8時間以上前に最後のエラーが出て、その後出ていないとすれば、そのエラーは対処が済んだと考えられます。
      • この辺のことをグラフで確認できます。PANDAの先頭ページの中程にProduction job summaryがクラウド毎に表示されています。クラウド名の横にグラフのアイコンがあります。それをクリックすると状態毎の過去の履歴がポップアップウインドウとして表示されます。
      • サイト毎に履歴が見たいときはクラウド名をクリックします。そうするとクラウド内のサイトが表示されます。このとき、オフラインにセットされたサイト名はグレーで表示されます。サイト名の横にあるグラフのアイコンをクリックすると同様にサイトの履歴がポップアップウインドウに表示されます。
    • サイトが所属するROC(Regional Operation Center)の見つけ方。
      • GOCDBのページの左側のメニューにあるList Sites per ROCをクリック。
      • ページの一番下に一ページにどれだけ表示するかを選択するメニューがあるのでALLを選択。もしくはここ。
      • これで知りたいサイトを「検索」すればそれが所属するROCがわかります。
      • CERNは北米などを含めキャッチオールROCとして働いていますが、これはそのうち変更になります。各国がROCを運用するようになる予定です。
      • GGUSチケット発行ポータルではROCを空白にしておくと文脈から自動的に探してくれます。
    • タスクリスト
      • バリデーションタスクのリストはPANDAモニターでみることができます。
    • Get error: No such file or directory
      • ジョブがこのメッセージでこけることがままあります。このとき、クラウド内の複数のTier2で発生する場合があります。ないと言われるデータセットはサイトのPRODDISKに関係しています。
      • この場合、考えられる原因として、DQ2でデータセットを消去するサービスが滞っているというのがあります。deletion service
      • Deletion overviewを見てみます。
      • クラウドの名前(CAやDEなど)をクリックするとサイト一覧が表示されます。
      • さらにサイト名をクリックするとそのサイトのスペーストークンが表示されます。
      • XXX_PRODDISKに消されるのを待っているデータセットがたくさんある場合、deletion backlogと呼ばれこのエラーの原因となります。
      • この場合、GGUSやSavannahのチケットの発行は必要ありません。Elogに記録を残すだけでよいです。backlogがない場合はデータセットがつぶれている可能性があります。DQ2-DDM Savannahに問題のデータセットについての報告を送ります。
  • ファイル転送の問題
    • サービスの状況の確認
      • DDMダッシュボードのサイト表示で一番右側に最近のSAMテストの結果が示されています。
      • 後述するSAMテストを見て、ファイル転送に関するサービスが正常かどうか確認することが出来ます。
      • srmlsやlcg-cpコマンドを使ってサービスやデータセットの状況を見ることが出来ます。
  • SAM(Site Availability Monitor)テスト
    • サイトの状態はLCGとATLASそれぞれで定期的にチェックされています。
    • Gstat2
      • LCGが行っているサービスで、サイトの様々な情報を見ることが出来ます。
    • ATLAS SAM test
      • ATLASで行っているテストの結果が表示されます。
  • Deletion Service
    • DDM Deletion Activity Overview
      • クラウドをクリックするとそのクラウド内のサイトが表示されます。
      • さらにサイトをクリックするとそのサイトのスペーストークンが表示されます。
      • スペーストークンをクリックすると、消去されるべきデータセットのリストが別ページに表示されます。
  • ソフトウエアリリース
    • 現在ではプロダクションソフトウエアはCVMFSを経由して自動的に各サイトに配布されています。HTTPを使って必要なファイルがファイルシステムの構造のまま各サイトに転送されます。
      • そのため、個別にリリースバージョンを調べる必要はありません。
      • 必要なリリースがないと言う時はCVMFSが動いていないということが考えられます。サイトのローカルサービスの問題の可能性があります。
      • 必要なファイルはSquidサービスを使ってサイトへ送られます。
    • サイトにインストールされているソフトウエアリリースの確認の方法
    • Release Missingエラー
      • クラウドやサイトに特定のリリースがインストールされていないというエラーが出ることがあります。
      • この場合、実際にインストールされていない、もしくはインストールに失敗している場合があります。上のリンクで確認します。されていない場合はGGUSで報告します。こちらをご覧ください。
      • 上記リンクからは正しくインストールされている様に見えるときは、一時的にリリースがインストールされたディレクトリが見えなくなってしまっている可能性があります。たとえばNFSサーバーが落ちたとか。サイトの障害と考えられます。GGUSを発行します。
↑

報告のための道具 †

  • 電子ログブック
    • アカウントの作成
      • 電子ログブックに記事を書くためにはログインしなければなりません。そのためにアカウントを作成する必要がありますが、WEB上で簡単にできます。
      • 電子ログブックを開きます。
      • Log inというボタンを押すとログイン画面が表示されます。その右下にRegister as new userというボタンがあります。それをクリックします。
      • 画面の指示に従って氏名、メールアドレス、アカウント名、パスワードなどを入力します。
    • ログの作成
      • どれかのエントリーのID番号をクリックするとその詳細が表示されます。そのとき、画面の上方にボタンが並んでいます。Newをクリックすると新しい項目を編集する画面に変わります。プルダウンメニューで必要な項目をセットし、記事を記入してSubmitします。
  • GGUS
    • チケットの閲覧
      • ホームページに最近のチケットなどが表示されています。
      • 下の方にあるshow all open ticketsをクリックすると開いているチケットがすべて表示されます。
      • 自分が発行しようとしている問題の内容がすでにチケットされている場合があります。重複しないように確認します。
      • すでに発行されたチケットを見つけたときには、そのチケットにpublic diaryとして情報を追加することができます。それによって問題解決を早めることができるかもしれません。
    • チケットの発行
      • ホームページのバナーの下にあるSubmit ticketをクリックします。
      • 通常のチケットの入力フォームが表示されますが、これは使いません。入力フォームの一番上にあるOpen team ticketをクリックします。
      • シフトではチームチケットと言ってシフター全員がチケットに関与できるチケットを発行します。
      • CCの行には追加したい電子メールアドレスを書きます。通常はサイトへチケットを送るとともにatlas-adc-cloud-XXにCCする場合があります。
      • Short Descriptionとチケット記事本体を記入します。
      • Change Priorityですが、次のような基準で決めます。
      • Top Priority: セントラルサービスなどATLAS全体に影響が及ぶ場合。
      • Very Urgent: Tier1のサービス。実データの転送などクラウド間に影響が及ぶ場合。
      • Urgent: その他のすべての障害。Tier2の問題など。
      • Less Urgent: 障害ではなく、情報として記録されるとき。
      • Type of problemを選びます。
      • MoU AreaはTier1かTier2かを選びます。ADCoSシフトの場合はアナリシスかその他が該当します。
      • Notify Siteで該当サイトを選択します。
      • 内容を確認したらSubmitボタンを押します。
    • チケットの更新
      • チケットで報告した内容に追加したいときや状況が変化したときなどはチケットを更新します。
      • GGUSの該当するチケットのページを開きます。
      • 真ん中あたりにModify section Ticket-ID: NNNNNというところがあります。
      • その下にPublic diary (Triggers email to submitter)というテキストボックスがあります。そこに加えたい内容を書き込みます。
      • 最後に一番下にあるSave modification and submitボタンを押します。
    • チケット記入の注意
      • チケットはサイト管理者に送られます。一般にATLASメンバーとは限りません。そのためATLAS固有の知識を前提として書いても理解されない場合があります。DQ2とかPANDAはATLASジャーゴンです。
      • 担当者が確認をしやすくするために失敗したジョブに関するパンダモニターのページへのリンクを書くべきです。
      • ファイル転送の場合は該当するページがないので、DDMダッシュボードからファイル転送の詳細を抜き出して貼り付けます。詳細は上述DDMダッシュボードのところを参照してください。
  • ADCO Support Jira
    • アカウントの作成
      • 画面左側のメニューの上の方に「Not Logged In」と赤字で書いてあり、その下にLoginとNew Userの選択肢があります。New Userをクリックします。
      • 登録画面に変わります。必要事項を記入します。アカウント名にはAFSのアカウント名を使うよう勧められています。
      • 最後にsubmitをクリックします。メールが自動的に送られます。それに応答することで確認が完了しログインできるようになります。
    • バグレポートの閲覧
      • ログインしていなくても見ることが出来ます。
      • メインの画面の上の方にメニュー項目が並んでいます。その中のSupportにカーソルを移動するとプロダウンメニューが表示されます。
      • プルダウンメニューからBrowseを選択します。Open(解決していない)な項目がピンクで、Close(解決した)な項目がグリーンで表示されます。
      • 項目のSummaryやIDをクリックするとその項目の詳細を見ることが出来ます。
    • バグレポートの作成
      • SupportのプルダウンメニューからSubmitを選択します。
      • 画面が投稿フォームに変わります。必要事項を記入します。
      • 投稿するグループによって記入する項目が異なります。同じグループに投稿された記事をBrowseで見ると何を書けばいいか想像できます。
      • 最後に画面一番下のSubmitをクリックします。
    • グループ
  • Shift Summary Page
    • シフト終了時に記入します。
    • Shifter timezoneはASIAです。
    • Check Listではダッシュボードを見ながら記入します。
      • Pilot jobはPandaモニターに表示されています。
      • Central Serviceでは次を見に行きます。
      • Service level status ここはNICEパスワードが聞かれます。
      • Physics Database Service
      • それぞれステータスが緑であればOKです。
      • ブラックリストされたサイトを見ます。
      • リストされたサイトで復旧が確認できたところを記載します。たとえばダウンタイムが終了したところなど。それ以外の場合は判断が難しいですが。

↑

サイトの実行待ち行列をonline/offlineにセットする。 †

  • 現在はハンマークラウドとスイッチャーというサービスにより、自動的にサイトのオンオフがされています。シフターが手動で操作することはほぼありません。ここでは参考までに掲載しておきます。
  • Linux端末から作業します。
    • 準備
      • 作業にはグリッド代理証明書が必要です。voms-proxy-initコマンドで生成します。 
        voms-proxy-init --voms atlas
      • /tmpに代理証明書が作られます。 
        ls /tmp/x509*
/tmp/x509up_u500
      • ここで最後の500というのは自分のLinuxのuidです。 
        ls /tmp/x509up_u`id -u`
      • でも同じ結果が得られます。バッククォーテーションでid -uコマンドを囲みます。
    • 確認事項
      • 待ち行列の状態をPANDAモニターのCloudsで確認します。autoでonlineだとします。
      • 待ち行列の名前を間違わないように。
    • autoからmanualへの変更を最初に行います。(表示の都合で2行に分けてありますが\続けて一行で記入してください。一行目の行末の\は不要です。)
curl -k --cert /tmp/x509up_u`id -u` \
 'https://panda.cern.ch:25943/server/controller/query?tpmes=setmanual\
&queue=Taiwan-LCG2-lcgpbs&comment=ELOG.12345'
  • ここでsetmanualがコマンド、Taiwan-LCG2-lcgpbsというのが待ち行列の名前です。
  • このとき、Taiwan-LCG2とサイト名を指定すると、そのサイトの全部のプロダクションキューが設定されますが、このときコメントが喪失してしまうので一つ一つキューの名前を指定してください。
  • certオプションで証明書を指定します。
  • 以下の項目を付け加えると良いでしょう。シングルクォーテーションの内側に追加します。特にコメント部分はPANDAモニターのキュー情報のところに表示されます。ここに後で述べるELOG番号を記述します。 
    &comment=ELOG.12345
  • 次にonlineからofflineに設定します。
    • 上記コマンドでsetofflineとします。
  • 問題が解決したと思われる場合testにします。
    • 上記コマンドでsettestとします。
    • この状態でテストジョブを投げてみます。(別項参照)
    • 問題がhじょきょされたことを確認します。
  • 問題が除去されてonlineに戻します。
    • 上記コマンドでsetonlineとします。
  • 最後にmanualからautoに設定します。
    • 上記コマンドでsetautoとします。
  • サイトの状態を変化させたときは必ずELOGにその旨を記述します。特にofflineにするときは以下のようにします。
    • まずELOGにofflineにセットする旨の記事を書きます。このELOGエントリー番号を上述のようにsetofflineのcommentに書きます。
    • 続いてサイトステータスSavannahにofflineにセットした旨を記述します。このとき、ELOGエントリーを参照します。これによってこのチケットを受け取った人がELOGに返事ができるようにします。
      • このとき、操作したキューの名前をSavannahチケットに書いておきましょう。同じサイトに複数キューがあって、それぞれの状況が異なることがあります。どれを元に戻せばよいのかわからなくなることがあるので、後からtestやonlineにする時に迷わないよう、キューの名前を明記しておきましょう。
    • 上述のELOGエントリーにreplyしてSavannahのチケット番号を記入します。これで相互に参照できるようになります。
  • ANALYキューについて
    • ANALY_ではじまるキューはHammerCloud?が管理しています。
      • onlineにしたりofflineにしたりする必要は通常ありません。
      • testというモードにはしません。代わりにHC.Test.Meというコメントをつけてbrokeroffにします。たとえば次のようになります。 
        curl -k --cert /tmp/x509up_u`id -u` \
 'https://panda.cern.ch:25943/server/controller/query?tpmes=setbrokeroff\
&queue=ANALY_TRIUMF&comment=HC.Test.Me'
  • これによりHammerCloud?がコメントを見つけて自動的にテストします。

↑

テストジョブ †

  • 現在ではテストジョブはハンマークラウドが自動的に送信し結果を確認しています。シフターが手動でテストジョブを送る必要はありません。参考までに記述を残します。
  • サイトのキューの状態をtestにセットしたらテストジョブを投入してその結果を見ます。問題なければonlineに戻します。
  • PANDAを使えるようにします。
    • SVN版です。リリース15以降はこちらで。
      • lxplus.cern.jpやlogin.icepp.jpで、voms-proxy-initを行ったところで。
  • スクリプトをダウンロードします。 
    mkdir panda
cd panda
svn co http://svnweb.cern.ch/guest/panda/panda-server/current/pandaserver/test
svn co http://svnweb.cern.ch/guest/panda/panda-server/current/pandaserver/taskbuffer
svn co http://svnweb.cern.ch/guest/panda/panda-server/current/pandaserver/userinterface
  • 作業環境を整えます。 
    cd test
export PYTHONPATH=..:$PYTHONPATH
  • これでテストジョブを投入する準備ができました。
    • evgenジョブを投げてみます。 
      python testEvgen16.py TOKYO-LCG2 FR
      • ここで実際には、TOKYO-LCG2にはサイト名、FRにはクラウド名を書きます。
    • g4simジョブを投げてみます。 
      python testG4Sim16.py TOKYO-LCG2 FR
  • デフォルト設定でうまく動かないときはスクリプトを編集します。evgenタスクはtestEvgen16.py、simタスクはtestG4sim16.pyを使用します。evgenタスクは入力ファイルを必要としないので走りやすいはず。simタスクは入力ファイルを取ってくるところからやりますのでより総合的なテストといえます。
    • testEvgen16.pyを編集します。次の部分の修正が必要です。(見栄えの関係で強引に改行していますが一行に書いて問題ありません。) 
         job.AtlasRelease      = 'Atlas-16.6.2'
   job.homepackage       = 'AtlasProduction/16.6.2.1'
   job.cmtConfig         = 'i686-slc5-gcc43-opt'
   job.jobParameters="2760 105048 19901 101 200 \
       MC10.105048.PythiaB_ccmu3mu1X.py %s NONE NONE NONE \
       MC10JobOpts-latest-test.tar.gz" % file.lfn
      • 編集が終わったらジョブをサブミットします。 
        python testEvgen16.py TOKYO-LCG2 FR
    • testG4sim16.pyを編集します。次の部分の修正が必要です。 
      prodDBlock = 'mc09_7TeV.105802.JF17_pythia_jet_filter.evgen.EVNT.e575_tid151441_00'
inputFile = 'EVNT.151441._002978.pool.root.1'
   job.AtlasRelease      = 'Atlas-16.6.2'
   job.homepackage       = 'AtlasProduction/16.6.2.1'
   job.cmtConfig         = 'i686-slc5-gcc43-opt'
   fileD.dataset    = 'ddo.000001.Atlas.Ideal.DBRelease.v090001'
   fileD.lfn = 'DBRelease-9.0.1.tar.gz'
   job.jobParameters="InputEvgenFile=%s OutputHitsFile=%s MaxEvents=50 " \ 
      "SkipEvents=4550 RandomSeed=316792 GeometryVersion=ATLAS-GEO-10-00-00 " \
      "PhysicsList=QGSP_BERT " \
      "JobConfig=VertexFromCondDB.py,jobConfig.LooperKiller.py,CalHits.py " \
      "DBRelease=%s ConditionsTag=OFLCOND-SIM-BS7T-02 IgnoreConfigError=False" \
      "AMITag=s765" % \
                      (fileI.lfn,fileOA.lfn,fileD.lfn)
    • 編集が終わったらジョブをサブミットします。 
      python testG4sim16.py TOKYO-LCG2 FR
  • ジョブの進行状況を確認します。Pandaモニターのtest job表示へ行きます。
    • このときtransferringまで進行するとログが見えます。成功したかどうかわかります。
    • すべて成功したらサイトをonlineに設定できます。ElogとSite Status Savannahに記録します。
  • simジョブの場合、パラメータを決めるのが大変ですが、そのサイトで最近成功したジョブのコピーを使うのが簡単でおすすめです。
    • pandaのプロダクションページでクラウドをクリックしてそのクラウド内のサイトを表示させます。そのfinishedの数字をクリックすると最近成功したジョブのリストが表示されます。
      • その数字が0の時は、Cloudメニューでキューの状態を表示させ、そのキュー名をクリックします。
      • キュー表示の上の方にLook for pilots on this queueというリンクがあります。それをクリックします。
      • 次のページでLook for recent INFN-FRASCATI Panda jobsというリンクがあります。添えrをクリックします。
      • ジョブのリストが表示されたら、States:がfinishedの数字をクリックします。
    • ジョブリストのTransformationsのところでcsc_atlasG4_trf.pyの数字をクリックします。
    • 最近成功したsimジョブのリストが表示されます。適当なジョブのジョブ番号をクリックします。テーブルの左端の欄の10桁の数字です。
    • ジョブの詳細な情報が表示されます。ここにすべての必要が情報が書かれています。
      • 一番上のテーブルのIn:に入力データセット名があります。たとえば　mc09_7TeV.105802.JF17_pythia_jet_filter.evgen.EVNT.e575_tid151441_00
      • 次のテーブルの中にデータベースのファイル名とデータセット名があります。DBRelease-9.0.1.tar.gz　と　ddo.000001.Atlas.Ideal.DBRelease.v090001
      • その下に入力ファイル名があります。EVNT.151441._002979.pool.root.1 その右には入力データセット名がありますが上と同じです。
      • jobの詳細がその下に書かれています。 
        AtlasRelease	Atlas-15.6.3
homepackage	AtlasProduction/15.6.3.10
jobParameters	InputEvgenFile=EVNT.151441._002979.pool.root.1 \
   OutputHitsFile=HITS.151493._316810.pool.root.1 MaxEvents=50 SkipEvents=450 \
   RandomSeed=316810 GeometryVersion=ATLAS-GEO-10-00-00 PhysicsList=QGSP_BERT \
   JobConfig=VertexFromCondDB.py,jobConfig.LooperKiller.py,CalHits.py \
   DBRelease=DBRelease-9.0.1.tar.gz ConditionsTag=OFLCOND-SIM-BS7T-02 \
   IgnoreConfigError=False AMITag=s765
      • このjobParametersはそのままでも使用できます。testG4sim15.pyではファイル名が%sで変関するように引数で与えられていますが。
      • これらの値を使ってtestG4sim15.pyを書き換えるのが簡単です。
  • ANALYキュー
    • ユーザーアナリシス用のキューはANALY_ではじまる名前を持っています。
      • これらのキューをテストするときは、testではなくbrokeroffにします。
      • 合わせて、コメントを次のようにします。&comment=HC.Test.Me
      • 以上をまとめると 
        curl -k --cert /tmp/x509up_u`id -u` \
'https://panda.cern.ch:25943/server/controller/query
&tpmes=brokeroff&queue=ANALY_TOKYO&comment=HC.TestMe'
      • これによりHammerCloud?が自動的にテストジョブを送ります。
↑

NO SPACE LEFT †

  • 現在ではサイトのディスク残量は自動的にモニターされ、残量が少なくなると自動的にブラックリストされます。ここでは参考までに記述を残します。
  • ファイル転送がDESTINATIONエラーでNO_SPACE_LEFTのために失敗しているときの措置
    • サイトのディスク残量を確認します。
    • この問題はサイトの使い方の問題であってサイトに問題があるわけではありません。
    • サイトの実行待ち行列をオフラインにします。方法はこちら
      • SCRATCHDISK(EGEE)やGROUPDISK(US)がフルの場合、ANALY_キューをオフラインにします。
      • PRODDISKがフルの場合、プロダクションキューをオフラインにします。
    • 自動的にクリーニング処理(使用頻度の低いファイルを消す)が行われるはず。
↑

ダウンタイム時の処理 †

  • 現在ではダウンタイムはAGISとSwitcherによって自動的にサイトキューがonline/offlineにセットされます。それ故シフターが手動で行うことはありません。ここでは参考のため記述を残します。
  • ダウンタイム開始時
    • サイトサービスのダウンタイムがはじまるときには、DDMはブラックリストされ、ジョブキューはofflineにセットされていなければなりません。
      • ブラックリストはAGISのダウンタイムを見て自動的にセットされるはずです。ブラックリストディスプレイhttp://bourricot.cern.ch/blacklisted_production.htmlにAGISと書かれています。
      • されていなければAMODに通告します。
      • ジョブキューの操作は手動です。その段階でonlineのままだとまずいので手動でofflineにセットします。サイトステータスサバンナに記録します。
  • ダウンタイム終了時
    • ブラックリストから解除
      • ダウンタイム終了で自動的に解除されるはずですが、いつまで待ってもブラックリストされたままの場合通告します。
    • ジョブキューをtestにセットしテストジョブを投入します。
      • 問題なければonlineに戻します。

↑

よくある障害(現在更新中。更新にご協力ください。) †

  • PANDプロダクションシステム関係(EXEPANDA)
    • EXEPANDA_JOBKILL_SIGTERM
      • 何かの原因でこのまま走らせることが適当でない場合にジョブが殺されます。問題解決後、このジョブはどこかで再度起動されると考えられます。ジョブシーケンスを確認して次が走っていれば良いとします。
      • ローカルバッチで、たとえばキューの最大CPU時間を超えてしまったりするとジョブは殺されます。何かの原因で予測よりずっと多くCPUを使ってしまった場合などに発生します。
      • このエラーでは要因としてGrid proxy certificate does not exist or is too shortと表示される場合があります。これはジョブが送られてから何らかの事情で実行完了までに24時間以上かかり、プロクシ証明書の期限が切れてしまう場合に起こります。その後、ジョブは再投入されます。通常は認証に問題があると言うことはあまりありません。
    • EXEPANDA_JOBKILL_BYPILOT
      • 上記と同様、パイロットによって殺されたものです。ジョブのオーナーがアボートしたときなど。
    • EXEPANDA_JOBEXPIRED_SIXDAYS
      • ジョブがサイトにアサインされたけれども、たとえば入力ファイルが用意されないなどの理由で実行されないまま一週間たってしまった。
    • EXEPANDA_ATHENA_START-FAILED-MISSING-INSTALLATION
      • athenaのリリースが見つからない場合です。本来、CEはどのリリースを持っているか公開しています。それを見てジョブが行くわけですが、行ってみたらリリースがない。これは深刻な問題なので報告します。2009年10月現在では、通常にGGUSチームチケットを発行します。このとき、atlas-grid-installアットcern.chにCCします。そしてチケットのサポートユニット(Assign ticket to support unit)をVOsupport、問題のタイプ(Type of problem)をVO Specific Softwareに設定して変更をサブミットします。
      • グリッド上のatlasソフトウエアのインストールの状況はこちらで見ることができます。
      • Gstatのサイトの表示にあるSub Cluster Informationからも見ることができます。
    • EXEPANDA_Release_MISSING
      • これも上記と同様です。
    • EXEPANDA_TRF_INSTALL-DIR-NOT-FOUND
      • これも同様の原因が考えられます。
    • EXEPANDA_NOSUCHDBRELEASEFILE
      • 指定されたバージョンのデータベースファイルが見つからない。クラウドにはコピーが用意されているはずですが何かの都合でそれができていないとこのエラーになります。ほかのリリースが正常に読める場合はインストールの問題です。
    • EXEPANDA_JOBDISPATCHER_HEARTBEAT
      • ネットワーク障害などでパイロットとの通信が途絶えたりすると発生するようです。GGUSチケットを発行します。
    • EXEPANDA_JOBDISPATCHER_NOREPLYTOSENTJOB
      • ワーカーノードに送られたジョブがパイロットから応答を待っていて30分以上経ってしまった。何か通信がうまく行っていない。これで落ちたジョブは再起動されるはずです。繰り返すようだとローカルエリアに問題がある可能性があります。その場合はGGUSです。
    • EXEPANDA_RUNJOBEXCEPTION
      • ジョブの中で、環境設定などathenaを走らせるための準備中に例外が発生してしまった。理由は色々と考えられますが。
    • EXEPANDA_CMTCONFIGMISMATCH
      • ジョブを走らせるために必要な環境変数CMTCONFIGの値と、実際にインストールされているプラットフォームの値が違う。例えばi686-slc4-gcc34-optが必要なのにローカルインストールはi386-linux26などとなっている。
    • EXEPANDA_PUT_GLOBUSSYSTEMERROR
      • athenaジョブが正常終了し、出力ファイルをlcg-crしようとしてGlobus system errorでこけた。ログを詳細に見ていくとglobus_xioに失敗していたりする。サイトの問題の場合が多いかも。
    • EXEPANDA_DQ2PUT_FILECOPYERROR
      • ジョブの出力を転送しようとして失敗している。LFCでmkdirできない。LFC_HOSTが解決できない。LFCホストの問題だと深刻だけれども、ジョブの側でホスト名解読に失敗している場合はサイト固有の問題。ジョブシーケンスで失敗を繰り返すのなら報告。
    • EXEPANDA_GET_LFCMODULEIMPORT
      • Pythonモジュールlfc.pyが見つからない。本来はWNインストールでlcg/lib/python/lfc.pyを見つけるはず。PYTHONPATHの設定がおかしい場合、ジョブの記述に問題があるかも。WNのインストールがおかしいとサイト問題。
    • EXEPANDA_GET_FAILEDTOGETLFCREPLICA
      • lfc_getreplicaコールで失敗。直接の原因はLFC参照の設定の問題だったり。上述のLFC_HOSTが解決できないとか。同じジョブシーケンスで失敗を繰り返すのなら報告。
    • EXEPANDA_DQ2_STAGEIN
      • 入力ファイルを用意する段階でget_fileでのエラー。パイロットログを見るとなぜこけたかがわかる。lcg-cpでタイムアウトしていたり。特定のサイトから持ってこようとしているとそのサイト側の問題と言うこともあり得る。
    • EXEPANDA_DQ2_FILEADD
      • ファイルを登録しようとして失敗している。
    • EXEPANDA_DQ2GET_INFILE
      • これも入力ファイルを取りに行って失敗している。srmcpコマンドがタイムアウトしていたり。ファイル転送の場合は送信側の問題の場合も受信側の問題もいずれも考えられます。
    • EXEPANDA_DQ2_SERVERERROR
      • could not get default storageとか、結構深刻なことを言ってくるかも。サーバーのエラーと言うことなのでサイトの問題として報告。
  • ジョブトランスフォーム関係(TRF)
    • これらのエラーはサイトのワーカーノードでathenaジョブを走らせて生じるエラーです。
      • PANDAモニターで失敗したジョブの情報を表示させます。ダッシュボードから行くときはfacilityid:の数字をクリックします。
      • ページの中程にあるFind and view log filesをクリックします。
      • ジョブを実行してできたファイルのリストが表示されます。その中のathena_stdout.txtやpilotlog.txt、jobReport.txt等の中身を調べて問題を理解します。
      • 時々、ダッシュボードに表示されるエラーは直接の原因でなく二次的に発生した障害を示す場合があります。ある原因でクラッシュし、その結果出力ファイルができなかったとき、出力ファイルが見つからないというエラーとして表示される時がありますが、本当のクラッシュの原因は別にあります。
      • 以下はTRF関係のエラーコードです。
    • TRFERROR
    • TRF_SEGFAULT
    • TRF_SEGVIO
    • TRF_SVRINIT
    • TRF_ATHENACRASH
    • TRF_OUTFILE
      • 出力ファイルが生成されなかった。これは結果であって、ジョブ失敗の直接の原因は他にある場合があります。athena_stdout.txtを調べて原因を追及しましょう。
  • NDGF(北欧グリッド)関係
    • GRIDARC_LRMS
    • WRAPARC_TRF_ATHENACRASH
  • ファイル転送関係(FTS)
    • DDMダッシュボードハウツーに詳細なエラーへの対応の仕方があります。
    • GENERAL_FAILURE:File is on an offline tape
    • GENERAL_FAILURE:Invalid Status returned by the SRM
    • GENERAL_FAILURE:File has no copy on tape or no diskcopies are accessible
    • REQUEST_TIMEOUT
    • PERMISSION
    • GRIDFTP_ERROR:No space left on device
      • これはファイル転送の問題ではなくて、ATLASの記憶域を使い切ってしまったということなのでatlas-support-cloud-xxにメールを送るとともにDDM Savannahに報告。
    • CONNECT
    • FILE_EXISTS:転送先にすでにファイルが存在する。サイトの問題と言うよりはDDMの不整合によるものでATLAS側に責任がある問題。DQ2-DDMサバンナに報告します。
↑

参考資料 †
トップ   編集 凍結 差分 バックアップ 添付 複製 名前変更 リロード   新規 一覧 単語検索 最終更新   ヘルプ   最終更新のRSS
Last-modified: 2016-08-25 (木) 15:19:50 (1646d)