Shared Nothing アーキテクチャでダウンタイムのリスクを軽減

データ ストレージ システムのフォールト トレランスのトピックは常に関連性があります。これは、仮想化とリソースの統合が広範に行われている現代において、ストレージ システムはその障害が通常の事故だけでなく、サービスの長期的なダウンタイムにつながるリンクであるためです。 したがって、最新のストレージ システムには、重複したコンポーネント (コントローラーも含む) が多数含まれています。 しかし、そのような保護は十分でしょうか?

間違いなくすべてのベンダーは、ストレージ システムの特性を列挙する際に、自社のソリューションの高い耐障害性について常に言及し、必ず「単一障害点がない」という用語を追加します。 典型的なストレージ システムを詳しく見てみましょう。 メンテナンス時のダウンタイムを回避するために、ストレージ システムは電源、冷却モジュール、入出力ポート、ドライブ (RAID のこと)、そしてもちろんコントローラーを二重化します。 このアーキテクチャを詳しく見ると、少なくとも XNUMX つの潜在的な障害点があることに気づきますが、それらは控えめに隠されています。

1. 単一のバックプレーンの可用性
2. データのコピーが XNUMX つあること

バックプレーンは技術的に複雑なデバイスであり、製造中に厳しいテストを受ける必要があります。 したがって、完全に失敗する場合が非常にまれにあります。 ただし、ドライブ スロットが機能しないなど、部分的な問題が発生した場合でも、ストレージ システムを完全にシャットダウンして交換する必要があります。

データのコピーを複数作成することも、一見すると問題ありません。 たとえば、一定の間隔でデータの完全なコピーを更新できるストレージ システムのクローン機能は、非常に普及しています。 ただし、同じバックプレイで問題が発生した場合、コピーはオリジナルと同様に使用できなくなります。

これらの欠点を克服する完全に明白な解決策は、別のストレージ システムへのレプリケーションです。 予想されるハードウェアのコストが XNUMX 倍になることに目をつぶったとしても (そのような決定を選択する人は十分に検討し、この事実を事前に受け入れていると依然として想定しています)、ライセンスの形でレプリケーションを組織するためのコストが依然として発生する可能性があります。ソフトウェアとハ​​ードウェア。 そして最も重要なことは、レプリケートされたデータの一貫性を何らかの方法で確保する必要があるということです。 それらの。 ストレージ バーチャライザー/vSAN などを構築しますが、これにもお金と時間のリソースが必要です。

アクセルストア 高可用性システムを作成するとき、私たちは上記の欠点を取り除くという目標を設定しました。 このようにして、Shared Nothing テクノロジーの解釈が登場しました。Shared Nothing テクノロジーは、大まかに翻訳すると「共有デバイスを使用しない」という意味です。

コンセプト 何も共有されていない このアーキテクチャは、それぞれが独自のデータ セットを持つ 56 つの独立したノード (コントローラー) の使用を表します。 同期レプリケーションは、InfiniBand XNUMXG インターフェイスを介してノード間で行われ、ストレージ システム上で実行されているソフトウェアに対して完全に透過的です。 その結果、ストレージバーチャライザーやソフトウェアエージェントなどを使用する必要がなくなりました。

物理的には、AccelStor の XNUMX ノード ソリューションは XNUMX つのモデルで実装できます。

• H510 — 中程度のパフォーマンスと最大 2TB の容量が必要な場合は、22U ケースのツイン サーバーに基づいています。
• H710 — 高性能と大容量 (最大 2TB) が必要な場合は、個々の 57U サーバーに基づいています。

ツインサーバーをベースにしたモデル H510

個々のサーバーに基づくモデル H710

さまざまなフォームファクターが使用されるのは、所定のボリュームとパフォーマンスを達成するにはさまざまな数の SSD が必要になるためです。 さらに、Twin プラットフォームはより安価で、単一のバックプレーンという条件付きの「欠点」はありますが、より手頃なソリューションを提供できます。 動作原理を含め、その他すべては両モデルで完全に同一です。

各ノードのデータセットには XNUMX つのグループがあります フレキシリマップ、さらに 2 つのホット スペア。 各グループは XNUMX 台の SSD の障害に耐えることができます。 に従ってノードを記録するためのすべての受信リクエスト イデオロギー FlexiRemap は 4KB ブロックをシーケンシャル チェーンに再構築し、最も快適なモード (シーケンシャル レコーディング) で SSD に書き込みます。 さらに、ホストは、データが SSD に物理的に配置された後でのみ記録確認を受け取ります。 RAM にキャッシュせずに。 その結果、最大 600K IOPS 書き込みおよび 1M+ IOPS 読み取り (モデル H710) という非常に優れたパフォーマンスが得られます。

前述したように、データ セットは、高スループットと低遅延の InfiniBand 56G インターフェイスを介してリアルタイムで同期されます。 小さなパケットを送信するときに通信チャネルを最も効率的に使用するため。 なぜなら通信チャネルは 1 つだけあり、追加の心拍数チェックには専用の XNUMXGbE リンクが使用されます。 心拍のみを伝達するため、速度特性の要求はありません。

システム容量を増加する場合 (最大 400+TB) 拡張シェルフ また、「単一障害点がない」という概念を維持するために、ペアで接続されています。

(AccelStor にはすでに XNUMX つのコピーがあるという事実に加えて) 追加のデータ保護のため、SSD に障害が発生した場合には特別な動作アルゴリズムが使用されます。 SSD に障害が発生すると、ノードはホット スペア ドライブの XNUMX つにデータの再構築を開始します。 FlexiRemap グループは劣化状態にあり、読み取り専用モードに切り替わります。 これは、バックアップ ディスク上での書き込み操作と再構築操作の間の干渉を排除するために行われ、最終的には回復プロセスが高速化され、システムが潜在的に脆弱になる時間を短縮します。 再構築が完了すると、ノードは通常の読み取り/書き込みモードに戻ります。

もちろん、他のシステムと同様に、再構築中は全体的なパフォーマンスが低下します (結局のところ、FlexiRemap グループの XNUMX つが記録には機能しません)。 ただし、回復プロセス自体は可能な限り迅速に行われるため、AccelStor システムが他のベンダーのソリューションと区別されます。

Nothing Shared アーキテクチャ テクノロジのもう XNUMX つの便利な特性は、いわゆる真のアクティブ/アクティブ モードでのノードの動作です。 システム内で XNUMX つのコントローラーだけが特定のボリューム/プールを所有し、XNUMX 番目のコントローラーが単純に I/O 操作を実行する「古典的な」アーキテクチャとは異なります。 アクセルストア 各ノードは独自のデータセットを処理し、その「隣接ノード」にリクエストを送信しません。 その結果、ノードによる I/O 要求とドライブへのアクセスの並列処理により、システム全体のパフォーマンスが向上します。 また、障害が発生した場合にボリュームの制御を別のノードに移す必要がないため、フェイルオーバーなどは事実上ありません。

Nothing Shared アーキテクチャ技術を本格的なストレージ システムの二重化と比較すると、一見したところ、ディザスタ リカバリの完全実装に比べて柔軟性が若干劣ります。 これは、ストレージ システム間の通信回線を構成する場合に特に当てはまります。 したがって、H710 モデルでは、それほど安価ではない InfiniBand アクティブ光ケーブルを使用して、ノードを最大 100 m の距離に分散することができます。 しかし、たとえ長距離であっても、利用可能なファイバーチャネルを介した他のベンダーによる同期レプリケーションの通常の実装と比較した場合でも、AccelStor のソリューションはより安価で、インストール/運用が容易です。 ストレージバーチャライザーをインストールしたり、ソフトウェアと統合したりする必要はありません (原理的に常に可能であるとは限りません)。 さらに、AccelStor ソリューションは、SSD のみを搭載した「クラシック」ストレージ システムよりも高いパフォーマンスを備えたオール フラッシュ アレイであることを忘れないでください。

AccelStor の Nothing Shared アーキテクチャを使用すると、非常にリーズナブルなコストで 99.9999% のストレージ システムの可用性を実現できます。 データの XNUMX つのコピーの使用などによるソリューションの高い信頼性と、独自のアルゴリズムによる優れたパフォーマンスに加えて、 フレキシリマップ、からのソリューション アクセルストア 最新のデータセンターを構築する際の重要なポジションに最適な候補者です。

出所： habr.com