Fehler bei der Cassandra-Datenreplikation

Sie lesen gerade die Dokumentation zu Apigee und Apigee Hybrid.
Apigee Edge-Dokumentation aufrufen.

Symptom

Wenn Sie Daten während einer multiregionalen Erweiterung replizieren, kann der Status CassandraDataReplication einen Fehlerstatus anzeigen und die Datenreplikation kann fehlschlagen.

Fehlermeldung

Wenn Sie kubectl verwenden, um den Status der Neuerstellung aufzurufen:

  kubectl -n apigee get apigeeds \
  -o jsonpath="{.items[].status.cassandraDataReplication}{'\n'}"

Sie sehen, dass bei einem oder mehreren Cassandra-Pods ein Fehlerstatus und die Meldung angezeigt werden, dass die Neuerstellung fehlgeschlagen ist. Beispiele:

{
  "rebuildDetails": {
    "apigee-cassandra-default-0": {
      "message": "failed to rebuild from us-west1: java.lang.IllegalStateException : Unable to find sufficient sources for streaming range (-8567285182390470134,-8567154549835592965] in keyspace system_distributed",
      "state": "error",
      "updated": 1641581899
    },
    …
  }
}

Mögliche Ursachen

Ursache	Beschreibung	Anleitungen zur Fehlerbehebung gelten für
Falsche Quellregion	Für die `source.region` in der YAML-Datei der Cassandra-Datenreplikation wurde ein falscher Wert angegeben.	Apigee hybrid
Probleme mit der Netzwerkverbindung	Es können Probleme mit der Netzwerkverbindung zwischen Cassandra-Pods in verschiedenen Rechenzentren auftreten.	Apigee hybrid

Allgemeine Diagnoseschritte

Rufen Sie den Status der Datenreplikation ab:

kubectl -n apigee get apigeeds \
-o jsonpath="{.items[].status.cassandraDataReplication}{'\n'}"

Wenn Sie einen Fehler mit einer Meldung ähnlich wie der unter Fehlermeldung erhalten, weist dies darauf hin, dass Sie dieses Problem beobachten.

Ursache: Falsche Quellregion

Wenn Sie in der YAML-Datei für die Datenreplikation eine Quellregion (datacenter) angeben, die sich vom tatsächlichen Quell-datacenter unterscheidet, schlägt die Datenreplikation fehl. Führen Sie die Schritte unter Diagnose aus, um dieses Szenario zu analysieren, und führen Sie die Schritte unter Lösung aus, um es zu korrigieren.

Diagnose

Listen Sie alle Cassandra-Pods in der Quellregion auf:
```
kubectl -n apigee get pods -l app=apigee-cassandra
```

Rufen Sie den tatsächlichen datacenter-Wert aus einem der in Schritt 1 zurückgegebenen Cassandra-Pods ab:

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

Rufen Sie den für source.region verwendeten Wert in der YAML-Datei (benutzerdefinierte Cassandra-Datenreplikationsdatei) ab, die Sie unter Multiregionale Bereitstellung erstellt haben. Wenn Sie den Beispieldateinamen aus der Dokumentation zur multiregionalen Bereitstellung verwenden, sollte die Datei den Namen datareplication.yaml haben.
```
cat datareplication.yaml
```
Beispielergebnisse:
```
apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: apigee-hybrid-example-org
  force: false
  source:
    region: "us-west1"
```

Prüfen Sie das Ergebnis der nodetool status-Ausgabe und prüfen Sie, ob der Wert datacenter mit dem Wert source.region übereinstimmt:

kubectl -n apigee exec -it apigee-cassandra-default-0 -- \
nodetool -u jmxuser -pw iloveapis123 status

Beispielergebnisse:

Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  10.104.13.2  491.84 KiB  256          100.0%            7254711c-fe0a-4b34-b50f-861109f97936  ra-1
UN  10.104.11.3  527.36 KiB  256          100.0%            5ec389f0-fd67-4de6-9f21-172d5899ff78  ra-1
UN  10.104.12.7  838.46 KiB  256          100.0%            7a88be82-1f81-4117-86e3-2cda434c0878  ra-1

Beachten Sie, dass die source.region (us-west1) aus der Datei datareplication.yaml nicht mit dem tatsächlichen datacenter-Wert (dc-1) aus der Statusausgabe nodetool übereinstimmt. Folgen Sie der Anleitung unter Lösung, um die Konfiguration zu korrigieren.

Lösung

Um die Datenreplikation zu korrigieren, müssen Sie den Datenreplikationsjob löschen und mit dem richtigen datacenter-Namen erstellen. Führen Sie diese Schritte aus:

Löschen Sie den aktuellen Datenreplikationsprozess. Wenn Sie den Beispieldateinamen aus der Dokumentation zur multiregionalen Bereitstellung verwenden, sollte die Datei den Namen datareplication.yaml haben.
```
kubectl delete -f datareplication.yaml
```

Aktualisieren Sie den Regionsnamen in der YAML-Datei auf den richtigen datacenter-Wert, z. B. dc-1:

apiVersion: apigee.cloud.google.com/v1alpha1
kind: CassandraDataReplication
metadata:
  name: region-expansion
  namespace: apigee
spec:
  organizationRef: apigee-hybrid-example-org
  force: false
  source:
    region: "dc-1"

Wenden Sie die aktualisierte Datenreplikation an:
```
kubectl apply -f datareplication.yaml
```
Prüfen Sie den Status der Neuerstellung mit dem folgenden Befehl und achten Sie darauf, dass der zuvor gemeldete Fehlerstatus nicht mehr angezeigt wird:
```
  kubectl -n apigee get apigeeds \
  -o jsonpath="{.items[].status.cassandraDataReplication}{'\n'}"
```
Wenn das Problem weiterhin besteht, fahren Sie mit Ursache: Probleme mit der Netzwerkverbindung fort.

Ursache: Probleme mit der Netzwerkverbindung

Der Datenreplikationsfehler kann auch das Ergebnis von Verbindungsproblemen zwischen Cassandra-Knoten sein.

Diagnose

Führen Sie die folgenden Schritte aus, um dieses Szenario zu analysieren:

Listen Sie alle Cassandra-Pods auf:

# list cassandra pods
kubectl -n=apigee get pods -l app=apigee-cassandra

Führen Sie den folgenden curl-Befehl und die Telnet-Verbindung zum ersten Cassandra-Pod im zweiten Rechenzentrum (dc-2) aus dem ersten Cassandra-Pod im ersten Rechenzentrum (dc-1) aus. Verwenden Sie dazu Port 7001:
```
kubectl -n apigee exec -it apigee-cassandra-default-0 bash -- curl -v telnet://DC_2_APIGEE_CASSANDRA_DEFAULT_0_POD_IP:7001
```

Wenn die Telnet-Verbindung erfolgreich war, wird eine Ausgabe ähnlich der folgenden angezeigt:

* Rebuilt URL to: telnet://10.0.4.10:7001/
*   Trying 10.0.4.10...
* TCP_NODELAY set
* Connected to 10.0.4.10 (10.0.4.10) port 7001 (#0)

Andernfalls wird ein Fehler wie der folgende angezeigt:

* Rebuilt URL to: telnet://10.0.4.10:7001/
*   Trying 10.0.4.10...
* TCP_NODELAY set
* connect to 10.0.4.10 port 7001 failed: Connection refused
* Failed to connect to 10.0.4.10 port 7001: Connection refused
* Closing connection 0
curl: (7) Failed to connect to 10.0.4.10 port 7001: Connection refused

Der Fehler bei der Verbindung vom Cassandra-Pod in einem Rechenzentrum zum Cassandra-Pod in einem anderen Rechenzentrum zeigt, dass eine Firewalleinschränkung oder ein Problem mit der Netzwerkverbindung vorliegt.

Lösung

Wenn sich diese Apigee Hybrid-Bereitstellung in GKE befindet, prüfen Sie, ob Firewallregeln vorhanden sind, die den Traffic von einem Rechenzentrum zu einem anderen blockieren, und analysieren Sie das Problem der Netzwerkverbindung. Verweisen Sie dazu auf Übersicht über VPC-Firewallregeln auf Ihrem Mobilgerät.
Wenn sich diese Apigee Hybrid-Bereitstellung in GKE On-Prem befindet, arbeiten Sie mit dem entsprechenden Netzwerkteam zusammen und analysieren Sie das Problem mit der Netzwerkverbindung.

Wenn das Problem weiterhin besteht, gehen Sie zu Erfassen von Diagnoseinformationen erforderlich.

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 Google Cloud Customer Care:

Die Google Cloud-Projekt-ID.
Die Apigee Hybrid-Organisation.
Die overrides.yaml-Dateien aus Quellregionen und neuen Regionen, mit denen vertrauliche Informationen maskiert werden.
Die CassandraDataReplication-YAML-Datei.

Cassandra-nodetool status-Ausgabe:

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

Cassandra-nodetool describecluster-Ausgabe:

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