Migrieren der Workloads von Azure Kubernetes Service (AKS) und MySQL – Flexible Server zur Unterstützung von Verfügbarkeitszonen

In diesem Leitfaden wird beschrieben, wie Sie die Workloads von Azure Kubernetes Service und MySQL Flexibler Server migrieren, um die Unterstützung der Verfügbarkeitszone für alle abhängigen Dienste abzuschließen. Eine vollständige Liste aller Workloadabhängigkeiten finden Sie unter Workloaddienstabhängigkeiten.

Die Unterstützung der Verfügbarkeitszone für diesen Workload muss während der Erstellung ihres AKS-Clusters oder Ihres MySQL – Flexibler Server aktiviert werden. Wenn Sie die Unterstützung der Verfügbarkeitszone für einen vorhandenen AKS-Cluster und für MySQL – Flexibler Server wünschen, müssen Sie diese Ressourcen erneut bereitstellen.

Im Zentrum dieses Migrationsleitfadens stehen hauptsächlich die Überlegungen zur Infrastruktur und zur Verfügbarkeit der Ausführung der folgenden Architektur in Azure:

Workloaddienstabhängigkeiten

Um vollständige Workloadunterstützung für Verfügbarkeitszonen bereitzustellen, muss jede Dienstabhängigkeit in dem Workload Verfügbarkeitszonen unterstützen.

Es gibt zwei verschiedene Ansätze für Dienste mit Verfügbarkeitszonenunterstützung: zonal oder zonenredundant. Die meisten Dienste unterstützen den einen oder den anderen. In einigen Fällen gibt es jedoch Optionen für die Auswahl einer zonalen- oder zonenredundanten Ressource für diesen Dienst. In den Empfehlungen unten wird angegeben, welche Dienste zonale und zonenredundante Ressourcen unterstützen. Darüber hinaus wird angegeben, welche Dienste global und welche regional sind.

Die AKS- und MySQL-Workloadarchitektur besteht aus den folgenden Komponentenabhängigkeiten:

Azure Kubernetes Service (AKS)

• Zonal: Der Systemknotenpool und die Benutzerknotenpools sind zonal, wenn Sie zu den Zonen, in denen die Knotenpools während der Erstellung bereitgestellt werden, eine Vorauswahl treffen. Es wird empfohlen, dass Sie im Sinne einer besseren Resilienz zu allen drei Zonen eine Vorauswahl treffen. Weitere Benutzerknotenpools, die Verfügbarkeitszonen unterstützen, können einem vorhandenen AKS-Cluster hinzugefügt werden, indem ein Wert für den Parameter zones angegeben wird.

• Zonenredundant: Kubernetes-Steuerungsebenenkomponenten wie etcd, API-Server, Scheduler und Controller-Manager werden automatisch repliziert oder über Zonen verteilt.

  Hinweis

  Zum Aktivieren der Zonenredundanz der Kontrollebenenkomponenten des AKS-Clusters müssen Sie ihren Standard-Systemknotenpool beim Erstellen eines AKS-Clusters mit Zonen definieren. Durch das Hinzufügen weiterer Zonenknotenpools zu einem vorhandenen nicht zonalen AKS-Cluster wird der AKS-Cluster nicht zonenredundant, da die Komponenten der Steuerelementebene durch diese Aktion nicht im Nachhinein über Zonen verteilt werden.

Azure Database for MySQL Flexible Server

• Zonal: Der Verfügbarkeitsmodus „Zonal“ bedeutet, dass ein Standbyserver immer innerhalb derselben Zone als primärer Server verfügbar ist. Während diese Option die Failoverzeit und die Netzwerklatenz reduziert, ist sie aufgrund eines einzelnen Zonenausfalls, der sowohl die primären als auch die Standbyserver beeinträchtigt, weniger widerstandsfähig.

• Zonenredundant: Der zonenredundante Verfügbarkeitsmodus bedeutet, dass ein Standbyserver immer in einer anderen Zone in derselben Region wie der primäre Server verfügbar ist. Zwei Zonen werden für die Zonenredundanz der primären und Standbyserver aktiviert. Diese Konfiguration wird im Sinne einer besseren Resilienz empfohlen.

Azure Load Balancer Standard oder Azure Application Gateway

Load Balancer Standard

Informationen zu Überlegungen im Zusammenhang mit Load Balancer Standard-Ressourcen finden Sie unter Load Balancer und Verfügbarkeitszonen.

• Zonenredundant: Die Auswahl der Zonenredundanz ist der Weg, der zur Konfiguration Ihrer Frontend-IP mit Ihrem vorhandenen Load Balancer empfohlen wird. Das zonenredundante Front-End entspricht dem AKS-Cluster-Back-End-Pool, der über mehrere Zonen verteilt wird.

• Zonal: Wenn Sie Ihre Knotenpools an bestimmte Zonen wie Zone 1 und 2 anheften, können Sie Zone 1 und 2 für Ihre Frontend-IP im vorhandenen Load Balancer im Voraus auswählen. Der Grund dafür, dass Sie Ihre Knotenpools ggf. an bestimmte Zonen anheften möchten, kann auf die Verfügbarkeit spezialisierter VM-SKU-Serien wie z. B. der M-Serie zurückzuführen sein.

Azure Application Gateway

Die Verwendung des Application Gateway-Eingangsdatencontroller-Add-Ons mit Ihrem AKS-Cluster wird nur für Application Gateway v2 SKUs (Standard und WAF) unterstützt. Weitere Überlegungen zu Azure Application Gateway finden Sie unter Skalierung von Application Gateway v2 und WAF v2.

Zonal: Um die Vorteile von Verfügbarkeitszonen zu nutzen, empfehlen wir, die Application Gateway-Ressource in mehreren Zonen zu erstellen, z. B. in den Zonen 1, 2 und 3. Wählen Sie für die beste Resilienzstrategie innerhalb der Region alle drei Zonen aus. Um Jedoch Ihren Back-End-Knotenpools zu entsprechen, können Sie Ihre Knotenpools an bestimmte Zonen anheften, indem Sie Zone 1 und 2 während der Erstellung Ihrer App-Gateway-Ressource vorab auswählen. Der Grund dafür, dass Sie Ihre Knotenpools ggf. an bestimmte Zonen anheften möchten, kann auf die Verfügbarkeit spezialisierter VM-SKU-Serien wie z. B. der M-series zurückzuführen sein.

Zonenredundanter Speicher (ZRS)

• Es wird empfohlen, Ihr AKS-Cluster mit verwalteten ZRS-Datenträgern zu konfigurieren, da es sich dabei um zonenredundante Ressourcen handelt. Volumes können in allen Zonen geplant werden.

• Kubernetes kennt Azure-Verfügbarkeitszonen seit Version 1.12. Sie können ein PersistentVolumeClaim-Objekt bereitstellen, das auf einen in Azure verwalteten Datenträger in einem Multizonen-AKS-Cluster verweist. Kubernetes kümmert sich um die Zeitplanung derjenigen Pods, die dieses PVC in der richtigen Verfügbarkeitszone in Anspruch nehmen.

• Für Azure-Datenbank für SQL empfehlen wir, die Daten und Protokolldateien in einem zonenredundanten Speicher (ZRS) zu hosten. Die Dateien werden mit der bei ZRS verfügbaren Replikation auf Speicherebene auf den Standbyserver repliziert.

Azure Firewall

Zonal: Um die Vorteile von Verfügbarkeitszonen zu nutzen, wird empfohlen, die Azure Firewall-Ressource in mehreren Zonen zu erstellen, z. B. in den Zonen 1, 2 und 3. Es wird empfohlen, für die beste Resilienzstrategie innerhalb der Region alle drei Zonen auszuwählen.

Azure Bastion

Regional: Azure Bastion wird innerhalb von VNets oder VNets mit Peering bereitgestellt und ist einer Azure-Region zugeordnet. Weitere Informationen finden Sie unter Zuverlässigkeit in Azure Bastion.

Azure Container Registry (ACR)

Zonenredundant: Es wird empfohlen, eine zonenredundante Registrierung auf der Premium-Dienstebene zu erstellen. Sie können auch ein zonenredundantes Registrierungsreplikat erstellen, indem Sie die Eigenschaft zoneRedundancy für das Replikat festlegen. Informationen zum Aktivieren der Zonenredundanz für Ihr ACR finden Sie unter Aktivieren der Zonenredundanz in Azure Container Registry für Resilienz und hohe Verfügbarkeit.

Azure Cache for Redis

Zonenredundant: Zonenredundante Konfigurationen werden von Azure Cache for Redis in den Tarifen „Premium“ und „Enterprise“ unterstützt. Bei einem zonenredundanten Cache können die zugehörigen Knoten in unterschiedlichen Azure-Verfügbarkeitszonen derselben Region platziert werden.

