AtlasJapanCERNComputing

CERN分室 計算機管理まとめ

PLEASE USE "WYSIWYG" TO EDIT THIS PAGE

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

このtwikiは管理のためのメモです。

Rebooting policy

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

定期行事

  • 年に一度、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論に使うものが優先。古いものは適宜消していく。
  • lxatutXXのどこかでatljphysになって、コマンドを実行
    • 分散のコマンド例:
      ~rysawada/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/workspace/atljphysTool/dataset_distribution.pyに改良版
    • Dataset IDのない、period containerに対応
  • 壊れたファイルのみを新しいファイルで上書き
    • full pathで表示した新しいファイルのリストを作って(元のファイルと全く同じ名前、同じ親ディレクトリ)下記のようなコマンドを実行
      ~rysawada/workspace/atljphysTool/fixCorruptedFile.sh filelist.txt ~atljphys/datafiles/SUSY/DAOD_SUSY1/mc15_13TeV
  • 分散したファイルをリンク先ごと消去
    • ~atljphys/datafilesの下の消したいdirectoryのリストを作って
      ~rysawada/workspace/atljphysTool/deleteFileList.sh directory.txt
      directoryは/home/atljphys/datafiles/から始まるフルパスで書く。ワイルドカードが使えるかどうか試してないので
      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

  • ジョブが流れないノードがある → iptablesが悪さをしている可能性あり。
    lxatutbs1でroot権限で、
    /etc/init.d/iptables stop
    chkconfig iptables off
    で止める。lxatutbs1を再起動した場合、毎回必要かもしれない。
  • exceed MAX_JOBS_SUBMITTEDと出てジョブを投げられない → どうやら~condor/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/etc/local_config/ の下に適当な設定ファイルのsymlinkを${HOSTNAME}.localの名で作る。その後、
      ~condor/etc/condor.addservice
      ~rysawada/workspace/aims2/scripts/setquota(_cloud).sh
    • cloud machineの場合はsetquota_cloud.shを使用
  • bs1とbs1は将来的に統合?

User registration

  • 所属大学の先生やスタッフから、田中(東大)か澤田(東大)に申請する。lxplusのユーザー名と学年を通知する。
  • root権限でlxatuthm1にログインし、/root/etcに移動。
    ./new_user&#x3000;(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にする。

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など)の場合は壊す必要はなく、そのまま床に置いてください。

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できる。

停電時の作業 (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/workspace/aims2 に若干新しいファイル
  • 実行例
    • CERN networkに登録
    • hostnameを書いたファイル(ファイル名 hosts)を用意
    • MAC addressを抽出
      $ scripts/landb.pl (hostname) --output=hosts.landb
    • kickstart fileを準備。templateが各種あるので、それを使って(例えばks.tmplを使う場合は)
      $ scripts/ks.pl -f hosts.landb -t ks.tmpl
      • これで(hostname).ksというファイルができる。
      • 中身をいろいろ変更する。
        • IPがxxx.xxx.xxx.xxxとなっているので、登録したIPを入れる。
        • netmask等も正しいものを入れる。(固定IPを登録した時に、連絡メールが来る)
        • パーティションの切り方を適宜変更。
    • 適当なlinuxにlogin (CC7の方がいい?)でkinit
    • aims2 clientを使ってkickstart登録。aims2clientがインストールされてない場合はyum等で入れる
      $ aims2 addhost --hostname (hostname) --kickstart (hostname).ks --pxe --name SLC6X_x86_64 --kopts "ksdevice=eth0"
      • 最後のksdeviceはポートによって変更 (eth1, eno0, eno1等があり得る)
      • CC7を入れる場合、nameはCC7_X86_64
    • pxeがenableならば起動後にkickstart installが始まる
      • インストール後はpxeoff/deregistrationのステップを入れておかないとinstallが無限にループするので注意
    • インストール後、home directoryなどをマウントするには、毎朝4時の同期を待つか、lxatuthm1 /root/etc/sync-nodes (CC7だと/root/etc/cc7/sync-nodes) で手動で同期する。
    • CC7はインストール後
      /usr/bin/locmap --list
      /usr/bin/locmap --enable ssh
      /usr/bin/locmap --configure ssh
      /usr/bin/locmap --enable kerberos
      /usr/bin/locmap --configure kerberos
      systemctl restart sshd
    • SLC6でafsを使うには/etc/krb5.confを他のAFSが動いているところからコピーする。
    • インストール後、
      $ scripts/cvms-install
      で/cvmfs を見えるようにする。
      • 最近の設定では、/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にする場合
      • lxatuthm1で、rootになってから各nodeにlogin
      • ~condor/etc/local_config/ の下に適当な設定ファイルのsymlinkを${HOSTNAME}.localの名で作る。その後、
        ~condor/etc/condor.addservice
    • 作業用マシンの場合
      • atljphysではlxatut01以外の他のマシンでのcrontab -lの内容をcrontab -eで追加
        ~rysawada/workspace/aims2/scripts/setquota(_cloud).sh
      • cloud machineの場合はsetquota_cloud.shを使用
    • ディスクマシンの場合
      • /etc/motdを他のマシンと同様に変更。
    • 必要に応じて/root/etc/nodes.list, /root/etc/desktop/nodes.list, /root/etc/onlydata/nodes.list等に追加。sync等が可能になるように一度lxatuthm1のrootから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-vm --foreman-hostgroup atljcluster --slc6 --landb-responsible atlas-eos-access-group-tokyo-admins--nova-flavor m2.large --nova-sshkey atutcloudadmin hostname.cern.ch
    • インスタンスが出来てから
    • openstack volume create --size 40 volumename --type standard
    • openstack server add volume hostname volumename
    • root@lxatuthm1から新しいホストにログインする。古い.ssh/know_hostの行は消す必要がある。
    • 普通にログインできるようになるまでにはpuppetが成功する必要がある。暫く待っても普通にログインできない場合は-i ~/.ssh/atutcloudadminを使う。
    • root@lxatuthm1で ~/etc/Cloud/sync/に行きnodes.listを変更してからsync-nodes
    • rootで新しいホストにログインし、/mntが正しくxfsでマウントされていたら、~rysawada/workspace/aims2/scripts/setquota_cloud.sh
    • condorのバッチノードにする場合は~condor/etc/local_config/ の下に適当な設定ファイルのsymlinkを${HOSTNAME}.localの名で作る。その後 ~condor/etc/condor.addservice

  • CERN cloudの消去
    • aiadmでai-kill-vm 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アドレスが必要だがフロントパネルだと全部の桁数表示されないので、まずはRS-232Cで接続しないといけない。 lxatutd151からだと成功した。baud rateは9600だとOKだった。puttyで接続できる。 接続直後は真っ暗だがESCを押したり、矢印を押したりすると何か現れて最終的には操作できるようになる。 Webログインとパネルのパスワードが同じで、入力が面倒なので、東京のコピー機と同じものを設定してある。

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

  • lxplusではkerasというDNN/CNN用のpython lib が source /cvmfs/sft.cern.ch/lcg/views/LCG_88/x86_64-slc6-gcc49-opt/setup.sh すると使える
  • 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周りで怒られたらドライバーかCUDAが見えていないので澤田に教えてください

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に送られる。

Various information

  • diskの使用者: /home/atljphys/public/diskinfo.txt
  • PCの使用者: lxatuthm1の/root/PClist.txt
Topic attachments
I Attachment History Action Size Date Who Comment
JPEGjpeg CERN_Cloud_memo_20190805.jpeg r1 manage 93.7 K 2019-08-05 - 18:50 YasuyukiOkumura CERN cloud を操作した時のメモ
JPEGjpg CERN_Cloud_memo_20190805.jpg r1 manage 98.7 K 2019-08-05 - 18:55 YasuyukiOkumura CERN cloud memo (Okumura)
Edit | Attach | Watch | Print version | History: r96 < r95 < r94 < r93 < r92 | Backlinks | Raw View | WYSIWYG | More topic actions
Topic revision: r96 - 2019-11-11 - RyuSawada
 
    • Cern Search Icon Cern Search
    • TWiki Search Icon TWiki Search
    • Google Search Icon Google Search

    Main All webs login

This site is powered by the TWiki collaboration platform Powered by PerlCopyright & 2008-2019 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback