AERODISKエンジン：耐災害性。 パート1

Habr読者の皆さん、こんにちは！ この記事のトピックは、AERODISK Engine ストレージ システムへのディザスタ リカバリ ツールの実装です。 当初は、レプリケーションとメトロクラスターの両方のツールについて XNUMX つの記事で書こうと考えていましたが、残念ながら記事が長すぎることが判明したため、記事を XNUMX つの部分に分割しました。 単純なものから複雑なものへ進みましょう。 この記事では、同期レプリケーションをセットアップしてテストします。XNUMX つのデータセンターを削除し、データセンター間の通信チャネルも切断して、何が起こるかを確認します。

お客様からは、レプリケーションに関するさまざまな質問がよく寄せられます。そのため、レプリカの設定と実装のテストに進む前に、ストレージにおけるレプリケーションとは何かについて少し説明します。

いくつかの説

ストレージ システムのレプリケーションは、複数のストレージ システム上でデータの同一性を同時に確保する継続的なプロセスです。 技術的には、レプリケーションは XNUMX つの方法で実行されます。

同期レプリケーション – これは、メイン ストレージ システムからバックアップ システムにデータをコピーし、その後、データが記録および確認されたことを両方のストレージ システムから強制的に確認します。 データが記録されていると見なされ、操作できるかどうかは、両側 (両方のストレージ システム) で確認された後です。 これにより、レプリカに参加しているすべてのストレージ システム上でデータの同一性が保証されます。

この方法の利点:

• データはすべてのストレージ システムで常に同一です

短所：

• ソリューションのコストが高い (高速通信チャネル、高価な光ファイバー、長波トランシーバーなど)
• 距離制限（数十km以内）
• 論理データの破損に対する保護はありません (メイン ストレージ システムでデータが (意図的または偶然に) 破損した場合、データは常に同一であるため、自動的かつ即座にバックアップ システムでも破損します (これが矛盾しています)。

非同期レプリケーション – これもメイン ストレージ システムからバックアップ システムにデータをコピーしますが、一定の遅延が発生し、反対側での書き込みを確認する必要はありません。 データはメイン ストレージ システムに記録した後すぐに操作でき、バックアップ ストレージ システムではしばらくしてからデータが利用可能になります。 もちろん、この場合のデータの同一性はまったく保証されません。 バックアップ ストレージ システム上のデータは常に少し「過去」になっています。

非同期レプリケーションの長所:

• 低コストのソリューション (あらゆる通信チャネル、光学系はオプション)
• 距離制限なし
• バックアップ ストレージ システムでは、メイン ストレージ システムでデータが破損しても (少なくともしばらくは) 劣化しません。データが破損した場合は、いつでもレプリカを停止して、バックアップ ストレージ システムでのデータ破損を防ぐことができます。

短所：

• 異なるデータセンターにあるデータは常に同一ではありません

したがって、レプリケーション モードの選択はビジネス目標によって異なります。 バックアップ データ センターにメイン データ センターとまったく同じデータが含まれることが重要である場合 (つまり、RPO = 0 のビジネス要件)、現金を出金して同期データ センターの制限に耐える必要があります。レプリカ。 データ状態の遅延が許容できる場合、または単にお金がない場合は、必ず非同期メソッドを使用する必要があります。

また、メトロクラスタなどのモード (より正確にはトポロジ) を個別に強調表示してみましょう。 メトロクラスター モードでは同期レプリケーションが使用されますが、通常のレプリカとは異なり、メトロクラスターでは両方のストレージ システムがアクティブ モードで動作できます。 それらの。 アクティブ データ センターとスタンバイ データ センターを分離することはできません。 アプリケーションは、物理的に異なるデータセンターにある XNUMX つのストレージ システムと同時に動作します。 このようなトポロジでの事故時のダウンタイムは非常に短くなります (RTO、通常は数分)。 この記事では、メトロクラスタの実装については考慮しません。これは非常に大規模で膨大なトピックであるため、この記事の続きとして別の次の記事で取り上げます。

また、ストレージ システムを使用したレプリケーションについて話すと、多くの人が当然の質問をします。 > 「多くのアプリケーションには独自のレプリケーション ツールがあるのに、なぜストレージ システムでレプリケーションを使用するのでしょうか?」 良いのか悪いのか？

ここには明確な答えはないので、引数 FOR と CONS を次に示します。

ストレージ レプリケーションの引数:

• ソリューションのシンプルさ。 2 つのツールを使用すると、負荷の種類やアプリケーションに関係なく、データ セット全体をレプリケートできます。 アプリケーションのレプリカを使用する場合は、各アプリケーションを個別に構成する必要があります。 それらが XNUMX つ以上ある場合、これは非常に労力と費用がかかります (アプリケーションのレプリケーションには、通常、アプリケーションごとに無料ではない個別のライセンスが必要です。ただし、これについては以下で詳しく説明します)。
• あらゆるアプリケーション、あらゆるデータをレプリケートでき、常に一貫性が保たれます。 多くの（ほとんどの）アプリケーションにはレプリケーション機能がなく、ストレージ システムからのレプリカが災害から保護する唯一の方法です。
• アプリケーションのレプリケーション機能に過剰な料金を支払う必要はありません。 一般に、ストレージ システムのレプリカのライセンスと同様、安価ではありません。 ただし、ストレージ レプリケーションのライセンスは XNUMX 回支払う必要があり、アプリケーション レプリカのライセンスはアプリケーションごとに個別に購入する必要があります。 このようなアプリケーションが多数ある場合、かなりの費用がかかり、ストレージ レプリケーションのライセンスのコストは大海の一滴になります。

ストレージ レプリケーションに反対する引数:

• アプリケーションを介したレプリカには、アプリケーション自体の観点からより多くの機能があり、アプリケーションはそのデータを (当然のことながら) よりよく知っているため、アプリケーションを操作するためのオプションが増えます。
• 一部のアプリケーションの製造元は、サードパーティのツールを使用してレプリケーションが行われた場合、データの一貫性を保証しません。 *

* - 物議を醸す論文。 たとえば、有名な DBMS メーカーは、自社の DBMS は自社の手段を使用して通常どおりに複製することしかできず、残りの複製 (ストレージ システムを含む) は「真実ではない」と、非常に長い間公式に宣言してきました。 しかし、人生はそうではないことを示しています。 おそらく (ただし確実ではありませんが)、これは顧客により多くのライセンスを販売するという最も誠実な試みではありません。

その結果、ほとんどの場合、ストレージ システムからのレプリケーションの方が優れています。 これはよりシンプルで安価なオプションですが、特定のアプリケーション機能が必要な場合や、アプリケーション レベルのレプリケーションを使用する必要がある複雑なケースもあります。

理論は終わりました、次は実践してください

ラボでレプリカを構成します。 実験室条件では、2 つのデータセンター (実際には、別の建物内にあるように見える 2016 つの隣接するラック) をエミュレートしました。 スタンドは、光ケーブルで相互に接続された 10 つの Engine NXNUMX ストレージ システムで構成されています。 Windows Server XNUMX を実行している物理サーバーは、XNUMXGb イーサネットを使用して両方のストレージ システムに接続されています。 非常にシンプルなスタンドですが、本質は変わりません。

概略的には次のようになります。

論理的には、レプリケーションは次のように構成されます。

次に、現在のレプリケーション機能を見てみましょう。
非同期と同期の 10 つのモードがサポートされています。 同期モードが距離と通信チャネルによって制限されるのは当然です。 特に、同期モードでは、物理的なものとしてファイバーを使用し、XNUMX ギガビット イーサネット (またはそれ以上) を使用する必要があります。

同期レプリケーションでサポートされる距離は 40 キロメートル、データセンター間の光チャネルの遅​​延値は最大 2 ミリ秒です。 一般に、遅延が大きくても機能しますが、記録中に大幅な速度低下が発生するため (これは当然のことです)、データセンター間の同期レプリケーションを計画している場合は、光学系の品質と遅延を確認する必要があります。

非同期レプリケーションの要件はそれほど深刻ではありません。 より正確に言えば、それらはまったく存在しません。 正常に動作しているイーサネット接続であればどれでも使用できます。

現在、AERODISK ENGINE ストレージ システムは、イーサネット プロトコル (銅線または光ファイバー経由) を介したブロック デバイス (LUN) のレプリケーションをサポートしています。 ファイバー チャネル上の SAN ファブリックを介したレプリケーションが必要なプロジェクトの場合、現在適切なソリューションを追加していますが、まだ準備ができていないため、この場合はイーサネットのみです。

レプリケーションは、ENGINE シリーズのストレージ システム (N1、N2、N4) 間で、ジュニア システムから古いシステムへ、またはその逆に機能します。

両方のレプリケーション モードの機能は完全に同じです。 利用可能な内容の詳細は以下のとおりです。

• レプリケーション「XNUMX 対 XNUMX」または「XNUMX 対 XNUMX」、つまり、メインとバックアップの XNUMX つのデータ センターを持つクラシック バージョン
• レプリケーションは「XNUMX 対多」または「XNUMX 対多」です。 XNUMX つの LUN を複数のストレージ システムに一度にレプリケート可能
• レプリケーションをそれぞれアクティブ化、非アクティブ化、「逆転」して、レプリケーションの方向を有効化、無効化、または変更します。
• レプリケーションは、RDG (RAID 分散グループ) プールと DDP (ダイナミック ディスク プール) プールの両方で使用できます。 ただし、RDG プールの LUN は別の RDG にのみレプリケートできます。 DDPも同様です。

他にも細かい機能はたくさんありますが、特に列挙する意味はなく、設定の際に説明します。

レプリケーションの設定

セットアッププロセスは非常に簡単で、XNUMX つの段階で構成されます。

1. ネットワーク設定
2. ストレージのセットアップ
3. ルール（接続）とマッピングの設定

レプリケーションを設定する際の重要な点は、最初の XNUMX つの段階はリモート ストレージ システムで繰り返し、XNUMX 番目の段階はメイン ストレージ システムでのみ繰り返す必要があることです。

ネットワークリソースのセットアップ

最初のステップは、レプリケーション トラフィックが送信されるネットワーク ポートを構成することです。 これを行うには、ポートを有効にし、フロントエンド アダプター セクションで IP アドレスを設定する必要があります。

この後、プール (この場合は RDG) とレプリケーション用の仮想 IP (VIP) を作成する必要があります。 VIP は、ストレージ コントローラーの XNUMX つの「物理」アドレス (先ほど構成したポート) に関連付けられたフローティング IP アドレスです。 これがメインのレプリケーション インターフェイスになります。 タグ付きトラフィックを処理する必要がある場合は、VIP ではなく VLAN を使用して操作することもできます。

レプリカの VIP を作成するプロセスは、I/O (NFS、SMB、iSCSI) の VIP を作成するプロセスとあまり変わりません。 この場合、通常の VIP (VLAN なし) を作成しますが、それがレプリケーション用であることを必ず指定してください (このポインターがないと、次のステップでルールに VIP を追加できません)。

VIP は、VIP がフローティングする IP ポートと同じサブネット内に存在する必要があります。

もちろん、別の IP を使用して、リモート ストレージ システム上でこれらの設定を繰り返します。
異なるストレージ システムの VIP は異なるサブネットに存在できます。重要なのは、それらの間にルーティングがあることです。 この例では、この例が正確に示されています (192.168.3.XX および 192.168.2.XX)。

これでネットワーク部分の準備は完了です。

ストレージのセットアップ

レプリカ用のストレージのセットアップは、特別なメニュー「レプリケーション マッピング」を通じてマッピングを行う点だけが通常と異なります。 それ以外の場合は、すべて通常のセットアップと同じです。 さて、順番に。

前に作成したプール R02 に、LUN を作成する必要があります。 これを作成して、LUN1 と名付けましょう。

また、同じサイズのリモート ストレージ システム上に同じ LUN を作成する必要があります。 私たちは創造します。 混乱を避けるために、リモート LUN を LUN1R と呼びます。

すでに存在する LUN を取得する必要がある場合は、レプリカのセットアップ中に、この本稼働 LUN をホストからアンマウントし、リモート ストレージ システム上に同じサイズの空の LUN を作成する必要があります。

ストレージのセットアップが完了したので、レプリケーション ルールの作成に進みましょう。

レプリケーション ルールまたはレプリケーション リンクのセットアップ

現時点ではプライマリとなるストレージ システム上に LUN を作成した後、ストレージ システム 1 のレプリケーション ルール LUN1 をストレージ システム 1 の LUN2R に構成します。

設定は「リモートレプリケーション」メニューで行います。

ルールを作りましょう。 これを行うには、レプリカの受信者を指定する必要があります。 ここで、接続の名前とレプリケーションのタイプ (同期または非同期) も設定します。

「リモート システム」フィールドにストレージ システムを追加します2。 さらに、管理 IP ストレージ システム (MGR) と、レプリケーションを実行するリモート LUN の名前 (この場合は LUN1R) を使用する必要があります。 制御 IP は接続を追加する段階でのみ必要になります。レプリケーション トラフィックは制御 IP を介して送信されません。これには、以前に構成された VIP が使用されます。

すでにこの段階で、「XNUMX 対多」トポロジに複数のリモート システムを追加できます。次の図のように、「ノードの追加」ボタンをクリックします。

私たちの場合、リモート システムは XNUMX つだけなので、これに限定します。

ルールは準備完了です。 すべてのレプリケーション参加者に自動的に追加されることに注意してください (この例では 1 つあります)。 このようなルールは、LUN の数や方向に好きなだけ作成できます。 たとえば、負荷のバランスをとるために、LUN の一部をストレージ システム 2 からストレージ システム 2 にレプリケートし、他の部分を逆にストレージ システム 1 からストレージ システム XNUMX にレプリケートできます。

ストレージシステム1. 作成後すぐに同期が始まりました。

ストレージシステム2. 同じルールが表示されますが、同期はすでに終了しています。

ストレージ システム 1 の LUN1 はプライマリの役割にあり、つまりアクティブです。 ストレージ システム 1 の LUN2R はセカンダリの役割を果たしており、ストレージ システム 1 に障害が発生した場合に備えてスタンバイ状態になります。
これで、LUN をホストに接続できるようになりました。

ここでは iSCSI 経由で接続しますが、FC 経由でも接続できます。 レプリカでの iSCSI LUN を介したマッピングの設定は通常のシナリオと実質的に変わらないため、ここでは詳しく検討しません。 このプロセスについては、記事「クイックセットアップ'。

唯一の違いは、「レプリケーション マッピング」メニューでマッピングを作成することです。

マッピングを設定し、LUN をホストに与えました。 ホストは LUN を認識しました。

それをローカル ファイル システムにフォーマットします。

以上でセットアップは完了です。 次にテストが来ます。

テスト

XNUMX つの主要なシナリオをテストします。

1. 通常の役割の切り替え セカンダリ > プライマリ。 たとえば、メイン データ センターで予防的な操作を実行する必要がある場合に、定期的な役割の切り替えが必要になります。この間、データを利用できるようにするために、負荷をバックアップ データ センターに転送します。
2. 緊急時の役割の切り替え セカンダリ > プライマリ (データセンター障害)。 これはレプリケーションが存在する主なシナリオであり、データセンターの完全な障害が発生した場合でも、企業を長期間停止させることなく存続するのに役立ちます。
3. データセンター間の通信チャネルの内訳。 何らかの理由でデータセンター間の通信チャネルが利用できない状況（たとえば、掘削機が間違った場所を掘って暗い光学系を壊した場合など）で XNUMX つのストレージ システムが正しく動作することを確認します。

まず、LUN へのデータの書き込み (ランダム データを含むファイルの書き込み) を開始します。 ストレージ システム間の通信チャネルが利用されていることがすぐにわかります。 これは、レプリケーションを担当するポートの負荷監視を開くと簡単に理解できます。

両方のストレージ システムに「有用な」データが入ったので、テストを開始できます。

念のため、ファイルの XNUMX つのハッシュ サムを調べて書き留めてみましょう。

定期的な役割の切り替え

ロールの切り替え操作 (レプリケーションの方向の変更) はどのストレージ システムでも実行できますが、プライマリでマッピングを無効にし、セカンダリ (プライマリになる) でマッピングを有効にする必要があるため、やはり両方に移動する必要があります。 ）。

おそらく、ここで当然の疑問が生じます。なぜこれを自動化しないのか? 答えは簡単です。レプリケーションは手動操作のみに基づく、災害に対する回復力を高める簡単な手段です。 これらの操作を自動化するためのメトロクラスター モードがあり、完全に自動化されていますが、その構成ははるかに複雑です。 次の記事ではメトロクラスターのセットアップについて書きます。

メイン ストレージ システムでは、記録が確実に停止されるようにマッピングを無効にします。

次に、いずれかのストレージ システム (メインでもバックアップでも構いません) の [リモート レプリケーション] メニューで接続 REPL1 を選択し、[役割の変更] をクリックします。

数秒後、LUN1R (バックアップ ストレージ システム) がプライマリになります。

LUN1R をストレージ システム 2 にマッピングします。

この後、E: ドライブは自動的にホストに接続されますが、今回のみ LUN1R から「到着」しました。

念のためハッシュサムを比較してみます。

同じです。 テストに合格しました。

フェイルオーバー。 データセンター障害

現時点では、定期切り替え後の主ストレージシステムは、それぞれストレージシステム 2 と LUN1R です。 事故をエミュレートするために、両方のストレージ コントローラの電源をオフにします2。
これ以上アクセスすることはできません。

ストレージ システム 1 (現時点ではバックアップ システム) で何が起こっているのかを見てみましょう。

プライマリ LUN (LUN1R) が使用できないことがわかります。 エラー メッセージがログ、情報パネル、およびレプリケーション ルール自体に表示されました。 したがって、ホストからのデータは現在利用できません。

LUN1 の役割をプライマリに変更します。

ホストへのマッピングを行っています。

ドライブ E がホスト上に表示されていることを確認します。

ハッシュを確認します。

すべて順調。 ストレージ システムは、稼働していたデータ センターの崩壊にも成功しました。 レプリケーションの「リバーサル」接続とバックアップ データ センターからの LUN の接続に費やしたおおよその時間は約 3 分でした。 実際の運用ではすべてがはるかに複雑であることは明らかであり、ストレージ システムでの操作に加えて、ネットワーク上、ホスト上、アプリケーション内でさらに多くの操作を実行する必要があります。 そして人生では、この期間ははるかに長くなるでしょう。

ここで、テストはすべて正常に完了したことを書きたいと思いますが、焦らないようにしましょう。 メイン ストレージ システムは「横たわっている」ため、「落ちた」ときはプライマリの役割を果たしていたことがわかります。 突然電源が入ったらどうなりますか？ XNUMX つのプライマリ ロールがあり、どちらがデータ破損に相当しますか? 今すぐ確認してみましょう。
基盤となるストレージ システムを突然オンにしてみましょう。

数分間ロードされ、短い同期の後、セカンダリの役割でサービスに戻ります。

大丈夫。 スプリットブレインは起こらなかった。 私たちはこれについて考えましたが、ストレージ システムが「存続期間中」どのような役割を果たしていたかに関係なく、障害が発生した後は常にストレージ システムがセカンダリの役割に切り替わります。 これで、データセンターの障害テストは成功したと断言できます。

データセンター間の通信チャネルの障害

このテストの主なタスクは、XNUMX つのストレージ システム間の通信チャネルが一時的に失われ、その後再び発生した場合に、ストレージ システムが異常な動作を開始しないことを確認することです。
それで。 ストレージ システム間のワイヤを切断します (掘削機によって掘られたと想像してみましょう)。

プライマリでは、セカンダリとの接続がないことがわかります。

セカンダリでは、プライマリとの接続がないことがわかります。

すべてが正常に動作し、引き続きメイン ストレージ システムにデータを書き込みます。つまり、データはバックアップ システムとは異なることが保証されており、つまり「分離」されています。

数分で通信チャネルを「修復」します。 ストレージ システムが相互に認識されるとすぐに、データ同期が自動的にアクティブになります。 ここでは管理者は何もする必要はありません。

しばらくすると、同期が完了します。

接続は回復し、通信チャネルの喪失による緊急事態は発生せず、電源を入れた後は同期が自動的に行われました。

所見

私たちは理論を分析しました - 何が必要で、なぜ必要なのか、どこに利点があり、どこに欠点があるのか​​。 次に、XNUMX つのストレージ システム間の同期レプリケーションを設定します。

次に、通常のスイッチング、データセンターの障害、および通信チャネルの障害に関する基本テストが実行されました。 いずれの場合も、ストレージ システムは正常に動作しました。 データの損失はなく、手動シナリオでは管理操作が最小限に抑えられます。

次回は状況を複雑にして、アクティブ/アクティブ モード、つまり両方のストレージ システムがプライマリであり、ストレージ システム障害時の動作が完全に自動化されているモードの自動化されたメトロクラスタでこのすべてのロジックがどのように動作するかを示します。

コメントをお書きください。健全な批評や実践的なアドバイスを喜んで受け取ります。

次回まで。

出所： habr.com