ディザスター リカバリーに Azure ローカル ストレッチ クラスターを使用する

次の参照アーキテクチャは、ストレッチ クラスタリングを使用して Azure Local のディザスター リカバリーを設計および実装する方法を示しています。

建築

このアーキテクチャの Visio ファイル をダウンロードします。

コンポーネント

このアーキテクチャには、次のコンポーネントと機能が組み込まれています。

• Azure Stack HCI バージョン 22H2。 Azure Local は、仮想化された Windows および Linux ワークロードとそのストレージをハイブリッドオンプレミス環境でホストするために使用できるハイパーコンバージド インフラストラクチャ (HCI) クラスター ソリューションです。 ストレッチ クラスターは、4 から 16 個の物理ノードで構成できます。
• 記憶域レプリカを します。 記憶域レプリカは、ディザスター リカバリーを目的としてサーバーまたはクラスター間のボリューム レプリケーションを有効にする Windows Server テクノロジです。
• ライブ マイグレーションを します。 ライブ マイグレーションは、Windows Server の Hyper-V 機能であり、実行中の仮想マシン (VM) を、ダウンタイムを認識することなく、ホスト間 Hyper-V シームレスに移動できます。
• クラウド監視を します。 クラウド監視は、Microsoft Azure Blob Storage を使用してクラスター クォーラムに関する投票を提供するフェールオーバー クラスター クォーラム監視です。

シナリオの詳細

通常、このアーキテクチャは、5 ミリ秒のラウンドトリップ ネットワーク待機時間の範囲内にある 2 つの物理的な場所間の Azure ローカル VM とファイル共有の自動フェールオーバーによるディザスター リカバリーに使用します。

推奨 事項

次の推奨事項は、ほとんどのシナリオに適用されます。 推奨事項をオーバーライドする特定の要件がない限り、推奨事項に従ってください。

ストレッチ クラスターを使用して、Azure Local でホストされている仮想化ワークロードとファイル共有の自動ディザスター リカバリーを実装する

Azure Local の組み込みの回復性を高めるために、サイトごとに 1 つのグループを持つ 2 つのノード グループで構成される拡張 Azure Local インスタンスを実装します。 各グループには、少なくとも 2 つのノードが含まれている必要があります。 クラスター内のノードの合計数は、Azure ローカル インスタンスでサポートされているノードの最大数を超えることはできません。 ノードは、標準 HCI ハードウェア要件を満たす必要があります。

ストレッチ Azure ローカル インスタンスは、記憶域レプリカに依存して、それぞれの物理サイト内の 2 つのノード グループによってホストされているストレージ ボリューム間で同期ストレージ レプリケーションを実行します。 障害がプライマリ サイトの可用性に影響を与える場合、クラスターは、潜在的なダウンタイムを最小限に抑えるために、ワークロードを存続サイト内のノードに自動的に移行します。 プライマリ サイトで計画的または予想されるダウンタイムの場合は、Hyper-V ライブ マイグレーションを使用してワークロードを他のサイトにシームレスに移行し、ダウンタイムを完全に回避できます。 このシナリオでは、ストレージの場所に注意する必要があります。 まず、記憶域レプリカのレプリケーションの方向を逆にしてから、VM のライブ マイグレーションを実行する必要があります。 ライブ マイグレーションが完了するまで、パフォーマンスに影響します。

考慮 事項

これらの考慮事項は、Azure Well-Architected Framework の柱を実装します。これは、ワークロードの品質を向上させるために使用できる一連の基本原則です。 詳細については、Microsoft Azure Well-Architected Frameworkの に関するページを参照してください。

確実

信頼性により、アプリケーションは顧客に対するコミットメントを確実に満たすことができます。 詳細については、「信頼性設計レビューチェックリスト」を参照してください。

• サイト レベルの障害ドメイン。 Azure ローカル ストレッチ クラスターの各物理サイトは、追加の回復性を提供する個別の障害ドメインを表します。 障害ドメインは、単一障害点を共有するハードウェア コンポーネントのセットです。 特定のレベルにフォールト トレラントにするには、そのレベルで複数の障害ドメインが必要です。

• サイトの認識。 サイト認識を使用すると、優先サイトを指定することで、仮想化されたワークロードの配置を制御できます。 ストレッチ クラスターの優先サイトを指定すると、サイト レベルでワークロードをグループ化したり、クォーラム投票オプションをカスタマイズしたりする機能など、多くの利点があります。 既定では、コールド スタート時にすべての仮想マシンが優先サイトを使用しますが、クラスターの役割またはグループ レベルで優先サイトを構成することもできます。 これにより、アクティブ/アクティブ モードで特定の仮想マシンをそれぞれのサイトに割り当てることができます。 クォーラムの観点からは、優先サイトの選択は、そのサイトを優先する方法で投票の割り当てに影響します。 たとえば、ストレッチ クラスター ノードをホストしている 2 つのサイト間の接続が失敗し、クラスター監視に到達できない場合、優先サイトはオンラインのままになり、もう一方のサイトのノードは削除されます。

