Azure 仮想マシン スケール セットに関してよくあるご質問

スケール セットには、プラットフォーム イメージに基づいて 0 から 1,000 個の仮想マシン (VM)、またはカスタム イメージに基づいて 0 から 600 個の VM を含めることができます。

はい。 スケール セットでは、セット内のすべての VM に適用される、接続されたデータ ディスクの構成を定義できます。 詳細については、Azure Scale Sets と接続されたデータ ディスクに関するページをご覧ください。 データを格納するための他のオプションを次に示します。

• Azure Managed Disks (Premium v2、Premium、Standard、Ultra)
• Azure Files (SMB または NFS 共有ドライブ)
• Azure NetApp Files
• Azure 共有ディスク
• オペレーティング システム ドライブ
• 一時ドライブ (ローカル、Azure Storage に保存されない)
• Azure データ サービス (Azure Table Storage、Azure Blob Storage など)
• 外部データ サービス (リモート データベースなど)

すべてのリージョンで Scale Sets がサポートされています。

仮想マシン スケール セットでは、すべての SKU がサポートされています。

VM イメージを作成してキャプチャしてから、それをスケール セットのソースとして使用します。 カスタム VM イメージを作成して使用する方法のチュートリアルについては、Azure CLI または Azure PowerShell に関するページを参照してください。

OS イメージのアップグレードは、仮想マシン スケール セット全体の OS イメージを、時間の経過とともに更新する、漸進的で中断のないプロセスであり、実行中のワークロードへの影響が最小限であることが保証されます。

再イメージ化は、選択した VM インスタンスにのみ影響する、より迅速で中断を含むアクションであり、その VM インスタンスを一時的に停止し、OS を再インストールします。

OS イメージのアップグレードと再イメージ化の相違点の詳細について説明します。

既定では、仮想マシンは、可用性ゾーン (スケール セットがゾーン構成でデプロイされている場合) および障害ドメイン間で均等にスケール セットから削除され、可用性が最大化されます。 ID が最大の VM が最初に削除されます。

スケール セットのスケールイン ポリシーを指定することで、仮想マシンの削除の順序を変更できます。

容量を 18 に増やすと、3 つの新しい VM が作成されます。 VM が作成されるたびに、VM インスタンス ID は前の最大値に増分された値となります (例: 20、21、22)。 VM は障害ドメイン間で分散されます。

はい、スケール セット拡張機能のシーケンス処理を使用できます。

リージョン (非ゾーン) スケール セットは配置グループを使用します。配置グループは、5 つの障害ドメインと 5 つの更新ドメインを使用する暗黙的な可用性セットとして機能します。 100 を超える VM のスケール セットは複数の配置グループにまたがります。 配置グループの詳細については、大規模な Virtual Machine Scale Sets の使用に関する記事をご覧ください。 VM の可用性セットは、VM Scale Sets と同じ VNET に存在できます。 一般的な構成では、(多くの場合、可用性セットに固有の構成を必要とする) 制御ノード VM とデータ ノードを Scale Sets に配置します。

はい。 詳細については、スケール セットのゾーンに関するドキュメントを参照してください。

「仮想環境の自動スケールに関するベスト プラクティス」を参照してください。

「Azure Monitor のサポートされるメトリック」を参照してください。

はい。 これらの例については、「Azure Monitor の自動スケールの一般的なメトリック」を参照してください。

Service Bus キューの場合は、次の JSON を使用します。

"metricName": "MessageCount",
"metricNamespace": "",
"metricResourceUri": "/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ServiceBus/namespaces/mySB/queues/myqueue"

ストレージ キューの場合は、次の JSON を使用します。

"metricName": "ApproximateMessageCount",
"metricNamespace": "",
"metricResourceUri": "/subscriptions/s1/resourceGroups/rg1/providers/Microsoft.ClassicStorage/storageAccounts/mystorage/services/queue/queues/mystoragequeue"

この例に使用されている値は、実際のリソースの URI (Uniform Resource Identifier) に置き換えてください。

VM の自動スケール設定は、ホストレベルのメトリックまたはゲスト オペレーティング システム ベースのメトリックを使用するように作成できます。

サポートされるメトリックの一覧については、「Azure Monitor の自動スケールの一般的なメトリック」を参照してください。

仮想マシン スケール セットの全サンプルについては、仮想マシン スケール セット向けの Resource Manager テンプレートを使用した高度な自動スケール構成に関するページを参照してください。

サンプルには、ホストレベル CPU のメトリックとメッセージ数のメトリックが使用されています。

仮想マシン スケール セットのメトリックに対するアラートは、PowerShell または Azure CLI で作成できます。 詳細については、「Azure Monitor の PowerShell クイックスタート サンプル」と「Azure Monitor クロスプラットフォーム CLI のクイックスタート サンプル」を参照してください。

仮想マシン スケール セットの TargetResourceId は次のように表示されます。

/subscriptions/yoursubscriptionid/resourceGroups/yourresourcegroup/providers/Microsoft.Compute/virtualMachineScaleSets/yourvmssname

アラートは、メトリックとなる VM のパフォーマンス カウンターを自由に選んで設定することができます。 詳細については、「Azure Monitor の自動スケールの一般的なメトリック」の記事の Resource Manager ベースの Windows VM のゲスト オペレーティング システム メトリックと Linux VM のゲスト オペレーティング システム メトリックに関するセクションを参照してください。

仮想マシン スケール セットの自動スケールに関するページを参照してください。 また、Azure CLI および Azure テンプレートを使用して、自動スケールを構成することもできます。

いいえ。 自動スケーリング ルールによって、追加の VM インスタンスがスケール セットの一部として必要とされる場合は、新しい VM インスタンスが作成されます。 停止 (割り当て解除) されている VM インスタンスは、自動スケール イベントの一部としては起動されません。 ただし、そのような停止 (割り当て解除) された VM は、任意の VM インスタンスを VM インスタンス ID の順序に基づいて削除できるのと同様に、インスタンスの数をスケールインする自動スケール イベントの一環として削除することができます。

VM に対して証明書を安全に配布するには、お客様のキー コンテナーから Windows の証明書ストアに直接、証明書をインストールします。

次の JSON を使用します。

"secrets": [
    {
        "sourceVault": {
            "id": "/subscriptions/{subscriptionid}/resourceGroups/myrg1/providers/Microsoft.KeyVault/vaults/mykeyvault1"
        },
        "vaultCertificates": [
            {
                "certificateUrl": "https://mykeyvault1.vault.azure.net/secrets/{secretname}/{secret-version}",
                "certificateStore": "certificateStoreName"
            }
        ]
    }
]

このコードは、Windows と Linux をサポートします。

詳細については、仮想マシン スケール セットの作成または更新に関するページを参照してください。

最新の例では、Azure シェルで次の Azure CLI ステートメントを使用します。これは stdout に出力されます。

az sf cluster create -h

自己署名証明書は、証明機関によって提供される分散信頼には使用できません。また、エンタープライズの実稼働ソリューションをホストすることを目的とした Service Fabric クラスターで使用することはできません。 セキュリティ ガイダンスの詳細については、「Azure Service Fabric セキュリティに関するベスト プラクティス」と「Service Fabric クラスターのセキュリティに関するシナリオ」を参照してください。

はい。 osProfile の REST API は、標準の VM REST API と似ています。

テンプレートに osProfile を含めます。

"osProfile": {
    "computerName": "[variables('vmName')]",
    "adminUsername": "[parameters('adminUserName')]",
    "linuxConfiguration": {
        "disablePasswordAuthentication": "true",
        "ssh": {
            "publicKeys": [
                {
                    "path": "[variables('sshKeyPath')]",
                    "keyData": "[parameters('sshKeyData')]"
                }
            ]
        }
    }
}

この JSON ブロックは、こちらの Azure クイックスタート テンプレートで使用されています。

詳細については、仮想マシン スケール セットの作成または更新に関するページを参照してください。

今後非推奨の証明書を削除するには、コンテナーの証明書一覧からその古い証明書を削除します。 コンピューターに残しておきたい証明書はすべて一覧に残しておいてください。 このアクションですべての VM から証明書が削除されるわけではありません。 仮想マシン スケール セットに作成された新しい VM にその証明書が追加されることもありません。

既存の VM から証明書を削除するには、証明書ストアから証明書を手動で削除するカスタム スクリプト拡張機能を使用します。

VM に提供するのが SSH の公開キーだけであれば、その公開キーを Azure Key Vault に配置する必要はありません。 公開キーはシークレットではありません。

SSH 公開キーは、Linux VM の作成時にプレーン テキストで提供できます。

"linuxConfiguration": {
    "ssh": {
        "publicKeys": [
            {
                "path": "path",
                "keyData": "publickey"
            }
        ]
    }
}

例として、vm-sshkey の GitHub クイックスタート テンプレートをご覧ください。

既存のソース コンテナーに新しいコンテナー証明書を使用するのではなく、同じコンテナーを再度追加しようとすると、このエラーが表示されることがあります。 シークレットをさらに追加している場合は、Add-AzVmssSecret コマンドが正しく動作しません。

同じキー コンテナーからシークレットを追加するには、次のリストを更新します。$vmss.properties.osProfile.secrets[0].vaultCertificates

適切な入力構造については、仮想マシン セットの作成または更新に関するページを参照してください。

キー コンテナーに存在する仮想マシン スケール セット オブジェクトから該当するシークレットを見つけてください。 その後、そのコンテナーに関連付けられているリストに証明書参照 (URL とシークレット ストア名) を追加します。

新しい VM に古い証明書が割り当てられることはありません。 ただし、証明書が存在していて、既にデプロイされていた VM には古い証明書が引き続き存在します。

スクリプトにパスワードをハードコーディングする必要はありません。 パスワードは、デプロイ スクリプトの実行時に使用するアクセス許可で動的に取得することができます。 シークレット ストアのキー コンテナーから証明書を移動するスクリプトがある場合、シークレット ストアの get certificate コマンドによって、.pfx ファイルのパスワードも出力されます。

オペレーティング システム プロファイルの Secrets プロパティに Windows リモート管理 (WinRM) 証明書参照が存在する必要があります。

ソース コンテナーを示す目的は、ユーザーの Azure Cloud Service モデル内に存在するアクセス制御リスト (ACL) ポリシーを適用することです。 ソース コンテナーを指定しないと、キー コンテナーへのシークレットのデプロイやシークレットへのアクセスに必要なアクセス許可のないユーザーが、コンピューティング リソース プロバイダー (CRP) を使用してこれらを実行できるようになります。 存在しないリソースにも ACL は存在します。

キー コンテナーの有効な URL を指定しても、指定したソース コンテナー ID が正しくない場合、操作をポーリングしたときにエラーが報告されます。

証明書は、既存の VM も含め、すべての VM に追加されます。 仮想マシン スケール セットの upgradePolicy プロパティが manual に設定されている場合は、VM で手動更新を実行したときに証明書が VM に追加されます。

Linux VM の証明書をデプロイする方法については、ユーザーが管理するキー コンテナーから証明書を VM にデプロイする方法についてのブログを参照してください。

コンテナー証明書を既存のシークレットに追加する方法については、次の PowerShell サンプルを参照してください。 シークレット オブジェクトは 1 つだけ使用します。

$newVaultCertificate = New-AzVmssVaultCertificateConfig -CertificateStore MY -CertificateUrl https://sansunallapps1.vault.azure.net:443/secrets/dg-private-enc/55fa0332edc44a84ad655298905f1809

$vmss.VirtualMachineProfile.OsProfile.Secrets[0].VaultCertificates.Add($newVaultCertificate)

Update-AzVmss -VirtualMachineScaleSet $vmss -ResourceGroup $rg -Name $vmssName

VM を再イメージ化した場合、証明書は削除されます。 再イメージ化すると、オペレーティング システム ディスク全体が削除されます。

キー コンテナーからシークレットを削除し、すべての VM に対して stop deallocate を実行した後で VM を再度起動すると、エラーが発生します。 CRP はキー コンテナーからシークレットを取得する必要がありますが、それができないためにこのエラーが発生します。 このシナリオでは、仮想マシン スケール セット モデルから証明書を削除できます。

CRP コンポーネントでは、顧客のシークレットは保持されません。 仮想マシン スケール セットのすべての VM に対して stop deallocate を実行すると、キャッシュが削除されます。 この場合、シークレットがキー コンテナーから取得されます。

スケールアウト時には、この問題が発生することはありません。(単一ファブリック テナント モデルでは) Azure Service Fabric にシークレットのコピーがキャッシュされているためです。

これは、VM にデプロイされた証明書をユーザーに明確に示すためです。

VM を作成してからキー コンテナーのシークレットを更新した場合、その新しい証明書は既存の VM にダウンロードされません。 しかし一見、既存の VM は新しい証明書を参照しているように見えます。また、新しい VM は新しいシークレットを取得します。 この問題を避けるために、シークレットのバージョンを参照する必要があります。

仮想マシン スケール セットに .cer 公開キーをデプロイするために、.cer ファイルのみを含む .pfx ファイルを生成できます。 これを行うには、X509ContentType = Pfx を実行します。 たとえば、C# または PowerShell で .cer ファイルを x509Certificate2 オブジェクトとして読み込んで、そのメソッドを呼び出します。

詳細については、「X509Certificate.Export メソッド (X509ContentType, String)」を参照してください。

Base64 文字列として証明書を渡す動作をエミュレートするには、Resource Manager テンプレート内で、バージョン管理された最新の URL を抽出してください。 Resource Manager テンプレートに次の JSON プロパティを追加します。

"certificateUrl": "[reference(resourceId(parameters('vaultResourceGroup'), 'Microsoft.KeyVault/vaults/secrets', parameters('vaultName'), parameters('secretName')), '2015-06-01').secretUriWithVersion]"

仮想マシン スケール セットと VM では、証明書は JSON オブジェクトにラップされている必要があります。

コンテンツ タイプとして application/x-pkcs12 もサポートされています。

.cer ファイルは現在サポートされていません。 .cer ファイルを使用するには、それらを .pfx コンテナーにエクスポートする必要があります。

仮想マシン スケール セットは、CRP の上のシン API レイヤーです。 どちらのコンポーネントも、Azure サービス ツリー内のコンピューティング プラットフォームの一部です。

コンプライアンスの観点からは、仮想マシン スケール セットは Azure コンピューティング プラットフォームの基幹部分です。 仮想マシン スケール セットは、チーム、ツール、プロセス、デプロイ方法、セキュリティ制御、Just-In-Time (JIT) コンパイル、監視、アラートなどを CRP 自体と共有します。 CRP は現行の PCI データ セキュリティ基準 (DSS) 構成証明の一部であるため、仮想マシン スケール セットは PCI (Payment Card Industry) に準拠しています。

詳細については、Microsoft トラスト センターを参照してください。

はい。 詳細については、マネージド ID の概要に関するページを参照してください。 Linux と Windows 用の Azure クイックスタート テンプレートで、MSI テンプレートの例をいくつか確認できます。

Azure Portal では、個々のインスタンスを削除するか、複数のインスタンスを選択して一括で削除できます。 ロックが設定されている単一のインスタンスを削除しようとした場合は、ロックが維持され、インスタンスを削除することはできません。 ただし、複数のインスタンスを一括選択し、それらのいずれかのインスタンスにロックが設定されている場合、ロックは維持されません。 選択したインスタンスはすべて削除されます。

Azure CLI では、個々のインスタンスのみを削除できます。 ロックが設定されている単一のインスタンスを削除しようとした場合は、ロックが維持され、インスタンスを削除することはできません。

仮想マシン スケール セットの拡張機能を削除するには、次の PowerShell コマンド例を使用してください。

$vmss = Get-AzVmss -ResourceGroupName "resource_group_name" -VMScaleSetName "vmssName"

$vmss=Remove-AzVmssExtension -VirtualMachineScaleSet $vmss -Name "extensionName"

Update-AzVmss -ResourceGroupName "resource_group_name" -VMScaleSetName "vmssName" -VirtualMacineScaleSet $vmss

extensionName の値は $vmss で確認できます。

Azure Monitor ログと統合する仮想マシン スケール セット テンプレートの例については、Azure Service Fabric クラスターをデプロイし、Azure Monitor ログを使用して監視を有効にする方法に関するページの 2 番目の例を参照してください。

更新ポリシーが自動に設定されている場合は、拡張機能の新しいプロパティが含まれたテンプレートを再デプロイすると、すべての VM が更新されます。

更新ポリシーが手動に設定されている場合は、まず拡張機能を更新したうえで、VM のすべてのインスタンスを手動で更新する必要があります。

仮想マシン スケール セット モデル内の拡張機能の定義を更新した場合、upgradePolicy プロパティが automatic に設定されていると VM が更新されます。 upgradePolicy プロパティが manual に設定されている場合、拡張機能にはモデルと一致していないというフラグが設定されます。

既存の VM でサービス復旧を実行した場合、これは VM の再起動と同様であり、拡張機能は再実行されません。 VM を再イメージ化した場合、プロセスはオペレーティング システム ドライブをソース イメージに置き換えた場合と同様になります。 最新モデルの特性 (拡張機能など) が再実行されます。

仮想マシン スケール セットを Active Directory ドメインに参加させるには、拡張機能を定義してください。

拡張機能を定義するには、JsonADDomainExtension プロパティを使用します。

"extensionProfile": {
    "extensions": [
        {
            "name": "joindomain",
            "properties": {
                "publisher": "Microsoft.Compute",
                "type": "JsonADDomainExtension",
                "typeHandlerVersion": "1.3",
                "settings": {
                    "Name": "[parameters('domainName')]",
                    "OUPath": "[variables('ouPath')]",
                    "User": "[variables('domainAndUsername')]",
                    "Restart": "true",
                    "Options": "[variables('domainJoinOptions')]"
                },
                "protectedsettings": {
                    "Password": "[parameters('domainJoinPassword')]"
                }
            }
        }
    ]
}

Azure Automation Desired State Configuration 拡張機能を使用できます。 オペレーティング システムが Windows Server 2012 R2 の場合、Azure は Windows Management Framework (WMF) 5.0 セットアップをプルし、再起動して構成を続行します。

ストレージ アカウント キーと名前を使用して、保護された設定を設定します。 詳細については、「カスタム スクリプト拡張機能」を参照してください。

次の操作を行うことができます。

• 仮想マシン スケール セット モデルを直接変更します。 このオプションは、API 2017-12-01 以降のバージョンでのみ使用できます。

  スケール セット モデルの管理者資格情報を直接更新します (たとえば Azure Resource Explorer、PowerShell、Azure CLI を使用します)。 スケール セットが更新されると、すべての新しい VM では新しい資格情報が使用されます。 既存の VM では、新しい資格情報は、それらが再イメージ化された場合のみ使用されます。

• VM アクセス拡張機能を使用してパスワードをリセットする。 FAQ で説明されているパスワードの要件に従っていることを確認します。

  VM アクセス拡張機能を使用しても、モデル内のパスワードは更新されないので、再イメージ化は必要はありません。 この拡張機能は、パスワードまたは SSH キー ファイルにパスワードを追加するスクリプトを実行します。 この拡張機能は、元の SSH キーを削除します。 拡張機能の更新後、インスタンスをアップグレードすると、ユーザー名とパスワードの更新がすべての VM インスタンスに適用されます。

  注意

  自動アップグレード ポリシーが manual に設定されている場合、対象インスタンスを手動で選択し、個々の VM インスタンスに対してアップグレード操作を実行してください。 自動アップグレードが Auto に設定されている場合は、拡張機能が自動的にアップグレードされます。 詳細については、拡張機能の自動アップグレードに関する記事を参照してください。

  Windows 仮想マシン スケール セットには、次の PowerShell の例を使用してください。

  $vmssName = "myvmss"
  $vmssResourceGroup = "myvmssrg"
  $publicConfig = @{"UserName" = "newuser"}
  $privateConfig = @{"Password" = "********"}
  
  $extName = "VMAccessAgent"
  $publisher = "Microsoft.Compute"
  $vmss = Get-AzVmss -ResourceGroupName $vmssResourceGroup -VMScaleSetName $vmssName
  $vmss = Add-AzVmssExtension -VirtualMachineScaleSet $vmss -Name $extName -Publisher $publisher -Setting $publicConfig -ProtectedSetting $privateConfig -Type $extName -TypeHandlerVersion "2.0" -AutoUpgradeMinorVersion $true
  Update-AzVmss -ResourceGroupName $vmssResourceGroup -Name $vmssName -VirtualMachineScaleSet $vmss
  

  Linux 仮想マシン スケール セットには、次の Azure CLI の例を使用してください。

  az vmss extension set \
    --resource-group myResouceGroup \ 
    --vmss-name myScaleSet \
    --publisher Microsoft.OSTCExtensions \
    --name VMAccessForLinux \
    --version 1.5 \
    --protected-settings "{'username': 'newUser', 'password': 'newPassword'}"
  

はい。 ネットワーク プロファイルの networkInterfaceConfigurations セクションで参照することで、スケール セットに NSG を直接適用できます。 次に例を示します。

"networkProfile": {
    "networkInterfaceConfigurations": [
        {
            "name": "nic1",
            "properties": {
                "primary": "true",
                "ipConfigurations": [
                    {
                        "name": "ip1",
                        "properties": {
                            "subnet": {
                                "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/virtualNetworks/', variables('vnetName'), '/subnets/subnet1')]"
                            },
                            "loadBalancerInboundNatPools": [
                                {
                                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('lbName'), '/inboundNatPools/natPool1')]"
                                }
                            ],
                            "loadBalancerBackendAddressPools": [
                                {
                                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/loadBalancers/', variables('lbName'), '/backendAddressPools/addressPool1')]"
                                }
                            ]
                        }
                    }
                ],
                "networkSecurityGroup": {
                    "id": "[concat('/subscriptions/', subscription().subscriptionId,'/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Network/networkSecurityGroups/', variables('nsgName'))]"
                }
            }
        }
    ]
}

Azure Load Balancer がある 2 つの仮想マシン スケール セットがあり、それらが同じサブスクリプションおよびリージョンに存在する場合、それぞれのパブリック IP アドレスの割り当てを解除し、もう一方に割り当てることができます。 詳細については、「VIP Swap: Blue-green deployment in Azure Resource Manager (VIP スワップ: Azure Resource Manager での Blue-green デプロイ)」を参照してください。 しかし、リソースの割り当て解除/割り当てがネットワーク レベルで行われるため、遅延が生じる場合があります。 高速なオプションは、Azure Application Gateway と 2 つのバックエンド プールおよびルーティング規則を使うものです。 または、Azure App Service でアプリケーションをホストすることもできます。このサービスでは、ステージング スロットと運用スロット間のすばやい切り替えをサポートしています。

IP アドレスは指定したサブネットから選択されます。

仮想マシン スケール セットに対する IP アドレスの割り当て方法は常に "動的" ですが、これらの IP アドレスが変わるわけではありません。 この場合の "動的" とは、あくまで PUT 要求での IP アドレスの指定が手動ではないということです。 サブネットを使用して静的なセットを指定してください。

仮想マシン スケール セットの既存の仮想ネットワークへのデプロイに関するページを参照してください。

はい。 高速ネットワークを使用するには、スケール セットの networkInterfaceConfigurations 設定で enableAcceleratedNetworking を true に設定します。 たとえば、次のように入力します。

"networkProfile": {
    "networkInterfaceConfigurations": [
        {
            "name": "niconfig1",
            "properties": {
                "primary": true,
                "enableAcceleratedNetworking" : true,
                "ipConfigurations": [
                ]
            }
        }
    ]
}

カスタム DNS 構成で仮想マシン スケール セットを作成するには、スケール セットの networkInterfaceConfigurations セクションに dnsSettings JSON パケットを追加します。 次に例を示します。

    "dnsSettings":{
        "dnsServers":["10.0.0.6", "10.0.0.5"]
    }

各 VM にパブリック IP アドレスを割り当てる仮想マシン スケール セットを作成するには、"Microsoft.Compute/virtualMachineScaleSets" リソースの API バージョンが 2017-03-30 であることを確認してから、スケール セットの ipConfigurations セクションに publicipaddressconfiguration JSON パケットを追加します。 次に例を示します。

    "publicipaddressconfiguration": {
        "name": "pub1",
        "properties": {
        "idleTimeoutInMinutes": 15
        }
    }

はい。 スケール セットネットワーク プロファイルの ipConfigurations セクションの applicationGatewayBackendAddressPools リストに、複数のアプリケーション ゲートウェイ バックエンド アドレス プールのリソース IP を追加できます。

VM 数が 2 個未満の仮想マシン スケール セットを作成する理由の 1 つは、仮想マシン スケール セットのエラスティック プロパティを使用することです。 たとえば、VM のランニング コストをかけずにインフラストラクチャのみを定義するために、VM が含まれていない仮想マシン スケール セットをデプロイできます。 その後 VM をデプロイする準備ができたら、運用インスタンス数に合わせて仮想マシン スケール セットの容量を増やすことができます。

2 個未満の VM で仮想マシン スケール セットを作成するもう 1 つの理由は、個別の VM で可用性セットを使うときほど可用性が問題にならないケースです。 仮想マシン スケール セットにより、代替可能で差別化されていないコンピューティング ユニットを使用できるようになります。 この均一性は、仮想マシン スケール セットと可用性セットの主な差別化要素の 1 つです。 多くのステートレス ワークロードでは、個々のユニットが追跡されません。 ワークロードが減少したら 1 つのコンピューティング ユニットにスケールダウンし、ワークロードが増加したときにユニット数をスケールアップすることができます。

Azure portal で仮想マシン スケール セットの VM 数を変更するには、仮想マシン スケール セットの [プロパティ] セクションで、[スケーリング] ペインをクリックし、スライダー バーを使用します。

アラートを処理する方法にはある程度の柔軟性があります。 たとえばカスタマイズされた webhook を定義できます。 次の webhook は、Resource Manager テンプレートからの例です。

{
    "type": "Microsoft.Insights/autoscaleSettings",
    "apiVersion": "[variables('insightsApi')]",
    "name": "autoscale",
    "location": "[parameters('resourceLocation')]",
    "dependsOn": [
        "[concat('Microsoft.Compute/virtualMachineScaleSets/', parameters('vmSSName'))]"
    ],
    "properties": {
        "name": "autoscale",
        "targetResourceUri": "[concat('/subscriptions/',subscription().subscriptionId, '/resourceGroups/', resourceGroup().name, '/providers/Microsoft.Compute/virtualMachineScaleSets/', parameters('vmSSName'))]",
        "enabled": true,
        "notifications": [
            {
                "operation": "Scale",
                "email": {
                    "sendToSubscriptionAdministrator": true,
                    "sendToSubscriptionCoAdministrators": true,
                    "customEmails": [
                        "youremail@address.com"
                    ]
                },
                "webhooks": [
                    {
                        "serviceUri": "<service uri>",
                        "properties": {
                            "key1": "custommetric",
                            "key2": "scalevmss"
                        }
                    }
                ]
            }
        ]
    }
}

はい、できます。

はい。スケール セット リソースは、新しいサブスクリプションまたはリソース グループに移動できます。

仮想マシン スケール セットを新しいイメージに更新し、パッチの適用を管理する方法については、仮想マシン スケール セットのアップグレードに関する記事を参照してください。

はい。イメージを変更せずに、再イメージ化操作を使用して VM をリセットできます。 ただし、version = latest が指定されたプラットフォーム イメージを仮想マシン スケール セットが参照している場合、reimage を呼び出すと、VM が新しいオペレーティング システム イメージに更新される可能性があります。

はい、スケール セットの VM に Azure Monitor 拡張機能をインストールすることで可能です。 Azure CLI を使用する例を次に示します。

az vmss extension set --name MicrosoftMonitoringAgent --publisher Microsoft.EnterpriseCloud.Monitoring --resource-group Team-03 --vmss-name nt01 --settings "{'workspaceId': '<your workspace ID here>'}" --protected-settings "{'workspaceKey': '<your workspace key here'}"

必須の workspaceId と workspaceKey は、Azure portal の Log Analytics ワークスペースで確認できます。 [概要] ページで、[設定] タイルを選択します。 上部の [接続されたソース] タブを選択します。

ブート診断を有効にするにはまず、ストレージ アカウントを作成します。 次に、仮想マシン スケール セットの virtualMachineProfile に次の JSON ブロックを配置して、仮想マシン スケール セットを更新します。

"diagnosticsProfile": {
    "bootDiagnostics": {
        "enabled": true,
        "storageUri": "http://yourstorageaccount.blob.core.windows.net"
    }
}

新しい VM を作成すると、VM の InstanceView プロパティにスクリーンショットの詳細が表示されます。 次に例を示します。

"bootDiagnostics": {
    "consoleScreenshotBlobUri": "https://o0sz3nhtbmkg6geswarm5.blob.core.windows.net/bootdiagnostics-swarmagen-4157d838-8335-4f78-bf0e-b616a99bc8bd/swarm-agent-9574AE92vmss-0_2.4157d838-8335-4f78-bf0e-b616a99bc8bd.screenshot.bmp",
    "serialConsoleLogBlobUri": "https://o0sz3nhtbmkg6geswarm5.blob.core.windows.net/bootdiagnostics-swarmagen-4157d838-8335-4f78-bf0e-b616a99bc8bd/swarm-agent-9574AE92vmss-0_2.4157d838-8335-4f78-bf0e-b616a99bc8bd.serialconsole.log"
}

仮想マシン スケール セットに関する一般的な問題のトラブルシューティングに関するページを参照してください。

次のリソース URI で REST API の GET を実行することで、ListVMInstanceViews を呼び出すことができます。

/subscriptions/<subscription_id>/resourceGroups/<resource_group_name>/providers/Microsoft.Compute/virtualMachineScaleSets/<scaleset_name>/virtualMachines?$expand=instanceView&$select=instanceView

スケール セットで最大拡散 (platformFaultDomainCount = 1) を使用する場合、この設定で使用される障害ドメインの数に関する保証はないため、障害ドメインは返されないことに注意してください。

いいえ、できません。 ただし、拡張機能は、それが実行される VM の一意のプロパティ (マシン名など) に基づいて動作することができます。 また、拡張機能から http://169.254.169.254 でインスタンスのメタデータを照会して、VM についての詳細情報を取得することもできます。

欠落があるのは、仮想マシン スケール セットの overprovision プロパティ が既定値 true に設定されているためです。 過剰プロビジョニングが true の場合、要求した数よりも多くの VM が作成されます。 その後、余分な VM が削除されます。 この場合、連続した名前付けと連続した NAT (ネットワーク アドレス変換) 規則が失われる代わりに、デプロイの信頼性が向上します。

このプロパティは false に設定します。 仮想マシン スケール セットの規模が小さい場合、デプロイの信頼性はさほど変わりません。

主な違いは、deallocate が仮想ハード ディスク (VHD) を削除しない点です。 stop deallocate の実行には、ストレージ コストが伴います。 どちらかを選択するのは次のような場合です。

• コンピューティングの料金の支払いは停止し、VM のディスクの状態は保持したい。
• 仮想マシン スケール セットをスケールアウトするよりも迅速に一連の VM を立ち上げる必要がある。
  • このシナリオに関連して、独自の自動スケール エンジンを作成しており、エンドツーエンドのスケーリングを高速化したい。
• 仮想マシン スケール セットが障害ドメインまたは更新ドメインに対して均等に分散されていない。 この不均等な分散の原因として、VM を選択的に削除したか、過剰プロビジョニング後に VM を削除したことが考えられます。 仮想マシン スケール セットに対して stop deallocate の後に start を実行すると、障害ドメインまたは更新ドメインに VM が均等に分散されます。

仮想マシン スケール セット のインスタンスのスナップショットを作成します。 次に例を示します。

$rgname = "myResourceGroup"
$vmssname = "myVMScaleSet"
$Id = 0
$location = "East US"

$vmss1 = Get-AzVmssVM -ResourceGroupName $rgname -VMScaleSetName $vmssname -InstanceId $Id
$snapshotconfig = New-AzSnapshotConfig -Location $location -AccountType Standard_LRS -OsType Windows -CreateOption Copy -SourceUri $vmss1.StorageProfile.OsDisk.ManagedDisk.id
New-AzSnapshot -ResourceGroupName $rgname -SnapshotName 'mySnapshot' -Snapshot $snapshotconfig

スナップショットからマネージド ディスクを作成します。 次に例を示します。

$snapshotName = "mySnapshot"
$snapshot = Get-AzSnapshot -ResourceGroupName $rgname -SnapshotName $snapshotName
$diskConfig = New-AzDiskConfig -AccountType Premium_LRS -Location $location -CreateOption Copy -SourceResourceId $snapshot.Id
$osDisk = New-AzDisk -Disk $diskConfig -ResourceGroupName $rgname -DiskName ($snapshotName + '_Disk')