【HW】Nutanix CEをHP ML380G7/P410i構成に入れようとしてドハマりした話 
2017, March 11, Saturday, 01:26 - PC, HardWare
投稿者 @xmms
　社内で自宅に構成したNutanix CEのデモを行ったところ､好感触だったのでとりあえずシングルノードで構成して触ってもらうことにしました｡　しかし､あいてるHWがリース切れでもらってきたML380G7だったため､ドハマりする結果になりました…。なんとか原因がわかったので後世のためにバッドノウハウを残します。

余談:導入のいきさつ


　未だに後進的な開発方法を行っていたのでどうにかしたいと思ってはいたのですが､インフラに詳しい人がほぼいないうえ､自分もかかり切りになるわけにはいかない状況で(あと一々VM作成依頼とか受けたくない)､誰でも必要なときにVMを作れるNutanix CEは非常に良いソリューションでした｡

ちなみに過去に開放するサーバのハイパーバイザを検討した結果:
VMware→vCenterServerがないのでクローンとか作るのが厳しいし､そのたびに一から作るのはあまりに効率が悪いので没 (出来なくはないけどSSHでログインしてvmkfstools 使えとかvmxファイルいじれとか非インフラの人にはもっと厳しい)
Linux KVM→同上 (そもそもアプリ開発チームにKVM使ったことある人いないのでは…)
HyperV→まあ妥当かなと思っていたけど社内にライセンスが2008R2Stdしかないのでメモリ32GB制限とRDP接続数制限…

　もちろん､それぞれ良いところはあるのですが､どれもある程度のナレッジが必要なので､あまり深く考えずに使う､というのはちょっと厳しいかなと思いました｡

　なので､ちょっと暇が出来たので｢とりあえず箱は用意したから好きに使っていいよ､ただし冗長性はないからいつ吹っ飛ぶか分からないから､必要なデータはgitデーモンなりSVNなりあとで本番仮想機の上に作るのでそっちに退避してね｣というスタンスでNutanix CEを入れようとしたのですが…

構成


ハードウェア構成
筐体 HP Proliant ML380G7
ストレージコントローラ P410i　(1G-FBWC付き)
ディスク構成 2.5インチSAS 300GB*8
CPU Xeon X5680*2
メモリ 48GB

OSバージョン
ce-2017.02.23-stable.img.gz

　ディスクが8本あるのに全て300GBというNutanix CEのHDD500GB要件を満たさないため､｢じゃあ全てRAID5でくっつけて一つにするか!｣という安易な発想から､サポート外構成のディスク構成をとりました｡ただ､SSDがないため､SSDだけは買ってもらい､HDDを一つ抜いてSSDに交換したので以下のようなディスク構成になりました｡

Array A 300*7 RAID5 1.8TiB
Array B 240GB * 1 RAID0


USBにce-2017.02.23-stableを焼き､起動までは良かったのですが…

ハマり1 ディスクがSSDとして認識されない


　みんなのハマりポイントなので情報は沢山ありました｡SmartArrayはSSDとして認識するのですが､何故かOSにはそれを見せないようです｡
echo 0 > /sys/block/【SSD】/queue/rotational

にてインストーラはごまかせました

ハマり2 CVM再起動後ストレージプールが死ぬ


　CVM起動後､PrismからみるとArray Aも何故かSSDと認識され､おかしいなーと思いCVMを再起動したところ､ストレージプールへ一切の書き込みが出来なくなりました｡
家に帰ってからも手持ちのP410コントローラを使い
Array A 1TB SATA HDD*2 RAID0
Array B 240GB SATA SSD * 1 RAID0

構成で同様のことを行ったのですが､やはり死にました｡
　余談ですがSmartArray P410がX79などのMBで起動しなかったため､メモリとコア数に余裕のある(Xeon L5640/6コア)懐かしのX58を引き出しました…｡



原因


　長時間の手探りの調査のあと､原因はSmartArrayで定義されたディスクが、ディスクのシリアルの代わりにコントローラのシリアルを返すことだと判明しました。