• 記憶域スペース ダイレクト ボリュームの修復速度が向上しました。 記憶域スペース ダイレクトでは、クラスター ノードの 1 つをシャットダウンしたり、ローカライズされたハードウェア障害を発生させたりするなど、記憶域プール内のディスクの可用性に影響を与えるイベントに続く自動再同期が提供されます。 Azure Local では、Windows Server 2019 よりもはるかに細かい粒度で動作する、強化された再同期プロセス が実装されています。 このプロセスにより、再同期操作の期間が大幅に短縮され、重複する複数のハードウェア 障害による潜在的な影響が最小限に抑えられます。

• 回復性の制限。 Azure Local では複数のレベルの回復性が提供されますが、ハイパーコンバージド アーキテクチャのため、その回復性は、クラスター クォーラムだけでなく、プール クォーラムによって課される制限の対象となります。

• 追加の回復性の利点を提供するさまざまな Azure サービスとの統合。 Azure ローカル インスタンスで実行されている仮想化されたワークロードを、Azure Backup や Azure Site Recoveryなどの Azure サービスと統合できます。

• 高速フェールオーバー。 サイト レベルのフェールオーバーを迅速に完了するために、ネットワーク インフラストラクチャとその構成を最適化できます。 たとえば、クラスター化されたリソースを表す DNS レコードで、拡張仮想 LAN (VLAN)、ネットワーク抽象化デバイス、短い Time to Live (TTL) 値を利用できます。 さらに、既定の回復性期間を下げることを検討してください。これは、クラスター化された VM を分離状態で実行できる期間を決定します。

安全

セキュリティは、意図的な攻撃や貴重なデータとシステムの悪用に対する保証を提供します。 詳細については、「セキュリティ設計レビューチェックリスト」を参照してください。

• 転送中の保護。 ストレージ レプリカは、パケット署名、AES-128-GCM の完全なデータ暗号化、Intel AES-NI 暗号化高速化のサポート、中間者攻撃防止の事前認証整合性など、レプリケーション トラフィックに対する組み込みのセキュリティを提供します。 記憶域レプリカでは、レプリケート ノード間の認証にも Kerberos AES256 が使用されます。

• 保存時の暗号化。 Azure Local では、データ ボリュームの BitLocker ドライブ暗号化がサポートされているため、FIPS 140-2 や HIPAA などの標準への準拠が容易になります。

• 追加のセキュリティ上の利点を提供するさまざまな Azure サービスとの統合。 Azure ローカル インスタンスで実行されている仮想化ワークロードを、Microsoft Defender for Cloud などの Azure サービス 統合できます。

• ファイアウォールに対応した構成。 記憶域レプリカ のトラフィックには、レプリケート ノード 間に限られた数の開いているポートが必要です。

コストの最適化

コストの最適化は、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳細については、「コストの最適化設計レビューチェックリスト」を参照してください。

• アクティブ/アクティブ構成とアクティブ/パッシブ構成。 ストレッチ Azure ローカル インスタンスでは、アクティブ/パッシブ モードとアクティブ/アクティブ モードがサポートされます。 アクティブ/パッシブ モードでは、指定されたプライマリ サイトは、ディザスター リカバリー機能を提供する別のサイトに一方向にレプリケートされます。 アクティブ/アクティブ モードでは、2 つのサイトがそれぞれのボリュームを一方向に相互にレプリケートし、いずれかのサイトで障害が発生した場合にフェールオーバー機能を提供します。 アクティブ/アクティブ モードは、専用のディザスター リカバリー サイトの必要性を排除することで、ビジネス継続性のコストを最小限に抑えるのに役立ちます。

• クラウド監視とファイル共有監視。 ミラーリング監視リソースは、Azure ローカル インスタンス内の必須コンポーネントです。 これを実装するには、Azure クラウド監視またはファイル共有監視のいずれかを選択します。 Azure クラウド監視は、スプリット ブレイン シナリオを防ぐために、仲裁ポイントとして指定した Azure ストレージ アカウント内の BLOB に依存します。 ファイル共有監視は、同じ目的を達成するためにサーバー メッセージ ブロック (SMB) ファイル共有に依存します。

• データ重複除去。 Azure ローカルレプリカとストレージ レプリカでは、データ重複除去がサポートされます。 Windows Server 2019 以降では、Azure Local に推奨されるファイル システムである Resilient File System (ReFS) でフォーマットされたボリュームで重複除去を使用できます。 重複除去は、ファイルの重複部分を特定し、1 回だけ格納することで、使用可能なストレージ容量を増やすのに役立ちます。

