Azure Kubernetes Service (AKS) en MySQL Flexible Server-workloads migreren naar ondersteuning voor beschikbaarheidszones

In deze handleiding wordt beschreven hoe u een Azure Kubernetes Service- en MySQL Flexible Server-workload migreert om ondersteuning voor beschikbaarheidszones voor alle afhankelijke services te voltooien. Zie Workloadserviceafhankelijkheden voor een volledige lijst met alle workloadafhankelijkheden.

Ondersteuning voor beschikbaarheidszones voor deze workload moet worden ingeschakeld tijdens het maken van uw AKS-cluster of MySQL Flexible Server. Als u ondersteuning voor beschikbaarheidszones voor een bestaand AKS-cluster en MySQL Flexible Server wilt, moet u deze resources opnieuw implementeren.

Deze migratierichtlijnen zijn voornamelijk gericht op de overwegingen voor infrastructuur en beschikbaarheid van het uitvoeren van de volgende architectuur in Azure:

Afhankelijkheden van workloadservice

Om volledige workloadondersteuning te bieden voor beschikbaarheidszones, moet elke serviceafhankelijkheid in de workload beschikbaarheidszones ondersteunen.

Er zijn twee benaderingen voor ondersteunde services voor beschikbaarheidszones: zonegebonden of zone-redundant. De meeste services ondersteunen een of meer. In sommige gevallen zijn er echter opties voor het kiezen van een zonegebonden of zone-redundante resource voor die service. We geven aan welke services zone-redundante en zone-redundante resources ondersteunen in de volgende aanbevelingen. We geven ook aan welke diensten wereldwijd en regionaal zijn.

De AKS- en MySQL-workloadarchitectuur bestaat uit de volgende onderdeelafhankelijkheden:

Azure Kubernetes Service (AKS)

• Zonegebonden : de systeemknooppuntgroep en gebruikersknooppuntgroepen zijn zonegebonden wanneer u de zones waarin de knooppuntgroepen worden geïmplementeerd tijdens het maken vooraf selecteert. U wordt aangeraden alle drie de zones vooraf te selecteren voor betere tolerantie. Meer gebruikersknooppuntgroepen die ondersteuning bieden voor beschikbaarheidszones kunnen worden toegevoegd aan een bestaand AKS-cluster en door een waarde voor de zones parameter op te geven.

• Zone-redundant: Onderdelen van het Kubernetes-besturingsvlak, zoals etcd, API-server, Scheduler en ControllerBeheer , worden automatisch gerepliceerd of verdeeld over zones.

  Notitie

  Als u zoneredundantie van de onderdelen van het AKS-clusterbesturingsvlak wilt inschakelen, moet u uw standaardsysteemknooppuntgroep met zones definiëren wanneer u een AKS-cluster maakt. Als u meer zonegebonden knooppuntgroepen toevoegt aan een bestaand niet-zonegebonden AKS-cluster, wordt het AKS-cluster niet zone-redundant, omdat met deze actie de onderdelen van het besturingsvlak niet worden verdeeld over zones na het feit.

Azure Database for MySQL Flexibele server

• Zonegebonden: De zonegebonden beschikbaarheidsmodus betekent dat een stand-byserver altijd beschikbaar is binnen dezelfde zone als de primaire server. Hoewel deze optie de failovertijd en netwerklatentie vermindert, is deze minder tolerant vanwege een storing in één zone die van invloed is op zowel de primaire als stand-byservers.

• Zone-redundant: de zone-redundante beschikbaarheidsmodus betekent dat een stand-byserver altijd beschikbaar is binnen een andere zone in dezelfde regio als de primaire server. Er worden twee zones ingeschakeld voor zoneredundantie voor de primaire en stand-byservers. We raden deze configuratie aan voor betere tolerantie.

Azure Standard Load Balancer of Azure-toepassing Gateway

Standard Load Balancer

Zie Load Balancer en Beschikbaarheidszones voor meer informatie over overwegingen met betrekking tot Standard Load Balancer-resources.

