Vanliga frågor och svar om Virtual Machine Scale Sets

En skalningsuppsättning kan ha 0 till 1 000 virtuella datorer baserade på plattformsavbildningar, eller 0 till 600 virtuella datorer baserade på anpassade avbildningar.

Ja. En skalningsuppsättning kan definiera en konfiguration för anslutna datadiskar som gäller för alla virtuella datorer i uppsättningen. Mer information finns i Azure scale sets and attached data disks (Azure-skalningsuppsättningar och anslutna datadiskar). Andra alternativ för att lagra data är:

• Azure-filer (delade SMB-enheter)
• Delade diskar i Azure
• OS-enhet
• Temporär enhet (lokal, backas inte upp av Azure Storage)
• Azure-datatjänst (t.ex. Azure-tabeller, Azure-blobbar)
• Extern datatjänst (t.ex. fjärrdatabas)

Alla regioner stöder skalningsuppsättningar.

Skapa och avbilda en VM-avbildning och använd den sedan som källa för din skalningsuppsättning. Om du vill ha en självstudiekurs om hur du skapar och använder en anpassad virtuell datoravbildning kan du använda Azure CLI eller Azure PowerShell

Som standard tas virtuella datorer bort från skalningsuppsättningen jämnt mellan tillgänglighetszoner (om skalningsuppsättningen distribueras i zonindelade konfigurationer) och feldomäner för att maximera tillgängligheten. Virtuella datorer med högst ID tas bort först.

Du kan ändra ordningen på borttagningen av den virtuella datorn genom att ange en inskalningsprincip för skalningsuppsättningen.

Om du ökar kapaciteten till 18 skapas 3 nya virtuella datorer. Varje gång ökas den virtuella datorinstansens ID från det tidigare högsta värdet (t.ex. 20, 21, 22). Virtuella datorer balanseras mellan feldomäner.

Ja, du kan använda sekvensering av skalningsuppsättningstillägg .

En regional (icke-zonindead) skalningsuppsättning använder placeringsgrupper , som fungerar som en implicit tillgänglighetsuppsättning med fem feldomäner och fem uppdateringsdomäner. Skalningsuppsättningar med fler än 100 virtuella datorer sträcker sig över flera placeringsgrupper. Mer information om placeringsgrupper finns i Arbeta med stora skalningsuppsättningar för virtuella datorer. En tillgänglighetsuppsättning för virtuella datorer kan finnas i samma virtuella nätverk som en skalningsuppsättning för virtuella datorer. En vanlig konfiguration är att placera virtuella kontrollnodsdatorer (som ofta kräver unika konfigurationer) i en tillgänglighetsuppsättning och placera datanoder i skalningsuppsättningen.

Ja! Mer information finns i dokumentet om skalningsuppsättningszoner.

Metodtips för autoskalning finns i Metodtips för automatisk skalning av virtuella datorer.

Måttnamn för autoskalning som använder värdbaserade mått finns i Mått som stöds med Azure Monitor.

Ja. Exempel på automatisk skalning baserat på ett Azure Service Bus-ämne och kölängd finns i Azure Monitor vanliga mått för automatisk skalning.

För en Service Bus-kö använder du följande JSON:

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

Använd följande JSON för en lagringskö:

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

Ersätt exempelvärden med dina resurs-URI:er (Uniform Resource Identifiers).

Du kan skapa en autoskalningsinställning på en virtuell dator för att använda mått på värdnivå eller mått baserade på gästoperativsystem.

En lista över mått som stöds finns i Azure Monitor vanliga mått för automatisk skalning.

Ett fullständigt exempel för VM-skalningsuppsättningar finns i Avancerad autoskalningskonfiguration med hjälp av Resource Manager för VM-skalningsuppsättningar.

Exemplet använder CPU-måttet på värdnivå och ett mått för antal meddelanden.

Du kan skapa aviseringar för mått för VM-skalningsuppsättningar via PowerShell eller Azure CLI. Mer information finns i Azure Monitor snabbstartsexempel för PowerShell och Azure Monitor cli-snabbstartsexempel för flera plattformar.

TargetResourceId för VM-skalningsuppsättningen ser ut så här:

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

Du kan välja vilken VM-prestandaräknare som helst som mått att ställa in en avisering för. Mer information finns i Mått för gästoperativsystem för Resource Manager-baserade virtuella Windows-datorer och mått för gästoperativsystem för virtuella Linux-datorer i artikeln om Azure Monitor för automatisk skalning.

Om du vill konfigurera autoskalning på en VM-skalningsuppsättning med hjälp av PowerShell kan du gå till Skala en VM-skalningsuppsättning automatiskt. Du kan också konfigurera autoskalning med Azure CLI och Azure-mallar

Nej. Om regler för automatisk skalning kräver ytterligare VM-instanser som en del av en skalningsuppsättning skapas en ny VM-instans. VM-instanser som stoppas (frisallokeras) startas inte som en del av en autoskalningshändelse. De stoppade (friplacerade) virtuella datorerna kan dock tas bort som en del av en autoskalningshändelse som skalar in antalet instanser, på samma sätt som alla virtuella datorinstanser kan tas bort baserat på ordningen på INSTANS-ID:t för den virtuella datorn.

Om du vill skicka ett certifikat till den virtuella datorn på ett säkert sätt kan du installera ett kundcertifikat direkt i ett Windows-certifikatarkiv från kundens nyckelvalv.

Använd följande 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"
            }
        ]
    }
]

Koden stöder Windows och Linux.

Mer information finns i Skapa eller uppdatera en VM-skalningsuppsättning.

I det senaste exemplet används följande azure CLI-instruktion i Azure Shell. Läs CLI-modulen Service Fabrics Exempeldokumentation, som skrivs ut till stdout:

az sf cluster create -h

Själv signerade certifikat kan inte användas för distribuerat förtroende som tillhandahålls av en certifikatutfärdare och bör inte användas för något Service Fabric-kluster som är avsett att vara värd för företagsproduktionslösningar. Mer information Service Fabric säkerhetsvägledning finns i Metodtips för säkerhet i Azure Service Fabric och Service Fabric för klustersäkerhet.

Ja. Den REST API för osProfile liknar standard-VM-REST API.

Inkludera osProfile i mallen:

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

Det här JSON-blocket används i den här Azure-snabbstartsmallen.

Mer information finns i Skapa eller uppdatera en VM-skalningsuppsättning.

Om du vill ta bort inaktuella certifikat tar du bort det gamla certifikatet från listan med valvcertifikat. Lämna alla certifikat som du vill behålla på datorn i listan. Detta tar inte bort certifikatet från alla dina virtuella datorer. Det lägger inte heller till certifikatet till nya virtuella datorer som skapas i VM-skalningsuppsättningen.

Om du vill ta bort certifikatet från befintliga virtuella datorer använder du ett tillägg för anpassat skript för att manuellt ta bort certifikaten från certifikatarkivet.

Om du endast tillhandahåller de virtuella datorerna med en offentlig SSH-nyckel behöver du inte placera de offentliga nycklarna i Key Vault. Offentliga nycklar är inte hemliga.

Du kan ange offentliga SSH-nycklar i oformaterad text när du skapar en virtuell Linux-dator:

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

Ett exempel finns i snabbstartsmallen vm-sshkey GitHub.

Update-AzVmss: Lista hemlighet innehåller upprepade instanser av /subscriptions/ <my-subscription-id> /resourceGroups/internal-rg-dev/providers/Microsoft.KeyVault/vaults/internal-keyvault-dev, vilket inte tillåts.

Detta kan inträffa om du försöker lägga till samma valv på nytt i stället för att använda ett nytt valvcertifikat för det befintliga källvalvet. Kommandot Add-AzVmssSecret fungerar inte korrekt om du lägger till ytterligare hemligheter.

Om du vill lägga till fler hemligheter från samma nyckelvalv uppdaterar du listan $vmss.properties.osProfile.secrets[0].vaultCertificates.

Information om den förväntade indatastrukturen finns i Skapa eller uppdatera en vm-uppsättning.

Hitta hemligheten i VM-skalningsuppsättningsobjektet som finns i nyckelvalvet. Lägg sedan till certifikatreferensen (URL:en och namnet på det hemliga arkivet) i listan som är associerad med valvet.

Nya virtuella datorer har inte det gamla certifikatet. Virtuella datorer som har certifikatet och som redan har distribuerats har dock det gamla certifikatet.

Du behöver inte hårdkoda lösenord i skript. Du kan hämta lösenord dynamiskt med de behörigheter som du använder för att köra distributionsskriptet. Om du har ett skript som flyttar ett certifikat från nyckelvalvet för det hemliga arkivet matar kommandot även ut lösenordet för get certificate PFX-filen.

En Windows för Fjärrhantering (WinRM) måste finnas i egenskapen Hemligheter för OS-profilen.

Syftet med att ange källvalvet är att tillämpa principer för åtkomstkontrollista (ACL) som finns i en användares Azure Cloud Service-modell. Om källvalvet inte anges kan användare som inte har behörighet att distribuera eller komma åt hemligheter till ett nyckelvalv via en CRP (Compute Resource Provider). ACL:er finns även för resurser som inte finns.

Om du anger ett felaktigt källvalvs-ID men en giltig nyckelvalvs-URL rapporteras ett fel när du avsöker åtgärden.

Certifikat läggs till på alla dina virtuella datorer, även befintliga. Om egenskapen upgradePolicy för VM-skalningsuppsättningen är inställd på manuell läggs certifikatet till i den virtuella datorn när du utför en manuell uppdatering på den virtuella datorn.

Information om hur du distribuerar certifikat för virtuella Linux-datorer finns i Distribuera certifikat till virtuella datorer från ett kund hanterat nyckelvalv.

Information om hur du lägger till ett valvcertifikat i en befintlig hemlighet finns i följande PowerShell-exempel. Använd bara ett hemligt objekt.

$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

Om du avbildningar av en virtuell dator tas certifikat bort. När du avbildningar på nytt tas hela OS-disken bort.

Om hemligheten tas bort från nyckelvalvet och sedan körs för alla dina virtuella datorer och sedan startar dem igen stop deallocate uppstår ett fel. Felet beror på att CRP måste hämta hemligheterna från nyckelvalvet, men det går inte. I det här scenariot kan du ta bort certifikaten från VM-skalningsuppsättningsmodellen.

CRP-komponenten bevarar inte kundhemligheter. Om du kör stop deallocate för alla virtuella datorer i VM-skalningsuppsättningen tas cacheminnet bort. I det här scenariot hämtas hemligheter från nyckelvalvet.

Du stöter inte på det här problemet när du skalar ut eftersom det finns en cachelagrad kopia av hemligheten i Azure Service Fabric (i klientmodellen med enkel infrastruktur).

Syftet med Key Vault att ange certifikatversionen är att göra det tydligt för användaren vilket certifikat som distribueras på deras virtuella datorer.

Om du skapar en virtuell dator och sedan uppdaterar hemligheten i nyckelvalvet laddas det nya certifikatet inte ned till dina virtuella datorer. Men dina virtuella datorer verkar referera till den, och nya virtuella datorer får den nya hemligheten. För att undvika detta måste du referera till en hemlig version.

Om du vill distribuera offentliga CER-nycklar till en VM-skalningsuppsättning kan du generera en PFX-fil som endast innehåller .cer-filer. Det gör du genom att använda X509ContentType = Pfx . Läs till exempel in CER-filen som ett x509Certificate2-objekt i C# eller PowerShell och anropa sedan metoden .

Mer information finns i X509Certificate.Export-metoden (X509ContentType, String).

Om du vill emulera att skicka ett certifikat som en base64-sträng kan du extrahera den senaste versions-URL:en i Resource Manager mall. Inkludera följande JSON-egenskap i din Resource Manager mall:

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

I VM-skalningsuppsättningar och virtuella datorer måste certifikat omslutas i JSON-objekt.

Vi stöder även innehållstypen application/x-pkcs12.

Vi stöder för närvarande inte .cer-filer. Om du vill använda .cer-filer exporterar du dem till PFX-containrar.

VM-skalningsuppsättningar är ett tunt API-läger ovanpå CRP. Båda komponenterna är en del av beräkningsplattformen i Azure-tjänsteträdet.

Från ett kompatibilitetsperspektiv är VM-skalningsuppsättningar en grundläggande del av Azure Compute-plattformen. De delar ett team, verktyg, processer, distributionsmetodik, säkerhetskontroller, JIT-kompilering (just-in-time), övervakning, aviseringar och så vidare med själva CRP:n. VM-skalningsuppsättningar är PCI-kompatibla (Payment Card Industry) eftersom CRP:n är en del av den aktuella attesteringen för PCI Data Security Standard (DSS).

Mer information finns i Microsoft Trust Center.

Ja. Du kan se några exempel på MSI-mallar i Azure-snabbstartsmallar för Linux och Windows.

I Azure-portalen kan du ta bort en enskild instans eller massborttagning genom att välja flera instanser. Om du försöker ta bort en enskild instans som har ett lås på plats respekteras låset och du kommer inte att kunna ta bort instansen. Men om du massväljer flera instanser och någon av dessa instanser har ett lås kommer låset/låset inte att respekteras och alla valda instanser tas bort.

I Azure CLI kan du bara ta bort en enskild instans. Om du försöker ta bort en enda instans som har ett lås på plats respekteras låset och du kommer inte att kunna ta bort den instansen.

Om du vill ta bort ett tillägg för VM-skalningsuppsättningen använder du följande PowerShell-exempel:

$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

Du hittar värdet extensionName i $vmss .

Ett exempel på en mall för VM-skalningsuppsättning som integreras med Azure Monitor-loggar finns i det andra exemplet i Distribuera ett Azure Service Fabric-klusteroch aktivera övervakning med hjälp av Azure Monitor loggar .

Om uppdateringsprincipen är inställd på automatisk uppdaterar omdistribution av mallen med de nya tilläggsegenskaperna alla virtuella datorer.

Om uppdateringsprincipen är inställd på manuell uppdaterar du först tillägget och uppdaterar sedan manuellt alla instanser på dina virtuella datorer.

Om tilläggsdefinitionen i VM-skalningsuppsättningsmodellen uppdateras och egenskapen upgradePolicy är inställd på automatisk uppdateras de virtuella datorerna. Om egenskapen upgradePolicy är inställd på manuell flaggas tilläggen som inte matchar modellen.

Om en befintlig virtuell dator är tjänstläkad visas den som en omstart och tilläggen körs inte igen. Om en virtuell dator återställs ersätter processen operativsystemenheten med källavbildningen på liknande sätt. Eventuella specialiseringar från den senaste modellen, till exempel tillägg, körs igen.

Om du vill ansluta en VM-skalningsuppsättning till en Ad-domän (Active Directory) kan du definiera ett tillägg.

Om du vill definiera ett tillägg använder du egenskapen 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')]"
                }
            }
        }
    ]
}

Om tillägget för VM-skalningsuppsättningen försöker installera något som kräver en omstart kan du använda tillägget Azure Automation Desired State Configuration (Automation DSC). Om operativsystemet är Windows Server 2012 R2 hämtar Azure konfigurationen Windows Management Framework (WMF) 5.0, startar om och fortsätter sedan med konfigurationen.

Om du vill köra ett anpassat skript som finns i ett privat lagringskonto ställer du in skyddade inställningar med lagringskontots nyckel och namn. Mer information finns i Anpassat skripttillägg.

Det finns två huvudsakliga sätt att ändra lösenordet för virtuella datorer i skalningsuppsättningar.

• Ändra vm-skalningsuppsättningsmodellen direkt. Tillgängligt med API 2017-12-01 och senare.

  Uppdatera autentiseringsuppgifterna för administratören direkt i skalningsuppsättningsmodellen (till exempel med hjälp Azure Resource Explorer, PowerShell eller CLI). När skalningsuppsättningen har uppdaterats har alla nya virtuella datorer de nya autentiseringsuppgifterna. Befintliga virtuella datorer har bara de nya autentiseringsuppgifterna om de återställs.

• Återställ lösenordet med hjälp av VM-åtkomsttilläggen. Se till att du följer lösenordskraven enligt beskrivningen här.

  Använd följande PowerShell-exempel:

  $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
  

Ja. En nätverkssäkerhetsgrupp kan tillämpas direkt på en skalningsuppsättning genom att referera till den i avsnittet networkInterfaceConfigurations i nätverksprofilen. Exempel:

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

Om du har två VM-skalningsuppsättningar med Azure Load Balancer-serverdelar och de finns i samma prenumeration och region kan du frita de offentliga IP-adresserna från var och en och tilldela till den andra. Se VIP-växling: Blå-grön distribution i Azure Resource Manager till exempel. Detta innebär dock en fördröjning eftersom resurserna frisätts/allokeras på nätverksnivå. Ett snabbare alternativ är att använda Azure Application Gateway med två serverpooler och en routningsregel. Du kan också vara värd för ditt program med Azure App som ger stöd för snabb växling mellan mellanlagrings- och produktionsplatser.

IP-adresser väljs från ett undernät som du anger.

Allokeringsmetoden för IP-adresser för VM-skalningsuppsättning är alltid "dynamisk", men det innebär inte att dessa IP-adresser kan ändras. I det här fallet innebär "dynamisk" endast att du inte anger IP-adressen i en PUT-begäran. Ange den statiska uppsättningen med hjälp av undernätet.

Information om hur du distribuerar en VM-skalningsuppsättning till ett befintligt virtuellt Azure-nätverk finns i Distribuera en VM-skalningsuppsättning till ett befintligt virtuellt nätverk.

Ja. Om du vill använda accelererat nätverk anger du enableAcceleratedNetworking till true i skalningsuppsättningens networkInterfaceConfigurations-inställningar. Till exempel

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

Om du vill skapa en VM-skalningsuppsättning med en anpassad DNS-konfiguration lägger du till ett dnsSettings JSON-paket i skalningsuppsättningens networkInterfaceConfigurations-avsnitt. Exempel:

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

Om du vill skapa en VM-skalningsuppsättning som tilldelar en offentlig IP-adress till varje virtuell dator kontrollerar du att API-versionen för resursen Microsoft.Compute/virtualMachineScaleSets är 2017-03-30 och lägger till ett publicipaddressconfiguration JSON-paket i skalningsuppsättningens ipConfigurations-avsnitt. Exempel:

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

Ja. Du kan lägga till resurs-ID:er för flera Application Gateway-adresspooler i listan applicationGatewayBackendAddressPools i avsnittet ipConfigurations i din nätverksprofil för skalningsuppsättningen.

Ett skäl till att skapa en VM-skalningsuppsättning med färre än två virtuella datorer är att använda de elastiska egenskaperna för en VM-skalningsuppsättning. Du kan till exempel distribuera en VM-skalningsuppsättning med noll virtuella datorer för att definiera infrastrukturen utan att betala löpande kostnader för virtuella datorer. När du är redo att distribuera virtuella datorer ökar du sedan "kapaciteten" för VM-skalningsuppsättningen till antalet produktionsinstanser.

En annan orsak till att du kan skapa en VM-skalningsuppsättning med färre än två virtuella datorer är om du är mindre tillgänglig än att använda en tillgänglighetsuppsättning med diskreta virtuella datorer. Vm-skalningsuppsättningar ger dig ett sätt att arbeta med o differentierade beräkningsenheter som är delbara. Den här enhetligheten är en viktig skillnad för VM-skalningsuppsättningar jämfört med tillgänglighetsuppsättningar. Många tillståndslösa arbetsbelastningar spårar inte enskilda enheter. Om arbetsbelastningen sjunker kan du skala ned till en beräkningsenhet och sedan skala upp till många när arbetsbelastningen ökar.

Om du vill ändra antalet virtuella datorer i en VM-skalningsuppsättning i Azure Portal klickar du på bladet "Skalning" i avsnittet egenskaper för VM-skalningsuppsättning och använder skjutreglaget.

