English
Deutsch
Español – América Latina
Français
Indonesia
Italiano
Português – Brasil
中文 – 简体
日本語
한국어

Kontakt Jetzt kostenlos testen

Multiregionale Bereitstellung

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

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

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

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

Vorbereitung

GKE

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

Kubernetes-Cluster in mehreren Regionen mit unterschiedlichen CIDR-Blöcken
Regionenübergreifende Kommunikation
Anforderungen an mehrere Regionen in Cassandra:
- Prüfen Sie, ob der Pod-Netzwerk-Namespace über die Konnektivität in den Regionen verfügt, einschließlich Firewalls, VPN, VPC-Peering und vNet-Peering. Dies ist bei den meisten GKE-Installationen der Fall.
- Wenn der Pod-Netzwerk-Namespace keine Verbindung zwischen Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.
  Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.
- Aktivieren Sie hostNetwork auf vorhandenen Clustern, bevor Sie die Multiregionen-Konfiguration auf neue Regionen erweitern.
- Wenn hostNetwork aktiviert ist, müssen die Worker-Knoten einen umgekehrten DNS-Lookup ausführen. Apigee Cassandra verwendet sowohl den Forward- als auch den Reverse-DNS-Lookup, um die Host-IP beim Start abzurufen.
  Tipp: Wenn die DNS-Auflösung nicht funktioniert, können Sie das Problem umgehen.
  Fügen Sie in der Datei /etc/hosts jedes Cassandra-Worker-Knotens einen statischen Hosteintrag hinzu, der in etwa so aussieht:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  oder
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

GKE On-Prem

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

Kubernetes-Cluster in mehreren Regionen mit unterschiedlichen CIDR-Blöcken
Regionenübergreifende Kommunikation
Anforderungen an mehrere Regionen in Cassandra:
- Wenn der Pod-Netzwerk-Namespace keine Verbindung zwischen Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt, dem Standardfall in GKE On-Prem-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.
  Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.
- Aktivieren Sie hostNetwork auf vorhandenen Clustern, bevor Sie die Multiregionen-Konfiguration auf neue Regionen erweitern.
- Wenn hostNetwork aktiviert ist, müssen die Worker-Knoten einen umgekehrten DNS-Lookup ausführen. Apigee Cassandra verwendet sowohl den Forward- als auch den Reverse-DNS-Lookup, um die Host-IP beim Start abzurufen.
  Tipp: Wenn die DNS-Auflösung nicht funktioniert, können Sie das Problem umgehen.
  Fügen Sie in der Datei /etc/hosts jedes Cassandra-Worker-Knotens einen statischen Hosteintrag hinzu, der in etwa so aussieht:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  oder
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

AKS

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

Bevor Sie die Schritte zur Clustereinrichtung ausführen, müssen Sie der Hybrid-Installationsanleitung folgen, um die Voraussetzungen wie Google Cloud- und Organisationskonfiguration zu erfüllen.
Anforderungen an mehrere Regionen in Cassandra:
- Wenn der Pod-Netzwerk-Namespace keine Verbindung zwischen Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt, dem Standardfall in AKS-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.
  Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.
- Aktivieren Sie hostNetwork auf vorhandenen Clustern, bevor Sie die Multiregionen-Konfiguration auf neue Regionen erweitern.
- Wenn hostNetwork aktiviert ist, müssen die Worker-Knoten einen umgekehrten DNS-Lookup ausführen. Apigee Cassandra verwendet sowohl den Forward- als auch den Reverse-DNS-Lookup, um die Host-IP beim Start abzurufen.
  Tipp: Wenn die DNS-Auflösung nicht funktioniert, können Sie das Problem umgehen.
  Fügen Sie in der Datei /etc/hosts jedes Cassandra-Worker-Knotens einen statischen Hosteintrag hinzu, der in etwa so aussieht:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  oder
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

EKS

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

Bevor Sie die Schritte zur Clustereinrichtung ausführen, müssen Sie der Hybrid-Installationsanleitung folgen, um die Voraussetzungen wie Google Cloud- und Organisationskonfiguration zu erfüllen.
Anforderungen an mehrere Regionen in Cassandra:
- Wenn der Pod-Netzwerk-Namespace keine Verbindung zwischen Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt, dem Standardfall in EKS-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.
  Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.
- Aktivieren Sie hostNetwork auf vorhandenen Clustern, bevor Sie die Multiregionen-Konfiguration auf neue Regionen erweitern.
- Wenn hostNetwork aktiviert ist, müssen die Worker-Knoten einen umgekehrten DNS-Lookup ausführen. Apigee Cassandra verwendet sowohl den Forward- als auch den Reverse-DNS-Lookup, um die Host-IP beim Start abzurufen.
  Tipp: Wenn die DNS-Auflösung nicht funktioniert, können Sie das Problem umgehen.
  Fügen Sie in der Datei /etc/hosts jedes Cassandra-Worker-Knotens einen statischen Hosteintrag hinzu, der in etwa so aussieht:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  oder
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

OpenShift

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

Bevor Sie die Schritte zur Clustereinrichtung ausführen, müssen Sie der Hybrid-Installationsanleitung folgen, um die Voraussetzungen wie Google Cloud- und Organisationskonfiguration zu erfüllen.
Anforderungen an mehrere Regionen in Cassandra:
- Wenn der Pod-Netzwerk-Namespace keine Verbindung zwischen Clustern hat (die Cluster werden als "Netzwerk im Inselmodus" ausgeführt, dem Standardfall in OpenShift-Installationen), aktivieren Sie das Kubernetes-Feature hostNetwork. Legen Sie dazu in der Überschreibungsdatei cassandra.hostNetwork: true für alle Regionen in Ihrer Apigee Hybrid-Installation für mehrere Regionen fest.
  Informationen zum Kubernetes-Feature hostNetwork finden Sie in der Kubernetes-Dokumentation unter Host-Namespaces.
- Aktivieren Sie hostNetwork auf vorhandenen Clustern, bevor Sie die Multiregionen-Konfiguration auf neue Regionen erweitern.
- Wenn hostNetwork aktiviert ist, müssen die Worker-Knoten einen umgekehrten DNS-Lookup ausführen. Apigee Cassandra verwendet sowohl den Forward- als auch den Reverse-DNS-Lookup, um die Host-IP beim Start abzurufen.
  Tipp: Wenn die DNS-Auflösung nicht funktioniert, können Sie das Problem umgehen.
  Fügen Sie in der Datei /etc/hosts jedes Cassandra-Worker-Knotens einen statischen Hosteintrag hinzu, der in etwa so aussieht:
```
echo -e "\\n127.0.1.1 ${HOSTNAME}" >> "/etc/hosts"
```
  oder
```
"\\nWORKER-NODE-IP ${HOSTNAME}" >> "/etc/hosts"
```
- Öffnen Sie die Cassandra-Ports 7000 und 7001 zwischen Kubernetes-Clustern in allen Regionen, um Worker-Knoten über Regionen und Rechenzentren hinweg zu kommunizieren. Siehe Ports konfigurieren.

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

Apigee Hybrid für mehrere Regionen konfigurieren

GKE

Seed-Host für mehrere Regionen konfigurieren

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

Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:
```
kubectl config use-context original-cluster-name
```

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

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

kubectl get pods -o wide -n apigee

NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

Entscheiden Sie, welche der IP-Adressen, die vom vorherigen Befehl zurückgegeben wurden, der Seed-Host für mehrere Regionen ist.
Konfigurieren Sie in Rechenzentrum 2 cassandra.multiRegionSeedHost und cassandra.datacenter unter Komponenten der Laufzeitebene verwalten, wobei multiRegionSeedHost für eine der IP-Adressen steht, die vom vorherigen Befehl zurückgegeben wurden:
```
cassandra:
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
  rack: rack_name
  hostNetwork: false
```
Beispiel:
```
cassandra:
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: false
```
Geben Sie in overrides_your_cluster_name.yaml für das neue Rechenzentrum bzw. für die neue Region vor der Installation von Hybrid die gleichen TLS-Zertifikate und -Anmeldedaten wie für die erste Region an.
HINWEIS: Verwenden Sie im zweiten Rechenzentrum die gleichen Cassandra-TLS-Zertifikate und -Anmeldedaten wie im ursprünglichen Rechenzentrum. Die Anmeldedaten, die Sie im ersten Rechenzentrum in der Überschreibungs-Datei festlegen, müssen mit den Anmeldedaten übereinstimmen, die Sie im zweiten Rechenzentrum in der Überschreibungs-Datei angeben. Ausführliche Informationen dazu finden Sie unter TLS für Cassandra konfigurieren.

Neue Region einrichten

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

So richten Sie die neue Region ein:

Kopieren Sie das Zertifikat aus dem vorhandenen in den neuen Cluster. Der neue CA-Stamm wird von Cassandra und anderen Hybrid-Komponenten für mTLS verwendet. Daher ist es wichtig, dass im Cluster konsistente Zertifikate vorhanden sind.
1. Legen Sie für den Kontext den ursprünglichen Namespace fest:
```
kubectl config use-context original-cluster-name
```
2. Exportieren Sie die aktuelle Namespace-Konfiguration in eine Datei:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exportieren Sie das apigee-ca-Secret in eine Datei:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Legen Sie für den Kontext den Clusternamen der neuen Region fest:
```
kubectl config use-context new-cluster-name
```
5. Importieren Sie die Namespace-Konfiguration in den neuen Cluster. Achten Sie darauf, den "Namespace" in der Datei zu aktualisieren, wenn Sie in der neuen Region einen anderen Namespace verwenden:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importieren Sie das Secret in den neuen Cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Installieren Sie Hybrid in der neuen Region. Achten Sie darauf, dass die Datei overrides_your_cluster_name.yaml genau die TLS-Zertifikate enthält, die in der ersten Region konfiguriert sind, wie im vorherigen Abschnitt erläutert.
Führen Sie folgende zwei Befehle aus, um Hybrid in der neuen Region zu installieren:

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.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Prüfen Sie mit dem folgenden Befehl, ob die Hybridinstallation erfolgreich war:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.

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

Beispiel für eine erfolgreiche Einrichtung:

Datacenter: dc-1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein.
1. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Beispiel:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Erstellen Sie eine benutzerdefinierte Cassandra-Datenreplikationsdatei (YAML). Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen datareplication.yaml.
  Die Datei muss Folgendes enthalten:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Wobei:
  - REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen beliebigen Namen verwenden.
  - NAMESPACE ist der gleiche Namespace, der in overrides.yaml bereitgestellt wird. Dies ist normalerweise "apigee".
  - APIGEEORG_VALUE ist die Wertausgabe des Befehls kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name aus dem vorherigen Schritt. Zum Beispiele rg-hybrid-b7d3b9c
  - SOURCE_REGION ist der Name des Rechenzentrums in der Quellregion. Dies ist der Wert, der für cassandra:datacenter: in Ihrer overrides.yaml festgelegt ist.
  Beispiel:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Wenden Sie CassandraDataReplication mit dem folgenden Befehl an:
```
kubectl apply -f datareplication.yaml
```
4. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
  Hinweis: Die Neuerstellung kann je nach Datengröße 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
}
```

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

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

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

Das folgende Beispiel zeigt beispielhafte Logeinträge.

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

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

Cassandra-Clusterstatus prüfen

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

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

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

GKE On-Prem

Seed-Host für mehrere Regionen konfigurieren

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

Achten Sie darauf, dass in der Datei overrides.yaml für Ihren ursprünglichen Cluster cassandra:hostNetwork auf true eingestellt ist. Beispiel:
```
cassandra:
  hostNetwork: true
```
Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:
```
kubectl config use-context original-cluster-name
```

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

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

kubectl get pods -o wide -n apigee

NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

Entscheiden Sie, welche der IP-Adressen, die vom vorherigen Befehl zurückgegeben wurden, der Seed-Host für mehrere Regionen ist.
In Rechenzentrum 2 konfigurieren Sie cassandra.multiRegionSeedHost in Ihrer Überschreibungsdatei, wobei multiRegionSeedHost eine der IPs ist, die vom vorherigen Befehl zurückgegeben wurde:
```
cassandra:
  hostNetwork: true
  multiRegionSeedHost: seed_host_IP
  datacenter: data_center_name
```
Beispiel:
```
cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"
```
Geben Sie in overrides_your_cluster_name.yaml für das neue Rechenzentrum bzw. für die neue Region vor der Installation von Hybrid die gleichen TLS-Zertifikate und -Anmeldedaten wie für die erste Region an.
HINWEIS: Verwenden Sie im zweiten Rechenzentrum die gleichen Cassandra-TLS-Zertifikate und -Anmeldedaten wie im ursprünglichen Rechenzentrum. Die Anmeldedaten, die Sie im ersten Rechenzentrum in der Überschreibungs-Datei festlegen, müssen mit den Anmeldedaten übereinstimmen, die Sie im zweiten Rechenzentrum in der Überschreibungs-Datei angeben. Ausführliche Informationen dazu finden Sie unter TLS für Cassandra konfigurieren.

Neue Region einrichten

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

So richten Sie die neue Region ein:

Kopieren Sie das Zertifikat aus dem vorhandenen in den neuen Cluster. Der neue CA-Stamm wird von Cassandra und anderen Hybrid-Komponenten für mTLS verwendet. Daher ist es wichtig, dass im Cluster konsistente Zertifikate vorhanden sind.
1. Legen Sie für den Kontext den ursprünglichen Namespace fest:
```
kubectl config use-context original-cluster-name
```
2. Exportieren Sie die aktuelle Namespace-Konfiguration in eine Datei:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exportieren Sie das apigee-ca-Secret in eine Datei:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Legen Sie für den Kontext den Clusternamen der neuen Region fest:
```
kubectl config use-context new-cluster-name
```
5. Importieren Sie die Namespace-Konfiguration in den neuen Cluster. Achten Sie darauf, den "Namespace" in der Datei zu aktualisieren, wenn Sie in der neuen Region einen anderen Namespace verwenden:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importieren Sie das Secret in den neuen Cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Installieren Sie Hybrid in der neuen Region. Achten Sie darauf, dass die Datei overrides_your_cluster_name.yaml genau die TLS-Zertifikate enthält, die in der ersten Region konfiguriert sind, wie im vorherigen Abschnitt erläutert.
Führen Sie folgende zwei Befehle aus, um Hybrid in der neuen Region zu installieren:

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.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Prüfen Sie mit dem folgenden Befehl, ob die Hybridinstallation erfolgreich war:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.

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

Beispiel für eine erfolgreiche Einrichtung:

Datacenter: dc-1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein.
1. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Beispiel:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Erstellen Sie eine benutzerdefinierte Cassandra-Datenreplikationsdatei (YAML). Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen datareplication.yaml.
  Die Datei muss Folgendes enthalten:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Wobei:
  - REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen beliebigen Namen verwenden.
  - NAMESPACE ist der gleiche Namespace, der in overrides.yaml bereitgestellt wird. Dies ist normalerweise "apigee".
  - APIGEEORG_VALUE ist die Wertausgabe des Befehls kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name aus dem vorherigen Schritt. Zum Beispiele rg-hybrid-b7d3b9c
  - SOURCE_REGION ist der Name des Rechenzentrums in der Quellregion. Dies ist der Wert, der für cassandra:datacenter: in Ihrer overrides.yaml festgelegt ist.
  Beispiel:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Wenden Sie CassandraDataReplication mit dem folgenden Befehl an:
```
kubectl apply -f datareplication.yaml
```
4. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
  Hinweis: Die Neuerstellung kann je nach Datengröße 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
}
```

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

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

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

Das folgende Beispiel zeigt beispielhafte Logeinträge.

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

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

Cassandra-Clusterstatus prüfen

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

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

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

AKS

In jeder Region ein virtuelles Netzwerk erstellen

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

Multiregionale Cluster erstellen

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

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

Seed-Host für mehrere Regionen konfigurieren

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

Achten Sie darauf, dass in der Datei overrides.yaml für Ihren ursprünglichen Cluster cassandra:hostNetwork auf true eingestellt ist. Beispiel:
```
cassandra:
  hostNetwork: true
```
Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:
```
kubectl config use-context original-cluster-name
```
Führen Sie folgenden kubectl-Befehl aus, um eine Seed-Hostadresse für Cassandra in der aktuellen Region zu identifizieren.

Mit einer Seed-Hostadresse kann eine neue regionale Instanz beim ersten Start den ursprünglichen Cluster finden, um die Topologie des Clusters zu erlernen. Die Seed-Hostadresse wird als Kontaktpunkt im Cluster festgelegt.
```
kubectl get pods -o wide -n apigee | grep apigee-cassandra
```
```
apigee-cassandra-default-0  1/1   Running   0   4d17h   120.38.1.9  aks-agentpool-21207753-vmss000000
```
Entscheiden Sie, welche der IP-Adressen, die vom vorherigen Befehl zurückgegeben wurden, der Seed-Host für mehrere Regionen ist. In diesem Beispiel, in dem nur ein Cassandra-Cluster mit einem einzelnen Knoten ausgeführt wird, lautet der Seed-Host 120.38.1.9.
Kopieren Sie in Ihrem Rechenzentrum 2 die Überschreibungsdatei in eine neue Datei, deren Name den Clusternamen enthält. Beispiel: overrides_your_cluster_name.yaml.

Konfigurieren Sie in Rechenzentrum 2 cassandra.multiRegionSeedHost und cassandra.datacenter in overrides_your_cluster_name.yaml, wobei multiRegionSeedHost eine der vom vorherigen Befehl zurückgegebenen IP-Adressen ist:

cassandra:
     multiRegionSeedHost: seed_host_IP
     datacenter: data_center_name
     rack: rack_name
     hostNetwork: true

Beispiel:

cassandra:
  multiRegionSeedHost: 120.38.1.9
  datacenter: "dc-2"
  rack: "ra-1"
  hostNetwork: true

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

Neue Region einrichten

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

So richten Sie die neue Region ein:

Kopieren Sie das Zertifikat aus dem vorhandenen in den neuen Cluster. Der neue CA-Stamm wird von Cassandra und anderen Hybrid-Komponenten für mTLS verwendet. Daher ist es wichtig, dass im Cluster konsistente Zertifikate vorhanden sind.
1. Legen Sie für den Kontext den ursprünglichen Namespace fest:
```
kubectl config use-context original-cluster-name
```
2. Exportieren Sie die aktuelle Namespace-Konfiguration in eine Datei:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exportieren Sie das apigee-ca-Secret in eine Datei:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Legen Sie für den Kontext den Clusternamen der neuen Region fest:
```
kubectl config use-context new-cluster-name
```
5. Importieren Sie die Namespace-Konfiguration in den neuen Cluster. Achten Sie darauf, den "Namespace" in der Datei zu aktualisieren, wenn Sie in der neuen Region einen anderen Namespace verwenden:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importieren Sie das Secret in den neuen Cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Installieren Sie Hybrid in der neuen Region. Achten Sie darauf, dass die Datei overrides_your_cluster_name.yaml genau die TLS-Zertifikate enthält, die in der ersten Region konfiguriert sind, wie im vorherigen Abschnitt erläutert.
Führen Sie folgende zwei Befehle aus, um Hybrid in der neuen Region zu installieren:

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.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Prüfen Sie mit dem folgenden Befehl, ob die Hybridinstallation erfolgreich war:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.

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

Beispiel für eine erfolgreiche Einrichtung:

Datacenter: dc-1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein.
1. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Beispiel:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Erstellen Sie eine benutzerdefinierte Cassandra-Datenreplikationsdatei (YAML). Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen datareplication.yaml.
  Die Datei muss Folgendes enthalten:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Wobei:
  - REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen beliebigen Namen verwenden.
  - NAMESPACE ist der gleiche Namespace, der in overrides.yaml bereitgestellt wird. Dies ist normalerweise "apigee".
  - APIGEEORG_VALUE ist die Wertausgabe des Befehls kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name aus dem vorherigen Schritt. Zum Beispiele rg-hybrid-b7d3b9c
  - SOURCE_REGION ist der Name des Rechenzentrums in der Quellregion. Dies ist der Wert, der für cassandra:datacenter: in Ihrer overrides.yaml festgelegt ist.
  Beispiel:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Wenden Sie CassandraDataReplication mit dem folgenden Befehl an:
```
kubectl apply -f datareplication.yaml
```
4. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
  Hinweis: Die Neuerstellung kann je nach Datengröße 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
}
```

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

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

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

Das folgende Beispiel zeigt beispielhafte Logeinträge.

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

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

Cassandra-Clusterstatus prüfen

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

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

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

OpenShift

Seed-Host für mehrere Regionen konfigurieren

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

Achten Sie darauf, dass in der Datei overrides.yaml für Ihren ursprünglichen Cluster cassandra:hostNetwork auf true eingestellt ist. Beispiel:
```
cassandra:
  hostNetwork: true
```
Legen Sie den kubectl-Kontext auf den ursprünglichen Cluster fest, bevor Sie den Startnamen abrufen:
```
kubectl config use-context original-cluster-name
```

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

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

kubectl get pods -o wide -n apigee

NAME                      READY   STATUS      RESTARTS   AGE   IP          NODE                                          NOMINATED NODE
apigee-cassandra-default-0        1/1     Running     0          5d    10.0.0.11   gke-k8s-dc-2-default-pool-a2206492-p55d
apigee-cassandra-default-1        1/1     Running     0          5d    10.0.2.4    gke-k8s-dc-2-default-pool-e9daaab3-tjmz
apigee-cassandra-default-2        1/1     Running     0          5d    10.0.3.5    gke-k8s-dc-2-default-pool-e589awq3-kjch

Wählen Sie die IP-Adresse Ihres Cassandra-Quellhosts aus, der als multiregionaler Starthost verwendet werden soll. In diesem Beispiel ist dies der apigee-cassandra-default-0-Cluster, der Quellhost ist 10.0.0.11.
Kopieren Sie in Ihrem Rechenzentrum 2 die Überschreibungsdatei in eine neue Datei, deren Name den Clusternamen enthält. Beispiel: overrides_your_cluster_name.yaml.

Konfigurieren Sie in Rechenzentrum 2 cassandra.multiRegionSeedHost und cassandra.datacenter in overrides_your_cluster_name.yaml, wobei multiRegionSeedHost eine der vom vorherigen Befehl zurückgegebenen IP-Adressen ist:

cassandra:
     hostNetwork: true
     multiRegionSeedHost: seed_host_IP # Cassandra pod IP address from the source region.
     datacenter: data_center_name

Beispiel:

cassandra:
  hostNetwork: true
  multiRegionSeedHost: 10.0.0.11
  datacenter: "dc-2"

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

Neue Region einrichten

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

So richten Sie die neue Region ein:

Kopieren Sie das Zertifikat aus dem vorhandenen in den neuen Cluster. Der neue CA-Stamm wird von Cassandra und anderen Hybrid-Komponenten für mTLS verwendet. Daher ist es wichtig, dass im Cluster konsistente Zertifikate vorhanden sind.
1. Legen Sie für den Kontext den ursprünglichen Namespace fest:
```
kubectl config use-context original-cluster-name
```
2. Exportieren Sie die aktuelle Namespace-Konfiguration in eine Datei:
```
kubectl get namespace namespace -o yaml > apigee-namespace.yaml
```
3. Exportieren Sie das apigee-ca-Secret in eine Datei:
```
kubectl -n cert-manager get secret apigee-ca -o yaml > apigee-ca.yaml
```
4. Legen Sie für den Kontext den Clusternamen der neuen Region fest:
```
kubectl config use-context new-cluster-name
```
5. Importieren Sie die Namespace-Konfiguration in den neuen Cluster. Achten Sie darauf, den "Namespace" in der Datei zu aktualisieren, wenn Sie in der neuen Region einen anderen Namespace verwenden:
```
kubectl apply -f apigee-namespace.yaml
```
6. Importieren Sie das Secret in den neuen Cluster:
```
kubectl -n cert-manager apply -f apigee-ca.yaml
```
Installieren Sie Hybrid in der neuen Region. Achten Sie darauf, dass die Datei overrides_your_cluster_name.yaml genau die TLS-Zertifikate enthält, die in der ersten Region konfiguriert sind, wie im vorherigen Abschnitt erläutert.
Führen Sie folgende zwei Befehle aus, um Hybrid in der neuen Region zu installieren:

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.
```
apigeectl init -f overrides_your_cluster_name.yaml
```
```
apigeectl apply -f overrides_your_cluster_name.yaml
```
Prüfen Sie mit dem folgenden Befehl, ob die Hybridinstallation erfolgreich war:
```
apigeectl check-ready -f overrides_your_cluster_name.yaml
```

Prüfen Sie die Einrichtung des Cassandra-Clusters mit dem folgenden Befehl. Die Ausgabe sollte sowohl die vorhandenen als auch die neuen Rechenzentren enthalten.

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

Beispiel für eine erfolgreiche Einrichtung:

Datacenter: dc-1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.87.93   68.07 GiB  256     ?     fb51465c-167a-42f7-98c9-b6eba1de34de  c
UN  10.132.84.94   69.9 GiB   256     ?     f621a5ac-e7ee-48a9-9a14-73d69477c642  b
UN  10.132.84.105  76.95 GiB  256     ?     0561086f-e95b-4232-ba6c-ad519ff30336  d

Datacenter: dc-2
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address        Load       Tokens  Owns  Host ID                               Rack
UN  10.132.0.8     71.61 GiB  256     ?     8894a98b-8406-45de-99e2-f404ab10b5d6  c
UN  10.132.9.204   75.1 GiB   256     ?     afa0ffa3-630b-4f1e-b46f-fc3df988092e  a
UN  10.132.3.133   68.08 GiB  256     ?     25ae39ab-b39e-4d4f-9cb7-de095ab873db  b

Richten Sie Cassandra auf allen Pods in den neuen Rechenzentren ein.
1. Rufen Sie mit dem folgenden Befehl apigeeorg aus dem Cluster ab:
```
kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
```
  Beispiel:
```
Ex: kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name
"rg-hybrid-b7d3b9c"
```
2. Erstellen Sie eine benutzerdefinierte Cassandra-Datenreplikationsdatei (YAML). Die Datei kann einen beliebigen Namen haben. In den folgenden Beispielen hat die Datei den Namen datareplication.yaml.
  Die Datei muss Folgendes enthalten:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: REGION_EXPANSION
  namespace: NAMESPACE
spec:
  organizationRef: APIGEEORG_VALUE
  force: false
  source:
    region: SOURCE_REGION
```
  Wobei:
  - REGION_EXPANSION ist der Name, den Sie diesen Metadaten geben. Sie können einen beliebigen Namen verwenden.
  - NAMESPACE ist der gleiche Namespace, der in overrides.yaml bereitgestellt wird. Dies ist normalerweise "apigee".
  - APIGEEORG_VALUE ist die Wertausgabe des Befehls kubectl get apigeeorg -n apigee -o json | jq .items[].metadata.name aus dem vorherigen Schritt. Zum Beispiele rg-hybrid-b7d3b9c
  - SOURCE_REGION ist der Name des Rechenzentrums in der Quellregion. Dies ist der Wert, der für cassandra:datacenter: in Ihrer overrides.yaml festgelegt ist.
  Beispiel:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: rg-hybrid-b7d3b9c
  force: false
  source:
    region: "dc-1"
```
3. Wenden Sie CassandraDataReplication mit dem folgenden Befehl an:
```
kubectl apply -f datareplication.yaml
```
4. Überprüfen Sie den Status der Neuerstellung mit dem folgenden Befehl.
  Hinweis: Die Neuerstellung kann je nach Datengröße 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
}
```

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

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

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

Das folgende Beispiel zeigt beispielhafte Logeinträge.

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

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

Cassandra-Clusterstatus prüfen

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

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

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

Fehlerbehebung

Siehe Fehler bei Cassandra-Datenreplikation.

Sofern nicht anders angegeben, sind die Inhalte dieser Seite unter der Creative Commons Attribution 4.0 License und Codebeispiele unter der Apache 2.0 License lizenziert. Weitere Informationen finden Sie in den Websiterichtlinien von Google Developers. Java ist eine eingetragene Marke von Oracle und/oder seinen Partnern.

Zuletzt aktualisiert: 2024-04-22 (UTC).