ラベル Azure Site Recovery の投稿を表示しています。 すべての投稿を表示
ラベル Azure Site Recovery の投稿を表示しています。 すべての投稿を表示

2022年1月30日日曜日

Azure Policy support for Azure Site Recovery だそうです

Generally available: Azure Policy support for Azure Site Recovery

という記事を見つけました。

Azure Site Recovery 用の Azure Policy というわけですね。Azure Policy から Site Recover だけをフィルターしたところ、現状下記のポリシーがありました。(ちなみにイニシアティブは無し)


  • [プレビュー]: Recovery Services コンテナーではプライベート リンクを使用する必要がある
  • [プレビュー]: プライベート DNS ゾーンを使用するよう Azure Recovery Services コンテナーを構成する
  • [プレビュー]: プライベート エンドポイントを Azure Recovery Services コンテナーに構成する
現状は、プライベートリンクやプライベート DNS ゾーンの使用を強制するためのポリシーが用意されていました。今後、増えていくかもしれませんね。

2020年8月1日土曜日

Windows Admin Center 2007 のお話

System Center User Group Japan 第22回 勉強会 のセッション資料、動画を公開させていただきます。
動画については、オンライン配信中に聞こえづらかったと伺っております。上記のスライド、動画をあわせて確認いただけますと幸いです。

2020年5月10日日曜日

SCDPM と ASR Agent は競合するのか

ふと思い立ち、物理サーバーに SCDPM 2019 をインストールした際のお話。

この物理サーバーには、SCOM コンソールなどいろいろ入っていたので、ちょっと整理していたのですが。

まず、廃止してしまった SCDPM の保護エージェントが入ったままで、SCDPM のインストール時に引っ掛かりました。これはそういうものだと思うので、直ちにアンインストール。

で、OS 保護用に Azure Site Recovery エージェントを入れていました。
こちらも、SCDPM のインストール時に引っ掛かるという。。。

※SSRS が止まっているところは無視してくださいね。

気を付けましょう。

2020年5月6日水曜日

Azure Site Recovery Provider の登録時エラー

再登録時エラーといったほうが良いかもしれませんね。

上記の画像ですが、Azure Site Recovery Provider にて登録を進めておりました。ただこの環境は、以前、Azure Site Recovery に登録したことがあります。

調べたところ、
Remove servers and disable protection

Unregister a Hyper-V host in a Hyper-V Site
が見つかりました。

このスクリプトを実行してやると、過去の情報を削除できるようです。


無事に登録できました!

2020年3月14日土曜日

Azure Site Recovery で SCVMM を使った セカンダリサイトへのレプリケーションが、約3年後に廃止されるので

Azure Site Recovery の 一部オプションが今後段階的に廃止されます。
で記載した通り、Azure Site Recovery で SCVMM を使った セカンダリサイトへのレプリケーションが2023年3月1日に廃止されます。

Azure Site Recovery で SCVMM を使った セカンダリサイトへのレプリケーション
については、管理部分をAzure Site Recovery に置いているものであり、レプリケーション自体は、Hyper-V レプリカを使用しています。
アーキテクチャ - セカンダリ サイトへの Hyper-V のレプリケーション
に記載されている概念図を見ていただけると理解しやすいです!

Azure Site Recovery に管理部分があるので、DR構成を一括で行えていたわけです。
では、この部分が2023年3月1日に廃止されるということは、レプリケーション自体は、Hyper-V レプリカを使用し続けるということになります。
Azure Site Recovery を使用したカスタマー マネージド サイト間での (VMM による) ディザスター リカバリーの廃止
に記載の代替オプション2を今後計画していく必要があるということです。
代替オプションの文面を下記に引用します。
オプション 2:サイト間レプリケーションを、基本的な Hyper-Hyper-V レプリカ ソリューションを使用して続行することを選択します。ただし、Azure portal で Azure Site Recovery を使用して DR 構成を管理することはできません。
※ちなみに、代替オプション1は、Hyper-V から Azure にレプリケーションする方法です。

2020/03/14時点の画面で確認しておきます。(言うまでもないですが、Azure は継続的に改良されるため、2023年3月1日に同じ画面になっているかは不明です)

レプリケーションアイテムをクリックし、[レプリケーションの無効化]をクリックします。


[レプリケーションを無効にして削除]が通常のやり方です。今回はこちらで実施しません。このやり方は、仮想マシンのレプリケーション(Hyper-Vレプリカ)を削除してから、レプリケーションアイテムを削除するという方法だからです。


[削除]を選択します。
こちらは、仮想マシンのレプリケーション(Hyper-Vレプリカ)を削除しないで、レプリケーションアイテムを削除する方法です。これにより、レプリケーションアイテムは削除されますが、仮想マシンのレプリケーション(Hyper-Vレプリカ)は残ります。
本来の目的は、警告アイコンにも書かれている通り、ソースの環境に接続できない場合に用いるオプションですね。

[OK]を押すと、削除が開始します。

削除されました。


Hyper-Vレプリカが残っていることを確認できました!


この移行作業は、レプリケーションアイテムごとに、作業します。つまり、レプリケーションアイテムが多いと、結構な手間になると思います。
移行パスとしては、少々面倒ではありますが、これまでのレプリケーションポリシーをそのまま使い続けるという点では、メリットがありますね。

2020年3月7日土曜日

Azure Site Recovery の 一部オプションが今後段階的に廃止されます。

2023 年 3 月 1 日に Azure Site Recovery のサポート オプションの一部が廃止に
を見かけました。

せっかくなので、上記含め、2020/03/07時点におけるサポートオプションの方向性を確認してみました。
下記に整理しておきますので、参考になさってください。誤り等は適宜修正するので、コメントいただけると幸いです。

2019年6月6日木曜日

Hyper-V Replica Broker を構成してから ASRを構成しましょう

フェールオーバークラスターを組みなおして、Azure Site Recovery(ASR)を構成しようとしたらエラー。。。

メッセージを見ると、両方のフェールオーバークラスターに Hyper-V Replica Broker が無いってことです。
※後でアドバイスもらったところ、下記にその旨、すなわち"Site Recovery doesn't support a VM in a Hyper-V cluster if the Hyper-V Replica Broker isn't configured for the cluster."がありました。
Analyze the Azure Site Recovery Deployment Planner report
要するに、フェールオーバークラスターで Hyper-V Replica を構成するのと同じ要件ですね。

両方のフェールオーバークラスターで、Hyper-V Replica Broker を作成しました。



というわけで、改めてレプリケーションにVMMを関連付けたところ、問題なく成功しました。


2019年6月2日日曜日

ASR で初期同期をオフラインで実行させようとしてハマった

Azure Site Recovery(ASR) で初期同期をオフラインで実行させようとしてハマったので、その顛末を記しておきます。
構成としては、プライマリーサイトにVMM、復旧サイトにVMMで、コントローラーとしての ASR があります。

レプリケーションポリシーで初期同期をオフラインで実行させようとして、
プライマリーサイトのエクスポート用途となるファイル共有と、復旧サイトのインポート用途となるファイル共有を指定したのですが。。。



それで、ネットを検索したら同じ目にあっている人はいましたが、解決策は書いてない。。。
Azure site recovery- replication policy for offline initial replication
上記エントリーの文面読んで、同じように隠し共有で構成しているなと。(ファイル共有名末尾に$がついています)
じゃあ、管理共有ではなく、通常のファイル共有にすればいいのではないかと。
プライマリーサイトのエクスポート用途となるファイル共有と、復旧サイトのインポート用途となるファイル共有は、まあ誰にでも触ってほしいものではありませんから、共有アクセス権は「ローカル管理者へのフルコントロールのみ」にしてみた。

リトライします。




プライマリーサイトのエクスポート用途となるファイル共有と、復旧サイトのインポート用途となるファイル共有の共有アクセス権、ファイルアクセス権を確認してみます。
プライマリーサイトのエクスポート用途となるファイル共有の共有アクセス権、ファイルアクセス権は、そのサーバー自体(今回はプライマリーサイトの Hyper-V ホスト)のコンピューターアカウントに権限がついています。



復旧サイトのインポート用途となるファイル共有の共有アクセス権、ファイルアクセス権は、、そのサーバー自体(今回は復旧サイトの Hyper-V ホスト)のコンピューターアカウントに権限がついています。


即ち、この権限が付与できないことでエラーになっていたと推測できます。

というわけで、
Azure site recovery- replication policy for offline initial replication
にできた旨、書いてみました。

2018年11月25日日曜日

Windows Admin Center から Azure インテグレーションを設定する 4. Azure Site Recovery

Windows Admin Center で Azure Site Recoveryというメニューがあるわけでないのですが、以下から設定できるようになっています。

Server Manager の各 Hyper-V ホスト→仮想マシン


フェールオーバークラスターマネージャー→仮想マシン


ハイパーコンバージドクラスターマネージャー→仮想マシン


では、Windows Admin Center による設定を見ていきます。
Azure Site Recoveryのセットアップを進めるので、[今すぐセットアップ]をクリックします。


ASRの構成に必要な情報を入れます。サブスクリプション、リソースグループ、Recovery Service コンテナー、位置情報です。
入れ終わりましたら、[ASR の設定]をクリックします。


設定中。


Hyper-V ホスト側でのセットアップ中。


セットアップが完了したので、改めて[仮想マシンに移動します。]をクリックします。



保護したい仮想マシンを選択し、[詳細]メニューから[VM の保護]をクリックします。


記憶域アカウントは、新規に作成します。


保護の開始中。


Azure Portal を覗いてみましたら、処理中でした。


保護が開始されました。

仮想マシンにある[保護]リンクをクリックすると、Azure Portal に遷移します。
無事に同期始まってました。