Documentazione dell'affidabilità di Azure

  • Articolo

L'affidabilità è costituita da due principi: resilienza e disponibilità. L'obiettivo della resilienza è evitare errori e, se ancora si verificano, per restituire l'applicazione a uno stato completamente funzionante. L'obiettivo della disponibilità è fornire un accesso coerente all'applicazione o al carico di lavoro. È importante pianificare l'affidabilità proattiva in base ai requisiti dell'applicazione.

Azure include servizi di affidabilità predefiniti che è possibile usare e gestire in base alle esigenze aziendali. Che si tratti di un singolo errore del nodo hardware, di un errore a livello di rack, di un'interruzione del data center o di un'interruzione a livello di area su larga scala, Azure offre soluzioni che migliorano l'affidabilità. Ad esempio, i set di disponibilità assicurano che le macchine virtuali distribuite in Azure vengano distribuite tra più nodi hardware isolati in un cluster. Le zone di disponibilità proteggono le applicazioni e i dati dei clienti da errori del data center in più posizioni fisiche all'interno di un'area. Le aree e le zone di disponibilità sono fondamentali per la progettazione e la resilienza dell'applicazione e sono descritte in modo più dettagliato più avanti in questo articolo.

La documentazione sull'affidabilità di Azure offre indicazioni sull'affidabilità per i servizi di Azure. Queste indicazioni includono informazioni sul supporto della zona di disponibilità, indicazioni sul ripristino di emergenza e sulla disponibilità dei servizi.

Per indicazioni dettagliate sull'affidabilità specifiche del servizio, incluse le zone di disponibilità, il ripristino di emergenza o la disponibilità elevata, vedere Panoramica delle linee guida per l'affidabilità specifiche del servizio di Azure.

Per informazioni sui principi di affidabilità e affidabilità e sull'architettura nei servizi di Microsoft Azure, vedere Framework microsoft Azure Well-Architected Framework: Reliability.

Requisiti di affidabilità

Il livello di affidabilità richiesto per qualsiasi soluzione di Azure dipende da diverse considerazioni. Il contratto di servizio di disponibilità e latenza e altri requisiti aziendali determinano le scelte architetturali e il livello di resilienza e devono essere considerati per primi. I requisiti di disponibilità vanno da quanto tempo di inattività è accettabile e quanto costa l'azienda, alla quantità di denaro e tempo che è possibile investire realisticamente per rendere un'applicazione a disponibilità elevata.

La creazione di sistemi di affidabilità in Azure è una responsabilità condivisa. Microsoft è responsabile dell'affidabilità della piattaforma cloud, inclusa la rete globale e i data center. I clienti e i partner di Azure sono responsabili della resilienza delle applicazioni cloud, usando le procedure consigliate per l'architettura in base ai requisiti di ogni carico di lavoro. Anche se Azure si impegna continuamente per ottenere la massima resilienza possibile nel contratto di servizio per la piattaforma cloud, è necessario definire contratti di servizio di destinazione personalizzati per ogni carico di lavoro nella soluzione. Un contratto di servizio consente di valutare se l'architettura soddisfi i requisiti aziendali. Quando si cercano percentuali più elevate di tempo di attività garantito dal contratto di servizio, aumentano i costi e la complessità per ottenere tale livello di disponibilità. Un tempo di attività del 99,99% si traduce in circa cinque minuti di tempo di inattività totale al mese. Vale la pena maggiore complessità e costo per raggiungere tale percentuale? La risposta dipende dai singoli requisiti aziendali. Durante la decisione degli impegni finali del contratto di servizio, comprendere i contratti di servizio supportati da Microsoft. Ogni servizio di Azure ha un proprio contratto di servizio.

Diagram showing the shared responsibility model for Azure business continuity.

Nel modello locale tradizionale, l'intera responsabilità della gestione, dall'hardware per calcolo, archiviazione e rete all'applicazione, dipende dall'utente. È necessario pianificare diversi tipi di errori e come gestirli creando una strategia di ripristino di emergenza. Con IaaS, il provider di servizi cloud è responsabile della resilienza dell'infrastruttura principale, tra cui archiviazione, rete e calcolo. Quando si passa da IaaS a PaaS e quindi a SaaS, si scopre che si è responsabili di meno e il provider di servizi cloud è responsabile di più.  

Per altre informazioni sui principi di affidabilità, vedere la documentazione sull'affidabilità del framework ben progettato.  

Creazione di affidabilità

È necessario definire i requisiti di affidabilità dell'applicazione all'inizio della pianificazione. Se si sa quali applicazioni non necessitano di disponibilità elevata al 100% durante determinati periodi di tempo, è possibile ottimizzare i costi durante questi periodi non critici. Identificare il tipo di errori che un'applicazione può riscontrare e il potenziale effetto di ogni errore. Un piano di ripristino deve coprire tutti i servizi critici finali finalizzando la strategia di ripristino a livello di singolo componente e del livello complessivo dell'applicazione. Progettare la strategia di ripristino per proteggersi da errori a livello di zona, a livello di area e di applicazione. Eseguire test dell'ambiente dell'applicazione end-to-end per misurare l'affidabilità e il ripristino delle applicazioni in caso di errore imprevisto.

L'elenco di controllo seguente illustra l'ambito della pianificazione dell'affidabilità.

