こんにちは。
てくさぽBLOGメンバーの宮里です。

前回に引き続きAzure Stack HCIの検証で得られた知見をお伝えします。検証の目的は、Azure Stack HCIの構築・管理・クラウドとの連携をどのような手順でおこなうのか、使いやすいのか、を実機を使って体感してみることです。
今回は3回シリーズの3回目で、Azureと連携してみた検証結果をお伝えします。

Azure Stack HCIを導入してみた Vol.1 -Azure Stack HCI構築編-
Azure Stack HCIを導入してみた Vol.2 -管理機能編-
Azure Stack HCIを導入してみた Vol.3 -Azureと連携編- ＊本編
 

Index

• はじめに
• 1. AzureにWindows Admin Centerを登録
• 2. Azure Backupとの連携
• 3. Azure Site Recoveryとの連携
• 4. Azure Update Managementとの連携
• まとめ
• お問い合わせ

 

はじめに

今回はオンプレミスのWindows Admin Center（以下、WAC）サーバーがAzureとどのように連携して利用できるのかを検証してみました。

今回の検証環境の概要図はこちらになります。WACサーバーはAzureのいろいろなサービスと連携できますが、今回はオンプレミス側にMXシリーズを導入する際に連携すると役に立つと思われる「Azure Backup」「Azure Site Recovery」「Azure Update Management」の３つを選択しました。それぞれのサービスを簡単に説明します。

• Azure Backup　・・・Azureの仮想サーバーだけでなくオンプレのサーバーのバックアップもAzure上にバックアップできるサービス。WACサーバー から AzureにWindows Server をバックアップすることができます。
• Azure Site Recovery ・・・Azure上に災害対策用のバックアップサイトを提供するサービス。WACサーバーからオンプレミスの仮想サーバーを保護することができます。
• Azure Update Management　・・・Azure上でAzureの仮想サーバーやオンプレミスのサーバーなどの更新プログラムを一元管理することができます。

 

1. AzureにWindows Admin Centerを登録

WACサーバーでAzureと連携させるために、まず最初にAzureにWACサーバーを登録します。

事前準備：Azure PortalでAzure の「テナントID」を確認

WACサーバーで登録設定を行います。

登録画面では表示されているコードをコピーして「コードを入力します。」をクリックします。

するとブラウザ画面に切り替わるので、コピーしたコードを入力し［続行］します。

再びWACに戻ると［Azure Active Directory］にテナントIDが表示されるので、Azure Portalで確認したIDであることを確認し、”新規作成”を選択して［接続］します。

最後に［サインイン］をクリックします。

Azureに登録されたことが確認できます。

以上でWACサーバーがAzureに登録されました。途中でブラウザ画面に切り替わってコードを入力するところが少し分かりづらかったです。

 

2. Azure Backupとの連携

まずはAzure Backupと連携してみました。
WACサーバーにて、バックアップを行うAzure Stack HCI上の仮想サーバーに接続し、左ペインの［Azure Backup］を選択し、右ペインの［Azure Backupのセットアップ］をクリックします。

Azure Backupの設定を行います。以下のように設定しました。

• 資格情報コンテナ：WACvault1（新規）＊デフォルト
• リソースグループ：WACResourceGroup（新規）＊デフォルト
• 位置情報：東日本　＊デフォルトが「東南アジア」だったので変更
• バックアップ対象：System State　＊デフォルト

デフォルトではバックアップ対象が［System State］ですが、この後ファイルをバックアップするジョブを追加してみます。

以上でWACでのAzure Backup設定が完了しました。
Azure Backupのセットアップが完了した仮想サーバーにはAzure Backupアプリが導入されました。これを起動してファイルをバックアップするジョブを追加します。
起動したAzure Backupアプリで［今すぐバックアップ］をクリックしてファイルをバックアップするジョブを追加します。

バックアップするフォルダ、スケジュール、保持する世代数、バックアップの種類を指定します。

これでフォルダをバックアップするジョブが追加できました。

バックアップジョブを2回実行したあとの画面です。回復ポイントが２になっています。

次にリストアしてみました。リストアはWACサーバーからでは無く、Azure Backupアプリから行います。
Azure Backupアプリを起動し、右ペインにある「データの回復」をクリックします。

リストアの種類として「個々のファイルおよびフィルダー」を選択して、次の画面でいつのバックアップから戻すか選択してリストアします。リストアが完了すると回復ボリュームとして空いているドライブ（今回はEドライブ）にマウントされます。

回復ボリュームにバックアップしたファイルがあることが確認できます。

マウントされたEドライブのファイルを元のCドライブのフォルダにコピーしたらリストアは完了です。
WACでのAzure Backupは操作が単純で簡潔な作りになっているため、操作性は非常にわかりやすかったです。
ですが、WAC上での設定だけでは完了とならず、別でアプリによる詳細設定をしなければならないのが少し面倒だと感じたポイントではありました。

 

3. Azure Site Recoveryとの連携

次にAzure Site Recoveryとの連携をやってみました。
まずWACサーバーにて、クラスターに接続してAzure Site Recoveryのセットアップを行います。リソースグループとRecovery ServiceコンテナはAzure Backup検証で作成した既存を指定し、［セットアップ］をクリックします。

続いてWACサーバーでAzure Site Recoveryの対象とする仮想マシンを選択し、「Azure Site Recoveryを使用して複製」をクリックします。

Azure Site Recoveryの設定画面となるので、記憶域アカウントを新規の名前で指定して［VMの保護］をクリックします。以上でWACサーバー側での設定は完了です。

Azure Portalに移動して確認してみます。WACサーバーでAzure Site Recoveryを設定したtest07という仮想サーバーが確認できます。レプリケーションヘルスが「正常」で、状態が「プロテクト」状態であることが確認できますが、構成の問題が１つエラーになっているのでこれをクリックします。

エラーの詳細が確認できます。ターゲットネットワークが構成されていないことが原因のようです。

エラーを解消するために仮想ネットワークを作成しました。今回はSR-testという名前で以下のような設定で作成しました。

Azureにレプリケートされた仮想サーバーtest07で、ターゲットネットワークに作成した仮想ネットワークが選択します。

これでエラーが無くなりました。

いよいよテストフェールオーバーしてみます。”正常に実行されませんでした”をクリックして実行します。

テストフェールオーバーが開始し、しばらく待って状態が「成功」になっていることを確認します。

成功を確認したら、フェールオーバーした仮想サーバー（今回はtest07-testという名前）のネットワークインターフェイス（画面では”nic-test07-00-test”）にパブリックIPを設定して、リモートデスクトップでこのパブリックIPにアクセスしてみます。

無事に接続できたのでテストフェールオーバーが成功しました。

Azure Site Recoveryとの連携では、設定に少々時間がかかりましたがうまく処理が進み、エラーが無くなる瞬間が気持ちよかったです。
因みにですが、この設定の時に参考にしていた資料とGUIが若干変更されており、設定のための項目を探すのに手間取りました。
もし、皆さんがここのページを参考にする際は注意して見てください。もしかしたらGUIが変更されている可能性がありますので・・・。

 

4. Azure Update Managementとの連携

3つ目の検証はAzure Update Managementとの連携です。Azure Update Managementと連携することで、オンプレミスにあるサーバーの更新プログラムの管理をAzure上からAzureの仮想サーバーと合わせて一元管理できるようになります。

まず、WACサーバーで、連携させる対象のサーバーの「更新プログラム」－”今すぐ更新”をクリックして設定します。

Azure Update Managementのセットアップ画面です。場所は「東日本」で、その他はすべて新規作成を指定してセットアップしました。

これでこのサーバーはAzure Update Managementで管理されるようになりました。

Azure Portalで確認します。作成したUpdate02というAzure Automationアカウントの「更新プログラムの管理」画面でサーバーが登録されていることが確認できました。

更新プログラムを適用してみます。「更新プログラムの展開スケジュール」をクリックします。

タイプとして「マシン」を選択し、登録されているAzure Stack HCI上の仮想サーバーが選択されていることを確認し［OK］します。

展開スケジュールが実行されて状態が「成功」であることが確認できました。

Azure Update Managementと連携することで、管理しているサーバの更新プログラムが一度に適用できるため、便利な機能になります。設定も簡単かつすぐに終わるので、迷うことなく出来ると思います。

 

まとめ

Azureとの連携編は以上になります。

全体を通して初めての構築や設定等行い、学ぶことは多かったです。
機能は知っていても実際に触ってみるとうまくいかないことがあり、トライアンドエラーの繰り返しによる経験で覚えるんだと実感しました。

作業中に気になった点ですが、サブスクリプションの機能を利用する際に、選んだデータの容量によってどれぐらいの金額が発生するのか見えないところが少し怖いと感じました。

もちろん事前に確認はしつつやっておりましたが、設定1つ間違えれば想定していない金額が発生すると思うとドキドキしました。
ざっくりでも良いので最終確認画面等でどのぐらいの金額になるか見せてもらえたら嬉しいなと個人的には思ったところです。

如何でしたでしょうか、以上で全３回のブログは終わりになります。
皆さんのお役に立てる情報が1つでもあると嬉しいです。

 

お問い合わせ

この記事に関するご質問は下記までご連絡ください。

エヌアイシー・パートナーズ株式会社
技術支援本部
E-Mail：nicp_support@NIandC.co.jp