Multiregionale Bereitstellung

Version 1.12 

Unterstützte Versionen:

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

Nicht unterstützte Versionen:

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

In diesem Thema wird eine multiregionale Bereitstellung für Apigee Hybrid in GKE, lokal bereitgestelltes Anthos GKE, Microsoft® Azure Kubernetes Service (AKS), Amazon Elastic Kubernetes Service (EKS) und auf RedHat OpenShift 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

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

GKE

• Bei der Installation multiregionaler Apigee-Bereitstellungen zwischen verschiedenen Netzwerken (z. B. verschiedene Cloud-Anbieter, unterschiedliche VPC-Netzwerke, Cloud und lokal) müssen Sie interne Verbindungen zwischen diesen separaten Netzwerken bereitstellen, die Cassandra für die Kommunikation zwischen den Knoten nutzen kann. Dies kann mithilfe von VPNs oder cloudspezifischen Konnektivitätslösungen erreicht werden.
• Wenn Sie Workload Identity in einem Cluster zur Authentifizierung von Dienstkonten verwenden, empfehlen wir dringend, für jeden Cluster, in den Sie erweitern, Workload Identity zu verwenden. Weitere Informationen finden Sie unter Workload Identity in GKE aktivieren oder Identitätsföderation von Arbeitslasten auf AKS und EKS aktivieren.
• Kubernetes-Cluster in mehreren Regionen mit unterschiedlichen CIDR einrichten.
• In jedem Cluster muss cert-manager installiert sein.
• Richten Sie die regionsübergreifende Kommunikation ein.
• Sorgen Sie dafür, dass alle Cassandra-Pods ihre eigenen Hostnamen auflösen können. Wenn hostNetwork auf false gesetzt ist, ist der Hostname der Name des Cassandra-Pods. Wenn hostNetwork auf true gesetzt ist, ist der Hostname der Hostname des Kubernetes-Knotens, auf dem der Cassandra-Pod ausgeführt wird.
  Tipp: Verwenden Sie diese Befehle, um zu prüfen, ob die Hostname-Auflösung funktioniert.
  
  Wenn hostNetwork auf false gesetzt ist, verwenden Sie Befehl 1. Wenn hostNetwork auf true gesetzt ist, verwenden Sie Befehl 2.
  
  Wenn die Auflösung des Hostnamens funktioniert, wird in der Ausgabe eine IP-Adresse angezeigt. Wenn die Auflösung des Hostnamens fehlschlägt, wird in der Ausgabe „Host nicht gefunden“ angezeigt.
  
  Befehl 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Befehl 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.

    Weitere Informationen zur Notwendigkeit von hostNetwork finden Sie unter Cluster im Inselmodus und hostNetwork unten.

  • 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 DNS-Lookup ihrer Hostnamen ausführen können. Apigee Cassandra verwendet den Weiterleitungs-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 den TCP-Port 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg kommunizieren zu lassen. Informationen zu den Cassandra-Portnummern finden Sie unter 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.

GKE On-Prem

• Bei der Installation multiregionaler Apigee-Bereitstellungen zwischen verschiedenen Netzwerken (z. B. verschiedene Cloud-Anbieter, unterschiedliche VPC-Netzwerke, Cloud und lokal) müssen Sie interne Verbindungen zwischen diesen separaten Netzwerken bereitstellen, die Cassandra für die Kommunikation zwischen den Knoten nutzen kann. Dies kann mithilfe von VPNs oder cloudspezifischen Konnektivitätslösungen erreicht werden.
• Kubernetes-Cluster in mehreren Regionen mit unterschiedlichen CIDR einrichten.
• In jedem Cluster muss cert-manager installiert sein.
• Richten Sie die regionsübergreifende Kommunikation ein.
• Sorgen Sie dafür, dass alle Cassandra-Pods ihre eigenen Hostnamen auflösen können. Wenn hostNetwork auf false gesetzt ist, ist der Hostname der Name des Cassandra-Pods. Wenn hostNetwork auf true gesetzt ist, ist der Hostname der Hostname des Kubernetes-Knotens, auf dem der Cassandra-Pod ausgeführt wird.
  Tipp: Verwenden Sie diese Befehle, um zu prüfen, ob die Hostname-Auflösung funktioniert.
  
  Wenn hostNetwork auf false gesetzt ist, verwenden Sie Befehl 1. Wenn hostNetwork auf true gesetzt ist, verwenden Sie Befehl 2.
  
  Wenn die Auflösung des Hostnamens funktioniert, wird in der Ausgabe eine IP-Adresse angezeigt. Wenn die Auflösung des Hostnamens fehlschlägt, wird in der Ausgabe „Host nicht gefunden“ angezeigt.
  
  Befehl 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Befehl 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.

    Weitere Informationen zur Notwendigkeit von hostNetwork finden Sie unter Cluster im Inselmodus und hostNetwork unten.

  • 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 DNS-Lookup ihrer Hostnamen ausführen können. Apigee Cassandra verwendet den Weiterleitungs-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 Cassandra-Ports zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg kommunizieren zu lassen. Informationen zu den Cassandra-Portnummern finden Sie unter 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, dann achten Sie darauf, die Systemzeiten zu synchronisieren.

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

AKS

• Bei der Installation multiregionaler Apigee-Bereitstellungen zwischen verschiedenen Netzwerken (z. B. verschiedene Cloud-Anbieter, unterschiedliche VPC-Netzwerke, Cloud und lokal) müssen Sie interne Verbindungen zwischen diesen separaten Netzwerken bereitstellen, die Cassandra für die Kommunikation zwischen den Knoten nutzen kann. Dies kann mithilfe von VPNs oder cloudspezifischen Konnektivitätslösungen erreicht werden.
• 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.
• In jedem Cluster muss cert-manager installiert sein.
• Sorgen Sie dafür, dass alle Cassandra-Pods ihre eigenen Hostnamen auflösen können. Wenn hostNetwork auf false gesetzt ist, ist der Hostname der Name des Cassandra-Pods. Wenn hostNetwork auf true gesetzt ist, ist der Hostname der Hostname des Kubernetes-Knotens, auf dem der Cassandra-Pod ausgeführt wird.
  Tipp: Verwenden Sie diese Befehle, um zu prüfen, ob die Hostname-Auflösung funktioniert.
  
  Wenn hostNetwork auf false gesetzt ist, verwenden Sie Befehl 1. Wenn hostNetwork auf true gesetzt ist, verwenden Sie Befehl 2.
  
  Wenn die Auflösung des Hostnamens funktioniert, wird in der Ausgabe eine IP-Adresse angezeigt. Wenn die Auflösung des Hostnamens fehlschlägt, wird in der Ausgabe „Host nicht gefunden“ angezeigt.
  
  Befehl 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Befehl 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.

    Weitere Informationen zur Notwendigkeit von hostNetwork finden Sie unter Cluster im Inselmodus und hostNetwork unten.

  • 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 DNS-Lookup ihrer Hostnamen ausführen können. Apigee Cassandra verwendet den Weiterleitungs-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 Cassandra-Ports zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg kommunizieren zu lassen. Informationen zu den Cassandra-Portnummern finden Sie unter 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.

EKS

• Bei der Installation multiregionaler Apigee-Bereitstellungen zwischen verschiedenen Netzwerken (z. B. verschiedene Cloud-Anbieter, unterschiedliche VPC-Netzwerke, Cloud und lokal) müssen Sie interne Verbindungen zwischen diesen separaten Netzwerken bereitstellen, die Cassandra für die Kommunikation zwischen den Knoten nutzen kann. Dies kann mithilfe von VPNs oder cloudspezifischen Konnektivitätslösungen erreicht werden.
• 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.
• In jedem Cluster muss cert-manager installiert sein.
• Sorgen Sie dafür, dass alle Cassandra-Pods ihre eigenen Hostnamen auflösen können. Wenn hostNetwork auf false gesetzt ist, ist der Hostname der Name des Cassandra-Pods. Wenn hostNetwork auf true gesetzt ist, ist der Hostname der Hostname des Kubernetes-Knotens, auf dem der Cassandra-Pod ausgeführt wird.
  Tipp: Verwenden Sie diese Befehle, um zu prüfen, ob die Hostname-Auflösung funktioniert.
  
  Wenn hostNetwork auf false gesetzt ist, verwenden Sie Befehl 1. Wenn hostNetwork auf true gesetzt ist, verwenden Sie Befehl 2.
  
  Wenn die Auflösung des Hostnamens funktioniert, wird in der Ausgabe eine IP-Adresse angezeigt. Wenn die Auflösung des Hostnamens fehlschlägt, wird in der Ausgabe „Host nicht gefunden“ angezeigt.
  
  Befehl 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Befehl 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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), 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. Amazon EKS verwendet standardmäßig das vollständig integrierte Netzwerkmodell.

    Weitere Informationen zur Notwendigkeit von hostNetwork finden Sie unter Cluster im Inselmodus und hostNetwork unten.

  • 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 DNS-Lookup ihrer Hostnamen ausführen können. Apigee Cassandra verwendet den Weiterleitungs-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 Cassandra-Ports zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg kommunizieren zu lassen. Informationen zu den Cassandra-Portnummern finden Sie unter 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.

OpenShift

• Bei der Installation multiregionaler Apigee-Bereitstellungen zwischen verschiedenen Netzwerken (z. B. verschiedene Cloud-Anbieter, unterschiedliche VPC-Netzwerke, Cloud und lokal) müssen Sie interne Verbindungen zwischen diesen separaten Netzwerken bereitstellen, die Cassandra für die Kommunikation zwischen den Knoten nutzen kann. Dies kann mithilfe von VPNs oder cloudspezifischen Konnektivitätslösungen erreicht werden.
• 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.
• In jedem Cluster muss cert-manager installiert sein.
• Sorgen Sie dafür, dass alle Cassandra-Pods ihre eigenen Hostnamen auflösen können. Wenn hostNetwork auf false gesetzt ist, ist der Hostname der Name des Cassandra-Pods. Wenn hostNetwork auf true gesetzt ist, ist der Hostname der Hostname des Kubernetes-Knotens, auf dem der Cassandra-Pod ausgeführt wird.
  Tipp: Verwenden Sie diese Befehle, um zu prüfen, ob die Hostname-Auflösung funktioniert.
  
  Wenn hostNetwork auf false gesetzt ist, verwenden Sie Befehl 1. Wenn hostNetwork auf true gesetzt ist, verwenden Sie Befehl 2.
  
  Wenn die Auflösung des Hostnamens funktioniert, wird in der Ausgabe eine IP-Adresse angezeigt. Wenn die Auflösung des Hostnamens fehlschlägt, wird in der Ausgabe „Host nicht gefunden“ angezeigt.
  
  Befehl 1:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee -- hostname -i

  
  Befehl 2:

  kubectl run -l app=alpine --image=alpine --restart=Never --rm -i -t alpine-linux -n apigee --overrides='{"kind":"Pod", "apiVersion":"v1", "spec": {"hostNetwork":true}}' -- hostname -i

• 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.

    Weitere Informationen zur Notwendigkeit von hostNetwork finden Sie unter Cluster im Inselmodus und hostNetwork unten.

  • 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 DNS-Lookup ihrer Hostnamen ausführen können. Apigee Cassandra verwendet den Weiterleitungs-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 Cassandra-Ports zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg kommunizieren zu lassen. Informationen zu den Cassandra-Portnummern finden Sie unter 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.

Cluster im Inselmodus und hostNetwork

Es gibt zwei Hauptnetzwerkmodelle für Kubernetes-Cluster: vollständig integrierter (oder flacher) und Inselmodus. Apigee empfiehlt, nach Möglichkeit das flache Netzwerkmodell zu verwenden, da dies die multiregionale Cassandra-Konnektivität vereinfacht. Wenn ein Kubernetes-Cluster im Inselmodus konfiguriert ist, ist das Pod-Netzwerk isoliert. Pods können über die Pod-IP-Adresse nicht direkt mit Pods in anderen Clustern kommunizieren. Weitere Informationen zu den Unterschieden zwischen diesen beiden Netzwerkmodellen und Beispielen für beide finden Sie unter Typische Netzwerkmodellimplementierungen.

Wenn Apigee Hybrid in zwei oder mehr Kubernetes-Clustern mit einem Netzwerkmodell im Inselmodus ausgeführt wird, muss die Einstellung hostNetwork für Cassandra über das cassandra.hostNetwork aktiviert werden. Standardmäßig sind Kubernetes-Pods in einzelnen Netzwerk-Namespaces isoliert, sodass sie die IP-Adresse des Kubernetes-Worker-Knotens nicht verwenden können. Wenn hostNetwork auf true gesetzt ist, wird der Pod nicht innerhalb seines eigenen Netzwerk-Namespace isoliert. Stattdessen wird die IP-Adresse und der Hostname des Kubernetes-Worker-Knotens verwendet, auf dem der Pod geplant ist. So kann Cassandra die IP-Adresse des Kubernetes-Worker-Knotens nativ verwenden und Cassandra so ein vollständiges Mesh-Netzwerk zwischen allen Cassandra-Pods in mehreren Clustern einrichten, die im Inselmodus ausgeführt werden.

Cassandra-Hostnamenauflösung

Ein Cassandra-Pod löst andere Cassandra-Pods nicht nach Hostname auf. Beim Start prüft Cassandra, ob sein eigener Hostname durch DNS aufgelöst werden kann. Da der Pod-Hostname mit dem Hostnamen des Kubernetes-Worker-Knotens identisch ist, wenn hostNetwork auf "true" gesetzt ist, muss der Hostname des Worker-Knotens über den Cluster-DNS-Dienst in eine IP-Adresse aufgelöst werden können. Wenn der Hostname des Kubernetes-Worker-Knotens nicht aufgelöst werden kann, wird der Cassandra-Pod nicht vollständig gestartet. Daher ist es wichtig, dass die Hostnamen der Kubernetes-Worker-Knoten von Pods im Cluster aufgelöst werden können, wenn hostNetwork auf true gesetzt wird.

Apigee Hybrid für mehrere Regionen konfigurieren

In diesem Abschnitt wird beschrieben, wie Sie Apigee Hybrid für mehrere Regionen konfigurieren.

GKE

Wichtig: Wenn Sie Apigee Hybrid in ein neues regionales Rechenzentrum erweitern, installieren Sie unbedingt dieselbe Version von Hybrid wie in Ihrem bestehenden Rechenzentrum. Vermeiden Sie die Ausführung verschiedener Hybridversionen in mehreren Rechenzentren.

Warnung: Wenn die Installation für eine neue Region fehlschlägt, fahren Sie nicht mit der Installation der Region fort. Löschen Sie stattdessen die Hybrid-Installation in der fehlgeschlagenen Region und erstellen Sie sie neu.

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. Rufen Sie für die erste erstellte Region die Pods in Ihrem Apigee-Namespace ab:

   kubectl get pods -o wide -n apigee
   

2. Identifizieren Sie die multiregionale Seed-Hostadresse für Cassandra in dieser Region, z. B. 10.0.0.11.

3. Bereiten Sie die Datei overrides.yaml für die zweite Region vor und fügen Sie die IP-Adresse des Seed-Hosts so hinzu:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Ersetzen Sie Folgendes:

   • SEED_HOST_IP_ADDRESS durch die IP-Adresse des Seed-Hosts, z. B. 10.0.0.11.
   • DATACENTER_NAME durch den Namen des Rechenzentrums, z. B. dc-2.
   • RACK_NAME durch den Rack-Namen, z. B. ra-1.
   • CLUSTER_NAME durch den Namen Ihres Apigee-Clusters. Der Standardwert ist apigeecluster. Wenn Sie einen anderen Clusternamen verwenden, müssen Sie einen Wert für cassandra.clusterName angeben. Sie können einen eigenen Wert festlegen, der aber in allen Regionen gleich sein muss.

Zweite Region konfigurieren

So richten Sie die neue Region ein:

1. Installieren Sie cert-manager in der zweiten Region.

2. 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
      

   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
      

3. Führen Sie die Schritte aus zum Apigee Hybrid-CRDs installieren in der neuen Region.

4. Verwenden Sie jetzt Helm-Diagramme, um Apigee Hybrid in der neuen Region mit den folgenden Helm-Diagrammbefehlen zu installieren (wie in Region 1):

   Hinweis: Sie können zur Konsistenz dieselben CRDs nutzen. Verwenden Sie dazu den Ordner, in den Sie die Diagramme heruntergeladen haben. Sie können auch die Überschreibungsdatei zwischen den Regionen 1 und 2 durch Benennung Ihrer Kennzeichnungen individuell halten, indem Sie einmalige Namen wie z. B. overrides-region_name.yaml usw. nutzen.
   Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
   Warnung: Wenn die Ausgabe dieses Befehls nicht sowohl die vorhandenen als auch die neuen Rechenzentren anzeigt, ist die Einrichtung fehlgeschlagen. Fahren Sie in diesem Fall nicht fort.

   Zur Behebung des Problems muss die Hybridinstallation in der neuen Region gelöscht und neu erstellt werden. Siehe Hybridlaufzeit deinstallieren. Wenn die Einrichtung fehlschlägt, versuchen Sie nicht, weiter fortzufahren oder dem Cluster beizutreten.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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

6. 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 die Quellregion, ein Datacenter-Wert im Abschnitt Cassandra der Quellregion überschreibt .yaml

      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

7. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
   Hinweis:
   Die Neuerstellung kann je nach Datenmenge einige Stunden dauern.

   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
   }

8. Sobald die Datenreplikation abgeschlossen und überprüft wurde, aktualisieren Sie die Seed-Hosts:
   1. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DATACENTER_NAME.yaml.

   2. Wenden Sie die Änderung noch einmal an, um die Apigee-Datenspeicher-CR zu aktualisieren:

      Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Prüfen Sie die Neuerstellungsprozesse in den Logs. Prüfen Sie weiter mit dem Befehl nodetool status die Datengröße.
   Hinweis: Wenn der Neuerstellungsvorgang den Status "Abgeschlossen" anzeigt und die Neuerstellungslogs "Alle Sitzungen abgeschlossen" enthalten, wurden alle Daten erfolgreich in die neue Region kopiert.

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Tipp: APIGEE_JMX_USER und APIGEE_JMX_PASSWORD werden normalerweise in den Umgebungsvariablen $APIGEE_JMX_USER und $APIGEE_JMX_PASSWORD definiert.

   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

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 APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

GKE On-Prem

Wichtig: Wenn Sie Apigee Hybrid in ein neues regionales Rechenzentrum erweitern, installieren Sie unbedingt dieselbe Version von Hybrid wie in Ihrem bestehenden Rechenzentrum. Vermeiden Sie die Ausführung verschiedener Hybridversionen in mehreren Rechenzentren.

Warnung: Wenn die Installation für eine neue Region fehlschlägt, fahren Sie nicht mit der Installation der Region fort. Löschen Sie stattdessen die Hybrid-Installation in der fehlgeschlagenen Region und erstellen Sie sie neu.

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. Rufen Sie für die erste erstellte Region die Pods in Ihrem Apigee-Namespace ab:

   kubectl get pods -o wide -n apigee
   

2. Identifizieren Sie die multiregionale Seed-Hostadresse für Cassandra in dieser Region, z. B. 10.0.0.11.

3. Bereiten Sie die Datei overrides.yaml für die zweite Region vor und fügen Sie die IP-Adresse des Seed-Hosts so hinzu:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Ersetzen Sie Folgendes:

   • SEED_HOST_IP_ADDRESS durch die IP-Adresse des Seed-Hosts, z. B. 10.0.0.11.
   • DATACENTER_NAME durch den Namen des Rechenzentrums, z. B. dc-2.
   • RACK_NAME durch den Rack-Namen, z. B. ra-1.
   • CLUSTER_NAME durch den Namen Ihres Apigee-Clusters. Der Standardwert ist apigeecluster. Wenn Sie einen anderen Clusternamen verwenden, müssen Sie einen Wert für cassandra.clusterName angeben. Sie können einen eigenen Wert festlegen, der aber in allen Regionen gleich sein muss.

Zweite Region konfigurieren

So richten Sie die neue Region ein:

1. Installieren Sie cert-manager in der zweiten Region.

2. 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
      

   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
      

3. Führen Sie die Schritte aus zum Apigee Hybrid-CRDs installieren in der neuen Region.

4. Verwenden Sie jetzt Helm-Diagramme, um Apigee Hybrid in der neuen Region mit den folgenden Helm-Diagrammbefehlen zu installieren (wie in Region 1):

   Hinweis: Sie können zur Konsistenz dieselben CRDs nutzen. Verwenden Sie dazu den Ordner, in den Sie die Diagramme heruntergeladen haben. Sie können auch die Überschreibungsdatei zwischen den Regionen 1 und 2 durch Benennung Ihrer Kennzeichnungen individuell halten, indem Sie einmalige Namen wie z. B. overrides-region_name.yaml usw. nutzen.
   Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
   Warnung: Wenn die Ausgabe dieses Befehls nicht sowohl die vorhandenen als auch die neuen Rechenzentren anzeigt, ist die Einrichtung fehlgeschlagen. Fahren Sie in diesem Fall nicht fort.

   Zur Behebung des Problems muss die Hybridinstallation in der neuen Region gelöscht und neu erstellt werden. Siehe Hybridlaufzeit deinstallieren. Wenn die Einrichtung fehlschlägt, versuchen Sie nicht, weiter fortzufahren oder dem Cluster beizutreten.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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

6. 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 die Quellregion, ein Datacenter-Wert im Abschnitt Cassandra der Quellregion überschreibt .yaml

      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

7. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
   Hinweis:
   Die Neuerstellung kann je nach Datenmenge einige Stunden dauern.

   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
   }

8. Sobald die Datenreplikation abgeschlossen und überprüft wurde, aktualisieren Sie die Seed-Hosts:
   1. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DATACENTER_NAME.yaml.

   2. Wenden Sie die Änderung noch einmal an, um die Apigee-Datenspeicher-CR zu aktualisieren:

      Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Prüfen Sie die Neuerstellungsprozesse in den Logs. Prüfen Sie weiter mit dem Befehl nodetool status die Datengröße.
   Hinweis: Wenn der Neuerstellungsvorgang den Status "Abgeschlossen" anzeigt und die Neuerstellungslogs "Alle Sitzungen abgeschlossen" enthalten, wurden alle Daten erfolgreich in die neue Region kopiert.

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Tipp: APIGEE_JMX_USER und APIGEE_JMX_PASSWORD werden normalerweise in den Umgebungsvariablen $APIGEE_JMX_USER und $APIGEE_JMX_PASSWORD definiert.

   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

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 APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

AKS

Wichtig: Wenn Sie Apigee Hybrid in ein neues regionales Rechenzentrum erweitern, installieren Sie unbedingt dieselbe Version von Hybrid wie in Ihrem bestehenden Rechenzentrum. Vermeiden Sie die Ausführung verschiedener Hybridversionen in mehreren Rechenzentren.

Warnung: Wenn die Installation für eine neue Region fehlschlägt, fahren Sie nicht mit der Installation der Region fort. Löschen Sie stattdessen die Hybrid-Installation in der fehlgeschlagenen Region und erstellen Sie sie neu.

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 einrichten. Siehe auch Schritt 1: Cluster erstellen. Verwenden Sie die zuvor erstellten Standorte und virtuellen Netzwerknamen.

Öffnen Sie Cassandra-Ports zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg kommunizieren zu lassen. Informationen zu den Cassandra-Portnummern finden Sie unter Ports konfigurieren.

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. Rufen Sie für die erste erstellte Region die Pods in Ihrem Apigee-Namespace ab:

   kubectl get pods -o wide -n apigee
   

2. Identifizieren Sie die multiregionale Seed-Hostadresse für Cassandra in dieser Region, z. B. 10.0.0.11.

3. Bereiten Sie die Datei overrides.yaml für die zweite Region vor und fügen Sie die IP-Adresse des Seed-Hosts so hinzu:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Ersetzen Sie Folgendes:

   • SEED_HOST_IP_ADDRESS durch die IP-Adresse des Seed-Hosts, z. B. 10.0.0.11.
   • DATACENTER_NAME durch den Namen des Rechenzentrums, z. B. dc-2.
   • RACK_NAME durch den Rack-Namen, z. B. ra-1.
   • CLUSTER_NAME durch den Namen Ihres Apigee-Clusters. Der Standardwert ist apigeecluster. Wenn Sie einen anderen Clusternamen verwenden, müssen Sie einen Wert für cassandra.clusterName angeben. Sie können einen eigenen Wert festlegen, der aber in allen Regionen gleich sein muss.

Zweite Region konfigurieren

So richten Sie die neue Region ein:

1. Installieren Sie cert-manager in der zweiten Region.

2. 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
      

   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
      

3. Führen Sie die Schritte aus zum Apigee Hybrid-CRDs installieren in der neuen Region.

4. Verwenden Sie jetzt Helm-Diagramme, um Apigee Hybrid in der neuen Region mit den folgenden Helm-Diagrammbefehlen zu installieren (wie in Region 1):

   Hinweis: Sie können zur Konsistenz dieselben CRDs nutzen. Verwenden Sie dazu den Ordner, in den Sie die Diagramme heruntergeladen haben. Sie können auch die Überschreibungsdatei zwischen den Regionen 1 und 2 durch Benennung Ihrer Kennzeichnungen individuell halten, indem Sie einmalige Namen wie z. B. overrides-region_name.yaml usw. nutzen.
   Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
   Warnung: Wenn die Ausgabe dieses Befehls nicht sowohl die vorhandenen als auch die neuen Rechenzentren anzeigt, ist die Einrichtung fehlgeschlagen. Fahren Sie in diesem Fall nicht fort.

   Zur Behebung des Problems muss die Hybridinstallation in der neuen Region gelöscht und neu erstellt werden. Siehe Hybridlaufzeit deinstallieren. Wenn die Einrichtung fehlschlägt, versuchen Sie nicht, weiter fortzufahren oder dem Cluster beizutreten.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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

6. 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 die Quellregion, ein Datacenter-Wert im Abschnitt Cassandra der Quellregion überschreibt .yaml

      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

7. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
   Hinweis:
   Die Neuerstellung kann je nach Datenmenge einige Stunden dauern.

   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
   }

8. Sobald die Datenreplikation abgeschlossen und überprüft wurde, aktualisieren Sie die Seed-Hosts:
   1. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DATACENTER_NAME.yaml.

   2. Wenden Sie die Änderung noch einmal an, um die Apigee-Datenspeicher-CR zu aktualisieren:

      Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Prüfen Sie die Neuerstellungsprozesse in den Logs. Prüfen Sie weiter mit dem Befehl nodetool status die Datengröße.
   Hinweis: Wenn der Neuerstellungsvorgang den Status "Abgeschlossen" anzeigt und die Neuerstellungslogs "Alle Sitzungen abgeschlossen" enthalten, wurden alle Daten erfolgreich in die neue Region kopiert.

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Tipp: APIGEE_JMX_USER und APIGEE_JMX_PASSWORD werden normalerweise in den Umgebungsvariablen $APIGEE_JMX_USER und $APIGEE_JMX_PASSWORD definiert.

   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

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 APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

EKS

Wichtig: Wenn Sie Apigee Hybrid in ein neues regionales Rechenzentrum erweitern, installieren Sie unbedingt dieselbe Version von Hybrid wie in Ihrem bestehenden Rechenzentrum. Vermeiden Sie die Ausführung verschiedener Hybridversionen in mehreren Rechenzentren. Diese Einschränkung gilt nicht, wenn mehrere Rechenzentren auf eine neue Version aktualisiert werden.

Warnung: Wenn die Installation für eine neue Region fehlschlägt, fahren Sie nicht mit der Installation der Region fort. Löschen Sie stattdessen die Hybrid-Installation in der fehlgeschlagenen Region und erstellen Sie sie neu.

In jeder Region ein virtuelles Netzwerk erstellen

Folgen Sie den AWS-Empfehlungen zum Einrichten einer regionenübergreifenden Kommunikation, wie unter Was ist VPC-Peering? beschrieben. Der AWS-Begriff für die Verwendung verschiedener Regionen ist VPC-Peering zwischen Regionen.

Multiregionale Cluster erstellen

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

Öffnen Sie Cassandra-Ports zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg kommunizieren zu lassen. Informationen zu den Cassandra-Portnummern finden Sie unter Ports konfigurieren.

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. Rufen Sie für die erste erstellte Region die Pods in Ihrem Apigee-Namespace ab:

   kubectl get pods -o wide -n apigee
   

2. Identifizieren Sie die multiregionale Seed-Hostadresse für Cassandra in dieser Region, z. B. 10.0.0.11.

3. Bereiten Sie die Datei overrides.yaml für die zweite Region vor und fügen Sie die IP-Adresse des Seed-Hosts so hinzu:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Ersetzen Sie Folgendes:

   • SEED_HOST_IP_ADDRESS durch die IP-Adresse des Seed-Hosts, z. B. 10.0.0.11.
   • DATACENTER_NAME durch den Namen des Rechenzentrums, z. B. dc-2.
   • RACK_NAME durch den Rack-Namen, z. B. ra-1.
   • CLUSTER_NAME durch den Namen Ihres Apigee-Clusters. Der Standardwert ist apigeecluster. Wenn Sie einen anderen Clusternamen verwenden, müssen Sie einen Wert für cassandra.clusterName angeben. Sie können einen eigenen Wert festlegen, der aber in allen Regionen gleich sein muss.

Zweite Region konfigurieren

So richten Sie die neue Region ein:

1. Installieren Sie cert-manager in der zweiten Region.

2. 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
      

   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
      

3. Führen Sie die Schritte aus zum Apigee Hybrid-CRDs installieren in der neuen Region.

4. Verwenden Sie jetzt Helm-Diagramme, um Apigee Hybrid in der neuen Region mit den folgenden Helm-Diagrammbefehlen zu installieren (wie in Region 1):

   Hinweis: Sie können zur Konsistenz dieselben CRDs nutzen. Verwenden Sie dazu den Ordner, in den Sie die Diagramme heruntergeladen haben. Sie können auch die Überschreibungsdatei zwischen den Regionen 1 und 2 durch Benennung Ihrer Kennzeichnungen individuell halten, indem Sie einmalige Namen wie z. B. overrides-region_name.yaml usw. nutzen.
   Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
   Warnung: Wenn die Ausgabe dieses Befehls nicht sowohl die vorhandenen als auch die neuen Rechenzentren anzeigt, ist die Einrichtung fehlgeschlagen. Fahren Sie in diesem Fall nicht fort.

   Zur Behebung des Problems muss die Hybridinstallation in der neuen Region gelöscht und neu erstellt werden. Siehe Hybridlaufzeit deinstallieren. Wenn die Einrichtung fehlschlägt, versuchen Sie nicht, weiter fortzufahren oder dem Cluster beizutreten.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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

6. 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 die Quellregion, ein Datacenter-Wert im Abschnitt Cassandra der Quellregion überschreibt .yaml

      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

7. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
   Hinweis:
   Die Neuerstellung kann je nach Datenmenge einige Stunden dauern.

   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
   }

8. Sobald die Datenreplikation abgeschlossen und überprüft wurde, aktualisieren Sie die Seed-Hosts:
   1. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DATACENTER_NAME.yaml.

   2. Wenden Sie die Änderung noch einmal an, um die Apigee-Datenspeicher-CR zu aktualisieren:

      Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Prüfen Sie die Neuerstellungsprozesse in den Logs. Prüfen Sie weiter mit dem Befehl nodetool status die Datengröße.
   Hinweis: Wenn der Neuerstellungsvorgang den Status "Abgeschlossen" anzeigt und die Neuerstellungslogs "Alle Sitzungen abgeschlossen" enthalten, wurden alle Daten erfolgreich in die neue Region kopiert.

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Tipp: APIGEE_JMX_USER und APIGEE_JMX_PASSWORD werden normalerweise in den Umgebungsvariablen $APIGEE_JMX_USER und $APIGEE_JMX_PASSWORD definiert.

   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

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 APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

OpenShift

Wichtig: Wenn Sie Apigee Hybrid in ein neues regionales Rechenzentrum erweitern, installieren Sie unbedingt dieselbe Version von Hybrid wie in Ihrem bestehenden Rechenzentrum. Vermeiden Sie die Ausführung verschiedener Hybridversionen in mehreren Rechenzentren.

Warnung: Wenn die Installation für eine neue Region fehlschlägt, fahren Sie nicht mit der Installation der Region fort. Löschen Sie stattdessen die Hybrid-Installation in der fehlgeschlagenen Region und erstellen Sie sie neu.

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. Rufen Sie für die erste erstellte Region die Pods in Ihrem Apigee-Namespace ab:

   kubectl get pods -o wide -n apigee
   

2. Identifizieren Sie die multiregionale Seed-Hostadresse für Cassandra in dieser Region, z. B. 10.0.0.11.

3. Bereiten Sie die Datei overrides.yaml für die zweite Region vor und fügen Sie die IP-Adresse des Seed-Hosts so hinzu:

   cassandra:
     multiRegionSeedHost: "SEED_HOST_IP_ADDRESS"
     datacenter: "DATACENTER_NAME"
     rack: "RACK_NAME"
     hostNetwork: false
     clusterName: CLUSTER_NAME

   Ersetzen Sie Folgendes:

   • SEED_HOST_IP_ADDRESS durch die IP-Adresse des Seed-Hosts, z. B. 10.0.0.11.
   • DATACENTER_NAME durch den Namen des Rechenzentrums, z. B. dc-2.
   • RACK_NAME durch den Rack-Namen, z. B. ra-1.
   • CLUSTER_NAME durch den Namen Ihres Apigee-Clusters. Der Standardwert ist apigeecluster. Wenn Sie einen anderen Clusternamen verwenden, müssen Sie einen Wert für cassandra.clusterName angeben. Sie können einen eigenen Wert festlegen, der aber in allen Regionen gleich sein muss.

Zweite Region konfigurieren

So richten Sie die neue Region ein:

1. Installieren Sie cert-manager in der zweiten Region.

2. 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
      

   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
      

3. Führen Sie die Schritte aus zum Apigee Hybrid-CRDs installieren in der neuen Region.

4. Verwenden Sie jetzt Helm-Diagramme, um Apigee Hybrid in der neuen Region mit den folgenden Helm-Diagrammbefehlen zu installieren (wie in Region 1):

   Hinweis: Sie können zur Konsistenz dieselben CRDs nutzen. Verwenden Sie dazu den Ordner, in den Sie die Diagramme heruntergeladen haben. Sie können auch die Überschreibungsdatei zwischen den Regionen 1 und 2 durch Benennung Ihrer Kennzeichnungen individuell halten, indem Sie einmalige Namen wie z. B. overrides-region_name.yaml usw. nutzen.
   Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

   helm upgrade operator apigee-operator \
     --install \
     --create-namespace \
     --namespace apigee-system \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade datastore apigee-datastore \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade telemetry apigee-telemetry \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade redis apigee-redis \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ingress-manager apigee-ingress-manager \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   helm upgrade ORG_NAME apigee-org \
     --install \
     --namespace apigee \
     --atomic \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env mentioned on the overrides
   helm upgrade ENV_NAME apigee-env/ \
     --install \
     --namespace apigee \
     --atomic \
     --set env=ENV_NAME \
     -f overrides-DATACENTER_NAME.yaml
   # repeat the below command for each env group mentioned on the overrides
   helm upgrade apigee-virtualhost-ENV_GROUP_NAME apigee-virtualhost/ \
     --install \
     --namespace apigee \
     --atomic \
     --set envgroup=ENV_GROUP_NAME \
     -f overrides-DATACENTER_NAME.yaml
   

5. Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.
   Warnung: Wenn die Ausgabe dieses Befehls nicht sowohl die vorhandenen als auch die neuen Rechenzentren anzeigt, ist die Einrichtung fehlgeschlagen. Fahren Sie in diesem Fall nicht fort.

   Zur Behebung des Problems muss die Hybridinstallation in der neuen Region gelöscht und neu erstellt werden. Siehe Hybridlaufzeit deinstallieren. Wenn die Einrichtung fehlschlägt, versuchen Sie nicht, weiter fortzufahren oder dem Cluster beizutreten.

   kubectl exec apigee-cassandra-default-0 -n apigee  \
   -- nodetool -u APIGEE_JMX_USER -pw APIGEE_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

6. 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 die Quellregion, ein Datacenter-Wert im Abschnitt Cassandra der Quellregion überschreibt .yaml

      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

7. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
   Hinweis:
   Die Neuerstellung kann je nach Datenmenge einige Stunden dauern.

   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
   }

8. Sobald die Datenreplikation abgeschlossen und überprüft wurde, aktualisieren Sie die Seed-Hosts:
   1. Entfernen Sie multiRegionSeedHost: 10.0.0.11 aus overrides-DATACENTER_NAME.yaml.

   2. Wenden Sie die Änderung noch einmal an, um die Apigee-Datenspeicher-CR zu aktualisieren:

      Wichtig: Lassen Sie das ‑‑atomic-Flag für migrierte Cluster weg.

      helm upgrade datastore apigee-datastore/ \
        --install \
        --namespace apigee \
        --atomic \
        -f overrides-DATACENTER_NAME.yaml
      

9. Prüfen Sie die Neuerstellungsprozesse in den Logs. Prüfen Sie weiter mit dem Befehl nodetool status die Datengröße.
   Hinweis: Wenn der Neuerstellungsvorgang den Status "Abgeschlossen" anzeigt und die Neuerstellungslogs "Alle Sitzungen abgeschlossen" enthalten, wurden alle Daten erfolgreich in die neue Region kopiert.

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

   kubectl exec apigee-cassandra-default-0 -n apigee  -- nodetool -u APIGEE_JMX_USER -pw APIGEE_JMX_PASSWORD status

   Tipp: APIGEE_JMX_USER und APIGEE_JMX_PASSWORD werden normalerweise in den Umgebungsvariablen $APIGEE_JMX_USER und $APIGEE_JMX_PASSWORD definiert.

   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

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 APIGEE_JMX_USER -pw APIGEE_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: us-west1
====================
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          100.0%              a200217d-260b-45cd-b83c-182b27ff4c99  ra-1
UN  10.0.0.21   78.68 KiB  256          100.0%              9f3364b9-a7a1-409c-9356-b7d1d312e52b  ra-1
UN  10.0.1.26   15.46 KiB  256          100.0%              1666df0f-702e-4c5b-8b6e-086d0f2e47fa  ra-1

Fehlerbehebung

Siehe Fehler bei Cassandra-Datenreplikation.