AtlasJapanCERNComputing

<!--optional-->

CERN分室 計算機管理まとめ

PLEASE USE "WYSIWYG" TO EDIT THIS PAGE

(A button of "WYSIWYG" can be found in the bottom of this page.)

このtwikiは管理のためのメモです。(ユーザー用は AtlasJapanCERNComputingForUsers)

Rebooting policy

コンピュータのメンテナンスのため、再起動が必要になる場合があります。 分室のbatch nodeやdiskは予告なしに再起動を行うことがあります。 個人用のデスクトップは再起動前にできる限り使用者にできる限り連絡を取りますが、連絡が付かない場合は何時間か間を置いて再起動する場合があります。

Jira

こちらで、ToDoなど管理しています。参加する場合は澤田までご連絡ください。

定期行事

• 年に一度、CERNの電源メンテナンスがあるので、そのときは分室全体を停止する。(1月が多いが)
• 3月中旬頃に卒業案内をatut MLに配布。
  • home, data, maxi, eosなどのお片付け、引継ぎ
• 年に一度程度、各大学や研究機関にユーザーを削除していいか、責任者に連絡して聞く。
  • 削除していいなら、
    • /etc/passwd ... シェルを /sbin/nologin に変更。
    • home, data, maxiなどはWillDeleteDec2020など(Disk容量に余裕があるなら(大体)1年間の猶予を持たせる)を作って、そちらに移動。
• 過去のWillDeleteDec2019などのディレクトリーを適宜削除する。

分室の部屋

場所

• b188-5-007 ... 入った場所。広い部屋
• b188-5-009 ... 奥の部屋。狭い部屋

冷房

• 4つのスイッチパネルがあります。
  • 空調のパワーは100kWです。
• 冷房1 ... UNF3-00792-B (入って右奥)
• 冷房2 ... UNF3-00792-D (入って左奥)
• 冷房3 ... UNF3-00792-C (奥の部屋に入って右)
• 冷房4 ... UNF3-00792-A (入ってすぐの場所 ... スイッチが入らない)

電源バー

• 3つの電源バーがあります。
  • 1本が40A, 3相です。つまり、理想的には220V x 40A x 3相 x 3本 = 220V x 360A = 79.2kVの電源までOKです。
  • ただし、3相なので、負荷が同じぐらいになるようにバランスをさせるがよいとされています。
• 電源バー1 ... 入って右の壁 ... 大元ブレーカー中
• 電源バー2 ... 入って左の壁 ... 大元ブレーカー左
• 電源バー3 ... 奥の部屋 ... 大元ブレーカー右

ブレーカー

• 種類: 2種類あります。
  • 大元のブレーカー: 廊下に出て会議室部屋の近くにある扉の中。BOXが2つあるが、下側のBOXです。中に3個のブレーカーがあります。「電源バー」との対応は上にあり。
    • 会議室部屋の外の廊下側にあるBOXもブレーカーですが、これは会議室部屋の大電力用のブレーカーです。計算機部屋とは全く関係ありません。
  • 電源タップのブレーカー: それぞれのラックには背面に電源タップを設置してある。UPSは電源タップに(多くの場合)繋がっているので、このタップ上のブレーカーが動作することもある。

構成について

• ノードリスト
  • 分室 SLC6: lxatuthm1:/root/etc/nodes.list
  • CERN cloud SLC6: lxatuthm1:/root/etc/Cloud/sync/nodes.list
  • CERN cloud CC7: lxatuthm1:/root/etc/cc7Cloud/sync/nodes.list
  • 分室 CC7: lxatuthm1:/root/etc/cc7/nodes.list
• 計算機情報
  • lxatuthm1:/root/PClist.txt
• Disk情報
  • /home/atljphys/public/diskinfo.txt

Dataset distribution

• 分散のrequestは、atut-susy-dataprepにて行うので、ここに登録してもらう。データセットは必ずしも複数人で共有する目的でなくてもよい。D論に使うものが優先。古いものは適宜消していく。
• 昔は分室のmaxiに分散していたが、今はEOSへ置くことを推奨している。EOSでは実際には分散はしないが、一箇所にまとめ、所有者を変更することで管理しやすくしている。
• EOSでのコピー
  • 情報は JiraにSub taskを作って記録する。
  • ユーザーにファイルをダウンロードし、ACLをセットしてもらう。 ( ユーザー用のマニュアル)
  • atlas-eos-access-group-tokyo-adminsのメンバーがlxplusやlxatutのCC7のマシンにログイン
  • ACLが正しくセットされていれば、ユーザーがダウンロードしたファイルを、/eos/atlas/unpledged/group-tokyo/datafiles/SUSY/以下の適当な場所に mv できる。
  • 移動先に同じデータセットがないことを確認してからmv。
  • quotaを超えないか事前確認。必要ならquotaは大きくしておく。
  • chown -R rysawada directory_name のようにして所有者を変更する。
• maxiに分散
  • lxatutXXのどこかでatljphysになって、コマンドを実行
    • 分散のコマンド例:

    • ~rysawada//workspace/atljphysTool/dataset_distribution.py -t /home/atljphys/datafiles/SUSY1/data15_13TeV -m 171,172,173 download/data15_13TeV.*.DAOD_SUSY1.*

  • ~atljphs/public/diskinfo.txtに分散用diskのconfiguration
  • 2018年5月13日時点で
    • Configuration A: maxi108,109,110
    • Configuration B: maxi113,114,115
    • Configuration C: maxi116,125,126
    • Configuration D: maxi130,131,132
    • Configuration E: maxi167,168,169
    • Configuration F: maxi171,172,173
    • Configuration G: maxi127,119,120
    • Configuration H: maxi88,95,117
    • Configuration I: maxi161,176,177
    • Combination J: maxi209,213,217
    • Combination K: maxi210,214,221
  • ~rysawada/public/atljphysTool/dataset_distribution.pyに改良版
    • Dataset IDのない、period containerに対応
  • 壊れたファイルのみを新しいファイルで上書き
    • full pathで表示した新しいファイルのリストを作って（元のファイルと全く同じ名前、同じ親ディレクトリ）下記のようなコマンドを実行

    • ~rysawada/public/atljphysTool/fixCorruptedFile.sh filelist.txt ~atljphys/datafiles/SUSY/DAOD_SUSY1/mc15_13TeV

  • 分散したファイルをリンク先ごと消去
    • ~atljphys/datafilesの下の消したいdirectoryのリストを作って
    • directoryは/home/atljphys/datafiles/から始まるフルパスで書く。ワイルドカードが使えるかどうか試してないので
    • のようにディレクトリを検索して書くのが安全。

    • ~rysawada/public/atljphysTool/deleteFileList.sh directory.txt

    • find /home/atljphys/datafiles/SUSY/DAOD_SUSY11/data16_13TeV/ -maxdepth 1 -type d -and -name "*p2623"