Microsoft Entra ID

Global: Microsoft Entra ID ist ein globaler Dienst mit mehreren Ebenen interner Redundanz und automatischer Wiederherstellbarkeit. Microsoft Entra ID wird in über 30 Rechenzentren auf der ganzen Welt bereitgestellt, die, sofern vorhanden, Verfügbarkeitszonen bereitstellen. Diese Zahl wächst schnell, da mehr Regionen bereitgestellt werden.

Azure Key Vault

Regional: Azure Key Vault wird in einer Region bereitgestellt. Um die Dauerhaftigkeit Ihrer Schlüssel und geheimen Schlüssel zu wahren, wird der Inhalt Ihres Schlüsseltresors innerhalb der Region sowie in eine sekundäre Region innerhalb desselben geografischen Gebiets repliziert.

Zonenredundant: Bei Azure-Regionen mit Verfügbarkeitszonen und ohne Regionspaar verwendet Key Vault zonenredundante Speicher (ZRS), um den Inhalt Ihres Schlüsseltresors dreimal innerhalb des einzelnen Standorts/der Region zu replizieren.

Überlegungen zum Workload

Azure Kubernetes Service (AKS)

• Pods können mit anderen Pods kommunizieren, unabhängig von dem Knoten oder der Verfügbarkeitszone, in dem bzw. der der Pod auf dem Knoten ankommt. Ihre Anwendung hat u. U. eine höhere Reaktionszeit, wenn sich die Pods in verschiedenen Verfügbarkeitszonen befinden. Während erwartet wird, dass die zusätzlichen Roundtriplatenzen zwischen Pods bei den meisten Anwendungen in einen akzeptablen Bereich fallen, gibt es Anwendungsszenarien, die eine niedrige Latenz erfordern, insbesondere bei einem intensiven Kommunikationsmuster zwischen Pods.

• Es wird empfohlen, Ihre Anwendung zu testen, um sicherzustellen, dass sie über Verfügbarkeitszonen hinweg gut funktioniert.

• Aus Leistungsgründen, wie z. B. bei einer geringen Latenz, können sich Pods in demselben Rechenzentrum innerhalb derselben Verfügbarkeitszone befinden. Um Pods im gleichen Rechenzentrum innerhalb derselben Verfügbarkeitszone zu finden, können Sie Benutzerknotenpools mit einer eindeutigen Zonen- und Näherungsplatzierungsgruppe erstellen. Sie können einem vorhandenen AKS-Cluster eine Näherungsplatzierungsgruppe (PPG) hinzufügen, indem Sie einen neuen Agentknotenpool erstellen und die PPG angeben. Nutzen Sie Topologieverteilungseinschränkungen für Pods, um zu steuern, wie Pods in Ihrem AKS-Cluster über Verfügbarkeitszonen, Knoten und Regionen verteilt werden.

• Nachdem Pods, die eine Kommunikation mit geringer Latenz erfordern, in derselben Verfügbarkeitszone liegen, erfolgt die Kommunikation zwischen den Pods nicht direkt. Stattdessen wird die Podkommunikation über einen Dienst kanalisiert, der eine logische Reihe von Pods in Ihrem AKS-Cluster definiert. Pods können so konfiguriert werden, dass sie mit AKS kommunizieren, und die Lasten der Kommunikation mit dem Dienst werden automatisch auf alle Pods verteilt, die Mitglieder des Diensts sind.

• Um Verfügbarkeitszonen zu nutzen, enthalten Knotenpools zugrunde liegende VMs, bei denen es sich um Zonenressourcen handelt. Um Anwendungen zu unterstützen, die unterschiedliche Compute- oder Speicheranforderungen haben, können Sie Benutzerknotenpools mit bestimmten VM-Größen erstellen, wenn Sie den Benutzerknotenpool erstellen.

  Sie können beispielsweise die Standard_M32ms aus der M-series für Ihre Benutzerknoten verwenden, da die Mikroservices in Ihrer Anwendung einen hohen Durchsatz, eine geringe Latenz und speicheroptimierte VM-Größen erfordern, die eine große Anzahl von vCPUs und große Speichermengen bieten. Je nach Bereitstellungsregion wird beim Auswählen der VM-Größe im Azure-Portal möglicherweise angezeigt, dass diese VM-Größe nur in Zone 1 und 2 unterstützt wird. Sie können diese Resilienzkonfiguration als Kompromiss für eine hohe Leistung akzeptieren.

