Affidabilità in Azure HDInsight in servizio Azure Kubernetes
Questo articolo descrive il supporto per l'affidabilità in Azure HDInsight in servizio Azure Kubernetes (servizio Azure Kubernetes) e illustra sia raccomandazioni specifiche sull'affidabilità che il ripristino di emergenza e la continuità aziendale. Per una panoramica più dettagliata dei principi di 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:
| Immagine | Priorità | Descrizione |
|---|---|---|
|
Fortemente | Correzione immediata necessaria. |
|
Medio | Correzione entro 3-6 mesi. |
|
Basso | Deve essere esaminato. |
Riepilogo delle raccomandazioni per l'affidabilità
Supporto della zona di disponibilità
Le zone di disponibilità di Azure sono costituite da almeno tre gruppi fisicamente separati di data center all'interno di ogni area di Azure. I data center all'interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. Le zone di disponibilità sono progettate in modo che, in caso di errore in una zona locale, i servizi regionali, la capacità e la disponibilità elevata della zona interessata siano supportati dalle altre due zone.
Gli errori possono essere di tipo hardware o software oppure correlati a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene conseguita mediante la ridondanza e l'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à sono progettati per fornire il livello adeguato di affidabilità e flessibilità. Tali servizi possono essere configurati in due modi. Possono essere con ridondanza della zona, che prevede la replica automatica tra le zone, o a zona, con istanze aggiunte in una zona specifica. È anche possibile combinare questi approcci. Per altre informazioni sulle architetture a zona e con ridondanza della zona, vedere Raccomandazioni per l'uso delle zone e delle aree di disponibilità.
Attualmente, Azure HDInsight nel servizio Azure Kubernetes non supporta la zona di disponibilità nelle offerte di servizio.
Continuità aziendale e ripristino di emergenza
Il ripristino di emergenza si occupa del ripristino in caso di eventi a impatto elevato, come disastri 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 a un piano di ripristino di emergenza, vedere Raccomandazioni per la progettazione di una strategia di ripristino di emergenza.
Nell'ambito del ripristino di emergenza, Microsoft usa il modello di responsabilità condivisa. In un modello basato sulla responsabilità condivisa, Microsoft garantisce che l'infrastruttura di base e i servizi della piattaforma siano disponibili. Allo stesso tempo, molti servizi di Azure non replicano automaticamente i dati o eseguono il fallback da un'area in cui si è verificato un errore per effettuare la replica incrociata in un'altra area abilitata. Per tali servizi, l'utente ha la responsabilità di configurare un piano di ripristino di emergenza che funzioni per i propri carichi di lavoro. La maggior parte dei servizi eseguiti nelle offerte PaaS (Piattaforma distribuita come servizio) di Azure forniscono funzionalità e indicazioni per supportare il ripristino di emergenza ed è possibile usare funzionalità specifiche del servizio per supportare il ripristino rapido e sviluppare il piano di ripristino di emergenza.
Attualmente, il servizio e i database CP(Control Plane) del servizio Azure Kubernetes in Azure HDInsight vengono distribuiti tra aree di Azure. Tra queste aree, Azure HDInsight in istanze del servizio Azure Kubernetes e le istanze del database sono isolate. Quando si verifica un'interruzione a livello di area, un'area è inattiva. Tutte le risorse in questa area, incluso rp(provider di risorse) di Azure HDInsight su CP del servizio Azure Kubernetes, il database di Azure HDInsight su CP del servizio Azure Kubernetes e tutti i cluster dei clienti in questa area. In questo caso, è possibile attendere solo la fine dell'interruzione a livello di area. Quando viene ripristinata l'interruzione, il servizio Azure HDInsight nel servizio Azure Kubernetes viene ripristinato e anche tutti i cluster dei clienti sono tornati. È possibile che si verifichino alcuni problemi a causa dell'incoerenza dei dati dopo l'interruzione e richiede una correzione manuale.
Ripristino di emergenza in più aree
Azure HDInsight nel servizio Azure Kubernetes attualmente non supporta il failover tra aree. Il miglioramento della continuità aziendale con il ripristino di emergenza a disponibilità elevata tra aree richiede progettazioni dell'architettura di maggiore complessità e costi più elevati. I clienti possono scegliere di progettare la propria soluzione per eseguire il backup dei dati chiave e dello stato del processo in aree diverse.
Rilevamento, notifica e gestione di interruzioni
Usare gli strumenti di monitoraggio di Azure in HDInsight nel servizio Azure Kubernetes per rilevare un comportamento anomalo nel cluster e impostare le notifiche di avviso corrispondenti. È possibile abilitare Log Analytics in vari modi e usare il servizio Prometheus gestito con i dashboard di Azure Grafana per il monitoraggio. Per altre informazioni, vedere Integrazione di Monitoraggio di Azure.
Sottoscrivere gli avvisi di integrità di Azure per ricevere notifiche relative a problemi del servizio, manutenzione pianificata, integrità e avvisi di sicurezza per una sottoscrizione, un servizio o un'area geografica. Le notifiche sull'integrità che includono la causa del problema e l'ETA risoluta consentono di eseguire meglio failover e failback. Per altre informazioni, vedere Gestire l'integrità dei servizi e la documentazione sull'integrità dei servizi di Azure.
Ripristino di emergenza a singola area
Attualmente, Azure HDInsight nel servizio Azure Kubernetes include solo un'offerta di servizio standard e i cluster vengono creati in un'area geografica a singola area. I clienti sono responsabili del ripristino diaster.
Resilienza della capacità e del ripristino di emergenza proattivo
Azure HDInsight nel servizio Azure Kubernetes e i suoi clienti operano con il modello di responsabilità condivisa, il che significa che il cliente deve gestire il ripristino di emergenza per il servizio che distribuisce e controlla. Per garantire che il ripristino sia proattivo, i clienti devono sempre pre-distribuire i database secondari perché non esiste alcuna garanzia di capacità al momento dell'impatto per coloro che non sono stati preallocati.
A differenza della versione originale di HDInsight, la Macchine virtuali usata in HDInsight nei cluster del servizio Azure Kubernetes richiede la stessa quota delle macchine virtuali di Azure. Per altre informazioni, vedere Pianificazione della capacità.
Contenuto correlato
Per altre informazioni sugli elementi descritti in questo articolo, vedere: