AERODISKエンジン：耐災害性。 パート 2. メトロクラスター

Habr読者の皆さん、こんにちは！ 前回の記事では、AERODISK ENGINE ストレージ システムにおける災害復旧の簡単な手段であるレプリケーションについて説明しました。 この記事では、より複雑で興味深いトピックであるメトロクラスターについて詳しく説明します。メトロクラスターとは、データセンターがアクティブ/アクティブモードで動作できるようにする、XNUMX つのデータセンターの自動災害保護手段です。 私たちはあなたに教え、見せ、壊し、直します。

いつものように理論​​が先

メトロクラスターは、都市または地域内の複数のサイトにまたがるクラスターです。 「クラスター」という言葉は、この複合体が自動化されていること、つまり、障害が発生した場合のクラスター ノードの切り替えが自動的に行われていることを明確に示唆しています。

ここが、メトロクラスターと通常のレプリケーションの主な違いです。 運用の自動化。 つまり、特定のインシデント（データセンターの障害、チャネルの破損など）が発生した場合、ストレージ システムはデータの可用性を維持するために必要なアクションを独立して実行します。 通常のレプリカを使用する場合、これらのアクションは管理者によって全部または部分的に手動で実行されます。

それは何のためにあるの？

特定のメトロクラスター実装を使用するときにお客様が追求する主な目標は、RTO (目標復旧時間) を最小限に抑えることです。 つまり、障害後の IT サービスの復旧時間を最小限に抑えるためです。 通常のレプリケーションを使用する場合、回復時間は常にメトロクラスターによる回復時間よりも長くなります。 なぜ？ とてもシンプルです。 管理者はデスクにいて、レプリケーションを手動で切り替える必要があります。これはメトロクラスタによって自動的に行われます。

眠らず、食べず、喫煙せず、病気にもならず、ストレージ システムの状態を 24 時間監視する専任の管理者がいない場合、管理者が適切な管理を行うことを保証する方法はありません。障害発生時に手動切り替えが可能です。

したがって、メトロクラスタまたは管理者義務サービスの 99 レベルの不滅の管理者が存在しない場合の RTO は、すべてのシステムの切り替え時間と、管理者が作業を開始することが保証されるまでの最大時間の合計に等しくなります。ストレージ システムと関連システム。

したがって、RTO の要件が数時間や数日ではなく数分である場合、つまり最悪のデータセンター障害が発生した場合に IT 部門がビジネスに時間を提供する必要がある場合には、メトロクラスターを使用する必要があるという明白な結論に達しました。 IT サービスへのアクセスを数分、場合によっては数秒以内に復元します。

それはどのように動作しますか？

下位レベルでは、メトロクラスタは、前の記事で説明した同期データ レプリケーションのメカニズムを使用します (「 リンク）。 レプリケーションは同期であるため、レプリケーションの要件は一致しています。つまり、次のとおりです。

• 物理としての光ファイバー、10 ギガビット イーサネット (またはそれ以上)。
• データセンター間の距離は 40 キロメートル以内です。
• データセンター間 (ストレージ システム間) の光チャネル遅延は最大 5 ミリ秒 (最適には 2 ミリ秒) です。

これらすべての要件は本質的に勧告的なものです。つまり、これらの要件が満たされていない場合でもメトロクラスタは動作しますが、これらの要件に準拠しない場合の結果は、両方のストレージ システムの動作の低下と同等であることを理解する必要があります。メトロクラスター。

では、同期レプリカはストレージ システム間でデータを転送するために使用されますが、レプリカはどのように自動的に切り替わるのか、そして最も重要なことに、スプリット ブレインを回避するにはどうすればよいのでしょうか? これを行うには、より高いレベルで追加のエンティティ、つまりアービターが使用されます。

仲裁人はどのように働き、その任務は何ですか?

アービターは、XNUMX 番目のサイト (オフィスなど) で起動し、ICMP および SSH 経由でストレージ システムへのアクセスを提供する必要がある小さな仮想マシンまたはハードウェア クラスターです。 起動後、アービターは IP を設定し、ストレージ側からそのアドレスと、メトロクラスターに参加するリモート コントローラーのアドレスを指定する必要があります。 この後、審判は準備が整います。

アービタは、メトロクラスタ内のすべてのストレージ システムを常に監視し、特定のストレージ システムが利用できない場合は、クラスタの別のメンバー (「ライブ」ストレージ システムの XNUMX つ) から利用できないことを確認した後、レプリケーション ルールを切り替える手順を開始することを決定します。そしてマッピング。

非常に重要な点です。 アービトレータは常に、ストレージ システムが設置されているサイトとは異なるサイト、つまり、ストレージ システム 1 が設置されているデータ センター 1 にも、ストレージ システム 2 が設置されているデータ センター 2 にも設置されていない必要があります。

なぜ？ これは、生き残っているストレージ システムの XNUMX つの助けを借りて、調停者がストレージ システムが設置されている XNUMX つのサイトのいずれかの陥落を明確かつ正確に判断できる唯一の方法であるためです。 他の方法でアービターを配置すると、スプリット ブレインが発生する可能性があります。

それでは、仲裁人の仕事の詳細を見ていきましょう。

アービターは、すべてのストレージ コントローラーを常にポーリングするいくつかのサービスを実行します。 ポーリング結果が以前の結果と異なる場合 (利用可能/利用不可)、その結果は小さなデータベースに記録され、アービターでも機能します。

仲裁人の仕事のロジックをさらに詳しく見てみましょう。

ステップ 1: 利用できないかどうかを判断します。 ストレージ システムの障害イベントとは、同じストレージ システムの両方のコントローラから 5 秒以内に ping が受信されないことです。

ステップ 2. 切り替え手順を開始します。 アービタは、ストレージ システムの XNUMX つが使用できないことに気づいた後、「デッド」ストレージ システムが本当に停止しているかどうかを確認するために、「ライブ」ストレージ システムにリクエストを送信します。

アービターからそのようなコマンドを受信した後、XNUMX 番目の (ライブ) ストレージ システムは、障害が発生した最初のストレージ システムの可用性をさらにチェックし、存在しない場合は、アービターに推測の確認を送信します。 ストレージ システムは実際に使用できません。

このような確認を受信した後、アービターは、レプリケーションを切り替え、障害が発生したストレージ システム上でアクティブ (プライマリ) だったレプリカのマッピングを引き上げるリモート手順を起動し、コマンドを XNUMX 番目のストレージ システムに送信して、これらのレプリカをセカンダリからプライマリに変更します。マッピングを上げます。 したがって、XNUMX 番目のストレージ システムはこれらの手順を実行し、失われた LUN へのアクセスをそれ自体から提供します。

なぜ追加の検証が必要なのでしょうか? 定足数のため。 つまり、合計奇数 (3) 個のクラスター メンバーの大部分がクラスター ノードの XNUMX つのダウンを確認する必要があります。 そうして初めて、この決定は間違いなく正しいことになります。 これは、誤った切り替え、ひいてはスプリット ブレインを回避するために必要です。

時間ステップ 2 には約 5 ～ 10 秒かかります。したがって、可用性がないと判断するのに必要な時間 (5 秒) を考慮すると、事故後 10 ～ 15 秒以内に、障害が発生したストレージ システムの LUN が自動的に使用可能になり、ライブ システムで動作できるようになります。ストレージシステム。

ホストとの接続が失われないようにするには、ホスト上でタイムアウトを正しく構成するように注意する必要があることは明らかです。 推奨されるタイムアウトは少なくとも 30 秒です。 これにより、災害発生時の負荷切り替え中にホストがストレージ システムへの接続を切断するのを防ぎ、I/O の中断を確実になくすことができます。

ちょっと待ってください。メトロクラスタですべてがうまくいっているのであれば、なぜ定期的なレプリケーションが必要なのでしょうか?

実際には、すべてがそれほど単純ではありません。

メトロクラスターの長所と短所を考えてみましょう

したがって、従来のレプリケーションと比較したメトロクラスターの明らかな利点は次のとおりであることがわかりました。

• 完全自動化により、災害発生時の復旧時間を最小限に抑えます。
• それだけです ：-）。

さて、注意してください、短所:

• ソリューションのコスト。 Aerodisk システムのメトロクラスターには追加のライセンスは必要ありません (レプリカと同じライセンスが使用されます) が、ソリューションのコストは同期レプリケーションを使用する場合よりもさらに高くなります。 同期レプリカのすべての要件に加え、追加のスイッチングと追加サイトに関連するメトロクラスターの要件も実装する必要があります (メトロクラスターの計画を参照)。
• ソリューションの複雑さ。 メトロクラスターは通常のレプリカよりもはるかに複雑で、計画、構成、文書化に多くの注意と労力を必要とします。

やがて。 Metrocluster は確かに、数秒または数分で RTO を提供する必要がある場合、非常に技術的に高度で優れたソリューションです。 しかし、そのようなタスクがなく、数時間の RTO がビジネス上問題ないのであれば、大砲でスズメを撃つ意味はありません。 メトロ クラスタでは追加コストが発生し、IT インフラストラクチャが複雑になるため、通常の労働者と農民のレプリケーションで十分です。

メトロクラスターの計画

このセクションは、メトロクラスタ設計の包括的なガイドであるとは主張しませんが、そのようなシステムを構築する場合に検討すべき主な方向性を示すだけです。 したがって、実際にメトロクラスタを導入する際には、必ずストレージシステムメーカー（つまり当社）および関連システムを巻き込んでご相談ください。

会場

前述したように、メトロクラスターには少なくとも XNUMX つのサイトが必要です。 ストレージ システムと関連システムが動作する XNUMX つのデータ センターと、仲裁人が動作する XNUMX 番目のサイト。

データセンター間の推奨距離は 40 キロメートル以内です。 距離が長くなると追加の遅延が発生する可能性が高く、メトロクラスターの場合、これは非常に望ましくないことです。 遅延は 5 ミリ秒以内に抑えることをお勧めしますが、遅延は最大 2 ミリ秒である必要があることに注意してください。

計画プロセス中にも遅延を確認することをお勧めします。 データセンター間に光ファイバーを提供する多かれ少なかれ成熟したプロバイダーは、品質チェックを非常に迅速に組織できます。

仲裁者までの遅延 (つまり、200 番目のサイトと最初の XNUMX つのサイトの間) については、推奨される遅延しきい値は最大 XNUMX ミリ秒です。つまり、インターネット上の通常の企業 VPN 接続が適切です。

スイッチングとネットワーキング

異なるサイトからストレージ システムを接続するだけで十分なレプリケーション スキームとは異なり、メトロクラスタ スキームでは、異なるサイトにある両方のストレージ システムにホストを接続する必要があります。 違いを明確にするために、両方のスキームを以下に示します。

この図からわかるように、サイト 1 のホストはストレージ システム 1 とストレージ システム 2 の両方を調べます。また、逆に、サイト 2 のホストはストレージ システム 2 とストレージ システム 1 の両方を調べます。 つまり、各ホストは両方のストレージ システムを認識します。 これは、メトロクラスタの動作の前提条件です。

もちろん、各ホストを光コードで別のデータセンターに接続する必要はなく、ポートやコードがあれば十分です。 これらの接続はすべて、イーサネット 10G+ またはファイバーチャネル 8G+ スイッチを介して行う必要があります (FC は IO 用にホストとストレージ システムを接続するためのみであり、レプリケーション チャネルは現在 IP (イーサネット 10G+) 経由でのみ利用可能です)。

次に、ネットワーク トポロジについて少し説明します。 重要な点は、サブネットを正しく構成することです。 次のタイプのトラフィックに対して複数のサブネットをただちに定義する必要があります。

• ストレージ システム間でデータが同期されるレプリケーション サブネット。 それらはいくつかある可能性がありますが、この場合は問題ではありません。すべては現在の (すでに実装されている) ネットワーク トポロジに依存します。 それらが XNUMX つある場合は、明らかにそれらの間でルーティングを構成する必要があります。
• ホストがストレージ リソースにアクセスする際に経由するストレージ サブネット (iSCSI の場合)。 各データセンターにはそのようなサブネットが XNUMX つ存在する必要があります。
• 制御サブネット、つまり、ストレージ システムが管理される XNUMX つのサイト上の XNUMX つのルーティング可能なサブネット。アービタもそこに配置されます。

サブネットはタスクに大きく依存しているため、ここではホスト リソースにアクセスするためのサブネットは考慮しません。

さまざまなトラフィックをさまざまなサブネットに分離することは非常に重要です (レプリカを I/O から分離することが特に重要です)。すべてのトラフィックを XNUMX つの「厚い」サブネットに混在させると、このトラフィックを管理できなくなります。 XNUMX つのデータセンターの状況によっては、依然として異なるネットワーク衝突オプションが発生する可能性があります。 データ センター間に張り巡らされたネットワークの計画については、ネットワーク機器メーカーのリソースで詳しく説明されているので、この記事の枠内ではこの問題については深く掘り下げません。

アービター構成

アービタは、ICMP および SSH プロトコルを介してストレージ システムのすべての管理インターフェイスへのアクセスを提供する必要があります。 アービターのフェイルセーフについても考慮する必要があります。 ここにはニュアンスがあります。

アービタ フェイルオーバーは非常に望ましいものですが、必須ではありません。 審判が間違ったタイミングでクラッシュしたらどうなるでしょうか？

• 通常モードでのメトロクラスタの動作は変わりません。 arbtir は、通常モードのメトロクラスターの動作にはまったく影響しません (そのタスクは、データセンター間で負荷をタイムリーに切り替えることです)。
• さらに、アービターが何らかの理由で倒れ、データセンター内の事故で「居眠り」した場合、必要な切り替えコマンドを与えてクォーラムを組織する人がいないため、切り替えは行われません。 この場合、メトロクラスタはレプリケーションを備えた通常のスキームに変わり、災害時には手動で切り替える必要があり、RTO に影響します。

これから何が起こるでしょうか？ 本当に最小限の RTO を保証する必要がある場合は、アービターがフォールト トレラントであることを確認する必要があります。 これには XNUMX つのオプションがあります。

• フォールト トレラント ハイパーバイザー上のアービターを使用して仮想マシンを起動します。幸いなことに、すべての成人向けハイパーバイザーはフォールト トレラントをサポートしています。
• 2 番目のサイト (従来のオフィス) で通常のクラスターをインストールするのが面倒で、既存の hypervozor クラスターがない場合は、ハードウェア バージョンのアービターが提供されています。 x-86 サーバーは動作し、ローカル障害が発生しても存続できます。

メトロクラスタが通常モードではアービターを必要としないにもかかわらず、アービターのフォールト トレランスを確保することを強くお勧めします。 しかし、理論と実践の両方が示しているように、本当に信頼性の高い災害に強いインフラストラクチャを構築する場合は、安全策を講じたほうがよいでしょう。 「卑劣の法則」、つまり、仲裁者とストレージ システムが配置されているサイトの XNUMX つの両方の失敗から自分自身とビジネスを守る方が賢明です。

ソリューションアーキテクチャ

上記の要件を考慮すると、次の一般的なソリューション アーキテクチャが得られます。

深刻な過負荷を避けるために、LUN は XNUMX つのサイトに均等に分散される必要があります。 同時に、両方のデータセンターのサイジングを行う際には、ボリュームを XNUMX 倍にする (XNUMX つのストレージ システムにデータを同時に保存するために必要) だけでなく、アプリケーションのパフォーマンスの低下を防ぐために IOPS と MB/秒のパフォーマンスも XNUMX 倍にする必要があります。データセンターの XNUMX つで障害が発生した場合。 ov.

これとは別に、サイジングに対する適切なアプローチ (つまり、IOPS と MB/秒の適切な上限、および必要な CPU および RAM リソースを提供している場合) を使用すると、ストレージ システムの XNUMX つがメトロ クラスタに障害が発生しても、XNUMX つのストレージ システムで一時的に作業を行っている状況では、パフォーマンスが大幅に低下することはありません。

これは、1 つのサイトが同時に動作している場合、各トランザクションを 10 つのストレージ システムに書き込む必要があるため (RAID-XNUMX/XNUMX と同様)、同期レプリケーションが書き込みパフォーマンスの半分を「消費」するという事実によって説明されます。 したがって、ストレージ システムの XNUMX つが故障した場合、レプリケーションの影響は一時的に (故障したストレージ システムが回復するまで) なくなり、書き込みパフォーマンスが XNUMX 倍に向上します。 障害が発生したストレージ システムの LUN が動作中のストレージ システム上で再起動されると、他のストレージ システムの LUN から負荷が発生するため、この XNUMX 倍の増加は解消され、障害が発生する前と同じレベルのパフォーマンスに戻ります。 「落ちる」が、それは XNUMX つのサイトの枠組み内でのみです。

適切なサイジングを利用することで、ユーザーがストレージ システム全体の障害をまったく感じない状況を確保できます。 ただし、もう一度繰り返しますが、これには非常に慎重なサイジングが必要です。ちなみに、そのことについては無料でお問い合わせいただけます :-)。

メトロクラスターのセットアップ

メトロクラスターのセットアップは、で説明した通常のレプリケーションのセットアップと非常に似ています。 前の記事。 したがって、違いだけに注目してみましょう。 上記のアーキテクチャに基づいて、最小限のバージョンのみでラボ内にベンチをセットアップしました。10G イーサネット経由で接続された 10 台のストレージ システム、10 台の XNUMXG スイッチ、および XNUMXG ポートを備えた両方のストレージ システムのスイッチを介して監視する XNUMX 台のホストです。 アービターは仮想マシン上で実行されます。

レプリカの仮想 IP (VIP) を構成する場合は、メトロクラスターの VIP タイプを選択する必要があります。

1 つの LUN に対して 2 つのレプリケーション リンクを作成し、それらを 2 つのストレージ システムに分散しました。ストレージ システム 2 の LUN TEST プライマリ (METRO リンク)、ストレージ システム XNUMX の LUN TESTXNUMX プライマリ (METROXNUMX リンク)。

これらに対して、XNUMX つの同一のターゲットを構成しました (この場合は iSCSI ですが、FC もサポートされており、セットアップ ロジックは同じです)。

ストレージシステム1:

ストレージシステム2:

レプリケーション接続の場合、各ストレージ システム上でマッピングが作成されました。

