Migrera arbetsbelastningar för Azure Kubernetes Service (AKS) och MySQL – flexibel server till stöd för tillgänglighetszoner

Den här guiden beskriver hur du migrerar en Azure Kubernetes Service- och MySQL Flexible Server-arbetsbelastning för att slutföra tillgänglighetszonens stöd för alla beroende tjänster. Fullständig lista över alla arbetsbelastningsberoenden finns i Arbetsbelastningstjänstberoenden.

Stöd för tillgänglighetszoner för den här arbetsbelastningen måste aktiveras när aks-klustret eller MySQL – flexibel server skapas. Om du vill ha stöd för tillgänglighetszoner för ett befintligt AKS-kluster och MySQL – flexibel server måste du distribuera om resurserna.

Den här migreringsvägledningen fokuserar främst på infrastruktur- och tillgänglighetsöverväganden för att köra följande arkitektur i Azure:

Beroenden för arbetsbelastningstjänst

För att ge fullständigt arbetsbelastningsstöd för tillgänglighetszoner måste varje tjänstberoende i arbetsbelastningen ha stöd för tillgänglighetszoner.

Det finns två metoder för typer av tjänster som stöds av tillgänglighetszoner: zonindelad eller zonredundant. De flesta tjänster stöder det ena eller det andra. I vissa fall finns det dock alternativ för att välja antingen en zonindelad eller zonredundant resurs för den tjänsten. Vi anger vilka tjänster som stöder zon- och zonredundanta resurser i följande rekommendationer. Vi anger också vilka tjänster som är globala och regionala.

Arkitekturen för AKS- och MySQL-arbetsbelastningen består av följande komponentberoenden:

Azure Kubernetes Service (AKS)

• Zonindelad : Systemnodpoolen och användarnodpoolerna är zonindelade när du i förväg väljer de zoner där nodpoolerna distribueras under skapandetiden. Vi rekommenderar att du i förväg väljer alla tre zoner för bättre återhämtning. Fler användarnodpooler som stöder tillgänglighetszoner kan läggas till i ett befintligt AKS-kluster och genom att ange ett värde för parametern zones .

• Zonredundant: Kubernetes-kontrollplanskomponenter som etcd, API-server, Scheduler och Controller Manager replikeras eller distribueras automatiskt mellan zoner.

  Kommentar

  Om du vill aktivera zonredundans för AKS-klusterkontrollplanskomponenterna måste du definiera din standardsystemnodpool med zoner när du skapar ett AKS-kluster. Om du lägger till fler zonindelade nodpooler i ett befintligt AKS-kluster som inte är zonindelade blir inte AKS-klustret zonredundant, eftersom den åtgärden inte distribuerar kontrollplanskomponenterna mellan zoner i efterhand.

Azure Database for MySQL – flexibel server

• Zonindelning: Zonindelad tillgänglighet innebär att en väntelägesserver alltid är tillgänglig inom samma zon som den primära servern. Även om det här alternativet minskar redundanstiden och nätverksfördröjningen är det mindre motståndskraftigt på grund av ett avbrott i en zon som påverkar både de primära servrarna och väntelägesservrarna.

• Zonredundant: Det zonredundanta tillgänglighetsläget innebär att en väntelägesserver alltid är tillgänglig inom en annan zon i samma region som den primära servern. Två zoner aktiveras för zonredundans för de primära servrarna och väntelägesservrarna. Vi rekommenderar den här konfigurationen för bättre återhämtning.

Azure Standard Load Balancer eller Azure Application Gateway

Standard Load Balancer

Information om överväganden som rör Standard Load Balancer-resurser finns i Lastbalanserare och tillgänglighetszoner.

• Zonredundant: Att välja zonredundans är det rekommenderade sättet att konfigurera klientdels-IP-adressen med din befintliga lastbalanserare. Den zonredundanta klientdelen motsvarar AKS-klustrets serverdelspool, som är distribuerad över flera zoner.

• Zonindelning: Om du fäster nodpoolerna på specifika zoner, till exempel zon 1 och 2, kan du välja zon 1 och 2 i förväg för klientdels-IP-adressen i den befintliga lastbalanseraren. Anledningen till att du kanske vill fästa nodpoolerna i specifika zoner kan bero på tillgängligheten för specialiserade SKU-serier för virtuella datorer, till exempel M-serien.

Azure Application Gateway

Användning av tillägget Ingress Controller för Application Gateway med ditt AKS-kluster stöds endast på Application Gateway v2 SKU:er (Standard och WAF). Mer information om ytterligare överväganden som rör Azure Application Gateway finns i Skala Application Gateway v2 och WAF v2.

Zonindelning: Om du vill använda fördelarna med tillgänglighetszoner rekommenderar vi att Application Gateway-resursen skapas i flera zoner, till exempel zon 1, 2 och 3. Välj alla tre zoner för bästa återhämtningsstrategi inom regionen. Men för att motsvara dina serverdelsnodpooler kan du fästa nodpoolerna på specifika zoner genom att välja zon 1 och 2 i förväg när du skapar din App Gateway-resurs. Anledningen till att du kanske vill fästa nodpoolerna på specifika zoner kan bero på tillgängligheten för specialiserade SKU-serier för virtuella datorer, till exempel M-series.

Zonredundant lagring (ZRS)

• Vi rekommenderar att AKS-klustret konfigureras med hanterade ZRS-diskar eftersom de är zonredundanta resurser. Volymer kan schemaläggas för alla zoner.

• Kubernetes är medveten om Azure-tillgänglighetszoner sedan version 1.12. Du kan distribuera ett PersistentVolumeClaim objekt som refererar till en Azure Managed Disk i ett AKS-kluster med flera zoner. Kubernetes tar hand om att schemalägga alla poddar som gör anspråk på denna PVC i rätt tillgänglighetszon.

• För Azure Database for SQL rekommenderar vi att data och loggfiler finns i zonredundant lagring (ZRS). Dessa filer replikeras till väntelägesservern via den replikering på lagringsnivå som är tillgänglig med ZRS.

Azure Firewall

Zonindelning: Om du vill använda fördelarna med tillgänglighetszoner rekommenderar vi att Azure Firewall-resursen skapas i flera zoner, till exempel zon 1, 2 och 3. Vi rekommenderar att du väljer alla tre zonerna för bästa återhämtningsstrategi inom regionen.

Azure Bastion

Regional: Azure Bastion distribueras i virtuella nätverk eller peer-kopplade virtuella nätverk och är associerat med en Azure-region. Mer information finns i Tillförlitlighet i Azure Bastion.

Azure Container Registry (ACR)

Zonredundant: Vi rekommenderar att du skapar ett zonredundant register på Premium-tjänstnivån. Du kan också skapa en zonredundant registerreplik genom att ange zoneRedundancy egenskapen för repliken. Information om hur du aktiverar zonredundans för din ACR finns i Aktivera zonredundans i Azure Container Registry för återhämtning och hög tillgänglighet.

Azure Cache for Redis

Zonredundant: Azure Cache for Redis stöder zonredundanta konfigurationer på Premium- och Enterprise-nivåerna. En zonredundant cache placerar sina noder i olika tillgänglighetszoner i samma region.

Microsoft Entra ID

Global: Microsoft Entra ID är en global tjänst med flera nivåer av intern redundans och automatisk återställning. Microsoft Entra-ID distribueras i över 30 datacenter runt om i världen som tillhandahåller tillgänglighetszoner där det finns. Det här antalet växer snabbt i takt med att fler regioner distribueras.

Azure Key Vault

Regional: Azure Key Vault distribueras i en region. För att upprätthålla hög hållbarhet för dina nycklar och hemligheter replikeras innehållet i ditt nyckelvalv inom regionen och till en sekundär region inom samma geografiska område.

Zonredundant: För Azure-regioner med tillgänglighetszoner och inget regionpar använder Key Vault zonredundant lagring (ZRS) för att replikera innehållet i ditt nyckelvalv tre gånger inom den enskilda platsen/regionen.

Överväganden för arbetsbelastning

Azure Kubernetes Service (AKS)

• Poddar kan kommunicera med andra poddar, oavsett vilken nod eller tillgänglighetszon podden hamnar i på noden. Ditt program kan få högre svarstid om poddarna finns i olika tillgänglighetszoner. Även om de extra svarstiderna mellan poddar förväntas ligga inom ett acceptabelt intervall för de flesta program, finns det programscenarier som kräver låg svarstid, särskilt för ett chattigt kommunikationsmönster mellan poddar.

• Vi rekommenderar att du testar ditt program för att säkerställa att det fungerar bra i olika tillgänglighetszoner.

• Av prestandaskäl så låg svarstid kan poddar finnas i samma datacenter i samma tillgänglighetszon. Om du vill samplaceera poddar i samma datacenter i samma tillgänglighetszon kan du skapa användarnodpooler med en unik zon och närhetsplaceringsgrupp. Du kan lägga till en närhetsplaceringsgrupp (PPG) i ett befintligt AKS-kluster genom att skapa en ny agentnodpool och ange PPG. Använd begränsningar för poddtopologispridning för att styra hur poddar sprids i DITT AKS-kluster över tillgänglighetszoner, noder och regioner.

• När poddar som kräver kommunikation med låg svarstid finns i samma tillgänglighetszon är kommunikationen mellan poddarna inte direkt. I stället kanaliseras poddkommunikation via en tjänst som definierar en logisk uppsättning poddar i ditt AKS-kluster. Poddar kan konfigureras för att kommunicera med AKS och kommunikationen till tjänsten lastbalanseras automatiskt till alla poddar som är medlemmar i tjänsten.

• För att dra nytta av tillgänglighetszoner innehåller nodpooler underliggande virtuella datorer som är zonindeliga resurser. För att stödja program som har olika beräknings- eller lagringskrav kan du skapa användarnodpooler med specifika VM-storlekar när du skapar användarnodpoolen.

  Du kan till exempel välja att använda Standard_M32ms under M-series för dina användarnoder eftersom mikrotjänsterna i ditt program kräver högt dataflöde, låg svarstid och minnesoptimerade VM-storlekar som ger höga vCPU-antal och stora mängder minne. Beroende på distributionsregionen kan du se att den här vm-storleken endast stöds i zon 1 och 2 när du väljer VM-storlek i Azure-portalen. Du kan acceptera den här återhämtningskonfigurationen som en kompromiss för höga prestanda.

• Du kan inte ändra storleken på den virtuella datorn för en nodpool när du har skapat den. Mer information om begränsningar för nodpooler finns i Begränsningar.

Azure Database for MySQL – flexibel server

Implikationen av att distribuera dina nodpooler i specifika zoner, till exempel zon 1 och 2, är att alla tjänstberoenden i ditt AKS-kluster också måste ha stöd för zon 1 och 2. I den här arbetsbelastningsarkitekturen har DITT AKS-kluster ett tjänstberoende på Azure Database for MySQL – flexibla servrar med zonåterhämtning. Du skulle välja zon 1 för din primära server och zon 2 för att väntelägesservern ska finnas tillsammans med dina AKS-användarnodpooler.

Azure Cache for Redis

• Azure Cache for Redis distribuerar noder i en zonredundant cache på ett resursallokeringssätt över de tillgänglighetszoner som du har valt.

• Du kan inte uppdatera en befintlig Premium-cache för att använda zonredundans. Om du vill använda zonredundans måste du återskapa Azure Cache for Redis.

• För att uppnå optimal återhämtning rekommenderar vi att du skapar Azure Cache for Redis med tre eller flera repliker så att du kan distribuera replikerna mellan tre tillgänglighetszoner.

Överväganden kring haveriberedskap

Tillgänglighetszoner används för bättre återhämtning för att uppnå hög tillgänglighet för din arbetsbelastning i den primära regionen för distributionen.

Haveriberedskap består av återställningsåtgärder och metoder som definierats i din affärskontinuitetsplan. Planen för affärskontinuitet beskriver både hur din arbetsbelastning återställs under en störande händelse och hur den återställs helt efter händelsen. Överväg att utöka distributionen till en alternativ region.

För programnivån läser du övervägandena för affärskontinuitet och haveriberedskap för AKS i den här artikeln.

• Överväg att köra flera AKS-kluster i alternativa regioner. Den alternativa regionen kan använda en sekundär parkopplad region. Eller om det inte finns någon regionparering för din primära region kan du välja en alternativ region baserat på dina överväganden för tillgängliga tjänster, kapacitet, geografisk närhet och datasuveränitet. Läs beslutsguiden för Azure-regioner. Granska även mönstret för distributionsstämpel.

• Du har möjlighet att konfigurera aktiv-aktiv, aktiv-standby, aktiv-passiv för dina AKS-kluster.

• För databasnivån omfattar haveriberedskapsfunktioner geo-redundanta säkerhetskopior med möjlighet att initiera geo-återställning och distribuera läsrepliker i en annan region.

• Under ett avbrott måste du bestämma om du vill initiera en återställning. Du behöver bara initiera återställningsåtgärder när avbrotten sannolikt kommer att pågå längre än arbetsbelastningens mål för återställningstid (RTO). Annars väntar du på tjänståterställning genom att kontrollera tjänststatusen på Instrumentpanelen för Azure Service Health. På bladet Service Health i Azure-portalen kan du visa alla meddelanden som är associerade med din prenumeration.

• När du initierar återställning med geo-återställningsfunktionen i Azure Database for MySQL skapas en ny databasserver med hjälp av säkerhetskopierade data som replikeras från en annan region.

Nästa steg

Läs mer om:

Azure-tjänster som stöder tillgänglighetszoner