次の方法で共有

Azure への VMware ディザスター リカバリーについての Deployment Planner レポートを分析する

  • [アーティクル]

生成された Microsoft Excel レポートには、次のシートが含まれています。

On-Premises summary (オンプレミス サマリー)

[On-premises summary](オンプレミス サマリー) ワークシートには、プロファイリングの対象となった VMware 環境の概要が表示されます。

VMware 環境のオンプレミス サマリー

[開始日] / [終了日] : レポートの生成時に考慮されたプロファイリング データの開始日と終了日です。 既定では、プロファイリングを開始した日付が開始日に、プロファイリングを終了した日付が終了日になります。 レポートがこれらのパラメーターを使って生成される場合、これを StartDate と EndDate 値にできます。

[Total number of profiling days](プロファイリングの合計日数) :レポートの生成対象期間 (開始日から終了日まで) におけるプロファイリングの合計日数です。

Number of compatible virtual machines (適合する仮想マシンの数): 必要なネットワーク帯域幅、必要なストレージ アカウントの数、Microsoft Azure コア数、構成サーバー数、追加プロセス サーバー数が計算される、適合する VM の総数。

Total number of disks across all compatible virtual machines (適合するすべての仮想マシンのディスクの総数): デプロイで使われる構成サーバーと追加プロセス サーバーの数を決定するための入力値の 1 つとして使われる数。

Average number of disks per compatible virtual machine (適合する仮想マシン 1 台あたりの平均ディスク数): 適合するすべての仮想マシンについて計算される平均ディスク数。

Average disk size (GB) (平均ディスク サイズ (GB)): 適合するすべての仮想マシンについて計算される平均ディスク サイズ。

Desired RPO (minutes) (必要な RPO (分)): 既定の RPO、または必要な帯域幅を見積もるためにレポートの生成時に DesiredRPO パラメーターで渡された値。

Desired bandwidth (Mbps) (必要な帯域幅 (Mbps)): 達成可能な RPO を見積もるためにレポートの生成時に Bandwidth パラメーターで渡した値。

[Observed typical data churn per day (GB)](観察された 1 日あたりの標準的なデータの変更頻度 (GB)) : プロファイリングの全日数にわたって観察されたデータ変更頻度の平均値です。 この値は、デプロイで使われる構成サーバーと追加プロセス サーバーの数を決定するための入力の 1 つとして使われます。

推奨事項

VMware to Azure レポートの [Recommendations](推奨事項) シートには、[Desired RPO](必要な RPO) の選択内容に応じて、次の情報が表示されます。

Recommendations for VMware to Azure レポート

プロファイリング データ

Deployment Planner のプロファイリング データ ビュー

[Profiled data period](プロファイリング データ期間) : プロファイリングが実行された期間です。 レポート生成時に StartDate と EndDate オプションを使って特定の期間のレポートを生成しない場合は、既定で、プロファイリングされたすべてのデータがツールでの計算に使われます。

[サーバー名]: レポート生成対象の仮想マシンがある VMware vCenter または ESXi ホストの名前または IP アドレス。

[Desired RPO](必要な RPO) : ご利用のデプロイに対する回復ポイントの目標です。 既定では、15 分、30 分、60 分の 3 とおりの RPO 値について、必要なネットワーク帯域幅が計算されます。 選択した値に応じて、シート上で関連する値が更新されます。 レポートの生成中に DesiredRPOinMin パラメーターを使用した場合、その値がこの [Desired RPO (必要な RPO)] の結果に表示されます。

プロファイリングの概要

Deployment Planner のプロファイリング結果

[プロファイリングされた仮想マシンの合計]: プロファイリング データを利用できる仮想マシンの総数。 プロファイリングされなかった仮想マシンの名前が VMListFile に含まれる場合、それらの VM はレポートの生成では除外され、プロファイリング済み仮想マシンの合計数にはカウントされません。

