Share via

ASR と Azure Pack を使用して IaaS ワークロード向け Managed DR を提供する

  • Article

このポストは、11 月 12 日に投稿された Offering Managed DR for IaaS Workloads with ASR and Azure Pack の翻訳です。

数週間前に、サービス プロバイダー向けに ASR の新機能を発表しました。これにより、Azure Site Recovery 上で高付加価値のサービスを提供する各種シナリオを実現できるようになりました。サービス プロバイダーは、ASR と Azure Pack を活用して、IaaS ワークロードを利用する顧客向けプレミアム サービスとして Managed DR を提供することができます。

この記事では、ASR と Azure Pack を統合し、ユーザー トレーニングや構成の変更を最小限に抑えて、顧客に Managed DR サービスを提供する方法についてご紹介します。さらに、DR 計画/アドオンの作成、テナントのオンボーディング、フェールオーバー後の Virtual Machines へのアクセスの方法についても簡単にご説明します。

上の図からおわかりのように、Azure Pack、System Center Virtual Machine Manager (SCVMM)、Windows Server は、Azure に対応したサービスを提供するための基盤となります。

サービス プロバイダーは、まず DR を提供する前段階としてインフラストラクチャを準備する必要があります。その前提条件は次のとおりです。

初期設定が完了したら、DR 計画をロールアウトすることができます。これにより、自動保護、非同期レプリケーション、仮想ワークロードの順序立てた復旧を含む ASR 機能の利用が可能になります。

以下のセクションでは、DR 計画/アドオンの作成、ASR Runbook のスケジュール設定、テナントのオンボーディング、フェールオーバー ドリルの管理、フェールオーバー後の VM へのアクセスの具体的な手順についてご説明します。

 

DR 計画/アドオンの作成

DR 計画を提供するには、計画を作成、公開し、それに DR アドオンをリンクした後、対応するプライベート復旧計画をセカンダリの Azure Pack 管理ポータル上で作成する必要があります。ここでは、サンプルとして「Gold Plan」という名前の計画を DR アドオンにリンクします。

DR アドオンを作成するには、[PLAN] を展開し、[CREATE ADD-ON] をクリックして、DRAddon という名前を指定します。作成されたアドオンには、まだ設定が必要です。アドオンの設定を行うには、Azure Pack 内の [ADD-ONS] をクリックして、作成したアドオンを選択します。アドオン サービス配下の “Virtual Machine Clouds” は有効になっていません。

[Virtual Machine Clouds] をクリックし、プライマリ データ センターの Azure Pack で使用するために設定した、[VMM MANAGEMENT SERVER] と [VIRTUAL MACHINE CLOUD] の名前を選択します。

利用している製品に応じて、コアの使用制限、メモリなど、残りの設定を行います。最後に、カスタム設定の下の [Enable protection for all virtual machines] にチェックマークを付けます。この項目は Azure Pack の更新プログラムのロールアップ 4 (機械翻訳) から追加されました。

これで DR アドオンの作成は完了です。次に、これを計画とリンクする必要があります。アドオンをリンクするには、[Link a plan] をクリックして [Gold Plan] を選択します。

この DR 計画は既に顧客に提供できる状態ですが、対応するプライベート計画がセカンダリの Azure Pack 上に必要です。このプライベート計画を利用することで、テナントのサブスクリプションは、DR サイト上にまったく同じサービスと製品を持つことができます。テナントのサブスクリプションは、ASR により、プライマリ計画からセカンダリ データ センターのプライベート計画に自動的に追加されます。これにより、どちらのデータセンターでも、テナントに対して一貫したシームレスなエクスペリエンスが提供されます。

プライベート計画を作成するには、セカンダリの Azure Pack 管理ポータルにログインして、Gold Plan-Recovery という名前の計画を作成します。プライベート計画の名前は、プライマリ計画の名前と接尾辞で構成されます。接尾辞は何でもかまいませんが、「-Recovery」のような、わかりやすいものにすることをお勧めします。

プライベート計画を作成できたら、前述の手順と同様に設定します。セカンダリ データセンターの [VMM MANAGEMENT SERVER] と [VIRTUAL MACHINE CLOUD] の名前を選択します。

 

マスター Runbook

ASR Runbook を使用すると、テナントごとに手動で保護機能を有効にする手間を省き、自動的に保護機能をデプロイできます。プライマリの Azure Pack 管理ポータルには 5 つの Runbook をインポートする必要がありますが、設定とスケジュールが必要なのは、Invoke-AzureSiteRecoveryProtectionJob.ps1 という名前のマスター Runbook だけです。残りの Runbook は、テナント サブスクリプションを照会したり、保護機能を有効にしたり、プライマリの Azure Pack 管理ポータルからセカンダリの Azure Pack 管理ポータルへサブスクリプションをコピーするときに、マスター Runbook によって内部で呼び出されます。

マスター Runbook の設定とスケジュールを行うには、プライマリの Azure Pack 管理ポータルで [AUTOMATION] を表示し、マスター Runbook を選択して [SCHEDULE] をクリックします。スケジュールに覚えやすい名前を付け、Runbook の実行頻度と時刻を指定します。スケジュールの設定を完了するには、Runbook パラメーターとしてアセットの名前を指定する必要があります。

詳しいアセットの作成方法は Microsoft スクリプト センター (英語) で確認できますが、ここでも例としてアセットを 1 つ作成します。

PrimarySiteAdminConnection パラメーターのアセットを作成するには、[AUTOMATION] を表示し、最上部の [ASSETS] をクリックして、下部中央の [ADD SETTINGS] をクリックします。

1) [ADD CONNECTION] を選択します。

2) 接続タイプとして MgmntSvcAdmin を選択し、Primary Azure Pack Login という名前を指定します。

3) コンピューター名、パスワード、プライマリの Azure Pack のユーザー名を指定します。

同様に残りのアセットも作成し、マスター Runbook 内にこれらのアセットの名前を設定します。

 

テナントのオンボーディング

テナントのオンボーディングはシームレスに行われます。テナントは、自分のポータル内に新しい DR 計画/アドオンがあるのを確認できます。自分のテナント ポータル アカウントを使用して新しい計画にサインアップすることにより、DR 計画にサブスクライブできます。完了したら、サブスクリプションに DR アドオンを追加します。以下は、テナント アカウント ポータルの画面サンプルです。

テナントがポータル内で Virtual Machines を作成すると、作成した Virtual Machines がポータル内に表示されます。

テナントが実施する手順はこれだけです。

自動保護

テナントが計画にサブスクライブすると、ASR Runbook は次の 2 つのタスクを実行します。

  • プライマリの Azure Pack 管理ポータル上で DR 計画のサブスクリプションを自動的に検出し、そのコピーをセカンダリの Azure Pack プライベート計画に追加する
  • テナントの Virtual Machines の保護を有効にし、すべての Virtual Machines をリカバリ用の Azure Pack にレプリケートする

注 : Runbook は、ユーザー アカウントをセカンダリの Azure Pack に自動的に追加することはありません。この処理は、サービス プロバイダーが、Active Directory Federation Services (ADFS) などのテクノロジを利用してサービスとして提供します。

以下のスクリーンショットでは、プライマリの Azure Pack 管理ポータルの Gold Plan のテナント サブスクリプションが、セカンダリの Azure Pack 管理ポータルの Gold Plan-Recovery に追加されています。

プライマリの Azure Pack

セカンダリの Azure Pack

ASR Runbook により、テナントの Virtual Machines の保護が有効になります。これは、下記に示すように、Azure Site Recovery ポータル内のジョブが自動的にトリガーされたということです。ジョブが自動的にトリガーされない場合は、手動で実行する必要があります。

プライマリの Azure Pack 管理ポータルには、Runbook ジョブ ビューがあります。このビューから、Runbook ごとに完了したジョブの詳細を確認することができます。

 

ASR ポータルでのフェールオーバーの実行

サービス プロバイダーは、Azure Site Recovery ポータルから、カスタマー アプリケーションの DR ドリルとフェールオーバーの両方を管理することができます。また、災害復旧計画を活用して、ASR ポータル内でテスト フェールオーバーやその他のフェールオーバーを実行したり、顧客に最適な復旧ポイント目標 (RPO) と復旧時間目標 (RTO) を提供したりすることができます。

この記事では、ASR 災害復旧計画を使用して、テナントの Virtual Machines のフェールオーバーの手順について見てきました。計画的なフェールオーバーを実行するには、Azure Site Recovery ポータルにログインして、災害復旧計画を作成します。以下のスクリーンショットからおわかりのように、この災害復旧計画ではテナントの VM が 2 つのグループに分割されています。この場合、リカバリ サイトで最初にデータベース サーバーの VM が起動し、続いて残りの 3 台の VM が起動します。これには、バックエンドの Virtual Machines を起動してから、依存関係にある他の VM を起動する狙いがあります。

 

フェールオーバー後の VM へのアクセス

ASR と Azure Pack を使用することで、テナントは、セカンダリ データベースでも一貫したエクスペリエンスを得ることができます。サービス プロバイダーは、セカンダリ サイトの Azure Pack テナント ポータルへのリンクを顧客に公開する必要があります。これにより、顧客はセカンダリ サイトのポータルにログインして、プライマリの Azure Pack ポータルにログインしているときとまったく同じように、シームレスに Virtual Machines にアクセスすることができます。以下のスクリーンショットは、テナントがセカンダリ サイトの Azure Pack テナント ポータルにログインしたときのようすを示しています。フェールオーバー後、4 台の Virtual Machines すべてが実行中です。

この記事では、サービス プロバイダーが DR 計画/アドオンを顧客にロールアウトし、ASR Runbook を使用して保護機能を自動的に有効にする方法についてご説明しました。さらに、テナントが DR 計画にサブスクライブし、フェールオーバー後に自分の VM にアクセスする方法についてもご説明しました。ASR と Azure Pack を統合することによって、サービス プロバイダーは、既存の Azure Pack セットアップの変更を最小限に抑えて DRaaS (サービスとしての DR) を提供できるだけでなく、DR 対応の IaaS を実現する包括的なソリューションを提供することで、収益を伸ばすことができます。

ご興味をお持ちいただけましたら、Azure Site Recovery と WAP の統合 (英語) に関する入門ガイドをご覧ください。

その他のご不明な点につきましては、MSDN の Azure Site Recovery フォーラム (英語) で追加情報を収集されるか、他のお客様と情報交換されることをお勧めします。