Pianificazione dell'affidabilità
Definire obiettivi di disponibilità e ripristino per soddisfare i requisiti aziendali.
Progettare le funzionalità di affidabilità delle applicazioni in base ai requisiti di disponibilità.
Allineare le applicazioni e le piattaforme dati per soddisfare i requisiti di affidabilità.
Configurare i percorsi di connessione per promuovere la disponibilità.
Usare le zone di disponibilità e la pianificazione del ripristino di emergenza, se applicabile per migliorare l'affidabilità e ottimizzare i costi.
Assicurarsi che l'architettura dell'applicazione sia resiliente agli errori.
Sapere cosa accade se i requisiti del contratto di servizio non vengono soddisfatti.
Identificare i possibili punti di errore nel sistema. La progettazione dell'applicazione deve tollerare gli errori di dipendenza distribuendo l'interruzione del circuito.
Creare applicazioni che operano in assenza delle relative dipendenze.

RTO e RPO

Due metriche importanti da considerare sono l'obiettivo del tempo di ripristino e l'obiettivo del punto di ripristino, dal momento che sono riconducibili al ripristino di emergenza.  Per altre informazioni sui requisiti di progettazione funzionale e non funzionale, vedere Requisiti funzionali e non funzionali del framework ben progettato.

  • L'obiettivo del tempo di ripristino (RTO) è il tempo massimo accettabile che un'applicazione non sia disponibile dopo un evento imprevisto.

  • Obiettivo del punto di ripristino (RPO) è la durata massima di perdita dei dati accettabile durante un'emergenza.

RTO e RPO sono requisiti non funzionali di un sistema e devono essere definiti dai requisiti aziendali. Per ottenere questi valori, è consigliabile condurre una valutazione dei rischi e comprendere chiaramente i costi correlati a tempo di inattività o perdita di dati.  

Aree e zone di disponibilità

Le aree e le zone di disponibilità fanno parte dell'equazione sull'affidabilità. Le aree includono più zone di disponibilità separate fisicamente. Queste zone di disponibilità sono connesse da una rete a prestazioni elevate con una latenza inferiore a 2 ms tra le zone fisiche. La bassa latenza consente ai dati di rimanere sincronizzati e accessibili quando si verificano problemi. È possibile usare questa infrastruttura in modo strategico durante la progettazione di applicazioni e infrastrutture dati che replicano e offrono automaticamente servizi ininterrotti tra zone e aree diverse.

I servizi di Microsoft Azure supportano le zone di disponibilità e sono abilitati per guidare le operazioni cloud a disponibilità elevata ottimale, supportando al contempo le esigenze di strategia di ripristino e continuità aziendale tra aree.

Per la pianificazione del ripristino di emergenza, le aree associate ad altre aree offrono la replica tra aree e garantiscono la protezione replicando in modo asincrono i dati in altre aree di Azure. Le aree senza una coppia seguono le linee guida per la residenza dei dati e offrono disponibilità elevata con zone di disponibilità e archiviazione con ridondanza locale o con ridondanza della zona. I clienti dovranno pianificare il ripristino di emergenza tra aree in base alle esigenze RTO/RPO.

Scegliere l'area migliore per le proprie esigenze in base alle considerazioni tecniche e normative, ovvero funzionalità del servizio, residenza dei dati, requisiti di conformità, latenza, e iniziare ad avanzare la strategia di affidabilità. Per altre informazioni, vedere Aree di Azure e zone di disponibilità.

Dipendenze del servizio di Azure

I servizi di Microsoft Azure sono disponibili a livello globale per guidare le operazioni cloud a un livello ottimale.

I servizi di Azure distribuiti nelle aree di Azure sono elencati nella pagina prodotti dell'infrastruttura globale di Azure. Per comprendere meglio le aree e le zone di disponibilità in Azure, vedere Aree e zone di disponibilità in Azure.

I servizi di Azure sono creati per l'affidabilità, tra cui disponibilità elevata e ripristino di emergenza. Non esistono servizi dipendenti da un singolo data center logico (per evitare singoli punti di errore). I servizi non a livello di area elencati nei prodotti dell'infrastruttura globale di Azure sono servizi per i quali non esiste alcuna dipendenza da un'area di Azure specifica. I servizi non a livello di area vengono distribuiti in due o più aree e, in caso di errore a livello di area, l'istanza del servizio in un'altra area continua a gestire i clienti. Alcuni servizi non a livello di area consentono ai clienti di specificare l'area in cui verrà distribuita la macchina virtuale (VM) sottostante in cui verrà eseguita l'esecuzione del servizio. Desktop virtuale Azure, ad esempio, consente ai clienti di specificare la posizione dell'area in cui risiede la macchina virtuale. Tutti i servizi di Azure che archiviano i dati dei clienti consentono al cliente di specificare le aree specifiche in cui verranno archiviati i dati. L'eccezione è Microsoft Entra ID, con posizionamento geografico ,ad esempio Europa o America del Nord. Per altre informazioni sulla residenza dell'archiviazione dei dati, vedere la mappa di residenza dei dati.

Se è necessario comprendere le dipendenze tra i servizi di Azure per progettare meglio le applicazioni e i servizi, è possibile richiedere la documentazione sulle dipendenze del servizio di Azure contattando il rappresentante microsoft. Questo documento elenca le dipendenze per i servizi di Azure, incluse le dipendenze da qualsiasi servizio interno principale comune, ad esempio i servizi del piano di controllo. Per ottenere questa documentazione, è necessario essere un cliente Microsoft e avere il contratto di non divulgazione appropriato con Microsoft.

Passaggi successivi