Virtual Machine

• VMにはKVMというソフトウェアを使っている。

• lxatutb011などはvirtual machine. lxatutvh12などの上で走っている
  • 2019年7月19日時点で
    • ホストOSのホスト名: ゲストOSのホスト名
    • lxatutvh01: lxatutbs1, bs2
    • lxatutvh02: lxatut01, 02
    • lxatutvh03: lxatut13, 14, 15
    • lxatutvh04: lxatut16, 17, 18
    • lxatutvh05: lxatut11, 12, 20
    • lxatutvh08: nothing (this is for tests)
    • lxatutvh09: lxatutb005, b006
    • lxatutvh12: lxatutb011, b012

• virshというコマンドで管理

  • virsh list

    で起動している全machineを表示

  • virsh list --all

    で全machineを表示

  • virsh reboot <hostname>

    で再起動

  • virsh destroy <hostname>

    再起動でうまくいかないときはこれで強制終了

  • virsh start <hostname>

    止まっているnodeを起動

  • virsh dominfo <hostname>

    nodeの設定情報の表示(CPU, memoryの割り当てなど)

  • virsh setmaxmem <hostname> 10G

    nodeに割り当てる最大メモリ

  • virsh setmem <hostname> 9G --config

    nodeのOSに割り当てられるメモリ(分室ではsetmaxmemの設定値より1GB少なくしている。特に理由はない...たぶん。)

  • virst shutdown <hostname>

    • ゲストOSを停止する。

  • guestmount -d <hostname> -i /mnt

    • Host OSの/mntにゲストOSのファイルシステムをマウントすることができる。編集可能になる。IP addressが変更になったときなどに使う。
    • Host OSで実行する。ゲストOSは停止している必要がある。
    • umount /mntでアンマウントできる。

Condorの管理

• ユーザーとしての使い方は AtlasJapanCondorHowTo を見てください。
• ジョブが流れないノードがある → iptablesが悪さをしている可能性あり。
  lxatutbs1でroot権限で、

  /etc/init.d/iptables stop
  chkconfig iptables off

  で止める。lxatutbs1を再起動した場合、毎回必要かもしれない。
• exceed MAX_JOBS_SUBMITTEDと出てジョブを投げられない → どうやら~condor/system/etc/condor_configで設定しているMAX_JOBS_SUBMITTEDはジョブの数を積算していて、これを超えると投げられなくなるらしい。
  lxatutbs1でroot権限で

  condor_restart

  または

  /etc/init.do/condor restart

  で一度condorを再起動する
• jobのlogなどが、/home/condor/Backup/condor.lxatutbs1/condor/spool にjog_quere.*、history.*の名前で貯まるので、一定期間ごとに削除する必要あり。
• condor nodeへの加え方
  • lxatuthm1で、rootになってから各nodeにlogin
  • ~condor/system/etc/local_config/ の下に適当な設定ファイルのsymlinkを${HOSTNAME}.localの名で作る。その後、キックスタートで入れた場合には

    /etc/yum.repos.d/htcondor-stable.repoをどこか(i.e. lxatutb064)から取ってきておく。その後、

    ~condor/system/etc/condor_cc7.addservice
    
    ~rysawada/public/aim2/scripts/setquota(_cloud).sh

  • cloud machineの場合はsetquota_cloud.shを使用
• bs1とbs1は将来的に統合？

User registration

• 所属大学の先生やスタッフから、田中(東大)か澤田(東大)に申請する。lxplusのユーザー名と学年を通知する。
• root権限でlxatuthm1にログインし、/root/etcに移動。

  ./new_user (username)

  で追加。
  • yを一度押す必要があり
  • プライマリーのグループが違う場合のために、new_user_with_id uidとgidを指定できるバージョンだが、最近はそういう人はほとんどいない。
  • dfを一度して固まらないか試す。dfで固まるとこのスクリプトも途中でハングする。
• ユーザーアカウントができたら、
  • eosのe-group: atlas-eos-access-group-tokyoに登録 (administratorとして登録されている必要がある)
    • 上記のeosが傘下にいるため、atutへの追加は不要。
  • /etc/passwdを編集する。
    • いつごろ卒業するか、が大体判断できるようにするため、ある時点の身分を書き入れる。
      • たとえば、ICEPP所属のTanaka Taro(2015年にM2の場合)の場合、5番目のカラムをTaro Tanaka (TOKYO, M2-2015)　とする。
• /etc/passwdなどは毎朝4時(CERN時間)に同期されるので、それまで待ってもらうのがいい。
  • 緊急の場合は、lxatuthm1で、 /etc/cron.daily/sync-nodesを実行する。
• home directoryの変更 (所属の追記、必要ならシェルの変更)
  • /etc/passwdを編集する。全サーバーで変更する必要あり。毎朝4時に同期されるが、lxatuthm1で、/root/etc/sync-nodesを実行してもよい。
• ユーザーを無効にする場合は、/etc/passwdのログインシェルを/sbin/nologinにする。
• ユーザーのgidがzpじゃない場合に、zpにも属しているかどうかは、lxplusで、id user_nameでわかる。

EOS

• ユーザーアカウントができたら、eosのe-group: atlas-eos-access-group-tokyoに登録
• 各ユーザーは

  $ /home/atljphys/eos/bin/eos-mkMYTokyoDir.sh

  を実行
• 上記が問題なくできたら、/eos/atlas/unpledged/group-tokyo/users/${USER} を使用可能
• Quotaは50 TB/person程度

