Domande frequenti sui set di scalabilità di macchine virtuali di Azure

Un set di scalabilità può avere da 0 a 1.000 macchine virtuali in base alle immagini della piattaforma o da 0 a 600 macchine virtuali basate su immagini personalizzate.

Sì. Un set di scalabilità può definire la configurazione di un disco dati collegato che si applica a tutte le macchine virtuali nel set. Per altre informazioni, vedere l'articolo relativo a set di scalabilità di Azure e dischi dati collegati. Le altre opzioni per l'archiviazione dei dati includono:

• Azure Managed Disks (Premium v2, Premium, Standard, Ultra)
• File di Azure (unità condivise SMB o NFS)
• Azure Netapp Files
• Dischi condivisi di Azure
• Unità del sistema operativo
• Unità temporanea (locale, non supportata da Archiviazione di Azure)
• Servizio dati di Azure (ad esempio, Archiviazione tabelle di Azure o Archivio BLOB di Azure)
• Servizio dati esterno (ad esempio, un database remoto)

Tutte le aree supportano i set di scalabilità.

Tutti gli SKU sono supportati per i set di scalabilità di macchine virtuali.

Creare e acquisire un'immagine di macchina virtuale e quindi usarla come origine per il set di scalabilità. Per un'esercitazione sulla creazione e sull'uso dell'immagine di una macchina virtuale personalizzata, è possibile usare l'interfaccia della riga di comando di Azure o Azure PowerShell.

L'aggiornamento dell'immagine del sistema operativo è un processo graduale e senza interruzioni che aggiorna l'immagine del sistema operativo per l'intero set di scalabilità di macchine virtuali nel tempo, garantendo un impatto minimo sui carichi di lavoro in esecuzione.

La ricreazione dell'immagine è un'azione più immediata e di interruzione che influisce solo sull'istanza di macchina virtuale selezionata, arrestandola temporaneamente e reinstallando il sistema operativo.

Altre informazioni sulla differenza tra l'aggiornamento dell'immagine del sistema operativo e la ricreazione dell'immagine.

Per impostazione predefinita, le macchine virtuali vengono rimosse dal set di scalabilità in modo uniforme tra zone di disponibilità (se il set di scalabilità è distribuito in una configurazione a zone) e domini di errore per ottimizzare la disponibilità. Le VM con ID più elevato vengono rimosse per prime.

È possibile modificare l'ordine di rimozione delle macchine virtuali specificando un criterio di riduzione per il set di scalabilità.

Se si aumenta la capacità a 18, vengono create 3 nuove VM. Ogni volta, l'ID istanza della VM viene ottenuto incrementando il valore più elevato precedente (ad esempio 20, 21, 22). Le macchine virtuali vengono bilanciate tra i domini di errore.

Sì, è possibile usare la sequenziazione delle estensioni nei set di scalabilità.

Un set di scalabilità basato sull'area e non sulla zona usa i gruppi di posizionamento che fungono da set di disponibilità implicito con cinque domini di errore e cinque domini di aggiornamento. I set di scalabilità di più di 100 macchine virtuali includono più gruppi di posizionamento. Per altre informazioni sui gruppi di posizionamento, vedere Uso di set di scalabilità di macchine virtuali di grandi dimensioni. Un set di disponibilità di macchine virtuali può trovarsi nella stessa rete virtuale di un set di scalabilità di macchine virtuali. Una configurazione comune consiste nell'inserire le macchine virtuali del nodo di controllo, che spesso richiedono una configurazione univoca, in un set di disponibilità e i nodi di dati nel set di scalabilità.

Sì. Per altre informazioni, vedere il documento sulle zone del set di scalabilità.

Vedere Procedure consigliate per la scalabilità automatica delle macchine virtuali.

Vedere Metriche supportate con Monitoraggio di Azure.

Sì. Per questi esempi, vedere Metriche comuni di scalabilità automatica di Monitoraggio di Azure.

Per una coda del bus di servizio, usare il codice JSON seguente:

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

Per una coda di archiviazione, usare il codice JSON seguente:

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

Sostituire i valori dell'esempio con gli URI (Uniform Resource Identifier) della risorsa specifica.

È possibile creare un'impostazione di scalabilità automatica in una macchina virtuale per usare metriche a livello di host o metriche basate su un sistema operativo guest.

Per un elenco delle metriche supportate, vedere Metriche comuni per la scalabilità automatica di Monitoraggio di Azure.

Per un esempio completo per i set di scalabilità di macchine virtuali, vedere Configurazione avanzata della scalabilità automatica usando modelli di Resource Manager per i set di scalabilità di macchine virtuali.

L'esempio usa la metrica relativa alla CPU a livello di host e una metrica di conteggio dei messaggi.

È possibile creare avvisi sulle metriche per i set di scalabilità di macchine virtuali tramite PowerShell o l'interfaccia della riga di comando di Azure. Per altre informazioni, vedere Esempi di avvio rapido con PowerShell per Monitoraggio di Azure ed Esempi di avvio rapido dell'interfaccia della riga di comando multipiattaforma 1.0 per Monitoraggio di Azure.

Il parametro TargetResourceId del set di scalabilità di macchine virtuali è simile al seguente:

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

È possibile scegliere qualsiasi contatore delle prestazioni delle macchine virtuali come metrica per cui impostare un avviso. Per altre informazioni, vedere Metriche del sistema operativo guest per le macchine virtuali Windows basate su Resource Manager e le Metriche del sistema operativo guest per le macchine virtuali Linux nell'articolo Metriche comuni di scalabilità automatica di Monitoraggio di Azure.

Vedere Dimensionare automaticamente un set di scalabilità di macchine virtuali. È anche possibile configurare la scalabilità automatica con l'interfaccia della riga di comando di Azure e i modelli di Azure.

No. Se le regole di scalabilità automatica richiedono istanze aggiuntive della macchina virtuale come parte di un set di scalabilità, verrà creata una nuova istanza di macchina virtuale. Le istanze di macchine virtuali arrestate (deallocate) non vengono avviate come parte di un evento di scalabilità automatica. Tuttavia, le macchine virtuali arrestate (deallocate) possono essere eliminate come parte di un evento di scalabilità automatica che riduce il numero di istanze, allo stesso modo in cui qualsiasi istanza di macchina virtuale può essere eliminata in base all'ordine di ID istanza della macchina virtuale.

Per inviare in modo sicuro un certificato alla macchina virtuale, è possibile installare un certificato cliente direttamente nell'archivio certificati Windows dall'insieme di credenziali delle chiavi del cliente.

Usare il codice JSON seguente:

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

Il codice supporta Windows e Linux.

Per altre informazioni, vedere Creare o aggiornare un set di scalabilità di macchine virtuali.

Per l'esempio più recente, in una shell di Azure, usare l'istruzione seguente dell'interfaccia della riga di comando di Azure, che verrà stampata in stdout:

az sf cluster create -h

I certificati autofirmati non possono essere usati per l'attendibilità distribuita fornita da un'autorità di certificazione e non devono essere usati per cluster di Service Fabric destinati a ospitare soluzioni di produzione aziendali. Per altre indicazioni sulla sicurezza, vedere Procedure consigliate per la sicurezza di Azure Service Fabric e Scenari di sicurezza del cluster di Service Fabric.

Sì. L'API REST per osProfile è simile all'API REST della macchina virtuale standard.

Includere osProfile nel modello:

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

Questo blocco JSON viene usato in questo modello di avvio rapido di Azure.

Per altre informazioni, vedere Create or update a virtual machine scale set (Creare o aggiornare un set di scalabilità di macchine virtuali).

Per rimuovere i certificati deprecati, rimuovere il certificato precedente dall'elenco di certificati dell'insieme di credenziali. Lasciare nell'elenco tutti i certificati da conservare nel computer. Questa azione non rimuove il certificato da tutte le macchine virtuali. Non aggiunge anche il certificato alle nuove macchine virtuali create nel set di scalabilità di macchine virtuali.

Per rimuovere il certificato dalle macchine virtuali esistenti, usare un'estensione personalizzata dello script per rimuovere manualmente i certificati dall'archivio certificati.

Se si fornisce alle macchine virtuali solo una chiave SSH pubblica, non è necessario inserire le chiavi pubbliche in Azure Key Vault. Le chiavi pubbliche non sono segrete.

Quando si crea una VM Linux è possibile fornire le chiavi pubbliche SSH in testo normale:

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

Per un esempio, vedere il modello di avvio rapido vm-sshkey di GitHub.

Questo errore si può verificare se si prova ad aggiungere di nuovo lo stesso insieme di credenziali invece di usare un nuovo certificato dell'insieme di credenziali per l'insieme di credenziali di origine esistente. Il comando Add-AzVmssSecret non funziona correttamente se si aggiungono altri segreti.

Per aggiungere altri segreti dallo stesso insieme di credenziali delle chiavi, aggiornare l'elenco seguente: $vmss.properties.osProfile.secrets[0].vaultCertificates.

Per la struttura di input prevista, vedere Create or update a virtual machine set (Creare o aggiornare un set di macchine virtuali).

Trovare il segreto nell'oggetto del set di scalabilità di macchine virtuali presente nell'insieme di credenziali delle chiavi. Aggiungere quindi il riferimento al certificato, ovvero l'URL e il nome dell'archivio di certificati, all'elenco associato all'insieme di credenziali.

Le nuove macchine virtuali non includeranno il certificato precedente. Le macchine virtuali che includono il certificato e che sono già distribuite avranno tuttavia il certificato precedente.

Non è necessario impostare come hardcoded password negli script. È possibile recuperare in modo dinamico le password con le autorizzazioni usate per eseguire lo script di distribuzione. Se è presente uno script che sposta un certificato dall'insieme di credenziali delle chiavi dell'archivio di segreti, il comando get certificate dell'archivio di segreti restituisce la password del file con estensione pfx.

Un riferimento al certificato Di gestione remota Windows (WinRM) deve essere presente nella proprietà Secrets del profilo del sistema operativo.

L'indicazione dell'insieme di credenziali di origine consente di applicare i criteri dell'elenco di controllo di accesso esistenti nel modello di Servizi cloud di Azure di un utente. Se l'insieme di credenziali di origine non è specificato, gli utenti che non sono autorizzati a distribuire o ad accedere ai segreti in un insieme di credenziali delle chiavi potrebbero eseguire l'accesso tramite provider di risorse di calcolo. Gli elenchi di controllo di accesso sono presenti anche per risorse inesistenti.

Se si specifica un ID errato per l'insieme di credenziali di origine ma un URL valido per l'insieme di credenziali delle chiavi, viene segnalato un errore quando si esegue il polling dell'operazione.

I certificati vengono aggiunti a tutte le VM, comprese quelle già esistenti. Se la proprietà upgradePolicy del set di scalabilità di macchine virtuali è impostata su manual, il certificato viene aggiunto alla macchina virtuale quando si esegue un aggiornamento manuale nella macchina virtuale.

Per informazioni su come distribuire i certificati per le macchine virtuali Linux, vedere Deploy certificates to VMs from a customer-managed key vault (Distribuire certificati nelle VM da un insieme di credenziali delle chiavi gestito dai clienti).

Per aggiungere un certificato dell'insieme di credenziali a un segreto esistente, vedere l'esempio di PowerShell seguente. Usare solo un oggetto segreto.

$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

Se si ricrea l'immagine di una macchina virtuale, i certificati vengono eliminati. La ricreazione dell'immagine elimina l'intero disco del sistema operativo.

Se si elimina il segreto dall'insieme di credenziali delle chiavi e quindi si esegue stop deallocate per tutte le VM, riavviando successivamente le VM, si verificherà un errore. L'errore si verifica perché il provider di risorse di calcolo deve recuperare i segreti dall'insieme di credenziali delle chiavi ma non riesce. In questo scenario è possibile eliminare i certificati dal modello del set di scalabilità di macchine virtuali.

Il componente CRP non rende persistenti i segreti dei clienti. Se si esegue stop deallocate per tutte le macchine virtuali nel set di scalabilità di macchine virtuali, la cache viene eliminata. In questo scenario, i segreti vengono recuperati dall'insieme di credenziali delle chiavi.

Questo problema non si verifica durante il ridimensionamento del numero di istanze, perché è disponibile una copia del segreto memorizzata nella cache in Azure Service Fabric nel modello di tenant a infrastruttura singola.

Lo scopo è rendere chiaro all'utente quale certificato viene distribuito nelle macchine virtuali.

Se si crea una macchina virtuale e quindi si aggiorna il segreto nell'insieme di credenziali delle chiavi, il nuovo certificato non viene scaricato nelle macchine virtuali. Le macchine virtuali fanno tuttavia riferimento al certificato e le nuove VM ottengono il nuovo segreto. Per evitare questo problema, è necessario fare riferimento a una versione privata.

Per distribuire le chiavi pubbliche con estensione cer in un set di scalabilità di macchine virtuali, è possibile generare un file con estensione pfx che contiene solo file con estensione cer. A questo scopo, usare X509ContentType = Pfx. Ad esempio, caricare il file .cer come oggetto x509Certificate2 in C# o PowerShell e quindi chiamare il metodo.

Per altre informazioni, vedere metodo X509Certificate.Export (X509ContentType, String).

Per emulare il passaggio di un certificato come stringa Base64, è possibile estrarre l'URL con versione più recente in un modello di Resource Manager. Includere la proprietà JSON seguente nel modello di Resource Manager:

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

Nei set di scalabilità di macchine virtuali e nelle macchine virtuali è necessario eseguire il wrapping dei certificati in oggetti JSON.

È anche supportato il tipo di contenuto application/x-pkcs12.

Non sono attualmente supportati i file con estensione cer. Per usare i file con estensione cer, esportarli in contenitori PFX.

I set di scalabilità di macchine virtuali sono un livello API sottile sopra il CRP. Entrambi i componenti sono parte della piattaforma di calcolo nell'albero dei servizi di Azure.

Dal punto di vista della conformità, i set di scalabilità di macchine virtuali sono una parte essenziale della piattaforma di calcolo di Azure. Condividono il codice seguente con il CRP stesso: un team, strumenti, processi, metodologia di distribuzione, controlli di sicurezza, compilazione JIT (Just-In-Time), monitoraggio e avvisi. I set di scalabilità di macchine virtuali sono compatibili con PCI (Payment Card Industry) perché il provider di risorse di calcolo è parte dell'attestazione PCI Data Security Standard (DSS) corrente.

Per ulteriori informazioni, vedi il Centro protezione Microsoft.

Sì. Per altre informazioni, vedere Panoramica delle identità gestite. È possibile visualizzare alcuni modelli MSI di esempio nei modelli di avvio rapido di Azure per Linux e Windows.

Nel portale di Azure è possibile eliminare una singola istanza oppure applicare l'eliminazione in blocco selezionando più istanze. Se si tenta di eliminare una singola istanza in cui è stato impostato un blocco, quest'ultimo verrà rispettato e non sarà possibile eliminare l'istanza. Tuttavia, se si esegue la selezione bulk di più istanze e una di queste istanze ha un blocco sul posto, i blocchi non vengono rispettati. Tutte le istanze selezionate verranno eliminate.

Nell'interfaccia della riga di comando di Azure è possibile eliminare solo singole istanze. Se si tenta di eliminare una singola istanza in cui è stato impostato un blocco, quest'ultimo verrà rispettato e non sarà possibile eliminare l'istanza.

Per eliminare un'estensione del set di scalabilità di macchine virtuali, usare l'esempio di PowerShell seguente:

$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

Il valore extensionName è disponibile in $vmss.

Per un esempio di modello di set di scalabilità di macchine virtuali che si integra con i log di Monitoraggio di Azure, vedere il secondo esempio in Deploy an Azure Service Fabric cluster and enable monitoring by using Azure Monitor logs (Distribuire un cluster di Azure Service Fabric e abilitare il monitoraggio usando i log di Monitoraggio di Azure).

Se i criteri impostati prevedono l'aggiornamento automatico, ridistribuendo il modello con le nuove proprietà di estensione verranno aggiornate tutte le macchine virtuali.

Se i criteri di aggiornamento sono impostati su manuale, aggiornare prima di tutto l'estensione e quindi aggiornare manualmente tutte le istanze nelle macchine virtuali.

Se la definizione di estensione nel modello del set di scalabilità di macchine virtuali viene aggiornata e la proprietà upgradePolicy è impostata su automatic, aggiorna le macchine virtuali. Se la proprietà upgradePolicy è impostata su manual, le estensioni vengono contrassegnate come non corrispondenti al modello.

Il ripristino del servizio di una macchina virtuale esistente viene considerato un riavvio e le estensioni non vengono nuovamente eseguite. Quando viene ricreata l'immagine di una macchina virtuale, viene attuato un processo simile alla sostituzione dell'unità del sistema operativo con l'immagine di origine. Vengono nuovamente eseguite eventuali specializzazioni dal modello più recente, ad esempio le estensioni.

Per aggiungere un set di scalabilità di macchine virtuali a un dominio di Active Directory (AD), è possibile definire un'estensione.

Per definire un'estensione, usare la proprietà 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')]"
                }
            }
        }
    ]
}

È possibile usare l'estensione Desired State Configuration di Automazione di Azure. Se il sistema operativo è Windows Server 2012 R2, Azure esegue il pull del programma di installazione di Windows Management Framework (WMF) 5.0, esegue il riavvio e quindi prosegue con la configurazione.

Configurare le impostazioni protette con la chiave e il nome dell'account di archiviazione. Per altre informazioni, vedere Estensione per script personalizzati.

È possibile:

• Modificare direttamente il modello del set di scalabilità delle macchine virtuali. Questa opzione è disponibile solo con l'API 2017-12-01 e versioni successive.

  Aggiornare le credenziali di amministratore direttamente nel modello del set di scalabilità (ad esempio tramite Azure Resource Explorer, PowerShell o l'interfaccia della riga di comando di Azure). Una volta aggiornato il set di scalabilità, tutte le nuove macchine virtuali dispongono delle nuove credenziali. Le VM esistenti avranno le nuove credenziali solo se ne viene ricreata l'immagine.

• Reimpostare la password usando le estensioni di accesso della macchina virtuale. Assicurarsi di seguire i requisiti delle password come descritto nelle domande frequenti.

  L'uso di un'estensione di accesso alla macchina virtuale non richiede la ricreazione dell'immagine, perché l'estensione non aggiorna la password nel modello. L'estensione esegue uno script per aggiungere la password al file delle password o della chiave SSH. L'estensione non rimuove la chiave SSH originale. Dopo aver aggiornato l'estensione, aggiornare le istanze per applicare gli aggiornamenti al nome utente e alla password in tutte le istanze della macchina virtuale.

  Nota

  Se i criteri di aggiornamento automatico sono impostati su manual, selezionare manualmente l'istanza per eseguire un'operazione di aggiornamento nelle singole istanze di macchina virtuale. Se l'aggiornamento automatico è impostato su Auto, l'estensione verrà aggiornata automaticamente. Per altre informazioni, vedere Aggiornamenti automatici delle estensioni

  Usare l'esempio di PowerShell seguente per un set di scalabilità di macchine virtuali 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
  

  Usare l'esempio seguente dell'interfaccia della riga di comando di Azure per un set di scalabilità di macchine virtuali 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'}"
  

Sì. È possibile applicare un gruppo di sicurezza di rete direttamente a un set di scalabilità facendo riferimento a esso nella sezione networkInterfaceConfigurations del profilo di rete. Ecco un esempio:

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

Se si hanno due set di scalabilità di macchine virtuali con Azure Load Balancer e si trovano nella stessa sottoscrizione e nella stessa area, è possibile deallocare gli indirizzi IP pubblici da ognuno e assegnarli all'altro. Per altre informazioni, vedere Scambio di indirizzi VIP: Distribuzione blu-verde in Azure Resource Manager. È tuttavia possibile che si verifichi un ritardo perché le risorse vengono deallocate o allocate a livello di rete. Un'opzione più rapida consiste nell'usare il Gateway applicazione di Azure con due pool di back-end e una regola di gestione. In alternativa, è possibile ospitare l'applicazione con servizio app di Azure, che supporta il passaggio rapido tra slot di staging e di produzione.

Gli indirizzi IP vengono selezionati da una subnet specificata.

Il metodo di allocazione degli indirizzi IP del set di scalabilità di macchine virtuali è sempre dinamico, ma ciò non significa che è possibile modificare questi indirizzi IP. In questo caso, dinamico significa solo che non si specifica l'indirizzo IP in una richiesta di PUT. Specificare il set statico usando la subnet.

Vedere Distribuire un set di scalabilità di macchine virtuali in una rete virtuale esistente.

Sì. Per usare la rete accelerata, impostare enableAcceleratedNetworking su true nelle impostazioni di networkInterfaceConfigurations del set di scalabilità. Ad esempio:

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

Per creare un set di scalabilità di macchine virtuali con una configurazione DNS personalizzata, aggiungere un pacchetto JSON dnsSettings alla sezione networkInterfaceConfigurations del set di scalabilità. Ecco un esempio:

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

Per creare un set di scalabilità di macchine virtuali che assegni un indirizzo IP pubblico a ogni macchina virtuale, verificare che la versione API della risorsa Microsoft.Compute/virtualMachineScaleSets sia 2017-03-30 e aggiungere un pacchetto JSON publicipaddressconfiguration alla sezione ipConfigurations del set di scalabilità. Ecco un esempio:

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

Sì. È possibile aggiungere gli ID risorsa per più pool di indirizzi back-end del gateway applicazione all'elenco applicationGatewayBackendAddressPools nella sezione ipConfigurations del profilo di rete del set di scalabilità.

Un motivo per la creazione di un set di scalabilità di macchine virtuali con meno di due macchine virtuali può essere relativo all'uso delle proprietà elastiche di un set di scalabilità di macchine virtuali. È ad esempio possibile distribuire un set di scalabilità di macchine virtuali con zero macchine virtuali per definire l'infrastruttura senza sostenere i costi operativi delle macchine virtuali. Quando si è pronti per distribuire le macchine virtuali, è quindi possibile aumentare la capacità del set di scalabilità di macchine virtuali al numero di istanze di produzione.

È possibile creare un set di scalabilità di macchine virtuali con meno di due macchine virtuali anche se si è interessati principalmente all'uso di un set di disponibilità con macchine virtuali discrete, invece che alla disponibilità. I set di scalabilità di macchine virtuali consentono di usare unità di calcolo non differenziate e fungibili. Questa uniformità è un elemento di differenziazione chiave tra set di scalabilità di macchine virtuali e set di disponibilità. Molti carichi di lavoro senza stato non tengono traccia delle singole unità. In caso di riduzione del carico di lavoro, è possibile passare a una sola unità di calcolo e quindi aumentare il numero di unità con l'aumento del carico di lavoro.

Per modificare il numero di macchine virtuali in un set di scalabilità di macchine virtuali nel portale di Azure, nella sezione Set di scalabilità di macchine virtuali Proprietà selezionare il riquadro Ridimensionamento e usare la barra del dispositivo di scorrimento.

La gestione degli avvisi per le soglie specificate offre una certa flessibilità. È ad esempio possibile definire webhook personalizzati. L'esempio di webhook seguente è tratto da un modello di Resource Manager:

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

Si, puoi.

Sì, è possibile spostare le risorse di un set di scalabilità in una nuova sottoscrizione o in un nuovo gruppo di risorse.

Per aggiornare il set di scalabilità di macchine virtuali a una nuova immagine e gestire l'applicazione di patch, vedere Aggiornare un set di scalabilità di macchine virtuali.

Sì, è possibile usare l'operazione di ricreazione dell'immagine per ripristinare una macchina virtuale senza modificare l'immagine. Se tuttavia il set di scalabilità di macchine virtuali fa riferimento a un'immagine di piattaforma con version = latest, la macchina virtuale può essere aggiornata a un'immagine del sistema operativo successiva quando si chiama reimage.

Sì, è possibile installando l'estensione Monitoraggio di Azure nelle macchine virtuali dei set di scalabilità. Di seguito è riportato un esempio che usa l'interfaccia della riga di comando di Azure:

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

È possibile trovare workspaceId e workspaceKey necessari nell'area di lavoro Log Analytics del portale di Azure. Nella pagina Panoramica selezionare il riquadro Impostazioni. Selezionare la scheda Origini connesse nella parte superiore.

Per attivare la diagnostica di avvio, creare prima di tutto un account di archiviazione. Inserire quindi questo blocco JSON nel set di scalabilità di macchine virtuali virtualMachineProfile e aggiornare il set di scalabilità di macchine virtuali:

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

Quando viene creata una nuova macchina virtuale, la proprietà InstanceView della macchina virtuale mostra i dettagli per lo screenshot. Ecco un esempio:

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

Visitare la pagina Risoluzione dei problemi comuni relativi ai set di scalabilità di macchine virtuali.

È possibile chiamare ListVMInstanceViews eseguendo un'API REST GET nell'URI della risorsa seguente:

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

Si noti che il dominio di errore non viene restituito quando il set di scalabilità usa la distribuzione massima (platformFaultDomainCount = 1), perché non esiste alcuna garanzia sul numero di domini di errore che verrebbero usati con questa impostazione.

No, non è possibile. Le estensioni possono tuttavia funzionare in base alle proprietà univoche della macchina virtuale sulla quale sono in esecuzione, ad esempio il nome della macchina. Le estensioni possono anche eseguire query sui metadati delle istanze in http://169.254.169.254 per ottenere altre informazioni sulla VM.

Le lacune sono dovuto al fatto che la proprietà overprovision del set di scalabilità di macchine virtuali è impostata sul valore predefinito true. Se il provisioning eccessivo è impostato su true, vengono create più macchine virtuali di quelle richieste. Le VM aggiuntive vengono quindi eliminate. In questo caso si ottiene una maggiore affidabilità per la distribuzione, a scapito tuttavia delle regole di contiguità di denominazione e di NAT (Network Address Translation).

È possibile impostare questa proprietà su false. Per i set di scalabilità di macchine virtuali di piccole dimensioni, l'affidabilità della distribuzione non sarà significativamente influenzata.

La differenza principale è che deallocate non elimina i dischi rigidi virtuali (VHD). L'esecuzione di stop deallocate comporta costi di archiviazione. È possibile usare una delle due opzioni per i motivi seguenti:

• Non si vogliono più sostenere i costi dei servizi di calcolo, mantenendo tuttavia lo stato dei dischi delle VM.
• Si vuole avviare un set di macchine virtuali con una velocità maggiore rispetto all'aumento del numero di istanze di un set di scalabilità di macchine virtuali.
  • In relazione a questo scenario è stato creato un motore di ridimensionamento automatico proprio e si vuole ottenere una scalabilità end-to-end più rapida.
• È presente un set di scalabilità di macchine virtuali distribuito in modo non uniforme nei domini di errore o nei domini di aggiornamento. Questa distribuzione non uniforme potrebbe essere dovuta all'eliminazione selettiva di macchine virtuali o all'eliminazione selettiva delle macchine virtuali dopo l'overprovisioning. L'esecuzione di stop deallocate seguito da start nel set di scalabilità di macchine virtuali consente di distribuire uniformemente le macchine virtuali nei domini di errore o nei domini di aggiornamento.

Creare uno snapshot dall'istanza di un set di scalabilità di macchine virtuali. Ecco un esempio:

$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

Creare un disco gestito da uno snapshot. Ecco un esempio:

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