0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

Azure Site RecoveryがPremiumSSDv2に対応したので試してみた

Last updated at Posted at 2025-10-22

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などネットワークまわりは事前に作成済みとなりますので、今回手順は割愛します。
image.png

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サイト側のリージョンを指定します。
image.png

バックアップストレージの冗長性は「ローカル冗長」を選択します。
image.png

他の項目は今回すべて既定値とします。確認して問題なければ「作成」をクリックします。
image.png

3.レプリケーションの有効化

RecoveryServiceコンテナーが作成できたら、レプリケーションの設定に移ります。
ここでは「+Site Recoveryを有効にする」をクリックします。
image.png

Azure仮想マシンに対して「1:レプリケーションを有効にする」をクリックします。
image.png

ここでは、サブスクリプションやリソースグループを選択します。
※同じEntraIDに所属していればサブスクリプション間のSiteRecoveryも可能です。
image.png

レプリケーション対象のAzureVMを選択していきます。
image.png

なお、レプリケーション対象のAzureVMは起動していないとエラーとなります。これはAgentがVMにインストールされるから当然の挙動ですね。
image.png

ここではターゲットのサブスクリプション、リソースグループ、フェールオーバー先のvNETやサブネットを指定します。
image.png

「ストレージ構成の表示/編集」をクリックした画面です。
PremiumSSDv2を接続しているAzureVMは「高チャーン」しか選択できなくなっています。対してPremiumSSDv2を利用していないAzureVMはノーマルチャーンも選択できます。
image.png

なお、VMのチャーンの変更はレプリケーションの無効化して再有効化が必要です。再度初期同期が走りますので、ご注意ください。
image.png

また、[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でもないです。)
image.png

「可用性オプションの表示/編集」をクリックした画面です。今回はこのままとします。
image.png

「管理」項目です。ここではレプリケーションポリシーと拡張機能の設定をします。
※レプリケーションポリシーと拡張機能の設定は後から設定変更可能です。
Automationアカウントは(新規)で作成します。
image.png

レプリケーションポリシーは以下の通り新規作成しました。(検証のためポリシー設定は適当に作っています。)
image.png

「レビュー」です。問題なければ「レプリケーションの有効化」をクリックします。
image.png

完了するまで待ちます。各AzureVMの初期同期が走ります。
image.png

初期同期が完了すれば、レプリケーションヘルスが [正常] となります。
image.png

ちなみに、レプリケーション対象のAzureVMのWindowsのインストール一覧をみると、AzureSiteRecovery関連のAgentが導入されています。※OS再起動は必要ありません。
image.png

キャッシュ用のストレージアカウントも本手順によって作成されますので、どのような形で作成されたか掲載しておきます。
こちらはPremiumSSDv2を利用しているVM用のキャッシュストレージです。Premium SKUです。
image.png

PremiumSSDv2を利用していない場合は、「ノーマルチャーン」が選択できます。この場合はStandard LRS v1として作成されました。
image.png

4.各VMフェールオーバー設定、復旧計画

まず、各VMごとにフェールオーバー設定をします。左ペインの「コンピューティング」「ネットワーク」「ディスク」が該当項目です。これによりDR切り替え時にわざわざインスタンスの作成から設定まで都度オペレーションする手間を省くことができます。
image.png

コンピューティングです。ターゲットのVM名や所属するリソースグループやインスタンスタイプなどが選択できます。
image.png

ネットワークです。切り替え先のvNETやNSG、サブネットを選択することができます。IPアドレスも固定した値を入れることができます。
image.png

ディスクです。ターゲットで作成されるディスクの名前を指定することが可能です。なお、ディスクタイプの指定はありませんので、レプリカマネージドディスクで指定したディスクタイプがデプロイされます。
image.png

プロパティはこんな感じです。
image.png

次に、復旧計画です。
復旧計画(Recovery Plan)は、以下のような目的で使用できます。
 - フェールオーバー対象の仮想マシン(VM)をグループ化
 - 起動順序や依存関係を定義
 - 復旧時の自動化タスク(スクリプトやRunbook)を設定
 - テストフェールオーバーの実行と検証

こちらの画面から「2:復旧計画を管理する」をクリックします。
image.png

「+復旧計画」をクリックします。
image.png

