高可用性ストレージ上のソフトウェアを検証することが重要な理由 (99,9999%)

最も「正確」かつ「動作」しているファームウェアのバージョンはどれですか? ストレージ システムが 99,9999% のフォールト トレランスを保証している場合、ソフトウェア アップデートがなくても中断なく動作することを意味しますか? それとも逆に、最大限の耐障害性を得るには、常に最新のファームウェアをインストールする必要がありますか? 私たちの経験に基づいて、これらの質問に答えていきます。

簡単な紹介

オペレーティング システムであれ、デバイスのドライバーであれ、ソフトウェアの各バージョンには、多くの場合、機器の耐用年数が終了するか「オープン」になるまで「表示」されない可能性のある欠陥/バグやその他の「機能」が含まれていることを誰もが理解しています。特定の条件下でのみ。 このようなニュアンスの数と重要性は、ソフトウェアの複雑さ (機能) と開発中のテストの品質によって異なります。 

多くの場合、ユーザーは「工場出荷時のファームウェア」（有名な「動作するのでいじらないでください」）を使い続けるか、常に最新バージョンをインストールします（ユーザーの理解では、最新とは最も動作するものを意味します）。 私たちは別のアプローチを使用しています - 使用されているものすべてについてリリースノートを調べます mClouds クラウド内 機器を選択し、各機器に適切なファームウェアを慎重に選択します。

彼らが言うように、私たちは経験からこの結論に達しました。 運用例を使用して、ソフトウェアのアップデートと説明を迅速に監視しなければ、ストレージ システムに約束された 99,9999% の信頼性が無意味になる理由を説明します。 どのメーカーのハードウェアでも同様の状況が発生する可能性があるため、今回のケースはどのベンダーのストレージ システムのユーザーにも適しています。

新しいストレージ システムの選択

昨年末、興味深いデータ ストレージ システムが当社のインフラストラクチャに追加されました。これは、IBM FlashSystem 5000 シリーズのジュニア モデルで、購入当時は Storwize V5010e と呼ばれていました。 現在は FlashSystem 5010 という名前で販売されていますが、実際には同じハードウェア ベースで、内部には同じ Spectrum Virtualize が搭載されています。 

ちなみに、IBM FlashSystem の主な違いは、統合管理システムの存在です。 若いシリーズのモデルの場合、より生産性の高いモデルと実質的に変わりはありません。 特定のモデルを選択すると、適切なハードウェア ベースのみが提供され、その特性により、XNUMX つまたは別の機能を使用したり、より高いレベルのスケーラビリティを提供したりできます。 ソフトウェアはハードウェアを識別し、このプラットフォームに必要かつ十分な機能を提供します。

IBMフラッシュシステム5010

モデル 5010 について簡単に説明します。これは、エントリーレベルのデュアルコントローラーブロックストレージシステムです。 NLSAS、SAS、SSD ディスクに対応できます。 このストレージ モデルは、NVMe ドライブのパフォーマンスを必要としない問題を解決するために配置されているため、NVMe の配置は利用できません。

ストレージ システムは、頻繁にアクセスされないアーカイブ情報やデータを収容するために購入されました。 したがって、階層化 (Easy Tier)、シン プロビジョニングといった標準機能セットで十分でした。 NLSAS ディスク上の 1000 ～ 2000 IOPS レベルのパフォーマンスも、私たちにとって非常に満足のいくものでした。

私たちの経験 - ファームウェアを時間通りに更新できなかった経緯

さて、ソフトウェアアップデート自体についてです。 購入時に、システムにはすでに少し古いバージョンの Spectrum Virtualize ソフトウェアがインストールされていました。 8.2.1.3.

私たちはファームウェアの説明を調査し、次のアップデートを計画しました。 8.2.1.9。 私たちがもう少し効率的であれば、この記事は存在しなかったでしょう。より新しいファームウェアではバグは発生しなかったでしょう。 しかし、諸事情により本システムのアップデートは延期となりました。

その結果、リンクの説明にあるように、わずかな更新の遅れにより、非常に不快な画像が表示されました。 https://www.ibm.com/support/pages/node/6172341. 

はい、そのバージョンのファームウェアでは、いわゆる APAR (Authorized Program Analysis Report) HU02104 が関連していました。 次のように表示されます。 負荷がかかると、特定の状況下でキャッシュがオーバーフローし始め、システムは保護モードになり、プールの I/O が無効になります。 この例では、RAID 3 モードの RAID グループの 6 つのディスクが切断されているように見えましたが、切断は 6 分間発生します。 次に、プール内のボリュームへのアクセスが復元されます。

IBM Spectrum Virtualize のコンテキストにおける論理エンティティーの構造と命名についてよく知らない人のために、ここで簡単に説明します。

ストレージシステムの論理要素の構造

ディスクは、MDisk (管理対象ディスク) と呼ばれるグループに集められます。 MDisk は、クラシック RAID (0,1,10,5,6、XNUMX、XNUMX、XNUMX、XNUMX) または仮想化された RAID (分散 RAID) にすることができます。 DRAID を使用すると、アレイのパフォーマンスを向上させることができます。 グループ内のすべてのディスクが使用され、障害が発生したディスクからすべてのデータを復元する必要はなく、特定のブロックのみを復元する必要があるため、再構築時間が短縮されます。

RAID-5 モードで分散 RAID (DRAID) を使用する場合のディスク間でのデータ ブロックの分散。

次の図は、XNUMX つのディスクに障害が発生した場合に DRAID 再構築がどのように機能するかのロジックを示しています。

XNUMX つのディスクに障害が発生した場合の DRAID 再構築のロジック

次に、XNUMX つ以上の MDisk がいわゆるプールを形成します。 同じプール内で、同じタイプのディスク上で異なる RAID/DRAID レベルの MDisk を使用することはお勧めできません。 これについてはあまり深く立ち入りません。なぜなら... これについては、次のいずれかの記事で取り上げる予定です。 実際、プールは複数のボリュームに分割されており、ボリュームは XNUMX つまたは別のブロック アクセス プロトコルを使用してホストに提供されます。

したがって、私たちは、で説明されている状況の結果として、 APAR HU02104XNUMX つのディスクの論理障害により、MDisk が機能しなくなり、その結果、プールと対応するボリュームに障害が発生しました。

これらのシステムは非常にスマートであるため、IBM Storage Insights クラウドベースの監視システムに接続でき、問題が発生した場合、IBM サポートにサービス リクエストが自動的に送信されます。 アプリケーションが作成され、IBM スペシャリストがリモートで診断を実行し、システム ユーザーに連絡します。 

このおかげで、問題は非常に迅速に解決され、サポート サービスから、システムを以前に選択したファームウェア 8.2.1.9 (その時点ではすでに修正されていた) に更新するよう速やかに推奨されました。 確認します 対応するリリースノート.

結果と推奨事項

ことわざにあるように、「終わり良ければすべて良し」です。 ファームウェアのバグは深刻な問題を引き起こさず、サーバーはデータ損失なくできるだけ早く復元されました。 一部のクライアントでは仮想マシンを再起動する必要がありましたが、すべてのインフラストラクチャ要素とクライアント マシンのバックアップを毎日作成しているため、一般的にはさらに悪影響が生じることは覚悟していました。 

99,9999% の可用性が約束された信頼性の高いシステムであっても、注意と適時のメンテナンスが必要であることが確認されました。 状況に基づいて、私たちは独自にいくつかの結論を導き出し、推奨事項を共有します。

• アップデートのリリースを監視し、潜在的に重大な問題の修正についてリリース ノートを検討し、計画されたアップデートを適時に実行することが不可欠です。

  これは組織的な、そして非常に明白な点であり、焦点を当てる価値はないと思われるかもしれません。 しかし、この「平地」では非常につまずきやすくなります。 実はこのとき、上記のようなトラブルが加わりました。 更新規制を作成するときは細心の注意を払い、その遵守状況を注意深く監視してください。 この点は「規律」の概念にさらに関係します。

• システムを常に最新のソフトウェア バージョンに保つことをお勧めします。 しかも現行品のほうが数値指定が大きいものではなく、発売日が遅いものです。 

  たとえば、IBM は、自社のストレージ システムに対して少なくとも 8.2 つのソフトウェア リリースを最新の状態に保っています。 この記事の執筆時点では、これらは 8.3 と 8.2 です。 8.3 のアップデートは以前に公開されます。 XNUMX の同様のアップデートは通常、わずかに遅れてリリースされます。

  リリース 8.3 には、8.3.1 つ以上の新しいディスクを追加して MDisk (DRAID モードで) を拡張できる機能など、機能上の利点が多数あります (この機能はバージョン 8.2 以降に登場しました)。 これはかなり基本的な機能ですが、残念ながら XNUMX にはそのような機能はありません。

• 何らかの理由で更新できない場合、Spectrum Virtualize ソフトウェアのバージョン 8.2.1.9 および 8.3.1.0 より前のバージョン (上記のバグが関連する場合) については、その発生のリスクを軽減するために、IBM テクニカル サポートが推奨します。以下の図に示すように、プール レベルでシステム パフォーマンスを制限します (この図は GUI のロシア語版で撮影したものです)。 10000 IOPS の値は例として示されており、システムの特性に応じて選択されます。

IBM ストレージのパフォーマンスを制限する

• ストレージ システムの負荷を正確に計算し、過負荷を回避する必要があります。 これを行うには、IBM サイザー (アクセスできる場合)、パートナー、またはサードパーティのリソースのいずれかを使用できます。 ストレージ システムの負荷プロファイルを理解することが不可欠です。 MB/秒および IOPS 単位のパフォーマンスは、少なくとも次のパラメータによって大きく異なります。

  • 操作タイプ: 読み取りまたは書き込み、

  • 演算ブロックサイズ、

  • 合計 I/O ストリームにおける読み取りおよび書き込み操作の割合。

  また、操作の速度は、データ ブロックの読み取り方法 (順次またはランダムな順序) によっても影響されます。 アプリケーション側で複数のデータ アクセス操作を実行する場合、依存操作の概念があります。 これも考慮に入れることをお勧めします。 これらすべては、OS、ストレージ システム、サーバー/ハイパーバイザーのパフォーマンス カウンターからのデータの全体を確認するだけでなく、アプリケーション、DBMS、およびディスク リソースのその他の「消費者」の動作機能を理解するのにも役立ちます。

• 最後に、バックアップが最新で動作していることを確認してください。 バックアップ スケジュールは、ビジネスにとって許容可能な RPO 値に基づいて構成する必要があり、許容可能な RTO 値を確保するために、バックアップの定期的な整合性チェックを検証する必要があります (かなりの数のバックアップ ソフトウェア ベンダーが製品に自動検証を実装しています)。

最後まで読んでいただきありがとうございます。
コメントでのご質問やご意見にお答えいたします。 また 私たちの電報チャンネルに登録することをお勧めしますでは、定期的なプロモーション (IaaS の割引と VPS の最大 100% のプロモーション コードのプレゼント) を開催し、興味深いニュースを執筆し、Habr ブログで新しい記事を発表します。

出所： habr.com