プライマリストレージサーバの置き換え
前編でプライマリを復旧したあと、しばらくそのままの環境で使っていましたが、その後バックアップサーバの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するようになりました。そしてディスクが安く売ってると買ってバックアップサーバを作らなくてはと言う強迫観念に駆られるという傷跡を残しました。
せめてもの救いは、オペミスしたのが自分の環境だったことで、仕事でやらなくて良かったという点です。個人的には仕事のデータなんかよりこちらの方がよほど大事ですが…。
かなり長い間悩んだ内容だったので記事自体も長くなってしまいましたが、誰かの役に立つことを願い一応まとめてみました。ストレージ関係の悪夢はほんとつらいので誰も見ないに越したことはないのですが。
[ コメントを書く ] ( 1146 回表示 ) | このエントリーのURL |
( 2.9 / 1861 ) | ツイート
凄く久々にブログを更新しますが、この間に色々問題が起きたのでその事についてまとめようと思います。
特に、この一年は何故かストレージ周りでトラブルが起きることが多く、とてもつらい感じでした…が、とりあえず収束したようなので書き出してみようと思います。
惨事その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 コメント ] ( 1193 回表示 ) | このエントリーのURL |
( 3 / 1735 ) | ツイートずいぶん前に貸与されてから塩漬けになっていたRB2011ですが、裏ルータ的な何かとしていざ使ってみたところ接続が不安定だった為メモしておきます。
結論から書くと、所謂MTU/MRU1454問題でした。まあこれだけ書けば分かる人には終了ですね。
RBの仕様は、PPPoEセッション上のMTU/MRUがデフォルトで1480で設定されるのですが、NTT網内のMTU/MRUが最大1454であるため、フラグメントが起きてしまうようなページを開いてしまうと、ページが不完全のまま表示されるかタイムアウトしてしまうのです。
具体的にはこのブログのTwitterプラグインで問題が起きます。なので、同様の問題があって検索した人がこのページを開けないという残念な問題が起きます。（ぇ もしかしたら不完全ながらも表示できるかもしれませんが。
このページをRB2011から別のPPPoEセッションを張りWANから参照してみた際のログですが、デフォルトの設定だと、以下のように、特定のファイルだけいつまでもファイルが降ってきません。
Pingなどが途切れることはなく、なおかつ問題ないページは問題なく表示されるのですが、一部の広告表示用Javascriptが挿入されているようなページだとタイムアウト待ちをするため、ブラウジングの際にページの表示速度が非常にストレスフルな表示速度になります。
内側のLinuxから行ったtracepathの結果やWebFigの表示結果を見る限りは、MTUの値は1480のデフォルトでも正しく1454で受け取るようなのですが、MRUの値は1480のままであり、これが問題になるようです。
解決するには、PPPoEインターフェースのMRUを変更します。
MTUは自動設定されますが、一応変えておいたほうが無難だと思われます。OK/Applyをクリックすることにより設定を反映しますが、その際にPPPoEを切ってから再度接続を行うため、ISPによってはIPが変わります。（OCNの環境だとIPが変わりました。）
変更後、見た限りWebページによって表示が遅い問題は解決しました。現在、2つのIFを束ねたBonding IF上に タグVLANを作成し、LANセグメントをいくつかとWANセグメントインターフェースを作成していますが、この構成でも問題なく動いています。
完全に接続ができないわけではなく、さらに回線速度測定ページなどでは問題なく速度が出てしまうため、この問題に気が付きませんでした。
悩んでいたところ解決の糸口を享受していただいた@neko6_tweetさんに感謝です。
しかし、1.6万前後でここまでVLANなどがいじれるルーターはなかなかないですね。ちらっと見たところポリシーベースルーティング(PBR)も当たり前のようにできるようですし、ネットワークにおける大体のやりたいことをどうにかする方法があるようです。これは魅力に取りつかれる人が多いのも納得です。
[ 1 コメント ] ( 1972 回表示 ) | このエントリーのURL |
( 3 / 2029 ) | ツイート
巷で話題のECS LivaをついIYHしてしまいました。秋葉原Buymoreの展示機を見てから、欲しいなと思っていつつも中々在庫がどこにも入ってこなかったのですが、仕事帰りに何となくドスパラを見たらあったのでつい…。
個人的に、何に使うかよりも、HWとしてどの程度使えるのか興味があったため、この評価ボード（違う）のレビューしてみます。画像の元ネタが一発で分かったような人には多分物足りないと思いますが。どうでも良いですが、元ネタは左手だったんですね。頭にあるイメージで右だと思って思いつきで突貫で作って、作ったあと気がつきました。ほんとどうでも良い。
思ったよりもハマりポイントが多かったため、まずはHWの部分です。
もっと読む...
[ コメントを書く ] ( 4532 回表示 ) | このエントリーのURL |
( 3.1 / 1825 ) | ツイート某所にいたときに不毛な作業を少しでも楽にしようと足掻いた時に作ったゴミを置いておきます。たまにこれをベースに何かを作ったりするので主に自分のためのメモですが。
内容としては、Expectで複数サーバに対して同一コマンドをsuして実行するだけのゴミと複数のサーバから一か所にファイルをSCPで集めるか送るだけのゴミです。
もっと読む...
[ コメントを書く ] ( 2326 回表示 ) | このエントリーのURL |
( 3 / 1927 ) | ツイート<<最初へ <戻る | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 進む> 最後へ>>
自己紹介
、もしくはTwitterまでお願いします。
