Multiregionale Bereitstellung auf AKS

Aktuell lesen Sie die Version 1.5 der Apigee Hybrid-Dokumentation. Diese Version ist nicht mehr gültig. Führen Sie ein Upgrade auf eine neuere Version durch. Weitere Informationen finden Sie unter Unterstützte Versionen.

Version 1.5 (unsupported)

Unterstützte Versionen:

• V1.12 (aktuellste Version)                        
• v1.11                         
• v1.10                                        
• Liste der unterstützten Versionen

Nicht unterstützte Versionen:

• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

In diesem Thema wird erläutert, wie Sie eine multiregionale Bereitstellung für Apigee Hybrid in Microsoft® Azure Kubernetes Service (AKS) einrichten.

Zu den Topologien für die Multiregions-Bereitstellung zählen:

• Aktiv-Aktiv: Wenn Sie Anwendungen an mehreren geografischen Standorten bereitgestellt haben und eine API-Antwort mit niedriger Latenz für Ihre Bereitstellungen benötigen. Sie haben die Möglichkeit, Hybrid an mehreren geografischen Standorten bereitzustellen, die Ihren Kunden am nächsten sind. Beispiel: US-Westküste, US-Ostküste, Europa, APAC.
• Aktiv-Passiv: Wenn Sie eine primäre Region und eine Failover-Region oder eine Region für die Notfallwiederherstellung haben.

Die Regionen in einer multiregionalen Hybrid-Bereitstellung kommunizieren über Cassandra, wie das folgende Bild zeigt:

Vorbereitung

Bevor Sie Hybrid für mehrere Regionen konfigurieren, müssen folgende Elemente vorhanden sein:

• Bevor Sie die Schritte zur Clustereinrichtung ausführen, müssen Sie der Hybrid-Installationsanleitung folgen, um die Voraussetzungen wie Google Cloud- und Organisationskonfiguration zu erfüllen.
• Anforderungen an mehrere Regionen in Cassandra:
  • Wenn der Pod-Netzwerk-Namespace keine Verbindung zwischen Pods in verschiedenen Clustern hat (die Cluster werden im „Insel-Netzwerkmodus“ ausgeführt, dem Standardfall in AKS-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork durch folgende Einstellung: cassandra.hostNetwork: true in der Überschreibungendatei für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen.
  • Aktivieren Sie hostNetwork auf vorhandenen Clustern, bevor Sie die Multiregionen-Konfiguration auf neue Regionen erweitern.
  • Wenn hostNetwork aktiviert ist, müssen die Worker-Knoten einen umgekehrten DNS-Lookup ausführen. Apigee Cassandra verwendet sowohl den Forward- als auch den Reverse-DNS-Lookup, um die Host-IP beim Start abzurufen.
    Tipp: Wenn die DNS-Auflösung nicht funktioniert, können Sie das Problem umgehen.

    Fügen Sie in der Datei /etc/hosts jedes Cassandra-Worker-Knotens einen statischen Hosteintrag hinzu, der in etwa so aussieht:

    echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"

    oder

    "\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"

  • Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg kommunizieren zu lassen. Siehe Ports konfigurieren.

Ausführliche Informationen dazu finden sich in der Kubernetes-Dokumentation.

HINWEIS: Apigee empfiehlt, dass Sie die Zeiten Ihrer Server synchronisieren.

Einige Funktionen, darunter der Verfall und der Widerruf von Tokens, sind auf die genaue Systemzeit angewiesen. Wenn Sie die Laufzeitkomponenten in verschiedenen Rechenzentren hosten, achten Sie darauf, dass die Systemzeiten synchronisiert werden.

Mit einem Tool wie ntpdate können Sie prüfen, ob die Serverzeiten synchronisiert sind.

In jeder Region ein virtuelles Netzwerk erstellen

In der Dokumentation zu Azure Kubernetes Service (AKS) finden Sie folgende Informationen:

• Erstellen Sie in jeder Region ein virtuelles Netzwerk.
• Richten Sie Netzwerk-Peering zwischen den Regionen ein.
• Prüfen Sie das Netzwerk-Peering.

Multiregionale Cluster erstellen

Kubernetes-Cluster in mehreren Regionen mit unterschiedlichen CIDR-Blöcken einrichten. Siehe auch Schritt 1: Cluster erstellen. Verwenden Sie die zuvor erstellten Standorte und virtuellen Netzwerknamen.

Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen (7000 kann bei der Fehlerbehebung als Sicherungsoption verwendet werden).

Seed-Host für mehrere Regionen konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie den vorhandenen Cassandra-Cluster auf eine neue Region erweitern. Diese Konfiguration ermöglicht der neuen Region, einen Bootstrap-Vorgang auf den Cluster anzuwenden und dem vorhandenen Rechenzentrum beizutreten. Ohne diese Konfiguration würden die multiregionalen Kubernetes-Cluster nichts voneinander wissen.

1. Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:

   kubectl config use-context original-cluster-name

2. Führen Sie folgenden kubectl-Befehl aus, um eine Seed-Hostadresse für Cassandra in der aktuellen Region zu identifizieren.

   Mit einer Seed-Hostadresse kann eine neue regionale Instanz beim ersten Start den ursprünglichen Cluster finden, um die Topologie des Clusters zu erlernen. Die Seed-Hostadresse wird als Kontaktpunkt im Cluster festgelegt.

   kubectl get pods -o wide -n apigee | grep apigee-cassandra
   
   apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
   

3. Entscheiden Sie, welche der IP-Adressen, die vom vorherigen Befehl zurückgegeben wurden, der Seed-Host für mehrere Regionen ist. In diesem Beispiel, in dem nur ein einzelner Knoten-Kassandra-Cluster ausgeführt wird, lautet der Seed-Host 120.38.1.9.
4. Kopieren Sie in Ihrem Rechenzentrum 2 die overrides-datei in eine neue Datei, deren Name den Clusternamen enthält. z. B. overrides_your_cluster_name.yaml
5. Konfigurieren Sie in Rechenzentrum 2 cassandra.multiRegionSeedHost und cassandra.datacenter in overrides_your_cluster_name.yaml, wobei multiRegionSeedHost eine der vom vorherigen Befehl zurückgegebenen IP-Adressen ist:

   cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name

   Beispiel:

   cassandra:
     multiRegionSeedHost: 120.38.1.9
     datacenter: "dc-1"
     rack: "ra-1"

6. Geben Sie in overrides_your_cluster_name.yaml für das neue Rechenzentrum bzw. für die neue Region vor der Installation von Hybrid die gleichen TLS-Zertifikate und -Anmeldedaten wie für die erste Region an.
   HINWEIS: Verwenden Sie im zweiten Rechenzentrum die gleichen Cassandra-TLS-Zertifikate und -Anmeldedaten wie im ursprünglichen Rechenzentrum. Die Anmeldedaten, die Sie im ersten Rechenzentrum in der Überschreibungs-Datei festlegen, müssen mit den Anmeldedaten übereinstimmen, die Sie im zweiten Rechenzentrum in der Überschreibungs-Datei angeben. Ausführliche Informationen dazu finden Sie unter TLS für Cassandra konfigurieren.

Neue Region einrichten

Nachdem Sie den Seed-Host konfiguriert haben, können Sie die neue Region einrichten.

So richten Sie die neue Region ein:

1. Kopieren Sie das Zertifikat aus dem vorhandenen in den neuen Cluster. Der neue CA-Stamm wird von Cassandra und anderen Hybrid-Komponenten für mTLS verwendet. Daher ist es wichtig, dass im Cluster konsistente Zertifikate vorhanden sind.
   1. Legen Sie für den Kontext den ursprünglichen Namespace fest:

      kubectl config use-context original-cluster-name

   2. Exportieren Sie die aktuelle Namespace-Konfiguration in eine Datei:

      $ kubectl get namespace apigee -o yaml > apigee-namespace.yaml

      apigee ist der Standard-Namespace.

   3. Exportieren Sie das apigee-ca-Secret in eine Datei:

      kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml

   4. Legen Sie für den Kontext den Clusternamen der neuen Region fest:

      kubectl config use-context new-cluster-name

   5. Importieren Sie die Namespace-Konfiguration in den neuen Cluster. Achten Sie darauf, den "Namespace" in der Datei zu aktualisieren, wenn Sie in der neuen Region einen anderen Namespace verwenden:

      kubectl apply -f apigee-namespace.yaml

   6. Importieren Sie das Secret in den neuen Cluster:

      kubectl -n cert-manager apply -f apigee-ca.yaml

2. Installieren Sie Hybrid in der neuen Region. Achten Sie darauf, dass die Datei overrides_your_cluster_name.yaml genau die TLS-Zertifikate enthält, die in der ersten Region konfiguriert sind, wie im vorherigen Abschnitt erläutert.

   Führen Sie folgende zwei Befehle aus, um Hybrid in der neuen Region zu installieren:

   apigeectl init -f overrides_your_cluster_name.yaml

   apigeectl apply -f overrides_your_cluster_name.yaml

3. Führen Sie nodetool rebuild nacheinander auf allen Knoten im neuen Rechenzentrum aus. Dies kann, je nach Datengröße, bis zu einigen Stunden dauern.

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password rebuild -- dc-1

   Dabei sind JMX_user und JMX_password der Nutzername und das Passwort für den Cassandra JMX-Nutzer.

4. Prüfen Sie die Neuerstellungsprozesse in den Logs. Prüfen Sie weiter mit dem Befehl nodetool status die Datengröße:

   kubectl logs apigee-cassandra-default-0 -f -n apigee

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u JMX_user -pw JMX_password status

   Das folgende Beispiel zeigt beispielhafte Logeinträge.

   INFO  01:42:24 rebuild from dc: dc-1, (All keyspaces), (All tokens)
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Executing streaming plan for Rebuild
   INFO  01:42:24 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.1.45
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.432KiB), sending 0 files(0.000KiB)
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.1.45 is complete
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.4.36
   INFO  01:42:25 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Starting streaming to /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 1 files(0.693KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.4.36 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889, ID#0] Beginning stream session with /10.12.5.22
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889 ID#0] Prepare completed. Receiving 3 files(0.720KiB), sending 0 files(0.000KiB)
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] Session with /10.12.5.22 is complete
   INFO  01:42:26 [Stream #3a04e810-580d-11e9-a5aa-67071bf82889] All sessions completed

5. Aktualisieren Sie die Seed-Hosts. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DC_name.yaml und wenden Sie es noch einmal an.
   Seed-Hosts sind lokale Clustermitglieder. Zum Starten einer neuen Region ist ein externer Seed-Host erforderlich. Sobald eine Region gestartet wurde, müssen Sie die Seed-Hosts wieder zu ihren lokalen Clustern in overrides.yaml ändern und die Konfiguration dann noch einmal anwenden.

   apigeectl apply -f overrides-DC_name.yaml