2022年04月

04

【やってみた】Azure Stack HCIを導入してみた:Azureと連携編

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

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

第一回:【やってみた】Azure Stack HCIを導入してみた:Azure Stack HCI構築編
第二回:【やってみた】Azure Stack HCIを導入してみた:管理機能編
第三回:【やってみた】Azure Stack HCIを導入してみた:Azureと連携編 *本編
 

Index


 

はじめに

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

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

  • 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回実行したあとの画面です。回復ポイントが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という仮想サーバーが確認できます。レプリケーションヘルスが「正常」で、状態が「プロテクト」状態であることが確認できますが、構成の問題が1つエラーになっているのでこれをクリックします。

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

エラーを解消するために仮想ネットワークを作成しました。今回は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つ間違えれば想定していない金額が発生すると思うとドキドキしました。
ざっくりでも良いので最終確認画面等でどのぐらいの金額になるか見せてもらえたら嬉しいなと個人的には思ったところです。

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

 

お問い合わせ

この記事に関するご質問は下記までご連絡ください
エヌアイシー・パートナーズ株式会社
技術支援本部
E-Mail:nicp_support@NIandC.co.jp

 

その他の記事

2022年06月24日

【早わかり】AIX と IBM i ライセンス情報

こんにちは。エヌアイシー・パートナーズ 村上です。 2022年度は新しい試みとして、 ・理解しているつもりだけど説明はできない ・時間があれば調べたいと思っていた ・当たり前な知識かもしれなくて質問しにくい という内容を取り上げた「早わかりシリーズ」を掲載していきます。 今回は、IBM Power のメインOS、AIX と IBM i のライセンス情報をご紹介します。 AIX とIBM i は、片方のライセンス情報しか知らないという方も意外と多いので、ぜひこの機会に比較しながら読んでみてくださいね。   セクション 1) 永続ライセンスのおさらい 2) マンスリーとサブスクリプションをご存じですか? 3) ライフサイクルとバージョンのポイント   1) 永続ライセンスのおさらい AIX とIBM i のスタンダードなライセンス「永続ライセンス」。 有効期限のない永続ライセンスは、SWMA (SoftWare MAintenance) と合わせて所有します。 永続ライセンス OSを利用できる権利。1年目に購入。 SWMA 「サブスクリプション(最新バージョンへのアップグレード)」と「テクニカルサポート(対象製品に対するQAサポート)」の権利。 1年~5年で選択し、継続するためには都度オーダーが必要。 更改などで新ハードウェアへ移行する場合、 AIX 永続ライセンスはIBM Power本体に紐づくので、新ハードウェアになるタイミングで永続ライセンスが買い直しになります IBM i 既存機のライセンスを新ハードウェア移管することが可能です(移行先の機械レベルが高くなる場合は追加料金が発生) IBM i には、移行中ライセンスとして安価なITL(IBM Temporary License)が提供されたり、DR機専用のライセンスがあったりもします。   2) マンスリーとサブスクリプションをご存じですか? さて、このセクションが今回のブログの本題です。 2022年6月現在、AIX とIBM i には「永続」「マンスリー」「サブスクリプション」と3種類のライセンスがあります。 以下は利用ケースのイメージです。 利用ケース 永続ライセンス ・長期間利用 マンスリーラインセンス ・移行時の短期利用 ・スパイク(最低限の環境をさっと作って概ねの方向性を確認する) サブスクリプションライセンス ・初期投資を抑えたい場合に利用 ・HWに依存せず臨機応変に利用(中長期間でAIXの場合) サブスクリプションライセンスは、AIX は2021年、IBM i は2022年に提供が開始されました。 (表が見えにくいのでクリックして拡大してご覧ください) サブスクリプションライセンスは、今後拡張が予定されています。 利用ケースにあったライセンスを選択できるようになってきたので、臨機応変な検討ができるようになりますね。   3) ライフサイクルとバージョンのポイント 2022年6月時点で、IBMは「AIX も IBM i も将来の投資を継続する」という発表をしています。 IBM Power ユーザとしては一安心です。 どちらのOSも、サポートライフサイクルは10年間となります。 下記にバージョンのポイントを纏めてみました。 <AIX > 購入できるバージョン v7.2 , v7.3 標準サポートがあるバージョン v7.1, v7.2, v7.3 どうやってもサポートが終わっているバージョン v5.3 実はまだ有償延長サポートがあるバージョン v6.1 TLが出るタイミング(※) 1回/年、成熟してくると1回/2年 サポートライフサイクル(10年) 標準(最短6年)+延長保守(3~5年) <IBM i > 購入できるバージョン v7.3 , v7.4, v7.5 標準サポートがあるバージョン v7.3, v7.4, v7.5 どうやってもサポートが終わっているバージョン v6.1 実はまだ有償延長サポートがあるバージョン v7.1, v7.2 TRが出るタイミング(※) 2回/年(最新バージョンと1世代前のバージョンに対して) サポートライフサイクル(10年) 標準(7年)+延長保守(3年) <※TLとTRの補足> TL:テクノロジー・レベル。AIXにおける問題の修正、新しいハードウェアのサポート、ソフトウェアの機能拡張が含まれたプログラム。 TR:テクノロジー・リフレッシュ。IBM i におけるオファリング、サービス、およびハードウェアの機能拡張を提供するプログラム。 かなり前のバージョンも、延長保守のサポートがあるため更改時も安心です。 ただ、延長保守サポートは、部品不足による急な保守終了や、新規の問い合わせに対応いただけない、という面があるので要注意です。 また、延長保守サポートには細かい前提が設けられており前提にも随時変更が入りますので、ご利用を検討される際はお問い合わせください。   さいごに つい先日(2022年6月)、IBM i の複数のソフトウェアラインセンスが無償化される発表(IBM PartnerWorld)がありました。 IBM i では更改の検討が始まると、実際に利用している有償ソフトウェアの見直しが入ったりして、見積もりに時間がかかることがありますよね。 有償ライセンスが減ったことで、見積もりが少しでも簡単になり助かります。 クラウドシフトが進む中で、ライセンス体系、課金、監査方法が複雑化しています。 弊社には毎日のようにパートナー様からライセンス関連の相談やお問い合わせが来ています。 OSのみではなく、あらゆるソフトウェアのライセンス情報収集に日々奮闘(?)しているSEが多数おりますので、お困りの際はお気軽にご連絡ください! ※ 本ブログの情報は時間経過とともに変更が入る可能性があります。   お問い合わせ この記事に関する、ご質問は下記までご連絡ください。 エヌアイシー・パートナーズ株式会社 E-Mail:voice_partners@niandc.co.jp  

back to top