ストレージシステム1:

ストレージシステム2:

マルチパスを設定し、ホストに提示しました。

仲裁人の設置

アービター自体で特別なことをする必要はなく、XNUMX 番目のサイトでアービターを有効にし、IP を与え、ICMP と SSH 経由でのアクセスを設定するだけです。 セットアップ自体はストレージ システム自体から実行されます。 この場合、メトロクラスター内のいずれかのストレージ コントローラーでアービターを XNUMX 回構成するだけで十分であり、これらの設定はすべてのコントローラーに自動的に配布されます。

[リモート レプリケーション] >> [メトロクラスター (任意のコントローラー上)] >> [構成] ボタンのセクションにあります。

アービタの IP と XNUMX つのリモート ストレージ コントローラの制御インターフェイスを入力します。

この後、すべてのサービスを有効にする必要があります (「すべて再起動」ボタン)。 将来再構成する場合、設定を有効にするためにサービスを再起動する必要があります。

すべてのサービスが実行されていることを確認します。

これでメトロクラスターのセットアップは完了です。

衝突試験

レプリケーション機能 (切り替え、整合性など) については「 前の記事。 したがって、メトロクラスタの信頼性をテストするには、障害検出、切り替えの自動化、記録損失 (I/O 停止) がないことを確認するだけで十分です。

これを行うには、両方のコントローラの電源を物理的にオフにすることで、一方のストレージ システムの完全な障害をエミュレートし、最初に大きなファイルの LUN へのコピーを開始します。この LUN は、もう一方のストレージ システムでアクティブ化する必要があります。

XNUMX つのストレージ システムを無効にします。 XNUMX 番目のストレージ システムでは、隣接システムとの接続が失われたことを示すアラートとメッセージがログに表示されます。 SMTP または SNMP 監視による通知が設定されている場合、管理者は対応する通知を受け取ります。

ちょうど 10 秒後 (両方のスクリーンショットに表示されます)、METRO レプリケーション接続 (障害が発生したストレージ システムでプライマリであった接続) が、動作中のストレージ システムで自動的にプライマリになりました。 既存のマッピングを使用すると、ホストは LUN TEST を引き続き利用でき、記録は少し (約束の 10% 以内に) 低下しましたが、中断されませんでした。

テストは正常に完了しました。

要約

現在の AERODISK Engine N シリーズ ストレージ システムへのメトロクラスターの実装により、IT サービスのダウンタイムを排除または最小限に抑え、最小限の人件費で 24 時間 7 日の稼働を確保する必要がある問題を解決することが完全に可能になります。

もちろん、これはすべて理論であり、実験室の理想的な条件などであると言えます...しかし、災害耐性機能を実装したプロジェクトが多数実施されており、システムは完璧に機能しています。 災害に強い構成で XNUMX つのストレージ システムだけを使用している非常に有名な顧客の XNUMX つが、すでにプロジェクトに関する情報を公開することに同意しているため、次のパートでは実戦実装について説明します。

ありがとうございます。生産的な議論を楽しみにしています。

出所： habr.com