[適合する仮想マシン]: Site Recovery を使って Azure で保護できる仮想マシンの数。 必要なネットワーク帯域幅、ストレージ アカウント数、Azure コア数、構成サーバー数、追加プロセス サーバー数の計算は、適合した仮想マシンの合計数に基づいています。 すべての適合する仮想マシンの詳細については、[適合する仮想マシン] セクションでわかります。

[適合しない仮想マシン]: プロファイリングされた仮想マシンのうち、Site Recovery での保護に適合しないものの数。 不適合の理由は、[適合しない仮想マシン] セクションに示されています。 プロファイリングされなかった仮想マシンの名前が VMListFile に含まれる場合、それらの仮想マシンは適合しない仮想マシンの数から除外されます。 これらの仮想マシンは、[適合しない仮想マシン] セクションの最後に [データが見つかりません] として列挙されます。

[Desired RPO](必要な RPO) : 必要な回復ポイントの目標 (分単位) です。 次の 3 つの RPO 値についてレポートが生成されます: 15 分 (既定値)、30 分、60 分。 シートの右上にある [Desired RPO (必要な RPO)] ボックスの一覧での選択に応じて、レポートされる推奨帯域幅が変化します。 -DesiredRPO パラメーターに独自の値を指定してレポートを生成した場合、[Desired RPO (必要な RPO)] ボックスの一覧には、その独自の値が既定値として表示されます。

必要なネットワーク帯域幅 (Mbps)

必要なネットワーク帯域幅 (Deployment Planner)

[To meet RPO 100% of the time](RPO を 100% の時間満たす場合) : 必要な RPO を 100% の時間満たす場合に割り当てる必要のある推奨帯域幅 (Mbps) です。 この帯域幅の量は、RPO 違反を回避するため、適合するすべての仮想マシンの安定状態の差分レプリケーション専用である必要があります。

[RPO を 90% の時間満たす場合]: ブロードバンドの価格やその他の要因により、目的の RPO を 100% の時間達成するために必要な帯域幅を設定できない場合は、目的の RPO を 90% の時間満たす低帯域幅の設定を選択できます。 設定する帯域幅を引き下げたことによって生じる影響を明らかにするために、レポートには RPO 違反の件数とその期間についての what-if 分析が示されます。

[達成されるスループット]: GetThroughput コマンドを実行するサーバーから、ストレージ アカウントが存在する Microsoft Azure リージョンまでのスループット。 このスループットの値は、構成サーバーまたはプロセス サーバーのストレージとネットワークの特性が、ツールを実行するサーバーのものと同じ状態のままであるとして、Site Recovery を使って適合する仮想マシンを保護するときに実現できる推定レベルを示します。

レプリケーションに関しては、RPO を 100% の時間満たすうえで推奨される帯域幅を設定してください。 必要な帯域幅を設定したにもかかわらず、ツールから報告される達成スループットに改善が見られない場合は、次の作業を行ってください。

  1. Site Recovery のスループットを制限するネットワーク QoS (サービス品質) が存在しているかどうかを確認します。

  2. 物理的にサポートされる最も近い Microsoft Azure リージョンに Site Recovery コンテナーが存在し、ネットワーク待ち時間が最小限で済んでいるかどうかを確認します。

  3. ローカル ストレージの特性を確認し、ハードウェアの強化 (例: HDD から SSD など) が可能であるかどうかを調べます。

  4. レプリケーションに使用されるネットワーク帯域幅を増やすために、プロセス サーバーで Site Recovery の設定を変更します。

既に保護された仮想マシンがある構成サーバーまたはプロセス サーバーでツールを実行する場合は、ツールを何回か実行します。 達成されるスループットの値は、その時点で処理されているチャーンの量に応じて変化します。

企業による Site Recovery のデプロイでは、常に ExpressRoute を使用することをお勧めします。

必要なストレージ アカウント

次のグラフは、すべての適合する仮想マシンを保護するために必要なストレージ アカウント (Standard と Premium) の総数を示したものです。 各仮想マシンで使用するストレージ アカウントを確認するには、[VM ストレージの配置] セクションを参照します。 Deployment Planner の v2.5 を使っている場合は、データが Managed Disks に直接書き込まれるため、この推奨事項では、レプリケーションに必要な Standard キャッシュ ストレージ アカウントの数のみが示されます。