以下のような形でソースとターゲットのリージョンを入力して「項目を選択してください」をクリックします。
image.png

復旧計画に取り入れるVMを選択します。
image.png

「作成」をクリックします。
image.png

作成が完了したら「カスタマイズ」をクリックします。
image.png

VMの起動の順番など設定が可能です。設定完了したら「保存」をクリックします。
image.png

5.テストフェールオーバー

それでは、1台のVMの切り替えテストを実施してみたいとおみます。「テストフェールオーバー」をクリックします。
image.png

任意の復旧ポイントとフェールオーバー先のvNETを選択します。事前にテスト切り替え用のvNETを作成しておくことで本番のネットワークとは異なるネットワークに切り替えをすることが可能です。これにより本番への影響をなくすことが可能です。一通り指定ができたら、「テストフェールオーバー」をクリックします。
image.png

テストフェールオーバーの進捗状況が確認できます。完了すると以下の通り成功ステータスとなります。
image.png

無事、DRサイトであるJapanWest(西日本リージョン)で起動してきました。VMの名前はわかりやすく-testが付いています。
image.png

image.png

PremiumSSDv2としてデプロイされていました。(レプリカマネージドディスクではPremiumSSDとなっていたので不安要素であったのでここはよかった。)ただ、ここで気になるところが見つかりました。PremiumSSDv2の特徴のひとつとして、最大IOPSとスループットの値を指定できるのですが、既定値にリセットされてしまっています。
image.png

こちらは元のVMの設定値です。反映されていませんね。。。
image.png

一部設定が反映されないことがわかりましたが、無事テストフェールオーバーができましたので、元に戻します。「テストフェールオーバーのクリーンアップ」をクリックします。
image.png

テストが完了しました... にチェックをして、「OK」をクリックします。
image.png

切り替えテストとしてJapanWest(西日本リージョン)で作成されたVMおよび関連リソースが自動的に削除されます。
image.png

DR環境を構築してもなかなかテスト環境がなかったり、大掛かりになってテスト計画できないことがあるあるだと思いますが、このように簡単にテストとクリーンアップができるのはとてもいいですね。

復旧計画で作成したリカバリプランでもテストフェールオーバーが可能です。以下に画面キャプチャを残しておきます。

image.png
 フェイルオーバー実施結果
image.png
 クリーンアップ実施結果
image.png

6.フェールオーバー

最後にフェールオーバーをします。せっかくなので作成した復旧計画に基づきフェールオーバーをします。「フェールオーバー」をクリックします。
image.png

ソースのVMと通信できない場合は「フェールオーバーを開始する前にマシンをシャットダウンする」のチェックを外します。「OK」をクリックします。操作はこれだけです。有事の際はこれはとても助かります。
image.png

復旧計画および各VMに設定したフェールオーバー設定に基づきDRサイトへ切り替えが行われます。
image.png

無事、DRサイトである西日本リージョンにて起動してきました。
image.png

切り替えが完了後、「再保護」をすることで逆向きにレプリケーションを行うことも可能となります。
image.png

image.png

まとめ

AzureSiteRecoveryにおけるPremiumSSDv2の挙動

  • PremiumSSDv2を搭載しているVMに対しては「高チャーン」しか選択できず、キャッシュ用のストレージアカウントはPremium SKUが必要
     こちらのURLに注記がありました。
    https://learn.microsoft.com/ja-jp/azure/site-recovery/azure-to-azure-architecture
    image.png

  • レプリカマネージドディスクのタイプはPremiumSSD一択となっているものの(見積注意)、PremiumSSDv2でちゃんと切り替え先ではデプロイされる。

  • フェールオーバー後は各ディスク個別に設定可能なIOPSとスループット値が既定値にリセットされる。※幸いオンラインで値は変更可能なためフェールオーバー後に修正はしやすいかと思います。

 

 実際触ってみたことで、細かな挙動のところではありましたが、MS learnサイトでなかなか見つけられない気付きを得ることができました。PremiumSSDv2とは関係ないですが、v6インスタンスがAzureSiteRecoveryにまだ対応していなかったのは驚きました。実は最初v6インスタンスで検証していたのでレプリケーション有効化する際にエラーになってしまい、やり直しをしました。本内容がみなさまの参考になれば幸いです。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?