【2014年6月】

「真珠湾、遙かなり―零戦隊血風録」を読んだ。

戦闘機、艦攻、艦爆の各パイロットの目線で、発艦から帰投までが描かれている。
米軍の戦闘機パイロット、外交折衝のシーンも同時進行で描かれている。
パイロットたちの正直な気持ちが読み取れて興味深い。

ただ、どこまでがノンフィクションなのか不明なのと、物語が頻繁にあっちこっちに飛ぶので、ちょっと頭の切り替えがきかないときがあるのが少し残念か。

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)
ESXi監視で大ハマリ (6) - DELLツールで監視(B)
ESXi監視で大ハマリ (7) - あとがき(A)

ところで、DELLの OpenManage Server Administrator と OpenManage Essentials、これらのソフトウェアの挙動が、どうにも気に入らない。

(1).SNMPで情報が取得できない？

DELL曰く…

という事なのだが、ちょっと待てよ、OpenManage Server Administrator では、ハードウェアの状態も、物理ドライブの状態も取得できている。
OpenManage Server Administrator では、IPMI など使っていないのだから、SNMPで ESXi と通信をして、情報を取得しているのと思われる。つまり、SNMPによる通信だけで、ハードウェアの状態は取得できるはずだ。

OpenManage Server Administrator で情報が取得できているのだから、OpenManage Essentials で取得できないわけがない。
単に OpenManage Essentials に、SNMPで ESXi と通信するための機能が備わっていないだけだと考えられる。

ちなみに、OpenManage Essentials の前バージョンである、OpenManage IT Assistant も、同様に ESXi からハードウェアの情報を取ることができない。

(2).ESXi 側から状態をプッシュできない（＝OpenManage Essentials 側からポーリングしなければならない）

OpenManage Essentials は、ESXi 側からの通信を受けて、エラーを検出するように構成する事はできなかった。
OpenManage Essentials から、定期的にポーリングを実行して、ESXi 側に問い合わせをしなければならない。
つまり、エラーを検出しても、リアルタイムに監視サーバに報告する事はできず、OpenManage Essentials 側がポーリングするまでエラーは検出されない。

ポーリングの間隔を短い時間に設定すればリアルタイムに近くなっていくが、それでも設定できる最短時間は1分で、ポーリングの間隔を短くすれば、当然、サーバにもネットワークにも負荷がかかる。
監視対象サーバから監視サーバにプッシュする形で、エラーをリアルタイムに報告できるべきだと思うが、残念ながら、そのように構成する事はできなかった。

結局、OpenManage Essentials でできたことは…

・OpenManage Server Administrator に、
・自動ポーリング機能と
・メール送信機能が付いた。

という事になる。
苦労して監視ができるようにした割に、得られた成果は少ない。
まぁ、監視はできているのでヨシとは言えるが、積み木を積むのに、わざわざクレーン車を買ってきたような感じだ。
こんなメンドクサイ設定をしなければ監視できないのだろうか？

昨今、ESXi を導入するサーバなど、そこら中でやっているのだから、「ESXi を監視する」という事は、普通に行われるはずだ。
それならば、もうちょっと簡単に監視が実現できるようにソフトウェアを改良してほしいものだ。
正直、この程度の監視は、「IPアドレス指定」＋「ボタン一発」の操作くらいで、基本設定まで完了してほしいと思う。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)
ESXi監視で大ハマリ (6) - DELLツールで監視(B)

最終的にはRAIDの監視ができるようにはなったのだが、洗練された監視状態とは言えない。
元々は、以下のように構成する事を狙っていた。

監視対象サーバが追加されたら、Power Edge T310 (A) 上の監視サーバの監視対象を増やして対応していくつもりだった。

しかし、ESXi を監視するためには、BMC経由にする必要があり、BMC経由にすると、今度は自分自身を監視できないため、結局、以下のように相互監視をする形にせざるを得なかった。

この場合でも、監視対象サーバが追加されたら、Power Edge T310 (A) 上の監視サーバの監視対象を増やして対応していく事になるが、Power Edge T310 (B) 上の監視サーバは、Power Edge T310 (A) を監視するためだけに稼働させることになるため、あまりきれいな構成とは言えない。

ただ…今思うと、結局のところ、「ESXi上で監視を行う」事がひじょうに面倒なだったというだけであるので、たとえば、ストレージ・サーバを1台追加して、ESXi からはNFSマウントするようにすれば、もっと簡単に構成できたかもしれない。
この場合、2台の Power Edge T310 は、ハードディスクも何も装備せず、USBメモリから起動して動くだけになる。

ストレージ・サーバを Windows や CentOS で稼働させれば、玄人志向などの安価なRAIDカードでも普通に認識して動作するだろうし、今回苦労した、物理ドライブの状態の監視も簡単にできるであろう。

もちろん、RAIDカードの信頼性や、NFSマウントでアクセスする事による速度低下などもあるだろうから、必ずしも、この構成がいいとは言えないとは思うが、少なくとも、監視そのものはひじょうに楽になる。

苦労したけど、勉強になった。
今後、この勉強できた事が生かせる時が来るといいな。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)
ESXi監視で大ハマリ (5) - DELLツールで監視(A)

OpenManage Essentials が反応しない理由がまったくわからない。

仕方がないので、DELLのサポートに電話をし、やろうとしている事を説明、解決策はないか聞いてみた。
回答は…。

何ですとぉ？
SNMP経由では監視できない？
回答に書かれていた詳細な手順に従って、BIOSの設定を変更し、ESXiを再起動。

OpenManage Essentials で、設定したBMCのIPアドレスを指定、IPMIでの検出を有効にし、検出を実行してみる。

が…まったく検出されない。
SNMPでの検出では、「？」が付きながらも「VMWare ESX Servers」として検出されたが、今度は検出すらされない。
指定したIPアドレスは生きているのだろうか？

~ # ping 192.168.XXX.XXX
PING 192.168.XXX.XXX (192.168.XXX.XXX): 56 data bytes

--- 192.168.XXX.XXX ping statistics ---
3 packets transmitted, 0 packets received, 100% packet loss
~ #

へ？
pingが通らない？
サーバを再起動して、BIOSの画面を出し、BMCに設定したIPアドレスを確認してみる。
間違いはない。どういう事だ？

もしかして、と思い、もう1台の T310 から ping を打ってみる。

~ # ping 192.168.XXX.XXX
PING 192.168.224.111 (192.168.XXX.XXX): 56 data bytes
64 bytes from 192.168.XXX.XXX: icmp_seq=0 ttl=64 time=0.543 ms
64 bytes from 192.168.XXX.XXX: icmp_seq=1 ttl=64 time=0.726 ms
64 bytes from 192.168.XXX.XXX: icmp_seq=2 ttl=64 time=0.667 ms

--- 192.168.XXX.XXX ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.543/0.645/0.726 ms
~ #

通った。
えー、自分自身のBMCにアクセスできない状態って事？

ハードウェアの問題なのか、ESXi のネットワークの問題なのかわからないが、ともかくも、BMC経由では「自分自身を監視できない」事がわかった。
なんだかな。

仕方がないので、もう1台の T310 にインストールしてある ESXi 上に、Windows Server 2008 R2 をインストールして監視サーバとし、OpenManage Server Administrator と OpenManage Essentials をインストール。
検出を実行してみる。

検出できた。
ただし、「VMWare ESX Servers」としてではなく、RAC（Remote Access Controller）として検出された。
どのような検出であれ、エラーを監視できるのであれば問題は無いので、気にしない事にする。

ハードウェアの情報も取得できた。

エラーは検出できるだろうか。
筐体の蓋を開けてみる。

検出できた。
アラートメールも着信した。

BMC経由では、自分自身の監視ができないようなので、2台のサーバで相互監視の形を取らざるを得ないが、監視はできる状態になった。
やれやれ。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)
ESXi監視で大ハマリ (4) - コマンドで監視(B)

DELLから提供されている、OpenManage Server Administrator および OpenManage Essentials を使用して、ESXi のアラート監視をトライしてみる事にする。

まず、ESXiには、OpenManage Server Administrator 用のVIBをインストールする。

インストールの前に、ESXi をメンテナンス・モードに切り替える必要があり、インストール後は ESXi の再起動が必要になる。

~ # esxcli software vib install -d /(path)/OM-SrvAdmin-Dell-Web-7.4.0-876.VIB-ESX55i_A00.zip

続いて、ESXi 上に Windows Server 2008 R2 をインストールし、これを監視サーバとする。

DELLのサイトから、OpenManage Server Administrator を含むISOイメージをダウンロードし、監視サーバにインストール。

問題なくインストール完了。
物理ドライブの状態、シリアルナンバーなども表示された。

OpenManage Server Administrator は、サーバの状態を表示する事はできるが、エラーを検出したらメールを発信するなどの監視機能は無い。
そこで、監視機能を持つ OpenManage Essentials をインストールする。
DELLのサイトから OpenManage Essentials をダウンロードし、監視サーバにインストール。

チュートリアルに従ってSNMPなどを初期設定。
サーバの検出を実行してみる。
が…「VMWare ESX Servers」として認識はされたものの、「？」が付いている。

ハードウェアの情報も、ほとんど取得できていない。

これでエラーを検出できる状態なのか？

OpenManage Essentials で、「管理」→「アラート」で、アラート監視を追加、電子メールを送信するように設定する。

ESXi 上から、SNMPにテスト送信を実行してみる。

~ # esxcli system snmp test

OpenManage Essentials は、まったく反応しない。
もちろん、メールも飛んでこない。

OpenManage Server Administrator で、「温度」の警告のしきい値を変更し、強制的に警告が出る状態にしてみる。

設定を変更した OpenManage Server Administrator だけでなく、vSphere Client でもエラーが検出された。
OpenManage Essentials でも検出するはずだ。

しかし、OpenManage Essentials は、まったく反応しない。

サーバの筐体の蓋を開けてみる。
OpenManage Server Administrator、vSphere Client では、サーバの筐体の蓋が開いたことが検出された。

しかし、OpenManage Essentials は、まったく反応しない。

監視サーバに、SNMPマネージャーをインストールして、SNMPの受信状態を確認してみると、アクションを起こしたタイミングで、何かを受信しているのを確認できる。

(A)は、esxcliコマンドでのテスト送信したタイミング。
(B)は、温度のしきい値を変更して、エラー状態にしたタイミング。
(C)は、温度のしきい値を元に戻し、通常の状態に回復したタイミング。
(D)は、筐体の蓋を開けたタイミング。
(E)は、筐体の蓋を閉じたタイミング。

SMNPは間違いなく何かを受信しているが、OpenManage Essentials は、まったく動作しない。
何だこれ？

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視
ESXi監視で大ハマリ (3) - コマンドで監視(A)

ESXi上で動作するコマンドで物理ドライブの状態が取得できないなら、RAIDカードのメーカが出しているサポート・ソフトウェアなどは無いだろうか。
DELLのサイトで探してみたが、それらしいツールは見当たらない。

DELL PERC 6/i は、LSI の OEM だったはず。
そうであれば、MegaRAID のコマンドを使って、S.M.A.R.T. の状態を取得できないだろうか。
LSIのサイトから MegaCli のコマンドをダウンロードして試してみる。

Find Support by Product Results - MegaCli

このブログを書いている時点では、「MegaCLI 5.5 P2」が最新版で、「VMWareMN」に対応となっているが、実際にダウンロードしてみると、このパッケージには「VMWareMN」用のプログラムは含まれていないようだ。

仕方がないので、バージョンを遡ってダウンロードし、「VMWareMN」用のプログラムを探す。
「Archived」をクリックし、上から順にダウンロードして確認していく。

幸い、一番上の「Jun 18, 2013」公開のバージョンで見つかった。
さっそくESXi上に転送して実行してみる。
が、エラー。

~ # ./MegaCli -PDList -aALL

./libstorelib.so: cannot open shared object file: No such file or directory

Exit Code: 0x01
~ #

「libstorelib.soが無い」と言っている。
更にバージョンを遡ってみても、この共有ライブラリは同梱されていない。
どうやら、この共有ライブラリは、元々は ESXi に標準でインストールされていたものであるが、ESXi 5.5 などでは標準でインストールされていないようだ。

旧バージョンの ESXi をインストールしてみれば、この共有ライブラリを取り出せると思うのだが…ちょっとめんどくさい。
IBM、日立など、ESXi 対応のサーバを販売しているサイトを探してみたところ、この共有ライブラリを同梱しているパッケージがあったので、ダウンロードして解凍し、この共有ライブラリだけを抽出させてもらう事にした。

S.M.A.R.T. の状態を取得できるか試してみる。

~ # ./MegaCli -PDList -aALL | grep "S.M.A.R.T"
Drive has flagged a S.M.A.R.T alert : No
Drive has flagged a S.M.A.R.T alert : No
~ #

取得できた。

故障した物理ドライブを特定できるか試してみる。

~ # ./MegaCli -PDList -aALL | grep "Inquiry Data:"
Inquiry Data:      WD-WMC4M2030827WDC WD20EZRX-00D8PB0                    80.00A80
Inquiry Data:      WD-WMC4M2030891WDC WD20EZRX-00D8PB0                    80.00A80
~ #

特定できた。
物理ドライブのシリアルナンバーが表示された。

このコマンドを cron などで定期的に実行するようにすれば、物理ドライブの故障を検出する事ができそうだ。
では、検出したエラーを、どうやって通知するかだが…。

ESXiには、標準で python がインストールされているので、やろうと思えばできそうな気がするが、すべてのモジュールがインストールされているわけでもないらしく、メールを送信するには、少々気合が要りそうだ。

物理ドライブの状況を取得する事はできたのだが…もう少し簡単に取得して、メールなどで通知できないものだろうか。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築
ESXi監視で大ハマリ (2) - 警告ランプで監視

ESXi上で動作するコマンドで、物理ドライブの状態を確認できないだろうか。

ESXi 5.5 では、esxcli コマンドでできる事が充実してきている。

VMware vSphere 5.5 ドキュメント センター ≫ vSphere Command-Line Interface Reference

ストレージ関連のコマンドとして「esxcli strage」がある。

VMware vSphere 5.5 ドキュメント センター ≫ esxcli strage

とりあえず、ドライブの一覧を表示させてみる。

~ # esxcli storage core device list | grep "Display Name: Local" | sort
   Display Name: Local ATA Disk (t10.ATA_____ST340014AS______________________________3JX9AZPZ____________)
   Display Name: Local ATA Disk (t10.ATA_____ST500NM0011_________________________________________Z1M0TLLX)
   Display Name: Local DELL Disk (naa.690b11c02520ba001af38d3c0962e329)
   Display Name: Local PLDS CD-ROM (mpx.vmhba1:C0:T0:L0)
   Display Name: Local USB Direct-Access (mpx.vmhba32:C0:T0:L0)
~ #

5つのドライブが一覧された。
上から、非RAIDのATAドライブ×2台、RAIDの仮想ドライブ×1台、光学ドライブ×1台、USBドライブ（ESXiがインストールされている起動ドライブ）×1台。

「esxcli strage」には、S.M.A.R.T. の状態を表示させるコマンドがあるので、状態を表示させてみる。
まず、非RAIDの物理ドライブの状態を表示させてみる。

~ # esxcli storage core device smart get -d t10.ATA_____ST340014AS______________________________3JX9AZPZ____________
Parameter                     Value  Threshold  Worst
----------------------------  -----  ---------  -----
Health Status                 OK     N/A        N/A
Media Wearout Indicator       N/A    N/A        N/A
Write Error Count             N/A    N/A        N/A
Read Error Count              56     6          48
Power-on Hours                50     0          50
Power Cycle Count             100    20         100
Reallocated Sector Count      100    36         100
Raw Read Error Rate           56     6          48
Drive Temperature             41     0          51
Driver Rated Max Temperature  N/A    N/A        N/A
Write Sectors TOT Count       200    0          200
Read Sectors TOT Count        100    0          253
Initial Bad Block Count       N/A    N/A        N/A
~ #

S.M.A.R.T.の状態が取れた。
続いて、RAIDの仮想ドライブの状態を表示させてみる。

~ # esxcli storage core device smart get -d naa.690b11c02520ba001af38d3c0962e329
Parameter                     Value  Threshold  Worst
----------------------------  -----  ---------  -----
Health Status                 N/A    N/A        N/A
Media Wearout Indicator       N/A    N/A        N/A
Write Error Count             N/A    N/A        N/A
Read Error Count              N/A    N/A        N/A
Power-on Hours                N/A    N/A        N/A
Power Cycle Count             N/A    N/A        N/A
Reallocated Sector Count      N/A    N/A        N/A
Raw Read Error Rate           N/A    N/A        N/A
Drive Temperature             N/A    N/A        N/A
Driver Rated Max Temperature  N/A    N/A        N/A
Write Sectors TOT Count       N/A    N/A        N/A
Read Sectors TOT Count        N/A    N/A        N/A
Initial Bad Block Count       N/A    N/A        N/A
~ #

くそー、全部「N/A」だ。
仮想ドライブ配下に接続されている物理ドライブの S.M.A.R.T. の情報を一覧してくれることを期待したのだが… esxcli コマンドでは、RAID配下の物理ドライブの情報は取れないようだ。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート
ESXi監視で大ハマリ (1) - RAIDを構築

さて、どうやってRAIDの状態を監視するか。

まず、ハードウェアの各種警告ランプで監視する事を考えてみる。
DELL PowerEdge T310 は、フロントパネルに状態インジケーターが装備されている。

正常な状態では青色で点灯している。

 何らかのエラーを検出すると、オレンジに変わる。

何らかのエラーが発生した事はわかるし、簡単なエラーの内容はわかる。
しかし、故障が発生したことがわかるのみで、どの物理ドライブが故障したのかといった、エラーの詳細はわからない。

フロントベゼルを開ければ、故障したドライブにはランプが点いているであろうから、故障したドライブの特定はできる。

しかし、1台の T310 は、上の写真のような、ブラケットで挿入しているが、もう1台の T310 は、普通に筐体内に固定しているだけなので、ランプでは確認できない。

また、できる事なら、エラーを検出したら、できるだけ早くそれを知りたいので、やはり、ランプの点灯状態で確認するのではなく、メールなどで通知できるようにしたい。

うまい方法はないだろうか。

一連記事：

このエピソードの続き。

ESXiをUSBメモリからブート

ESXi上でRAIDを構成したのだが、その監視で大ハマリしたのでメモ。

ESXiはRAIDカードの選定がシビアだ。

ESX/ESXi をインストールするための最小システム要件 (2052813)

この資料によると、以下のカードしか認識しない。

DELL PERC（Adaptec RAID または LSI MegaRAID）
HP Smart Array RAID
IBM ServeRAID

たとえば、玄人志向などの安価なRAIDカードは認識しない。
しかし、DELL PERC 6/i をまともに購入すると、4万円強の出費が必要になる。

Dell - PERC 6/i 内臓 SAS RAID コントローラカード

ビンボー人 ずんべ には、ちょっと買えない。
この金額でデータを保護できるなら安いものだとは言えなくはないが、やはり、何とか安く購入したい。
そんな時は、ヤフオク頼みだ。
ヤフオクで検索してみると、取り外し品などがけっこう出品されている。

ヤフオク! - 「DELL PERC 6/i」の検索結果

新品の1割くらいで買える。
と、いう事で、RAIDカードはヤフオクで調達。

さっそくRAIDカードを取り付け、RAIDを構築。
ESXiを起動すると、すんなりRAID上の仮想ドライブを認識した。

RAID上の仮想ドライブにゲストOSを作成してインストールしてみるが、特に問題はない。

ここまでは順調。

しかし、ここで問題が発生した。
どうやってRAIDの状態を監視するのだろう？

一連記事：

馬ノ背山（うまのせやま、岐阜県、標高767m）、八百山（やおやま、岐阜県、標高800m）、屏風山（びょうぶやま、岐阜県、標高794m）、北屏風山（きたびょうぶやま、岐阜県、標高不明）に登り、小滝（こたき）、寿老滝（じゅろうたき）を見てきた。

より大きな地図で 2014/06/16 馬ノ背山、八百山、屏風山、北屏風山 を表示

スタート！
百曲り登山口。

馬の背山。

八百山。

屏風山。

北屏風山。

屏風山大栂の木。

胸突八丁登山口へ下山。

林道を歩いて、小滝。

更に林道を歩いて、寿老滝。

更に林道を歩いて、湿地経由登山口。

黒の田東湿地。

ぐるっと回って、出発地点の百曲り登山口まで戻ってきた。
今日もゴミを回収。

気持ちよく歩いて回ることができた。
時間の都合で行けなかった山もあるので、また登りに来たい。

まとめページ：