• Sie können die VM-Größe eines Knotenpools nach der Erstellung nicht mehr ändern. Weitere Informationen zu Knotenpoolbeschränkungen finden Sie unter Einschränkungen.

Azure Database for MySQL Flexible Server

Die Auswirkung der Bereitstellung Ihrer Knotenpools in bestimmten Zonen, wie z. B. in Zone 1 und 2, besteht darin, dass alle Dienstabhängigkeiten Ihres AKS-Clusters auch Zone 1 und 2 unterstützen müssen. In dieser Workloadarchitektur verfügt Ihr AKS-Cluster über eine Dienstabhängigkeit von Azure Database for MySQL – Flexibler Server mit Zonenresilienz. Sie wählen Zone 1 für Ihren primären Server und Zone 2 für Ihren Standbyserver aus, sodass gemeinsam mit Ihren AKS-Benutzerknotenpools positioniert werden.

Azure Cache for Redis

• Azure Cache for Redis verteilt Knoten in einem zonenredundanten Cache im Rundlaufverfahren auf die ausgewählten Verfügbarkeitszonen.

• Sie können einen vorhandenen Premium-Cache nicht so aktualisieren, dass er Zonenredundanz verwendet. Um Zonenredundanz zu verwenden, müssen Sie Azure Cache for Redis neu erstellen.

• Um eine optimale Resilienz zu erzielen, empfehlen wir Ihnen, Ihr Azure Cache for Redis mit drei oder mehr Replikaten zu erstellen, damit Sie die Replikate über drei Verfügbarkeitszonen verteilen können.

Überlegungen zur Notfallwiederherstellung

Verfügbarkeitszonen werden für eine bessere Resilienz verwendet, um eine hohe Verfügbarkeit Ihres Workloads innerhalb der primären Region Ihrer Bereitstellung zu erzielen.

Notfallwiederherstellung besteht aus Wiederherstellungsvorgängen und Methoden, die in Ihrem Geschäftskontinuitätsplan definiert sind. In Ihrem Geschäftskontinuitätsplan geht es sowohl um die Wiederherstellung Ihres Workloads während eines Störereignisses als auch darum, wie er nach dem Ereignis wieder vollständig wiederhergestellt werden kann. Ziehen Sie in Betracht, Ihre Bereitstellung auf eine alternative Region zu erweitern.

Lesen Sie zu Ihrer Anwendungsebene die Informationen in diesem Artikel zur Geschäftskontinuität und zur Notfallwiederherstellung für AKS.

• Ziehen Sie in Betracht, mehrere AKS-Cluster in alternativen Regionen auszuführen. Die alternative Region kann ein sekundäres Regionspaar verwenden. Sie können auch, wenn es keine Regionspaare für Ihre primäre Region gibt, basierend auf Ihren Überlegungen zu den verfügbaren Diensten, der Kapazität, der geografischen Nähe und der Datenhoheit eine alternative Region auswählen. Lesen Sie den Leitfaden zur Entscheidungsfindung für Azure-Regionen. Überprüfen Sie auch das Muster mit Bereitstellungsstempeln.

• Sie können Ihre AKS-Cluster auch Aktiv/Aktiv, Aktiv/Standby, Aktiv/Passiv konfigurieren.

• Auf Ihrer Datenbankebene beinhalten die Funktionen der Notfallwiederherstellung georedundante Sicherungen mit der Möglichkeit zum Initiieren der Geowiederherstellung und zum Bereitstellen von Lesereplikaten in einer anderen Region.

• Während eines Ausfalls müssen Sie entscheiden, ob eine Wiederherstellung initiiert werden soll. Sie müssen Wiederherstellungsvorgänge nur initiieren, wenn davon auszugehen ist, dass der Ausfall länger dauert, als das Wiederherstellungszeitziel (RTO) Ihres Workloads. Andernfalls warten Sie auf die Dienstwiederherstellung, indem Sie den Dienststatus auf dem Azure Service Health-Dashboard überprüfen. Auf dem Blatt „Service Health“ im Azure-Portal können Sie alle Benachrichtigungen in Verbindung mit Ihrem Abonnement anzeigen.

• Wenn Sie die Wiederherstellung mit der Geowiederherstellungsfunktion in Azure Database for MySQL initiieren, wird ein neuer Datenbankserver mithilfe von Sicherungsdaten erstellt, die aus einer anderen Region repliziert werden.

Nächste Schritte

Weitere Informationen: