Multiregionale Bereitstellung

In diesem Thema wird eine multiregionale Bereitstellung für Apigee Hybrid in GKE, lokal bereitgestelltes Anthos GKE, RedHat OpenShift und Microsoft® Azure Kubernetes Service (AKS) beschrieben. Wählen Sie in den Voraussetzungen und Verfahren Ihre Plattform aus.

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

GKE

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

  • Kubernetes-Cluster in mehreren Regionen mit unterschiedlichen CIDR-Blöcken
  • Regionenübergreifende Kommunikation
  • Anforderungen an mehrere Regionen in Cassandra:
    • Prüfen Sie, ob der Pod-Netzwerk-Namespace über die Konnektivität in den Regionen verfügt, einschließlich Firewalls, VPN, VPC-Peering und vNet-Peering. Dies ist bei den meisten GKE-Installationen der Fall.
    • Wenn der Pod-Netzwerk-Namespace keine Verbindung zwischen Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.

      Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.

    • 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.
    • Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

GKE On-Prem

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

  • Kubernetes-Cluster in mehreren Regionen mit unterschiedlichen CIDR-Blöcken
  • Regionenübergreifende Kommunikation
  • Anforderungen an mehrere Regionen in Cassandra:
    • Wenn der Pod-Netzwerk-Namespace keine Verbindung zwischen Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt, dem Standardfall in GKE On-Prem-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.

      Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.

    • 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.
    • Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

AKS

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 Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt, dem Standardfall in AKS-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.

      Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.

    • 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.
    • Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

EKS

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 Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt, dem Standardfall in EKS-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.

      Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.

    • 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.
    • Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

OpenShift

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 Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt, dem Standardfall in OpenShift-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.

      Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.

    • 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.
    • Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

Apigee Hybrid für mehrere Regionen konfigurieren

GKE

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
    NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
    apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
    apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
    apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch
  3. Entscheiden Sie, welche der IP-Adressen, die vom vorherigen Befehl zurückgegeben wurden, der Seed-Host für mehrere Regionen ist.
  4. Konfigurieren Sie in Rechenzentrum 2 cassandra.multiRegionSeedHost und cassandra.datacenter unter Komponenten der Laufzeitebene verwalten, wobei multiRegionSeedHost für eine der IP-Adressen steht, die vom vorherigen Befehl zurückgegeben wurden:
    cassandra:
      multiRegionSeedHost: seed_host_IP
      datacenter: data_center_name
      rack: rack_name
      hostNetwork: false

    Beispiel:

    cassandra:
      multiRegionSeedHost: 10.0.0.11
      datacenter: "dc-2"
      rack: "ra-1"
      hostNetwork: false
  5. 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.

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 namespace -o yaml > apigee-namespace.yaml
    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. Prüfen Sie mit dem folgenden Befehl, ob die Hybridinstallation erfolgreich war:
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u JMX_user -pw JMX_password status

    Beispiel für eine erfolgreiche Einrichtung:

    Datacenter: dc-1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address        Load       Tokens  Owns  Host ID                               Rack
    UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
    UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
    UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
    
    Datacenter: dc-2
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address        Load       Tokens  Owns  Host ID                               Rack
    UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
    UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
    UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b
  5. Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein.
    1. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Beispiel:

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      
    2. Erstellen Sie eine benutzerdefinierte Cassandra-Datenreplikationsdatei (YAML). Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen datareplication.yaml.

      Die Datei muss Folgendes enthalten:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Wobei:

      • REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen beliebigen Namen verwenden.
      • NAMESPACE ist der gleiche Namespace, der in overrides.yaml bereitgestellt wird. Dies ist normalerweise "apigee".
      • APIGEEORG_VALUE ist die Wertausgabe des Befehls kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name aus dem vorherigen Schritt. Zum Beispiele rg-hybrid-b7d3b9c
      • SOURCE_REGION ist der Name des Rechenzentrums in der Quellregion. Dies ist der Wert, der für cassandra:datacenter: in Ihrer overrides.yaml festgelegt ist.

      Beispiel:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"
    3. Wenden Sie CassandraDataReplication mit dem folgenden Befehl an:
      kubectl apply -f datareplication.yaml
    4. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Die Ergebnisse sollten in etwa so aussehen:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }
  6. 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
  7. Aktualisieren Sie die Seed-Hosts. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DC_name.yaml und wenden Sie es noch einmal an.
    apigeectl apply -f overrides/overrides-DC_name.yaml

Cassandra-Clusterstatus prüfen

Mit folgendem Befehl können Sie ersehen, ob die Clustereinrichtung in zwei Rechenzentren erfolgreich verläuft. Der Befehl überprüft den nodetool-Status für beide Regionen.

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


Datacenter: dc-1
=================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On-Prem

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. Achten Sie darauf, dass in der Datei overrides.yaml für Ihren ursprünglichen Cluster cassandra:hostNetwork auf true eingestellt ist. Beispiel:
    cassandra:
      hostNetwork: true
  2. Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:
    kubectl config use-context original-cluster-name
  3. 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
    NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
    apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
    apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
    apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch
  4. Entscheiden Sie, welche der IP-Adressen, die vom vorherigen Befehl zurückgegeben wurden, der Seed-Host für mehrere Regionen ist.
  5. In Rechenzentrum 2 konfigurieren Sie cassandra.multiRegionSeedHost in Ihrer Überschreibungsdatei, wobei multiRegionSeedHost eine der IPs ist, die vom vorherigen Befehl zurückgegeben wurde:
    cassandra:
      hostNetwork: true
      multiRegionSeedHost: seed_host_IP
      datacenter: data_center_name
    

    Beispiel:

    cassandra:
      hostNetwork: true
      multiRegionSeedHost: 10.0.0.11
      datacenter: "dc-2"
    
  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.

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 namespace -o yaml > apigee-namespace.yaml
    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. Prüfen Sie mit dem folgenden Befehl, ob die Hybridinstallation erfolgreich war:
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u JMX_user -pw JMX_password status

    Beispiel für eine erfolgreiche Einrichtung:

    Datacenter: dc-1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address        Load       Tokens  Owns  Host ID                               Rack
    UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
    UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
    UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
    
    Datacenter: dc-2
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address        Load       Tokens  Owns  Host ID                               Rack
    UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
    UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
    UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b
  5. Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein.
    1. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Beispiel:

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      
    2. Erstellen Sie eine benutzerdefinierte Cassandra-Datenreplikationsdatei (YAML). Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen datareplication.yaml.

      Die Datei muss Folgendes enthalten:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Wobei:

      • REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen beliebigen Namen verwenden.
      • NAMESPACE ist der gleiche Namespace, der in overrides.yaml bereitgestellt wird. Dies ist normalerweise "apigee".
      • APIGEEORG_VALUE ist die Wertausgabe des Befehls kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name aus dem vorherigen Schritt. Zum Beispiele rg-hybrid-b7d3b9c
      • SOURCE_REGION ist der Name des Rechenzentrums in der Quellregion. Dies ist der Wert, der für cassandra:datacenter: in Ihrer overrides.yaml festgelegt ist.

      Beispiel:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"
    3. Wenden Sie CassandraDataReplication mit dem folgenden Befehl an:
      kubectl apply -f datareplication.yaml
    4. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Die Ergebnisse sollten in etwa so aussehen:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }
  6. 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
  7. Aktualisieren Sie die Seed-Hosts. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DC_name.yaml und wenden Sie es noch einmal an.
    apigeectl apply -f overrides/overrides-DC_name.yaml

Cassandra-Clusterstatus prüfen

Mit folgendem Befehl können Sie ersehen, ob die Clustereinrichtung in zwei Rechenzentren erfolgreich verläuft. Der Befehl überprüft den nodetool-Status für beide Regionen.

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


Datacenter: dc-1
=================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

In jeder Region ein virtuelles Netzwerk erstellen

Folgen Sie den Azure-Empfehlungen zum Einrichten einer regionenübergreifenden Kommunikation: VNet-to-VNet: Virtuelle Netzwerke in Azure über verschiedene Regionen verbinden.

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. Achten Sie darauf, dass in der Datei overrides.yaml für Ihren ursprünglichen Cluster cassandra:hostNetwork auf true eingestellt ist. Beispiel:
    cassandra:
      hostNetwork: true
  2. Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:
    kubectl config use-context original-cluster-name
  3. 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
    
  4. Entscheiden Sie, welche der IP-Adressen, die vom vorherigen Befehl zurückgegeben wurden, der multiregionale Seed-Host ist. In diesem Beispiel, in dem nur ein Cassandra-Cluster mit einem einzelnen Knoten ausgeführt wird, lautet der Seed-Host 120.38.1.9.
  5. Kopieren Sie in Ihrem Rechenzentrum 2 die Überschreibungsdatei in eine neue Datei, deren Name den Clusternamen enthält. Beispiel: overrides_your_cluster_name.yaml.
  6. 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
         hostNetwork: true

    Beispiel:

    cassandra:
      multiRegionSeedHost: 120.38.1.9
      datacenter: "dc-2"
      rack: "ra-1"
      hostNetwork: true
  7. 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.

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 namespace -o yaml > apigee-namespace.yaml
    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. Prüfen Sie mit dem folgenden Befehl, ob die Hybridinstallation erfolgreich war:
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u JMX_user -pw JMX_password status

    Beispiel für eine erfolgreiche Einrichtung:

    Datacenter: dc-1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address        Load       Tokens  Owns  Host ID                               Rack
    UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
    UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
    UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
    
    Datacenter: dc-2
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address        Load       Tokens  Owns  Host ID                               Rack
    UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
    UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
    UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b
  5. Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein.
    1. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Beispiel:

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      
    2. Erstellen Sie eine benutzerdefinierte Cassandra-Datenreplikationsdatei (YAML). Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen datareplication.yaml.

      Die Datei muss Folgendes enthalten:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Wobei:

      • REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen beliebigen Namen verwenden.
      • NAMESPACE ist der gleiche Namespace, der in overrides.yaml bereitgestellt wird. Dies ist normalerweise "apigee".
      • APIGEEORG_VALUE ist die Wertausgabe des Befehls kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name aus dem vorherigen Schritt. Zum Beispiele rg-hybrid-b7d3b9c
      • SOURCE_REGION ist der Name des Rechenzentrums in der Quellregion. Dies ist der Wert, der für cassandra:datacenter: in Ihrer overrides.yaml festgelegt ist.

      Beispiel:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"
    3. Wenden Sie CassandraDataReplication mit dem folgenden Befehl an:
      kubectl apply -f datareplication.yaml
    4. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Die Ergebnisse sollten in etwa so aussehen:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }
  6. 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
  7. Aktualisieren Sie die Seed-Hosts. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DC_name.yaml und wenden Sie es noch einmal an.
    apigeectl apply -f overrides/overrides-DC_name.yaml

Cassandra-Clusterstatus prüfen

Mit folgendem Befehl können Sie ersehen, ob die Clustereinrichtung in zwei Rechenzentren erfolgreich verläuft. Der Befehl überprüft den nodetool-Status für beide Regionen.

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


Datacenter: dc-1
=================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

OpenShift

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. Achten Sie darauf, dass in der Datei overrides.yaml für Ihren ursprünglichen Cluster cassandra:hostNetwork auf true eingestellt ist. Beispiel:
    cassandra:
      hostNetwork: true
  2. Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:
    kubectl config use-context original-cluster-name
  3. 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
    NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
    apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
    apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
    apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch
  4. Wählen Sie die IP-Adresse Ihres Cassandra-Quellhosts aus, der als multiregionaler Starthost verwendet werden soll. In diesem Beispiel ist dies der apigee-cassandra-default-0-Cluster, der Quellhost ist 10.0.0.11.
  5. Kopieren Sie in Ihrem Rechenzentrum 2 die Überschreibungsdatei in eine neue Datei, deren Name den Clusternamen enthält. Beispiel: overrides_your_cluster_name.yaml.
  6. 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:
         hostNetwork: true
         multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
         datacenter: data_center_name

    Beispiel:

    cassandra:
      hostNetwork: true
      multiRegionSeedHost: 10.0.0.11
      datacenter: "dc-2"
  7. 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.

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 namespace -o yaml > apigee-namespace.yaml
    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. Prüfen Sie mit dem folgenden Befehl, ob die Hybridinstallation erfolgreich war:
    apigeectl check-ready -f overrides_your_cluster_name.yaml
  4. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
    kubectl exec apigee-cassandra-default-0 -n apigee  \
      -- nodetool -u JMX_user -pw JMX_password status

    Beispiel für eine erfolgreiche Einrichtung:

    Datacenter: dc-1
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address        Load       Tokens  Owns  Host ID                               Rack
    UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
    UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
    UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d
    
    Datacenter: dc-2
    ====================
    Status=Up/Down
    |/ State=Normal/Leaving/Joining/Moving
    --  Address        Load       Tokens  Owns  Host ID                               Rack
    UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
    UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
    UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b
  5. Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein.
    1. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:
      kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      

      Beispiel:

      Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
      "rg-hybrid-b7d3b9c"
      
    2. Erstellen Sie eine benutzerdefinierte Cassandra-Datenreplikationsdatei (YAML). Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen datareplication.yaml.

      Die Datei muss Folgendes enthalten:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: REGION_EXPANSION
        namespace: NAMESPACE
      spec:
        organizationRef: APIGEEORG_VALUE
        force: false
        source:
          region: SOURCE_REGION

      Wobei:

      • REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen beliebigen Namen verwenden.
      • NAMESPACE ist der gleiche Namespace, der in overrides.yaml bereitgestellt wird. Dies ist normalerweise "apigee".
      • APIGEEORG_VALUE ist die Wertausgabe des Befehls kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name aus dem vorherigen Schritt. Zum Beispiele rg-hybrid-b7d3b9c
      • SOURCE_REGION ist der Name des Rechenzentrums in der Quellregion. Dies ist der Wert, der für cassandra:datacenter: in Ihrer overrides.yaml festgelegt ist.

      Beispiel:

      apiVersion: apigee.cloud.google.com/v1alpha1
      kind: CassandraDataReplication
      metadata:
        name: region-expansion
        namespace: apigee
      spec:
        organizationRef: rg-hybrid-b7d3b9c
        force: false
        source:
          region: "dc-1"
    3. Wenden Sie CassandraDataReplication mit dem folgenden Befehl an:
      kubectl apply -f datareplication.yaml
    4. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
      kubectl -n apigee get apigeeds -o json | jq .items[].status.cassandraDataReplication

      Die Ergebnisse sollten in etwa so aussehen:

      {
        "rebuildDetails": {
          "apigee-cassandra-default-0": {
            "state": "complete",
            "updated": 1623105760
          },
          "apigee-cassandra-default-1": {
            "state": "complete",
            "updated": 1623105765
          },
          "apigee-cassandra-default-2": {
            "state": "complete",
            "updated": 1623105770
          }
        },
        "state": "complete",
        "updated": 1623105770
      }
  6. 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
  7. Aktualisieren Sie die Seed-Hosts. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DC_name.yaml und wenden Sie es noch einmal an.
    apigeectl apply -f overrides/overrides-DC_name.yaml

Cassandra-Clusterstatus prüfen

Mit folgendem Befehl können Sie ersehen, ob die Clustereinrichtung in zwei Rechenzentren erfolgreich verläuft. Der Befehl überprüft den nodetool-Status für beide Regionen.

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


Datacenter: dc-1
=================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.12.1.45  112.09 KiB  256          100.0%            3c98c816-3f4d-48f0-9717-03d0c998637f  ra-1
UN  10.12.4.36  95.27 KiB  256          100.0%            0a36383d-1d9e-41e2-924c-7b62be12d6cc  ra-1
UN  10.12.5.22  88.7 KiB   256          100.0%            3561f4fa-af3d-4ea4-93b2-79ac7e938201  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address     Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.0.4.33   78.69 KiB  256          0.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          0.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          0.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

Fehlerbehebung

Siehe Fehler bei Cassandra-Datenreplikation.