Affidabilità in Macchine virtuali

  • Articolo

Questo articolo contiene raccomandazioni specifiche sull'affidabilità per Macchine virtuali, nonché informazioni dettagliate sulla resilienza a livello di area della macchina virtuale con zone di disponibilità e ripristino di emergenza tra aree e continuità aziendale.

Per una panoramica dell'architettura dell'affidabilità in Azure, vedere Affidabilità di Azure.

Raccomandazioni relative all'affidabilità

Questa sezione contiene raccomandazioni per ottenere resilienza e disponibilità. Ogni raccomandazione rientra in una delle due categorie seguenti:

  • Gli elementi di integrità riguardano aree come gli elementi di configurazione e la corretta funzione dei componenti principali che costituiscono il carico di lavoro di Azure, ad esempio le impostazioni di configurazione delle risorse di Azure, le dipendenze da altri servizi e così via.

  • Gli elementi di rischio riguardano aree quali requisiti di disponibilità e ripristino, test, monitoraggio, distribuzione e altri elementi che, se lasciati non risolti, aumentano le probabilità di problemi nell'ambiente.

Matrice di priorità delle raccomandazioni per l'affidabilità

Ogni raccomandazione è contrassegnata in base alla matrice di priorità seguente:

Image Priorità Descrizione
Fortemente Correzione immediata necessaria.
Medio Correzione entro 3-6 mesi.
Bassa Deve essere esaminato.

Riepilogo delle raccomandazioni per l'affidabilità

Category Priorità Elemento consigliato
Disponibilità elevata Eseguire carichi di lavoro di produzione in due o più macchine virtuali usando Azure set di scalabilità di macchine virtuali Flex
Distribuire macchine virtuali tra zone di disponibilità o usare set di scalabilità di macchine virtuali Flex con zone
Eseguire la migrazione di macchine virtuali usando set di disponibilità a set di scalabilità di macchine virtuali Flex
Usare dischi gestiti per i dischi delle macchine virtuali
Ripristino di emergenza Replicare macchine virtuali con Azure Site Recovery
Eseguire il backup dei dati nelle macchine virtuali con Backup di Azure servizio
Prestazioni Ospitare i dati dell'applicazione e del database in un disco dati
Le macchine virtuali di produzione devono usare dischi SSD
Abilitare la rete accelerata (AccelNet)
Quando AccelNet è abilitato, è necessario aggiornare manualmente l'unità NIC GuestOS
Gestione VM-9: Controllare la disponibilità di macchine virtuali nello stato Arrestato
Usare le configurazioni di manutenzione per la macchina virtuale
Sicurezza I VVMs non devono avere un indirizzo IP pubblico associato direttamente
le interfacce Rete virtuale hanno un gruppo di sicurezza di rete associato
L'inoltro IP deve essere abilitato solo per le appliance virtuali di rete
L'accesso di rete al disco della macchina virtuale deve essere impostato su "Disabilitare l'accesso pubblico e abilitare l'accesso privato"
Abilitare la crittografia dei dischi e i dati inattivi per impostazione predefinita
Networking I server DNS del cliente devono essere configurati a livello di Rete virtuale
Storage I dischi condivisi devono essere abilitati solo nei server in cluster
Conformità Assicurarsi che le macchine virtuali siano conformi ai criteri di Azure
Monitoraggio Abilitare Informazioni dettagliate macchina virtuale
Configurare le impostazioni di diagnostica per tutte le risorse di Azure

Disponibilità elevata

Eseguire carichi di lavoro di produzione in due o più macchine virtuali usando set di scalabilità di macchine virtuali Flex

Per proteggere i carichi di lavoro dell'applicazione dal tempo di inattività a causa dell'indisponibilità temporanea di un disco o di una macchina virtuale, è consigliabile eseguire carichi di lavoro di produzione in due o più macchine virtuali usando set di scalabilità di macchine virtuali Flex.

Per eseguire carichi di lavoro di produzione, è possibile usare:

  • Azure set di scalabilità di macchine virtuali creare e gestire un gruppo di macchine virtuali con carico bilanciato. Il numero di istanze di macchine virtuali può aumentare o diminuire automaticamente in risposta alla domanda o a una pianificazione definita.

  • Zone di disponibilità. Per altre informazioni sulle zone di disponibilità e sulle macchine virtuali, vedere Supporto della zona di disponibilità.

// Azure Resource Graph Query
// Find all VMs that are not associated with a VMSS Flex instance
resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where isnull(properties.virtualMachineScaleSet.id)
| project recommendationId="vm-1", name, id, tags

Distribuire macchine virtuali tra zone di disponibilità o usare set di scalabilità di macchine virtuali Flex con zone*

Quando si creano le macchine virtuali, usare le zone di disponibilità per proteggere le applicazioni e i dati da un probabile errore del data center. Per altre informazioni sulle zone di disponibilità per le macchine virtuali, vedere Supporto della zona di disponibilità in questo documento.

Per informazioni su come abilitare il supporto delle zone di disponibilità quando si crea la macchina virtuale, vedere Creare il supporto per la zona di disponibilità.

Per informazioni su come eseguire la migrazione delle macchine virtuali esistenti al supporto della zona di disponibilità, vedere Eseguire la migrazione al supporto della zona di disponibilità.

// Azure Resource Graph Query
// Find all VMs that are not assigned to a Zone
Resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where isnull(zones)
| project recommendationId="vm-2", name, id, tags, param1="No Zone"

Eseguire la migrazione di macchine virtuali usando set di disponibilità a set di scalabilità di macchine virtuali Flex

Modernizzare i carichi di lavoro eseguendo la migrazione da macchine virtuali a set di scalabilità di macchine virtuali Flex.

Con set di scalabilità di macchine virtuali Flex, è possibile distribuire le macchine virtuali in uno dei due modi seguenti:

  • Tra zone
  • Nella stessa zona, ma tra domini di errore (FD) e domini di aggiornamento (UD) automaticamente.

In un'applicazione a più livelli è consigliabile inserire ogni livello applicazione nel proprio set di scalabilità di macchine virtuali Flex.

// Azure Resource Graph Query
// Find all VMs using Availability Sets
resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where isnotnull(properties.availabilitySet)
| project recommendationId = "vm-3", name, id, tags, param1=strcat("availabilitySet: ",properties.availabilitySet.id)

Usare dischi gestiti per i dischi delle macchine virtuali*

Per garantire un'affidabilità migliore per le macchine virtuali in un set di disponibilità, usare i dischi gestiti. I dischi gestiti sono sufficientemente isolati l'uno dall'altro per evitare singoli punti di errore. Inoltre, i dischi gestiti non sono soggetti ai limiti di operazioni di I/O al secondo dei dischi rigidi virtuali creati in un account di archiviazione.

// Azure Resource Graph Query
// Find all VMs that are not using Managed Disks
Resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where isnull(properties.storageProfile.osDisk.managedDisk)
| project recommendationId = "vm-5", name, id, tags

Ripristino di emergenza

Replicare macchine virtuali con Azure Site Recovery

Quando si esegue la replica di macchine virtuali di Azure usando Site Recovery, tutti i dischi delle macchine virtuali vengono replicati in modo continuo nell'area di destinazione in modo asincrono. I punti di ripristino vengono creati ogni pochi minuti, che offre un obiettivo del punto di ripristino (RPO) nell'ordine di minuti. È possibile condurre esercitazioni sul ripristino di emergenza quante volte si vuole, senza alcun effetto sull'applicazione di produzione o sulla replica in corso.

Per informazioni su come eseguire un'esercitazione sul ripristino di emergenza, vedere Eseguire un failover di test.

// Azure Resource Graph Query
// Find all VMs that do NOT have replication with ASR enabled
// Run query to see results.
resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| project name, id, tags
| join kind=leftouter (
    recoveryservicesresources
    | where type =~ 'Microsoft.RecoveryServices/vaults/replicationFabrics/replicationProtectionContainers/replicationProtectedItems'
    | where properties.providerSpecificDetails.dataSourceInfo.datasourceType =~ 'AzureVm'
    | project id=properties.providerSpecificDetails.dataSourceInfo.resourceId
    | extend name=strcat_array(array_slice(split(id, '/'), 8, -1), '/')
) on name
| where isnull(id1)
| project-away id1
| project-away name1
| project recommendationId = "vm-4", name, id, tags
| order by id asc

Eseguire il backup dei dati nelle macchine virtuali con Backup di Azure servizio

Il servizio Backup di Azure offre soluzioni semplici, sicure ed economicamente convenienti per eseguire il backup dei dati e ripristinarli dal cloud di Microsoft Azure. Per altre informazioni, vedere Informazioni sul servizio Backup di Azure.

// Azure Resource Graph Query
// Find all VMs that do NOT have Backup enabled
// Run query to see results.
resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| project name, id, tags
| join kind=leftouter (
    recoveryservicesresources
    | where type =~ 'Microsoft.RecoveryServices/vaults/backupFabrics/protectionContainers/protectedItems'
    | where properties.dataSourceInfo.datasourceType =~ 'Microsoft.Compute/virtualMachines'
    | project idBackupEnabled=properties.sourceResourceId
    | extend name=strcat_array(array_slice(split(idBackupEnabled, '/'), 8, -1), '/')
) on name
| where isnull(idBackupEnabled)
| project-away idBackupEnabled
| project-away name1
| project recommendationId = "vm-7", name, id, tags
| order by id asc

Prestazioni

Ospitare i dati dell'applicazione e del database in un disco dati

Un disco dati è un disco gestito collegato a una macchina virtuale. Usare il disco dati per archiviare i dati dell'applicazione o altri dati da conservare. I dischi dati vengono registrati come unità SCSI ed etichettati con una lettera di propria scelta. L'hosting dei dati in un disco dati semplifica il backup o il ripristino dei dati. È anche possibile eseguire la migrazione del disco senza dover spostare l'intera macchina virtuale e l'intero sistema operativo. È anche possibile selezionare uno SKU di disco diverso, con tipi, dimensioni e prestazioni diversi che soddisfano i requisiti. Per altre informazioni sui dischi dati, vedere Dischi dati.

// Azure Resource Graph Query
// Find all VMs that only have OS Disk
Resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where array_length(properties.storageProfile.dataDisks) < 1
| project recommendationId = "vm-6", name, id, tags

Le macchine virtuali di produzione devono usare dischi SSD

I dischi SSD Premium offrono supporto su disco a bassa latenza e prestazioni elevate per applicazioni a elevato utilizzo di I/O e carichi di lavoro di produzione. I dischi SSD Standard sono un'opzione di archiviazione conveniente ottimizzata per i carichi di lavoro che richiedono prestazioni coerenti a livelli di I/O al secondo inferiori.

È consigliabile:

  • Usare dischi HDD Standard per scenari di sviluppo/test e carichi di lavoro meno critici al costo più basso.
  • Usare dischi SSD Premium anziché dischi HDD Standard con le macchine virtuali con supporto Premium. Per qualsiasi macchina virtuale a istanza singola che usa l'archiviazione Premium per tutti i dischi del sistema operativo e i dischi dati, Azure garantisce la connettività delle macchine virtuali di almeno il 99,9%.

Se si vuole eseguire l'aggiornamento da HDD Standard a dischi SSD Premium, considerare i problemi seguenti:

  • L'aggiornamento richiede un riavvio della macchina virtuale e il completamento di questo processo richiede 3-5 minuti.
  • Se le macchine virtuali sono macchine virtuali di produzione cruciali, valutare la disponibilità migliorata rispetto al costo dei dischi Premium.

Per altre informazioni sui tipi di dischi e dischi gestiti di Azure, vedere Tipi di dischi gestiti di Azure.

// Azure Resource Graph Query
// Find all disks with StandardHDD sku attached to VMs
Resources
| where type =~ 'Microsoft.Compute/disks'
| where sku.name == 'Standard_LRS' and sku.tier == 'Standard'
| where managedBy != ""
| project recommendationId = "vm-8", name, id, tags, param1=strcat("managedBy: ", managedBy)

Abilitare la rete accelerata (AccelNet)

AccelNet abilita la virtualizzazione di I/O radice singola (SR-IOV) a una macchina virtuale, migliorando notevolmente le prestazioni di rete. Questo percorso a prestazioni elevate esclude l'host dal percorso dati, riducendo così la latenza, l'instabilità e l'utilizzo della CPU e può essere usato con i carichi di lavoro di rete più impegnativi nei tipi di macchina virtuale supportati.

Per altre informazioni sulla rete accelerata, vedere Rete accelerata

// Azure Resource Graph Query
// Find all VM NICs that do not have Accelerated Networking enabled
resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| mv-expand nic = properties.networkProfile.networkInterfaces
| project name, id, tags, lowerCaseNicId = tolower(nic.id), vmSize = tostring(properties.hardwareProfile.vmSize)
| join kind = inner (
    resources
    | where type =~ 'Microsoft.Network/networkInterfaces'
    | where properties.enableAcceleratedNetworking == false
    | project nicName = split(id, "/")[8], lowerCaseNicId = tolower(id)
    )
    on lowerCaseNicId
| summarize nicNames = make_set(nicName) by name, id, tostring(tags), vmSize
| extend param1 = strcat("NicName: ", strcat_array(nicNames, ", ")), param2 = strcat("VMSize: ", vmSize)
| project recommendationId = "vm-10", name, id, tags, param1, param2
| order by id asc

Quando AccelNet è abilitato, è necessario aggiornare manualmente il driver della scheda di interfaccia di rete GuestOS

Quando AccelNet è abilitato, l'interfaccia predefinita di Azure Rete virtuale in GuestOS viene sostituita per un'interfaccia Mellanox. Di conseguenza, il driver della scheda di interfaccia di rete GuestOS viene fornito da Mellanox, un fornitore di terze parti. Anche se le immagini del Marketplace gestite da Microsoft vengono offerte con la versione più recente dei driver Mellanox, una volta distribuita la macchina virtuale, è necessario aggiornare manualmente il driver della scheda di interfaccia di rete GuestOS ogni sei mesi.

// cannot-be-validated-with-arg

Gestione

Esaminare le macchine virtuali in stato arrestato

Le istanze di macchine virtuali passano attraverso stati diversi, tra cui provisioning e stati di alimentazione. Se una macchina virtuale si trova in uno stato arrestato, la macchina virtuale potrebbe riscontrare un problema o non è più necessaria e potrebbe essere rimossa per ridurre i costi.

// Azure Resource Graph Query
// Find all VMs that are NOT running
Resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where properties.extended.instanceView.powerState.displayStatus != 'VM running'
| project recommendationId = "vm-9", name, id, tags

Usare le configurazioni di manutenzione per la macchina virtuale

Per assicurarsi che gli aggiornamenti o le interruzioni della macchina virtuale vengano eseguiti in un intervallo di tempo pianificato, usare le impostazioni di configurazione della manutenzione per pianificare e gestire gli aggiornamenti. Per altre informazioni sulla gestione degli aggiornamenti delle macchine virtuali con configurazioni di manutenzione, vedere Gestione degli aggiornamenti delle macchine virtuali con configurazioni di manutenzione.

// Azure Resource Graph Query
// Find VMS that do not have maintenance configuration assigned
Resources
| extend resourceId = tolower(id)
| project name, location, type, id, tags, resourceId, properties
| where type =~ 'Microsoft.Compute/virtualMachines'
| join kind=leftouter (
maintenanceresources
| where type =~ "microsoft.maintenance/configurationassignments"
| project planName = name, type, maintenanceProps = properties
| extend resourceId = tostring(maintenanceProps.resourceId)
) on resourceId
| where isnull(maintenanceProps)
| project recommendationId = "vm-22",name, id, tags
| order by id asc

Sicurezza

Le macchine virtuali non devono avere un indirizzo IP pubblico associato direttamente

Se una macchina virtuale richiede la connettività Internet in uscita, è consigliabile usare il gateway NAT o Firewall di Azure. Il gateway NAT o le Firewall di Azure consentono di aumentare la sicurezza e la resilienza del servizio, poiché entrambi i servizi hanno una disponibilità più elevata e porte SNAT (Source Network Address Translation). Per la connettività Internet in ingresso, è consigliabile usare una soluzione di bilanciamento del carico, ad esempio Azure Load Balancer e gateway applicazione.

// Azure Resource Graph Query
// Find all VMs with PublicIPs directly associated with them
Resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where isnotnull(properties.networkProfile.networkInterfaces)
| mv-expand nic=properties.networkProfile.networkInterfaces
| project name, id, tags, nicId = nic.id
| extend nicId = tostring(nicId)
| join kind=inner (
    Resources
    | where type =~ 'Microsoft.Network/networkInterfaces'
    | where isnotnull(properties.ipConfigurations)
    | mv-expand ipconfig=properties.ipConfigurations
    | extend publicIp = tostring(ipconfig.properties.publicIPAddress.id)
    | where publicIp != ""
    | project name, nicId = tostring(id), publicIp
) on nicId
| project recommendationId = "vm-12", name, id, tags
| order by id asc

Le interfacce di rete vm hanno un gruppo di sicurezza di rete (NSG) associato*

È consigliabile associare un gruppo di sicurezza di rete a una subnet o a un'interfaccia di rete, ma non entrambi. Poiché le regole in un gruppo di sicurezza di rete associato a una subnet possono essere in conflitto con le regole in un gruppo di sicurezza di rete associato a un'interfaccia di rete, è possibile avere problemi di comunicazione imprevisti che richiedono la risoluzione dei problemi. Per altre informazioni, vedere Traffico all'interno della subnet.

// Azure Resource Graph Query
// Provides a list of virtual machines and associated NICs that do have an NSG associated to them and also an NSG associated to the subnet.
Resources
| where type =~ 'Microsoft.Network/networkInterfaces'
| where isnotnull(properties.networkSecurityGroup)
| mv-expand ipConfigurations = properties.ipConfigurations, nsg = properties.networkSecurityGroup
| project nicId = tostring(id), subnetId = tostring(ipConfigurations.properties.subnet.id), nsgName=split(nsg.id, '/')[8]
| parse kind=regex subnetId with '/virtualNetworks/' virtualNetwork '/subnets/' subnet
    | join kind=inner (
        Resources
        | where type =~ 'Microsoft.Network/NetworkSecurityGroups' and isnotnull(properties.subnets)
        | project name, resourceGroup, subnet=properties.subnets
        | mv-expand subnet
        | project subnetId=tostring(subnet.id)
    ) on subnetId
    | project nicId
| join kind=leftouter (
    Resources
    | where type =~ 'Microsoft.Compute/virtualMachines'
    | where isnotnull(properties.networkProfile.networkInterfaces)
    | mv-expand nic=properties.networkProfile.networkInterfaces
    | project vmName = name, vmId = id, tags, nicId = nic.id, nicName=split(nic.id, '/')[8]
    | extend nicId = tostring(nicId)
) on nicId
| project recommendationId = "vm-13", name=vmName, id = vmId, tags, param1 = strcat("nic-name=", nicName)

L'inoltro IP deve essere abilitato solo per le appliance virtuali di rete

L'inoltro IP consente all'interfaccia di rete della macchina virtuale di:

  • Ricevere il traffico di rete non destinato a uno degli indirizzi IP assegnati a una delle configurazioni IP associate all'interfaccia di rete.

  • Inviare il traffico di rete con un indirizzo IP di origine diverso da quello assegnato a una delle configurazioni IP di un'interfaccia di rete.

L'impostazione di inoltro IP deve essere abilitata per ogni interfaccia di rete collegata alla macchina virtuale che riceve il traffico da inoltrare. Una macchina virtuale può inoltrare il traffico indipendentemente dal fatto che disponga di più interfacce di rete o di una singola interfaccia di rete collegata. Mentre l'inoltro IP è un'impostazione di Azure, la macchina virtuale deve anche eseguire un'applicazione in grado di inoltrare il traffico, ad esempio firewall, ottimizzazione WAN e applicazioni di bilanciamento del carico.

Per informazioni su come abilitare o disabilitare l'inoltro IP, vedere Abilitare o disabilitare l'inoltro IP.

// Azure Resource Graph Query
// Find all VM NICs that have IPForwarding enabled. This feature is usually only required for Network Virtual Appliances
Resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where isnotnull(properties.networkProfile.networkInterfaces)
| mv-expand nic=properties.networkProfile.networkInterfaces
| project name, id, tags, nicId = nic.id
| extend nicId = tostring(nicId)
| join kind=inner (
    Resources
    | where type =~ 'Microsoft.Network/networkInterfaces'
    | where properties.enableIPForwarding == true
    | project nicId = tostring(id)
) on nicId
| project recommendationId = "vm-14", name, id, tags
| order by id asc

L'accesso di rete al disco della macchina virtuale deve essere impostato su "Disabilitare l'accesso pubblico e abilitare l'accesso privato"

È consigliabile impostare l'accesso alla rete del disco della macchina virtuale su "Disabilitare l'accesso pubblico e abilitare l'accesso privato" e creare un endpoint privato. Per informazioni su come creare un endpoint privato, vedere Creare un endpoint privato.

// Azure Resource Graph Query
// Find all Disks with "Enable public access from all networks" enabled
resources
| where type =~ 'Microsoft.Compute/disks'
| where properties.publicNetworkAccess == "Enabled"
| project id, name, tags, lowerCaseDiskId = tolower(id)
| join kind = leftouter (
    resources
    | where type =~ 'Microsoft.Compute/virtualMachines'
    | project osDiskVmName = name, lowerCaseOsDiskId = tolower(properties.storageProfile.osDisk.managedDisk.id)
    | join kind = fullouter (
        resources
        | where type =~ 'Microsoft.Compute/virtualMachines'
        | mv-expand dataDisks = properties.storageProfile.dataDisks
        | project dataDiskVmName = name, lowerCaseDataDiskId = tolower(dataDisks.managedDisk.id)
        )
        on $left.lowerCaseOsDiskId == $right.lowerCaseDataDiskId
    | project lowerCaseDiskId = coalesce(lowerCaseOsDiskId, lowerCaseDataDiskId), vmName = coalesce(osDiskVmName, dataDiskVmName)
    )
    on lowerCaseDiskId
| summarize vmNames = make_set(vmName) by name, id, tostring(tags)
| extend param1 = iif(isempty(vmNames[0]), "VMName: n/a", strcat("VMName: ", strcat_array(vmNames, ", ")))
| project recommendationId = "vm-17", name, id, tags, param1
| order by id asc

Abilitare la crittografia dei dischi e i dati inattivi per impostazione predefinita

Sono disponibili diversi tipi di crittografia per i dischi gestiti, tra cui Crittografia dischi di Azure, crittografia lato server e crittografia a livello di host.

  • Crittografia dischi di Azure consente di proteggere i dati per soddisfare gli obblighi di sicurezza e conformità dell'organizzazione.
  • Crittografia lato server Archiviazione disco di Azure (detta crittografia dei dati inattivi o crittografia Archiviazione di Azure) crittografa automaticamente i dati archiviati in dischi gestiti di Azure (sistema operativo e dischi dati) quando vengono mantenuti nei cluster di Archiviazione.
  • La crittografia nell'host garantisce che i dati archiviati nell'host della macchina virtuale che ospitano la macchina virtuale siano crittografati inattivi e i flussi crittografati nei cluster Archiviazione.
  • La crittografia dischi riservati associa le chiavi di crittografia del disco al TPM della macchina virtuale e rende il contenuto del disco protetto accessibile solo alla macchina virtuale.

Per altre informazioni sulle opzioni di crittografia dischi gestiti, vedere Panoramica delle opzioni di crittografia del disco gestito.

// under-development

Rete

I server DNS devono essere configurati a livello di Rete virtuale

Configurare il server DNS nel Rete virtuale per evitare l'incoerenza della risoluzione dei nomi nell'ambiente. Per altre informazioni sulla risoluzione dei nomi per le risorse nelle reti virtuali di Azure, vedere Risoluzione dei nomi per macchine virtuali e servizi cloud.

