Elenco di controllo per la resilienza per servizi di Azure specifici

  • Articolo

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 gli slot di staging e i backup automatici. Per altre informazioni, vedere Panoramica approfondita dei piani per Servizio app di Azure

Evitare il ridimensionamento. 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 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 usare gli slot nella distribuzione di produzione per il test. Tutte le app contenute nello stesso piano di servizio app condividono le stesse istanze di VM. 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 soluzione contiene sia un front-end Web che un'API Web, si può considerare di scomporli in app del Servizio app separate. 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 di servizio app con ridondanza della zona. Nelle aree supportate, i piani di servizio app possono essere distribuiti come ridondanti della zona, il che significa che le istanze vengono distribuite automaticamente tra le zone di disponibilità. servizio app 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, che ha un costo in DTU.

Distribuire in uno slot di staging. Creare uno slot di distribuzione per lo staging. Distribuire gli aggiornamenti dell'applicazione nello slot di staging e verificare la distribuzione prima di scambiarla nell'ambiente di 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 pronte per essere scambiate 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'ultima distribuzione valida nota. Quando si distribuisce un aggiornamento nell'ambiente di produzione, spostare la distribuzione di produzione precedente nell'ultimo slot valido noto. Questa operazione rende più semplice eseguire il rollback di una distribuzione non corretta. Se viene rilevato un problema in un secondo momento, è possibile ripristinare rapidamente l'ultima versione valida nota. 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 e di eseguire l'analisi della causa radice degli errori.

Azure Load Balancer

Selezionare SKU Standard. Load Balancer Standard offre una dimensione di affidabilità che Basic non è quella delle zone di disponibilità e della resilienza della zona. Ciò significa che se una zona viene danneggiata, questo non influisce su Load Balancer Standard con ridondanza della zona. Ciò garantisce che le distribuzioni siano in grado di contenere gli errori di zona all'interno di un'area. Inoltre, Load Balancer Standard supporta il bilanciamento del carico globale proteggendo l'applicazione da errori di area.

Eseguire il provisioning di almeno due istanze. Distribuire Azure LB con almeno due istanze nel back-end. Una singola istanza può causare un singolo punto di guasto. Per favorire la scalabilità, può essere necessario associare Load Balancer ai set 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. Altre informazioni sulla connettività in uscita. Anche se le regole in uscita consentono di migliorare la soluzione per distribuzioni di piccole o medie dimensioni, per i carichi di lavoro di produzione è consigliabile eseguire l'accoppiamento di Load Balancer Standard o qualsiasi distribuzione di subnet con il NAT di rete virtuale.

Gateway applicazione

Eseguire il provisioning di almeno due istanze. Distribuire il gateway applicazione con almeno due istanze. Un'istanza singola è un singolo punto di errore. Usare due o più istanze per la ridondanza e la scalabilità. Per essere idonei al contratto di servizio, è necessario eseguire il provisioning di due o più istanze di medie o grandi dimensioni.

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 della zona. Per altre informazioni, vedere Ottenere la disponibilità elevata con Azure Cosmos DB.

Replicare il database tra aree. 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 in un'altra area. Per altre informazioni, vedere Come distribuire i dati a livello globale con Azure Cosmos DB.

Hub eventi di

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

Gestire i messaggi duplicati. In caso di errore di un consumer eventi, l'elaborazione dei messaggi viene ripresa 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 consumer eventi in genere elabora un batch di messaggi in un ciclo. È 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. 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 Hub eventi non ha funzionalità predefinite per l'inserimento in una coda di messaggi non recapitabili. È possibile usare l'archivio code o il bus di servizio di Azure per implementare una coda di messaggi non recapitabili oppure usare Funzioni di Azure o altri meccanismi di gestione eventi.

Configurare la ridondanza della zona. Quando la ridondanza della zona è abilitata nello spazio dei nomi, Hub eventi replica automaticamente le modifiche tra più zone di disponibilità. Se una zona di disponibilità ha esito negativo, il failover viene eseguito automaticamente. Per altre informazioni, vedere Zone di disponibilità.

Implementare il ripristino di emergenza effettuando il failover in uno spazio dei nomi di Hub eventi secondario. 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 cache, 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 della zona per cache di Azure per Redis.

Configurare la replica geografica. 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 la cache di Azure per Redis.

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 una cache di Azure per Redis 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.

Eseguire il provisioning di più repliche. Usare almeno due repliche per la disponibilità elevata in lettura o tre per la disponibilità elevata in scrittura.

Usare la ridondanza della zona. È possibile distribuire repliche di Ricerca cognitiva in più zone di disponibilità. Questo approccio consente al servizio di rimanere operativi anche quando si verificano interruzioni del data center. Per altre informazioni, vedere Affidabilità in Ricerca cognitiva di Azure

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 puntare ogni indicizzatore di ogni servizio di Ricerca cognitiva di Azure a livello di area alla replica dell'origine dati locale. Tale approccio non è tuttavia consigliato per i set di dati di grandi dimensioni archiviati nel database SQL di Azure. Il motivo è che Ricerca cognitiva di Azure non è in grado di eseguire l'indicizzazione incrementale da repliche di database SQL secondarie, solo dalle repliche primarie. Puntare quindi tutti gli indicizzatori sulla replica primaria. Dopo un failover, puntare gli indicizzatori Ricerca cognitiva di Azure nella nuova replica primaria.

  • Se l'origine dati non viene replicata geograficamente, punta più indicizzatori nella stessa origine dati, in modo che Ricerca cognitiva di Azure servizi in più aree in modo continuo e indipendente dall'origine dati. Per altre informazioni, vedere Considerazioni sulle prestazioni e sull'ottimizzazione di Ricerca di Azure.

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.

Criteri di ripetizione. Il bus di servizio consente di selezionare i criteri di ripetizione più appropriati 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. Per altre informazioni, vedere Criteri di ripetizione - Bus di servizio.

Usare una coda di messaggi non recapitabili. 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 risolvere il problema. A seconda dello scenario, è possibile riprovare a inviare il messaggio così com'è, apportare le modifiche e riprovare oppure eliminare il messaggio. Per altre informazioni, vedere Panoramica delle code dei messaggi non recapitabili del bus di servizio.

Usare la ridondanza della zona. Quando la ridondanza della zona è abilitata nello spazio dei nomi, bus di servizio replica automaticamente le modifiche tra più zone di disponibilità. Se una zona di disponibilità ha esito negativo, il failover viene eseguito 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 geografico. 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 altre informazioni, vedere Ripristino di emergenza geografico per il bus di servizio di Azure.

Storage

Usare l'archiviazione con ridondanza della 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à, Archiviazione di Azure esegue automaticamente il failover in una zona alternativa. 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 o archiviazione con ridondanza geografica e accesso in lettura, i dati vengono replicati in un'area secondaria. RA-GRS usa l'archiviazione con ridondanza locale nell'area primaria, mentre l'archiviazione con ridondanza della zona (ZRS) viene usata dall'archiviazione con ridondanza della zona 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 di VM, usare Managed Disks.Il servizio Managed Disks offre una maggiore affidabilità per le VM in un set di disponibilità, perché fa in modo che i dischi siano sufficientemente isolati gli uni dagli altri per evitare singoli punti di guasto. I dischi gestiti, inoltre, non sono soggetti ai limiti delle operazioni di I/O al secondo 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 code, creare una coda di backup in un'altra area. Per Queue Archiviazione, una replica di sola lettura ha un uso limitato, perché non è possibile accodare o rimuovere dalla coda gli elementi. Creare invece una coda di backup in un account di archiviazione in un'altra area. Se si verifica un'interruzione Archiviazione di Azure, l'applicazione può usare la coda di backup fino a quando 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. Nella fase 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 del partizionamento orizzontale per il database. Il partizionamento orizzontale può isolare gli errori. Per altre informazioni, vedere Aumentare il numero di istanze con il database SQL di Azure.

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

Eseguire 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, 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 altre informazioni, consultare Backup geografici.

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, si usano un solo 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 traffico, eseguire il failback manuale anziché 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. Per altre informazioni, vedere Eseguire macchine virtuali in più aree per una disponibilità elevata.

Creare un endpoint di probe di integrità. Creare un endpoint personalizzato che segnali l'integrità generale dell'applicazione. Gestione traffico può così eseguire il failover se si verifica un errore in un percorso critico, non solo nel front-end. L'endpoint restituisce un codice di errore HTTP se una qualsiasi dipendenza critica non è integra o non è raggiungibile. Non segnalare tuttavia gli errori relativi ai servizi non critici. In caso contrario, il probe di integrità potrebbe generare il failover quando non è necessario e creare di conseguenza 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, con un servizio di bilanciamento del carico in primo piano.

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 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 set di disponibilità sono posizionate in più domini di errore (FD) e di aggiornamento (UD). Per ottenere il vantaggio della ridondanza dei domini di errore e dei domini di aggiornamento, tuttavia, ogni macchina virtuale nel set di disponibilità deve essere in grado di gestire le stesse richieste del client.

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 tal modo, si ottiene 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.

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, tenerne presente il limite per ogni dimensione.

Usare Managed Disks per i dischi rigidi virtuali.Il servizio Managed Disks offre una maggiore affidabilità per le VM in un set di disponibilità, perché fa in modo che i dischi siano sufficientemente isolati gli uni dagli altri per evitare singoli punti di guasto. I dischi gestiti, inoltre, non sono soggetti ai limiti delle operazioni di I/O al secondo 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 altre informazioni, vedere Proteggere le VM di Azure con un insieme di credenziali di 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 delle macchine virtuali di Azure, inclusi il sistema operativo guest e i carichi di lavoro in esecuzione, 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 un probe di integrità personalizzato. I probe di integrità di Load Balancer possono testare i protocolli HTTP o TCP. Se una macchina virtuale viene eseguita in un server HTTP, il migliore indicatore dello stato di integrità è un probe HTTP 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 il probe di integrità. Il probe di integrità di 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 il probe di integrità, il servizio di bilanciamento del carico rimuove la macchina virtuale dalla rotazione.

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