Azure Site Recovery による VMware および物理的ワークロードの保護を目的として Process Server をデプロイする場合のベスト プラクティス

このポストは、1 月 22 日に投稿された Best Practices for Process Server Deployment when Protecting VMware and Physical Workloads with Azure Site Recovery の翻訳です。

2014 年夏、マイクロソフトは InMage Systems 社を買収 (英語) しました。InMage Systems 社は、幅広いプラットフォームや OS に対応するエンタープライズ クラスの災害復旧 (DR) 製品を専門に提供していた企業です。買収後間もなく、サイト間およびサイトからホスティング サービスへの災害復旧を行う InMage の主力製品が Microsoft Azure Site Recovery (ASR) に組み込まれました。また、これに続き Microsoft Migration Accelerator のプレビューがリリース (英語) されました。これは InMage のテクノロジを基礎とするサービスで、ダウンタイムを最小限に抑えながら Microsoft Azure にすばやく簡単にユーザーのワークロードを移行することができます。

 

基本的に、InMage のレプリケーション チャネルを活用した現行サービスは、すべて同一のアーキテクチャを基盤とし、その主要コンポーネントには次のようなものがあります。

• Configuration Server – セカンダリ サイトで実行される VM。レプリケーション ポリシー、レプリケーション ステータス、正常性レポートの保守を担当。
• Master Target – セカンダリ サイトで実行される VM。すべての複製されたデータおよび変更ジャーナルのリポジトリとなる。
• Mobility Service – レプリケーションのために保護対象のワークロードでのデータ変更を継続的かつリアルタイムにメモリから直接キャプチャする軽量のソフトウェア コンポーネント。
• Process Server – プライマリ サイト内のゲートウェイ。レプリケーションに関する高負荷の演算処理や入出力処理をすべて実行。

この記事では、InMage のレプリケーション チャネルまたは Migration Accelerator を使用して ASR を初めて実装するユーザーを対象として、Process Server コンポーネントのサイズと配置について説明します。

 

Process Server とは

Process Server は、保護対象のプライマリのワークロードと同じ場所に配置されるゲートウェイ アプライアンスです。この製品は Windows Server 2012 R2 を実行している物理マシンまたは仮想マシンにデプロイされ、災害復旧のためにセカンダリの場所にレプリケーションを実行する準備として、プライマリ サイトのワークロードにおいてデータ変更の取得、圧縮、暗号化、キャッシュ、帯域幅の管理を行います。この手法では、継続的なレプリケーションに伴う高負荷の演算処理や入出力処理をすべて Process Server が実行するため、保護対象のワークロードのオーバーヘッドをほぼ完全に排除することができます。

 

Process Server の配置

これまでの経験から、ホストの負荷を軽減する InMage のアーキテクチャを最大限に活用するには、保護対象のプライマリのワークロードと同じ場所に Process Server をプロビジョニングする必要があります。こうすることで、プライマリ サイトのワークロードの演算処理や入出力処理で発生するオーバーヘッドがほぼゼロになります。

 

Process Server のサイズの決定

一般的に、Process Server のサイズは、保護対象とするすべてのワークロードで 1 日に変更されるデータの量によって決定されます。インラインでの圧縮処理や暗号化などのタスクを実行するには、十分な演算能力を確保する必要があります。また、プライマリ サイトとセカンダリ サイトの間のネットワークのボトルネックや障害を考慮して、十分なキャッシュ用ストレージをプロビジョニングする必要もあります。次の表に、参考にしていただけるガイドラインをまとめした。特に、InMage のレプリケーション チャネルまたは Migration Accelerator を使用して初めて ASR を実装する際はご活用ください。

データの変更量	CPU	メモリ容量	ブート ボリューム容量	キャッシュ ディスク サイズ	必要となるディスクの総スループット	NIC の詳細
最大 300 GB/日	4 コア	8 GB	40 GB	最低 400 GB	15 ～ 20 MB/秒	2 x 1 GigE (静的 IP あり)
最大 700 GB/日	8 コア	16 GB	40 GB	最低 790 GB	34.9 ～ 46.6 MB/秒	2 x 1 GigE (静的 IP あり)
最大 1 TB/日	8 コア	32 GB	40 GB	最低 790 GB	51.2 ～ 68.27 MB/秒	2 x 1 GigE (静的 IP あり)

 

通常、キャッシュ ディスクの入出力処理は大規模で連続的に実行されます。必要なスループットを得るためには、どちらかと言えば容量よりもキャッシュ ディスクのスピンドル数のほうが重要となります。Process Server を物理マシンにプロビジョニングする場合、FC または iSCSI の記憶域配列から十分な処理能力が得られるだけのストライピングを構成してキャッシュ用ディスクまたは LUN をプロビジョニングし、十分なスピンドル数を確保することを推奨します。Process Server を VM にプロビジョニングする場合、SAN を基礎とするブロック単位またはファイル単位のデータストアにキャッシュ用の仮想ディスクを確保する必要がありますが、それ以外は特に何もする必要はありません。変更量が 1 TB/日を超える場合、必要な数だけ Process Server を追加してスケール アウトすることをお勧めします。これに関しては、後日ブログ記事で、プロファイリングおよび処理能力計画について説明したいと思います。

 

その他の考慮事項

レプリケーションは IP ネットワークを利用して実行されるため、Process Server ではデータを送受信するポートを開く必要があります。プライマリまたはセカンダリのエンティティからのデータを受信するポートには、9080 や 9443 を使用します。また、レプリケーションのステータスと正常性をリアルタイムに更新する場合は、80 や 443 のポートを使用して Configuration Server へデータを送信します。プライマリ サイトとセカンダリ サイトのコンポーネントの間は、セキュアなサイト間 VPN トンネルまたはパブリック インターネットのいずれかを使用して、NAT IP によって Process Server のインターフェイスの 1 つと接続します。Migration Accelerator のデプロイメントの全体図と必要なポートについては、こちらのページ (英語) をご覧ください。

 

まとめ

ここまでの内容をまとめると、InMage のレプリケーション チャネルを使用して ASR 向けの Process Server をプロビジョニングする場合、そのサイズと配置は、保護対象のワークロードの数や 1 日あたりのデータの変更量などのいくつかの要因により決定されます。最良の結果が得られるように、この記事をガイドラインとしてお使いください。ご不明な点やご意見がありましたら、MSDN の Azure Site Recovery のフォーラム (英語) をご確認ください。Azure Site Recovery および VMware と物理的なワークロードを保護する能力の詳細については、手順を追って説明した記事を公開していますので、そちらをご覧ください。また、Azure Site Recovery は無料の試用版 Azure でご利用いただけます。ぜひお試しになってください。