必要なストレージ アカウント (Deployment Planner)

必要な Azure コア数

この結果は、適合するすべての仮想マシンのフェールオーバーまたはテスト フェールオーバーの前にセットアップされるコアの総数です。 サブスクリプションで利用できるコアが少なすぎる場合、Site Recovery はテスト フェールオーバーまたはフェールオーバー時に仮想マシンを作成できません。

必要な Azure のコア数 (Deployment Planner)

必要なオンプレミス インフラストラクチャ

この値は、適合するすべての仮想マシンを保護するのに十分な、構成すべき構成サーバーと追加プロセス サーバーの総数です。 サポートされる構成サーバーの推奨サイズに応じて、追加のサーバーがツールで推奨されます。 この推奨事項は、構成サーバーまたは追加プロセス サーバーが最初に到達する、1 日あたりのチャーン、または保護対象仮想マシンの最大数 (仮想マシンごとに平均 3 台のディスクを想定) のどちらか大きい方に基づきます。 1 日あたりの総変更頻度と保護対象ディスクの総数の詳細については、[On-premises summary](オンプレミス サマリー) セクションに記載されています。

必要なオンプレミス インフラストラクチャ (Deployment Planner)

What-if 分析

What-if 分析は、設定する帯域幅を引き下げて、必要な RPO を 90% の時間だけ満たすようにしたとき、プロファイリング期間中、おおよそ何件の違反が発生するかを可能性として提示するものです。 RPO 違反は日々生じることが考えられ、 グラフにはそれぞれの日のピーク RPO が表示されます。 この分析結果を見て、RPO 違反がすべての日にわたって存在しているかどうか、また、帯域幅を 100% から引き下げた場合の 1 日のピーク RPO が許容範囲内にあるかどうかを判断することができます。 許容できる場合は、レプリケーションにより低い帯域幅を割り当て、それ以外の場合は必要な RPO を 100% の時間満たすように、より高い帯域幅を割り当てることができます。

What-if 分析 (Deployment Planner)

このセクションでは、必要な RPO を 100% の時間満たすことのできる推奨帯域幅を使い、並列に保護して初期レプリケーションを 72 時間以内に完了できる、仮想マシンの推奨台数が示されます。 この値は設定によって変更することができます。 レポートの生成時に変更するには、GoalToCompleteIR パラメーターを使用します。

ここのグラフでは、適合するすべての仮想マシンについて検出された平均仮想マシン サイズに基づき、初期レプリケーションを 72 時間以内に完了するための、帯域幅の値の範囲と計算された仮想マシンのバッチ サイズ カウントが示されます。

パブリック プレビューのレポートでは、バッチに含める必要のある仮想マシンは指定されません。 [適合する VM] セクションで示されるディスク サイズを使って各仮想マシンのサイズを確認してバッチに含めるものを選ぶか、既知のワークロード特性に基づいて仮想マシンを選ぶことができます。 初期レプリケーションが完了するまでの時間は、仮想マシンの実際のディスク サイズ、使われているディスク領域、利用できるネットワーク スループットに比例して変化します。

推奨される仮想マシン バッチ サイズ

コスト見積もり

このグラフは、選択したターゲット リージョンの Azure に対するディザスター リカバリー (DR) の総コスト見積もりの概要と、レポート生成に関して指定された通貨を示しています。

コスト見積もりの概要

この概要は、Azure Site Recovery を使用して、互換性のあるすべての仮想マシンを Azure に保護する場合に、ストレージ、コンピューティング、ネットワーク、ライセンスに対して支払う必要があるコストを把握するのに役立ちます。 コストは、互換性のある仮想マシンについて計算され、プロファイリングされたすべての仮想マシンに関しては計算されません。

コストは月単位または年単位で表示することができます。 詳細については、「サポートされるターゲット リージョン」と「サポートされる通貨」を参照してください。