• Zone-redundant: het kiezen van zoneredundantie is de aanbevolen manier om uw Front-end-IP te configureren met uw bestaande Load Balancer. De zone-redundante front-end komt overeen met de back-endpool van het AKS-cluster, die over meerdere zones wordt verdeeld.

• Zonegebonden: Als u uw knooppuntgroepen vastzet aan specifieke zones zoals zone 1 en 2, kunt u zone 1 en 2 vooraf selecteren voor uw Front-end-IP in de bestaande Load Balancer. De reden waarom u uw knooppuntgroepen mogelijk wilt vastmaken aan specifieke zones, kan worden veroorzaakt door de beschikbaarheid van gespecialiseerde VM-SKU-reeksen, zoals M-serie.

Azure Application Gateway

Het gebruik van de invoegtoepassing Voor inkomend verkeer van Application Gateway met uw AKS-cluster wordt alleen ondersteund op Application Gateway v2-SKU's (Standard en WAF). Zie Application Gateway v2 en WAF v2 schalen voor meer overwegingen met betrekking tot Azure-toepassing Gateway.

Zonegebonden: Als u de voordelen van beschikbaarheidszones wilt gebruiken, raden we u aan om de Application Gateway-resource te maken in meerdere zones, zoals zone 1, 2 en 3. Selecteer alle drie de zones voor de beste strategie voor tolerantie binnen regio's. Als u echter wilt overeenkomen met uw back-endknooppuntgroepen, kunt u uw knooppuntgroepen vastmaken aan specifieke zones door zone 1 en 2 vooraf te selecteren tijdens het maken van uw App Gateway-resource. De reden waarom u uw knooppuntgroepen mogelijk wilt vastmaken aan specifieke zones, kan worden veroorzaakt door de beschikbaarheid van gespecialiseerde VM-SKU-reeksen, zoals M-series.

Zoneredundante opslag (ZRS, zone redundant storage)

• U wordt aangeraden uw AKS-cluster te configureren met beheerde ZRS-schijven omdat ze zone-redundante resources zijn. Volumes kunnen worden gepland op alle zones.

• Kubernetes is op de hoogte van Azure-beschikbaarheidszones sinds versie 1.12. U kunt een PersistentVolumeClaim object implementeren dat verwijst naar een Azure Managed Disk in een AKS-cluster met meerdere zones. Kubernetes zorgt voor het plannen van pods die dit PVC in de juiste beschikbaarheidszone claimen.

• Voor Azure Database for SQL raden we aan dat de gegevens en logboekbestanden worden gehost in zone-redundante opslag (ZRS). Deze bestanden worden gerepliceerd naar de stand-byserver via de replicatie op opslagniveau die beschikbaar is met ZRS.

Azure Firewall

Zonegebonden: Als u de voordelen van beschikbaarheidszones wilt gebruiken, raden we u aan om de Azure Firewall-resource te maken in meerdere zones, zoals zone 1, 2 en 3. U wordt aangeraden alle drie de zones te selecteren voor de beste strategie voor tolerantie binnen regio's.

Azure Bastion

Regionaal: Azure Bastion wordt geïmplementeerd binnen VNets of gekoppelde VNets en is gekoppeld aan een Azure-regio. Zie de veelgestelde vragen over Bastion voor meer informatie.

Azure Container Registry (ACR)

Zone-redundant: u wordt aangeraden een zone-redundant register te maken in de Premium-servicelaag. U kunt ook een zoneredundante registerreplica maken door de zoneRedundancy eigenschap voor de replica in te stellen. Zie Zoneredundantie inschakelen in Azure Container Registry voor tolerantie en hoge beschikbaarheid voor meer informatie over het inschakelen van zoneredundantie voor uw ACR.

Azure Cache voor Redis