[root@NTNX-71f86937-A ~]# smartctl -a /dev/sda
=== START OF INFORMATION SECTION ===
Vendor: HP
Product: LOGICAL VOLUME
Revision: 6.64
User Capacity: 240,021,504,000 bytes [240 GB]
Logical block size: 512 bytes
Rotation Rate: 15000 rpm
Logical Unit id: 0x600508b1001cb8ae0693a3fdcc1e17ca

Serial number: PACCRID11320BPR　<========これ

Device type: disk
Local Time is: Thu Mar 9 14:24:53 2017 PST
SMART support is: Unavailable - device lacks SMART capability.

=== START OF READ SMART DATA SECTION ===

Error Counter logging not supported

Device does not support Self Test logging
[root@NTNX-71f86937-A ~]# smartctl -a /dev/sdb
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.4.26-1.el7.nutanix.20170222.x86_64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke,www.smartmontools.org

=== START OF INFORMATION SECTION ===
Vendor: HP
Product: LOGICAL VOLUME
Revision: 6.64
User Capacity: 2,000,342,441,984 bytes [2.00 TB]
Logical block size: 512 bytes
Rotation Rate: 15000 rpm
Logical Unit id: 0x600508b1001cec93d95097d47affa22f

Serial number: PACCRID11320BPR　<========これ

Device type: disk
Local Time is: Thu Mar 9 14:24:56 2017 PST
SMART support is: Unavailable - device lacks SMART capability.

=== START OF READ SMART DATA SECTION ===

Error Counter logging not supported

Device does not support Self Test logging

[root@NTNX-71f86937-A ~]#hpacucli ctrl slot=1 show

Smart Array P410 in Slot 1
Bus Interface: PCI
Slot: 1
Serial Number: PACCRID11320BPR　　　<========これ
…


　このシリアルがCVMの初期設定時にxmlに書かれるのですが､このシリアルをCVMの中でマウントポイントとして使っているため､同じシリアルがあると二重マウントになりどちらかがアクセスできなくなります｡


[root@NTNX-d16bad23-A ~]# virsh dumpxml NTNX-d16bad23-A-CVM
(省略)
<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source dev='/dev/disk/by-id/scsi-3600508b1001cec93d95097d47affa22f'/>
<backingStore/>
<target dev='sda' bus='scsi'/>
<serial>PACCRID11320BPR</serial>　　　　　　<========これ
<wwn>600508b1001cec93</wwn>
<vendor>ATA</vendor>
<product>LOGICAL VOLUME</product>
<alias name='scsi0-0-0-0'/>
<address type='drive' controller='0' bus='0' target='0' unit='0'/>
</disk>


<disk type='block' device='disk'>
<driver name='qemu' type='raw' cache='none' io='native'/>
<source dev='/dev/disk/by-id/scsi-3600508b1001cb8ae0693a3fdcc1e17ca'/>
<backingStore/>
<target dev='sdb' bus='scsi'/>
<serial>PACCRID11320BPR</serial>　　　　　　<========これ
<wwn>600508b1001cb8ae</wwn>
<vendor>ATA</vendor>
<product>LOGICAL VOLUME</product>
<alias name='scsi0-0-0-1'/>
<address type='drive' controller='0' bus='0' target='0' unit='1'/>
</disk>


CVM上のマウントポイントは以下のようになります｡
nutanix@NTNX-71f86937-A-CVM:172.20.1.114:~$ mount
(省略)
/dev/sdb1 on /home/nutanix/data/stargate-storage/disks/PACCRID11320BPR type ext4 (rw,nosuid,noatime,data=ordered,nodiscard,nodelalloc,init_itable=30)
/dev/sda4 on /home/nutanix/data/stargate-storage/disks/PACCRID11320BPR type ext4 (rw,nosuid,noatime,data=ordered,nodiscard,nodelalloc,init_itable=30)
none on /dev/cgroup type cgroup (rw,cpu,cpuacct,memory,freezer,net_cls)


　この結果から､1つのSmartArrayコントローラ上で論理ディスクを2つ以上作ると死ぬ事が確定したので､これを回避する必要があります｡どうにかコントローラからエクスポートするシリアルを変更できないか､CVM構成後にディスク情報を変えられないか調べたのですが､時間の無駄でした｡

　この記事を書きながらふと｢ではlibvirt向けのxmlを書き出すところでstartctrlからの情報ではなくその都度ランダムに生成するようにすれば､あるいは…｣とも思いましたが気力が尽きました｡

対処法


　今回の対処としては､光学ドライブに2.5インチのディスクをマウントする12.5mm厚のダミーマウンタを買い､SSDはAHCIに見せることにしました｡


　どうでも良いですが､ML380の光学ドライブを交換したあとにディスクの後ろに付いているスペーサに気がつきました｡


　めんどくさいのでそのままです｡窪んでます｡雑い｡


ハマり3 何故かSmartArrayの通常ディスクがSSDとして認識されてしまう


　かくして､マウントポイントが被る問題は対処できたのですが､今度は何故か何度CVMを作り直しても､通常のHDDがSSDとして認識されてしまいました｡
　これが今回の大きなハマりポイントでした｡

　Prismやnclからみても､HDDであるべきストレージがSSDと認識されてしまいます｡もちろん､ホスト上の/sys/~/rotationalは1を返しています｡1.5TのSSDが本当にあったら良かったんですが､残念ながらHDDです｡



　まあそのままでも動くので､階層化が全く機能しなくなるけどもう良いかなと心が折れかけていましたが､原因が見つかりました｡

原因


　Nutanix CEにinstallで入ると､インストールスクリプトの中でどのディスクがSSDであるかをhclリストの中から探し､その中になければ今回SSDとして認識されたディスク（cat /sys/~/rotational 0として認識したディスク）を/home/install/phx_iso/phoenix/hcl.jsonの中に追記し､それをCVMに渡すようです｡

　CVMは､起動時にそのjsonを元に､今アタッチされているディスクのうちどれがSSDかを確認するようです｡アタッチされているディスクの情報は､libvirtのxmlに書かれたProduct名(今回は<product>LOGICAL VOLUME</product>と言う値)がCVMに渡るようです｡

　さて､この/home/install/phx_iso/phoenix/hcl.jsonですが､再インストールのためにrootで./cleanup.sh を行っても初期の状態には戻らないため､過去にecho 0 >/sys~をやって過去にSSDとして認識されてしまうと､そのディスクがずっとSSDとして残り続けるようです｡これが原因でした｡

対処法


/home/install/phx_iso/phoenix/hcl.jsonを編集し､該当行を消し､CVMを作り直します｡もしくはもう一度USBメモリを作り直し､初期の状態にもどします｡
　今回は下記の行をまるっと削除し､再度installでログインしてCVMを作り直しました｡
{
"nand_type": "MLC",
"capacity_gb": 240.02150400000002,
"interface": "SATA600",
"data": "true",
"last_edit": 1489090465,
"manufacturer": "Community Edition",
"boot": "true",
"model_string": "LOGICAL VOLUME",
"approved_by": "Nutanix, CE",
"model": "LOGICAL VOLUME",
"metadata": "true"
}


　その後､無事にHDDとして認識されました｡

まとめ


サポート外構成は､やめようね!!!


　何故サポートしないか､それにはちゃんとした理由があると実感しました｡つらかった…
　少なくとも､NutanixにP410以前のSmartArrayカードはサポートされていないので使うべきではありません｡特に1つのコントローラで2つ以上の論理ドライブを作成する場合は確実に死にます｡

　MegaRAIDカードの場合は､インストールスクリプト中でmegacliであれこれしてシリアルを抜き出しているようなので､それぞれのディスクをRAID0で見せる場合は大丈夫な気がしますが､複数のディスクでRAID5などを作成した場合は分かりません｡

　SmartArrayも､P420以降に関しては､ファームバージョン7くらいからHBAモードがあるのは確認しましたが､HBAモード時にディスクのSerialをどう返すかは未確認です｡

　しかしながら､このほぼ情報がないトラブルのおかげでずいぶんとnutanixがインストール時に何をするかを深いところまでみられたので､勉強にはなりました｡あとncliやhpacucliも初めて使いましたが調査の段階で何度も様々なコマンドを打ったので､だいぶ慣れました｡

　多分運用が始まるとそれはそれで問題が出るので､何かあればまた記事にしようと思います｡


[ 1 コメント ] ( 1516 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3.1 / 1467 )  |  
【HW】RackSwitch G8124-Eのファンを交換してみた 
2016, November 26, Saturday, 23:24 - HardWare, Network
投稿者 @xmms



　3年くらい前にRackSwitch G8124-EをeBayで仕入れ、しばらく使用していたのですが、あるときにファンの一つが故障し、それまで30%くらいで回転していたファンが全て減退運転に入り、全て80%くらいで回転するようになりました。それまでは結構静かだったのですが、さすがに小型ファンの高速回転はうるさく、部屋のノイズ主成分(音的な意味で)になっていました。
　うるさい事と定期的にファン故障のトラップが飛ぶ以外は特に問題がないので(問題ですが)、故障後も放置してしばらく使っていましたが、運良く非常に安くApresia 130000が手に入ったので交換してしまいました。





　燦然と輝く真っ青なスイッチに、VLANを使った程度のL2ネットワークをさせるだけではオーバースペック感ありますが、まあそれなりに静かでいい感じです。
　その後、G8124は放置になっていたのですが、ふと直せるかどうか気になったのでふたを開けてみました。

　壊れたファンはSUNONのGM1204PQV1-8Aと言うファンで、他のファンはUltraFlo W40S12BUA5-52なのですが、何故かこれだけSUNON製のものになっていました。元のオーナーが同じように手で直したのでしょうか…。




　とりあえず、ファンの形状やコネクタは一般的なもののように見えたので、手元のゴミを漁ったら秋葉原でいつか役に立ちそうな気がして買った40ミリファンの連結した何かが出てきたので、それを分解して交換することにしました。




　多分Supermicroの保守パーツ的な何かだと思いますが、もはやこれが何であってもどうでもいいです。




　その中のファンにはSanAceの109P0412J3063が使われていました。むしろ他のも全てこれに交換してしまいたいレベルですが、とりあえず壊れた部分だけ交換します。

　交換して、ひとまず動くか電源ON。起動しましたが、その直後異臭が立ちこめたので真顔で即座にACを引っこ抜きました。幸い、発煙や炎上はありませんでしたが、部屋がICを過電流で焼いたときの臭いで包まれました。この臭いほんとに嫌いです…(嗅ぐ羽目になったシチュエーションでは大体ああああああなことになってるので)

　原因を確認してみると、コネクタは普通の3ピンなのですがアサインが違いました。これは死ぬ。何故確認しなかったし…。




　解決策として、SUNON製のファンのコネクタを切り取り、綺麗な芋ハンダ(汚い)で直そうかと思いましたが、半田ごてをしばらく使っていなかったので引っ張り出すのがめんどくさくなり、その代わり手元にあったブレッドボード用のジャンプワイヤを使う事にしました。




　その後おそるおそる起動してみると、とりあえずファンは順調に回っていたので、再び電源を落とし、ふたを戻しました。
　ふたを戻したあと、起動してみると、普段はファン故障でファンの回転数は落ちないのですが、今回は無事に回転数が落ちました。ファンの全回転時と比べ、20Wくらいの差がありました。
　コンソールに入ってみると、無事に回転数も取れていました。

RS G8124-E#show sys-info

System Information at 15:44:38 Mon Sep 5, 2016
Time zone: No timezone configured
Daylight Savings Time Status: Disabled

IBM Networking Operating System RackSwitch G8124-E

Switch has been up for 0 days, 0 hours, 12 minutes and 9 seconds.
Last boot: 15:32:42 Mon Sep 5, 2016 (power cycle)

MAC address: xx:xx:xx:xx:xx:xx IP (If 1) address: 0.0.0.0
MGMT-A Port MAC Address: xx:xx:xx:xx:xx:xx
MGMT-A Port IP Address (if 127): 172.20.1.6
MGMT-B Port MAC Address: xx:xx:xx:xx:xx:xx
MGMT-B Port IP Address (if 128): 192.168.51.50
Hardware Revision: 8
Board Revision: 2
Switch Serial No: xx:xx:xx:xx:xx:xx
Hardware Part No: xx:xx:xx:xx:xx:xx Spare Part No: xx:xx:xx:xx:xx:xx
Manufacturing date: 10/46


Software Version 7.9.11 (FLASH image2), active configuration.
Boot kernel version 7.9.11



Temperature Sensor 1: 21.5 C
Temperature Sensor 2: 27.0 C
Temperature Sensor 3: 26.00 C
Temperature Sensor 4: 43.75 C
Temperature Sensor 5: 35.50 C

Warning at 85C and Failure at 100C

Speed of Fan 1: 7964 RPM (75 PWM)
Speed of Fan 2: 8169 RPM (75 PWM)
Speed of Fan 3: 8023 RPM (75 PWM)　<---故障したファン
Speed of Fan 4: 8503 RPM (75 PWM)
Speed of Fan 5: 8256 RPM (75 PWM)
Speed of Fan 6: 8120 RPM (75 PWM)

System Fan Airflow: Front to Rear

State of Power Supply 1: On
State of Power Supply 2: On


　自分の不確認により一つSanAceの109P0412J3063が犠牲になりましたが、最終的には無事に直すことが出来ました。直しても今後使う予定はないので微妙ですが、某所のラボネットワークの変更時に持ち込もうかなあ…。

　ピンアサインにさえ気をつければ一般品でも交換できるので、保守のないスイッチで、もし同じようにファン故障で困っている人がいたら試す価値はあると思います。

[ コメントを書く ] ( 1115 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1669 )  |  
【HW】VR500(aka 鎖国ルーター)をゲットしたのでOpenWrtを入れて遊んでみた 
2016, September 19, Monday, 17:45 - HardWare, Network
投稿者 @xmms
　SRCHACKさんがVR500で面白そうな遊びをしていたので、VR500はHW面で興味があったのですが、自分も筐体をゲットできたので遊んでみました。文章が長いのと長い文章に疲れて所々雑になっているのは許してヒヤシンス



もっと読む...

[ コメントを書く ] ( 4531 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1420 )  |  
すとれーじないとめあ　後編 
2016, July 24, Sunday, 05:27 - PC, HardWare
投稿者 @xmms
　前編でまず2つの惨劇を体験しましたが、トラブルはまだ終わりません。

プライマリストレージサーバの置き換え


　前編でプライマリを復旧したあと、しばらくそのままの環境で使っていましたが、その後バックアップサーバのST2000DL003が死にました。半年以内に3台のDM001と1台のDL003が連鎖的に死亡していくのをみて、さすがに怖くなってプライマリストレージサーバのHDDを全て交換することにしました。(ちなみに死亡したHDDに限って購入時のレシートが見つからないという)
　グロ画像ことプライマリとバックアップサーバから引き抜いたDL003君とDM001君です




　ストレージサーバの置き換えには、遊んでいたX8DTLにXeon L5630とメモリを適当に積み、ディスクには東芝製MD04ACA200を使う事とにしました。

惨事その3 RAIDアレイが突然死


　X8DTLにはオンボードで LSI 1068Eから生える8ポートのJBODで見えるSATA/SASポートがあり、このポートを利用してmdraidでraid5のSRPデータストアを作成し、AHCIの方から生えているSATAポートを/などのOS用に割り当てることにしました。
　当初はこれで問題なく動いていたのですが、構築から2週間後にZabbixから

kernel: mptbase: ioc0: WARNING - IOC is in FAULT state!!!


　という見たくない感じのエラーが飛び、その後mdからディスクが1本もげました。
　何故構築してから全く時間が経っていないのにディスクが故障?と思いましたが、とりあえず予備のMD04ACA200と交換することにしました。が、再構築中にmdがUU__U___になり死にました。その死に方も、一旦その状態になるとsmartctrl -x /dev/sdaなど、1068Eに繋がっている他のディスクに対して行うとエラーを返す、fdiskでも見えなくなるという状態でした。
　この文章を書き起こしていても思い出したくないくらいのトラウマなのですが、全てのディスクをsmartやWindowsからHDTuneで読み書きテストをしてみても、特に問題は見つかりませんでした。仕方がないので、再度RAIDの初期化を行い、再度バックアップからの戻しを行いました。
　しかし、また1ヶ月後に例のエラーが出て、ディスクアレイが死にました。

惨事その4 RAID HBAが突然死


　おそらく、この状態になっていると言う事は、オンボードのLSIのチップが死んでいる?という可能性があったので、オンボードの1068Eを利用しないでLSI 2008チップを載せたD2607を追加し、JBODで見る設定にしました。何故このHBAかというと、手元にありかつ速度がそれなりに速くて接続されたディスクをJBODで見せられるというのが魅力だと感じたからでした。
　が、こいつも1ヶ月後にmdが全崩壊を起こしました。

惨事その5 解決したと思わせてからのHBAの突然死


　この辺でトラブルについてはほんともうお腹いっぱいだったのですが、この不定期に起きる悪夢の根本原因を探すことにしました。
　しかし、何から調べたものか…と、困っていると、ディスクのsmartを取ろうとすると、smartを取得してからその情報を返すまで、非常にディスクのIOが遅くなっていることに気がつきました。
　これを手がかりに、検証機でテストしてみると、何もないときはddで内容を読んでいても全く問題がないのですが、smartctrlを動かしながらddをすると、あるタイミングでsmartが刺さり、smartの内容を全く返さなくなり^Cでも中断できなくなり、かつIOがゼロになると言う問題が起きました。
　何もせずにdd if=/dev/sda (D2607に繋がってるMD04ACA200) of=/dev/nullを行っているときの状態です。Readが193MB/s出ているので普通です。




　その状態で、新しくSSHのセッションを張り、

while :; do smartctrl -x /dev/sda >/dev/null ;date; sleep 1 ; done


　をした結果です。




　ddは続いているのですが、IOが0になり、かつDisk busyが100になり、CPUを1つI/O WAITで潰しています。

　この内容で調べてみると、ぴったりではないのですが、D2607のファームウェア情報に、SMARTの情報異常を感知してコピーバックをする(予備ディスクに内容をコピーして異常時に備える)時にHBAが死ぬという情報があったので、とりあえずファームを新しくしてみました。
　その結果、smartctrlをかけながらddをしても、smartを返す時にはIOは遅くなるものの、完全に刺さることはなくなりました。
　また、Debianでsmartmontoolsを入れるとデフォルトで定期的にsmartdが各ディスクにSMARTクエリを飛ばすので、systemctl disable smartdを行い、ドライバもLSIから落としたものをビルドし、smart関連で刺さらないことを祈りました。ディスクへの情報取得で何かが起きていることはおそらく間違いないので、さすがにこれで解決したと思いました。いや、思いたかったのですが…
　再びHBAが死にました。

再現性の調査


　もしかしたらこの悪夢はLSI 2008チップと東芝のディスクの相性が原因で、他のLSI 2008チップを使っているHBAでも同じように起きるのでは?と思いいくつか試してみました。




　検証環境で試した結果、以下の結果が分かりました。

・D2607だけではなく、HP OEMの LSI SAS 9212-4i(同じLSI2008チップを使うデフォルトでITモードで動くHBA)でもOSから複数のディスクでRAIDを組むと、バースト的な高負荷書き込みが連続すると不定期に死ぬ
・D2607はJBODを有効にせず、それぞれのディスクで1本のRAID0を作る(過去に8708EM2等で使われていた方法)を使うと検証期間中には問題が起きなかった(SMARTの取得は出来なくなりますが)
・MD04だけではなく、MD03、DT01、日立のHUA723でもSMARTの問題は起きる(これらのディスクは返す内容が大体同じ)
・SeagateのDM001、DL003、WDのCaviarGreen等ではSMARTの問題は起きない(日立系ディスクに比べて非常に簡素な内容しか返さない)
・LSI 2108を載せたボードでは、JBODは出来ないがHBA上でRAIDを組む分には問題なさそう(短期間しか試してないので怪しい)

以上のことから、LSI のチップでEnable JBODを有効にしてJBODでディスクをみていたり、ITモードで動くHBAと日立系のディスクは問題があるのかもしれないという結論に達しました。

ディスク全交換 そしてトラブルは静まる


　上述のテストをしてる間に、秋葉原のBUYMOREでMG03ACAがバルクで入荷し、非常に安かったので一つ買ってみたところ問題が起きなさそうだったので、結局ディスクを全てMG03ACA300に交換してしまいました。MG03はSMARTでSAS系の情報を返すNL-SAS製品で、MD/DTシリーズとは動きが違うようでした(噂ではMGシリーズは富士通の流れをくむディスクで、それ以外は日立の流れをくむらしい。富士通のSASディスクでSMARTを見たことないので確証はありませんが、近いとは思います)。もうこのトラブルとおさらばできるのなら多少の出費は厭わない、という感じです。
　このディスクに交換したところ、D2607でJBODで見ていても過去のトラブルが嘘のような平凡な日々が訪れました。少なくとも、今のところは…。

まとめ


　今回の問題を回避するには、少なくともLinux上では

・LSIのチップに日立系のディスクを混ぜないこと
・LSIのチップで日立系のディスクを使うのなら、HBA自体のRAIDを利用すること(少なくともJBODで見るよりはトラブらない)
・日立系ディスクをJBODで見たいなら、オンボードのAHCI/SCUを使う事(smart取得時の速度低下は起きるが死ぬ事はなかった)
・2012年頃のSeagateのディスクはやばい(DM01が3/8で36%の故障率、DL003が1/6で16%の故障率)

　と言うのが今のところの結論です。日立系のディスクと言っても、ニアラインSASや10kRPMのSASドライブではまた違うと思いますが、少なくともデスクトップ向けのディスクとLSIのチップは避けるべきのようです。
　また、DM001の故障率は有名なBACKBLAZEでもST3000DM001が導入からちょうど2-3年で20-40%の割合で故障しているので、奇しくもこのデータと近い値が出てしまいました。このヤバいディスクがINしてるシステムでまだ問題が起きていないのであれば、早急に交換をおすすめします。(大半のディスクはもう死んでこの世にいないかもしれませんが)
　1台2台がばらばらの時期に壊れてくれるのであれば良いのですが(良くはない)、まさか連続死を起こされるとは…。まあ、それを見越した設計でも最後の砦を壊したのはこの手でしたが。
　この一件で、バックアップの重要性を身をもって実感することになり、いくつかのデータは仮想マシンではなく物理マシンにrsyncするようになりました。そしてディスクが安く売ってると買ってバックアップサーバを作らなくてはと言う強迫観念に駆られるという傷跡を残しました。
　せめてもの救いは、オペミスしたのが自分の環境だったことで、仕事でやらなくて良かったという点です。個人的には仕事のデータなんかよりこちらの方がよほど大事ですが…。


　かなり長い間悩んだ内容だったので記事自体も長くなってしまいましたが、誰かの役に立つことを願い一応まとめてみました。ストレージ関係の悪夢はほんとつらいので誰も見ないに越したことはないのですが。

[ コメントを書く ] ( 1031 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 2.9 / 1757 )  |  
【HW】すとれーじないとめあ　前編 
2016, July 24, Sunday, 01:28 - PC, HardWare
投稿者 @xmms


　凄く久々にブログを更新しますが、この間に色々問題が起きたのでその事についてまとめようと思います。
　特に、この一年は何故かストレージ周りでトラブルが起きることが多く、とてもつらい感じでした…が、とりあえず収束したようなので書き出してみようと思います。

惨事その1　RAIDアレイ崩壊→VMストレージの死


　事の発端はまずここからでした。去年2015年の6月頃に、まず1台ディスクが故障しました。故障したディスクは悪名高きST2000DM001です。(あとになって故障率の高さを知りましたが。7200.12くらいの頃はディスクロックというもの以外そこまで壊れた経験がなかったのでSeagateのディスクは大丈夫だろうと思いましたが、それが甘かったです…)
　まあ、当時でも構築して2年くらいが経っていたので、そろそろディスクの1台くらい壊れても不思議ではないかなあと思い、手持ちのST2000DM001と交換し、再構築しました。
　その時は特に問題がなかったのですが、更に2ヶ月後の8月に2台目のDM001が死にました。このときに手元にあったのがバックアップストレージに使っていたST2000DL003だったのですが、回転数が違うので新しいのを買わないとなあと1週間くらいRAIDがデグレッた状態で放置していたのですが、この一週間のうちに3台目のST2000DM001が死に、RAIDアレイが全損しました。

　うっせやろと思いながらも、ghettoVCBにてバックアップのストレージに重要なマシンのコピーを取っていたので、ダメージは少なく、ここから戻しを行うことにしました。
　しかし、ghettoVCBのような方法だと、vmdkの差分コピーとはならず、実行する度に全てのディスクをまるまるコピーすることになるので、TBクラスのディスクを定義しているとなると色々厳しくなります。
　そのため、ある程度データが大きくなりそうなものについては、バックアップ対象外のVMとしてNFSサーバを作り、そこに置くようにしていました。そして、これが悲劇の元に…

惨事その2　オペミス


　タイトルでネタバレしていますが、まず環境を簡単に説明します。




　非常に雑な絵ですが、このような方法で/を含むsdaのイメージバックアップと、sdbに含まれるNFSの領域をsdcへコピーしていました。オレンジの円がVMホストからのSRP接続のデータストアで、青い円がVMゲストから別の物理NFSサーバ(10G接続)への接続です。同期方法は/はMondo backupによるイメージバックアップで、/exportは/export_backへrsyncでした。
　ちなみに、NFSには内輪で使っていた諸々のMODデータやこのブログのデータが置いてありました。

　プライマリのストレージに問題が起きた場合はvmxファイルなどが消えますが、その際には新規でVMを定義し直し、NFSからMondo backupで定期的に作成されるISOをマウントして復旧、その後/exportを/export_backから戻す、と言う想定でした。mondo自体の実績はあったのでまあ手間だけど問題ないだろうと言う判断でした。

　直接NFSに/exportのコピー持てば良くないかと思うかもしれませんが、NFSサーバはメインで使っているNASなので、フルに同期するとその当時の容量的にぎりぎり収まるか何かあれば溢れるという状態だったため、容量的に余裕のあるghettoVCBのバックアップ先にもなっているセカンダリストレージサーバにSRPデータストアを作成していました。

　環境の説明が終わったところで、本題に移ります。今回はプライマリストレージが死んだので、このような状態になりました。



　そのため、プライマリストレージのディスクを新しく2本買い再構築したうえで、想定通り/nfsに取っていたISOイメージからまずVMの戻しを行いました。正確に言うと微妙に図とは違いますが、概要としてはこうなります。




　その後、/が復旧したので、/exportの復旧を行うことにしました。が、ここでデータストアを間違えてセカンダリストレージに定義してしまいました。(あっ…)



　あ、vmdkの置き先を間違えた、と気がついたので、再度ディスクの定義をしようと一旦間違えた方をけす事にしました。そして実際のオペレーションが下記です。







　ミスに気がついたときの状態のイメージです。ご確認ください。




　ええ、人は犯したミスの大きさ、そのミスが戻せないと分かるとほんとこんな感じになります。しかもたちの悪いことにディスクイメージ自体の削除を選んでしまったんですよね。バックアップがあるから大丈夫、という慢心の結果、そのバックアップを自らの手で消す、という愚行を行ってしまいました。これさえしていなければ何事もなかったというのに…。

　SRPのエクスポートを一旦止めて、あれこれとディスクの復旧が出来ないかと試してみましたが、まあ無理でした。
　バイナリレベルではいくつかのテキストが見つかりましたが、ある程度の大きさのファイルは断片化があり復旧は困難でした。

　どうにか復旧できないかとあれこれ探した結果、物理サーバでブログを動かしていた頃のディスクがあったので、そこから何とか復旧できましたが、諸々のデータが1年分消えました。(前エントリが非常に古いのはそのせい)

　その後、色々動いていないと不便なので結局プライマリのストレージは再度稼動させ、VM環境もどうにか以前の状態までは復旧させました。
　ここまでで十分惨状ですが、このあともまだトラブルは続きました…(長くなったので後半へ)

[ 2 コメント ] ( 1120 回表示 )   |  このエントリーのURL  |  $star_image$star_image$star_image$star_image$star_image ( 3 / 1623 )  |  

<<最初へ <戻る | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 進む> 最後へ>>