Häufig gestellte Fragen zu Virtual Machine Scale Sets-Instanzen

Sie bezahlen für die zugrunde liegenden Ressourcen, die von Ihrer Skalierungsgruppe verwendet werden, z. B. VMs, Speicher und Netzwerkressourcen. Für die Skalierungsgruppe selbst fallen keine zusätzlichen Kosten an.

Eine Skalierungsgruppe kann 0 bis 1.000 auf Plattformimages basierende virtuelle Computer (VMs) bzw. 0 bis 600 auf benutzerdefinierten Images basierende virtuelle Computer enthalten.

Ja. Für eine Skalierungsgruppe kann die Konfiguration für angefügte Datenträger definiert werden, die für alle virtuellen Computer der Gruppe gilt. Weitere Informationen finden Sie unter Azure-VM-Skalierungsgruppen und angefügte Datenträger. Beispiele für andere Optionen zum Speichern von Daten:

• Azure Managed Disks: Premium v2, Premium, Standard, Ultra
• Azure Files: freigegebene SMB- (Server Message Block) oder NFS-Laufwerke (Network File System)
• Azure NetApp Files
• Freigegebene Azure-Datenträger
• Betriebssystemlaufwerk
• Temporäres Laufwerk: lokal, ohne Azure Storage
• Azure-Datendienst: z. B. Azure Table Storage oder Azure Blob Storage
• Externer Datendienst: z. B. eine Remotedatenbank

Alle Regionen unterstützen Skalierungsgruppen.

Alle SKUs werden für Virtual Machine Scale Sets-Instanzen unterstützt.

Erstellen und erfassen Sie ein VM-Image, und verwenden Sie es dann als Quelle für Ihre Skalierungsgruppe. Ein Tutorial zum Erstellen und Verwenden eines benutzerdefinierten VM-Images finden Sie in der Azure CLI oder Azure PowerShell.

Das Upgraden des Betriebssystemimage ist ein schrittweiser und unterbrechungsfreier Prozess, der das Betriebssystemimage für die gesamte VM-Skalierungsgruppe im Lauf der Zeit aktualisiert. Dadurch werden minimale Auswirkungen auf ausgeführte Workloads sichergestellt.

Reimaging ist ein unmittelbarerer und nicht unterbrechungsfreier Prozess, der nur die ausgewählte VM-Instanz betrifft und bei dem die Instanz vorübergehend angehalten und das Betriebssystem neu installiert wird.

Erfahren Sie mehr über den Unterschied zwischen Betriebssystemimage-Upgrade und Reimaging.

VMs werden standardmäßig gleichmäßig aus den Skalierungsgruppen der Verfügbarkeitszonen (wenn die Skalierungsgruppe in zonaler Konfiguration bereitgestellt wurde) und Fehlerdomänen entfernt, um die Verfügbarkeit zu maximieren. Die virtuellen Computer mit den höchsten IDs werden zuerst entfernt.

Sie können die Reihenfolge zur Entfernung der VM ändern, indem Sie eine Richtlinie für horizontales Herunterskalieren für die Skalierungsgruppe festlegen.

Wenn Sie die Kapazität auf 18 erhöhen, werden drei neue VMs erstellt. Die VM-Instanz-ID wird jeweils ausgehend vom vorherigen höchsten Wert erhöht (Beispiel: 20, 21, 22). Die VMs werden gleichmäßig auf die Fehlerdomänen verteilt.

Ja, Sie können die Erweiterungssequenzierung für Skalierungsgruppen verwenden.

Eine regionale Skalierungsgruppe (ohne Zonen) verwendet Platzierungsgruppen, die als implizite Verfügbarkeitsgruppe mit fünf Fehlerdomänen und fünf Updatedomänen fungieren. Skalierungsgruppen mit mehr als 100 VMs erstrecken sich auf mehrere Platzierungsgruppen. Weitere Informationen zu Platzierungsgruppen finden Sie unter Verwenden umfangreicher VM-Skalierungsgruppen. Eine Verfügbarkeitsgruppe mit virtuellen Computern kann sich im gleichen virtuellen Netzwerk befinden wie eine Skalierungsgruppe mit virtuellen Computern. Oftmals werden virtuelle Steuerknotencomputer (für die häufig eine eindeutige Konfiguration erforderlich ist) in einer Verfügbarkeitsgruppe und Datenknoten in der Skalierungsgruppe platziert.

Ja. Weitere Informationen hierzu finden Sie in der Dokumentation zu Skalierungsgruppen über verschiedene Verfügbarkeitszonen hinweg.

Siehe dazu Bewährte Methoden für die automatische Skalierung virtueller Computer.

Siehe dazu Unterstützte Metriken von Azure Monitor.

Ja. Diese Beispiele finden Sie unter Allgemeine Metriken für die automatische Skalierung in Azure Monitor.

Verwenden Sie für eine Service Bus-Warteschlange den folgenden JSON-Code:

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

Verwenden Sie für eine Speicherwarteschlange den folgenden JSON-Code:

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

Ersetzen Sie die Beispielwerte durch die URIs (Uniform Resource Identifiers) Ihrer Ressource.

Sie können eine Einstellung zur automatischen Skalierung auf einem virtuellen Computer erstellen, um Metriken auf Hostebene oder Metriken zu verwenden, die auf einem Gastbetriebssystem basieren.

Eine Liste mit unterstützten Metriken finden Sie unter Allgemeine Metriken für die automatische Skalierung in Azure Monitor.

Ein vollständiges Beispiel für Virtual Machine Scale Sets-Instanzen finden Sie unter Tutorial: Automatisches Skalieren einer VM-Skalierungsgruppe mit einer Azure-Vorlage.

In dem Beispiel werden die CPU-Metrik auf der Hostebene und die Metrik für die Nachrichtenanzahl verwendet.

Metrikwarnungen für Virtual Machine Scale Sets-Instanzen können über PowerShell oder die Azure-Befehlszeilenschnittstelle erstellt werden. Weitere Informationen finden Sie unter Azure Monitor – PowerShell-Schnellstartbeispiele und unter Azure Monitor – Schnellstartbeispiele für die plattformübergreifende CLI.

Das TargetResourceId-Element der VM-Skalierungsgruppe sieht wie folgt aus:

/subscriptions/IhreAbonnementID/resourceGroups/<Ihre Ressourcengruppe>/providers/Microsoft.Compute/virtualMachineScaleSets/<Name Ihrer VM-Skalierungsgruppe>

Als Metrik, für die eine Warnung festgelegt werden soll, können Sie einen beliebigen VM-Leistungsindikator auswählen. Weitere Informationen finden Sie im Artikel Allgemeine Metriken für die automatische Skalierung in Azure Monitor unter Gastbetriebssystem-Metriken für Resource Manager-basierte virtuelle Windows-Computer und Gastbetriebssystem-Metriken für virtuelle Linux-Computer.

Lesen Sie dazu Tutorial: Automatisches Skalieren einer VM-Skalierungsgruppe mit Azure PowerShell. Außerdem können Sie die automatische Skalierung mit Azure CLI und Azure-Vorlagen konfigurieren.

Nein. Wenn Regeln für die automatische Skalierung weitere VM-Instanzen als Teil einer Skalierungsgruppe erfordern, wird eine neue VM-Instanz erstellt. VM-Instanzen, die beendet wurden (bzw. deren Zuordnung aufgehoben wurde), werden im Rahmen einer Autoskalierung nicht gestartet. Die beendeten (freigegebenen) VMs können jedoch im Zuge einer Autoskalierung gelöscht werden, bei der die Anzahl der Instanzen skaliert wird, so wie jede VM-Instanz in der Reihenfolge der VM-Instanz-ID gelöscht werden kann.

Um ein Zertifikat sicher auf den virtuellen Computer zu übertragen, können Sie ein Kundenzertifikat aus dem Schlüsseltresor des Kunden direkt in einem Windows-Zertifikatspeicher installieren.

Verwenden Sie dazu den folgenden JSON-Code:

"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"
            }
        ]
    }
]

Der Code ist für Windows und Linux geeignet.

Weitere Informationen finden Sie unter Erstellen oder Aktualisieren einer Virtual Machine Scale Sets-Instanz.

Verwenden Sie für ein aktuelles Beispiel in einer Azure-Shell die folgende Azure CLI-Anweisung, die an stdout ausgibt:

az sf cluster create -h

Selbstsignierte Zertifikate können nicht für die verteilte Vertrauensstellung verwendet werden, die von einer Zertifizierungsstelle bereitgestellt wird, und sie sollten nicht für einen Service Fabric-Cluster verwendet werden, der zum Hosten von Produktionslösungen in Unternehmen vorgesehen ist. Weitere Sicherheitsleitfäden finden Sie unter Bewährte Methoden für die Azure Service Fabric-Sicherheit sowie unter Szenarien für die Clustersicherheit in Service Fabric.

Ja. Die REST-API für osProfile ist der standardmäßigen VM-REST-API ähnlich.

Nehmen Sie osProfile in Ihre Vorlage auf:

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

Dieser JSON-Block wird in dieser Azure-Schnellstartvorlage verwendet.

Weitere Informationen finden Sie unter Erstellen oder Aktualisieren einer Virtual Machine Scale Sets-Instanz.

Ein veraltetes Zertifikat können Sie entfernen, indem Sie es aus der Liste mit den Tresorzertifikaten entfernen. Belassen Sie alle Zertifikate, die auf dem Computer bleiben sollen, in der Liste. Durch diese Aktion wird das Zertifikat nicht von allen Ihren virtuellen Computern entfernt. Das Zertifikat wird auch nicht zu neuen virtuellen Computern hinzugefügt, die in der Virtual Machine Scale Sets-Instanz erstellt werden.

Wenn Sie das Zertifikat von vorhandenen virtuellen Computern entfernen möchten, verwenden Sie eine benutzerdefinierte Skripterweiterung, die das Zertifikat manuell aus Ihrem Zertifikatspeicher entfernt.

Wenn Sie die virtuellen Computer nur mit einem öffentlichen SSH-Schlüssel bereitstellen, müssen Sie die öffentlichen Schlüssel nicht in Azure Key Vault speichern. Öffentliche Schlüssel sind nicht geheim.

Sie können öffentliche SSH-Schlüssel bei der Erstellung eines virtuellen Linux-Computers im Nur-Text-Format angeben:

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

Ein Beispiel finden Sie in der GitHub-Schnellstartvorlage vm-sshkey.

Dieser Fehler kann auftreten, wenn Sie versuchen, den gleichen Tresor erneut hinzuzufügen, anstatt ein neues Tresorzertifikat für den vorhandenen Quelltresor zu verwenden. Der Befehl Add-AzVmssSecret funktioniert nicht ordnungsgemäß, wenn Sie weitere Geheimnisse hinzufügen.

Aktualisieren Sie die folgende Liste, um weitere Geheimnisse aus demselben Schlüsseltresor hinzuzufügen: $vmss.properties.osProfile.secrets[0].vaultCertificates.

Die erwartete Eingabestruktur finden Sie unter Create or update a set (Erstellen oder Aktualisieren einer Gruppe).

Suchen Sie im Schlüsseltresor das Geheimnis in der Virtual Machine Scale Sets-Instanz. Fügen Sie anschließend Ihren Zertifikatsverweis (URL und Name des Geheimnisspeichers) der dem Tresor zugeordneten Liste hinzu.

Neue VMs verfügen nicht über das alte Zertifikat. Virtuelle Computer, die über das Zertifikat verfügen und bereits bereitgestellt wurden, besitzen allerdings das alte Zertifikat.

In Skripts müssen keine hartcodierten Kennwörter verwendet werden. Sie können dynamisch Kennwörter mit den Berechtigungen abrufen, die Sie zum Ausführen des Bereitstellungsskripts verwenden. Wenn Sie über ein Skript verfügen, das ein Zertifikat aus dem Geheimnisspeicher-Schlüsseltresor verschiebt, gibt der Geheimnisspeicherbefehl get certificate auch das Kennwort der PFX-Datei aus.

In der Secrets-Eigenschaft des Betriebssystemprofils muss ein WinRM-Zertifikatverweis (Windows Remote Management) vorhanden sein.

Die Angabe des Quelltresors dient zur Erzwingung von ACL-Richtlinien (Access Control List; Zugriffssteuerungsliste) aus dem Azure Cloud Services-Modell eines Benutzers. Ohne Angabe des Quelltresors können Benutzer über einen Anbieter von Computeressourcen (Compute Resource Provider, CRP) auch ohne entsprechende Berechtigungen Geheimnisse in einem Schlüsseltresor bereitstellen oder darauf zugreifen. ACLs sind sogar für nicht vorhandene Ressourcen vorhanden.

Wenn Sie eine falsche Quelltresor-ID und eine gültige Schlüsseltresor-URL angeben, wird beim Abfragen des Vorgangs ein Fehler gemeldet.

Zertifikate werden allen Ihren virtuellen Computern hinzugefügt. Das gilt auch für bereits vorhandene virtuelle Computer. Wenn die upgradePolicy-Eigenschaft Ihrer Virtual Machine Scale Sets-Instanz auf manual festgelegt ist, wird das Zertifikat dem virtuellen Computer hinzugefügt, wenn Sie ein manuelles Update auf dem virtuellen Computer ausführen.

Eine Anleitung zum Bereitstellen von Zertifikaten für virtuelle Linux-Computer finden Sie unter Deploy Certificates to VMs from customer-managed Key Vault (Bereitstellen von Zertifikaten für virtuelle Computer über eine vom Kunden verwaltete Key Vault-Instanz).

Sehen Sie sich das folgende PowerShell-Beispiel an, wenn Sie einem vorhandenen Geheimnis ein Tresorzertifikat hinzufügen möchten. Verwenden Sie nur ein einzelnes Geheimnisobjekt.

$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

Wenn Sie für einen virtuellen Computer ein Reimaging durchführen, werden die Zertifikate gelöscht. Durch das Reimaging wird der gesamte Betriebssystemdatenträger gelöscht.

Wenn das Geheimnis aus dem Schlüsseltresor gelöscht wird und Sie anschließend für alle Ihre VMs stop deallocate ausführen und diese dann neu starten, tritt ein Fehler auf. Der Grund für den Fehler: Der CRP muss das Geheimnis aus dem Schlüsseltresor abrufen, das ist aber nicht möglich. In diesem Szenario können Sie die Zertifikate aus dem Virtual Machine Scale Sets-Modell löschen.

Durch die CRP-Komponente werden Kundengeheimnisse nicht persistent. Wenn Sie stop deallocate für alle virtuellen Computer in der Virtual Machine Scale Sets-Instanz ausführen, wird der Cache gelöscht. In diesem Szenario werden die Geheimnisse aus dem Schlüsseltresor abgerufen.

Beim horizontalen Hochskalieren tritt dieses Problem nicht auf, da eine zwischengespeicherte Kopie des Geheimnisses in Azure Service Fabric (im Einzelfabric-Mandantenmodell) vorhanden ist.

Der Zweck besteht darin, die Benutzer wissen zu lassen, welches Zertifikat genau auf ihren virtuellen Computern bereitgestellt wird.

Wenn Sie einen virtuellen Computer erstellen und anschließend Ihr Geheimnis im Schlüsseltresor aktualisieren, wird das neue Zertifikat nicht auf Ihre virtuellen Computer heruntergeladen. Ihre virtuellen Computer scheinen jedoch darauf zu verweisen, und neue virtuelle Computer erhalten das neue Geheimnis. Um dieses Problem zu vermeiden, müssen Sie auf eine Geheimnisversion verweisen.

Wenn Sie öffentliche CER-Schlüssel für eine VM-Skalierungsgruppe bereitstellen möchten, können Sie mit X509ContentType = Pfx eine PFX-Datei erstellen, die nur CER-Dateien enthält. Laden Sie beispielsweise die CER-Datei als x509Certificate2-Objekt in C# oder PowerShell, und rufen Sie dann die Methode auf.

Für weitere Informationen siehe X509Certificate.Export Method (X509ContentType, String).

Sie können das Übergeben eines Zertifikats als Base64-Zeichenfolge emulieren, indem Sie die neueste URL mit Versionsangabe in einer Resource Manager-Vorlage extrahieren. Schließen Sie in Ihre Resource Manager-Vorlage die folgende JSON-Eigenschaft ein:

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

Bei Virtual Machine Scale Sets-Instanzen und auf virtuellen Computern müssen Zertifikate mit JSON-Objekten umschlossen werden.

Wir unterstützen auch den Inhaltstyp application/x-pkcs12.

CER-Dateien werden aktuell nicht unterstützt. Zu verwendende CER-Dateien müssen in PFX-Container exportiert werden.

Bei Virtual Machine Scale Sets-Instanzen handelt es sich um eine dünne API-Schicht über dem CRP. Beide Komponenten sind Teil der Computeplattform in der Azure-Dienststruktur.

Virtual Machine Scale Sets-Instanzen sind hinsichtlich der Konformität ein grundlegender Bestandteil der Azure-Computeplattform. Sie teilen sich folgende Informationen mit dem eigentlichen CRP: Team, Tools, Prozesse, Bereitstellungsmethode, Sicherheitskontrollen, JIT-Kompilierung, Überwachung und Warnungen. Virtual Machine Scale Sets-Instanzen sind PCI-konform (Payment Card Industry), da der CRP Teil des aktuellen PCI DSS-Nachweises (Data Security Standard) ist.

Weitere Informationen finden Sie im Microsoft Trust Center.

Ja. Weitere Informationen finden Sie in der Übersicht zu verwalteten Identitäten. Einige MSI-Beispielvorlagen (Managed Service Identity) finden Sie in den Azure-Schnellstartvorlagen für Linux und Windows.

Im Azure-Portal haben Sie die Möglichkeit, eine einzelne Instanz zu löschen oder mehrere Instanzen auszuwählen und gleichzeitig in einem Schritt zu löschen. Wenn Sie versuchen, eine einzelne gesperrte Instanz zu löschen, wird die Sperre beachtet, sodass Sie die Instanz nicht löschen können. Wenn Sie jedoch mehrere Instanzen durch Mehrfachauswahl auswählen und für eine dieser Instanzen eine Sperre aktiv ist, werden die Sperren nicht beachtet. Alle ausgewählten Instanzen werden gelöscht.

An der Azure-Befehlszeilenschnittstelle können Sie nur eine einzelne Instanz löschen. Wenn Sie versuchen, eine einzelne gesperrte Instanz zu löschen, wird die Sperre beachtet, sodass Sie die Instanz nicht löschen können.

Verwenden Sie zum Löschen einer Virtual Machine Scale Sets-Erweiterung das folgende PowerShell-Beispiel:

$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

Sie finden den Wert extensionName in $vmss.

Ein Beispiel für eine Virtual Machine Scale Sets-Vorlage, die mit Azure Monitor-Protokollen integriert wird, finden Sie unter Bereitstellen eines Azure Service Fabric-Clusters und Aktivieren der Überwachung mithilfe von Azure Monitor-Protokollen im zweiten Beispiel.

Wenn die Aktualisierungsrichtlinie auf „Automatisch“ festgelegt ist, werden durch die erneute Bereitstellung der Vorlage mit den neuen Erweiterungseigenschaften alle virtuellen Computer aktualisiert.

Wenn die Aktualisierungsrichtlinie auf „Manuell“ festgelegt ist, aktualisieren Sie zunächst die Erweiterung, und aktualisieren Sie anschließend manuell alle Instanzen auf Ihren virtuellen Computern.

Wenn die Erweiterungsdefinition im Virtual Machine Scale Sets-Modell aktualisiert wird und die upgradePolicy-Eigenschaft auf automatic festgelegt ist, werden die virtuellen Computer aktualisiert. Wenn die upgradePolicy-Eigenschaft auf manual festgelegt ist, werden Erweiterungen als nicht mit dem Modell übereinstimmend gekennzeichnet.

Wenn ein vorhandener virtueller Computer vom Dienst repariert wird, wird dies wie ein Neustart behandelt, und die Erweiterungen werden nicht erneut ausgeführt. Wird ein Reimaging für eine VM durchgeführt, ist der Prozess ähnlich wie das Ersetzen des Betriebssystemlaufwerks durch das Quellimage. Sämtliche Spezialisierungen aus dem neuesten Modell (etwa Erweiterungen) werden erneut ausgeführt.

Es kann eine Erweiterung definiert werden, um einer Active Directory-Domäne eine Virtual Machine Scale Sets-Instanz hinzuzufügen.

Verwenden Sie zum Definieren einer Erweiterung die JsonADDomainExtension-Eigenschaft:

"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')]"
                }
            }
        }
    ]
}

Sie können die Azure Automation Desired State Configuration-Erweiterung verwenden. Bei Verwendung des Betriebssystems Windows Server 2012 R2 führt Azure das WMF 5.0-Setup (Windows Management Framework) aus, startet neu und setzt dann die Konfiguration fort.

Richten Sie geschützte Einstellungen mit dem Speicherkontoschlüssel und -namen ein. Weitere Informationen finden Sie unter Benutzerdefinierte Skripterweiterung.

Ihre Möglichkeiten:

• Ändern Sie das Virtual Machine Scale Sets-Modell direkt. Diese Option ist nur für API 2017-12-01 und höher verfügbar.

  Aktualisieren Sie die Administratoranmeldeinformationen direkt im Skalierungsgruppenmodell (z. B. mit dem Azure-Ressourcen-Explorer, mit PowerShell oder mit der Azure CLI). Nachdem die Skalierungsgruppe aktualisiert wurde, werden für alle neuen virtuellen Computer die neuen Anmeldeinformationen verwendet. Vorhandene VMs erhalten die neuen Anmeldeinformationen nur, wenn für sie ein Reimaging durchgeführt wird.

• Setzen Sie das Kennwort mithilfe der Zugriffserweiterungen für virtuelle Computer zurück. Achten Sie darauf, den Kennwortanforderungen zu folgen, wie in den häufig gestellten Fragen beschrieben.

  Bei Verwendung einer VM-Zugriffserweiterung ist kein Reimaging erforderlich, da durch die Erweiterung das Kennwort im Modell nicht aktualisiert wird. Die Erweiterung führt ein Skript aus, um das Kennwort an das Kennwort oder an die SSH-Schlüsseldatei anzufügen. Die Erweiterung entfernt nicht den ursprünglichen SSH-Schlüssel. Nachdem die Erweiterung aktualisiert wurde, aktualisieren Sie die Instanzen, um die Updates auf den Benutzernamen und das Kennwort für alle VM-Instanzen anzuwenden.

  Hinweis

  Wenn die Richtlinie für automatische Upgrades auf manual festgelegt ist, wählen Sie die Instanz manuell aus, um einen Upgradevorgang für einzelne VM-Instanzen auszuführen. Wenn das automatische Upgrade auf Auto festgelegt ist, wird die Erweiterung automatisch aktualisiert. Weitere Informationen finden Sie unter Automatische Aktualisierungen der Erweiterung

  Verwenden Sie das folgende PowerShell-Beispiel für eine Virtual Machine Scale Sets-Instanz unter Windows:

  $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
  

  Verwenden Sie das folgende Azure CLI-Beispiel für eine Virtual Machine Scale Sets-Instanz unter Linux:

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

Ja. Sie können eine NSG direkt auf eine Skalierungsgruppe anwenden, indem Sie im networkInterfaceConfigurations-Abschnitt des Netzwerkprofils direkt auf sie verweisen. Ein Beispiel:

"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'))]"
                }
            }
        }
    ]
}

Wenn Sie über zwei VM-Skalierungsgruppen mit Azure Load Balancer verfügen und diese sich im selben Abonnement und derselben Region befinden, können Sie die Zuordnung der öffentlichen IP-Adressen zu den einzelnen Gruppen aufheben und sie der jeweils anderen zuordnen. Weitere Informationen dazu finden Sie unter VIP Swap: Blue-green deployment in Azure Resource Manager (VIP-Tausch: Blaugrünbereitstellung in Azure Resource Manager). Unter Umständen tritt eine Verzögerung auf weil die Ressourcen auf Netzwerkebene zugeordnet werden bzw. ihre Zuordnung aufgehoben wird. Eine schnellere Option ist die Verwendung von Azure Application Gateway mit zwei Back-End-Pools und einer Routingregel. Alternativ können Sie Ihre Anwendung mit Azure App Service hosten. Dieser Dienst bietet Unterstützung für das schnelle Wechseln zwischen Staging- und Produktionsslots.

IP-Adressen werden in einem von Ihnen angegebenen Subnetz ausgewählt.

Die IP-Adresszuordnungsmethode für Virtual Machine Scale Sets-Instanzen ist immer dynamisch. Das bedeutet aber nicht, dass sich diese IP-Adressen ändern können. In diesem Fall bedeutet „dynamisch“ lediglich, dass Sie die IP-Adresse nicht in einer PUT-Anforderung angeben. Verwenden Sie zum Angeben der statischen Gruppe das Subnetz.

Weitere Informationen finden Sie unterBereitstellen einer Virtual Machine Scale Sets-Instanz für ein vorhandenes virtuelles Netzwerk.

Ja. Wenn Sie beschleunigte Netzwerke verwenden möchten, legen Sie enableAcceleratedNetworking in den networkInterfaceConfigurations-Einstellungen Ihrer Skalierungsgruppe auf true fest. Beispiel:

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

Zum Erstellen einer Virtual Machine Scale Sets-Instanz mit benutzerdefinierter DNS-Konfiguration fügen Sie dem networkInterfaceConfigurations-Abschnitt der Skalierungsgruppe ein dnsSettings-JSON-Paket hinzu. Ein Beispiel:

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

Beachten Sie beim Erstellen einer Virtual Machine Scale Sets-Instanz, die jeder VM eine öffentliche IP-Adresse zuweist, dass die API-Version der Ressource Microsoft.Compute/virtualMachineScaleSets „2017-03-30“ ist, und fügen Sie ein publicipaddressconfiguration-JSON-Paket im Abschnitt ipConfigurations der Skalierungsgruppe hinzu. Hier sehen Sie ein Beispiel:

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

Ja. Sie können die Ressourcen-IDs für mehrere Back-End-Adresspools des Anwendungsgateways der applicationGatewayBackendAddressPools-Liste im Abschnitt ipConfigurations des Netzwerkprofils Ihrer Skalierungsgruppe hinzufügen.

Ein Grund für die Erstellung einer Virtual Machine Scale Sets-Instanz mit weniger als zwei virtuellen Computern ist die Verwendung der elastischen Eigenschaften einer Virtual Machine Scale Sets-Instanz. So können Sie beispielsweise eine Virtual Machine Scale Sets-Instanz ohne virtuelle Computer bereitstellen, um Ihre Infrastruktur zu definieren, ohne die laufenden Kosten für virtuelle Computer zu bezahlen. Wenn Sie dann für die Bereitstellung von virtuellen Computern bereit sind, können Sie die Kapazität der Virtual Machine Scale Sets-Instanz auf die Anzahl von Produktionsinstanzen erhöhen.

Ein weiterer Grund für die Erstellung einer Virtual Machine Scale Sets-Instanz mit weniger als zwei virtuellen Computern wäre, wenn Sie sich weniger Gedanken um die Verfügbarkeit machen, sondern eher auf die Verwendung einer Verfügbarkeitsgruppe mit diskreten virtuellen Computern Wert legen. Virtual Machine Scale Sets-Instanzen ermöglichen die Verwendung undifferenzierter, austauschbarer Compute-Einheiten. Diese Einheitlichkeit ist ein wichtiges Unterscheidungsmerkmal von Virtual Machine Scale Sets-Instanzen im Vergleich zu Verfügbarkeitsgruppen. Bei vielen zustandslosen Workloads werden keine einzelnen Einheiten nachverfolgt. Sie können auf eine einzelne Computeeinheit herunterskalieren, wenn die Workload zurückgeht, und wieder auf viele Computeeinheiten hochskalieren, wenn sich die Workload erhöht.

Zum Ändern der Anzahl der virtuellen Computer in einer Virtual Machine Scale Sets-Instanz im Azure-Portal wählen Sie im Bereich Eigenschaften der Virtual Machine Scale Sets-Instanz das Blatt Skalierung aus und verwenden den Schieberegler.

Warnungen für angegebene Schwellenwerte können mit einer gewissen Flexibilität gehandhabt werden. So können Sie beispielsweise benutzerdefinierte Webhooks definieren. Das folgende Webhookbeispiel stammt aus einer Resource Manager-Vorlage:

{
    "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"
                        }
                    }
                ]
            }
        ]
    }
}

Ja, das ist möglich.

Ja, Sie können Skalierungsgruppenressourcen in ein neues Abonnement oder eine neue Ressourcengruppe verschieben.

Informationen zum Durchführen eines Upgrades für Ihre Virtual Machine Scale Sets-Instanz auf ein neues Image sowie zum Verwalten des Patchens finden Sie unter Durchführen eines Upgrades für eine Virtual Machine Scale Sets-Instanz.

Ja. Sie können einen virtuellen Computer mittels Reimaging zurücksetzen, ohne das Image zu ändern. Falls Ihre Virtual Machine Scale Sets-Instanz allerdings auf ein Plattformimage mit version = latest verweist, kann für Ihren virtuellen Computer ein Update auf ein höheres Betriebssystemimage durchgeführt werden, wenn Sie reimage aufrufen.

Ja, Sie können dazu die Azure Monitor-Erweiterung auf den VMs der Skalierungsgruppe installieren. Dies ist ein Beispiel unter Verwendung der Azure-Befehlszeilenschnittstelle:

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'}"