New directory on maxi

• rootで対象のmaxiがのっているサーバーにログイン
• mkdirでディレクトリ作成。名前は/etc/passwdを参照する。
• chmod xxx.yyy direcotory_name で所有者の設定。xxx.yyyに入るUIDとGIDは/etc/passwdを参照する。
• lxatuthm1:/home/atljphys/public/diskinfo.txt を編集。
• .tmp以下にディレクトリが残っている場合は使用者に連絡して、可能なら消す。

File copy

ディスクサーバの入れ替えなどで、ユーザのファイルを移動しなければいけない場合は、パーミッションに注意して行う。 NFS越しだとrootが全てのファイルを読み書きできるわけではないので、コピー元、コピー先それぞれでroot権限が使える方法でコピーする。 まずは、rootでコピー先のホストにログイン。

DON'T login this machine.

のようなメッセージが表示されるが、これは一般ユーザに向けての注意なので無視してよい。 例えば、

• rsync -auv --delete -e ssh lxatutd141:/export/maxi141/atljphys/username /export/maxi96/atljphys/username

とするとSSH越しでコピーが行われる。引数はコピー元、コピー先の順番。--deleteをつけるとコピー先のファイルがコピー元にない場合は消されるの注意。もし一度テストしてから実行したい場合は、-nをつけて走らせると何が行われるかを表示するだけで実際には何も行われないので、心配ならそれで一度確認するとよい。 また、コマンドの後に、

 2>&1 | tee /dev/shm/logfile.txt

をつけてエラーが起きてないかをチェックするとなおよい。途中で通信が切れたりするのが心配ならscreenの中で実行する。

ハードディスク交換 (Disk replacement)

日常の監視など

• ハードディスクが壊れた時は管理者に警告メールがくるので、以下で説明する方法で状態を確認して必要なら交換する。
  • ディスクはサイズを確認して基本的には同じものを交換する(2TB, 4TB, 10TB or 14TB)。2TB以下の交換用ディスクは基本的にないので、その場合は2TBを使う。
  • 予備のディスクがなくなったら、担当者(澤田)に連絡して発注させる。
• メールが来ない場合もあるので、たまに分室のハードディスクのLEDをチェックする。
• たまに担当者(澤田)がlxatuthm1:/root/tmp/3wareでsh ./CheckStatus.shして、DEGRADED(使えないので「交換」しなさい、という意味)、ECC-ERROR(たぶん「交換」... 今後調べます)、SMART-FAILURE(HDDが近い将来故障する可能性があるので早めに交換、という意味)をチェック。

交換作業で共通する注意

• 交換時にディスクサーバーの電源を落とす必要はありません。稼働状態で作業してください。
• 交換したHDDは廃棄しますので、扉付近の床に置いておいてください。RAID1のもの(=OSが入っているHDD)を交換した場合はトンカチ(机の引き出しの中にあるはず)でHDDを物理的に壊してください。RAID6(maxiなど)の場合は壊す必要はなく、そのまま床に置いてください。
• 廃棄されたサーバーに搭載されていたHDDの再利用について、以下の組み合わせで「OK」は通常通り作業できます。「ダメ」はとりあえず禁止です(HDDを刺すと面倒なことが起きますのでご注意を)。
  • 左辺 = 再利用するHDDが搭載されていたサーバーのRAIDメーカー
  • 右辺 = これからRAIDを再構築するサーバーのRAIDメーカー
    • adaptec -> adaptec ダメ
    • adaptec -> 3ware OK
    • 3ware -> adaptec OK
    • 3ware -> 3ware OK

3ware

• 3ware 3DM2 alert -- host: lxatutd152.cern.ch　あるいは　LSI 3DM2 alert -- host: lxatutd144.cern.ch　のようなメールが来たら、RAIDディスクエラーの可能性あり
• 該当するサーバーにログインして、root権限で

  /opt/AMCC/CLI/tw_cli /c0 show

  でRAIDの状況を確認
  • コマンドの場所が

    /opt/3ware/CLI/tw_cli

    の場合もある。(購入した時期による)
  • コントローラーの番号(e.g. /c0)が違う場合もある (例えば /c4)。間違った番号の場合は何も起きないので、/0から順番に探せばよい。
    • /c0, /c1, /c2, ... はサーバーに依存します。間違ったものを指定しても、「そんなRAIDコントローラーは存在しません」というだけなので問題ありません。
• OK以外(SMART-FAILURE, SMART-FAILURE)が出ていたら、そのディスクを取り出して別のものに交換。ECC-ERRORはrescanで消えることもあるが、消えなければ交換。エラーが出ているディスクにはランプが点灯している。
• 交換手順
  • 該当するHDDを交換する。
  • 交換したディスクは最初Unitがu?となっていることが多いので、

    /opt/AMCC/CLI/tw_cli /c0 rescan

    をする (u?が消えるまで、30秒待機+rescanを数度繰り返す。数回やっても駄目なら、時間を置いて再度やってみる。これでもu?のままならHDDを交換してみるなどする。u?のままでは次に進めない。)
    • showやrescanは何度行ってもいい。
  • [細心の注意が必要] 他がu0, u1なのに対して、交換したディスクはu2となることが多いので、一度これを消去するために

    /opt/AMCC/CLI/tw_cli /c0/u2 del

    を実行 (yes or noを聞かれますので、再度正しいものかどうかチェックしてyesを選択する)
    • ただし、元々u2がある場合は、u3になったりするので、そのときはu3を消去
    • 誤っても取り返しがつきませんので慎重に!
  • delを実行後、再度

    /opt/AMCC/CLI/tw_cli /c0 rescan

    を実行すると、自動的にRebuildが始まる。ただし、自動的に開始まで5分ぐらいかかることもある。Rebuildの進行状況はshowで確認。1時間ぐらい待ってもよい(気長に)。
  • いつまで待ってもRebuildが始まらない場合は

    /opt/AMCC/CLI/tw_cli maint rebuild c0 u1 p16

    のようにして手動で始めることもできる。

    p16

    は交換したスロット。
  • REBUILDには1日以上かかることもあります。

    /opt/AMCC/CLI/tw_cli /c0 show

    でRAIDの状態がREBUILDINGからOKになるまで気長に待ってください。
• HDDの場所が分からない場合、

  /opt/AMCC/CLI/tw_cli /c0/p16 identify=on

  でサーバーのHDDのLEDを点灯(点滅)させることができます。

• /opt/AMCC/CLI/tw_cli help, /opt/AMCC/CLI/tw_cli /c0 help

  などでどういった命令が使えるか分かります。

Adaptec

• 4Uサイズの筐体で24台のHDDが搭載できるサーバーです。
• Event Notification - Event Type: Error　のようなメールが来たら、RAIDディスクエラーの可能性あり。
• 交換手順
  • LEDが赤く光って異常を示しているディスクを交換する。
    • 過去にAdaptecで使われたディスク(左の小部屋の奥)を再利用してはいけない
  • 通常は自動的にRebuildが始まる。
• 通常は必要ないが、状態をみたり、手動で操作をした場合の方法。
  • X windowを起動した状態で、

    /usr/StorMan/StorMan.sh

    を実行すると、別ウィンドウにAdaptec Storage Managerが開く
    • Java関連のセキュリティホールのため /etc/rc.d/init.d/stor_agent stop (かつ、chkconfigで再起動しても起動しなくした) としたため、別のノードを操作することはできなくなりました。したがって、個別にログインして StorMan.sh を起動させてください。
  • !マークが付いているとこで何か問題が起こっているので、確認
  • Event Notification - Event Type: Warning の場合はたいてい大丈夫
    • Bad stripesの場合は特に何もしなくてよい。この警告を止めるには、全データを避難させてからRAIDを作り直さないといけない。
  • Errorが出ていた場合は、diskを取り出して交換。
    • どのdiskか分からない場合は、blink physicsl deviceで、LEDを点灯(点滅)させて確認
  • 自動的にRebuildが始まらない場合
    • たいていは、そのディスクをStorManの中でInitializeすれば始まる。それでも始まらない場合は以下のようにする。
    • Shut down the system and replace the failed drive with a new one (of equal or greater capacity). Boot the system, press Ctrl + A to access the BIOS / Configuration Utility of the HostRAID controller. Select "Array Configuration Utility". From the Array Configuration Utility (ACU) menu select "Manage Arrays". From the List of Arrays, select the array you want to rebuild. Press Ctrl + R to rebuild. Wait for the rebuild to be finished. Note: This procedure is not available with the Adaptec SATA RAID 1210SA.

Infortrend

• RAID Eventから始まるメールが来る。
• 交換手順
  • 異常を示しているディスクを交換する。
  • 通常は自動的にRebuildが始まる。
• ディスクを取り替えても自動でRAIDのRebuildが始まらない場合はWebブラウザでそのdisk array( "http://lxatutraid??" )にアクセスして、web UIからRebuildを始める。
  • PINは東京のコピー機と同じもの
  • どのディスクかわからない時は、webやフロントパネルでLEDでidentifyできる。

ソフトウェアRAID

• こんなエラーメール：DegradedArray event on /dev/md/2:lxatutvh05.cern.ch
  • md1 : active raid1 sdb1[1]
    204668800 blocks super 1.2 [2/1] [_U]
    bitmap: 2/2 pages [8KB], 65536KB chunk
• 対処法 (分室ではRAID1つまりミラータイプのRAIDで使っていることが大多数です。)
  • 該当マシンにrootでログインして、cat /proc/mdstat で確認する。
  • つぎに、RAID構成を考えて(他の壊れていないRAIDの構成方法などを参考にする)、たとえば、mdadm /dev/md1 --add /dev/sda1 を実行する。
  • これで失敗する場合は、HDDが壊れている可能性があるので、慎重に交換して同じことを実施。(間違ったものを抜かないように、注意。)

停電時の作業 (Work for power cut)