[Cost by components](コンポーネントごとのコスト) DR コストの合計は次の 4 つのコンポーネントに分けられます: コンピューティング、ストレージ、ネットワーク、Azure Site Recovery ライセンス コスト。 このコストは、コンピューティング、ストレージ (Premium と Standard)、オンプレミス サイトと Azure の間に構成されている ExpressRoute/VPN、Azure Site Recovery ライセンスに関して、レプリケーション中および DR ドリル時に発生する消費量に基づいて計算されます。

[Cost by states](状態ごとのコスト) ディザスター リカバリー (DR) の合計コストが、レプリケーションと DR ドリルという 2 種類の状態に基づいて分類されます。

[Replication cost]\(レプリケーション コスト\): レプリケーション時に発生するコスト。 ストレージ、ネットワーク、Azure Site Recovery ライセンスのコストが含まれます。

[DR-Drill cost](DR ドリル コスト): テスト フェールオーバー時に発生するコスト。 テスト フェールオーバー中は、Azure Site Recovery によって仮想マシンがスピンアップされます。 DR ドリルのコストには、実行中の仮想マシンのコンピューティング コストとストレージ コストが含まれます。

月および年あたりの Azure ストレージ コスト Premium ストレージと Standard ストレージに関して、レプリケーションと DR ドリルで生じる合計ストレージ コストが表示されます。 [コスト見積もり] シートでは、仮想マシンごとの詳細なコスト分析を確認できます。

増加率と使用パーセンタイル値

シートの一番下にあるこのセクションでは、プロファイリング対象の仮想マシンのすべてのパフォーマンス カウンターに使われるパーセンタイル値 (既定値は 95 パーセンタイル) と、すべての計算に使われる増加率 (既定値は 30 パーセント) が示されます。

増加率と使用パーセンタイル値

使用可能な帯域幅の入力に関する推奨事項

使用可能な帯域幅の入力に関する推奨事項

Site Recovery のレプリケーション用に設定できる帯域幅 (Mbps) の上限があらかじめわかっているケースもあるでしょう。 Deployment Planner ツールでは、使用可能な帯域幅を (レポートの生成中に -Bandwidth パラメーターで) 入力し、達成可能な RPO (分) を取得することができます。 この達成可能な RPO 値を元に、さらに帯域幅を設定する必要があるか、またはこの RPO でディザスター リカバリー ソリューションに問題がないかを決定できます。

500 Mbps の帯域幅で達成可能な RPO

仮想マシンのストレージの配置

Note

Deployment Planner v 2.5 以降では、マネージド ディスクに直接レプリケートするマシンへのストレージの配置を推奨しています。

仮想マシンのストレージの配置

[レプリケーション ストレージの種類]: Standard または Premium マネージド ディスク。[配置する VM] 列で示されている対応するすべての仮想マシンをレプリケートするために使われます。

Log Storage Account Type (ログ ストレージ アカウントの種類) :レプリケーションのログはすべて Standard ストレージ アカウントに格納されます。

Suggested Prefix for Storage Account (ストレージ アカウントに推奨されるプレフィックス) :キャッシュ ストレージ アカウントに名前を付ける場合に使用できる 3 文字の推奨プレフィックスです。 独自のプレフィックスを使用することもできますが、ストレージ アカウントのパーティションの名前付け規則に準拠したプレフィックスがツールから提案されます。

[Suggested Log Account Name](推奨ログ アカウント名) : 推奨されるプレフィックスを付けた後のストレージ アカウント名です。 山かっこ (< と >) で囲まれた名前は、カスタムの入力値に置き換えてください。

[配置の概要]: 保護される仮想マシンに必要なディスクの、ストレージの種類別の概要。 これには、仮想マシンの総数、すべてのディスクでプロビジョニングされる合計サイズ、ディスクの総数が含まれます。

[配置する仮想マシン]: 最善のパフォーマンスと使用のために、特定のストレージ アカウントに配置する必要があるすべての仮想マシンのリスト。

適合する仮想マシン

適合する仮想マシンの Excel スプレッドシート

[仮想マシン名]: レポートの生成時に VMListFile で使われた仮想マシンの名前または IP アドレス。 この列には、仮想マシンにアタッチされているディスク (VMDK) の一覧も表示されます。 名前または IP アドレスが重複する vCenter の仮想マシンを区別するため、名前には ESXi ホスト名が含まれます。 一覧に表示される ESXi ホストは、プロファイリング期間中にツールによって検出されたときに仮想マシンが配置されていたものです。

[仮想マシンの適合性]: 値は [はい] と [はい*] です。 [はい*] は、仮想マシンが Premium SSD に適しているインスタンスを示します。 この場合、プロファイリングされたチャーンまたは 1 秒あたり入出力操作数 (IOPS) が高いディスクは P20 または P30 のカテゴリに適しますが、ディスク サイズのためにそれより低い P10 または P20 にマッピングされます。 ストレージ アカウントでは、Premium Storage のディスク タイプが、そのサイズに基づいて決定されます。 次に例を示します。

  • <128 GB の場合は P10
  • 128 ～ 256 GB の場合は P15
  • 256 ～ 512 GB の場合は P20
  • 512 ～ 1,024 GB の場合は P30
  • 1,025 ～ 2,048 GB の場合は P40
  • 2,049 ～ 4,095 GB の場合は P50

たとえば、ディスクのワークロード特性は P20 または P30 カテゴリであっても、サイズのためにそれより低い Premium Storage ディスク タイプに対応している場合、ツールはその仮想マシンを [はい*] とマークします。 そのうえで、推奨される適切な Premium Storage ディスク タイプに合わせてレプリケーション元のディスク サイズを変更するか、またはレプリケーション先のディスク タイプをフェールオーバー後に変更するように促されます。

[ストレージの種類]: Standard または Premium があります。

Asrseeddisk (Managed Disk) created for replication (レプリケーション用に作成された Asrseeddisk (マネージド ディスク)) :レプリケーションを有効にしたときに作成されるディスクの名前。 データとそのスナップショットが Azure に格納されます。

[Peak R/W IOPS (with Growth Factor) (読み取り/書き込み IOPS のピーク (増加率を考慮))]: 将来的な増加率 (既定では 30 %) を加味した、ディスクに対するピーク ワークロードの読み取り/書き込み IOPS (既定では 95 パーセンタイル) です。 仮想マシンの合計読み取り/書き込み IOPS が、個々のディスクの読み取り/書き込み IOPS を足した値になるとは限りません。これは、仮想マシンのピーク読み取り/書き込み IOPS は、プロファイリング期間を通じた個々のディスクの読み取り/書き込み IOPS の合計のピークであるためです。

[Peak Data Churn in Mbps (with Growth Factor) ( データの変更頻度のピーク (Mbps) (増加率を考慮))]: 将来的な増加率 (既定では 30%) を加味した、ディスクに対する変更頻度のピーク値 (既定では 95 パーセンタイル) です。 仮想マシンの合計データ チャーンは、個々のディスクのデータ チャーンを足した値になるとは限りません。これは、仮想マシンのピーク データ チャーンは、プロファイリング期間を通じた個々のディスクのチャーンの合計のピークであるためです。

[Azure 仮想マシン サイズ]: このオンプレミス仮想マシンに対応する最適な Azure Cloud Services 仮想マシンのサイズ。 この対応は、オンプレミス仮想マシンのメモリ、ディスク数、コア数、NIC 数、読み取り/書き込み IOPS に基づきます。 推奨されるのは、常に、オンプレミス仮想マシンのすべての特性と一致する最小の Azure 仮想マシンのサイズです。

[ディスク数]: 仮想マシンの仮想マシン ディスク (VMDK) の総数。

[ディスク サイズ (GB)]: 仮想マシンの全ディスクの合計セットアップ サイズ。 仮想マシンに含まれる個々のディスクのサイズも表示されます。

[コア数]: 仮想マシンの CPU コアの数。

[メモリ (MB)]: 仮想マシンの RAM。

[NIC 数]: 仮想マシンの NIC の数。

[ブートの種類]: 仮想マシンのブートの種類。 BIOS と EFI のどちらかになります。 現在、Azure Site Recovery では、ブート ディスク内のパーティションの数が 4 未満で、ブート セクターのサイズが 512 バイトの場合に、Windows Server EFI 仮想マシン (Windows Server 2012、2012 R2、2016) がサポートされます。 EFI 仮想マシンを保護するには、Azure Site Recovery Mobility Service バージョン 9.13 以降が必要です。 EFI 仮想マシンではフェールオーバーのみがサポートされます。 フェールバックはサポートされていません。

[OS の種類]: 仮想マシンの OS の種類。 これは、仮想マシンの作成時に VMware vSphere で選択されたテンプレートに基づいて、Windows、Linux、またはその他です。

互換性のない仮想マシン

適合しない仮想マシンの Excel スプレッドシート

[仮想マシン名]: レポートの生成時に VMListFile で使われた仮想マシンの名前または IP アドレス。 この列には、仮想マシンにアタッチされている VMDK の一覧も表示されます。 名前または IP アドレスが重複する vCenter の仮想マシンを区別するため、名前には ESXi ホスト名が含まれます。 一覧に表示される ESXi ホストは、プロファイリング期間中にツールによって検出されたときに仮想マシンが配置されていたものです。

[仮想マシンの適合性]: 特定の仮想マシンが Site Recovery での使用に適合していない理由を示します。 理由は仮想マシンの適合しないディスクごとに示されており、公開されているストレージの制限に基づいて、次のいずれかになります。

  • データ ディスク サイズが間違っているか、OS ディスク サイズが間違っている。 サポートの制限を確認してください。

  • 仮想マシンの合計サイズ (レプリケーション + TFO) が、サポートされているストレージ アカウントの上限サイズ (35 TB) を超えています。 この不適合は、通常、仮想マシンの 1 台のディスクのパフォーマンス特性が、Azure または Site Recovery でサポートされる Standard ストレージの上限を超えている場合に発生します。 そのようなインスタンスの仮想マシンは Premium Storage ゾーンになります。 ただし、Premium ストレージ アカウントでサポートされる最大サイズは 35 TB であり、保護対象の単一の仮想マシンを、複数のストレージ アカウントにまたがって保護することはできません。 また、テスト フェールオーバーが保護対象の仮想マシンで実行されるときは、レプリケーションが進行しているのと同じストレージ アカウントで実行されることに注意してください。 この場合、レプリケーションの進行と同時にテスト フェールオーバーが正常完了するためには、対象となるディスク サイズの 2 倍の容量をセットアップする必要があります。

  • レプリケーション元の IOPS が、ストレージでサポートされている IOPS の上限 (ディスクあたり 7,500 IOPS) を超えている。

  • ソースの IOPS が、サポートされているストレージ IOPS 制限 (仮想マシンあたり 80,000) を超えています。

  • 平均データ変更頻度が、Site Recovery でサポートされているデータ変更頻度の上限 (ディスクの平均 I/O サイズで 20 MB/秒) を超えている。

  • 仮想マシンの全ディスクでのピーク データ チャーンが、Site Recovery でサポートされるピーク データ チャーンの上限 (仮想マシンあたり 54 MB/秒) を超えています。

  • 平均実効書き込み IOPS が、Site Recovery でサポートされるディスク IOPS の上限 (840) を超えている。

  • 算出されたスナップショット ストレージが、スナップショット ストレージに関してサポートされている上限 (10 TB) を超えている。

  • 1 日あたりの総データ変更頻度が、プロセス サーバーでサポートされる 1 日あたりの変更頻度の上限 (2 TB) を超えている。

[Peak R/W IOPS (with Growth Factor)](ピーク読み取り/書き込み IOPS (増加率を考慮)): 将来的な増加率 (既定では 30%) を加味した、ディスクに対するピーク ワークロードの IOPS (既定では 95 パーセンタイル) です。 仮想マシンの合計読み取り/書き込み IOPS が、個々のディスクの読み取り/書き込み IOPS を足した値になるとは限りません。これは、仮想マシンのピーク読み取り/書き込み IOPS は、プロファイリング期間を通じた個々のディスクの読み取り/書き込み IOPS の合計のピークであるためです。

[Peak Data Churn in Mbps (with Growth Factor)](データの変更頻度のピーク (Mbps) (増加率を考慮)): 将来的な増加率 (既定では 30%) を加味した、ディスクに対する変更頻度のピーク値 (既定では 95 パーセンタイル) です。 仮想マシンの合計データ チャーンは、個々のディスクのデータ チャーンを足した値になるとは限りません。これは、仮想マシンのピーク データ チャーンは、プロファイリング期間を通じた個々のディスクのチャーンの合計のピークであるためです。

[ディスク数]: 仮想マシンの VMDK の総数。

[ディスク サイズ (GB)]: 仮想マシンの全ディスクの合計セットアップ サイズ。 仮想マシンに含まれる個々のディスクのサイズも表示されます。

[コア数]: 仮想マシンの CPU コアの数。

[メモリ (MB)]: 仮想マシンの RAM の量。

[NIC 数]: 仮想マシンの NIC の数。

[ブートの種類]: 仮想マシンのブートの種類。 BIOS と EFI のどちらかになります。 現在、Azure Site Recovery では、ブート ディスク内のパーティションの数が 4 未満で、ブート セクターのサイズが 512 バイトの場合に、Windows Server EFI 仮想マシン (Windows Server 2012、2012 R2、2016) がサポートされます。 EFI 仮想マシンを保護するには、Azure Site Recovery Mobility Service バージョン 9.13 以降が必要です。 EFI 仮想マシンではフェールオーバーのみがサポートされます。 フェールバックはサポートされていません。

[OS の種類]: 仮想マシンの OS の種類。 これは、仮想マシンの作成時に VMware vSphere で選択されたテンプレートに基づいて、Windows、Linux、またはその他です。

Azure Site Recovery の制限

以下の表は、Azure Site Recovery の制限を示したものです。 上記の制限は、弊社のテストに基づいて公開されていますが、アプリケーション I/O として想定されるすべての組み合わせを網羅したものではありません。 実際の結果は、ご使用のアプリケーションで発生するさまざまな I/O によって異なることが考えられます。 理想的な結果を得るために、デプロイ計画後も必ず、テスト フェールオーバーを実行してアプリケーションのテストを徹底し、そのパフォーマンスの真の姿を把握することをお勧めします。

レプリケーション先のストレージ レプリケーション元の平均ディスク I/O サイズ レプリケーション元ディスクの平均データ変更頻度 レプリケーション元ディスクの 1 日あたりのデータ変更頻度合計
Standard Storage 8 KB 2 MB/秒 (ディスクあたり) 168 GB
Premium P10 または P15 ディスク 8 KB 2 MB/秒 (ディスクあたり) 168 GB
Premium P10 または P15 ディスク 16 KB 4 MB/秒 (ディスクあたり) 336 GB
Premium P10 または P15 ディスク 32 KB 以上 8 MB/秒 (ディスクあたり) 672 GB
Premium P20、P30、P40、または P50 ディスク 8 KB 5 MB/s (ディスクあたり) 421 GB
Premium P20、P30、P40、または P50 ディスク 16 KB 以上 20 MB/秒 (ディスクあたり) 1,684 GB
ソース データ変更頻度 上限
仮想マシンの全ディスクにおけるピーク データ チャーン 54 MB/秒
プロセス サーバーでサポートされる 1 日あたりのデータ変更頻度の上限 2 TB

前述の数値は、I/O のオーバーラップを 30% とした場合の平均値です。 Site Recovery は、オーバーラップ比に基づくより高いスループットと、より大きな書き込みサイズ、そして実ワークロード I/O 動作を扱うことができます。 上記の数値には、標準的なバックログとして約 5 分が想定されています。 つまりデータはアップロード後 5 分以内に処理されて復旧ポイントが作成されます。

コスト見積もり

コスト見積もりについて詳しい情報をご覧ください。

次のステップ

コスト見積もりについて詳しい情報をご覧ください。