編集

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

Azure Blob Storage
Azure Backup
Azure Monitor
Azure Stack HCI

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

アーキテクチャ

アクティブ/アクティブおよびアクティブ/パッシブの Azure Stack HCI ストレッチ クラスターを示す図。ストレージ ボリュームとクラスターのパフォーマンス履歴は Storage レプリカ経由でレプリケートされます。アクティブ/アクティブ モードでは、両方のサイトで Azure Stack HCI VM がホストされ、各方向のレプリケーション トラフィックがあります。アクティブ/パッシブ モードでは、アクティブなサイトで Azure Stack HCI VM がホストされ、レプリケーションは一方向です。

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

コンポーネント

アーキテクチャは、次のコンポーネントと機能で構成されています。

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

シナリオの詳細

通常、このアーキテクチャは、Azure Stack HCI VM の自動フェールオーバーと、ラウンド トリップ ネットワーク遅延時間範囲が 5 ms の 2 つの物理的な場所間でのファイル共有を使用したディザスター リカバリーに使用されます。

Recommendations

ほとんどのシナリオには、次の推奨事項が適用されます。 優先すべき特定の要件がない限り、これらの推奨事項に従ってください。

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

Azure Stack HCI の組み込みの回復性を強化するには、2 つのノード グループ (サイトごとに 1 つのグループ) で構成された Azure Stack HCI のストレッチ クラスターを実装できます。 各グループには、2 つ以上のノードが含まれている必要があります。 クラスター内のノードの合計数は、Azure Stack HCI クラスターでサポートされる最大ノード数を超えることはできません。 ノードは、標準の HCI ハードウェア要件を満たしている必要があります。

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

注意

同期レプリケーションでは、フェールオーバー中のファイル システム レベルでのデータ損失をゼロにして、クラッシュの整合性が保証されます。

注意事項

ストレッチ クラスターに適用可能な同期レプリケーション要件により、レプリケート サイト内の 2 つのクラスター ノード グループ間のラウンドトリップ ネットワーク遅延時間が 5 ms に制限されます。 物理ネットワーク接続の特定に応じて、この制約は、通常、約 20 から 30 物理マイルに変換されます。

注意

記憶域レプリカの署名および暗号化機能により、レプリケーション トラフィックは自動的に保護されます。

考慮事項

Microsoft Azure Well-Architected フレームワークは、この参照アーキテクチャの基になっている一連の基本原則です。 以下の考慮事項は、これらの原則のコンテキストで構成されています。

[信頼性]

信頼性により、顧客に確約したことをアプリケーションで確実に満たせるようにします。 詳細については、「信頼性の重要な要素の概要」を参照してください。

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

注意

各場所が個別の AD DS サイトに対応する場合、クラスター プロビジョニング プロセスにより、サイト割り当てが自動的に構成されます。 2 つの場所を表す個別の AD DS サイトはないが、ノードは 2 つの異なるサブネット上にある場合、クラスター プロビジョニング プロセスでは、サブネットの割り当てに基づいてサイトを識別します。 ノードが同じサブネット上にある場合、サイトの割り当てを明示的に定義する必要があります。

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

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

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

  • さらに多くの回復性の利点を提供するさまざまな Azure サービスとの統合。 Azure Stack HCI クラスターで実行されている仮想化されたワークロードを、Azure Backup や Azure Site Recovery などの Azure サービスと統合できます。

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

注意事項

SDN でストレッチ クラスターを使用することは、高度な構成と見なされます。さらに支援が必要な場合は、システム インテグレーターまたは Microsoft サポートにお問い合わせください。

セキュリティ

セキュリティは、重要なデータやシステムの意図的な攻撃や悪用に対する保証を提供します。 詳細については、「セキュリティの重要な要素の概要」を参照してください。

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

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

  • さらに多くのセキュリティの利点を提供するさまざまな Azure サービスとの統合。 Azure Stack HCI クラスターで実行されている仮想化されたワークロードを、Microsoft Defender for Cloud などの Azure サービスと統合できます

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

注意事項

記憶域レプリカと Azure Stack HCI のストレッチ クラスターは、AD DS 環境内で動作する必要があります。 Azure Stack HCI のストレッチ クラスターのデプロイを計画する場合、クラスター ノードをホストしている各サイトで AD DS ドメイン コントローラーへの接続を確保します。

コストの最適化

コストの最適化とは、不要な費用を削減し、運用効率を向上させる方法を検討することです。 詳しくは、コスト最適化の柱の概要に関する記事をご覧ください。

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

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

注意

クラスター内のすべてのサーバー ノードが信頼できるインターネットに接続されている場合、Azure Stack HCI のストレッチ クラスターには、Azure クラウド監視を選択することをお勧めします。 対応する Azure 料金はごくわずかです。料金は、クラスター状態の変更に対応する更新頻度の低い小さい BLOB の価格に基づきます。 ストレッチ クラスターが関係するシナリオでは、ファイル共有監視は 3 番目のサイトに存在する必要があります。このため、3 番目のサイトが既に利用可能であり、ストレッチ クラスター ノードをホストしているサイトへの既存の信頼できる接続がある場合以外は、実装コストが大幅に増加する可能性があります。

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

注意事項

ソースと宛先の両方のサーバーにデータ重複除去サーバー ロール サービスをインストールする必要はありますが、Azure Stack HCI のストレッチ クラスター内の宛先ノードでデータ重複除去を有効にしないでください。 データ重複除去では書き込みが管理されるため、ソース クラスター ノードでのみ実行する必要があります。 宛先ノードでは常に、各ボリュームの重複除去されたコピーが受け取られます。

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

オペレーショナル エクセレンスは、アプリケーションをデプロイし、それを運用環境で実行し続ける運用プロセスをカバーします。 詳細については、「オペレーショナル エクセレンスの重要な要素の概要」を参照してください。

注意

ストレッチ クラスター用のボリュームと仮想ディスクの作成は、単一サイト クラスターの場合よりも複雑です。 ストレッチ クラスターには、少なくとも 4 つのボリューム (2 つのデータ ボリュームと 2 つのログ ボリューム) が必要であり、各サイトにデータとログのボリュームのペアがあります。 Windows Admin Center を使用して、レプリケート データ ボリュームを作成する場合、プロセスにより自動的に、プライマリ サイトでログ ボリュームがプロビジョニングされ、セカンダリ サイトでデータとログの両方のレプリケート ボリュームがプロビジョニングされて、各サイトで必要なサイズと構成の設定が確保されます。

  • Windows PowerShell の使用によるストレッチ クラスターの自動プロビジョニングと記憶域管理のサポート。 PowerShell は、いずれかの Azure Stack HCI サーバーからローカルで実行するか、管理コンピューターからリモートで実行することができます。

  • さらに多くの運用上の利点を提供する Azure サービスとの統合。 Azure Stack HCI で実行されている仮想化されたワークロードを、Azure Monitor などの Azure サービス、および Azure Automation ソリューション (変更履歴とインベントリ、Update Management を含む) と統合できます。 最初の必須の登録手順を完了すると、Azure Stack HCI クラスターで、監視と課金に Azure Arc を利用できるようになります。 Azure Arc 統合により、Azure Policy や Log Analytics などの他のハイブリッド サービスとの統合が強化されます。 登録すると、Azure Stack HCI クラスターを表す Azure Resource Manager リソースの作成がトリガーされ、Azure 管理プレーンが Azure Stack HCI に効果的に拡張されます。

パフォーマンス効率

パフォーマンス効率とは、ユーザーによって行われた要求に合わせて効率的な方法でワークロードをスケーリングできることです。 詳細については、「パフォーマンス効率の柱の概要」を参照してください。

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

注意事項

RDMA は、同じサブネット上の同じサイト内にあるクラスター ノード間のすべてのトラフィックに対して既定で有効になっています。 サイト間または異なるサブネット間の RDMA は無効になり、サポートされません。 サイト間トラフィックに対して SMB ダイレクトを無効にするか、または同じサイト内でサイト間トラフィックをノード間トラフィックと分離する追加のプロビジョニングを実装する必要があります。

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

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

注意

ストレッチ クラスター ボリュームのプロビジョニングに Windows Admin Center を使用すると、最適な構成が自動的に割り当てられます。

次のステップ