Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Für dieses Thema gibt es keine entsprechende Apigee Edge-Dokumentation.
In diesem Thema werden Schritte erläutert, mit denen Sie Probleme mit dem Cassandra-Datenspeicher beheben können. Cassandra ist ein nichtflüchtiger Datenspeicher, der in der Komponente cassandra der Hybridlaufzeitarchitektur ausgeführt wird.
Weitere Informationen finden Sie unter Laufzeitdienst-Konfiguration – Übersicht.
Cassandra-Pods verbleiben im Release-Status
Symptom
Nach dem Versuch, eine Aktualisierung der Cassandra-Pods durchzuführen, meldet der Datenspeicher, dass er im Status "Release" festhängt.
Fehlermeldung
Wenn Sie den Pod-Status mit kubectl aufrufen, sehen Sie, dass ein oder mehrere Cassandra-Pods im Releasestatus verbleiben:
Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Ack 57s (x7 over 24h) apigee-datastore release started
Mögliche Ursachen
Ein Pod, der im Release-Status verbleibt, kann folgende Ursachen haben:
| Ursache | Beschreibung |
|---|---|
| Änderungen der Speicherkapazität |
Es wurden Schritte ausgeführt, um die Speicherkapazität in der Datei override.yaml zu ändern.
|
| Sonstige Konfigurationsänderungen |
An den Cassandra-Attributen in der Datei override.yaml wurden Aktualisierungen vorgenommen. Die Änderungen wurden jedoch nicht wirksam.
|
Änderungen der Speicherkapazität
Diagnose
-
Verwenden Sie
kubectl, um den aktuellen Status desapigee-Datenspeicher-Pods aufzurufen:kubectl get apigeeds -n apigee
NAME STATE AGE default releasing 122d
-
Prüfen Sie, ob Änderungen an der Datei
override.yamlvorgenommen wurden: -
Vergleichen Sie mithilfe Ihres Versionskontrollsystems die vorherige Version der
override.yaml-Datei mit der aktuellen Version:diff OVERRIDES_BEFORE.yaml OVERRIDES_AFTER.yaml
-
Die Ausgabe eines Diff-Befehls in der
override.yamlkann das mögliche Problem mit der Größe der Speicherkapazität anzeigen. Beispiel:# Overrides.yaml before: cassandra: storage: capacity: 500Gi # Overrides.yaml after: cassandra: storage: capacity: 100GiWenn bei einem Vorgang zum Ändern der Speicherkapazität Schritte übersprungen wurden, und wenn eine neue
override.yamldirekt angewendet wurde, kann dies dazu führen, dass der Datenspeicher im Release-Status bleibt. -
Prüfen Sie
statefulset, um sicherzugehen, dass ein Exemplar fürapigee-cassandra-defaultvorhanden ist:kubectl describe sts -n apigee
Die Ausgabe sieht in etwa so aus:
Name: apigee-cassandra-default Namespace: apigee CreationTimestamp: Tue, 18 Jul 2023 00:40:57 +0000 Selector: app=apigee-cassandra,name=default Labels: apigee.cloud.google.com.revision=v1-2cc098050836c6b4 apigee.cloud.google.com.version=v1 apigee.cloud.google.com/platform=apigee app=apigee-cassandra name=default Annotations: <none> Replicas: 3 desired | 3 total Update Strategy: RollingUpdate Partition: 0 Pods Status: 3 Running / 0 Waiting / 0 Succeeded / 0 Failed Pod Template: Labels: apigee.cloud.google.com/apigee_servicename=production apigee.cloud.google.com/billing_type=subscription apigee.cloud.google.com/platform=apigee app=apigee-cassandra name=default revision=v1 runtime_type=hybrid Annotations: apigee.cloud.google.com/pod-template-spec-hash: 2cc098050836c6b4 prometheus.io/path: /metrics prometheus.io/port: 7070 prometheus.io/scheme: https prometheus.io/scrape: true Containers: apigee-cassandra: Image: gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra:1.10.1 Ports: 7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP Host Ports: 7000/TCP, 7001/TCP, 7199/TCP, 9042/TCP, 8778/TCP Requests: cpu: 500m memory: 1Gi Readiness: exec [/bin/bash -c /opt/apigee/ready-probe.sh] delay=0s timeout=5s period=10s #success=1 #failure=2 Environment: POD_NAME: (v1:metadata.name) POD_IP: (v1:status.podIP) MAX_HEAP_SIZE: 512M HEAP_NEWSIZE: 100M CASSANDRA_SEEDS: apigee-cassandra-default-0.apigee-cassandra-default.apigee.svc.cluster.local CASSANDRA_CLUSTER_NAME: apigeecluster CASSANDRA_DC: dc-1 CASSANDRA_RACK: ra-1 CASSANDRA_OPEN_JMX: true CPS_ADMIN_USER: <set to the key 'admin.user' in secret 'apigee-datastore-default-creds'> Optional: false CPS_ADMIN_PASSWORD: <set to the key 'admin.password' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JMX_USER: <set to the key 'jmx.user' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JMX_PASSWORD: <set to the key 'jmx.password' in secret 'apigee-datastore-default-creds'> Optional: false CASS_PASSWORD: <set to the key 'default.password' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JOLOKIA_USER: <set to the key 'jolokia.user' in secret 'apigee-datastore-default-creds'> Optional: false APIGEE_JOLOKIA_PASSWORD: <set to the key 'jolokia.password' in secret 'apigee-datastore-default-creds'> Optional: false Mounts: /opt/apigee/apigee-cassandra/conf from appsfs (rw) /opt/apigee/customer from cwc-volume (ro) /opt/apigee/data from cassandra-data (rw) /opt/apigee/ssl from tls-volume (ro) /var/secrets/google from apigee-cassandra-backup (rw) /var/secrets/keys from apigee-cassandra-backup-key-file (rw) Volumes: cwc-volume: Type: Secret (a volume populated by a Secret) SecretName: config-cassandra-default Optional: false tls-volume: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-default-tls Optional: false appsfs: Type: EmptyDir (a temporary directory that shares a pod's lifetime) Medium: SizeLimit: <unset> apigee-cassandra-backup: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-backup-svc-account Optional: true apigee-cassandra-backup-key-file: Type: Secret (a volume populated by a Secret) SecretName: apigee-cassandra-backup-key-file Optional: true Volume Claims: Name: cassandra-data StorageClass: Labels: <none> Annotations: <none> Capacity: 10Gi Access Modes: [ReadWriteOnce] Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal SuccessfulCreate 47m statefulset-controller create Pod apigee-cassandra-default-2 in StatefulSet apigee-cassandra-default successful
-
Prüfen Sie den apigee-Controller auf Fehler:
kubectl logs -f apigee-controller-manager-59cf595c77-wtwnr -n apigee-system -c manager | grep apigeedatastore
Ergebnisse:
"error creating apigee-cassandra object: failed to update resource apigee/apigee-cassandra-default: StatefulSet.apps \"apigee-cassandra-default\" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbiddenerror creating apigee-cassandra object: failed to update resource apigee/apigee-cassandra-default: StatefulSet.apps \"apigee-cassandra-default\" is invalid: spec: Forbidden: updates to statefulset spec for fields other than 'replicas', 'template', 'updateStrategy', 'persistentVolumeClaimRetentionPolicy' and 'minReadySeconds' are forbidden"
Lösung
So können Sie den Status für Cassandra zurücksetzen, um ihn wieder in den aktiven Status zu versetzen:
- Deaktivieren Sie den
apigee-controller:kubectl -n apigee-system edit deployments and set --enable-controllers=true to --enable-controllers=false
-
Verwenden Sie den Befehl
PATCH, um den Datenspeicher wieder zu starten:curl -XPATCH \-H "Accept: application/json" -H "Content-Type: application/json-patch+json" --data '[{"op": "replace", "path": "/status/nestedState", "value": ""},{"op": "replace", "path": "/status/state", "value": "running"}]' 'http://127.0.0.1:8001/apis/apigee.cloud.google.com/v1alpha1/namespaces/apigee/apigeedatastores/default/status' -
Wenden Sie die ursprüngliche
override.yaml-Datei noch einmal an:./apigeectl apply --datastore -f overrides.yaml
-
Aktivieren Sie den
apigee-controller:kubectl -n apigee-system edit deployments and set --enable-controllers=false to --enable-controllers=true
-
Warten Sie, bis der Datenspeicher wieder aktiviert ist, und validieren Sie ihn mit:
kubectl get apigeeds --namespace apigee
-
Prüfen Sie, ob Apigee-Bereitstellungen und -Pods den Status „Wird ausgeführt“ haben und
apigeedsnicht mehr den Release-Status hat:kubectl get ad -n apigee
kubectl get pods -n apigee
kubectl get apigeeds -n apigee
NAME STATE AGE default running 24d
Weitere Konfigurationsänderungen
Änderungen an den cassandra-Attributen in override.yaml und Änderungen wurden nicht wirksam. Dies kann eine Passwortänderung oder Änderung an Ressourcen im override.yaml sein.
Oder es wurde fälschlicherweise die falsche override.yaml auf einen Cluster angewendet.
Diagnose
Schritte dazu finden Sie unter Diagnose.
Lösung
Weitere Informationen finden Sie unter Lösung.
Erfassen von Diagnoseinformationen erforderlich
Wenn das Problem auch nach Befolgen der obigen Anweisungen weiterhin besteht, sammeln Sie die folgenden Diagnoseinformationen und wenden Sie sich dann an den Google Cloud-Support:
-
Overrides.yamlfür jeden Cluster in der Installation. -
Ein Kubernetes-Cluster-Info-Dump aus der Hybridinstallation:
Kubernetes-
cluster-info dumpgenerieren:kubectl cluster-info dump -A --output-directory=/tmp/kubectl-cluster-info-dump
Kubernetes-
cluster-info dumpmit ZIP komprimieren:zip -r kubectl-cluster-info-dump`date +%Y.%m.%d_%H.%M.%S`.zip /tmp/kubectl-cluster-info-dump/*
Cassandra-Pods verbleiben im Status "Ausstehend"
Symptom
Nach dem Start verbleiben die Cassandra-Pods im Status Ausstehend.
Fehlermeldung
Wenn Sie den Pod-Status mit kubectl aufrufen, sehen Sie, dass ein oder mehrere Cassandra-Pods im Status Pending verbleiben. Der Status Pending gibt an, dass Kubernetes den Pod auf einem Knoten nicht planen kann: Der Pod kann nicht erstellt werden. Beispiel:
kubectl get pods -n NAMESPACE
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-default-0 0/1 Pending 0 10m
...Mögliche Ursachen
Ein Pod, der im Status "Ausstehend" verbleibt, kann mehrere Ursachen haben. Beispiel:
| Ursache | Beschreibung |
|---|---|
| Unzureichende Ressourcen | Es ist nicht genügend CPU oder Arbeitsspeicher zum Erstellen des Pods verfügbar. |
| Volume nicht erstellt | Der Pod wartet auf die Erstellung des nichtflüchtigen Volumes. |
| Amazon EBS CSI-Treiber fehlt | Bei EKS-Installationen ist der erforderliche Amazon EBS CSI-Treiber nicht installiert. |
Diagnose
Verwenden Sie kubectl, um den Pod zu beschreiben und die Ursache des Fehlers zu ermitteln. Beispiel:
kubectl -n NAMESPACE describe pods POD_NAME
Beispiel:
kubectl describe pods apigee-cassandra-default-0 -n apigee
Die Ausgabe kann eines der folgenden möglichen Probleme anzeigen:
- Wenn unzureichende Ressourcen das Problem sind, wird eine Warnmeldung angezeigt, dass die CPU oder der Arbeitsspeicher nicht ausreicht.
- Wenn in der Fehlermeldung darauf hingewiesen wird, dass der Pod ungebundene sofortige PersistentVolumeClaims (PVC) hat, kann der Pod kein nichtflüchtiges Volume erstellen.
Lösung
Unzureichende Ressourcen
Ändern Sie den Cassandra-Knotenpool so, dass er über ausreichende CPU- und Speicherressourcen verfügt. Weitere Informationen finden Sie unter Größe eines Knotenpools anpassen.
Kein nichtflüchtiges Volume erstellt
Wird ein Problem mit einem nichtflüchtigen Volume festgestellt, so beschreiben Sie den PVC (PersistentVolumeClaim), um festzustellen, warum er nicht erstellt wird:
- Listen Sie die PVCs im Cluster auf:
kubectl -n NAMESPACE get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cassandra-data-apigee-cassandra-default-0 Bound pvc-b247faae-0a2b-11ea-867b-42010a80006e 10Gi RWO standard 15m ...
- Beschreiben Sie den PVC für den Pod, der fehlschlägt. Mit dem folgenden Befehl wird beispielsweise der PVC beschrieben, der an den Pod
apigee-cassandra-default-0gebunden ist:kubectl apigee describe pvc cassandra-data-apigee-cassandra-default-0 Events: Type Reason Age From Message ---- ------ ---- ---- ------- Warning ProvisioningFailed 3m (x143 over 5h) persistentvolume-controller storageclass.storage.k8s.io "apigee-sc" not found
Beachten Sie, dass in diesem Beispiel die StorageClass namens
apigee-scnicht vorhanden ist. Erstellen Sie zum Beheben dieses Problems die fehlende StorageClass im Cluster, wie unter Standard-StorageClass ändern beschrieben.
Weitere Informationen finden Sie unter Pods debuggen.
Amazon EBS CSI-Treiber fehlt
Wenn die Hybridinstanz auf einem EKS-Cluster ausgeführt wird, achten Sie darauf, dass der EKS-Cluster den CSI-Treiber (Container Storage Interface) von Amazon EBS verwendet. Weitere Informationen finden Sie in den häufig gestellten Fragen zur Amazon EBS CSI-Migration.
Cassandra-Pods verbleiben im CrashLoopBackoff-Status
Symptom
Während des Starts verbleiben die Cassandra-Pods im Status CrashLoopBackoff.
Fehlermeldung
Wenn Sie den Pod-Status mit kubectl aufrufen, sehen Sie, dass sich ein oder mehrere Cassandra-Pods im Status CrashLoopBackoff befinden.
Dieser Status gibt an, dass Kubernetes den Pod nicht erstellen kann. Beispiel:
kubectl get pods -n NAMESPACE
NAME READY STATUS RESTARTS AGE
adah-resources-install-4762w 0/4 Completed 0 10m
apigee-cassandra-default-0 0/1 CrashLoopBackoff 0 10m
...Mögliche Ursachen
Ein Pod, der im Status CrashLoopBackoff verbleibt, kann mehrere Ursachen haben. Beispiel:
| Ursache | Beschreibung |
|---|---|
| Rechenzentrum unterscheidet sich vom vorherigen Rechenzentrum | Dieser Fehler weist darauf hin, dass der Cassandra-Pod ein nichtflüchtiges Volume mit Daten aus einem vorherigen Cluster hat und die neuen Pods dem alten Cluster nicht mehr beitreten können. Dies geschieht in der Regel, wenn veraltete nichtflüchtige Volumes vom vorherigen Cassandra-Cluster auf demselben Kubernetes-Knoten erhalten bleiben. Dieses Problem kann auftreten, wenn Sie Cassandra im Cluster löschen und neu erstellen. |
| Kubernetes-Upgrade | Ein Kubernetes-Upgrade kann sich auf den Cassandra-Cluster auswirken. Dies kann passieren, wenn die Anthos-Worker-Knoten, die die Cassandra-Pods hosten, auf eine neue Betriebssystemversion aktualisiert werden. |
Diagnose
Prüfen Sie das Cassandra-Fehlerlog, um die Ursache des Problems zu ermitteln.
- Listen Sie die Pods auf, um die ID des Cassandra-Pods zu erhalten, der fehlschlägt:
kubectl get pods -n NAMESPACE
- Prüfen Sie das Log des fehlerhaften Pods:
kubectl logs POD_ID -n NAMESPACE
Lösung
Suchen Sie die folgenden Hinweise im Log des Pods:
Rechenzentrum unterscheidet sich vom vorherigen Rechenzentrum
Wenn dieser Logeintrag angezeigt wird:
Cannot start node if snitch's data center (us-east1) differs from previous data center
- Prüfen Sie, ob der Cluster veraltete oder alte PVCs enthält und löschen Sie diese.
- Wenn es sich um eine Neuinstallation handelt, löschen Sie alle PVCs und wiederholen die Einrichtung. Beispiel:
kubectl -n NAMESPACE get pvckubectl -n NAMESPACE delete pvc cassandra-data-apigee-cassandra-default-0
Durch Anthos-Upgrade werden Sicherheitseinstellungen geändert
Prüfen Sie die Cassandra-Logs auf diese Fehlermeldung:
/opt/apigee/run.sh: line 68: ulimit: max locked memory: cannot modify limit: Operation not permitted
- Wenn die Hybrid-Instanz multiregional ist, deaktivieren Sie die betroffene Hybrid-Instanz und erweitern Sie sie wieder in die betroffene Region.
- Wenn die Hybrid-Instanz eine einzelne Region ist, führen Sie für jeden Cassandra-Pod in der Hybrid-Instanz einen rollierenden Neustart durch.
Client-Container zur Fehlerbehebung erstellen
In diesem Abschnitt wird erläutert, wie Sie einen Client-Container erstellen, über den Sie auf Cassandra-Debugging-Dienstprogramme wie cqlsh zugreifen können. Diese Dienstprogramme können zum Abfragen von Cassandra-Tabellen und für Fehlerbehebungszwecke nützlich sein.
Client-Container erstellen
So erstellen Sie den Client-Container:
- Der Container muss das TLS-Zertifikat aus dem Pod
apigee-cassandra-user-setupverwenden. Dies wird als Kubernetes-Secret gespeichert. Rufen Sie den Namen des Secrets ab, in dem dieses Zertifikat gespeichert ist:kubectl get secrets -n apigee --field-selector type=kubernetes.io/tls | grep apigee-cassandra-user-setup | awk '{print $1}'Dieser Befehl gibt den Namen des Secrets zurück. Beispiel:
apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls. Sie benötigen ihn in der YAML-Datei im FeldsecretName. - Öffnen Sie eine neue Datei und fügen Sie folgende Pod-Spezifikation in diese ein:
apiVersion: v1 kind: Pod metadata: labels: name: CASSANDRA_CLIENT_NAME # For example: my-cassandra-client namespace: apigee spec: containers: - name: CASSANDRA_CLIENT_NAME image: "gcr.io/apigee-release/hybrid/apigee-hybrid-cassandra-client:YOUR_APIGEE_HYBRID_VERSION" # For example, 1.10.5. imagePullPolicy: Always command: - sleep - "3600" env: - name: CASSANDRA_SEEDS value: apigee-cassandra-default.apigee.svc.cluster.local - name: APIGEE_DML_USER valueFrom: secretKeyRef: key: dml.user name: apigee-datastore-default-creds - name: APIGEE_DML_PASSWORD valueFrom: secretKeyRef: key: dml.password name: apigee-datastore-default-creds volumeMounts: - mountPath: /opt/apigee/ssl name: tls-volume readOnly: true volumes: - name: tls-volume secret: defaultMode: 420 secretName: YOUR_SECRET_NAME # For example: apigee-cassandra-user-setup-rg-hybrid-b7d3b9c-tls restartPolicy: Never
- Speichern Sie die Datei mit der Erweiterung
.yaml. Beispiel:my-spec.yaml - Wenden Sie die Spezifikation auf Ihren Cluster an:
kubectl apply -f YOUR_SPEC_FILE.yaml -n apigee
- Melden Sie sich beim Container an:
kubectl exec -n apigee CASSANDRA_CLIENT_NAME -it -- bash
- Stellen Sie mit dem folgenden Befehl eine Verbindung zur Cassandra-Schnittstelle
cqlshher. Geben Sie den Befehl genau so ein:cqlsh ${CASSANDRA_SEEDS} -u ${APIGEE_DML_USER} -p ${APIGEE_DML_PASSWORD} --ssl
Client-Pod löschen
Verwenden Sie diesen Befehl, um den Cassandra-Client-Pod zu löschen:
kubectl delete pods -n apigee cassandra-client
Falsch konfigurierte Regionserweiterung: alle Cassandra-Knoten unter einem Rechenzentrum
Diese Situation tritt bei einer multiregionalen Erweiterung auf GKE- und GKE On-Prem-Plattformen (Anthos) auf. Versuchen Sie nicht, alle Ihre Cassandra-Knoten im selben Rechenzentrum zu erstellen.
Symptom
Cassandra-Knoten werden im Rechenzentrum für die zweite Region nicht erstellt.
Fehlermeldung
failed to rebuild from dc-1: java.lang.RuntimeException : Error while rebuilding node: Stream failed
Lösung
Reparieren Sie die falsch konfigurierte Regionserweiterung mit den folgenden Schritten:
- Aktualisieren Sie den Cassandra-
replicaCountin der Dateioverrides.yamlfür das zweite Rechenzentrum auf1. Beispiel:cassandra: . . . replicaCount: 1
Wenden Sie die Einstellung mit
apigeectl applyan:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml
- Verwenden Sie
kubectl exec, um mit dem folgenden Befehl auf den verbleibenden Cassandra-Pod zuzugreifen:kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bash
- Nehmen Sie den verbleibenden Cassandra-Pod mit dem folgenden Befehl außer Betrieb:
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD decommission
- Löschen Sie die Cassandra-Pods aus dem zweiten Rechenzentrum mit
apigeectl deletemit dem Argument--datastore. Beispiel:$APIGEECTL_HOME/apigeectl delete -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Wechseln Sie mit dem Kubernetes-Kontext zum Cluster für Ihr erstes Rechenzentrum:
kubectl config use-context FIRST_DATACENTER_CLUSTER
- Achten Sie darauf, dass sich im ersten Rechenzentrum keine Cassandra-Knoten in einem inaktiven Zustand befinden.
nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status
- Prüfen Sie, ob die falsch konfigurierten Cassandra-Knoten (für das zweite Rechenzentrum) aus dem ersten Rechenzentrum entfernt wurden. Achten Sie darauf, dass die in der nodetool-Statusausgabe angezeigten IP-Adressen nur die IP-Adressen für die Cassandra-Pods sind, die für Ihr erstes Rechenzentrum vorgesehen sind. In der folgenden Ausgabe sollte beispielsweise die IP-Adresse
10.100.0.39für einen Pod in Ihrem ersten Rechenzentrum vorgesehen sein.kubectl exec -it -n apigee apigee-cassandra-default-0 -- /bin/bashnodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD statusDatacenter: dc-1 ================ Status=U/D (Up/Down) | State=N/L/J/M (Normal/Leaving/Joining/Moving) -- Address Load Tokens Owns (effective) Host ID Rack UN 10.100.0.39 4.21 MiB 256 100.0% a0b1c2d3-e4f5-6a7b-8c9d-0e1f2a3b4c5d ra-1 - Prüfen Sie, ob die Datei
overrides.yamlfür das zweite Rechenzentrum die Einstellung für den Rechenzentrumsnamen im Abschnitt „cassandra“ enthält. Beispiel:cassandra: datacenter: DATA_CENTER_2 rack: "RACK_NAME" # "ra-1" is the default value. . . .
- Aktualisieren Sie die Einstellung
cassandra:replicaCountin der Dateioverrides.yamlfür das zweite Rechenzentrum auf die gewünschte Zahl. Beispiel:cassandra: datacenter: DATA_CENTER_2 . . . replicaCount: 3
- Wenden Sie die Datei
overrides.yamlfür das zweite Rechenzentrum mit dem Argument--datastorean. Beispiel:$APIGEECTL_HOME/apigeectl apply -f 2ND_DATACENTER_OVERRIDES.yaml --datastore
- Verwenden Sie
kubectl exec, um auf einen der neuen Cassandra-Pods im zweiten Rechenzentrum zuzugreifen und zu prüfen, ob zwei Rechenzentren vorhanden sind:"nodetool -u CASSANDRA_DB_USER -pw CASSANDRA_DB_PASSWORD status"
Weitere Informationen
Einführung in Playbooks für Apigee X und Apigee Hybrid