セイテクエンジニアのブログ かつて山市良と呼ばれたおじさんのブログ vol.14 ラボ環境 on Azureを作る(2)- Azure VMのデプロイ
2024年05月30日配信
2024年06月18日更新
執筆者:山内 和朗
今回から、前回検討(妄想)したAzure上のラボ環境を現実化するための作業になります。まず、Azure VMをデプロイして、ラボ環境のプラットフォーム(Azureはそのプラットフォームのプラットフォーム)となるHyper-VホストのOS環境を準備します。Azure仮想マシン(Auzre VM)のサイズやディスク(マネージドディスク)の種類は後で変更できるので、細かいことはあまり気にせずに進めていきます。
図1は、前回検討したAzure上に構築する自分だけのラボ環境のイメージ図です。今回は、紫の点線で示した部分のAzure VMとAzure仮想ネットワーク(VNET)をデプロイします。
図1 Azure上に構築するHyper-Vベースのラボ環境 紫の点線で示した部分を構築していく
Azure VMシリーズの必須要件は、「入れ子になった仮想化(Nested Virtualization)」をサポートするVMシリーズであること。以下のドキュメントの一覧で「***」印(ハイパースレッド化されており、入れ子になった仮想化を実行できます)が付いているものが、入れ子になった仮想化をサポートしています。
Azure コンピューティング ユニット (ACU)
https://docs.microsoft.com/ja-jp/azure/virtual-machines/acu
以下のドキュメントのリンク先で、VMシリーズごとに入れ子になった仮想化(仮想化を入れ子にする)がサポートされるか、されないかを確認することもできます。今回は、いろいろと比較してみた結果、「Dsv5シリーズ(外部サイト)」にしようと思います。
汎用仮想マシンのサイズ
https://learn.microsoft.com/ja-jp/azure/virtual-machines/sizes-general
VMシリーズを決めたら、必要なリソース量(コア数、メモリ容量)とAzureクレジット枠内(私の場合は2万2,500円/月)で利用することを考慮して、サイズを決定します。ただし、VMシリーズとサイズはいつでも変更できるので、例えば、多くのリソースが必要になるときにだけ、より大きなサイズに変更して使用すればよいので、あまり悩む必要はありません。VMシリーズのサイズごとに「コスト/月」が示されますが、Azure VMは「停止済み(割り当て解除)」状態の場合、コンピューティング料金が発生しないため、例えば1日に6時間、月に20日、使用するという場合、実質的な月額コストは6分の1程度で済みます(注:停止したら割り当て解除状態にするのをくれぐれも忘れないように!)。
実際に必要になるリソース量は評価対象によって異なるため、この時点でサイズを決めることはできませんが、複数台のHyper-V仮想マシン(Hyper-V VM)を同時実行できるHyper-Vホスト環境として、Azureクレジット枠を考慮しても、少なくとも4コア、16GBメモリはほしいところです。Dsv5シリーズなら「Standard_D4s_v5(4コア、16GBメモリ、27,142円/月)」です。しかし、OS環境とHyper-V環境をセットアップするまではそんなに必要ありません。当面は、「Standard_D2s_v5(2コア、8GBメモリ、13,571円/月)」で進めて、後でリソースが必要になったらサイズ変更しようと思います。
Azure VMのコストについては、使用中にのみ課金されるAzure VMのコンピューティング料金とは別に、Azure VMに必要なストレージの料金(Managed Disksの料金《外部サイト》、Azure料金計算ツール《外部サイト》)もあることに留意してください。後でも触れますが、ストレージ料金はAzure VMに割り当てたとき、割り当てた容量に対してその種類(パフォーマンス)の課金が始まり、それはAzure VMの稼働状態とは関係なく、削除されるまで課金が続きます。例えば、128GBのマネージドディスク(東日本、LRS)の場合、Premium SSD(P10)、Standard SSD(E10)、Stamdard HDD(S10)の月額料金は、それぞれ約3,436円~、約1,485円~、約900円~(固定料金に加えて、IOPS、スループットに対する課金も発生します)になります。
何はともあれ、早速、ゲストOS「Windows Server 2022(Desktop Experience)」のAzure VMをデプロイしてみます。最も簡単な方法は、Azure MarketplaceでMicrosoftがオファーする「仮想マシン」のイメージからのデプロイです。
「≡(ポータルメニュー)」から「+リソースの作成」を選択し、「仮想マシン」の「Create」をクリックします。
画面1 Azure VMの作成を開始する
「基本」ページで、Azure VMの基本設定を行います(画面2、画面3)。リソースグループ名、仮想マシン名、地域(リージョン)を選択し、可用性オプションは「必要ありません」にしました。セキュリティの種類は既定の「トラステッド起動の仮想マシン」を推奨します。これにより、セキュアブートが有効化され、TPMによる起動プロセスの保護が強化されます。
イメージとしては、「[smalldisk]Windows Server 2022 Datacenter - x64 Gen2」を選択しました。[smalldisk]が付くイメージは既定で30GBのOSディスクが割り当てられます。[smalldisk]が付かないイメージは128GBのOSディスクが割り当てられます。ディスクのサイズはストレージの課金に影響するため、小さいほうを選択しました。
VMのシリーズ/サイズは前述したように、「Standard_D2Ss_v5」を選択しました。
管理者アカウントのユーザー名とパスワード、インターネットからのリモートデスクトップ接続を可能にするためのパブリックポートによる受信許可を構成したら、次のページに進みます。
画面2 Azure VMの基本情報を設定していく(その1)
画面3 Azure VMの基本情報を設定していく(その2)
「ディスク」のページでは、OSディスクのサイズと種類を指定します。以前は[smalldisk]イメージのOSディスクは30GB(Windowsの場合)固定でしたが、現在は32GBや64GB(128GB以下の場合)を指定できるようになりました。数年間運用している私個人のWindows Server 2022 Hyper-Vの物理サーバーのC:ドライブを確認してみると、C:ドライブに意図的に何か大きなデータを保存することなく使用してきましたが、現在の使用領域は30GBを超えていました。既定の30GBだと、Windows Updateを繰り返していくうちに、すぐに足りなくなると思います。そこで、今回はPremium SSDの64GB(P6)を選択しました(画面4)。
画面4 OSディスクを既定の 30GB から64GBに変更
また、Hyper-V VMの格納先として、データディスクを追加しておきます。今回は 512GB の「Premium SSD(ローカル冗長ストレージ《LRS》)」のディスクを1つ追加しておきます。ホストキャッシュは既定の「読み取り専用」で問題ないでしょう。なお、ディスクのサイズと種類(パフォーマンス)は課金に大きく影響するので、不用意に大きなサイズを割り当てるのは避けるべきです。あとから、サイズや種類は変更できますし、ディスクを追加することもできるからです(画面5)。
画面5 Hyper-V VMの格納用にデータディスクを追加する
「ネットワーク」ページでは、既定の設定をそのまま受け入れます。Azure IaaS環境で1台のAzure VMを動かすだけなので、複雑なカスタム構成は不要と判断しました(画面6)。
画面6 VNETの構成は既定の構成を受け入れる
「管理」、「監視」、「詳細」、「タグ」のページは適宜設定します。既定の設定から変更したところがあるとすれば、「管理」ページで「自動シャットダウンを有効にする」と「バックアップの有効化」をオフにしたくらいです。最後に「確認および作成」で「作成」をクリックして、 Azure VM のデプロイを開始します(画面7)。デプロイはほんの数分で完了しました。
画面7 「作成」をクリックして数分待つと、デプロイが完了し、リソースのページ(「Virtual Machines」ブレードのVMのページ)に誘導される
Azureポータルの「Virtual Machines」ブレードのVMのページを開くと、VMが実行中の場合は「接続」メニューからRDP接続(Windowsの場合)を開始(RDPファイルをダウンロードして開く)することができます(画面8)。しかしその前に、真っ先にやっておくべきことがあります。現在、VMにはパブリックなIPアドレスが割り当てられ、RDPポート(3389)がパブリック受信ポートでインターネットに開かれており、非常にリスクのある状態です。
画面8 デプロイが完了し、実行中になったAzure VM。「接続」からRDP接続を開始できるが、ちょっと待った!
前回説明したAzure Bastion(外部サイト)を導入すれば、VNETとインターネットの境界のゲートウェイとして機能し、VMにパブリックIPを割り当てることなく、プライベートなVNETをインターネットから完全に遮断した状態で、VNET内のVMにHTTPSベース(ブラウザーまたはトンネル)で安全に接続することができます。しかし、このサービスは結構なお値段がするので、Azureクレジット枠内での利用は困難です。
Azure Bastionを利用せずにセキュリティを高めるために、お勧めする方法は、「ネットワークセキュリティグループ(NSG)」の「受信セキュリティ規則」のルールの強化です。
AzureポータルからWindows VMをデプロイすると、任意のソースから任意の宛先に対するRDPポート(3389/TCP)への接続が許可されます。このNSGの受信セキュリティ規則(受信ポートルール)は、VMのページの「ネットワーク設定」から確認、編集することができます。RDPに対応したルールのソースとして、静的なIPアドレスまたはIPアドレス範囲(企業で特定の範囲をすべて利用できる場合)に固定して、接続元を限定してしまうのです。動的にIPアドレスが割り当てられるインターネット環境の場合は、Azure VMに起動する(アクセスする)たびに毎回設定すればよいのです。ソースとして「My IP address」を選択すれば、静的/動的に関係なく、現在、AzureポータルにアクセスしているデバイスのIPアドレス(インターネット側から見えるパブリックIPアドレス)に変換してくれます(画面9)。AzureポータルやAzureサブスクリプションへの接続認証は、ユーザー名とパスワードだけでなく、電話や認証アプリによる多要素認証で強化できるため、NSGの設定が改ざんされる心配はないでしょう。
画面9 NSGの「受信セキュリティ規則」でRDP接続用の規則を編集し、ソースをアクセス元(会社)のIPアドレスに限定する
このように、受信セキュリティ規則(受信ポートルール)を会社のパブリックIPに限定してしまえば、もし仮にRDP接続を第三者に許してしまったとしても(RDP接続のためには、さらにユーザー名とパスワードの入力が必要ですが)、その犯人はそのとき、社内ネットワークにアクセスできるところ(リモートワークを含む)にいたということになるでしょう。
私はこれまで、Windows VMをデプロイしたら、すぐWindows Updateで最新にすることをさまざまな所でお勧めしてきました。しかし、Azure MarketplaceのイメージからデプロイしたAzure VMの場合、そんなに慌てる必要はありません。Azure MarketplaceのWindowsイメージは毎月最新のビルドベースに更新されているため、そのイメージからデプロイしたVMはほぼ最新状態です(※実は、このままWindows Updateを実行すると...→次回のお楽しみ)。
デプロイは数分で終わりますが、この記事は少し長くなったので、今回(今日)はここまでにしましょう。接続中のRDPセッションからOSをシャットダウンして、Azureポータルの「Virtual Machines」ブレードでVMの状態が「実行中」から「停止済み」に変わったら、さらに「□ 停止」コマンドをクリックして、「停止済み(割り当て解除)」になったことを確認します(「更新」コマンドをクリックして、表示をリフレッシュして確認してください)。この操作を忘れてしまうと、「停止済み」状態でもAzure VMのコンピューティング料金の課金が続いてしまいます。
画面10 停止したAzure VMをさらに「停止」して、割り当て解除状態にすることで、無駄な課金を回避できる
ちなみに、今回、Azure VMのデプロイから割り当て解除まで4時間ほどでした。コンピューティング料金だけに限れば約75円(画面7の時間単価×4時間)です。もし割り当て解除を忘れた場合、24時間後には約450円ほどになります。その状態が1か月続いたとすると、Azure VMを動かしていないのに約1万3,500円のAzureクレジットを無駄に消費してしまうことになります。
さらに、ストレージ料金は別にかかるので、VMを使用していないとき、同一サイズで別の種類に変更しておけば(画面11)、大幅にコストを節約できるはずです(Premium SSD→Standard HDDで時間あたりのコストは約4分の1に)。私のラボ環境のように、Azure VMが1台だけなら、そのような手間のかかる運用もたいして苦になりません。こういったちょっとした手間は、評価、検証環境としてAzure VMを利用する場合の賢い節約術になります。
画面11 Azure VMを使用していないとき、OSディスクとデータディスクを同一サイズのPremium SSDからStandard HDDに変更して、ストレージコストを抑制
2024年10月31日 | vol.56 はじめてのAzure REST API|Azure&Entra IDスクリプト大作戦(3) |
---|---|
2024年10月29日 | メモ. AlmaLinux(RHEL系)をVMwareからHyper-VへV2V移行するには |
2024年10月28日 | vol.55 サービスプリンシパルによる非対話型認証|Azure&Entra IDスクリプト大作戦(2) |
2024年10月25日 | メモ. Hyper-Vのもう1つの可用性オプション、Hyper-Vレプリカ |
2024年10月24日 | vol.54 Azure&Entra IDの情報取得、スクリプト大作戦 |
2024年10月22日 | メモ. Windows 11 24H2の新規インストール、正しいはずのパスワードが弾かれる(追加情報あり) |
2024年10月21日 | vol.53 Zabbixにあって、BOMにないもの、代用できるもの|BOMおじさんとZabbix(9) |
2024年10月18日 | メモ. クラスター対応更新(CAU)ってこんな感じ |
2024年10月17日 | vol.52 Webサイト/アプリの稼働監視|BOMおじさんとZabbix(8) |
2024年10月15日 | vol.51 更新の監視と管理|BOMおじさんとZabbix(7) |