// Azure Resource Graph Query
// Find all VM NICs that have DNS Server settings configured in any of the NICs
Resources
| where type =~ 'Microsoft.Compute/virtualMachines'
| where isnotnull(properties.networkProfile.networkInterfaces)
| mv-expand nic=properties.networkProfile.networkInterfaces
| project name, id, tags, nicId = nic.id
| extend nicId = tostring(nicId)
| join kind=inner (
    Resources
    | where type =~ 'Microsoft.Network/networkInterfaces'
    | project name, id, dnsServers = properties.dnsSettings.dnsServers
    | extend hasDns = array_length(dnsServers) >= 1
    | where hasDns != 0
    | project name, nicId = tostring(id)
) on nicId
| project recommendationId = "vm-15", name, id, tags
| order by id asc

Storage

I dischi condivisi devono essere abilitati solo nei server in cluster

Dischi condivisi di Azure è una funzionalità dei dischi gestiti di Azure che consente di collegare un disco gestito a più macchine virtuali contemporaneamente. Quando si collega un disco gestito a più macchine virtuali, è possibile distribuire applicazioni cluster nuove o migrate esistenti in Azure. I dischi condivisi devono essere usati solo in tali situazioni in cui il disco viene assegnato a più membri di una macchina virtuale di un cluster.

Per altre informazioni su come abilitare i dischi condivisi per i dischi gestiti, vedere Abilitare il disco condiviso.

// Azure Resource Graph Query
// Find all Disks configured to be Shared. This is not an indication of an issue, but if a disk with this configuration is assigned to two or more VMs without a proper disk control mechanism (like a WSFC) it can lead to data loss
resources
| where type =~ 'Microsoft.Compute/disks'
| where isnotnull(properties.maxShares)
| project id, name, tags, lowerCaseDiskId = tolower(id), diskState = tostring(properties.diskState)
| join kind = leftouter (
    resources
    | where type =~ 'Microsoft.Compute/virtualMachines'
    | project osDiskVmName = name, lowerCaseOsDiskId = tolower(properties.storageProfile.osDisk.managedDisk.id)
    | join kind = fullouter (
        resources
        | where type =~ 'Microsoft.Compute/virtualMachines'
        | mv-expand dataDisks = properties.storageProfile.dataDisks
        | project dataDiskVmName = name, lowerCaseDataDiskId = tolower(dataDisks.managedDisk.id)
        )
        on $left.lowerCaseOsDiskId == $right.lowerCaseDataDiskId
    | project lowerCaseDiskId = coalesce(lowerCaseOsDiskId, lowerCaseDataDiskId), vmName = coalesce(osDiskVmName, dataDiskVmName)
    )
    on lowerCaseDiskId
| summarize vmNames = make_set(vmName) by name, id, tostring(tags), diskState
| extend param1 = strcat("DiskState: ", diskState), param2 = iif(isempty(vmNames[0]), "VMName: n/a", strcat("VMName: ", strcat_array(vmNames, ", ")))
| project recommendationId = "vm-16", name, id, tags, param1, param2
| order by id asc

Conformità

Assicurarsi che le macchine virtuali siano conformi ai criteri di Azure

È importante garantire la protezione delle macchine virtuali (VM) per le applicazioni che si intende eseguire. La protezione delle macchine virtuali può includere uno o più servizi o funzionalità di Azure che gestiscono l'accesso sicuro alle macchine virtuali e l'archiviazione sicura dei dati. Per altre informazioni su come proteggere le macchine virtuali e le applicazioni, vedere Criteri di Azure controlli di conformità alle normative per Azure Macchine virtuali.

// Azure Resource Graph Query
// Find all VMs in "NonCompliant" state with Azure Policies
PolicyResources
| where type =~ "Microsoft.PolicyInsights/policyStates" and properties.resourceType =~ "Microsoft.Compute/virtualMachines" and properties.complianceState =~ "NonCompliant"
| project
    policyAssignmentName = properties.policyAssignmentName,
    policyDefinitionName = properties.policyDefinitionName,
    lowerCasePolicyDefinitionIdOfPolicyState = tolower(properties.policyDefinitionId),
    lowerCaseVmIdOfPolicyState = tolower(properties.resourceId)
| join kind = leftouter (
    PolicyResources
    | where type =~ "Microsoft.Authorization/policyDefinitions"
    | project lowerCasePolicyDefinitionId = tolower(id), policyDefinitionDisplayName = properties.displayName
    )
    on $left.lowerCasePolicyDefinitionIdOfPolicyState == $right.lowerCasePolicyDefinitionId
| project policyAssignmentName, policyDefinitionName, policyDefinitionDisplayName, lowerCaseVmIdOfPolicyState
| join kind = leftouter (
    Resources
    | where type =~ "Microsoft.Compute/virtualMachines"
    | project vmName = name, vmId = id, vmTags = tags, lowerCaseVmId = tolower(id)
    )
    on $left.lowerCaseVmIdOfPolicyState == $right.lowerCaseVmId
| extend
    param1 = strcat("AssignmentName: ", policyAssignmentName),
    param2 = strcat("DefinitionName: ", policyDefinitionDisplayName),  // Align to Azure portal's term.
    param3 = strcat("DefinitionID: ", policyDefinitionName)            // Align to Azure portal's term.
| project recommendationId = "vm-18", name = vmName, id = vmId, tags = vmTags, param1, param2, param3

Monitoraggio

Abilitare Informazioni dettagliate macchina virtuale

Abilitare Informazioni dettagliate macchina virtuale per ottenere maggiore visibilità sull'integrità e sulle prestazioni della macchina virtuale. Vm Insights offre informazioni sulle prestazioni e sull'integrità delle macchine virtuali e dei set di scalabilità di macchine virtuali, monitorando i processi in esecuzione e le dipendenze da altre risorse. Informazioni dettagliate sulle macchine virtuali consente di offrire prestazioni prevedibili e disponibilità di applicazioni vitali identificando i colli di bottiglia delle prestazioni e i problemi di rete. Informazioni dettagliate consentono anche di comprendere se un problema è correlato ad altre dipendenze.

// Azure Resource Graph Query
// Check for VMs without Azure Monitoring Agent extension installed, missing Data Collection Rule or Data Collection Rule without performance enabled.
Resources
| where type == 'microsoft.compute/virtualmachines'
| project idVm = tolower(id), name, tags
| join kind=leftouter (
    InsightsResources
    | where type =~ "Microsoft.Insights/dataCollectionRuleAssociations" and id has "Microsoft.Compute/virtualMachines"
    | project idDcr = tolower(properties.dataCollectionRuleId), idVmDcr = tolower(substring(id, 0, indexof(id, "/providers/Microsoft.Insights/dataCollectionRuleAssociations/"))))
on $left.idVm == $right.idVmDcr
| join kind=leftouter (
    Resources
    | where type =~ "Microsoft.Insights/dataCollectionRules"
    | extend
        isPerformanceEnabled = iif(properties.dataSources.performanceCounters contains "Microsoft-InsightsMetrics" and properties.dataFlows contains "Microsoft-InsightsMetrics", true, false),
        isMapEnabled = iif(properties.dataSources.extensions contains "Microsoft-ServiceMap" and properties.dataSources.extensions contains "DependencyAgent" and properties.dataFlows contains "Microsoft-ServiceMap", true, false)//,
    | where isPerformanceEnabled or isMapEnabled
    | project dcrName = name, isPerformanceEnabled, isMapEnabled, idDcr = tolower(id))
on $left.idDcr == $right.idDcr
| join kind=leftouter (
    Resources
        | where type == 'microsoft.compute/virtualmachines/extensions' and (name contains 'AzureMonitorWindowsAgent' or name contains 'AzureMonitorLinuxAgent')
        | extend idVmExtension = tolower(substring(id, 0, indexof(id, '/extensions'))), extensionName = name)
on $left.idVm == $right.idVmExtension
| where isPerformanceEnabled != 1 or (extensionName != 'AzureMonitorWindowsAgent' and extensionName != 'AzureMonitorLinuxAgent')
| project recommendationId = "vm-20", name, id = idVm, tags, param1 = strcat('MonitoringExtension:', extensionName), param2 = strcat('DataCollectionRuleId:', idDcr), param3 = strcat('isPerformanceEnabled:', isPerformanceEnabled)

Configurare le impostazioni di diagnostica per tutte le risorse di Azure

Le metriche della piattaforma vengono inviate automaticamente alle metriche di Monitoraggio di Azure per impostazione predefinita, senza necessità di configurazione. I log della piattaforma forniscono informazioni dettagliate di diagnostica e controllo per le risorse di Azure e la piattaforma Azure da cui dipendono e sono uno dei tipi seguenti:

  • Log delle risorse che non vengono raccolti finché non vengono indirizzati a una destinazione.
  • I log attività esistenti autonomamente, ma possono essere instradati ad altre posizioni.

Ogni risorsa di Azure richiede una propria impostazione di diagnostica, che definisce i criteri seguenti:

  • Sources Tipo di dati di metrica e di log da inviare alle destinazioni definite nell'impostazione. I tipi disponibili variano in base al tipo di risorsa.
  • Destinazioni: una o più destinazioni a cui inviare.

Una singola impostazione di diagnostica può definire al massimo una destinazione di ogni tipo. Se si vogliono inviare i dati a più di un tipo di destinazione specifico (ad esempio, due aree di lavoro Log Analytics diverse), creare più impostazioni. Ogni risorsa può avere fino a cinque impostazioni di diagnostica.

Per informazioni, vedere Impostazioni di diagnostica in Monitoraggio di Azure.

// Azure Resource Graph Query
// Find all Virtual Machines without diagnostic settings enabled/with diagnostic settings enabled but not configured both performance counters and event logs/syslogs.
resources
| where type =~ "microsoft.compute/virtualmachines"
| project name, id, tags, lowerCaseVmId = tolower(id)
| join kind = leftouter (
    resources
    | where type =~ "Microsoft.Compute/virtualMachines/extensions" and properties.publisher =~ "Microsoft.Azure.Diagnostics"
    | project
        lowerCaseVmIdOfExtension = tolower(substring(id, 0, indexof(id, "/extensions/"))),
        extensionType = properties.type,
        provisioningState = properties.provisioningState,
        storageAccount = properties.settings.StorageAccount,
        // Windows
        wadPerfCounters = properties.settings.WadCfg.DiagnosticMonitorConfiguration.PerformanceCounters.PerformanceCounterConfiguration,
        wadEventLogs = properties.settings.WadCfg.DiagnosticMonitorConfiguration.WindowsEventLog,
        // Linux
        ladPerfCounters = properties.settings.ladCfg.diagnosticMonitorConfiguration.performanceCounters.performanceCounterConfiguration,
        ladSyslog = properties.settings.ladCfg.diagnosticMonitorConfiguration.syslogEvents
    | extend
        // Windows
        isWadPerfCountersConfigured = iif(array_length(wadPerfCounters) > 0, true, false),
        isWadEventLogsConfigured = iif(isnotnull(wadEventLogs) and array_length(wadEventLogs.DataSource) > 0, true, false),
        // Linux
        isLadPerfCountersConfigured = iif(array_length(ladPerfCounters) > 0, true, false),
        isLadSyslogConfigured = isnotnull(ladSyslog)
    | project
        lowerCaseVmIdOfExtension,
        extensionType,
        provisioningState,
        storageAccount,
        isPerfCountersConfigured = case(extensionType =~ "IaaSDiagnostics", isWadPerfCountersConfigured, extensionType =~ "LinuxDiagnostic", isLadPerfCountersConfigured, false),
        isEventLogsConfigured = case(extensionType =~ "IaaSDiagnostics", isWadEventLogsConfigured, extensionType =~ "LinuxDiagnostic", isLadSyslogConfigured, false)
    )
    on $left.lowerCaseVmId == $right.lowerCaseVmIdOfExtension
| where isempty(lowerCaseVmIdOfExtension) or provisioningState !~ "Succeeded" or not(isPerfCountersConfigured and isEventLogsConfigured)
| extend
    param1 = strcat("DiagnosticSetting: ", iif(isnotnull(extensionType), strcat("Enabled, partially configured (", extensionType, ")"), "Not enabled")),
    param2 = strcat("ProvisioningState: ", iif(isnotnull(provisioningState), provisioningState, "n/a")),
    param3 = strcat("storageAccount: ", iif(isnotnull(storageAccount), storageAccount, "n/a")),
    param4 = strcat("PerformanceCounters: ", case(isnull(isPerfCountersConfigured), "n/a", isPerfCountersConfigured, "Configured", "Not configured")),
    param5 = strcat("EventLogs/Syslogs: ", case(isnull(isEventLogsConfigured), "n/a", isEventLogsConfigured, "Configured", "Not configured"))
| project recommendationId = "vm-21", name, id, tags, param1, param2, param3, param4, param5

Supporto della zona di disponibilità

Le zone di disponibilità di Azure sono almeno tre gruppi di data center separati fisicamente all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di energia, raffreddamento e infrastruttura di rete indipendenti. In caso di errore della zona locale, le zone di disponibilità sono progettate in modo che se l'unica zona è interessata, i servizi regionali, la capacità e la disponibilità elevata sono supportati dalle due zone rimanenti.

Gli errori possono variare da errori software e hardware a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori si ottiene con ridondanza e isolamento logico dei servizi di Azure. Per informazioni più dettagliate sulle zone di disponibilità in Azure, vedere Aree e zone di disponibilità.

I servizi abilitati per le zone di disponibilità di Azure sono progettati per offrire il giusto livello di affidabilità e flessibilità. Possono essere configurati in due modi. Possono essere ridondanti della zona, con replica automatica tra zone o zone, con istanze aggiunte a una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sull'architettura zonale e con ridondanza della zona, vedere Consigli per l'uso di zone e aree di disponibilità.

Le macchine virtuali supportano le zone di disponibilità con tre zone di disponibilità per ogni area di Azure supportata e sono anche ridondanti della zona e di zona. Per altre informazioni, vedere Supporto delle zone di disponibilità. Il cliente è responsabile della configurazione e della migrazione delle macchine virtuali per la disponibilità.

Per altre informazioni sulle opzioni di idoneità della zona di disponibilità, vedere:

Prerequisiti

  • Gli SKU della macchina virtuale devono essere disponibili tra le zone in per l'area. Per esaminare le aree che supportano le zone di disponibilità, vedere l'elenco delle aree supportate.

  • Gli SKU delle macchine virtuali devono essere disponibili nelle zone dell'area. Per verificare la disponibilità dello SKU della macchina virtuale, usare uno dei metodi seguenti:

Miglioramenti del contratto di servizio

Poiché le zone di disponibilità sono fisicamente separate e forniscono una fonte di alimentazione, una rete e un raffreddamento distinti, aumentano i contratti di servizio (contratti di servizio). Per altre informazioni, vedere Contratto di Servizio per Macchine virtuali.

Creare una risorsa con zone di disponibilità abilitate

Per iniziare, creare una macchina virtuale con la zona di disponibilità abilitata dalle opzioni di distribuzione seguenti:

Supporto del failover a livello di zona

È possibile configurare le macchine virtuali per eseguire il failover in un'altra zona usando il servizio Site Recovery. Per altre informazioni, vedere Site Recovery.

Tolleranza di errore

Le macchine virtuali possono eseguire il failover in un altro server in un cluster, con il riavvio del sistema operativo della macchina virtuale nel nuovo server. È consigliabile fare riferimento al processo di failover per il ripristino di emergenza, la raccolta di macchine virtuali nella pianificazione del ripristino e l'esecuzione di esercitazioni sul ripristino di emergenza per assicurarsi che la soluzione di tolleranza di errore sia corretta.

Per altre informazioni, vedere i processi di site recovery.

Esperienza di riduzione della zona

Durante un'interruzione a livello di zona, è necessario prevedere una breve riduzione delle prestazioni fino a quando il servizio macchina virtuale non ribilancia la capacità sottostante per adattarsi alle zone integre. La riparazione automatica non dipende dal ripristino della zona; è previsto che lo stato di riparazione automatica del servizio gestito da Microsoft compensa una zona persa, usando la capacità di altre zone.

È anche consigliabile prepararsi per la possibilità che si verifichi un'interruzione di un'intera area. Se si verifica un'interruzione del servizio per un'intera area, le copie con ridondanza locale dei dati non saranno temporaneamente disponibili. Se la replica geografica è abilitata, altre tre copie dei BLOB e delle tabelle di Archiviazione di Azure vengono archiviate in un'area diversa. Quando si verifica un'interruzione completa a livello di area o un'emergenza in cui l'area primaria non è recuperabile, Azure esegue di nuovo il mapping di tutte le voci DNS all'area con replica geografica.

Preparazione e ripristino dell'interruzione della zona

Le indicazioni seguenti vengono fornite per le macchine virtuali di Azure durante un'interruzione del servizio dell'intera area in cui viene distribuita l'applicazione macchina virtuale di Azure:

Progettazione a bassa latenza

Per la progettazione di una soluzione di macchina virtuale a bassa latenza, sono disponibili opzioni tra aree (area secondaria), sottoscrizione incrociata (anteprima) e tra zone (anteprima). Per altre informazioni su queste opzioni, vedere i metodi di ripristino supportati.

Importante

Rifiutando esplicitamente la distribuzione con riconoscimento della zona, si rinuncia alla protezione dall'isolamento degli errori sottostanti. Uso di SKU che non supportano le zone di disponibilità o che rifiutano esplicitamente le forze di configurazione della zona di disponibilità dipendono dalle risorse che non obbediscono al posizionamento e alla separazione della zona (incluse le dipendenze sottostanti di queste risorse). Queste risorse non dovrebbero essere previste per sopravvivere a scenari di zona inattiva. Le soluzioni che sfruttano tali risorse devono definire una strategia di ripristino di emergenza e configurare un ripristino della soluzione in un'altra area.

Cassaforte tecniche di distribuzione

Quando si sceglie l'isolamento delle zone di disponibilità, è consigliabile usare tecniche di distribuzione sicure per gli aggiornamenti del codice dell'applicazione e delle applicazioni. Oltre a configurare Azure Site Recovery e implementare una delle seguenti tecniche di distribuzione sicura per le macchine virtuali:

Poiché Microsoft esegue periodicamente aggiornamenti di manutenzione pianificata, potrebbero esserci rare istanze quando questi aggiornamenti richiedono un riavvio della macchina virtuale per applicare gli aggiornamenti necessari all'infrastruttura sottostante. Per altre informazioni, vedere Considerazioni sulla disponibilità durante la manutenzione pianificata.

Prima di aggiornare il set successivo di nodi in un'altra zona, è necessario eseguire le attività seguenti:

  • Controllare il dashboard integrità dei servizi di Azure per individuare lo stato del servizio macchine virtuali per le aree previste.
  • Assicurarsi che la replica sia abilitata nelle macchine virtuali.

Eseguire la migrazione al supporto della zona di disponibilità

Per informazioni su come eseguire la migrazione di una macchina virtuale al supporto della zona di disponibilità, vedere Eseguire la migrazione di Macchine virtuali e set di scalabilità di macchine virtuali al supporto della zona di disponibilità.

Ripristino di emergenza tra aree e continuità aziendale

Il ripristino di emergenza riguarda il ripristino da eventi ad alto impatto, ad esempio calamità naturali o distribuzioni non riuscite che comportano tempi di inattività e perdita di dati. Indipendentemente dalla causa, il miglior rimedio per un'emergenza è un piano di ripristino ben definito e testato e una progettazione di applicazioni che supporta attivamente tale ripristino. Prima di iniziare a pensare alla creazione del piano di ripristino di emergenza, vedere Consigli per la progettazione di una strategia di ripristino di emergenza.

Per quanto riguarda il ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello di responsabilità condivisa, Microsoft garantisce che siano disponibili l'infrastruttura di base e i servizi della piattaforma. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o non eseguono il fallback da un'area non riuscita per eseguire la replica incrociata in un'altra area abilitata. Per questi servizi, l'utente è responsabile della configurazione di un piano di ripristino di emergenza che funziona per il carico di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Platform as a Service) di Azure offre funzionalità e linee guida per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido per lo sviluppo del piano di ripristino di emergenza.

È possibile usare il ripristino tra aree per ripristinare le macchine virtuali di Azure tramite aree abbinate. Con il ripristino tra aree è possibile ripristinare tutte le macchine virtuali di Azure per il punto di ripristino selezionato se il backup viene eseguito nell'area secondaria. Per altre informazioni sul ripristino tra aree, vedere la voce di riga della tabella tra aree nelle opzioni di ripristino.

Ripristino di emergenza nell'area geografica in più aree

In caso di interruzione del servizio a livello di area, Microsoft lavora diligentemente per ripristinare il servizio macchina virtuale. Tuttavia, è comunque necessario basarsi su altre strategie di backup specifiche dell'applicazione per ottenere il massimo livello di disponibilità. Per altre informazioni, vedere la sezione Strategie dei dati per il ripristino di emergenza.

Rilevamento, notifica e gestione di interruzioni

L'infrastruttura hardware o fisica per la macchina virtuale potrebbe non riuscire in modo imprevisto. Gli errori imprevisti possono includere errori di rete locali, errori del disco locale o altri errori a livello di rack. Quando viene rilevato, la piattaforma Azure esegue automaticamente la migrazione (guarita) della macchina virtuale a una macchina fisica integra nello stesso data center. Durante la procedura di riparazione, nelle macchine virtuali si verificano tempi di inattività (riavvio) e in alcuni casi la perdita dell'unità temporanea. Il sistema operativo e i dischi dati collegati vengono sempre conservati.

Per informazioni più dettagliate sulle interruzioni del servizio di macchine virtuali, vedere indicazioni sul ripristino di emergenza.

Configurare il ripristino di emergenza e il rilevamento di interruzioni

Quando si configura il ripristino di emergenza per le macchine virtuali, comprendere cosa offre Azure Site Recovery. Abilitare il ripristino di emergenza per le macchine virtuali con i metodi seguenti:

Ripristino di emergenza in area geografica singola

Con la configurazione del ripristino di emergenza, le macchine virtuali di Azure vengono replicate continuamente in un'area di destinazione diversa. In caso di guasto, è possibile effettuare il failover delle macchine virtuali nell'area secondaria e accedervi da lì.

Quando si esegue la replica di macchine virtuali di Azure usando Site Recovery, tutti i dischi delle macchine virtuali vengono replicati nell'area di destinazione in modo continuativo e asincrono. I punti di ripristino vengono creati ogni pochi minuti, che concede un obiettivo del punto di ripristino (RPO) nell'ordine di minuti. È possibile condurre esercitazioni sul ripristino di emergenza quante volte si vuole, senza alcun effetto sull'applicazione di produzione o sulla replica in corso. Per altre informazioni, vedere Eseguire un'esercitazione sul ripristino di emergenza in Azure.

Per altre informazioni, vedere Componenti dell'architettura delle macchine virtuali di Azure e associazione di aree.

Resilienza della capacità e del ripristino di emergenza proattivo

Microsoft e i suoi clienti operano con il modello di responsabilità condivisa. Responsabilità condivisa significa che per il ripristino di emergenza abilitato per il cliente (servizi responsabili del cliente), è necessario rivolgersi al ripristino di emergenza per qualsiasi servizio distribuito e controllato. Per garantire che il ripristino sia proattivo, è consigliabile eseguire sempre la pre-distribuzione dei database secondari perché non esiste alcuna garanzia di capacità al momento dell'impatto per coloro che non sono stati preallocati.

Per la distribuzione di macchine virtuali, è possibile usare la modalità di orchestrazione flessibile in set di scalabilità di macchine virtuali. Tutte le dimensioni delle macchine virtuali possono essere usate con la modalità di orchestrazione flessibile. La modalità di orchestrazione flessibile offre anche garanzie di disponibilità elevata (fino a 1000 macchine virtuali) distribuendo le macchine virtuali tra domini di errore all'interno di un'area o all'interno di una zona di disponibilità.

Passaggi successivi