Eseguire la migrazione dei carichi di lavoro del server flessibile servizio Azure Kubernetes (AKS) e MySQL al supporto della zona di disponibilità
Questa guida descrive come eseguire la migrazione di un carico di lavoro server flessibile servizio Azure Kubernetes e MySQL per completare il supporto della zona di disponibilità in tutti i servizi dipendenti. Per un elenco completo di tutte le dipendenze del carico di lavoro, vedere Dipendenze del servizio del carico di lavoro.
Il supporto della zona di disponibilità per questo carico di lavoro deve essere abilitato durante la creazione del cluster del servizio Azure Kubernetes o del server flessibile MySQL. Se si vuole il supporto della zona di disponibilità per un cluster del servizio Azure Kubernetes esistente e un server flessibile MySQL, sarà necessario ridistribuire tali risorse.
Questa guida alla migrazione è incentrata principalmente sulle considerazioni sull'infrastruttura e sulla disponibilità relative all'esecuzione dell'architettura seguente in Azure:
Dipendenze del servizio del carico di lavoro
Per fornire il supporto completo del carico di lavoro per le zone di disponibilità, ogni dipendenza del servizio nel carico di lavoro deve supportare le zone di disponibilità.
Esistono due tipi di approcci di servizi supportati per la zona di disponibilità: zonal o con ridondanza della zona. La maggior parte dei servizi supporta uno o l'altro. In alcuni casi, tuttavia, sono disponibili opzioni per scegliere una risorsa zonale o con ridondanza della zona per tale servizio. I servizi che supportano le risorse zonali e con ridondanza della zona sono indicate nelle raccomandazioni seguenti. Vengono inoltre indicati i servizi globali e regionali.
L'architettura del carico di lavoro del servizio Azure Kubernetes e MySQL è costituita dalle dipendenze dei componenti seguenti:
Servizio Azure Kubernetes (AKS)
Zonal : il pool di nodi di sistema e i pool di nodi utente sono di zona quando si pre-selezionano le zone in cui vengono distribuiti i pool di nodi durante la creazione. È consigliabile pre-selezionare tutte e tre le zone per migliorare la resilienza. Altri pool di nodi utente che supportano le zone di disponibilità possono essere aggiunti a un cluster del servizio Azure Kubernetes esistente e fornendo un valore per il
zonesparametro .Ridondanza della zona: i componenti del piano di controllo Kubernetes, ad esempio etcd, server API, Utilità di pianificazione e Gestione controller vengono replicati o distribuiti automaticamente tra le zone.
Nota
Per abilitare la ridondanza della zona dei componenti del piano di controllo del cluster del servizio Azure Kubernetes, è necessario definire il pool di nodi di sistema predefinito con zone quando si crea un cluster del servizio Azure Kubernetes. L'aggiunta di più pool di nodi di zona a un cluster del servizio Azure Kubernetes non di zona esistente non rende ridondante la zona del cluster del servizio Azure Kubernetes, perché tale azione non distribuisce i componenti del piano di controllo tra le zone dopo il fatto.
Server flessibile di Database di Azure per MySQL
Zona: la modalità di disponibilità di zona indica che un server di standby è sempre disponibile all'interno della stessa zona del server primario. Anche se questa opzione riduce il tempo di failover e la latenza di rete, è meno resiliente a causa di un'interruzione della zona che influisce sia sui server primario che su quello di standby.
Con ridondanza della zona: la modalità di disponibilità con ridondanza della zona indica che un server standby è sempre disponibile all'interno di un'altra zona nella stessa area del server primario. Due zone verranno abilitate per la ridondanza della zona per i server primario e standby. Questa configurazione è consigliata per migliorare la resilienza.
Gateway di Load Balancer Standard o di app Azure di Azure
Load Balancer Standard
Per informazioni sulle considerazioni relative alle risorse di Load Balancer Standard, vedere Load Balancer e zone di disponibilità.
Ridondanza della zona: la scelta della ridondanza della zona è il modo consigliato per configurare l'indirizzo IP front-end con il servizio di bilanciamento del carico esistente. Il front-end con ridondanza della zona corrisponde al pool back-end del cluster del servizio Azure Kubernetes, distribuito tra più zone.
Zona: se si stanno aggiungendo i pool di nodi a zone specifiche, ad esempio la zona 1 e 2, è possibile pre-selezionare la zona 1 e 2 per l'indirizzo IP front-end nel servizio di bilanciamento del carico esistente. Il motivo per cui è consigliabile aggiungere i pool di nodi a zone specifiche potrebbe essere dovuto alla disponibilità di serie di SKU di macchine virtuali specializzate, ad esempio serie M.
Gateway applicazione di Azure
L'uso del componente aggiuntivo Controller in ingresso gateway applicazione con il cluster del servizio Azure Kubernetes è supportato solo in gateway applicazione SKU v2 (Standard e WAF). Per altre considerazioni relative al gateway di app Azure lication, vedere Scalabilità gateway applicazione v2 e WAF v2.
Zonal: per usare i vantaggi delle zone di disponibilità, è consigliabile creare la risorsa gateway applicazione in più zone, ad esempio la zona 1, 2 e 3. Selezionare tutte e tre le zone per la migliore strategia di resilienza all'interno dell'area. Tuttavia, per corrispondere ai pool di nodi back-end, è possibile aggiungere i pool di nodi a zone specifiche pre-selezione selezionando la zona 1 e 2 durante la creazione della risorsa gateway app. Il motivo per cui è possibile aggiungere i pool di nodi a zone specifiche potrebbe essere dovuto alla disponibilità di serie di SKU di macchine virtuali specializzate, M-seriesad esempio .
Archiviazione con ridondanza della zona (ZRS)
È consigliabile configurare il cluster del servizio Azure Kubernetes con dischi con ridondanza della zona perché sono risorse con ridondanza della zona. I volumi possono essere pianificati in tutte le zone.
Kubernetes è a conoscenza delle zone di disponibilità di Azure dalla versione 1.12. È possibile distribuire un
PersistentVolumeClaimoggetto che fa riferimento a un disco gestito di Azure in un cluster del servizio Azure Kubernetes a più zone. Kubernetes si occuperà della pianificazione di tutti i pod che dichiarano questo PVC nella zona di disponibilità corretta.Per Database di Azure per SQL, è consigliabile ospitare i dati e i file di log nell'archiviazione con ridondanza della zona. Questi file vengono replicati nel server standby tramite la replica a livello di archiviazione disponibile con archiviazione con ridondanza della zona.
Firewall di Azure
Zonal: per usare i vantaggi delle zone di disponibilità, è consigliabile creare la risorsa Firewall di Azure in più zone, ad esempio la zona 1, 2 e 3. È consigliabile selezionare tutte e tre le zone per la migliore strategia di resilienza all'interno dell'area.
Azure Bastion
Area: Azure Bastion viene distribuito all'interno di reti virtuali o reti virtuali con peering ed è associato a un'area di Azure. Per altre informazioni, vedere Domande frequenti su Bastion.
Registro Azure Container
Ridondanza della zona: è consigliabile creare un registro con ridondanza della zona nel livello di servizio Premium. È anche possibile creare una replica del Registro di sistema con ridondanza della zona impostando la zoneRedundancy proprietà per la replica. Per informazioni su come abilitare la ridondanza della zona per il Registro Azure Container, vedere Abilitare la ridondanza della zona in Registro Azure Container per la resilienza e la disponibilità elevata.
Cache Redis di Azure
Ridondanza della zona: cache di Azure per Redis supporta le configurazioni con ridondanza della zona nei livelli Premium ed Enterprise. Una cache con ridondanza della zona inserisce i nodi in zone di disponibilità diverse nella stessa area.
Microsoft Entra ID
Globale: Microsoft Entra ID è un servizio globale con più livelli di ridondanza interna e recuperabilità automatica. Microsoft Entra ID viene distribuito in oltre 30 data center in tutto il mondo che forniscono zone di disponibilità in cui sono presenti. Questo numero cresce rapidamente man mano che vengono distribuite più aree.
Insieme di credenziali chiave di Azure
Area: Azure Key Vault viene distribuito in un'area. Per mantenere una durabilità elevata delle chiavi e dei segreti, il contenuto dell'insieme di credenziali delle chiavi viene replicato all'interno dell'area e in un'area secondaria all'interno della stessa area geografica.
Ridondanza della zona: per le aree di Azure con zone di disponibilità e nessuna coppia di aree, Key Vault usa l'archiviazione con ridondanza della zona per replicare il contenuto dell'insieme di credenziali delle chiavi tre volte all'interno della singola posizione/area.
Considerazioni sul carico di lavoro
Servizio Azure Kubernetes (AKS)
I pod possono comunicare con altri pod, indipendentemente dal nodo o dalla zona di disponibilità in cui il pod si trova nel nodo. L'applicazione potrebbe riscontrare tempi di risposta più elevati se i pod si trovano in zone di disponibilità diverse. Anche se le latenze di round trip aggiuntive tra i pod rientrano in un intervallo accettabile per la maggior parte delle applicazioni, esistono scenari di applicazione che richiedono bassa latenza, soprattutto per un modello di comunicazione tra pod.
È consigliabile testare l'applicazione per assicurarsi che funzioni correttamente tra le zone di disponibilità.
Per motivi di prestazioni di tale bassa latenza, i pod possono trovarsi nello stesso data center all'interno della stessa zona di disponibilità. Per individuare i pod nello stesso data center all'interno della stessa zona di disponibilità, è possibile creare pool di nodi utente con un gruppo di posizionamento di prossimità e zona univoco. È possibile aggiungere un gruppo di posizionamento di prossimità (PPG) a un cluster del servizio Azure Kubernetes esistente creando un nuovo pool di nodi agente e specificando il PPG. Usare i vincoli di distribuzione della topologia pod per controllare la modalità di distribuzione dei pod nel cluster del servizio Azure Kubernetes tra zone di disponibilità, nodi e aree.
Dopo che i pod che richiedono comunicazioni a bassa latenza si trovano nella stessa zona di disponibilità, le comunicazioni tra i pod non sono dirette. Le comunicazioni dei pod vengono invece incanalate tramite un servizio che definisce un set logico di pod nel cluster del servizio Azure Kubernetes. I pod possono essere configurati per comunicare con il servizio Azure Kubernetes e la comunicazione con il servizio verrà automaticamente bilanciata con tutti i pod membri del servizio.
Per sfruttare i vantaggi delle zone di disponibilità, i pool di nodi contengono macchine virtuali sottostanti che sono risorse di zona. Per supportare applicazioni con esigenze di calcolo o archiviazione diverse, è possibile creare pool di nodi utente con dimensioni di vm specifiche quando si crea il pool di nodi utente.
Ad esempio, è possibile decidere di usare l'oggetto
Standard_M32msM-seriesunder per i nodi utente perché i microservizi nell'applicazione richiedono velocità effettiva elevata, bassa latenza e dimensioni di macchine virtuali ottimizzate per la memoria che forniscono conteggi di vCPU elevati e grandi quantità di memoria. A seconda dell'area di distribuzione, quando si selezionano le dimensioni della macchina virtuale nella portale di Azure, è possibile che questa dimensione della macchina virtuale sia supportata solo nella zona 1 e 2. È possibile accettare questa configurazione di resilienza come compromesso per prestazioni elevate.Non è possibile modificare le dimensioni della macchina virtuale di un pool di nodi dopo averlo creato. Per altre informazioni sulle limitazioni del pool di nodi, vedere Limitazioni.
Server flessibile di Database di Azure per MySQL
L'implicazione della distribuzione dei pool di nodi in zone specifiche, ad esempio la zona 1 e 2, è che tutte le dipendenze del servizio del cluster del servizio Azure Kubernetes devono supportare anche la zona 1 e 2. In questa architettura del carico di lavoro il cluster del servizio Azure Kubernetes ha una dipendenza dai server flessibili Database di Azure per MySQL con resilienza della zona. Selezionare la zona 1 per il server primario e la zona 2 per il server di standby in modo che si trovi con i pool di nodi utente del servizio Azure Kubernetes.
Cache Redis di Azure
cache di Azure per Redis distribuisce i nodi in una cache con ridondanza della zona in modo round robin sulle zone di disponibilità selezionate.
Non è possibile aggiornare una cache Premium esistente per usare la ridondanza della zona. Per usare la ridondanza della zona, è necessario ricreare il cache di Azure per Redis.
Per ottenere una resilienza ottimale, è consigliabile creare il cache di Azure per Redis con tre o più repliche in modo da poter distribuire le repliche tra tre zone di disponibilità.
Considerazioni sul ripristino di emergenza
Le zone di disponibilità vengono usate per migliorare la resilienza per ottenere una disponibilità elevata del carico di lavoro all'interno dell'area primaria della distribuzione.
Il ripristino di emergenza è costituito da operazioni e procedure di ripristino definite nel piano di continuità aziendale. Il piano di continuità aziendale risolve sia il modo in cui il carico di lavoro viene ripristinato durante un evento di interruzione sia il modo in cui viene ripristinato completamente dopo l'evento. Valutare la possibilità di estendere la distribuzione a un'area alternativa.
Per il livello applicazione, vedere le considerazioni sulla continuità aziendale e sul ripristino di emergenza per il servizio Azure Kubernetes in questo articolo.
Prendere in considerazione l'esecuzione di più cluster del servizio Azure Kubernetes in aree alternative. L'area alternativa può usare un'area associata secondaria. In alternativa, in cui non è presente alcuna associazione di aree per l'area primaria, è possibile selezionare un'area alternativa in base alle considerazioni relative a servizi, capacità, prossimità geografica e sovranità dei dati disponibili. Consultare la guida alle decisioni sulle aree di Azure. Esaminare anche il modello di stamp di distribuzione.
È possibile configurare active-active-standby e active-passive per i cluster del servizio Azure Kubernetes.
Per il livello di database, le funzionalità di ripristino di emergenza includono backup con ridondanza geografica con la possibilità di avviare il ripristino geografico e distribuire repliche in lettura in un'area diversa.
Durante un'interruzione, è necessario decidere se avviare un ripristino. Sarà necessario avviare le operazioni di ripristino solo quando è probabile che l'interruzione dura più a lungo dell'obiettivo del tempo di ripristino (RTO) del carico di lavoro. In caso contrario, si attenderà il ripristino del servizio controllando lo stato del servizio nel dashboard di integrità dei servizi di Azure. Nel pannello Integrità dei servizi della portale di Azure è possibile visualizzare tutte le notifiche associate alla sottoscrizione.
Quando si avvia il ripristino con la funzionalità di ripristino geografico in Database di Azure per MySQL, viene creato un nuovo server di database usando i dati di backup replicati da un'altra area.
Passaggi successivi
Altre informazioni su: