Vanliga frågor och svar om Skalningsuppsättningar för virtuella Azure-datorer

En skalningsuppsättning kan ha 0 till 1 000 virtuella datorer baserat på plattformsbilder eller 0 till 600 virtuella datorer baserat på anpassade avbildningar.

Ja. En skalningsuppsättning kan definiera konfigurationen av en ansluten datadisk 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 Managed Disks (Premium v2, Premium, Standard, Ultra)
• Azure Files (SMB- eller NFS-delade enheter)
• Azure Netapp Files
• Delade diskar i Azure
• Operativsystemenhet
• Temporär enhet (lokal, backas inte upp av Azure Storage)
• Azure-datatjänst (till exempel Azure Table Storage eller Azure Blob Storage)
• Extern datatjänst (till exempel en fjärrdatabas)

Alla regioner stöder skalningsuppsättningar.

Alla SKU:er stöds för VM-skalningsuppsättningar.

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

Uppgradering av OS-avbildning är en gradvis och icke-störande process som uppdaterar OS-avbildningen för hela vm-skalningsuppsättningen över tid, vilket säkerställer minimal påverkan på arbetsbelastningar som körs.

Reimage är en mer omedelbar och störande åtgärd som endast påverkar den valda vm-instansen, stoppar den tillfälligt och installerar om operativsystemet.

Läs mer om skillnaden mellan uppgradering av os-avbildning och Omimage.

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

Du kan ändra ordningen för borttagning av virtuella datorer 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-zonindelad) 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 vm-skalningsuppsättningar. 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 kontrollnoddatorer (som ofta kräver unik konfiguration) i en tillgänglighetsuppsättning och placera datanoder i skalningsuppsättningen.

Ja. Mer information finns i dokumentet om skalningsuppsättningszonen.

Se Metodtips för automatisk skalning av virtuella datorer.

Se Mått som stöds med Azure Monitor.

Ja. De här exemplen finns i Vanliga mått för automatisk skalning i Azure Monitor.

Använd följande JSON för en Service Bus-kö:

"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 resursens 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 baserat på ett gästoperativsystem.

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

Ett fullständigt exempel för VM-skalningsuppsättningar finns i Avancerad autoskalningskonfiguration med hjälp av Resource Manager-mallar 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 om mått för VM-skalningsuppsättningar via PowerShell eller Azure CLI. Mer information finns i Azure Monitor PowerShell-snabbstartsexempel och Azure Monitor plattformsoberoende CLI-snabbstartsexempel.

Vm-skalningsuppsättningen TargetResourceId 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 för att ange 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 vanliga mått för automatisk skalning i Azure Monitor.

Se Skala en VM-skalningsuppsättning automatiskt. Du kan också konfigurera autoskalning med Azure CLI - och Azure-mallarna.

Nej. Om autoskalningsregler kräver fler VM-instanser som en del av en skalningsuppsättning skapas en ny VM-instans. VM-instanser som stoppas (frigörs) startas inte som en del av en autoskalningshändelse. De stoppade (frigjorda) virtuella datorerna kan dock tas bort som en del av en autoskalningshändelse som skalar i antalet instanser, på samma sätt som alla VM-instanser kan tas bort baserat på ordningen på VM-instans-ID:n.

Om du vill skicka ett certifikat på ett säkert sätt till den virtuella datorn 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 i ett Azure-gränssnitt använder du följande Azure CLI-instruktion, som skrivs ut till stdout:

az sf cluster create -h

Självsignerade 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 service fabric-kluster som är avsedda att vara värdar för företagets produktionslösningar. Mer säkerhetsvägledning finns i Metodtips för Azure Service Fabric-säkerhet och Säkerhetsscenarier för Service Fabric-kluster.

Ja. REST-API:et 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. Den här åtgärden 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 anpassat skripttillägg för att manuellt ta bort certifikatet 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 Azure 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.

Det här felet kan inträffa om du försöker lägga till samma valv igen 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 fler hemligheter.

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

Den förväntade indatastrukturen finns i Skapa eller uppdatera en virtuell datoruppsä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. Men de virtuella datorer som har certifikatet och som redan har distribuerats har det gamla certifikatet.

Du behöver inte hårdkoda lösenord i skript. Du kan dynamiskt hämta lösenord 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 secret store get certificate även ut lösenordet för .pfx-filen.

En WinRM-certifikatreferens (Windows Remote Management) måste finnas i Secrets egenskapen för operativsystemprofilen.

Syftet med att ange källvalvet är att tillämpa ACL-principer (Access Control List) som finns i en användares Azure Cloud Services-modell. Om källvalvet inte har angetts kan användare som inte har behörighet att distribuera eller komma åt hemligheter till ett nyckelvalv via en beräkningsresursprovider (CRP). ACL:er finns även för resurser som inte finns.

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

Certifikat läggs till i alla dina virtuella datorer, även befintliga. Om egenskapen Vm-skalningsuppsättning upgradePolicy är inställd manualpå läggs certifikatet till på 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 kundhanterat 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 återskapar en virtuell dator tas certifikat bort. Om du återskapar tas hela operativsystemdisken bort.

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

CRP-komponenten gör inte kundhemligheter beständiga. Om du kör stop deallocate för alla virtuella datorer i VM-skalningsuppsättningen tas cachen 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 en infrastrukturresurser).

Syftet är att tydliggöra för användaren vilket certifikat som distribueras på deras virtuella datorer.

Om du skapar en virtuell dator och sedan uppdaterar din hemlighet i nyckelvalvet laddas inte det nya certifikatet 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 det här problemet 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 överföring av ett certifikat som en base64-sträng kan du extrahera den senaste versions-URL:en i en 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ållstypprogrammet /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-lager ovanpå CRP. Båda komponenterna är en del av beräkningsplattformen i Azure-tjänsteträdet.

Ur ett efterlevnadsperspektiv är Vm-skalningsuppsättningar en grundläggande del av Azure-beräkningsplattformen. De delar följande med CRP: ett team, verktyg, processer, distributionsmetodik, säkerhetskontroller, jit-kompilering , övervakning och aviseringar. Vm-skalningsuppsättningar är PCI-kompatibla (Payment Card Industry) eftersom CRP är en del av den aktuella DSS-attesteringen (PCI Data Security Standard).

För mer information, se Microsoft Trust Center.

Ja. Mer information finns i översikten över hanterade identiteter. Du kan se några exempel på MSI-mallar i Azure-snabbstartsmallar för Linux och Windows.

I Azure-portalen har du möjlighet att 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 kan inte ta bort instansen. Men om du massval flera instanser och någon av dessa instanser har ett lås på plats, respekteras inte låsen. Alla valda instanser tas bort.

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

Om du vill ta bort ett tillägg för vm-skalningsuppsättningar 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 extensionName värdet i $vmss.

Ett mallexempel för vm-skalningsuppsättningar som integreras med Azure Monitor-loggar finns i det andra exemplet i Distribuera ett Azure Service Fabric-kluster och aktivera övervakning med hjälp av Azure Monitor-loggar.

Om uppdateringsprincipen är inställd på automatisk uppdateras alla virtuella datorer genom att omdistribuera mallen med de nya tilläggsegenskaperna.

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

Om tilläggsdefinitionen i vm-skalningsuppsättningsmodellen uppdateras och upgradePolicy egenskapen är inställd på automaticuppdaterar den de virtuella datorerna. Om egenskapen upgradePolicy är inställd på manualflaggas tillägg som inte matchar modellen.

Om en befintlig virtuell dator är tjänstläkt visas den som en omstart och tilläggen körs inte igen. Om en virtuell dator återskapas liknar processen att ersätta operativsystemenheten med källavbildningen. Alla specialiseringar från den senaste modellen, till exempel tillägg, körs igen.

Om du vill ansluta en VM-skalningsuppsättning till en Active Directory-domän 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')]"
                }
            }
        }
    ]
}

Du kan använda tillägget För önskad tillståndskonfiguration i Azure Automation. Om operativsystemet är Windows Server 2012 R2 hämtar Azure installationsprogrammet för Windows Management Framework (WMF) 5.0, startar om och fortsätter sedan med konfigurationen.

Konfigurera skyddade inställningar med lagringskontonyckeln och namnet. Mer information finns i Tillägg för anpassat skript.

Du kan:

• Ändra vm-skalningsuppsättningsmodellen direkt. Det här alternativet är endast tillgängligt med API 2017-12-01 och senare versioner.

  Uppdatera administratörsautentiseringsuppgifterna direkt i skalningsuppsättningsmodellen (till exempel med hjälp av Azure Resource Explorer, PowerShell eller Azure 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 har återskapats.

• Återställ lösenordet med hjälp av tilläggen för vm-åtkomst. Se till att följa lösenordskraven enligt beskrivningen i vanliga frågor och svar.

  Att använda ett tillägg för vm-åtkomst kräver inte att du ändrar storlek eftersom tillägget inte uppdaterar lösenordet i modellen. Tillägget kör ett skript för att lägga till lösenordet i lösenordet eller till SSH-nyckelfilen. Tillägget tar inte bort den ursprungliga SSH-nyckeln. När tillägget har uppdaterats uppgraderar du instanserna för att tillämpa uppdateringarna på användarnamnet och lösenordet på alla vm-instanser.

  Kommentar

  Om principen för automatisk uppgradering är inställd manualpå väljer du instansen manuellt för att utföra en uppgraderingsåtgärd på enskilda vm-instanser. Om automatisk uppgradering är inställt på Autouppgraderas tillägget automatiskt. Mer information finns i Automatiska tilläggsuppgraderingar

  Använd följande PowerShell-exempel för en Skalningsuppsättning för virtuella Windows-datorer:

  $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
  

  Använd följande Azure CLI-exempel för en Skalningsuppsättning för virtuella Linux-datorer:

  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. Du kan använda en NSG direkt på en skalningsuppsättning genom att referera till den networkInterfaceConfigurations i avsnittet i nätverksprofilen. Här är ett 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 och de finns i samma prenumeration och region kan du frigöra de offentliga IP-adresserna från var och en och tilldela till den andra. Mer information finns i VIP-växling: Blågrön distribution i Azure Resource Manager. Det kan dock uppstå en fördröjning eftersom resurserna frigörs eller allokeras på nätverksnivå. Ett snabbare alternativ är att använda Azure Application Gateway med två serverdelspooler och en routningsregel. Du kan också vara värd för ditt program med Azure App Service, som stöder 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ättningar är alltid dynamisk, men det betyder 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.

Se 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 avsnittet skalningsuppsättning networkInterfaceConfigurations . Här är ett 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 av resursen Microsoft.Compute/virtualMachineScaleSets är 2017-03-30 och lägger till ett publicipaddressconfiguration JSON-paket i skalningsuppsättningsavsnittet ipConfigurations . Här är ett exempel:

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

Ja. Du kan lägga till resurs-ID:n för flera application gateway-serverdelsadresspooler applicationGatewayBackendAddressPools i listan i avsnittet i ipConfigurations din skalningsuppsättningsnätverksprofil.

En anledning till att skapa en VM-skalningsuppsättning med färre än två virtuella datorer är att använda elastiska egenskaper för en VM-skalningsuppsättning. Du kan till exempel distribuera en VM-skalningsuppsättning utan virtuella datorer för att definiera din infrastruktur utan att betala driftskostnader för virtuella datorer. När du sedan är redo att distribuera virtuella datorer kan du öka 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 bryr dig mindre om tillgänglighet än om du använder en tillgänglighetsuppsättning med diskreta virtuella datorer. Vm-skalningsuppsättningar ger dig ett sätt att arbeta med icke-differentierade beräkningsenheter som är roliga. Den här likformigheten är en viktig differentiering 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-portalen går du till avsnittet Egenskaper för vm-skalningsuppsättning, väljer fönstret Skalning 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 kommer 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, det kan du.

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 för att hantera korrigeringar finns i Uppgradera en VM-skalningsuppsättning.

Ja, du kan använda återimeringsåtgärden för att återställa en virtuell dator utan att ändra avbildningen. Men om vm-skalningsuppsättningen refererar till en plattformsavbildning med version = latestkan den virtuella datorn uppdatera till en senare operativsystemavbildning när du anropar reimage.

Ja, det kan du genom att installera Azure Monitor-tillägget på de virtuella skalningsuppsättningsdatorerna. Här är ett exempel som använder 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'}"

Du hittar den nödvändiga workspaceId och workspaceKey i Log Analytics-arbetsytan i Azure-portalen. På sidan Översikt väljer du panelen Inställningar. Välj fliken Anslut källor längst upp.

Om du vill aktivera startdiagnostik skapar du först ett lagringskonto. Placera sedan det här JSON-blocket i vm-skalningsuppsättningen virtualMachineProfileoch uppdatera vm-skalningsuppsättningen:

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

När en ny virtuell dator skapas InstanceView visar egenskapen för den virtuella datorn information för skärmbilden. 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"
}

Gå till sidan Felsökning av vanliga problem med vm-skalningsuppsättningar .

Du kan anropa ListVMInstanceViews genom att göra ett REST-API GET på följande resurs-URI:

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

Observera att feldomänen inte returneras när skalningsuppsättningen använder maximal spridning (platformFaultDomainCount = 1), eftersom det inte finns någon garanti för hur många feldomäner som ska användas med den här inställningen.

Nej, det kan du inte. Tillägg kan dock fungera baserat på de unika egenskaperna för den virtuella dator som de körs på, till exempel på 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.

Luckor beror på att egenskapen Vm-skalningsuppsättning overprovision är inställd på standardvärdet trueför . Om överetablering är inställt på trueskapas fler virtuella datorer än begärt. Extra virtuella datorer tas sedan bort. I det här fallet får du ökad distributionstillförlitlighet, men på bekostnad av sammanhängande regler för 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åverkas inte distributionens tillförlitlighet nämnvärt.

Den största skillnaden är att deallocate de virtuella hårddiskarna inte tas bort. Det finns lagringskostnader som är associerade med att köra stop deallocate. Du kan använda det ena eller det andra av följande skäl:

• Du vill sluta betala beräkningskostnader, men du vill behålla disktillståndet för de virtuella datorerna.
• Du vill starta en uppsättning virtuella datorer snabbare än du kan skala ut en VM-skalningsuppsättning.
  • I det här scenariot kan du ha skapat en egen autoskalningsmotor och vill ha en snabbare skalning från slutpunkt till slutpunkt.
• Du har en vm-skalningsuppsättning som är ojämnt fördelad över feldomäner eller uppdateringsdomäner. Den här ojämna fördelningen kan bero på att du har tagit bort virtuella datorer selektivt eller på att virtuella datorer har tagits bort efter överetablering. Körs stop deallocate följt av start på VM-skalningsuppsättningen distribuerar de virtuella datorerna jämnt mellan feldomäner eller uppdateringsdomäner.

Skapa en ögonblicksbild från en instans av en VM-skalningsuppsättning. Här är ett exempel:

$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. Här är ett exempel:

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