2025年9月から「PremiumSSDv2」が Azure Site Recovery でサポートされるようになりました。
PremiumSSDv2とは以下の特徴があります。
・主な特徴
- ディスク容量は最小 1 GiB から最大 64 TiB で構成(拡張)可能
- 標準 3,000 IOPS , 125 MB/秒 ベースライン パフォーマンスを提供
- 最大 80,000 IOPS , 1,200 MB/秒 まで拡張可
- オンラインでのIOPSとスループット値の変更が可能
・ サポート
- 東日本リージョン、西日本リージョンで利用可能
- Azure Backup 利用可 (リージョン間コピー可)
- Azure Migrate の移行先ディスクとして利用可
- Azure Site Recovery で利用可
・ 価格
- ディスク容量 $0.097/GiB
- IOPS (3,000 IOPS を超える分) $0.0059/IOPS
- スループット (125 MB/s を超える分) $0.049/MBper秒
従来の Premium SSD と同容量、同性能で比較した場合、安価で利用できます。
・ 制約
- データ・ディスクとしてのみ利用可 (OS ディスクとしては利用不可)
- AzureBackupファイルレベルの復元は非サポート(ちと痛い、、、)
- ホスト・キャッシュは非サポート
- LRS (ローカル冗長ストレージ) 構成のみサポート
- 「ゾーン VM」にのみ接続可で「可用性セットのVM」には接続不可
- ディスクサイズ変更には VM 停止が必要
一部制約はあるものの、総じてPremiumSSDよりも容量指定の柔軟性があり、かつ安価に利用できますので、パフォーマンス要求が高いサーバに積極的に使っていきたいところです。そのような中で、ようやくAzureSiteRecoveryへの対応が発表されましたので、試してみました。
検証環境
今回の検証環境となります。
vNETやSubnetなどネットワークまわりは事前に作成済みとなりますので、今回手順は割愛します。
1.事前確認&準備
AzureSiteRecoveryを利用する前には必ずこちらを確認ください。意外と非サポート構成となる落とし穴があります。
Azure リージョン間での Azure VM ディザスター リカバリーに関するサポート マトリックス
https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-support-matrix#replicated-machines---compute-settings
AzureSiteRecovery対象のAzureVMもネットワーク通信要件がありますので、こちらのURLを確認ください。※レプリケーショントラフィックはVMからではなくAzure基盤のバックグラウンド処理となります。AzureVMのトラフィックは主にAzureSiteRecoveryの管理トラフィックになります。
https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-tutorial-enable-replication
個人的に遭遇しやすい考慮事項は以下かなと思いました。
・ネットワーク接続を制御するための認証プロキシの使用をサポートしていません。
・Azure Site Recovery のドライバーは、RAM の 6% を消費します。
・NVMe ストレージ インターフェイスがサポートされていない。
→v6シリーズのインスタンスは軒並みNGです。。。
なお、今回はAzureサブスクリプション「所有者」権限で実施しています。
では、やっていきましょう。
2.RecoveryServiceコンテナーの作成
AzureSiteRecoveryの要であるRecoveryServiceコンテナーを新規作成していきます。リージョンはDRサイト側のリージョンを指定します。
バックアップストレージの冗長性は「ローカル冗長」を選択します。
他の項目は今回すべて既定値とします。確認して問題なければ「作成」をクリックします。
3.レプリケーションの有効化
RecoveryServiceコンテナーが作成できたら、レプリケーションの設定に移ります。
ここでは「+Site Recoveryを有効にする」をクリックします。
Azure仮想マシンに対して「1:レプリケーションを有効にする」をクリックします。
ここでは、サブスクリプションやリソースグループを選択します。
※同じEntraIDに所属していればサブスクリプション間のSiteRecoveryも可能です。
なお、レプリケーション対象のAzureVMは起動していないとエラーとなります。これはAgentがVMにインストールされるから当然の挙動ですね。
ここではターゲットのサブスクリプション、リソースグループ、フェールオーバー先のvNETやサブネットを指定します。
「ストレージ構成の表示/編集」をクリックした画面です。
PremiumSSDv2を接続しているAzureVMは「高チャーン」しか選択できなくなっています。対してPremiumSSDv2を利用していないAzureVMはノーマルチャーンも選択できます。
なお、VMのチャーンの変更はレプリケーションの無効化して再有効化が必要です。再度初期同期が走りますので、ご注意ください。
また、[Normal Churn] (通常のチャーン) オプションでは、VM あたり最大 54 MB/秒しかサポートできません。[High Churn] (高チャーン)にすることでVM あたり最大 100 MB/秒まで可能です。選択の指標としてください。
https://learn.microsoft.com/ja-jp/azure/site-recovery/concepts-azure-to-azure-high-churn-support
キャッシュストレージを見てみます。PremiumSSDv2を利用しているVMのキャッシュストレージはPremiumLRSとなっています。PremiumSSDv2接続のAzureVMをレプリケーションする場合はどうやらこれしか選択肢がないようです。
ちなみに、PremiumSSDv2以外はレプリカマネージドディスクのタイプは任意の選択が可能ですが、PremiumSSDv2はPremiumSSD一択の模様です。(PremiumSSDv2でもないです。)
「可用性オプションの表示/編集」をクリックした画面です。今回はこのままとします。
「管理」項目です。ここではレプリケーションポリシーと拡張機能の設定をします。
※レプリケーションポリシーと拡張機能の設定は後から設定変更可能です。
Automationアカウントは(新規)で作成します。
レプリケーションポリシーは以下の通り新規作成しました。(検証のためポリシー設定は適当に作っています。)
「レビュー」です。問題なければ「レプリケーションの有効化」をクリックします。
完了するまで待ちます。各AzureVMの初期同期が走ります。
初期同期が完了すれば、レプリケーションヘルスが [正常] となります。
ちなみに、レプリケーション対象のAzureVMのWindowsのインストール一覧をみると、AzureSiteRecovery関連のAgentが導入されています。※OS再起動は必要ありません。
キャッシュ用のストレージアカウントも本手順によって作成されますので、どのような形で作成されたか掲載しておきます。
こちらはPremiumSSDv2を利用しているVM用のキャッシュストレージです。Premium SKUです。
PremiumSSDv2を利用していない場合は、「ノーマルチャーン」が選択できます。この場合はStandard LRS v1として作成されました。
4.各VMフェールオーバー設定、復旧計画
まず、各VMごとにフェールオーバー設定をします。左ペインの「コンピューティング」「ネットワーク」「ディスク」が該当項目です。これによりDR切り替え時にわざわざインスタンスの作成から設定まで都度オペレーションする手間を省くことができます。
コンピューティングです。ターゲットのVM名や所属するリソースグループやインスタンスタイプなどが選択できます。
ネットワークです。切り替え先のvNETやNSG、サブネットを選択することができます。IPアドレスも固定した値を入れることができます。
ディスクです。ターゲットで作成されるディスクの名前を指定することが可能です。なお、ディスクタイプの指定はありませんので、レプリカマネージドディスクで指定したディスクタイプがデプロイされます。
次に、復旧計画です。
復旧計画(Recovery Plan)は、以下のような目的で使用できます。
- フェールオーバー対象の仮想マシン(VM)をグループ化
- 起動順序や依存関係を定義
- 復旧時の自動化タスク(スクリプトやRunbook)を設定
- テストフェールオーバーの実行と検証
こちらの画面から「2:復旧計画を管理する」をクリックします。
以下のような形でソースとターゲットのリージョンを入力して「項目を選択してください」をクリックします。
VMの起動の順番など設定が可能です。設定完了したら「保存」をクリックします。
5.テストフェールオーバー
それでは、1台のVMの切り替えテストを実施してみたいとおみます。「テストフェールオーバー」をクリックします。
任意の復旧ポイントとフェールオーバー先のvNETを選択します。事前にテスト切り替え用のvNETを作成しておくことで本番のネットワークとは異なるネットワークに切り替えをすることが可能です。これにより本番への影響をなくすことが可能です。一通り指定ができたら、「テストフェールオーバー」をクリックします。
テストフェールオーバーの進捗状況が確認できます。完了すると以下の通り成功ステータスとなります。
無事、DRサイトであるJapanWest(西日本リージョン)で起動してきました。VMの名前はわかりやすく-testが付いています。
PremiumSSDv2としてデプロイされていました。(レプリカマネージドディスクではPremiumSSDとなっていたので不安要素であったのでここはよかった。)ただ、ここで気になるところが見つかりました。PremiumSSDv2の特徴のひとつとして、最大IOPSとスループットの値を指定できるのですが、既定値にリセットされてしまっています。
一部設定が反映されないことがわかりましたが、無事テストフェールオーバーができましたので、元に戻します。「テストフェールオーバーのクリーンアップ」をクリックします。
テストが完了しました... にチェックをして、「OK」をクリックします。
切り替えテストとしてJapanWest(西日本リージョン)で作成されたVMおよび関連リソースが自動的に削除されます。
DR環境を構築してもなかなかテスト環境がなかったり、大掛かりになってテスト計画できないことがあるあるだと思いますが、このように簡単にテストとクリーンアップができるのはとてもいいですね。
復旧計画で作成したリカバリプランでもテストフェールオーバーが可能です。以下に画面キャプチャを残しておきます。
6.フェールオーバー
最後にフェールオーバーをします。せっかくなので作成した復旧計画に基づきフェールオーバーをします。「フェールオーバー」をクリックします。
ソースのVMと通信できない場合は「フェールオーバーを開始する前にマシンをシャットダウンする」のチェックを外します。「OK」をクリックします。操作はこれだけです。有事の際はこれはとても助かります。
復旧計画および各VMに設定したフェールオーバー設定に基づきDRサイトへ切り替えが行われます。
無事、DRサイトである西日本リージョンにて起動してきました。
切り替えが完了後、「再保護」をすることで逆向きにレプリケーションを行うことも可能となります。
まとめ
AzureSiteRecoveryにおけるPremiumSSDv2の挙動
-
PremiumSSDv2を搭載しているVMに対しては「高チャーン」しか選択できず、キャッシュ用のストレージアカウントはPremium SKUが必要
こちらのURLに注記がありました。
https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-architecture
-
レプリカマネージドディスクのタイプはPremiumSSD一択となっているものの(見積注意)、PremiumSSDv2でちゃんと切り替え先ではデプロイされる。
-
フェールオーバー後は各ディスク個別に設定可能なIOPSとスループット値が既定値にリセットされる。※幸いオンラインで値は変更可能なためフェールオーバー後に修正はしやすいかと思います。
実際触ってみたことで、細かな挙動のところではありましたが、MS learnサイトでなかなか見つけられない気付きを得ることができました。PremiumSSDv2とは関係ないですが、v6インスタンスがAzureSiteRecoveryにまだ対応していなかったのは驚きました。実は最初v6インスタンスで検証していたのでレプリケーション有効化する際にエラーになってしまい、やり直しをしました。本内容がみなさまの参考になれば幸いです。