社内の検証用サーバーのうち、なぜか私がほぼ独占的に使用しているHP ProLiant DL320 G6サーバーで、再起動すると数回に一回ぐらいの確率でBIOS設定が初期化されてしまうと言う問題が起きていました。

　再設定すると数回は大丈夫なのですが、そのうちまた初期化されてしまいます。しかも、設定と同時に同時に製品番号とシリアルナンバーの情報も消えてしまうため、iLOの管理画面で見るとUUIDがゼロで埋め尽くされていて、やや驚きます。設定がリセットされる以外は使用上の問題はありませんが、気になるのでその都度BIOSで番号を手入力したり、設定を復元してやっていました。

　BIOS設定が飛ぶ、ということは、考えられるのはシステムボードの電池が切れてしまったか、システムボード障害の二つの可能性を考えて、前者は試したのですが改善されず、そろそろサポートに連絡してシステムボード交換にでもなるかしら、と思っていたのですが、きのうこんなアドバイザリを見つけました。

　Advisory: HP ProLiant Servers – FIRMWARE UPDATE RECOMMENDED for Smart Array P212/P410/P410i/P411/P711m/P712m/P812 Controllers to Prevent Server Serial Number, Product ID, and Other Configuration Settings From Being Unexpectedly Cleared or Reset to Default
　http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=c03083515

　「ファームウェアアップデート: SmartArray P212/410… シリーズがサーバーのシリアル番号・製品番号・その他の設定を誤ってクリア・デフォルトリセットしてしまう問題を解消する」……つまりSmart Arrayのファームウェア不具合ということのようです。なんてこったい、これは盲点。これによって、ファームウェアのバージョンが5.14もしくは5.36(こちらはP711mとP712mのみ)になっています。また、これらのバージョンは今日2011/12/16時点で通常のドライバー検索では出てこないようですのでご注意あれ。

　さて、さっそく今日アップデートを行ってみました。が、これまでランダムで発生していたものなので、すぐに「改善された！」とはいえないですが、少し様子を見て、改善されたようだったら追記でご報告したいと思います。

　ESXi 5.x boot delays when configured for Software iSCSI

　この問題にあわせて、ZIP形式のパッチと、パッチ済のISOイメージ（こちらは有償ライセンスを所持しているユーザーのみ）が配布されています。が、ZIP形式のパッチをあてようとしたところ、私が知っていたvihostupdate.plを使ったアップデートはできなくなっていました。結局、この場は評価利用中だったvCenter ServerとUpdate Managerでアップデートをしました。

　うーん、このままではちょっと悔しいので、あらためてパッチのあて方を勉強することにしました。

パッチのあてかた

　検索すると、最近はesxcliコマンドを使用してアップデートをするようです。やり方を丁寧に紹介しているブログもありますが、自分で試して、他よりちょっと？だけ手順を省ける方法がありましたのでこちらを紹介します。

• パッチのZIPファイルをデータストアにアップロードします。今回はデータストア「datastore1」の一番上のディレクトリに配置している状態を例とします。
• ESXiホストをメンテナンスモードにします。
• vSphere CLIのコマンドを起動して、次のコマンドを実行します(2011/1/26更新: software vib installをsoftware vib updateに変更)。

  >esxcli --server <サーバーのIPアドレス> --username <ユーザー名> software vib update -d [datastore1]ESXi500-201111001.zip

• 完了すると、「Message: The update completed successfully, but the system needs to be reboot ed for the changes to be effective.(アップデートが成功しました。ただし、再起動が必要です)」というメッセージと、パッケージのインストール状況表示されるので、ESXiホストを再起動して、メンテナンスモードを解除してやります。

　ちなみに、よその手順との違いは、ESXiのSSHを有効にせずにvSphereCLIに付属のコマンドを使用している点です。角括弧でデータストアを指定してその後ろにパスをつけると、データストアにあるファイルを使ってくれました。SSHを有効にすると、vCenter Serverに登録している環境では警告として表示されてしまいますから、警告が出ていると気になってしまう方におすすめかもしれません（？）。

メモ

　いま(2011/11/27現在)のところESXi 5.0へのパッチは、ESXi500-201109001とESXi500-201111001の二つがリリースされていますが、最初のBuild 469512からアップデートするときは、ESXi500-201111001を適用するだけで良いようです。これを適用した時に、ESXi500-201109001に含まれていたtools-lightのアップデートもされていました。
　また、ESXi500-201111001のインストールが済んでいる状態でESXi500-201109001をインストールすると、esx-baseのバージョンが戻ります（した）。バージョンダウンのチェックはしていないらしいのでご注意アレ。(2012/1/26追記)esxcliを使用してvibを適用する際には、installコマンド以外にもupdateコマンドが含まれていました。コメントにてご指摘いただきましてありがとうございました。

(2012/1/26追記)参照: http://pubs.vmware.com/vsphere-50/topic/com.vmware.vcli.ref.doc_50/esxcli_software.html

(大まかに)vSphere Web Clientが使えるようになるまでの流れ

次のような手順で、vSphere Web Clientが使用可能となります。

• vCenter Serverをインストール
• vSphere Clientをインストール
• vSphere Clientにログインして、データセンタとホストの追加を行う
• vSphere Web Clientをインストール
• vSphere Admininstration Applicationで、vCenter Serverの情報を登録(後述)
• vSphere Web Clientにアクセス(後述)

　途中、vSphere Clientにログインしてデータセンタとホストを追加していますが、現状のvSphere Web Clientではこれらの追加はできないようでした。

vSphere Admininstration Applicationのようす

　インストール直後に自動で表示されるか、スタートメニューの中にリンクか有るのでそちらからアクセスします。

　登録画面はこんな感じで、IPアドレス・ユーザー名・パスワードを指定する程度です。

vSphere Web Clientのようす

　vSphere Web Clientもスタートメニューの中にリンクがあるのでそちらからアクセスします。なお、Web Clientを利用するにはFlashが必要となります。

　ログイン後は次のような感じです。仮想マシンのサマリを表示しているところ。

　プラグインをインストールすると、VMのコンソール画面を開く事も可能です。対応ブラウザはInternetExplorerもしくはFirefox(Windowsのみ)に対応しているようです。

　仮想マシンの追加は可能のようで、vSphere Clientで操作するのと同じように（もしくは従来より若干快適に）仮想マシンを作成できました。若干、というのは、仮想マシン作成ウィザード内で仮想CDドライブにISOをマウントできる点が個人的に便利だと感じました。

　パフォーマンスの確認ももちろん可能です。

　そしてなんと、ライブマイグレーションもできそうな雰囲気です。実際には試していませんが、複数ホストを用意してvMotionを有効にすれば、Webから簡単にライブマイグレーションを実行することができそうです。

まとめ

　Macなど別のOSでWebアクセスして仮想マシンを管理することが可能になったため、普段の業務でMacBookを使用している(VMwareを扱い時にはWindowsのVMをいちいち立ち上げていた)弊社としては非常に便利なツールが登場したなあ、と感じました。

　Windowsのみ対応らしいリモートコンソールについては、SSHやWindowsのリモートデスクトップでどうにでもできますので、なくてもそれほど困らないかと思っています。

　さて、ESXi 5では「ホストキャッシュ」と言う機能が追加されて、SSDをVMのメモリのスワップ置き場にすることで、メモリスワップ時の速度低下を低減させる、と言うもののようです。まずはホストキャッシュの追加までできましたので、こちらの手順をご紹介します。

　検証に使用しているサーバーはHP ProLiant DL360 G6です。余談ですが、例によって数週間前にヤフオクで入手された出物です。ストレージ構成は次の通り。おなじみのSmartArray P410iで構成されています。

• 論理ボリューム1: 10kRPM 146GB SASディスク 1本
• 論理ボリューム2: Samsung 64GB MLC SSD (MMCRE64G5MXP-0VB) 1本

　vSphere Clientの「構成タブ」-「ソフトウェア」-「ホスト キャッシュの構成」を選択します。

　「ストレージの追加」をクリックして、ストレージを追加します。追加ウィザードは、通常のデータストアの追加方法と全く同じですので、手順は割愛します。

　……手順を割愛したものの、実はここでSSDが非SSDとして認識されていました。よって上記リストには表示されず、データストアでのみ表示されるようになっていました。データストアのリストを見ると、次のように表示されています。

　HP Smart Array では論理ボリュームを作る時にSATA SSDとして認識されていますが、ESXi側では単純にHP Serial Attached SCSI Diskとしてしか見えないようです。

　マニュアルの「vSphere ストレージ ガイド (vSphere Storage)」を参照すると「15. Solid State Disks Enablement」の章の144ページに、自動で認識されなかった場合に手動でドライブのタイプをSSDにする手順が記載されていましたので、こちらを試してみます。

• ESXiのコマンドラインにアクセスする(SSHやvSphere CLIなど)。
• 「esxcli storage nmp device list」を実行する。すると、次のように、ストレージの一覧が表示されるので、SSDのデバイス名(naaで始まる文字列)と、Storage Array Typeを確認する。

  ~ # esxcli storage nmp device list
  naa.600508b1001c97ac14eb5b233da87a59
     Device Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c97ac14eb5b233da87a59)
     Storage Array Type: VMW_SATP_LOCAL
     Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
     Path Selection Policy: VMW_PSP_FIXED
     Path Selection Policy Device Config: {preferred=vmhba0:C0:T0:L1;current=vmhba0:C0:T0:L1}
     Path Selection Policy Device Custom Config:
     Working Paths: vmhba0:C0:T0:L1
  
  naa.600508b1001c2a9d6a8d81dc7a150ec9
     Device Display Name: HP Serial Attached SCSI Disk (naa.600508b1001c2a9d6a8d81dc7a150ec9)
     Storage Array Type: VMW_SATP_LOCAL
     Storage Array Type Device Config: SATP VMW_SATP_LOCAL does not support device configuration.
     Path Selection Policy: VMW_PSP_FIXED
     Path Selection Policy Device Config: {preferred=vmhba0:C0:T0:L2;current=vmhba0:C0:T0:L2}
     Path Selection Policy Device Custom Config:
     Working Paths: vmhba0:C0:T0:L2

• デバイスにルールを追加して、SSDとして認識するようにする。

  ~ # esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device naa.600508b1001c2a9d6a8d81dc7a150ec9 --option=enable_ssd
  ※ esxcli storage nmp satp rule add -s [Storage Array Type] --device [デバイス名] --option=enable_ssd

• unclaimを実行(どう訳して良いか分からないのですが、おそらく認識を解除)する。

  ~ # esxcli storage core claiming unclaim --type device --device naa.600508b1001c2a9d6a8d81dc7a150ec9
  ※ esxcli storage core claiming unclaim --type device --device [デバイス名]

• 次のコマンドを実行して再認識させる。

  ~ # esxcli storage core claimrule load
  ~ # esxcli storage core claimrule run

　そうして、データストアを見てみると、SSDが無効のような状態になっていた(うろおぼえですみません……)ため、一度「更新」を実行。すると、SSDとして認識されるようになりました。

　ホストキャッシュのリストにも無事表示されています。プロパティを表示して、SSDをホストキャッシュに使用するための設定を行います。

　「ホスト キャッシュに領域を割り当て」にチェックをして、割り当てる容量を設定します。今回は全部の容量を使用することにしました。

　設定後の一覧は次の通りです。「ホスト キャッシュ 領域」が0から58GBに変化しています。

まとめ

　RAIDカードなどで論理ボリュームとして作成されたSSDドライブをホストキャッシュとして追加するには、ちょっと一手間必要なようでしたが、とりあえず追加することができました。ちなみに、手動でSSDとして認識させる設定を削除する手順も、同じマニュアルに記載されていますので、削除したいという場合にはそちらを参照して下さい。

　次は、実際にスワップした時にどうなるか試してみたいと思います。

スペック

移行元のML350 G5は次のようなスペックでした。

• CPU: Dual-Core Intel Xeon 5120 @1.86GHz
• Memory: PC2-5300 FB-DIMM 1GB * 8 == 8GB
• HDD: 250GB*2(RAID1) + 2TB*2(RAID1)
• 電源: 850W電源×2系統
• 他: SCSIカード(PCI-X), LTO3ドライブ

移行先のML350 G6のスペックは次の通りです。HDDとLTO3ドライブは移行元からそのまま移植しました。
HDDはHPのRAIDコントローラー「SmartArray」で組まれた状態ですが、SmartArray P400搭載のサーバーからSmartArray P410搭載のサーバーに差し替えても認識してくれました。ただし、100%認識してくれるとは限らないので、必ずバックアップしてから差し替えるべきでしょう。今回の移行時にも、必要なデータをバックアップしてからの移行作業となりました。

• CPU: Quad-Core Intel Xeon 5506 @2.13GHz
• Memory: PC3-10600R 4GB * 3 == 12GB
• HDD: 250GB*2(RAID1) + 2TB*2(RAID1)　※移行元から移植
• 電源: 460W電源×1系統
  • ※モノが入手でき次第追加したい
• 他: SCSIカード(PCI-E), LTO3ドライブ　※ドライブは移行元から移植

消費電力

約50%の消費電力ダウンに成功しました。

• ML350 G5: 124W + 152W == 276W
• ML350 G6: 135W

ただし、移行先サーバーでは電源が冗長化されておらず平等ではないので、別のサーバーで使用している同型の電源を挿して、同条件で測定しました。結果は次の通り、3Wほど上昇する程度で大きな変化は見られませんでした。

• ML350 G6(電源冗長化時): 87W + 51W == 138W

温度

もう一つ注目したいのは温度です。温度のデータはHPのサーバー管理機能のiLO2で確認することができます。
まずはML350 G5の温度データです。メモリ付近が82℃と、非常に高い温度です。たしかに、サーバーを停止してメモリを差し替える時なんかは、ヒートスプレッダーが熱々になっていて触れなかったりしましたね……。

• CPU付近: 38℃
• メモリ付近: 82℃
• アンビエント ゾーン: 28℃
• I/O ボード ゾーン: 48℃

そしてML350 G6の温度データはこちら。メモリは43℃と、ちょっと熱めのお風呂程度の温度になりました。G5サーバーではなかったシステムゾーンという項目がやや高めの温度を示していますが、それでも先ほどのメモリ付近82℃に比べると低い方かと思います。

• CPU付近: 40℃
• メモリ付近(最高値): 43℃
• アンビエント ゾーン: 25℃
• I/O ボード ゾーン(最高値): 42℃
• システムゾーン: 69℃

また、サーバー背部の排気も、手を当てた時の感覚的な温度が大きく変わったのがわかりました。夏場は室内が非常に熱かったのですが、サーバーリプレースによって今年は少しぐらい涼しくなるでしょうか……？

まとめ

サーバーリプレースによって、おおよその目論見通り消費電力が半分になり、排気温度も下がったので非常に満足な結果となりました。また、サーバースペックも向上してリソースに余裕ができた(CPUコア数が2コ増えメモリも4GB増に。)ので、さらに仮想マシンを増やせる状態にもなりました。
1つだけ、移行元サーバーのメモリを1GB×8ではなく、4GB×2に変更した時に消費電力と温度がどう変わるか興味がありますので、こちらについてちょっと調べてみたいと思います。

2011/6/22追記: FB-DIMMを1GB×8枚から4GB×2枚にした時の消費電力

実際に計測しましたので追記の形でレポートします。まずは共通のスペックの紹介。

• CPU: Dual-Core Intel Xeon 5120 @1.86GHz
• Memory: PC2-5300 FB-DIMM 合計8GB
• HDD: 3.5inch10kRPM 146GB SAS×2(RAID1)
• 電源: 850W電源×1系統
• 他: SCSIカード(PCI-X)

消費電力の測定は、素のCentOSを起動して、何もしていない状態で行いました。
メモリを1GB×8枚にした時の結果は222Wでした。そして、これを4GB×2枚に換装して測定した結果、173Wと、約50Wほど消費電力が下がりました。このことから、メモリ1枚当たりの容量を大きくして、サーバーに搭載するメモリの合計枚数を減らす事でも若干の節電が可能なようです。

測定環境

測定にはワットチェッカーを使用しました。
OSには測定当時出たばかりだったFedora 15 betaを使用しました(現在はFedora15がリリース済のようです)。
CPU負荷をかける際は「yes > /dev/null」をCPUのコア数の分だけ同時実行しました。

ML350 G4p

スペック

• SingleCore Xeon 3.00GHz (VT非対応)
• メモリ3GB
• 3.5” 36GB SCSI 10kRPM * 2
• SmartArray 641/642 メモリ無し

測定結果

• 待機電力: 約20W
• 起動して何もしていない状態: 約150W
• CPUに負荷をかけた状態: 約200W

ML350 G5

スペック

• DualCore Xeon 5130 2GHz (VT対応)
• メモリ4GB(1GB*4)
• 2.5” 36GB SCSI 10kRPM * 2
• SmartArray E200 メモリあり

測定結果

• 待機電力: 約20W
• 起動して何もしていない状態: 約190W
• CPUに負荷をかけた状態: 約210W

ML350 G6

• QuadCore Xeon E5620 2.4GHz (VT対応)
• メモリ6GB(2GB*3)
• 2.5” 36GB SCSI 10kRPM * 2
• SmartArray P410 メモリあり

測定結果

• 待機電力: 約13W
• 起動して何もしていない状態: 約75W
• CPUに負荷をかけた状態: 約150W

グラフと一口メモ

G5サーバーではOS起動後何もしていない状態でも200W弱の電力を消費するようでした。G4pサーバーはディスクの大きさ・規格が違うものの、低負荷時で150WとG5サーバーよりも消費電力が小さい点はやや意外でした。
G6サーバー(Xeon5500/5600番台世代)は、やはり旧世代に比べて消費電力が低いのがわかります。G6サーバーの高負荷時とG4pサーバーの低負荷時が同じ消費電力となりました。
細かいところだと、待機電力はG4p・G5サーバーが20W、G6が13Wと、7Wほどの差がありました。待機中はiLO2の稼働に電力を消費していると思われますが、ここでも違いがあるようです。
現在、社内サーバーとしてML350 G5に仮想マシンを6〜7台載せて運用していますが、近々G6サーバーにリプレース予定です。リプレース前後の消費電力について後日紹介したいと思います。