192.168.1.1 hpc01 192.168.1.2 hpc02 192.168.1.3 hpc03 このファイルは全ノードで修正しなければならない。全ノードで修正しなければならないファイルは、他にもいくつかある。ということで、新ノードの修正よりも、既存ノードの修正のほうが手間がかかることがわかる。 以上の作業を全ノードでマニュアルでやっていたのでは、とても時間が掛かるし、間違いが発生する可能性も高い。そこで修正を自動で行うscriptを作った。cluster.mapを読み込み、コピー済みのディスクの第3パーティション（/ ディレクトリ以下）を修正する。コピー済みのディスクが、/dev/sddで、ノード名がhpc03だとすると、 ./modify.sh d hpc03 のようにして使う。このscriptをちょっと変更して使えば、全ノードの修正が簡単にできると思う。時間がなかったので完成度は高くないが、急いで使いたい人は以下のscriptを試して欲しい。読んで意味が理解できない場合は、使わないで欲しい。問題が発生しても、筆者と関係者は責任を負えない。自己責任で使って欲しい。サポートは、HPCDIYC会員に対してのみ行う。HPCDIYC会員になるには、こちら。費用は発生しない。 [root@hpc02 ~]# cat modify.sh #!/bin/bash if [ $# != 2 ]; then echo usage: $0 device-char[a-g] node-name exit fi DEVICE=/dev/sd$1 PARTITION=${DEVICE}3 PART_TYPE=`fdisk -l ${DEVICE}|grep ${PARTITION}|awk '{print $6}'` if [ "$PART_TYPE" != "Linux" ]; then echo ${PARTITION} does not exist or is not Linux exit fi
MAP=./cluster.map SOURCE_ROOT="/mnt" mount ${PARTITION} ${SOURCE_ROOT} TARGET_ROOT="root" if [ -d $TARGET_ROOT ]; then # echo $TARGET_ROOT exist, remove it. rm -rf $TARGET_ROOT fi
Device Boot Start End Blocks Id System /dev/sda1 * 1 26 208813+ 83 Linux /dev/sda2 27 2116 16787925 82 Linux swap / Solaris /dev/sda3 2117 121601 959763262+ 83 Linux 以上から、システムディスクは3つのパーティションに分かれていて、最初のパーティションが200MBで/bootにマウント、2番目のパーティションが16GBでswap、残り全部が3番目のパーティションで/にマウントされていることがわかる。続いて、/etc/fstabを調べる。 [root@hpc01 ~]# cat /etc/fstab # # /etc/fstab # Created by anaconda on Mon Feb 13 14:42:29 2012 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # UUID="954729a3-af4b-4260-b1c4-ad4757e157d6" / ext4 defaults 1 1 UUID="14aaea5f-d9eb-40bc-af53-782932474caf" /boot ext4 defaults 1 2 UUID="a1f5fc87-dc60-497f-81d0-2d66e0b19704" swap swap defaults 0 0 以下省略 UUIDを使ってマウントされていることがわかる。UUIDを使う方針だと、コピーされたディスクパーティションのUUIDは異なるので、コピー後blockidコマンドを使って新たなUUIDを調べ、fstabを書き換える必要がある。それだと手間がかかるので、コピー元をUUIDを使わないマウント方法に変更する。このやりかたには異論があるかもしれないが、拡張性や完全性を捨て、簡便性を得るためだ。念のため、オリジナルの/etc/fstabを別の名前にコピーして残しておき、/etc/fstabを次のように変更する。動作中に変更を加えても、問題ない。 [root@hpc01 ~]# cat /etc/fstab # # /etc/fstab # Created by anaconda on Mon Feb 13 14:42:29 2012 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/sda3 / ext4 defaults 1 1 /dev/sda1 /boot ext4 defaults 1 2 /dev/sda2 swap swap defaults 0 0 以下変更なし UUIDを使ったマウントの/etc/fstabはシステムインストール時に自動的に作られる。UUIDを使うメリットを否定するわけではない。システムディスクをコピーして他のノードで使うなどという、イレギュラーな目的にはありがた迷惑になる。同様に注意すべきファイルがある。EthernetのMACアドレスがブート時に書き込まれてしまうファイルがある。このファイルを残したままシステムディスクのコピーを行うと、新しいノードでeth0やeth1が使えなくなってしまう（eth0とeth1がある場合、代わりにeth2とeth3になる）。/etc/udev/rules.d/70-persistent-net.rulesがそのファイルだ。 [root@hpc02 ~]# cat /etc/udev/rules.d/70-persistent-net.rules # This file was automatically generated by the /lib/udev/write_net_rules # program, run by the persistent-net-generator.rules rules file. # # You can modify it, as long as you keep each rule on a single # line, and change only the value of the NAME= key.
# PCI device 0x8086:0x1521 (igb) SUBSYSTEM=="net", ACTION=="add", DRIVERS=="?*", ATTR{address}=="00:25:90:6a:e3:b3", ATTR{type}=="1", KERNEL=="eth*", NAME="eth1" このファイルを消去する。消去しても、次のブートで、新しいeth0とeth1のMACアドレスが書き込まれたものが、自動的に作られるので、心配は無用だ。 [root@hpc02 ~]# rm /etc/udev/rules.d/70-persistent-net.rules コピー元に加える修正はこれで終わりだ。 続いて、コピー先のディスクディバイス名を調べる。 [root@hpc02 ~]# fdisk -l | grep "/Disk /" Disk /dev/sda: 1000.2 GB, 1000204886016 bytes Disk /dev/sdd: 500.1 GB, 500107862016 bytes /dev/sdaはコピー元であることはわかっているので、/dev/sddがコピー先であることがわかる。コピー元と同様な構成のパーティションを作る。コピー元と全く同じにする必要はないが、/bootは（/の内部ではなく）別パーティションにする必要がある（元の構成がそうだから、変更するとgrub.confを変更する必要があるが、ここでは触れない）。fdisk /dev/sddコマンドを使うわけだが、使い方がわからなければコマンドを実行して、mを入力すれば表示されるので、それを見て欲しい。このへんについても解説が必要なら、メールまたはコメントでそう書いて欲しい。この解説では、/dev/sdaと同じ構成にした。/dev/sdaは1TB、/dev/sddは500GBなので、3番目のパーティションの容量だけが違う。パーティションを作ったら、各パーティションをフォーマットする。 [root@hpc02 ~]# mkfs.ext4 /dev/sdd1 [root@hpc02 ~]# mkswap /dev/sdd2 [root@hpc02 ~]# mkfs.ext4 /dev/sdd3 コマンドレスポンス表示は省略、/dev/sdd3では終了まで数分かかる 次に、コピー先がマウントされていないとコピー出来ないので、コピー元と同様な構造にマウントする。マウントするディレクトリはここでは/mntを使う。 [root@hpc02 ~]# mount /dev/sdd3 /mnt [root@hpc02 ~]# mkdir /mnt/boot [root@hpc02 ~]# mount /dev/sdd1 /mnt/boot [root@hpc02 ~]# df Filesystem 1K-blocks Used Available Use% Mounted on /dev/sda3 944702688 4887404 891827124 1% / tmpfs 33040588 260 33040328 1% /dev/shm /dev/sda1 202219 33207 158572 18% /boot /dev/sdd3 463989668 202740 440217568 1% /mnt /dev/sdd1 202219 5902 185877 4% /mnt/boot いよいよファイルのコピーだ。コピー元である、/ 以下のディレクトリを確認する。 [root@hpc02 ~]# cd / [root@hpc02 /]# ls bin cgroup etc lib lost+found misc net proc sbin srv tmp var boot dev home lib64 media mnt opt root selinux sys usr /以下のファイルを/mntにコピーすればいいだけだが、全部をコピーしようとするとうまくいかない。cgroupとprocとsysはシステムがマウントするので除く。homeはnfsマウントされているので除く。mntはコピー先なので除く。ついでにコピーの時間もtimeコマンドで計測する。cpコマンドのオプションには-aを使って、属性（owner、時間等）が変化しないようにする。 [root@hpc02 /]# time cp -a [bdelnort-z]* media misc sbin selinux srv /mnt
real 4m39.852s user 0m1.712s sys 0m20.204s 時間は5分弱と、ddコマンドを使ってディスクを丸ごとコピーするのと比較して、遥かに短時間だ。 コピーしなかったディレクトリは、マウントポイントとして必要なので、mkdirコマンドで作成する。 [root@hpc02 /]# mkdir /mnt/cgroup /mnt/home /mnt/mnt /mnt/sys /mnt/proc 次に、grubを使って、MBRを書き込む。ちょっとわかりにくいので、入力部分は色を変えてある。 [root@hpc02 /]# grub Probing devices to guess BIOS drives. This may take a long time.
GNU GRUB version 0.97 (640K lower / 3072K upper memory)
[ Minimal BASH-like line editing is supported. For the first word, TAB lists possible command completions. Anywhere else TAB lists the possible completions of a device/filename.] grub> device (hd3) /dev/sdd device (hd3) /dev/sdd grub> root (hd3,0) root (hd3,0) Filesystem type is ext2fs, partition type 0x83 grub> setup (hd3) setup (hd3) Checking if "/boot/grub/stage1" exists... no Checking if "/grub/stage1" exists... yes Checking if "/grub/stage2" exists... yes Checking if "/grub/e2fs_stage1_5" exists... yes Running "embed /grub/e2fs_stage1_5 (hd3)"... 27 sectors are embedded. succeeded Running "install /grub/stage1 (hd3) (hd3)1+27 p (hd3,0)/grub/stage2 /grub/grub.conf"... succeeded Done. grub> quit quit これでコピー作業は全て終了だ。コピー先のディスクは、ブート可能で使えるが、コピー元と全く同じ設定である。バックアップとしては役立つが、新たなノードには使えない。この後、新しいノードにするため、hostnameやIPアドレス等、幾つかのファイルを修正しなければならない。それについては次の記事で。
IPMIにPower Cappingというものがあることは以前書いた。最大消費電力を指定すると、それを超えないように、自動調整する機能だ。これを使えば、今年の夏も乗り越えられるだろうか？Power Capping機能を有効にしながら、ベンチマークプログラムを走らせて、その有用性を探ってみた。最大消費電力設定機能の精度を調べるのが目的ではない。そこはそれなりの精度を出せていると想定して、最大電力を制限するとどれだけ性能が落ちるかに焦点を当てたい。 テストに用いたマシンは、HPC Do It Yourself ClubのHPCDIY-2U2CPU128GB9だ。詳しい仕様はこちら。価格表はこちら。CPUは8コアE5-2690＠2.9GHzが2個、メモリは8GBメモリモジュールが16枚で128GB実装のものを使った。 ベンチマークプログラムはこちらの記事に書いた姫野ベンチを使った。いくつかあるバージョンの中から、性能が出て、消費電力も大きい、FortranMPI版を選択した。OSはCentOS6.2を使った。OS標準付属のgfortranでは性能が出ないので、インテル® Parallel Studio XE Linux 版をインストールして使った。MPIが必要だが、Open MPI: Version 1.4.5をダウンロードし、Intel Compiler用にconfigureとmakeを行い、インストールした。 姫野ベンチの実行は、サイズの最も大きいXL(1024x512x512)で16コア並列実行した。配列の分割は、2 8 1が最も高性能だったので、全ててこれを使った。標準の実行時間は1分だが、最大消費電力になるまで時間がかかる(温度が上がりきるまでの時間)ことと、性能計測のばらつきを抑えるため、10分になるようプログラムを書き換えた。 プログラムとは関係ないが、BIOS設定で、Hyper Threadingは、HPCでは性能向上の役に立たないので、Disableにしてある。 コンパイルは、 mpif90 -O3 -ip -xhost himenoBMTxpr.f90 実行は、 mpirun -np 16 --byslot ./a.out <<_EOT_ xl 2 8 1 _EOT_ で行った。 最初は、当然だが、Power Capping無しで、性能(MFLOPS)と最大消費電力を測定した。その結果、実行速度は35568MFLOPSで、最大消費電力は、530Wであることがわかった。実行速度が理論値に比べて極端に低いのは、演算に比較してメモリの読み込みが非常に多いことによる。ここでは、Power Cappingで消費電力を制限すると、どれだけ性能が低下するかという相対値を調べるのが目的なので、絶対性能は気にしない。 次に、530Wの90％である477W、80％の424W、70％の371W、60%の318W、50%の265WにPower Cappingを設定しながら、上記と同様に、実行時間を10分にした姫野ベンチを実行していく。例えば、80%の424WにPower Cappingしたときは、以下のように表示される。例では設定値とぴったり同じだが、Current Power ConsumptionはRefreshボタンを押すたびに変化する。ざっと観察してみた感じでは、平均値が設定値を超えないような制御が行われているように見える。 測定結果は以下のようになった。
消費電力(W)
消費電力(%)
速度(MFLOPS)
速度(%)
530
100
35568
100
477
90
34691
97.5
424
80
34847
98.0
371
70
33865
95.2
318
60
30103
84.6
265
50
20086
56.5
消費電力を制限しても、性能はそれほど落ちていないことがわかる。消費電力を70%に制限しても、十分使える気がする。このベンチマークの場合、メモリアクセスが多いので、性能が落ちなかったのかもしれない。キャッシュが効いて、メモリアクセスが比較的少ないプログラムでは、傾向が変わる可能性がある。しかし、流体計算とか、構造解析とかの実用的プログラムは、メモリアクセスが多いので、その種のプログラムを多用する場合は、Power Cappingは大変有効ではなかろうか。HPC Do It Yourself Clubで販売しているコンピュータには、標準でIPMIが付属しているので、これを御購入頂き、この夏はPower Cappingで乗り切ってはいかがだろうか。
自分自身で、IPMIを使ったことがなかったので、いろいろ試している。やりたかったのは、サーバーの、消費電力情報取得と、遠隔操作だ。いろいろ試行錯誤を重ねて、まだ全部理解したとは言いがたいが、当初の目的は達成できた。このblogでは、試行錯誤も含めて、なるべくリアルタイムで、やってみたことを記録していきたいと思っている。テーマに区切りがついたら、文章を整理して、HPC Do It Yourself Club本館へアップしていくつもりだ。ここを見ている方は、是非本館も見て欲しい。本館は、http://hpcdiyc.hpc.co.jp/へ。
本格的な使い方は、別の記事で書いていくつもりだ。