オペレーショナル エクセレンス

オペレーショナル エクセレンスは、アプリケーションをデプロイし、運用環境で実行し続ける運用プロセスを対象としています。 詳細については、「オペレーショナル エクセレンス設計レビュー チェックリスト」を参照してください。

• 自動フェールオーバーと復旧。 プライマリ サイトの障害が発生すると、自動フェールオーバーがトリガーされます。 フェールオーバー後、新しいプライマリ/以前のセカンダリ サイトから新しいセカンダリ/以前のプライマリ サイトへのレプリケーションを確立するプロセスも自動的に行われます。 データ損失の可能性を防ぐために、レプリケートされたボリュームが完全に同期されるまで、クラスターはフェールバックを防ぎます。

• Windows Admin Center を使用してプロビジョニングと管理のエクスペリエンスを簡素化しました。 Windows Admin Center のクラスターの作成ウィザードには、Azure ローカルストレッチ クラスターを作成するプロセスを説明するウィザード駆動型インターフェイスが用意されています。 ウィザードは、クラスター ノードが 2 つの異なる Active Directory Domain Services (AD DS) サイトに存在するかどうか、またはそれらの IP アドレスが 2 つの異なるサブネットに属しているかどうかを検出します。 2 つの異なるサブネットに存在する場合、ウィザードは、それぞれ個別の障害ドメインを表す対応するクラスター サイトを自動的に作成して構成します。 また、優先サイトを指定することもできます。 同様に、Windows Admin Center を使用すると、レプリケートされたボリュームをプロビジョニングするプロセスが簡略化されます。

• Windows PowerShell を使用した自動拡張クラスター プロビジョニング と ストレージ管理 のサポート。 PowerShell は、Azure ローカル コンピューターのいずれかからローカルに実行することも、管理コンピューターからリモートで実行することもできます。

• 追加の運用上の利点を提供するさまざまな Azure サービスとの統合。 Change Tracking や Inventory、Update Management など、Azure Monitor や Azure Automation ソリューションなどの Azure サービスと Azure ローカル インスタンスで実行されている仮想化ワークロードを統合できます。 最初の必須登録手順に従って、Azure Local インスタンスは Azure Arc を利用して監視と課金を行うことができます。 Azure Arc 統合では、Azure Policy や log Analyticsなど、他のハイブリッド サービスとの統合 強化されています。 登録は、Azure ローカル インスタンスを表す Azure Resource Manager リソースの作成をトリガーし、Azure 管理プレーンを Azure Local に効果的に拡張します。

パフォーマンス効率

パフォーマンス効率は、ユーザーの要求を効率的に満たすワークロードの機能です。 詳細については、「パフォーマンス効率設計レビュー チェックリスト」を参照してください。

• 最適化されたレプリケーション トラフィック。 Azure ローカル ストレッチ クラスターのインフラストラクチャを設計する場合は、サイト間を流れる追加の記憶域レプリカ、ライブ マイグレーション、および記憶域レプリカ クラスターパフォーマンス履歴トラフィックを検討してください。 同期レプリケーションには、ストレッチ クラスター サイト間の少なくとも 1 Gb のリモート 直接メモリ アクセス (RDMA) またはイーサネット/TCP 接続が必要です。 ただし、レプリケーション トラフィックの量によっては、高速の RDMA 接続が必要になる場合があります。 また、サイト間に複数の接続をプロビジョニングする必要があります。これにより、回復性の利点が得られ、ライブ マイグレーション トラフィックHyper-V 記憶域レプリカ トラフィックを できます。

• シード処理された初期同期のサポート。 初期同期時間を最小限に抑える必要があるシナリオや、ストレッチ クラスターをホストする 2 つのサイト間で使用できる帯域幅が制限されているシナリオでは、シードされた初期同期 を 実装できます。

• ストレージ I/O の処理を最適化しました。 パフォーマンスレベル ボリュームとセクターのサイズ設定、ディスクの種類、ファイル システムなど、レプリケートされたデータとログ ボリュームのの最適な構成を確認します。

次の手順

• Azure ローカル ソリューションの概要
• Windows Server と Azure ローカル でのフェールオーバー クラスタリングの
• フェールオーバー クラスター のクラウド監視をデプロイする
• Azure Local の新機能
• Azure ローカルの FAQ

関連リソース

• ハイブリッド アーキテクチャの設計
• Azure ハイブリッド オプション を する
• リモート オフィスまたはブランチ オフィス に Azure Local スイッチレス 相互接続と軽量クォーラムを使用する
• Azure Arc を使用してオンプレミス環境とマルチクラウド環境での SQL Server インスタンスの管理を最適化する
• Azure Automation State Configuration の