Affidabilità in Operatore Nexus di Azure
Importante
Questa funzionalità è attualmente disponibile solo in anteprima. Le anteprime vengono rese disponibili a condizione che l'utente accetti le condizioni supplementari per l'utilizzo.
Questo articolo descrive il supporto per l'affidabilità in Operatore Nexus di Azure e illustra la resilienza all'interno dell'area con le zone di disponibilità. Per una panoramica più dettagliata dell'affidabilità in Azure, vedere Affidabilità di Azure.
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 presenti all’interno di ogni zona sono dotati di alimentazione, raffreddamento e infrastruttura di rete indipendenti. In caso di errore in una zona locale, le zone di disponibilità sono progettate in modo tale che i servizi a livello di area, la capacità e la disponibilità elevata della zona interessata siano supportati dalle due zone rimanenti.
Gli errori possono essere correlati a software e hardware o a eventi come terremoti, inondazioni e incendi. La tolleranza agli errori viene raggiunta con 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à.
Operatore Nexus di Azure offre distribuzioni con ridondanza della zona di disponibilità per impostazione predefinita. I componenti di Operatore Nexus, ad esempio Gestione cluster e Controller di tessuto di rete, vengono distribuiti in un cluster del servizio Azure Kubernetes (AKS) abilitato con le zone di disponibilità. Altre dipendenze del servizio, ad esempio il servizio account di archiviazione e KeyVault, sono configurate anche con la ridondanza della zona di disponibilità.
Nota
L'istanza locale di Operatore Nexus implementa una progettazione multi-rack che fornisce ridondanza fisica a tutti i livelli dello stack. Ogni rack è progettato come dominio di errore o zona Nexus. I carichi di lavoro dei clienti possono essere distribuiti in più rack/nodi, offrendo essenzialmente un'esperienza simile alla zona di disponibilità multipla.
Esperienza di inattività della zona di disponibilità di Azure
In uno scenario di inattività della zona di disponibilità, le chiamate API al cluster e ai provider di risorse continuerebbero a funzionare senza interruzioni. Non vi sarebbe alcun impatto sui carichi di lavoro del tenant locale attualmente in esecuzione o sulla possibilità di creare nuovi carichi di lavoro del tenant. Inoltre, non dovrebbe verificarsi alcuna perdita di dati, poiché è garantita la resilienza di Operatore Nexus e altri tipi di risorse.
Supporto del failover della zona di disponibilità di Azure
In caso di errore della zona di disponibilità, la riconnessione a un'altra zona di disponibilità di Azure è automatica e non richiede alcuna interazione da parte dell'utente.
Disponibilità nelle distribuzioni dell’istanza Operatore Nexus
La garanzia della disponibilità nelle distribuzioni del carico di lavoro di Operatore Nexus di Azure è una responsabilità suddivisa. Come indicato nella sezione precedente, le risorse basate sul servizio Azure Kubernetes di Operatore Nexus vengono distribuite con ridondanza della zona di disponibilità. In questa sezione vengono prese in considerazione le procedure consigliate per la disponibilità del carico di lavoro locale.
In generale, gli obiettivi di disponibilità vengono raggiunti tramite distribuzioni locali e con ridondanza geografica.
Zona Nexus: meccanismo per la ridondanza del carico di lavoro locale
Le istanze locali di Operatore Nexus sono costituite da una progettazione multi-rack che fornisce ridondanza fisica a tutti i livelli dello stack. Ogni rack è designato come dominio di errore e, pertanto, può essere configurato come una zona Nexus in cui queste zone possono e, preferibilmente, devono essere utilizzate per le distribuzioni di carichi di lavoro ridondanti locali.
Istanza Nexus: meccanismo per la ridondanza del carico di lavoro geografico
Le istanze locali di Nexus sono ospitate in un'area di Azure specifica. Come indicato in precedenza, i servizi di Azure e le risorse Nexus usati vengono distribuiti in più zone di disponibilità dell'area di Azure.
Le istanze Nexus distribuite geograficamente, ovvero non nello stesso data center dell'operatore e, probabilmente, nemmeno nella stessa area geografica, e ospitate in aree di Azure diverse, dovrebbero essere usate per distribuire in modo ridondante i carichi di lavoro per la ridondanza geografica.
Avviso
La distribuzione di carichi di lavoro, ad esempio, in due istanze Nexus distribuite geograficamente non è sufficiente per ottenere una vera ridondanza geografica, a meno che le istanze Nexus con ridondanza geografica non siano ospitate in aree di Azure diverse.
Nell’improbabile eventualità che un'area di Azure non sia più disponibile, anche i servizi di Azure e le risorse Nexus in tale area non saranno più disponibili. Sebbene ciò non abbia un impatto sui carichi di lavoro in esecuzione, ostacola funzionalità come l'avvio di nuovi carichi di lavoro, l'analisi, e così via.
Istanze Nexus multiple nella stessa area geografica
Esistono scenari in cui è necessario distribuire più istanze Nexus nella stessa area geografica. La ridondanza geografica del carico di lavoro non si ottiene ovviamente distribuendo i carichi di lavoro in istanze Nexus nella stessa area geografica.
Nella progettazione dell'affidabilità, oltre alla disponibilità, è necessario prendere in considerazione anche la resilienza e la capacità di eseguire il ripristino in caso di errori. Il ripristino in caso di errori e la capacità di soddisfare gli obiettivi del tempo di ripristino richiedono di limitare il raggio di "esplosione" o di impatto degli errori. Nello scenario in cui più istanze Nexus vengono distribuite nella stessa area geografica, la progettazione resiliente richiede che queste istanze Nexus siano ospitate in aree di Azure diverse. Pertanto, quando si verifica un errore in un'area di Azure, l'impatto è limitato a un'istanza Nexus.