Hyper-V仮想マシン（VM）は、さまざまな方法で高可用性を実現できます。 これらの方法の1つであるHyper-Vレプリカを使用すると、ビジネスに不可欠なVM企業を別の物理的な場所（バックアップデータセンターなど）に複製できます。 この場合、壊滅的なソリューションを実装し、データセンター全体が失われてもVMが失われることはありません。 しかし、何社の企業がバックアップデータセンターを持つ余裕がありますか？ そして、それがそこにないが、サイトレベルでの障害に対する抵抗がまだ必要な場合は？ Azure Site Recoveryサービスは最近更新され、Microsoft Azureを「バックアップデータセンター」として使用して、VMのレプリカをMicrosoftクラウドに直接構成できるようになりました。 ここでは、その外観を確認できます。 さらに、考えられるシナリオとその1つの実装を検討します。

Hyper-Vレプリカと耐障害性？

Windows Server 2012で初めて導入されたHyper-Vレプリカは、VM非同期レプリケーションメカニズムです。 最小限の構成では、Hyper-Vレプリカには、データリンクによって接続された、昇格されたHyper-Vの役割を持つ2つのホストが必要です。 選択したVMのレプリケーションが構成された後、このVMのコピーがターゲットホスト（オフ状態）に作成され、元のVMで発生した変更が元のホストから一定の間隔で転送されます。 Windows Server 2012では、レプリケーション間隔は5分ですが、Windows Server 2012 R2では、30秒、5分、15分の3つの有効な値から選択できます。







ホストのドロップまたはその他の問題のために元のVMが使用できない場合、管理者はレプリカへの切り替えを開始します。 この場合、レプリケートされたVMはターゲットホストで起動し、その後、クライアントをこのVMに切り替えます。このVMには、異なるIP、他のVLAN設定などがあります。このような予期しない障害（予期しないフェールオーバー）では、非同期レプリケーション（最後の失敗するまで複製）。 たとえば、計画されたフェールオーバーを使用して、ソースサーバーまたはメインサイトでメンテナンスタスクを実行することもできます。 この場合、Hyper-Vレプリカは、元のVMを停止して複製されたVMを開始する前に、最後の複製の瞬間からすべての変更の転送を保証します。



災害対策ソリューションの構築は、Hyper-Vレプリカの主要なアプリケーションの1つです。 実際、ホストハードウェアには特別な要件はなく、すべてがWindows Serverツールを使用して行われます。 通信チャネルにも特別な要件はありません。 その厚さは、複製されたVMの数とボリューム、および複製の頻度によって決まります。 Hyper-VレプリカのCapacity Plannerを使用して、特定の構成のさまざまなパラメーターを評価できます。 ただし、念頭に置いておく必要がある基本的なポイントがいくつかあります。

• Hyper-Vは、元のVMからレプリカへ、必要に応じて反対方向への切り替えを提供します。 ただし、クライアントをVMに切り替える（ロードする）ツールは含まれていません。
• Hyper-Vはレプリケーション参加者を監視します。 ただし、フェールオーバークラスタリングとは異なり、メインサイトとの通信が失われた場合など、自動フェールオーバー用の組み込みロジックは含まれていません。 切り替える決定は、管理者が行う必要があります。
• 自動切り替え用のスクリプトを準備した場合でも（もちろん、Hyper-Vレプリカを管理するためのPowerShellコマンドレットが利用可能です）、これらのスクリプトは「X」時間のどこかに保存して実行する必要があります。 信頼性の基準によれば、この「どこか」はメインサイトでもバックアップでもありません。 3番目のポイントが必要です-オブザーバーまたはオーケストラ。

Azure Site Recovery（ASR）

Azure Site Recoveryクラウドサービススイート（以前のAzure Hyper-V Recovery Manager）は、計画的または計画外の停止が発生した場合の複製および切り替えプロセスのオーケストレーターとして当初考えられていました。



耐災害性を確保するには、少なくとも次のものが必要です。

• Azureにプライマリサイトとバックアップサイトを提供するために、これらの通信チャネルを使用して、保護されたオブジェクトの状態を監視します。
• レプリケーションで保護する必要があるVMと、レプリケーションオプションを指定します。
• バックアップデータセンターでのVMの起動シーケンス、可能なスクリプト、起動シーケンスなど、バックアップサイトに切り替えるために必要なすべての手順を反映する復旧計画を作成します。

このソリューションのアーキテクチャは次のとおりです。







Azureとの通信チャネルは、サイト間の切り替え時の構成、監視、および制御に使用されることに注意してください。 レプリケーショントラフィックはクラウド経由ではなく、使用するデータセンター間のチャネル経由で送信されます。



ASRのおかげで、3番目の観測/オーケストレーションポイントがあり、Microsoftは高可用性を提供します。 さらに、最初にホストでレプリケーションを構成する必要はありません。 Azure管理ポータルでAzure通信チャネル（データセンター）を構成すると、プライベートクラウド、ホスト、およびVMに関する情報を確認し、ここからレプリケーションを構成できます。 Azureチャネル-データセンターは証明書によって保護され、プロキシサーバーを介した接続設定をサポートします。また、インフラストラクチャに関しては、これらの接続は送信されます。 最後に、復旧計画では、ポートのオープンから仮想マシン設定の変更まで、最も広範なタスクを実行できるスクリプトの実行など、フェイルオーバーのロジックを説明できます。 スクリプトを含むリカバリプランのすべてのコンポーネントもAzureに保存され、高可用性が確保されます。 比Fig的に言えば、Azure Site Recoveryをセットアップすると、「レスキューボタン」が表示されます。このボタンをクリックすると、インターネットのどこからでもリカバリプロセスを開始できます。



上記のアーキテクチャは、組織に少なくとも2つのデータセンターがあることを意味します。 Hyper-Vレプリカの使用に関する限り、仮想化環境はSystem Center Virtual Machine Manager（VMM）によって管理されていると想定されています。 そのため、Azure Site Recoveryの最初の実装では、Azureとデータセンター間の接続は、VMMに特別なプロバイダーがインストールされたAzureとVMM間の接続でした。 VMMはプロバイダーを使用して、物理環境と仮想環境の構成についてAzureに通知し、たとえば管理者が設定したレプリケーション設定を使用してAzureから監視要求と管理コマンドを受け取ります。VMMは必要なHyper-VホストとVMホストに適用されます。



いくつかのサイトとVMMの必須使用により、明らかに、Azure Site Recoveryの範囲が制限されました。 このサービスの最近の更新により、新しいシナリオを実装できるようになりました。 それらを見てみましょう。

Azure Site Recoveryを使用するシナリオ

執筆時点では、Azure Site Recoveryを使用してVMを保護するために次のオプションを使用できます。

1. Hyper-Vレプリケーションを使用したオンプレミスのHyper-VサイトからAzureへの保護 。 Azureの1つ以上のHyper-VサーバーからのVM​​レプリケーション。 VMMは必要ありません。
2. Hyper-Vレプリケーションを使用したオンプレミスVMMサイトからオンプレミスVMMサイトへの保護 。 VMMによって管理されるホストまたはサイト間のVMレプリケーション。 これは最初に実装されたオプションであり、上記で検討しました。
3. SANレプリケーションを使用したオンプレミスVMMサイトからオンプレミスVMMサイトへの保護 。 VMMによって管理されるHyper-Vクラスター間のVMレプリケーション。 以前のシナリオとは異なり、レプリケーションはHyper-Vレプリカを使用してここでは行われませんが、SANによって提供されるメカニズムを使用します。 このシナリオは、主にストレージシステムのハードウェアベースのレプリケーションを既に使用している組織を対象としています。
4. オンプレミスのVMMサイトからAzureへの保護 。 1つ以上のHyper-V VMM管理サーバーからAzureへのVMレプリケーション。 シナリオ1と似ていますが、VMMがローカルに展開されている場合に適用されます。
5. InMageを使用したオンプレミスVMwareサイトからオンプレミスVMwareサイト 。 InMage Scoutコンポーネントを使用したVMwareサイト間のレプリケーション。

ローカルインフラストラクチャのこれらのオプションと対応する要件はここでより詳細に説明されます 。 4番目のシナリオの実装の簡単な例-VMMによって管理されるVMのMicrosoft Azureクラウドへのレプリケーションをさらに見ていきます。

VMMサイトとMicrosoft Azure間のVMレプリケーション

レプリケーションのセットアッププロセスについては説明しません。 VMMインフラストラクチャが展開され、プライベートクラウドが作成され、VMが実行されている場合、 ここで非常に優れたステップバイステップガイドを使用できます 。 いくつかの重要な点だけに注意します。



まず、VMMの最新バージョン（System Center 2012 R2 Virtual Machine Manager）のみがサポートされますが、VMMが管理するホストはWindows Server 2012とWindows Server 2012 R2の両方を使用できます。 この資料のコレクションには、モノの古いバージョンからの移行に関する多くの有用な情報があります。



次に、Azureでのレプリケーションは、第1世代のVM（世代1）に対してのみ構成でき、VHDまたはVHDXファイルを仮想ハードドライブとして使用するかどうかは関係ありません。



レプリケーションのセットアップは、Azure管理ポータルでのいわゆるリカバリボールトの作成から始まります。これは、VMレプリカではなく、リカバリプランを含むAzure Site Recoveryのすべての設定を含むリポジトリです。 後者は、Azureの他のVMと同様に、ストレージアカウントに作成されます。 レプリカに使用するストレージアカウントでは、ジオレプリケーションオプションを有効にし、このアカウントを回復ボールトと同じリージョン（場所）に配置する必要があります。







VMMにプロバイダーを、Hyper-Vホストにエージェントをインストールすると、AzureポータルにVMMで作成されたすべてのクラウドに関する情報が表示されます。 最初にクラウドの保護を有効にする必要があります。







そして、このクラウド内の必要なVMに対して。







つまり、AzureにレプリケートするVMはVMMクラウドに関連付けられている必要があります。



特定のVMのレプリケーションをセットアップする場合、ウィザードは、保護されたマシンに最適なAzure（ターゲットサイズ）のVMテンプレートを提供します。 このパラメーターは自由に変更できますが。 私の例では、4 GBのRAMを搭載したデュアルコアマシン用のD2テンプレートが提案されました。 保護されたVMは動的メモリを使用することに注意してください。動的メモリの設定の最大量は4 GBです。 これが、Azureがテンプレートを選択するときに焦点を当てているものです。







図の下部には、もう1つの基本的な設定であるネットワークマッピングがあります。 このメカニズムを使用して、スケジュールされたフェールオーバーまたは計画外のフェールオーバーが発生したときに、どのAzure仮想ネットワークがレプリケートされたVMに接続するかを実際に示します。 少なくともアドレス空間は、この仮想ネットワークのパラメーターで設定されます（この例では10.2.1.0/24）。 ただし、これに加えて、この仮想ネットワークとインフラストラクチャ間にVPNトンネルを構成できます。 その後、フェールオーバー後、AzureのVMはトンネルを介してネットワーク上の他のマシンと通信できるようになります。 もちろん、トンネルがAzureを障害後に失ったまさにデータセンターに接続した状況を除きます。



プロバイダーとエージェントをインストールした後、すべての構成アクションがAzureポータルで実行されることを再度強調したいと思います。 レプリケーションをセットアップしたら、保護されたクラウドのすべてのHyper-VホストでHyper-Vレプリカが実際にオンになっていること（デフォルトでオフになっている）を確認でき、変更が定期的にAzureにレプリケートされます。 これは、Azure Log PortalのJOBSセクションで確認できます。以下に例を示します。







そして、保護されたVMが実行されているホストのHyper-Vコンソールで直接：







最後の重要なポイントは、回復計画です。 私の最も単純なデモシナリオでは、この計画は次のようになります。







VMグループは1つだけです-グループ1は、保護されたVMを1つだけ所有しています-Web-App01。 このプランを実行する場合、Azureは次のことを試みます。

1. グループ内のすべてのVMをオフにします（計画外の障害の場合、データセンターとの接続が失われる可能性が高いため、このステップはほとんどの場合失敗します）。
2. フェールオーバーを実行します。つまり、レプリカが現在メインマシンになっていることを示します。
3. グループ内のVMを実行します。

より複雑なシナリオでは、レプリケーションを使用して最終的に保護するアプリケーションを複数のVM（フロントエンド、バックエンドなど）に分散できます。これらのVMは、フェールオーバー時に特定の順序で失敗する必要があります。作成された回復計画の関連グループ用。 ユーザーがVMに接続するポートを開くなど、追加のタスクを実行する必要がある場合があります。 これを行うには、準備されたスクリプトを回復計画の適切な場所に追加します。







最後に、実際の状況はarbitrarily意的に複雑になる可能性があり、バックアップVMへの切り替えプロセスを完全に自動化することはできません。 一部の手順では、ITスタッフの介入が必要になります。 このような「手動」アクションを復旧プランに追加できます。







その後、管理者が必要なアクションを実行し、ボタンをクリックしてこのステップの完了を確認するまで、このステップでリカバリプランの実装が中断されます。 その後、計画の実施は継続されます。



復旧計画の準備ができていると仮定して、次は何をしますか？ さらに、フェールオーバーテストを実行することを強くお勧めします。 Hyper-Vレプリカの大きな利点は、既に構成されているレプリケーションプロセスを中断せずにこのようなテストを実行できることです。 Test Failover操作は、実際に複製されたVMのスナップショットを作成し、それに基づいて、名前VM-Test_Nameで複製されたVMのコピーを作成して開始します。 このVMを分離されたネットワークセグメントに接続し、アプリケーションが内部的にどのように動作するか、テストクライアントがどのように接続するかなどを確認することは理にかなっています。 VMをMicrosoftクラウドに複製する場合、まったく同じ機会にAzure Site Recoveryが提供されます。 Azureでテスト仮想ネットワークを作成してから、復旧計画を選択し、下部の[ テストフェールオーバー ]ボタンをクリックして、レプリケートされたVMのコピーを接続するネットワークを選択できます。







VMの作成が完了すると、必要なすべてのチェックとテストを実行できます。 [ テストフェールオーバーが完了しました]をクリックして、テストの完了をAzureに通知する必要があります。その後、テストVMは自動的に削除されます。



これですべての準備が整い、チェックが完了しました。スケジュール済みまたはスケジュール外の切り替えに使用できる「緊急ボタン」ができました。







そして、後者のオプションではクリックする必要がないことを強く望みます。



追加情報：

• 耐災害性とアプリケーションとサービスの高可用性の提供
• Windows Server 2003 / R2移行リソースリファレンス