Condividi tramite

Elenco di controllo per la resilienza per servizi di Azure specifici

La resilienza è la capacità di un sistema di correggere gli errori e continuare a funzionare. Ogni tecnologia ha modalità di errore specifiche che è necessario tenere in considerazione durante la progettazione e l'implementazione di un'applicazione. Usare questo elenco di controllo per esaminare le considerazioni relative alla resilienza per servizi di Azure specifici. Per altre informazioni su come progettare applicazioni resilienti, vedere Progettare applicazioni Azure affidabili.

Servizio app

Usare il livello Standard o Premium. Questi livelli supportano i slot di test e i backup automatici. Per altre informazioni, vedere Panoramica approfondita dei piani per Servizio app di Azure

Evitare il ridimensionamento verso l'alto o verso il basso. Selezionare invece un livello e una dimensione di istanza che soddisfino i requisiti di prestazioni in condizioni di carico tipico e quindi aumentare il numero delle istanze per gestire le modifiche nel volume del traffico. Il ridimensionamento verso l'alto o verso il basso può determinare il riavvio dell'applicazione.

Archiviare la configurazione come impostazioni dell'app. Usare le impostazioni dell'app per conservare le impostazioni di configurazione come impostazioni dell'app. Definire le impostazioni nei modelli di Resource Manager oppure tramite PowerShell, in modo da poterle applicare come parte di un processo di distribuzione/aggiornamento automatizzato, che è più affidabile. Per altre informazioni, vedere Configurazione delle app Web in Servizio app di Azure.

Creare piani di servizio app separati per la produzione e per il test. Non utilizzare gli slot nella tua distribuzione in produzione per effettuare i test. Tutte le app all'interno dello stesso piano di servizio app condividono le stesse istanze di macchina virtuale. L'inserimento delle distribuzioni di produzione e di test nello stesso piano può influire negativamente sulla distribuzione di produzione. I test di carico, ad esempio, possono ridurre le prestazioni del sito di produzione attivo. Se si inseriscono le distribuzioni di test in un piano separato, le si isola dalla versione di produzione.

Separare le app Web dalle API Web. Se la tua soluzione ha sia un front-end Web che un'API Web, considera di scomporli in app separate del Servizio App. Questa progettazione rende più semplice scomporre la soluzione in base al carico di lavoro. Si possono eseguire l'app Web e l'API Web in piani di servizio app separati in modo che le si possa scalare in maniera indipendente. Se inizialmente questo livello di scalabilità non è necessario, è possibile distribuire le app nello stesso piano e spostarle successivamente in piani separati, se necessario.

Distribuire piani Servizio App a ridondanza di zona. Nelle aree supportate, i piani di servizio App possono essere distribuiti come a ridondanza di zona, il che significa che le istanze vengono automaticamente distribuite tra le zone disponibili. Il servizio App Service distribuisce automaticamente il traffico tra le zone e gestisce il failover in caso di interruzione di una zona. Per altre informazioni, vedere Eseguire la migrazione di servizio app al supporto della zona di disponibilità.

Evitare di usare la funzionalità di backup del Servizio app per eseguire il backup dei database SQL di Azure. Usare invece i backup automatici del database SQL. Il backup del Servizio App esporta il database in un file BACPAC SQL, il cui costo è in DTU.

Distribuire in un ambiente di staging. Creare uno slot di distribuzione per la fase di sviluppo. Distribuire gli aggiornamenti dell'applicazione nell'ambiente di staging e verificare la distribuzione prima di passarla alla produzione. In questo modo, diminuiscono le probabilità che si esegua un aggiornamento non corretto nell'ambiente di produzione. Assicura inoltre che tutte le istanze siano riscaldate prima di essere passate nell'ambiente di produzione. Molte applicazioni presentano tempi di riscaldamento e di avvio a freddo piuttosto lunghi. Per altre informazioni, vedere Configurare ambienti di staging per le app Web nel Servizio app di Azure.

Creare uno slot di distribuzione per contenere l'ultimo stato valido noto della distribuzione. Quando si distribuisce un aggiornamento nell'ambiente di produzione, spostare la distribuzione precedente nella configurazione funzionante più recente. Questa operazione rende più semplice eseguire il rollback di una distribuzione non corretta. Se scopri un problema in seguito, puoi rapidamente ripristinare la versione LKG. Per altre informazioni, vedere Applicazione Web di base.

Abilitare la registrazione diagnostica, includendo la registrazione delle applicazioni e del server Web. La registrazione è importante per il monitoraggio e la diagnostica. Vedere Abilitare la registrazione diagnostica per le app Web nel servizio app di Azure.

Registrare nell'archivio BLOB. Questa operazione rende più semplice raccogliere e analizzare i dati.

Creare un account di archiviazione separato per i log. Non usare lo stesso account di archiviazione per i log e i dati dell'applicazione. In questo modo si impedisce che la registrazione riduca le prestazioni dell'applicazione.

Monitorare le prestazioni. Usare un servizio di monitoraggio delle prestazioni, ad esempio New Relic o Application Insights per monitorare le prestazioni dell'applicazione e il comportamento sotto carico. Il monitoraggio delle prestazioni offre informazioni approfondite in tempo reale sull'applicazione. Consente di diagnosticare i problemi ed eseguire l'analisi della causa radice degli errori.

Azure Load Balancer (bilanciatore di carico di Azure)

Selezionare SKU Standard. Il bilanciamento del carico Standard offre una dimensione di affidabilità che il bilanciamento Basic non ha: quella delle zone di disponibilità e della resilienza nelle zone. Ciò significa che quando una zona diventa inattiva, il Load Balancer Standard a zona ridondante non sarà interessato. Ciò garantisce che le implementazioni possano resistere ai guasti zonali all'interno di una regione. Inoltre, Load Balancer Standard supporta il bilanciamento globale del carico assicurando che l'applicazione non sia interessata dai guasti regionali.

Attivare almeno due istanze. Distribuire Azure Load Balancer con almeno due istanze nel back-end. Una singola istanza può causare un singolo punto di guasto. Per costruire per la scalabilità, è necessario associare un bilanciatore del carico con insiemi di scalabilità di macchine virtuali.

Usare le regole in uscita. Le regole in uscita assicurano che non si riscontrano errori di connessione a causa dell'esaurimento delle porte SNAT (Source Network Address Translation). Altre informazioni sulla connettività in uscita. Anche se le regole in uscita consentiranno di migliorare la soluzione per distribuzioni di piccole e medie dimensioni, per i carichi di lavoro di produzione, è consigliabile accoppiare il servizio di bilanciamento del carico Standard o qualsiasi distribuzione di subnet con NAT (VNet Network Address Translation).

Indirizzi IP pubblici di Azure

Selezionare SKU Standard. Gli indirizzi IP pubblici Standard forniscono zone di disponibilità e resilienza zonale rispetto agli indirizzi IP pubblici Basic. Se si utilizza un servizio che richiede un indirizzo IP pubblico, selezionare un indirizzo IP pubblico a ridondanza di zona. Per gli indirizzi IP esistenti, aggiornarli dalla versione Basic alla versione Standard per usufruire dei vantaggi della zona ridondante per impostazione predefinita.

Gateway applicativo

Attivare almeno due istanze. Distribuire il gateway applicativo con almeno due istanze. Un'istanza singola è un singolo punto di vulnerabilità. Usare due o più istanze per la ridondanza e la scalabilità. Per qualificarsi per il service-level agreement (SLA), è necessario approvvigionare due o più istanze medie o superiori.

Azure Cosmos DB

Configurare la ridondanza della zona. Quando si usa la ridondanza della zona, Azure Cosmos DB replica in modo sincrono tutte le scritture tra le zone di disponibilità. Esegue automaticamente il failover in caso di interruzione di zona. Per altre informazioni, vedere Raggiungere una disponibilità elevata con Azure Cosmos DB.

