In diesem Thema wird erläutert, wie Cassandra horizontal und vertikal skaliert und wie Cassandra herunterskaliert wird.
Cassandra-Skalierung skalieren
Cassandra horizontal skalieren
- Prüfen Sie, ob Ihr
apigee-data
-Knotenpool bei Bedarf zusätzliche Kapazitäten hat, bevor Sie Cassandra skalieren. Siehe auch Dedizierte Knotenpools konfigurieren. - Legen Sie den Wert des Konfigurationsattributs
cassandra.replicaCount
in Ihrer Überschreibungsdatei fest. Weitere Informationen zu diesem Attribut finden Sie in der Referenz zu Konfigurationsattributen. Siehe auch Komponenten der Laufzeitebene verwalten. - Änderungen anwenden Beispiele:
$APIGEE_HOME/apigeectl apply --datastore -f overrides/overrides.yaml
Cassandra-Skalierung vertikal skalieren
In diesem Abschnitt wird erläutert, wie Sie die Cassandra-Pods vertikal skalieren, um höhere CPU- und Speicheranforderungen zu erfüllen.
Übersicht
Für eine Bereitstellung mit Apigee hybriden Produktionsumgebungen empfehlen wir, dass Sie mindestens zwei separate Knotenpools erstellen: einen für zustandsorientierte Dienste (Cassandra) und einen für zustandslose Dienste (Laufzeit). Ein Beispiel finden Sie unter Anforderungen an GKE-Produktionscluster.
Für den zustandsorientierten Knotenpool von Cassandra empfehlen wir, mit acht CPU-Kernen und 30 GB Arbeitsspeicher zu beginnen. Nachdem der Knotenpool bereitgestellt wurde, können diese Einstellungen nicht mehr geändert werden. Siehe auch Cassandra für die Produktion konfigurieren.
Wenn Sie die Cassandra-Pods hochskalieren müssen, um höhere CPU- und Speicheranforderungen zu erfüllen, folgen Sie den in diesem Thema beschriebenen Schritten.
Cassandra-Pods skalieren
Führen Sie die folgenden Schritte aus, um die CPU und den Arbeitsspeicher für den zustandsorientierten Knotenpool für Cassandra zu erhöhen:
- Folgen Sie der Anleitung Ihrer Kubernetes-Plattform, um dem Cluster einen neuen Knotenpool hinzuzufügen. Unterstützte Plattformen werden in der Installationsanleitung aufgeführt.
- Prüfen Sie, ob der neue Knotenpool bereit ist:
kubectl get nodes -l NODE_POOL_LABEL_NAME=NODE_POOL_LABEL_VALUE
Beispielbefehl:
kubectl get nodes -l cloud.google.com/gke-nodepool=apigee-data-new
Beispielausgabe:
NAME STATUS ROLES AGE VERSION gke-apigee-data-new-441387c2-2h5n Ready <none> 4m28s v1.14.10-gke.17 gke-apigee-data-new-441387c2-6941 Ready <none> 4m28s v1.14.10-gke.17 gke-apigee-data-new-441387c2-nhgc Ready <none> 4m29s v1.14.10-gke.17
- Aktualisieren Sie die Überschreibungsdatei, um den neuen Knotenpool für Cassandra zu verwenden, und aktualisieren Sie die Pod-Ressourcen auf die erhöhte CPU-Anzahl und die gewünschte Speichergröße. Verwenden Sie für einen GKE-Cluster beispielsweise eine Konfiguration, die der folgenden ähnelt.
Wenn Sie eine andere Kubernetes-Plattform verwenden, müssen Sie den Wert
apigeeData.key
entsprechend anpassen:nodeSelector: requiredForScheduling: true apigeeData: key: "NODE_POOL_LABEL_NAME" value: "NODE_POOL_LABEL_VALUE" cassandra: resources: requests: cpu: NODE_POOL_CPU_NUMBER memory: NODE_POOL_MEMORY_SIZE
Beispiel:
nodeSelector: requiredForScheduling: true apigeeData: key: "cloud.google.com/gke-nodepool" value: "apigee-data-new" cassandra: resources: requests: cpu: 14 memory: 16Gi
- Wenden Sie die Überschreibungsdatei auf den Cluster an:
$APIGEECTL_HOME/apigeectl apply -f ./overrides/overrides.yaml --datastore
Wenn Sie diese Schritte ausführen, werden die Cassandra-Pods auf den neuen Knotenpool übertragen.
Cassandra herunterskalieren
Apigee Hybrid verwendet einen Ring von Cassandra-Knoten als StatefulSet. Cassandra bietet nichtflüchtigen Speicher für bestimmte Apigee-Entitäten auf Laufzeitebene. Weitere Informationen zu Cassandra finden Sie unter Informationen zur Laufzeitebene.
Cassandra ist ein ressourcenintensiver Dienst und sollte nicht in einem Pod mit anderen Hybriddiensten bereitgestellt werden. Je nach Last kann es sinnvoll sein, die Anzahl der Cassandra-Knoten im Ring in Ihrem Cluster herunterzuskalieren.
So skalieren Sie einen Cassandra-Ring allgemein herunter:
- Achten Sie darauf, dass der Cassandra-Cluster fehlerfrei ist und über genügend Speicher verfügt, um das Herunterskalieren zu unterstützen.
- Aktualisieren Sie das Attribut
cassandra.replicaCount
inoverrides.yaml
. - Wenden Sie die Konfigurationsaktualisierung an.
- Löschen Sie je nach Clusterkonfiguration den Anspruch auf ein nichtflüchtiges Volume oder ein Volume.
Das sollten Sie wissen
- Wenn ein anderer Knoten außer dem Knoten, der außer Betrieb genommen werden soll, fehlerhaft ist, fahren Sie nicht fort. Kubernetes kann die Pods aus dem Cluster nicht herunterskalieren.
- Skalieren Sie immer um einen Faktor von drei Knoten herunter oder hoch.
Cassandra herunterskalieren
- Bestätigen Sie, dass der Cluster fehlerfrei ist und alle Knoten ausgeführt werden, wie im folgenden Beispiel gezeigt:
kubectl get pods -n yourNamespace -l app=apigee-cassandra NAME READY STATUS RESTARTS AGE apigee-cassandra-default-0 1/1 Running 0 2h apigee-cassandra-default-1 1/1 Running 0 2h apigee-cassandra-default-2 1/1 Running 0 2h apigee-cassandra-default-3 1/1 Running 0 16m apigee-cassandra-default-4 1/1 Running 0 14m apigee-cassandra-default-5 1/1 Running 0 13m apigee-cassandra-default-6 1/1 Running 0 9m apigee-cassandra-default-7 1/1 Running 0 9m apigee-cassandra-default-8 1/1 Running 0 8m
kubectl -n yourNamespace exec -it apigee-cassandra-default-0 nodetool status Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.16.2.6 690.17 KiB 256 48.8% b02089d1-0521-42e1-bbed-900656a58b68 ra-1 UN 10.16.4.6 705.55 KiB 256 51.6% dc6b7faf-6866-4044-9ac9-1269ebd85dab ra-1 to UN 10.16.11.11 674.36 KiB 256 48.3% c7906366-6c98-4ff6-a4fd-17c596c33cf7 ra-1 UN 10.16.1.11 697.03 KiB 256 49.8% ddf221aa-80aa-497d-b73f-67e576ff1a23 ra-1 UN 10.16.5.13 703.64 KiB 256 50.9% 2f01ac42-4b6a-4f9e-a4eb-4734c24def95 ra-1 UN 10.16.8.15 700.42 KiB 256 50.6% a27f93af-f8a0-4c88-839f-2d653596efc2 ra-1 UN 10.16.11.3 697.03 KiB 256 49.8% dad221ff-dad1-de33-2cd3-f1a572367e6f ra-1 UN 10.16.14.16 704.04 KiB 256 50.9% 1feed042-a4b6-24ab-49a1-24d4cef95473 ra-1 UN 10.16.16.1 699.82 KiB 256 50.6% beef93af-fee0-8e9d-8bbf-efc22d653596 ra-1
- Prüfen Sie, ob im Cassandra-Cluster genügend Speicherplatz vorhanden ist, um das Herunterskalieren zu unterstützen. Nach dem Herunterskalieren sollten die Cassandra-Knoten nicht mehr als 75% ihres Speicherplatzes belegen.
Wenn Ihr Cluster beispielsweise 6 Cassandra-Knoten hat und alle zu etwa 50% voll sind, würde die Herunterskalierung auf drei Knoten alle drei bei 100 % belassen, sodass kein Platz für den weiteren Betrieb bleibt.
Wenn Sie allerdings 9 Cassandra-Knoten haben, die alle zu ca. 50% ausgelastet sind, würde die Herunterskalierung auf 6 Knoten alle verbleibenden Knoten bei einer Auslastung von ca. 75% belassen. Sie können herunterskalieren.
- Aktualisieren Sie das Attribut
cassandra.replicaCount
oder fügen Sie es der Dateioverrides.yaml
hinzu. Wenn die aktuelle Knotenanzahl beispielsweise 9 beträgt, ändern Sie sie auf 6:cassandra: replicaCount: 6 #
- Wenden Sie die Konfiguration auf Ihren Cluster an:
./apigeectl apply --datastore -f overrides/override.yaml
namespace/apigee unchanged secret/ssl-cassandra unchanged storageclass.storage.k8s.io/apigee-gcepd unchanged service/apigee-cassandra unchanged statefulset.apps/apigee-cassandra configured
- Prüfen Sie, ob alle verbleibenden Cassandra-Knoten ausgeführt werden:
kubectl get pods -n yourNamespace -l app=apigee-cassandra NAME READY STATUS RESTARTS AGE apigee-cassandra-default-0 1/1 Running 0 3h apigee-cassandra-default-1 1/1 Running 0 3h apigee-cassandra-default-2 1/1 Running 0 2h apigee-cassandra-default-3 1/1 Running 0 25m apigee-cassandra-default-4 1/1 Running 0 24m apigee-cassandra-default-5 1/1 Running 0 23m
- Prüfen Sie, ob der Wert
cassandra.replicaCount
der Anzahl der vom Befehlnodetool status
zurückgegebenen Knoten entspricht.Wenn Sie Cassandra beispielsweise auf drei Knoten herunterskaliert haben, gehen Sie so vor:
kubectl exec apigee-cassandra-default-0 -n apigee -- nodetool -u JMX_user -pw JMX_password status Datacenter: us-east1 ==================== Status=Up/Down |/ State=Normal/Leaving/Joining/Moving -- Address Load Tokens Owns (effective) Host ID Rack UN 10.16.2.6 1009.17 KiB 256 73.8% b02089d1-0521-42e1-bbed-900656a58b68 ra-1 UN 10.16.4.6 1055.55 KiB 256 75.6% dc6b7faf-6866-4044-9ac9-1269ebd85dab ra-1 to UN 10.16.11.11 999.36 KiB 256 72.8% c7906366-6c98-4ff6-a4fd-17c596c33cf7 ra-1 UN 10.16.1.11 1017.03 KiB 256 74.2% ddf221aa-80aa-497d-b73f-67e576ff1a23 ra-1 UN 10.16.5.13 1061.64 KiB 256 75.9% 2f01ac42-4b6a-4f9e-a4eb-4734c24def95 ra-1 UN 10.16.8.15 1049.42 KiB 256 74.9% a27f93af-f8a0-4c88-839f-2d653596efc2 ra-1
- Prüfen Sie nach dem Herunterskalieren des Cassandra-Clusters, ob pvcs (PersistentVolumeClaim) den verbleibenden Cassandra-Knoten entsprechen.
Rufen Sie die Namen der pvcs ab:
kubectl get pvc -n yourNamespace NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE cassandra-data-apigee-cassandra-default-0 Bound pvc-f9c2a5b9-818c-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 7h cassandra-data-apigee-cassandra-default-1 Bound pvc-2956cb78-818d-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 7h cassandra-data-apigee-cassandra-default-2 Bound pvc-79de5407-8190-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 7h cassandra-data-apigee-cassandra-default-3 Bound pvc-d29ba265-81a2-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 5h cassandra-data-apigee-cassandra-default-4 Bound pvc-0675a0ff-81a3-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 5h cassandra-data-apigee-cassandra-default-5 Bound pvc-354afa95-81a3-11e9-8862-42010a8e014a 100Gi RWO apigee-gcepd 5h
In diesem Beispiel sollten keine pvcs angezeigt werden, die den drei herunterskalierten Knoten entsprechen:
cassandra-data-apigee-cassandra-8
cassandra-data-apigee-cassandra-7
cassandra-data-apigee-cassandra-6