Zone-redundant: Azure Cache voor Redis ondersteunt zone-redundante configuraties in de Premium- en Enterprise-lagen. Een zone-redundante cache plaatst de knooppunten in verschillende beschikbaarheidszones in dezelfde regio.

Microsoft Entra ID

Globaal: Microsoft Entra ID is een wereldwijde service met meerdere niveaus van interne redundantie en automatische herstelbaarheid. Microsoft Entra ID wordt geïmplementeerd in meer dan 30 datacenters over de hele wereld die beschikbaarheidszones bieden waar aanwezig. Dit aantal groeit snel naarmate er meer regio's worden geïmplementeerd.

Azure Key Vault

Regionaal: Azure Key Vault wordt geïmplementeerd in een regio. Als u een hoge duurzaamheid van uw sleutels en geheimen wilt behouden, wordt de inhoud van uw sleutelkluis gerepliceerd binnen de regio en naar een secundaire regio binnen dezelfde geografie.

Zone-redundant: Voor Azure-regio's met beschikbaarheidszones en geen regiopaar gebruikt Key Vault zone-redundante opslag (ZRS) om de inhoud van uw sleutelkluis drie keer binnen de ene locatie/regio te repliceren.

Overwegingen voor workload

Azure Kubernetes Service (AKS)

• Pods kunnen communiceren met andere pods, ongeacht het knooppunt of de beschikbaarheidszone waarin de pod op het knooppunt terechtkomt. Uw toepassing kan een hogere reactietijd ervaren als de pods zich in verschillende beschikbaarheidszones bevinden. Hoewel de extra retourlatenties tussen pods naar verwachting binnen een acceptabel bereik vallen voor de meeste toepassingen, zijn er toepassingsscenario's waarvoor lage latentie is vereist, met name voor een chatachtig communicatiepatroon tussen pods.

• U wordt aangeraden uw toepassing te testen om ervoor te zorgen dat deze goed presteert in verschillende beschikbaarheidszones.

• Om prestatieredenen, zoals lage latentie, kunnen pods zich in hetzelfde datacenter binnen dezelfde beschikbaarheidszone bevinden. Als u pods in hetzelfde datacenter in dezelfde beschikbaarheidszone wilt zoeken, kunt u gebruikersknooppuntgroepen maken met een unieke zone en nabijheidsplaatsingsgroep. U kunt een nabijheidsplaatsingsgroep (PPG) toevoegen aan een bestaand AKS-cluster door een nieuwe agentknooppuntgroep te maken en de PPG op te geven. Gebruik Beperkingen voor spreiding van podtopologie om te bepalen hoe pods worden verspreid in uw AKS-cluster in beschikbaarheidszones, knooppunten en regio's.

• Nadat pods waarvoor communicatie met lage latentie is vereist, zich in dezelfde beschikbaarheidszone bevinden, zijn de communicatie tussen de pods niet direct. In plaats daarvan worden podcommunicatie gekanaald via een service die een logische set pods in uw AKS-cluster definieert. Pods kunnen worden geconfigureerd om te communiceren met AKS en de communicatie met de service wordt automatisch verdeeld over alle pods die lid zijn van de service.

• Als u wilt profiteren van beschikbaarheidszones, bevatten knooppuntgroepen onderliggende VM's die zonegebonden resources zijn. Ter ondersteuning van toepassingen met verschillende reken- of opslagvereisten kunt u gebruikersknooppuntgroepen maken met specifieke VM-grootten wanneer u de gebruikersknooppuntgroep maakt.

  U kunt bijvoorbeeld besluiten om de Standard_M32msM-series onderliggende knooppunten voor uw gebruikersknooppunten te gebruiken, omdat voor de microservices in uw toepassing hoge doorvoer, lage latentie en geoptimaliseerde VM-grootten met hoge vCPU-aantallen en grote hoeveelheden geheugen nodig zijn. Afhankelijk van de implementatieregio ziet u, wanneer u de VM-grootte selecteert in Azure Portal, mogelijk dat deze VM-grootte alleen wordt ondersteund in zone 1 en 2. U kunt deze tolerantieconfiguratie accepteren als een compromis voor hoge prestaties.

• U kunt de VM-grootte van een knooppuntgroep niet wijzigen nadat u deze hebt gemaakt. Zie Beperkingen voor meer informatie over beperkingen van knooppuntgroepen.

Azure Database for MySQL Flexibele server

De implicatie van het implementeren van uw knooppuntgroepen in specifieke zones, zoals zone 1 en 2, is dat alle serviceafhankelijkheden van uw AKS-cluster ook zone 1 en 2 moeten ondersteunen. In deze workloadarchitectuur heeft uw AKS-cluster een serviceafhankelijkheid van Azure Database for MySQL Flexibele servers met zonetolerantie. U selecteert zone 1 voor uw primaire server en zone 2 om uw stand-byserver te koppelen aan uw AKS-gebruikersknooppuntgroepen.

Azure Cache voor Redis

• Azure Cache voor Redis knooppunten in een zone-redundante cache op een round robin-manier distribueert over de beschikbaarheidszones die u hebt geselecteerd.

• U kunt een bestaande Premium-cache niet bijwerken om zoneredundantie te gebruiken. Als u zoneredundantie wilt gebruiken, moet u de Azure Cache voor Redis opnieuw maken.

• Voor optimale tolerantie raden we u aan uw Azure Cache voor Redis te maken met drie of meer replica's, zodat u de replica's over drie beschikbaarheidszones kunt distribueren.

Overwegingen voor herstel na noodgeval

Beschikbaarheidszones worden gebruikt voor betere tolerantie om een hoge beschikbaarheid van uw workload binnen de primaire regio van uw implementatie te bereiken.

Herstel na noodgevallen bestaat uit herstelbewerkingen en -procedures die zijn gedefinieerd in uw bedrijfscontinuïteitsplan. Uw bedrijfscontinuïteitsplan heeft betrekking op de wijze waarop uw workload wordt hersteld tijdens een verstorende gebeurtenis en hoe deze volledig herstelt na de gebeurtenis. Overweeg uw implementatie uit te breiden naar een alternatieve regio.

Raadpleeg voor uw toepassingslaag de overwegingen voor bedrijfscontinuïteit en herstel na noodgevallen voor AKS in dit artikel.

• Overweeg om meerdere AKS-clusters in alternatieve regio's uit te voeren. De alternatieve regio kan een secundair gekoppelde regio gebruiken. Of, als er geen regiokoppeling is voor uw primaire regio, kunt u een alternatieve regio selecteren op basis van uw overweging voor beschikbare services, capaciteit, geografische nabijheid en gegevenssoevereine. Raadpleeg de beslissingshandleiding voor Azure-regio's. Controleer ook het patroon van de implementatiestempel.

• U hebt de mogelijkheid om actief-actief, actief-stand-by, actief-passief te configureren voor uw AKS-clusters.

• Voor uw databaselaag bevatten functies voor herstel na noodgevallen geografisch redundante back-ups met de mogelijkheid om geo-herstel en het implementeren van leesreplica's in een andere regio te initiëren.

• Tijdens een storing moet u beslissen of u een herstelbewerking wilt initiëren. U moet herstelbewerkingen alleen initiëren wanneer de storing waarschijnlijk langer duurt dan de beoogde hersteltijd (RTO) van uw workload. Anders wacht u op serviceherstel door de servicestatus te controleren op het Azure Service Health-dashboard. Op de blade ServiceStatus van Azure Portal kunt u alle meldingen bekijken die zijn gekoppeld aan uw abonnement.

• Wanneer u herstel uitvoert met de functie geo-herstel in Azure Database for MySQL, wordt er een nieuwe databaseserver gemaakt met behulp van back-upgegevens die vanuit een andere regio worden gerepliceerd.

Volgende stappen

Meer informatie over:

Azure-services die ondersteuning bieden voor Beschikbaarheidszones)