Replica il database in tutte le regioni. Azure Cosmos DB consente di associare un numero qualsiasi di aree di Azure a un account di database Azure Cosmos DB. Un database di Azure Cosmos DB può avere un'area di scrittura e più aree di lettura. Se si verifica un errore nell'area di scrittura, è possibile leggere da un'altra replica. Il client SDK gestisce questa situazione automaticamente. È anche possibile eseguire il failover dell'area di scrittura su un'altra area. Per altre informazioni, vedere Come distribuire i dati a livello globale con Azure Cosmos DB.

Hub eventi

Usare i checkpoint. Un consumatore di eventi deve scrivere la propria posizione corrente nell'archivio permanente a intervalli predefiniti. In tal modo, se il consumer subisce un malfunzionamento (ad esempio, in caso di arresto anomalo del consumer o guasto dell'host), una nuova istanza può riprendere la lettura del flusso di dati dall'ultima posizione registrata. Per altre informazioni, vedere Consumatori di eventi.

Gestire i messaggi duplicati. In caso di errore di un consumatore di eventi, l'elaborazione dei messaggi riprende dall'ultimo checkpoint registrato. I messaggi che sono già stati elaborati dopo l'ultimo checkpoint verranno elaborati di nuovo. È quindi necessario che la logica di elaborazione dei messaggi sia idempotente o che l'applicazione possa deduplicare i messaggi.

Gestire le eccezioni. Un consumatore di eventi in genere elabora un gruppo di messaggi in un ciclo ripetitivo. È consigliabile gestire le eccezioni all'interno di questo ciclo di elaborazione per evitare di perdere un intero batch di messaggi se un singolo messaggio causa un'eccezione.

Usare una coda di messaggi non recapitabili (dead-letter queue). Se l'elaborazione di un messaggio determina un errore non temporaneo, inserire il messaggio in una coda di messaggi non recapitabili per poterne monitorare lo stato. A seconda dello scenario, è possibile eseguire un nuovo tentativo in un secondo momento, applicare una transazione di compensazione o effettuare altre azioni. Si noti che Event Hubs non ha alcuna funzionalità integrata per una coda dei messaggi errati. È possibile usare Azure Queue Storage o Service Bus per implementare una coda di messaggi non recapitabili oppure utilizzare Azure Functions o altri meccanismi di gestione eventi.

Configura la ridondanza di zona. Quando la ridondanza di zona è abilitata nello spazio dei nomi, Hub Eventi replica automaticamente le modifiche tra più zone di disponibilità. Se una zona di disponibilità si guasta, il failover avviene automaticamente. Per altre informazioni, vedere Zone di disponibilità.

Implementare il ripristino di emergenza eseguendo la commutazione a uno spazio dei nomi secondario di Event Hubs. Per altre informazioni, vedere Ripristino di emergenza geografico nel servizio Hub eventi di Azure.

Cache Redis di Azure

Configurare la ridondanza della zona. Quando la ridondanza della zona è abilitata nella tua cache, la cache di Azure per Redis distribuisce le macchine virtuali che ospitano la cache in più zone di disponibilità. La ridondanza della zona offre disponibilità elevata e tolleranza di errore in caso di interruzione del data center. Per altre informazioni, vedere Abilitare la ridondanza a livello di zona per Redis di Azure Cache.

Configurare la georeplicazione. La replica geografica fornisce un meccanismo per il collegamento di due istanze Cache Redis di Azure di livello Premium. I dati scritti nella cache primaria vengono replicati in una cache secondaria di sola lettura. Per altre informazioni, vedere Come configurare la replica geografica per Cache Redis di Azure.

Configurare la persistenza dei dati. La persistenza di Redis consente di rendere persistenti i dati archiviati in Redis. È inoltre possibile creare snapshot ed eseguire il backup dei dati, per consentirne il caricamento in caso di errore hardware. Per altre informazioni, vedere Come configurare la persistenza dei dati per cache Redis di Azure di livello Premium.

Se si usa la cache di Azure per Redis come cache di dati temporanea e non come archivio persistente, queste raccomandazioni potrebbero non essere applicabili.

Fornire più repliche. Usare almeno due repliche per un'alta disponibilità di lettura o tre per un'alta disponibilità di lettura-scrittura.

Utilizzare la ridondanza zonale. È possibile distribuire repliche AI Search in più zone di disponibilità. Questo approccio consente al servizio di rimanere operativo anche quando si verificano interruzioni del data center. Per altre informazioni, vedere Affidabilità nella ricerca di intelligenza artificiale

Configurare gli indicizzatori per le distribuzioni in più aree. Con una distribuzione in più aree, si possono considerare le opzioni per la continuità nell'indicizzazione.

  • Se l'origine dati è con replica geografica, in genere è consigliabile indirizzare ogni indicizzatore di ogni servizio di ricerca di intelligenza artificiale regionale alla replica locale dell'origine dati. Tale approccio non è tuttavia consigliato per i set di dati di grandi dimensioni archiviati nel database SQL di Azure. Il motivo è che Ricerca di intelligenza artificiale non può eseguire l'indicizzazione incrementale da repliche di database SQL secondarie, solo dalle repliche primarie. Indirizzare quindi tutti gli indicizzatori verso la replica primaria. Dopo un failover, punta gli indicizzatori dell'AI Search verso la nuova replica primaria.

  • Se l'origine dati non è replicata geograficamente, indirizza più indicizzatori alla stessa origine dati, in modo che i servizi di ricerca di intelligenza artificiale in più regioni possano indicizzare continuamente e in modo indipendente dall'origine dati. Per altre informazioni, vedere Considerazioni sull'affidabilità della ricerca di intelligenza artificiale.

Bus di servizio

Usare il livello Premium per i carichi di lavoro di produzione. La messaggistica Premium del bus di servizio offre risorse di elaborazione dedicate e riservate, oltre alla capacità di memoria per supportare velocità effettiva e prestazioni prevedibili. Il livello di messaggistica Premium consente anche di accedere alle nuove funzionalità disponibili in un primo momento solo per i clienti Premium. È possibile decidere il numero di unità di messaggistica in base ai carichi di lavoro previsti.

Gestire i messaggi duplicati. Se in un server di pubblicazione si verifica un errore subito dopo l'invio di un messaggio o se si riscontrano problemi di rete o di sistema, potrebbe erroneamente non venire registrato che il messaggio è stato recapitato e lo stesso messaggio potrebbe essere inviato due volte al sistema. Il bus di servizio può gestire questo problema abilitando il rilevamento dei messaggi duplicati. Per altre informazioni, vedere Rilevamento duplicati.

Gestire le eccezioni. Le API di messaggistica generano eccezioni quando si verifica un errore dell'utente, un errore di configurazione o un errore di altro tipo. Il codice client (mittenti e ricevitori) dovrebbe gestire queste eccezioni nel codice. Questo aspetto è particolarmente importante nell'elaborazione batch, in cui la gestione delle eccezioni può essere usata per evitare di perdere un intero batch di messaggi. Per altre informazioni, vedere Eccezioni di messaggistica del bus di servizio.

Politica di ripetizione. Service Bus consente di selezionare la politica di ripetizione più appropriata per le applicazioni. Il criterio predefinito consente un massimo di 9 tentativi di ripetizione e un'attesa di 30 secondi, ma può essere modificato ulteriormente.

Usare una coda dei messaggi non consegnati. Se un messaggio non può essere elaborato o recapitato ad alcun destinatario dopo più tentativi, viene spostato in una coda di messaggi non recapitabili. Implementare un processo per leggere i messaggi dalla coda di messaggi non recapitabili, controllarli e correggere il problema. A seconda dello scenario, è possibile riprovare a inviare il messaggio così com'è, apportare le modifiche e riprovare oppure eliminare il messaggio. Per ulteriori informazioni, vedere Panoramica delle code di dead-letter del Service Bus.