Du har viss flexibilitet i hur du hanterar aviseringar för angivna tröskelvärden. Du kan till exempel definiera anpassade webhooks. Följande webhook-exempel är från en Resource Manager mall:

{
    "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, du kan skapa en skalningsuppsättning i en befintlig resursgrupp.

Ja, du kan flytta skalningsuppsättningsresurser till en ny prenumeration eller resursgrupp.

Information om hur du uppdaterar VM-skalningsuppsättningen till en ny avbildning och hanterar korrigeringar finns i Uppgradera en VM-skalningsuppsättning.

Ja, du kan använda avbildningsåtgärden för att återställa en virtuell dator utan att ändra avbildningen. Men om VM-skalningsuppsättningen refererar till en plattformsavbildning med kan den virtuella datorn uppdateras till en version = latest senare OS-avbildning när du anropar reimage .

Ja, du kan genom att installera Azure Monitor på de virtuella datorerna i skalningsuppsättningen. Här är ett Azure CLI-exempel:

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

Du hittar det workspaceId och workspaceKey som krävs på Log Analytics-arbetsytan i Azure Portal. På sidan Översikt klickar du på Inställningar panelen. Klicka på fliken Anslutna källor högst upp.

Om du vill aktivera startdiagnostik skapar du först ett lagringskonto. Placera sedan JSON-blocket i VM-skalningsuppsättningen virtualMachineProfile och uppdatera VM-skalningsuppsättningen:

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

När en ny virtuell dator skapas visar egenskapen InstanceView för den virtuella datorn information om skärmbilden och så vidare. Här är ett exempel:

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

Om du vill hämta egenskapsinformation för varje virtuell dator utan att göra flera anrop kan du anropa genom ListVMInstanceViews att REST API på följande GET resurs-URI:

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

Nej, du kan inte skicka olika tilläggsargument till olika virtuella datorer i en VM-skalningsuppsättning. Tillägg kan dock fungera baserat på de unika egenskaperna för den virtuella dator som de körs på, till exempel datornamnet. Tillägg kan också köra frågor mot instansmetadata http://169.254.169.254 för att få mer information om den virtuella datorn.

Det finns luckor mellan VM-datornamnen för VM-skalningsuppsättningen och VM-ID:n eftersom vm-skalningsuppsättningens overprovision-egenskap har angetts till standardvärdet true. Om överetablering är inställt på sant skapas fler virtuella datorer än vad som begärts. Extra virtuella datorer tas sedan bort. I det här fallet får du ökad tillförlitlighet för distributionen, men på bekostnad av sammanhängande namngivning och sammanhängande NAT-regler (Network Address Translation).

Du kan ange den här egenskapen till false. För små VM-skalningsuppsättningar påverkar detta inte distributionens tillförlitlighet i någon större utsträckning.

Den största skillnaden mellan att ta bort en virtuell dator i en VM-skalningsuppsättning och att ta bort den virtuella datorn är att de virtuella hårddiskarna deallocate inte tas bort. Det finns lagringskostnader associerade med att köra stop deallocate . Du kan använda den ena eller den andra av någon av följande orsaker:

• Du vill sluta betala beräkningskostnader, men du vill behålla de virtuella datorernas disktillstånd.
• Du vill starta en uppsättning virtuella datorer snabbare än du kan skala ut en VM-skalningsuppsättning.
  • När det gäller det här scenariot kanske du har skapat en egen autoskalningsmotor och vill ha en snabbare skalning från hel till slut.
• Du har en VM-skalningsuppsättning som är ojämnt distribuerad mellan feldomäner eller uppdateringsdomäner. Det kan beror på att du selektivt har tagit bort virtuella datorer eller på att virtuella datorer har tagits bort efter överetablering. När stop deallocate du kör följt av på start VM-skalningsuppsättningen distribueras de virtuella datorerna jämnt mellan feldomäner eller uppdateringsdomäner.

Skapa en ögonblicksbild från en instans av en VM-skalningsuppsättning.

$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

Skapa en hanterad disk från ögonblicksbilden.

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