Sie finden die erforderlichen workspaceId und workspaceKey im Log Analytics-Arbeitsbereich des Azure-Portals. Klicken Sie auf der Seite Übersicht auf die Kachel Einstellungen. Wählen Sie oben die Registerkarte Verbundene Datenquellen aus.

Erstellen Sie zum Aktivieren der Startdiagnose zunächst ein Speicherkonto. Fügen Sie dann den folgenden JSON-Block unter virtualMachineProfile in die Virtual Machine Scale Sets-Instanz ein, und aktualisieren Sie die Virtual Machine Scale Sets-Instanz:

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

Beim Erstellen eines neuen virtuellen Computers zeigt die InstanceView-Eigenschaft des virtuellen Computers die Details für den Screenshot usw. an. Hier sehen Sie ein Beispiel:

"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"
}

Weitere Informationen finden Sie auf der Seite zur Problembehandlung allgemeiner Probleme mit Virtual Machine Scale Sets-Instanzen.

Sie können ListVMInstanceViews aufrufen, indem Sie einen GET-REST-API-Vorgang für den folgenden Ressourcen-URI ausführen:

/subscriptions/<Abonnement-ID>/resourceGroups/<Name der Ressourcengruppe>/providers/Microsoft.Compute/virtualMachineScaleSets/<Name der Skalierungsgruppe>/virtualMachines?$expand=instanceView&$select=instanceView

Die Fehlerdomäne wird nicht zurückgegeben, wenn die Skalierungsgruppe die maximale Streuung verwendet (platformFaultDomainCount = 1), da es bei dieser Einstellung keine Garantie dafür gibt, wie viele Fehlerdomänen verwendet werden.

Nein, das ist nicht möglich. Erweiterungen können aber unter Berücksichtigung der eindeutigen Eigenschaften der ausführenden VM (beispielsweise des Computernamens) aktiv werden. Darüber hinaus können Erweiterungen Instanzmetadaten von http://169.254.169.254 abfragen, um weitere Informationen zu dem virtuellen Computer zu erhalten.

Die Lücken haben die Ursache, dass die Eigenschaft overprovision Ihrer Virtual Machine Scale Sets-Instanz auf den Standardwert true festgelegt ist. Wenn die Überbereitstellung auf true festgelegt ist, werden mehr virtuelle Computer als angefordert bereitgestellt. Zusätzliche virtuelle Computer werden anschließend gelöscht. Dies erhöht zwar die Bereitstellungszuverlässigkeit, geht jedoch zulasten fortlaufender Namen und zusammenhängender Regeln für die Netzwerkadressenübersetzung (Network Address Translation, NAT).

Sie können diese Eigenschaft auf false festlegen. Bei kleinen VM-Skalierungsgruppen hat das keine nennenswerten Auswirkungen auf die Bereitstellungszuverlässigkeit.

Der Hauptunterschied besteht darin, dass deallocate die virtuellen Festplatten (VHDs) nicht löscht. Das Ausführen von stop deallocate ist mit Speicherkosten verbunden. Im Anschluss finden Sie Gründe für die Verwendung der einzelnen Verfahren:

• Sie möchten keine Computekosten mehr bezahlen, aber den Datenträgerzustand der virtuellen Computer beibehalten.
• Sie möchten eine Gruppe virtueller Computer schneller starten als sich eine Virtual Machine Scale Sets-Instanz aufskalieren lässt.
  • Im Zusammenhang mit diesem Szenario: Sie haben ggf. eine eigene Engine für die automatische Skalierung erstellt und möchten eine schnellere End-to-End-Skalierung erreichen.
• Sie verfügen über eine Virtual Machine Scale Sets-Instanz, die ungleichmäßig auf Fehler- bzw. Updatedomänen verteilt ist. Diese ungleiche Verteilung kann auftreten, wenn Sie selektiv virtuelle Computer gelöscht haben oder virtuelle Computer nach einer Überbereitstellung gelöscht wurden. Wenn Sie stop deallocate und anschließend start für die Virtual Machine Scale Sets-Instanz ausführen, werden die virtuellen Computer gleichmäßig auf Fehler- bzw. Updatedomänen verteilt.

Erstellen Sie eine Momentaufnahme aus einer Virtual Machine Scale Sets-Instanz. Hier sehen Sie ein Beispiel:

$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

Erstellen Sie einen verwalteten Datenträger aus der Momentaufnahme. Hier sehen Sie ein Beispiel:

$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')