Usare la ridondanza delle zone. Quando la ridondanza della zona è abilitata nello spazio dei nomi, il Service Bus replica automaticamente le modifiche tra più zone di disponibilità. Se una zona di disponibilità si guasta, il failover avviene automaticamente. Per altre informazioni, vedere Procedure consigliate per isolare le applicazioni del bus di servizio da interruzioni ed emergenze del servizio.

Usare il Ripristino di Emergenza Geolocalizzato. Il ripristino di emergenza geografico assicura che l'elaborazione dei dati continui a funzionare in un'area o un data center diverso se un'intera area o data center di Azure diventa non disponibile a causa di una situazione di emergenza. Per ulteriori informazioni, vedere Ripristino geografico di emergenza di Azure Service Bus.

Archiviazione

Utilizzare l'archiviazione con ridondanza a livello di zona. L'archiviazione con ridondanza della zona (ZRS) copia i dati in modo sincrono fra tre zone di disponibilità di Azure nell'area primaria. Se si verifica un'interruzione di una zona di disponibilità, Azure Storage passa automaticamente a un'altra zona. Per altre informazioni, vedere Ridondanza di Archiviazione di Azure.

Quando si usa la ridondanza geografica, configurare l'accesso in lettura. Se si usa un'architettura in più aree, usare un livello di archiviazione appropriato per la ridondanza globale. Con l'archiviazione con ridondanza geografica e accesso in lettura (RA-GRS) o l'archiviazione con ridondanza geografica a zone e accesso in lettura (RA-GZRS), i dati vengono replicati in una regione secondaria. RA-GRS usa l'archiviazione a ridondanza locale (LRS) nell'area primaria, mentre RA-GZRS usa l'archiviazione a ridondanza di zona (ZRS) nell'area primaria. Entrambe le configurazioni forniscono l'accesso in sola lettura ai dati nell'area secondaria. Se si verifica un'interruzione dell'archiviazione nell'area primaria, l'applicazione può leggere i dati dall'area secondaria se è stata progettata per questa possibilità. Per altre informazioni, vedere Ridondanza di Archiviazione di Azure.

Per i dischi delle macchine virtuali, usare i dischi gestiti.I dischi gestiti offrono una migliore affidabilità per le macchine virtuali in un set di disponibilità, perché i dischi sono sufficientemente isolati l'uno dall'altro per evitare singoli punti di errore. Inoltre, i dischi gestiti non sono soggetti ai limiti di IOPS dei dischi rigidi virtuali creati in un account di archiviazione. Per altre informazioni, vedere Gestire la disponibilità delle macchine virtuali Windows in Azure.

Per l'archiviazione delle code, creare una coda di backup in un'altra regione. Per l'archiviazione tramite code, una replica di sola lettura ha un uso limitato, perché non è possibile accodare o rimuovere elementi dalla coda. Creare invece una coda di backup in un account di archiviazione in un'altra area. Se si verifica un'interruzione dell’Archiviazione di Azure, l'applicazione può usare la coda di backup fino a che l'area primaria non diventa nuovamente disponibile. In questo modo, l'applicazione può continuare a elaborare nuove richieste durante l'interruzione.

Database SQL

Usare il livello Standard o Premium. Questi livelli offrono un periodo di ripristino temporizzato più lungo (35 giorni). Per altre informazioni vedere SQL Database options and performance (Prestazioni e opzioni del database SQL).

Abilitare il controllo del database SQL. Il controllo può essere usato per diagnosticare errori umani o attacchi dannosi. Per altre informazioni, vedere l' Introduzione al controllo del database SQL.

Usare la replica geografica attiva. Usare la replica geografica attiva per crearne una secondaria leggibile in un'altra area. Se il database primario restituisce un errore o deve semplicemente essere portato offline, eseguire un failover manuale al database secondario. Fino al momento di failover, il database secondario rimane in sola lettura. Per altre informazioni, vedere SQL Database Active Geo-Replication (Replica geografica attiva del database SQL).

Usare il partizionamento orizzontale. Considerare l'utilizzo dello sharding per il partizionamento orizzontale del database. La shardizzazione può fornire un isolamento dei guasti. Per ulteriori informazioni, vedere Scalabilità orizzontale con Azure SQL Database.

Utilizzare il ripristino a un punto specifico nel tempo per recuperare da un errore umano. Il ripristino a un determinato momento riporta il database a un momento precedente. Per altre informazioni, vedere Ripristinare un database SQL di Azure mediante i backup automatici del database.

Utilizzare il ripristino a livello geografico per recuperare da un'interruzione del servizio. Il ripristino geografico recupera un database da un backup con ridondanza geografica. Per altre informazioni, vedere Ripristinare un database SQL di Azure mediante i backup automatici del database.

Azure Synapse Analytics

Non disabilitare il backup geografico. Per impostazione predefinita, Azure Synapse Analytics esegue un backup completo dei dati nel pool SQL dedicato ogni 24 ore per il ripristino di emergenza. È sconsigliato disattivare la funzionalità. Per ulteriori informazioni, vedere Geo-backups.

SQL Server in esecuzione in una VM

Eseguire il backup del database. Se si usa già Backup di Azure per eseguire il backup delle VM, considerare di usare Backup di Azure per carichi di lavoro di SQL Server con DPM. Con questo approccio, esiste un ruolo di amministratore di backup per l'organizzazione e una procedura di ripristino unificata per le macchine virtuali e SQL Server. Usare altrimenti Backup gestito di SQL Server in Microsoft Azure.

Gestione traffico

Eseguire il failback manuale. Dopo un failover di Gestione del traffico, eseguire il failback manuale anziché quello automatico. Prima del failback, verificare che tutti i sottosistemi dell'applicazione siano integri. In caso contrario, si potrebbe creare una situazione in cui l'applicazione passa alternativamente da un data center all'altro.

Creare un endpoint di sonda di controllo dello stato. Creare un endpoint personalizzato che segnali lo stato generale dell'applicazione. Il Gestione Traffico può così eseguire il failover se si verifica un errore in un percorso critico, e non solo nel front-end. L'endpoint dovrebbe restituire un codice di errore HTTP se una qualsiasi dipendenza critica è malfunzionante o non è raggiungibile. Non segnalare tuttavia gli errori relativi ai servizi non critici. Altrimenti, la sonda di integrità potrebbe attivare il failover quando non è necessario, creando così falsi positivi. Per altre informazioni, vedere Traffic Manager endpoint monitoring and failover (Monitoraggio degli endpoint di Gestione traffico e failover).

Macchine virtuali

Evitare di eseguire un carico di lavoro di produzione in una singola VM. La distribuzione in una singola macchina virtuale non è resistente alle operazioni di manutenzione pianificate o non pianificate. Inserire invece più macchine virtuali in un set di disponibilità o set di scalabilità di macchine virtuali, posizionando un servizio di bilanciamento del carico davanti.

Specificare un set di disponibilità quando si esegue il provisioning della VM. Non è possibile attualmente aggiungere una macchina virtuale a un set di disponibilità dopo avere eseguito il provisioning della macchina virtuale. Quando si aggiunge una nuova macchina virtuale a un set di disponibilità esistente, assicurarsi di creare una scheda di rete per la macchina virtuale e aggiungere la scheda di rete al pool di indirizzi back-end nel servizio di bilanciamento del carico. In caso contrario, il servizio di bilanciamento del carico non instrada il traffico di rete a tale macchina virtuale.

Inserire ogni livello di applicazione in un set di disponibilità separato. In un'applicazione a più livelli, non inserire le macchine virtuali appartenenti a livelli differenti nello stesso set di disponibilità. Le macchine virtuali in un availability set sono distribuite su domini di errore (FD) e su domini di aggiornamento (UD). Per ottenere il vantaggio della ridondanza di FDs e UDs, tuttavia, ogni macchina virtuale nel set di disponibilità deve essere in grado di gestire le stesse richieste dei clienti.

Replicare le 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 nell'area di destinazione in modo continuativo e asincrono. I punti di ripristino vengono creati a intervalli di pochi minuti. In questo modo, si ottiene un Obiettivo del Punto di Ripristino (RPO) nell'ordine di pochi 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.

Scegliere le dimensioni di VM corrette in base ai requisiti di prestazioni. Quando si sposta un carico di lavoro esistente in Azure, per iniziare scegliere le dimensioni di VM più simili a quelle dei server locali. Misurare quindi le prestazioni del carico di lavoro effettivo in relazione agli aspetti di CPU, memoria e operazioni di I/O al secondo del disco e regolare le dimensioni secondo le necessità. Ciò aiuta a garantire il corretto funzionamento dell'applicazione in un ambiente cloud. Inoltre, se sono necessarie più schede di interfaccia di rete, è importante essere consapevoli del limite per ciascuna dimensione delle schede.

Usa dischi gestiti per i VHD.I dischi gestiti offrono una migliore affidabilità per le macchine virtuali in un set di disponibilità, perché i dischi sono sufficientemente isolati tra loro per evitare punti di errore singoli. Inoltre, i dischi gestiti non sono soggetti ai limiti di IOPS dei dischi rigidi virtuali creati in un account di archiviazione. Per altre informazioni, vedere Gestire la disponibilità delle macchine virtuali Windows in Azure.

Installare le applicazioni in un disco di dati, non nel disco del sistema operativo. In caso contrario, è possibile raggiungere il limite delle dimensioni del disco.

Usare Backup di Azure per eseguire il backup delle VM. I backup proteggono contro la perdita di dati accidentale. Per ulteriori informazioni, consultare Proteggere le VM di Azure con una cassetta dei servizi di ripristino.

Abilitare i log di diagnostica. Includere le metriche di integrità di base, i log dell'infrastruttura e la diagnostica di avvio. La diagnostica di avvio permette di diagnosticare gli errori di avvio quando la VM passa a uno stato non avviabile. Per altre informazioni, vedere Overview of Azure Diagnostic Logs (Panoramica dei log di diagnostica di Azure).

Configurare Monitoraggio di Azure. Raccogliere e analizzare i dati di monitoraggio dalle macchine virtuali di Azure, inclusi il sistema operativo guest e i carichi di lavoro che vi si eseguono, vedere Monitoraggio di Azure e Avvio rapido: Monitoraggio di Azure.

Rete virtuale

Per consentire o bloccare gli indirizzi IP pubblici, aggiungere un gruppo di sicurezza di rete alla subnet. Bloccare l'accesso di utenti malintenzionati o consentire l'accesso solo agli utenti che dispongono delle autorizzazioni per accedere all'applicazione.

Creare una sonda di integrità personalizzata. I probe di integrità di Load Balancer possono testare i protocolli HTTP o TCP. Se una macchina virtuale esegue un server HTTP, il probe HTTP è un indicatore migliore dello stato di salute rispetto a un probe TCP. Per un probe HTTP, usare un endpoint personalizzato che segnali l'integrità complessiva dell'applicazione, incluse tutte le dipendenze critiche. Per altre informazioni, vedere Panoramica di Azure Load Balancer.

Non bloccare la sonda di stato. Il controllo di integrità del Load Balancer viene inviato da un indirizzo IP noto, 168.63.129.16. Non bloccare il traffico da o verso questo indirizzo IP nei criteri del firewall o nelle regole del gruppo di sicurezza di rete. Se si blocca la sonda di integrità, il servizio di bilanciamento del carico rimuove la macchina virtuale dal ciclo.

Abilitare il logging del Load Balancer. I registri mostrano il numero di macchine virtuali nel back-end che non ricevono traffico di rete a causa di risposte fallite delle sonde. Per altre informazioni, vedere Log analytics for Azure Load Balancer (Analisi dei log per Azure Load Balancer).