• 停電が計画されている時には、念のためすべてのマシンの電源を落とす
  • 実際の作業は/root/bin/shutdownMachines.shで行う。forで回すリストを切り替えながら計算機の機能毎に順に落としていく。以下その説明をする。ホームはこのスクリプトでは落とせないので、普通にコマンドで落とす。
  • CERN Cloudも立ち上がっているとdiskが落とせないので、落とす
  • 落とす順番
    • 1. 次のノード
      • lxatutXX ... loginノード
      • lxatutbXXX ... batchノード
      • lxatutbsX ... batchのヘッドノード(Condorの親分)
      • lxatutgpuXX ... GPUノード
      • winatutXX ... Windowsノード
      • pcatutXX ... Project baseのノード
      • [CERN Cloud (lxatut30以降とlxatutb400以降がCERNクラウドですので、上のloginノードとbatchノードに含まれます。)]
    • 2. disk (lxatutdXXX)
    • 3. backup (lxatutbkupX)
    • 4. ホーム (lxatuthm1)
      • (ホームに限ったことではないかもしれませんが) shutdown コマンドを打つ前に df をやってみる。df のコマンドがぱっと終了してプロンプトが戻ってこなかったら、 NFS マウントでつまっている問題であることおおいので、 umount -fl コマンドで強制アンマウント、再度 df で確認したのちに shutdown という手続きをとる。
    • 5. Infortrendのディスクアレー (lxatutraidXX)
      • Infortrendのディスクアレーはキャッシュがきれいになってから落とさないといけないので、 マニュアルの6-29に従う。これのコピーは分室のホワイトボードに貼ってある。Shutdownができていれば、手で電源を切っていい (勝手に止まりはしない)。Resetというのはrebootという意味なので、再起動するつもりがない場合には実行しない。
      • マニュアル中、適宜 Password を打つ必要があります。Up/Down で文字を選択、Ent で桁の移動、全桁をうったら Ent 長押しで確定
  • lxatuthm1でroot権限で/root/tmp/DoExec_for_AllNodes.shを使って、

    ssh ${loop} /sbin/shutdown -h 0:00 &

    などのコマンドを実行
    • ノードのリストは#MachineList
    • shutdownしてもなかなか落ちない時には、他の(すでに落ちた)NFSサーバーを見に行っていることが多い。その場合は/etc/mtabをみて、mountしているNFSディスクをumountする。ダメな場合はumount -flで強制的にumountする。
  • Cloudは同じ方法で落とせる。落ちたかどうかの確認は、https://openstack.cern.ch/project/instances/ から行う。STATUSがActiveのものでFilterして探す。
    • sshで落とせなかったらopenstackからでもよい。 LxAdm -Authorized-Usersというe-groupに入っている必要がある。lxplusからは入れない。

      • ssh aiadm.cern.ch

      • kinit

      • export OS_PROJECT_NAME="ATLAS-Tokyo Cluster service of data analysis for ATLAS Japan"

      • openstack server stop lxatutb604

        のようなコマンドをloop回す
    • CERN Cloud サーバーの操作 (start/shutoff) は web インターフェースからも (https://openstack.cern.ch/project/instances/) できる。 (操作の例)
• 電気が戻ったら、上記の逆の順番で復旧する。
  • ブレーカーが何度も落ちる場合には、電源を入れる計算機の順番を変えるなどして、トライする。それでもダメな場合は、UPSやサーバーの電源を落として再挑戦。
  • Infortrendのディスクアレーは、何もしなくても自動的に起動するはず。
  • 分室の計算機は電源ボタンを押して起動。
  • CERN cloudは以下のようにする。LxAdm-Authorized-Usersというe-groupに入っている必要がある。lxplusからは入れない。

    • ssh aiadm.cern.ch

    • kinit

    • export OS_PROJECT_NAME="ATLAS-Tokyo Cluster service of data analysis for ATLAS Japan"

    • openstack server start lxatutb604

      のようなコマンドをloop回して全部起動
  • CERN Cloud サーバーの操作 (start/shutoff) は web インターフェースからも (https://openstack.cern.ch/project/instances/) できる。 (操作の例)
  • 立ち上げ終了後に、lxatuthm1でroot権限で/root/bin/scanMachines.shを使って、起動したかどうかを確認する。
    • ノードのリストは ここ。スクリプト内でこのリストを使っているはず。
  • 正常終了しなかった場合には、コンソール(raritan)で状況を見て適宜対応する。以下は例。
    • マニュアルでfsckをかけないといけない場合もある。
      • /etc/fstabをみて問題のありそうなディスクのフォーマットをチェック
      • ここを参考に修復。ただし、実行するコマンドはフォーマットによって違うので注意; 例えば、fsck.xfsだったり、fsck.ext4だったりする。これらのコマンドを使う場合は　"-t ext3"のようなオプションは付けない。

バッテリー交換 (UPS replacement)

• 赤いLEDが光っていたら、交換する。
• バッテリーには1500VAと3000VAの二つのタイプがあるので、正しい方を使う。
  • 正しくないのは入らないはずなので、間違って入れることは起こらない。
• ラックマウントUPSは新旧二つのタイプがある。
  • 旧タイプ (ディスプレー無し)
    • 接続した計算機は稼動したままでいい。
    • バッテリーを入れ替えたら、1を長押し (「自己診断」モードになる)。
    • 替えた日付を書いたシールをバッテリー表面に貼っておく
  • 新タイプ (ディスプレー有り)
    • 接続した計算機は稼動したままでいい。
    • バッテリーを入れ替えたら、
      • 新しいバッテリー? YES
      • 日付入力
      • 「自己診断」開始
      • 替えた日付を書いたシールをバッテリー表面に貼っておく
• 替えた日付のためのシール
  • 作業机の「上」か「引き出しの中」に白いシールがあるので、July 2019などと書いてバッテリー表面に張る。
• 常に予備(1500VAと3000VA一個ずつ)を持っておく。予備がなければ担当者(澤田)に買わせる。

コンソール (Raritan) の使い方

• 計算機ノードの選択

  "Scroll Lock"

  をすばやく2回押す。

• ヘルプ表示: 計算機ノード選択画面にしてから

  F1

  を押す。

• 名前でソート: 計算機ノード選択画面にしてから

  F12

  を押す。

• ログアウト: 計算機ノード選択画面にしてから

  F9

  を押す。

• 名前の変更
  • 該当する誤った名前になっている計算機ノード選択する。
  • その状態で、計算機ノード選択画面にしてからF5を押す。
  • Channel Configurationを選択する。
  • 該当の計算機ノードを選択して、リターン。編集して、終わったらリターンを押す。
  • ESCを押すと保存するかどうか聞かれるのでYを押す。
  • ESCを何度か押せば、元の状態に戻る。

File server decommission

ファイルサーバーが要らなくなった時は、

• lxatuthm1で/etc/auto.dataを編集して該当行を消すかコメントアウト
• lxatuthm1 /root/etc/sync-nodes で手動で同期するか、朝4時まで待つ
• lxatuthm1でroot権限で/root/tmp/DoExec_for_AllNodes.shを使って/etc/init.d/autofs reloadを実行
• 該当サーバーを止める
• /home/atljphys/public/diskinfo.txtを編集
• ごみ箱(Garbage bin for server materials)をEDHで取り寄せて廃棄
  • 盗難を避けるため、できれば週の前半に廃棄してその週に回収してもらう
  • 廃棄するハードディスクのうち中身を見られては困るもの(例えばrootの認証キーがあるもの)はチップを金づちで破壊する
  • 備品については、
    • 備品シールと全体の写真を撮る
    • 備品シールを綺麗に剥がして、写真とともに秘書さんに提出
  • ディスクを再利用する際には取り出し元が3wareかAdaptecかわかるようにしておく。

Package Cleanup

• [UPDATE] - FAILURE on lxatutXX.cern.ch のようなメールが来たら、package-cleanupを実行
  • 個別に実行する場合: 各nodeでrootになって、

    package-cleanup -y --oldkernels --count 2

    を実行
  • 一斉に実行する場合: lxatuthm1でrootになって、/root/tmp/DoExec_for_AllNodes.shで下記の行を有効にして実行

    scp removeKernels.sh ${loop}:
    ssh ${loop} /root/removeKernels.sh
    ssh ${loop} rm -f removeKernels.sh

  • Batch以外にも走らせるなら、次のを消して、その次のを有効にする。

    for loop in `cat /root/etc/batch_list.txt`
    
    for loop in `cat /root/tmp/nodes.list.all`

  • 古いkernelを使っていると、消去できないのでrebootして新しいkernelに更新する
• RPMは問題ないが、/export以下のディスクのマウントがおかしい場合もエラーになる。その場合は /var/log/yum-autoupdate.log に関連したエラーメッセージがある。以下のようになっている場合は、再マウントするとなおる。

  ?--x-wsrwx 4849302817095439445 1868771141 1953850738 122K Jan  1  1970 /export/maxi152

Kickstart

• ~ shimpei/workspace/aims2 に大元のファイル
  • ~rysawada/public/aim2 に若干新しいファイル
• 実行例
  • CERN networkに登録
    • 登録や変更は https://network.cern.ch/sc/fcgi/sc.fcgi?Action=Main
    • 他のホストの例を見て同じように登録する。例えば、outletは0007/09
    • 固定IPも登録する。
    • ResponsibleまたはMain Userとして登録されていないと、あとのaims2 clientが使えない。（e-groupで認証する方法もあるようだが未確認）
  • (optional) 多数の同型ホスト（ディスクサーバーなど）を作る時は、ホスト名（.cern.chは省略）を一行一台書いたファイルを用意してもよい。
  • kickstart fileを準備。templateが各種あるので、それを使って(例えばks.tmplを使う場合は)

    $ scripts/make-kickstart.py --template ks.tmpl --out-dir (some directory) --host (host names)

    • これで(some directory)に(hostname).ksというファイルがホストごとにできる。ホストのネットワークインターフェース情報はLanDBから取得される。
    • 上の(optional)でファイルを書いたなら、--host (host names) の代わりに --file (file path)
    • 必要であれば中身をいろいろ変更する。パーティションの切り方など。
    • ファイルのチェックは ksvalidator でできる。これから入れようとしているのと同じOSでチェックするのがよい。
  • 適当なlinuxにlogin (CC7の方がいい？)でkinit
  • aims2 clientを使ってkickstart登録。aims2clientがインストールされてない場合はyum等で入れる

    $ aims2 addhost --hostname (hostname without .cern.ch) --kickstart (hostname).ks --pxe --name CC7_x86_64 --kopts "ksdevice=bootif"

  • これでPXE installationが予約されるので、ターゲットホスト起動後にkickstart installが始まる
    • そのままだとホストを再起動するたびにインストールが始まることになるが、新しい（CC7以降）のテンプレートではKickstartファイル内からPXEを止めるコマンドを打つことでそれを回避している
    • ただし、PXEがオフになってもKickstartの情報はAIMS2のデータベースに残るので、後片付けとしてエントリを消すのもよい：

      $ aims2 delhost (hostname)

  • 必要に応じて/root/etc/nodes.list, /root/etc/desktop/nodes.list, /root/etc/onlydata/nodes.list等に追加。sync等が可能になるように一度lxatuthm1のrootからsshしておく。 /etc/eos がない場合は作らないと失敗する。
  • インストール後、home directoryなどをマウントするには、毎朝4時の同期を待つか、lxatuthm1 /root/etc/sync-nodes (CC7だと/root/etc/cc7/sync-nodes) で手動で同期する。
  • ポストインストール
    • CC7
      • https://its.cern.ch/jira/browse/ATLJPATUT-97 にある対応 をしてから再起動。
      • mkdir /etc/eos
      • /usr/bin/locmap --list
      • /usr/bin/locmap --enable ssh
      • /usr/bin/locmap --configure ssh
      • /usr/bin/locmap --enable kerberos
      • /usr/bin/locmap --configure kerberos
      • /usr/bin/locmap --enable eosclient
      • /usr/bin/locmap --configure eosclient
      • systemctl restart sshd
      • /afs/cern.ch/user/r/rysawada/public/aim2/scripts/cvmfs-install
• • • SLC6 *afsを使うには/etc/krb5.confを他のAFSが動いているところからコピーする。
      • $ ~rysawada/public/aim2/scripts/cvmfs-install
        • 最近の設定では、/bin/fusermount のgroupがgangliaになっているせいで、cvmfsが見えない。chgrp fuse /bin/fusermount でgroupを変えると見えるようになる。
      • eosのインストールはまだkickstartで入れるようになっていないので手で入れる。http://eos-docs.web.cern.ch/eos-docs/quickstart.html)
        • (Beryl-Aquamarineは古いので、Citrineを入れる。)
        • yum install eos-client
    • condor nodeにする場合 (CC7)
      • lxatuthm1で、rootになってから各nodeにlogin
      • ~condor/system/etc/local_config/ の下に適当な設定ファイルのsymlinkを${HOSTNAME}.localの名で作る。
      • /etc/yum.repos.d/htcondor-stable.repoをどこか(i.e. lxatutb064)から取ってきておく。
      • ~condor/system/etc/condor_cc7.addservice
    • ディスクマシンの場合 (CC7, SLC6共通)
      • /etc/motdを他のマシンと同様に変更。
      • rootでcrontabを他のdisk serverと同様に設定し、makeLSlRfile.shが適切なmaxiに対して実行されるようにする。(一度手で実行してテストする)
    • 作業用マシン(lxatut??)の場合 (CC7, SLC6共通)
      • 非クラウドマシンで/localを一時ファイル置き場にした場合: ~rysawada/public/aim2/scripts/setquota.sh
      • 非クラウドマシンで/tmpを一時ファイル置き場にした場合: ~rysawada/public/aim2/scripts/setquota_tmpdir.sh
      • クラウドマシン: ~rysawada/public/aim2/scripts/setquota_cloud.sh
      • (これは廃止) atljphysではlxatut01以外の他のマシンでのcrontab -lの内容をcrontab -eで追加
    • ごくたまに、/etc/ssh/の秘密鍵ファイルのオーナーグループ（ssh_keys）がインストールのどこかの段階で消える。理由は全く不明。これが起きるとCC7ではノードにSSHできなくなる。SSHを試みると/var/log/messagesにprivate keyのパーミッションについてエラーメッセージが出る。chownでroot:rootにしてしまってもいいが、
      groupadd --gid 991 --system ssh_keys
      で対応してもいい（GIDはもしかしたら991でないかも。ls -l /etc/sshで確認すべき）

CERN cloud

• CERN clouldの管理者になるためには
  • atlas-eos-access-group-tokyo-adminsというe-groupに加入する必要がある。澤田、田中にコンタクトすべし。
• CERN cloudのインストール
  • ここを参考にする。まずは、いくつかのegroup(e.g. LxAdm -Authorized-Users)に入る。
  • aiadm.cern.chにssh
  • export OS_PROJECT_NAME="ATLAS-Tokyo Cluster service of data analysis for ATLAS Japan"
  • ai-bs --foreman-hostgroup atljcluster --cc7 --landb-responsible atlas-eos-access-group-tokyo-admins --nova-flavor m2.large --nova-sshkey atutcloudadmin hostname.cern.ch
  • インスタンスが出来てから
  • もし、volumeがない場合は次のようにする。VMを作り直すなど、昔のものが残っているなら再利用する。
    • openstack volume create --size 40 volumename --type standard
  • openstack server add volume hostname volumename
    • volumenameは、例えばatutvol31, atutbvol616, atutbvolbs3が存在する。
  • root@lxatuthm1から新しいホストにログインする。古い.ssh/know_hostの行は消す必要がある。
  • 普通にログインできるようになるまでにはpuppetが成功する必要がある。暫く待っても普通にログインできない場合は-i ~/.ssh/atutcloudadminを使う。
  • root@lxatuthm1で 例えば/root/etc/cc7Cloud/sync/nodes.listを変更してからそこにあるsync-nodes。場合によっては、タイプの違うnodes.listから該当するホストを除く必要もある。nodes.listのリストは/etc/cron.daily/sync-nodesから分かる。
  • rootで新しいホストにログインし、/mntが正しくxfsでマウントされていたら、~rysawada/public/aim2/scripts/setquota_cloud.sh
  • /homeは/etc/systemd/system/home.serviceによって、/usr/local/libexec/home.shが実行されてリンクに置き換えられることになっている。なっていない場合はrebootするか、手でrootでスクリプトを実行する。
  • condorのバッチノードにする場合は~condor/system/etc/local_config/ の下に適当な設定ファイルのsymlinkを${HOSTNAME}.localの名で作る。その後 ~condor/system/etc/condor_cc7.addservice

• CERN cloudの消去
  • aiadmでai-kill hostname.cern.ch

Mail from server

• 各nodeの/root/.forwardに転送先のメールアドレスを書く
  • 全nodeで一斉に変更したい場合は、lxatuthm1の/root/tmp/DoExec_for_AllNodes.shで下記の行を実行

    scp /root/tmp/dot.forward ${loop}:/root/.forward

    /root/tmp/dot.forwardは予め編集しておく
• check_quotaのメール
  • lxatuthm1の/root/bin/chk_quotas.shで設定
• warnquotaのメール
  • lxatuthm1および/data/dataXを置いているdisk serverの/etc/warnquota.conf を編集
• checknonquotaのメール
  • lxatuthm1と/data/dataxを積んでるサーバーの /root/bin/checknonquota.py を編集
• CERN cloudからのメール
  • atljclusterのdata/hostgroup/atljcluster.yamlを変更してcommit,push (masterブランチ)
• 3wareからのメール
  • /etc/3dm2/3dm2.conf を編集後、/etc/init.d/tdm2 restart
• Adaptecからのメール
  • 各ノードで/usr/StorMan/StorMan.shを実行
  • ConfigureのタブからEmail Notificationsに行って、メールアドレスを追加
    • ERRORで十分だが、4台に1台ぐらいはERROR, WARNINGにする。これは部屋の温度が上昇するとエラーを受け取れるから。
• Cron <root@pcatut02> /usr/bin/kinit -k というメールが毎日来る
  • cronジョブでkinitを実行しているせい。DFSのため？
  • とりあえず、/etc/cron.d/host-kinitを空にしたら消える
• InfortrendのRAIDからのメール
  • そのRAIDに直接ブラウザで接続して変更。パスワードは東京のコピー機と同じ。
• UPS関連
  • root宛に送られるので、それが上記の/root/.forwardで転送される。
  • 一部のホスト(d085, d105, d109)は/etc/apcupsd/apccontrolでb188-computing-room-monitoring@cern.chにも送っている。

InfortrendのRAIDについて

このタイプはディスクアレーとNFSサーバーは分かれていて、sshでディスクアレーにログインはできない。 対応はlxatuthm1:/root/PClist.txtに書かれている。

管理は直接ブラウザで接続して行う。(ブラウザによってはつながらない。現段階(2018年)ではFirefoxはOK。) DNS serverを設定できないので、メールサーバーなどはIPアドレスで設定しないといけない。

新品の場合は、まずCERNに登録するのにMacアドレスが必要だがフロントパネルだと全部の桁数表示されないが、今までのパターンからすると、フロントパネルに表示されているものの前に 00 をつければ多分大丈夫 (e.g. 00-32-D0-A1-73-01)。ダメな場合は、まずはRS-232Cで接続しないといけない。 lxatutd151からだと成功した。baud rateは9600だとOKだった。puttyで接続できる。 接続直後は真っ暗だがESCを押したり、矢印を押したりすると何か現れて最終的には操作できるようになる。 Webログインとパネルのパスワードが同じで、入力が面倒なので、東京のいつものを設定してある。
2023年追記:baud rateはディスクアレーから読み取った38400(デフォルト?)にしたらできた。Escを何回か押して、Terminal (VT100) みたいなものを選ぶと、操作画面に遷移した。lxatutd151で putty -serialコマンドを使用して、/dev/ttyS0に接続した。

GPU machine

• lxatutgpu01とlxatutgpu02はGPU programming用のマシン。gpu02の方が速いGPU(V100)を持っている。
  • GPUプログラミングにはNVIDIAのCUDAというものを使う

• • lxatutgpu01
    • /usr/local/ssd/zpは700GBぐらいあるので、作業中はここを使ってもいいです。それほど大きな領域ではないので、仕事が終わったらかたずけてください。
  • lxatutgpu02
    • /usr/local/scratchは9TBぐらいあるので、作業中はここを使ってもいいです。大きな領域ですが、適宜かたずけてください。その他、/usr/local/ssd/zpはSSDで300GB程度ぐらいあります。SSDの速さが必要ならばここを一時的に使ってください。

マシーンラーニング with keras/tensorflow

• lxatutgpu01や02では GPU が乗っているのでlxplusでやるよりはやい。
  • 以下のコマンドでlocalに入れたtensorflow/kerasと対応すrootが使える。(rootのバージョンは変わるかもしれないので適当に変えてください。)

    $ source /usr/local/tensorflow/bin/activate
    $ source /usr/local/cern/install/root-6.12.04_python3/bin/thisroot.sh

  • PyTorch を使う場合は

    $ source /usr/local/tensorflow_python36/bin/activate

  • PyTorch の古いバージョン(0.3)を使う場合は

    $ source /usr/local/tensorflow_python36_pytorch0.3/bin/activate

  • GPUを使わない場合は、特殊なことはないので、以上のようなセットアップでうまくいかない場合や、lxplusなどの場合は自分で環境を作ってください。例えば、

$ cd /any/directory/you/make/an/environement
$ virtualenv myenv -p /usr/bin/python3.6
$ source myenv/bin/activate
$ pip install -U pip wheel setuptools
$ pip install tensorflow keras h5py theano pandas sklearn matplotlib

• • もしGPU周りで怒られたらドライバーかCUDAが見えていないので澤田に教えてください

<!--
* ????????local????tensorflow/keras????????
* virtualenv???????????virtualenv?????<verbatim>
$ source /usr/local/tensorflow/bin/activate
$ cp ~mmorinag/mnist_cnn.py ./
$ chmod +x mnist_cnn.py
$ ./mmorinag/mnist_cnn.py</verbatim>
* virtualenv???????<verbatim>
$ deactivate</verbatim>
* ???
-->

Conference room PC

• b188-5-011のパス: C0nfR00m(Year)

Temperature sensors

温度のデータは ここで見ることができる。スマートフォン用のアプリもある。アカウントは二つあり、管理者用と読み取り用。読み取り用のアカウントは以下

• ID: rbab7682
• パスワード: lxatutondo

以下、温度計のリスト。DHCPがうまくいかないことがあるので、固定IPを使っている。

• tmatut01
  • 計算機室の右奥
  • Registration code: 36935392
  • Serial: 52160AB7
  • MAC address: 00:0d:8b:05:0a:b7
  • IPv4: 128.141.214.242
  • Outlet: 0188-5:0007/10
  • Default gateway: 128.141.214.1
  • Subnet mask: 255.255.255.0
  • (Broadcast address: 128.141.214.255)
  • DNS servers: 137.138.16.5 and 137.138.17.5

警告はb188-computing-room-monitoring@cern.chに送られる。

管理用 Raspberry Pi

部屋の奥の方のラックにRaspberry Pi (Model 4B, 8GB RAM + Camera module (no IR filter))が括り付けられている。場所は備え付けのカメラで冷房のコントロールパネルを監視しているため。

ノード名：rpiutokyo01.dyndns.cern.ch (wifiでCERN networkに接続・IPアドレスは動的)
ログイン：lxatuthm1のrootになって ssh pi@rpiutokyo01NOSPAMPLEASE.dyndns.cern.ch （セキュリティのためパスワードログインは禁止してある）

現在のところ冷房スイッチのコントロールにしか使っていないが、汎用Linuxノードなので他のタスクにも使用可能。

Switchbot

冷房１・２・３のコントロールパネルにSwitchbotが両面テープで貼り付けられている。近隣の任意のBluetoothデバイスからコマンドを送ることで、冷房のOn/Offができる。rpiutokyo01からコントロールする場合は

cd ~/ac_control
./ac_control.sh (1|2|3)

Live streaming

冷房１・２のコントロールパネルをrpiutokyo01のカメラで常時モニターしている 。CERNネットワーク内から http://rpiutokyo01.dyndns.cern.ch:8000 でアクセス可能。わかりにくいが、こちらの写真の矢印の先にある白い点がコントロールパネルのLED。冷房にエラーが発生すると点滅する。

• Webサーバーが起動していない場合は、rpiutokyo01で~pi/ac_control/video_stream.pyを実行。現在のところはユーザーpiとしてscreenセッションの中でforegroundで実行しているが、もっとスマートな方法（ちゃんとしたデーモンにするetc）を考えるべきか？

ネットワーク

• b188のマシンはHP ProCurve 5412zlというスイッチ(lxatutsw10.cern.ch)でCERNのネットワークと接続されている。
  • 歴史的な経緯でVLANの名前はROOM007になっているが、すべてuntaggedなので、lxatutsw10にあるポートはA1とA2以外はどこを使ってもOK。
  • ポートA1/A2はTruckされていて、CERNのネットワークと接続されている。10Gbpsが2本なので、最大20Gbpsまで通信可能。
  • ログイン名はadmin。
  • lxatutsw10のスイッチはWeb経由でJaveアプリを使って設定できていたが、ほとんど(すべて?)のブラウザがJavaを無効にしたので実際には使えない。
• HP ProCurve 6600-48G-4XGはlxatutsw24等で利用している。
  • sw10と同じ理由でWeb経由のアクセスは実質できない。
  • パスワードのみ(ログイン名無し)
  • RJ45が刺さる場所が2か所あるので間違えないように。コンソールの方に刺す。
  • ログイン後は menu というコマンドを使えばいい。(5412zlも同じ)
• RC232でシリアル通信で設置するしか手段がなくなった。Linuxでも可能で、screen /dev/ttyUSB0 9600 などでOK。抜けるときはctrl-aとしてからkを押す(うまく行かないこともあるが)。ただし、管理者権限が必要。(2022/10/29時点で lxatutgpu02 にケーブルを指している。)
  • gktermというソフトがLinuxにはある。 ここ。 オリジナル。 CentOS用。(自己責任)

Various information

• diskの使用者: /home/atljphys/public/diskinfo.txt
• PCの使用者: lxatuthm1の/root/PClist.txt