Clever Geek Handbook

バックアップする理由 RAIDがあります





企業ブログで成功談を書くのが慣習です-これは会社のイメージにプラスの影響を与えます。 残念なことに、すべてがハッピーエンドで終わるのは、エンジニアの仕事の中で常にではありません。

私の同僚は、私が問題を「引き付けている」と冗談を言い始めていると言わなければなりません。 何らかの形で、私は最近、ほとんどすべての問題のあるアプリケーションに参加しました。 そして今、私は私の練習から1つの有益な物語を伝えたいです。



ストーリーは、あるストレージシステムのディスクアレイのパフォーマンスを分析するように依頼されたという事実から始まりました。そのストレージアレイの「ブレーキ」は、ブランチ全体の作業を麻痺させました。 初期状態は次のとおりです。





アレイのパフォーマンスログによると、負荷の増加により「ブレーキ」は発生しませんでした。 問題の原因は、HP EVA仮想化ストレージシステムのコントローラーの故障であると思われました。 通常、パフォーマンスの問題はリモートで解決されますが、この場合、彼らはエンジニアをその場所に派遣することに決めました（その旅行が2週間続くと疑われる人はいませんでした）。



その後、パフォーマンス分析中に「ポルターガイスト」が表示され始めました。vSphereインターフェイスのアレイのボリュームは、顧客がアレイの問題と見なした誤ったボリューム（マイナスから数十ペタバイト）を定期的に表示します。 同時に、一部の仮想マシンのコンソールへのアクセスが消失し、他の問題が発生しました。 私もすでに緊張し始めており、顧客はちょうど連絡が取れていません。



そして、問題の花火だけが始まります。



誤ったボリュームサイズが表示される可能性があるESXiのバグが見つかりました。 しかし、VMwareサポートの公式契約はないことが判明しました。 サポートはサードパーティ企業によって提供され、営業日のみで、土曜日に行われます。











完全な幸福のために、3台のサーバーのうち2台とスイッチ（ブレードシャーシ）のファームウェアは、シャーシ制御モジュールのファームウェアよりも遅れており、これは最も予期しない問題につながる可能性があります。 さて、ケーキのチェリー：SANスイッチではファームウェアの異なるバージョンであり、前のすべてのメジャーバージョン（6.xx、8.0.xが利用可能な場合）です。



最後に、MS SQL Server Expressの空き容量が不足したため、vSphereでVMコンソールを使用できる「ポルターガイスト」が発生し、ボリュームサイズが正しく表示されませんでした。 そのため、管理者がデータベースの問題を解決している間に、ストレージを把握しようとしました。



何らかのアクションの後、メインボリュームが突然オフラインになりました。



SHDバージョン7.3、7.4、および7.5のファームウェアのバグを思い出しました。これは、一定数のヒット後に圧縮ボリュームにビートブロックが表示されることがあるためです（この状況では、エラーがあるため、RAIDフォールトトレランスも隣接するアレイへのボリュームのミラーリングも役に立たないことがあります）より高いレベルです）。



そして、ここで最も興味深いニュアンスが明らかになりました。それは、IBSがすでに3か月間顧客と協力していないことが判明したことです。 つまり、バックアップは存在しますが、それらは関係がなく、それらからの回復はデータの損失と同じです。



ボリュームをオンラインで（アレイのCLIを介して）翻訳することができましたが、ホストが最初に何かを書き込もうとすると、再び落ちました。 サーバー上のすべてのデータストアをオフにし、翌日、ほとんど呼吸することなくオフィスで過ごし、動作するすべての仮想マシンをサーバー、USBドライブ、PCにコピーしました。



その結果、スナップショットの統合が開始されたVMを除くすべてのデータを保存することができました。これは、統合プロセス中にLUNがオフラインになり、VMデータの代わりに「混乱」が生じたためです。 意地悪の法則によると、これはVM電子文書管理システムであることが判明しました。 さらに、さまざまなリスクを排除するために、VMware、Brocade、HP Bladeなど、インフラストラクチャのほぼ全体をアップグレードする必要がありました。



災害の背景



似たような状況に陥らないように、この物語から著名な読者はどのような結論を引き出すことができますか？



  1. ストレージが正しく設計されていません 。 〜12 TBのシングルボリュームは、従来のストレージシステムでは正常に動作しません。 常に総容量を1〜2 TBのオーダーのボリュームに分割します。 はい、有用な容量は少なくなりますが、「すべてが私たちと一緒に遅くなっている」アプリケーションを開く可能性はずっと少なくなります。 更新 ：多くのブロックアクセスストレージシステムでは、複数のホストが同じ月（たとえば、仮想化クラスター）に集中的にアクセスしている場合、パフォーマンスの問題が発生する可能性があります。 そのような状況では、LUNのコマンドキューに実行されないように、ボリュームを小さなボリュームに分割することをお勧めします。
  2. ファームウェアは更新されていません 。 これは、古いファームウェアのバグがダウンタイムまたはデータ損失につながった唯一の話ではありません。 はい、新しいファームウェアにもバグがありますが、誰もあなたに最先端の使用を強制することはありません。 安定した推奨バージョンを使用してください。
  3. バックアップ バックアップを作成および確認するために必要なリクエストと推奨事項の数-カウントされません。 私は自分自身を繰り返すつもりはありませんが、 常に時間をかけてバックアップを確認してください 。 このストーリーでは、IBSが稼働状態に維持されていれば、ダウンタイムを少なくとも2倍削減できました。











  4. ベンダーのハードウェアサポートはありませんでした 。 機器の深い知識を持つ優秀なスペシャリストがいますが、ベンダーだけが手助けできる状況があります。
  5. データベースの空き領域は監視されませんでした 。 ディスクだけでなくデータベースの空き領域にも注意してください。


ご静聴ありがとうございました。



Alexey Trifonov Tomatos氏、Jet Infosystemsサービスセンターのエンジニア。


More articles:


All Articles