Azure Site Recoveryでクラウドおよび仮想マシンの保護を有効にする際にハマったこと

以前ブログ記事でも紹介しましたが、現在Azure Site Recoveryの検証を進めています。

• Azure Site RecoveryでAzureをDR先に構成可能に | System Center Blog

実際に検証を進める中で、仮想マシンの保護を有効にするまでにいくつかハマったポイントがありましたので共有します。

参考情報

Azure Site Recoveryって何?という方のためにリンクもいくつか貼っておきます。

まずはこちら。概要が良くわかります。

• Implementing Enterprise-Scale Disaster Recovery with Hyper-V Recovery Manager, Network Virtualization, and Microsoft System Center 2012 R2 | TechEd North America 2014 | Channel 9

以下のブログもASRの概要の理解に役立ちました。

• Microsoft Azure Site Recovery Preview | Thomas Maurer

具体的な計画や構築ステップに関しては以下のサイトがまとまっています。

• Recovery Manager | Microsoft Azure Technical Documentation Library http://msdn.microsoft.com/en-us/library/azure/dn440569.aspx

保護対象とする仮想マシンには結構制限があります。ここには注意が必要です。

• Prerequisites and support http://msdn.microsoft.com/en-us/library/azure/dn469078.aspx
  • OSはWindows Server 2008以降, CentOS, openSUSE, SUSE, Ubuntu
  • 64bitOSのみ
  • OSのディスクサイズは20MB～127GBで1ディスクのみ
  • データディスクは20MB～1023GB
  • ネットワークアダプタは1つ、IPアドレスも1つのみ。複数NICがある場合には1つだけ選択することになる。
  • 静的IPアドレスはサポートされない。フェールオーバー後にDHCP構成となる。
  • iSCSIディスクはサポート対象外。
  • 共有VHDディスクはサポート対象外。
  • FCディスクはサポート対象外。
  • クラスターティスクはサポートされる。
  • ディスクフォーマットはVHD, VHDXの両方がサポートされる。
  • 第1世代の仮想マシンのみサポートされる。

ハマったポイント1 : 証明書の有効期限

ハマったポイントの1番目は証明書の有効期限です。証明書をアップロードすると、以下のように有効ではないと怒られてしまいました。

エラーメッセージは以下です。

Invalid certificate uploaded. Please veryfy that the certificate is not expired, has at least 2048 bit key, enhanced key usage is ClientAuthentication and expiration date is not more than 3 years from current date.

証明書の条件として以下の4つが必要だと書かれています。

1. 期限切れでないこと
2. 2048ビット以上の長さの鍵であること
3. クライアント認証に使える事
4. 期限が3年未満であること

この4つ目の条件…、こうしてみると当たり前に書いてあるのですが、きちんとこのメッセージを読んでおらず「3年未満」でなければいけないのに「3年以上」でないといけないと思い込んでしまい、ずっとうまく行きませんでした。

この「3年未満」という条件は復旧サービス(Azure Site Recovery)のみの縛りのようで、「設定」から進むと3年以上の有効期間を持つ鍵でもアップロードできちゃいます。これもあって中々間違いに気がつけませんでした。

結局はmakecert.exeで証明書を作成する際にきちんと -eオプションで適切な日時を期限に設定することでうまくいきました。分かった気にならずにきちんと英語を落ち着いて読まなければいけませんね・・・。

 

SCVMM DB上のゴミによって処理に失敗する

証明書の部分を突破すればあとは対して落とし穴は無いのですが…、私の環境ではもう一つありました。SCVMM Database上に不正なレコードがあったのです。

仮想マシンの保護を有効にしようとすると以下のように「VMMデータベースに接続できない」というエラーになってしまいました。

一度保護を無効化しようとしても同じエラー。一度クラウド保護の部分からやり直してみても同じ…ということでお手上げ状態になってしまいました。VMMデータベースに接続できない…ということだけれどもSCVMMはきちんと稼働してますし…。これは製品の不具合の可能性もあるかもしれないと思って、フォーラムで質問してみたところ、Microsoftの方に対応してもらえました。

• Enabling protection couldn’t be completed for the virtual machine. (Error code: 70095)

結局はSCVMM Database内の[VirtualManagerDB].[dbo].[tbl_WLC_VMInstance]というテーブル内にVMIdが登録されていないおかしなレコードが存在しており、それが原因で失敗していました。

みてみたところ、確かにそういうレコードがありました。

このVMは仮想マシン名すら表示されない本当におかしなレコードになってしまっていました。SCVMM 2012 SP1からSCVMM 2012 R2にDBをアップグレードする際に何かしらの原因でこのような状態になってしまったようです。

VMInstanceIDを指定して Remove-SCVirtualMachineコマンドレットを使用することでこのレコードを削除し、問題は解決しました。

 

私がハマったのは上記の2箇所でした。仮想マシンの保護は順調に稼働しているようです。評価をさらに進めていきます。