概要
- Azure 初心者の新川です。今日は、VMSSのデプロイ方法をAzure Portal および Azure CLI の2パターンでご紹介します。構築で両方使ってみると、初めはAzure Portalの方が分かりやすいですが、慣れるとAzure CLI の方がサクサクと捗ります。
- VMSSはVirtual Machine Scale Sets（仮想マシン スケール セット）の略であり、負荷分散を行うための VM のグループを作成して管理する機能となります。VMSSを使用することで、手動あるいは自動のスケジュールに合わせてVM インスタンスの数を増減させることができます。
- AWSに置き換えると、EC2 Auto Scalingで提供される製品となります。
前提条件
- 前半は、Azure Portal を使用した手順です。リソース グループ、ロードバランサー、スケール セットおよびネットワークセキュリティグループを作成します。スケール セットで起動するインスタンスには、CentOS のイメージを使用します。また、インスタンス起動時にカスタムデータを指定して、Webサーバーのセットアップを行っています。
- 後半は、Azure CLI を使用した手順です。前半で作成したリソース グループに対して、ロードバランサー、スケール セットを追加で作成します。ネットワークセキュリティグループは前半で作成したリソースを流用します。Azure CLIでも、VMSS作成時にカスタムデータを指定できますが、yumのパッケージインストールでエラーとなり、Webサーバーのセットアップは起動後に手動で行っています。
- 後半で使用するAzure CLI のインストール方法は、下記の記事を参照ください。
Azure Portalを使ったVMSS のデプロイ方法
リソースグループの作成
- ロードバランサー、スケール セットなど関連するリソースを管理する単位であるリソースグループを作成します。
- Azure Portal にサインインし、[リソース グループ]を選択します。[追加]を選択します。
- 次の値を選択 or 入力します。
- サブスクリプション
- リソース グループ（例: niikawa-vmss-test-rg）
- リージョン（例: 東日本）
- パラメータの値に誤りがなければ、[作成]を選択します。
ロードバランサーの作成
- [ロード バランサー]を選択します。[追加]を選択します。
- 次の値を選択 or 入力します。
- サブスクリプション
- リソース グループ（例: niikawa-vmss-test-rg）
- 名前（例: niikawa-vmss-test-lb1）
- 地域（例: 東日本）
- 種類（内部 or パブリック）
- SKU（Basic or Standard）
- パブリック IP アドレス（新規作成）
- パブリック IP アドレス名（例: niikawa-vmss-test-pubip1)
- 可用性ゾーン（ゾーン冗長 or 2, 1, 3）
- パブリック IPv6 アドレスを追加する（いいえ）
- 今回は、ロード バランサーの種類に“パブリック”、SKUに“Standard”を指定します。ロードバランサーのSKUには、Standard SKU, Basic SKU があり、機能, 制限事項, 料金が異なります。Standard SKU, Basic SKUの比較は、下記の資料を参照。
- ゾーン冗長を構成する場合は、可用性ゾーンに“ゾーン冗長”を選択します。リソースを複数のゾーンに分散し、全体の可用性を向上させます。可用性ゾーンの詳細については、下記の資料を参照ください。
仮想マシン スケール セットの作成
- [Virtual Machine Scale Sets]を選択します。[追加]を選択します。
- 基本の設定に、次の値を選択 or 入力します。可用性ゾーンに複数のゾーンを指定することで、ゾーン冗長スケール セットが構成可能です。
- サブスクリプション
- リソース グループ（例: niikawa-vmss-test-rg）
- 仮想マシン スケール セットの名前（例: niikawa-vmss-test-scaleset1）
- 地域（例: 東日本）
- 可用性ゾーン（なし or ゾーン 1, 2, 3）
- イメージ（例: CentOSの最新バージョン）
- サイズ（要件に応じて選択）
- 認証の種類（SSH 公開キー）
- ユーザー名（例: azureuser）
- SSH 公開キーのソース（例: 新しいキーペアの作成）
- キー ペア名（例: niikawa-ssh-key）
- ディスクの設定はデフォルトから変更せず、次へ進みます。
- ネットワークの設定に、次の値を選択 or 入力します。
- 仮想ネットワークの選択（例: niikawa-vmss-test-rg-vnet）
- ロード バランサーを使用する（はい）
- 負荷分散のオプション（Azure Load Balancer）
- ロード バランサーの選択（例: niikawa-vmss-test-lb1）
- バックエンド プールの選択（例: niikawa-vmss-test-bepool1）
- スケールの設定に、次の値を選択 or 入力します。今回はスケーリングは、手動で行います。
- 初期インスタンス数（要件に応じて）
- スケーリング ポリシー（手動 or カスタム）
- スケールイン ポリシー（既定 or 最新の VM, 最も古い VM）
- 管理の設定に、次の値を選択 or 入力します。今回はVMイメージを”手動アップグレード” させるため、手動を選択します。
- アップグレードモード（自動 or 手動, ローリング）
- 各パラメータの意味は下記の通りです。
- 自動 – このモードでは、スケール セットは VM の停止順序を保証しません。 スケール セットは、すべての VM を同時に停止できます。
- ローリング – このモードでは、スケール セットは更新をバッチでロールアウトします。必要に応じて、バッチ間の一時停止時間を設定します。
- 手動 – このモードでは、スケール セット モデルの更新時に、既存の VM は更新されません。
- 詳細の設定に、次の値を入力します。
- カスタム データに、次のcloud-init スクリプトを貼り付けます。CentOS にhttpdパッケージをインストールし、/var/www/html/index.html にファイルを配置、httpdサービスを再起動するyumとなります。
#cloud-config
package_upgrade: true
packages:
- httpd
write_files:
- path: /var/www/html/index.html
content: |
Hello World!
runcmd:
- service httpd restart
- 下記画面が表示されます。SSH 公開キーに“新しいキーペアの作成” を選択したため、新たにキーペアが作成されました。作成されたSSHの秘密キーをダウンロードします。
ロードバランサーに正常性プローブを作成
- [ロード バランサー]を選択します。先ほど作成したロード バランサーを選択します。ロード バランサーの設定から、正常性プローブ、負荷分散規則、送信規則（アウトバウンド規則）の3つを追加設定します。
- 正常性プローブによって、Load Balancer でバックエンド エンドポイントの状態を検出します。プローブ チェックが失敗した仮想マシンは、ロード バランサーから削除されます。 障害が解決されると、仮想マシンがロード バランサーに再び追加されます。
- 次の値を選択 or 入力します。Standard SKU の場合、TCP リスナー,HTTP エンドポイント,HTTPS エンドポイントが選択可です。Basic SKU の場合、TCP リスナー,HTTP エンドポイントが選択可です。
- 名前（例: niikawa-vmss-test-lb1-probe）
- プロトコル（TCP）
- ポート（例: 80）
- 間隔（例: 5）
- 異常しきい値（例: 2）
- 詳細は、下記の資料を参照。
ロードバランサーに負荷分散規則を追加
- 負荷分散ルールでは、選択した IP アドレスとポートの組み合わせに送信される着信トラフィックを、バックエンド プール イ- ンスタンスのグループ全体に分散します。正常性プローブが正常と見なすバックエンド インスタンスのみが、新しいトラフィックを受信します。
- 負荷分散規則の設定を選択します。次の値を選択 or 入力します。
- 名前（例: niikawa-vmss-test-lb1-rule）
- フロントエンド IP アドレス（例: XX.XX.XX.XX LoadBalancerFrontEnd）
- プロトコル（例: TCP）
- ポート（例: 80）
- バックエンド ポート（例: 80）
- バックエンド プール（例: niikawa-vmss-test-bepool1）
- 正常性プローブ（例: niikawa-vmss-test-lb1-probe）
- セッション永続化（なし, クライアント IP, クライアント IP とプロトコル）
- セッション永続化は、セッション期間中にクライアントからのトラフィックをバックエンド プール内の同じ仮想マシンで処理する必要があることを指定します。
- [なし] は、同じクライアントからの連続する要求をどの仮想マシンが処理しても構わないことを示します。
- [クライアント IP] は、同じクライアント IP アドレスからの連続する要求を同一の仮想マシンで処理することを示します。
- [クライアント IP とプロトコル] は、同じクライアント IP アドレスとプロトコルの組み合わせからの要求を同じ仮想マシンで処理することを示します。
- フロントエンドで指定されたパブリック IP アドレスを使用するには、バックエンド プール内のインスタンスに対して送信 SNAT を構成します。今回は、「(推奨) アウトバウンド規則を使用して、バックエンド プールのメンバーがインターネットにアクセスできるようにします。」を選択しています。アウトバウンド接続の詳細は、下記資料を参照ください。
ロードバランサーにアウトバウンド規則を追加
- アウトバウンド規則の設定を選択します。次の値を選択 or 入力します。
- 名前（例: niikawa-vmss-test-lb1-outbound）
- フロントエンド IP アドレス（例: XX.XX.XX.XX LoadBalancerFrontEnd）
- プロトコル（All, TCP, UDP）
- バックエンド プール（例: niikawa-vmss-test-bepool1）
- ポートの割り当て（送信ポートの数を手動で選択する）
- 送信ポート選択基準（バックエンド インスタンスの最大数）
- バックエンド インスタンスの最大数（要件に応じて指定）
ネットワーク セキュリティ グループの作成
- [ネットワーク セキュリティ グループ]を選択します。作成したリソース グループに関連付けられたネットワーク セキュリティ グループを選択します。
- 以下、デフォルトの受信セキュリティ規則、送信セキュリティ規則になります。
- 受信セキュリティ規則にSSHを許可する規則を追加します。
- ソース（IPアドレス, ポート範囲）、宛先（IPアドレス, ポート範囲）、プロトコル、アクション（許可 or 拒否）、優先度、名前を指定します。
- 受信セキュリティ規則にHTTPを許可する規則を追加します。
- ソース（IPアドレス, ポート範囲）、宛先（IPアドレス, ポート範囲）、プロトコル、アクション（許可 or 拒否）、優先度、名前を指定します。
- 下記の通り、SSH, HTTPを許可する受信セキュリティ規則が追加されました。
疎通テスト
- クライアントより、Webブラウザ or curlコマンドを使用して、ロード バランサーのパブリック IP アドレスに疎通テストを行います。
- 以下、Webブラウザの結果です。
niikawa@niikawa1:~$ curl http://xx.xx.xx.xx
Hello World!
Azure CLIを使ったVMSS のデプロイ方法
- 後半は、Azure CLI を使用した手順です。前半のAzure Portalで作成したリソース グループに対して、ロードバランサー、スケール セットを追加で作成します。ネットワークセキュリティグループは前半で作成したリソースを流用することとします。
ロードバランサーの作成
- 1行目は、作成済みのリソース グループ（例: niikawa-vmss-test-rg）を指定し、パブリック IP アドレス（例: niikawa-vmss-test-pubip2）を作成しています。
- 2行目は、作成済みのリソース グループ（例: niikawa-vmss-test-rg）、パブリック IP アドレス（例: niikawa-vmss-test-pubip2）を指定し、ロード バランサー（例: niikawa-vmss-test-lb2）、バックエンド プール（例: niikawa-vmss-test-bepool2）を作成しています。
az network public-ip create --resource-group niikawa-vmss-test-rg --name niikawa-vmss-test-pubip2 --allocation-method Static --sku Standard
az network lb create --resource-group niikawa-vmss-test-rg --name niikawa-vmss-test-lb2 --backend-pool-name niikawa-vmss-test-bepool2 --sku Standard --public-ip-address niikawa-vmss-test-pubip2
仮想マシン スケール セットの作成
- 作成済みのリソース グループ（例: niikawa-vmss-test-rg）、ロード バランサー（例: niikawa-vmss-test-lb2）、ネットワーク セキュリティ グループ（例: basicNsgniikawa-vmss-test-rg-vnet-nic01）を指定し、仮想マシン スケール セット（例: niikawa-vmss-test-scaleset2）を作成しています。
- イメージは”OpenLogic:CentOS:7.7:latest” を指定しています。（”CentOS” だけの指定では、CentOS 7.5がインストールされてしまいました）
- スケール セットの作成時にネットワーク セキュリティ グループを割り当てなかった場合は、後からネットワーク セキュリティ グループを追加で割り当てが可能です。
- アップグレードモードは手動を指定しました。各パラメータの意味は下記の通りです。
- 自動 – このモードでは、スケール セットは VM の停止順序を保証しません。 スケール セットは、すべての VM を同時に停止できます。
- ローリング – このモードでは、スケール セットは更新をバッチでロールアウトします。必要に応じて、バッチ間の一時停止時間を設定します。
- 手動 – このモードでは、スケール セット モデルの更新時に、既存の VM は更新されません。
- カスタム データに、ローカルPCに配置されたcloud-init スクリプトを指定可です。WindowsのPCからPowerShell を使用している場合は、スクリプトの文字コードをShift JIS にする必要がありました。（但し、今回の検証ではyumのインストールが実行できなかったため、手動でセットアップを行っています）
- スケール セットの作成時に、Azure Portalで作成済みのazureuserユーザーのSSH 公開キーを指定しています。
az vmss create --resource-group niikawa-vmss-test-rg --name niikawa-vmss-test-scaleset2 --load-balancer niikawa-vmss-test-lb2 --nsg basicNsgniikawa-vmss-test-rg-vnet-nic01 --image OpenLogic:CentOS:7.7:latest --upgrade-policy-mode manual --custom-data cloud-config.yaml --admin-username azureuser --ssh-key-value "ssh-rsa AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA= generated-by-azure"
ロードバランサーに正常性プローブを作成
- 作成済みのリソース グループ（例: niikawa-vmss-test-rg）、ロード バランサー（例: niikawa-vmss-test-lb2）を指定し、正常性プローブ（例: niikawa-vmss-test-lb2-probe）を作成しています。
az network lb probe create --resource-group niikawa-vmss-test-rg --name niikawa-vmss-test-lb2-probe --lb-name niikawa-vmss-test-lb2 --port 80 --protocol tcp --interval 5
ロードバランサーに負荷分散規則を追加
- 作成済みのリソース グループ（例: niikawa-vmss-test-rg）、ロード バランサー（例: niikawa-vmss-test-lb2）、フロントエンド IP アドレス（例: LoadBalancerFrontEnd）、バックエンド プール（例: niikawa-vmss-test-bepool2）、正常性プローブ（例: niikawa-vmss-test-lb2-probe）を指定し、負荷分散規則（例: niikawa-vmss-test-lb2-rule）を作成しています。
- アウトバウンド規則を使用して、バックエンド プールのメンバーがインターネットにアクセスできるようにするには、”disable-outbound-snat true” を指定します。
az network lb rule create --resource-group niikawa-vmss-test-rg --name niikawa-vmss-test-lb2-rule --lb-name niikawa-vmss-test-lb2 --probe-name niikawa-vmss-test-lb2-probe --backend-pool-name niikawa-vmss-test-bepool2 --backend-port 80 --frontend-ip-name LoadBalancerFrontEnd --frontend-port 80 --protocol tcp --disable-outbound-snat true
ロードバランサーにアウトバウンド規則を追加
- 作成済みのリソース グループ（例: niikawa-vmss-test-rg）、ロード バランサー（例: niikawa-vmss-test-lb2）、フロントエンド IP アドレス（例: LoadBalancerFrontEnd）、バックエンド プール（例: niikawa-vmss-test-bepool2）、正常性プローブ（例: niikawa-vmss-test-lb2-probe）を指定し、アウトバウンド規則（例: niikawa-vmss-test-lb2-outbound）を作成しています。
- “outbound-ports”は、インスタンスに対する送信 SNAT に関連した設定です。インスタンスごとのポート数には、AzurePortalでアウトバウンド規則を作成時に表示された”7992″ を指定します。
az network lb outbound-rule create --resource-group niikawa-vmss-test-rg --name niikawa-vmss-test-lb2-outbound --lb-name niikawa-vmss-test-lb2 --address-pool niikawa-vmss-test-bepool2 --frontend-ip-configs LoadBalancerFrontEnd --idle-timeout 4 --protocol all --outbound-ports 7992
疎通テスト
- クライアントより、Webブラウザ or curlコマンドを使用して、ロード バランサーのパブリック IP アドレスに疎通テストを行います。
- 以下、Webブラウザの結果です。
niikawa@niikawa1:~$ curl http://xx.xx.xx.xx
Hello World!
参考資料
元記事はこちら
「やさしいVMSS のデプロイ方法」
