Questo argomento illustra come fare lo scale up di Cassandra orizzontalmente e verticalmente e come fare lo scale up da Cassandra.
Scalabilità orizzontale di Cassandra
per lo scale up di Cassandra in orizzontale
- Assicurati che il pool di nodi
apigee-data
abbia capacità aggiuntiva, se necessario, prima di scalare Cassandra. Vedi anche Configurazione di servizi pool di nodi. - Imposta il valore dell'attributo
cassandra.replicaCount
di configurazione automatica nel file di override. Il valore direplicaCount
deve essere un multiplo di3
. Per determinare il valore direplicaCount
che preferisci, ti consigliamo di prendere in considerazione le seguenti:- Stima le richieste di traffico per i proxy.
- Esegui il test di carico ed esegui previsioni ragionevoli sull'utilizzo della CPU.
- Puoi specificare valori
replicaCount
diversi in regioni diverse. - Puoi espandere
replicaCount
in futuro nel file degli override.
Per informazioni su questa proprietà, vedi consulta il riferimento delle proprietà di configurazione. Vedi anche Gestire i componenti del piano di runtime.
- Applica le modifiche. Ad esempio:
helm upgrade datastore apigee-datastore/ \ --namespace apigee \ --atomic \ -f OVERRIDES_FILE.yaml
Scalabilità verticale di Cassandra
Questa sezione spiega come scalare i pod Cassandra verticalmente per con requisiti di CPU e memoria più elevati.
Panoramica
Per un deployment di produzione ibrida Apigee, ti consigliamo di creare almeno due pool di nodi separati: uno per i servizi stateful (Cassandra) e uno per i servizi stateless (runtime). Ad esempio, vedi Requisiti per i cluster di produzione GKE.
Per il pool di nodi Cassandra stateful, consigliamo di iniziare con 8 core CPU e 30 GB di la memoria. Una volta eseguito il provisioning del pool di nodi, queste impostazioni non possono essere modificate. Vedi anche Configurare Cassandra per la produzione.
Se devi fare lo scale up dei pod Cassandra per soddisfare requisiti di CPU e memoria più elevati, segui la procedura descritta in questo argomento.
Fare lo scale up dei pod Cassandra
Segui questi passaggi per aumentare la CPU e la memoria per il pool di nodi stateful utilizzato per Cassandra:
- Segui le istruzioni della piattaforma Kubernetes per aggiungere un nuovo pool di nodi al cluster. Supportato sono indicate nelle istruzioni di installazione.
- Verifica che il nuovo pool di nodi sia pronto:
kubectl get nodes -l NODE_POOL_LABEL_NAME=NODE_POOL_LABEL_VALUE
Comando di esempio:
kubectl get nodes -l cloud.google.com/gke-nodepool=apigee-data-new
Output di esempio:
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
- Aggiorna il file degli override per utilizzare il nuovo pool di nodi per Cassandra e
aggiorna le risorse pod all'aumento del conteggio della CPU e delle dimensioni della memoria
che vuoi utilizzare. Ad esempio, per un cluster GKE, utilizza una configurazione simile alla seguente.
Se utilizzi un'altra piattaforma Kubernetes, devi modificare il valore
apigeeData.key
di conseguenza: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
Ad esempio:
nodeSelector: requiredForScheduling: true apigeeData: key: "cloud.google.com/gke-nodepool" value: "apigee-data-new" cassandra: resources: requests: cpu: 14 memory: 16Gi
- Applica il file degli override al cluster:
helm upgrade datastore apigee-datastore/ \ --namespace apigee \ --atomic \ -f OVERRIDES_FILE.yaml
Una volta completati questi passaggi, i pod Cassandra inizieranno a eseguire il rollback al nuovo pool di nodi.
Scale down di Cassandra
di Gemini Advanced.Apigee hybrid utilizza un anello di nodi Cassandra come StatefulSet. Cassandra offre archiviazione permanente per alcune entità Apigee sul piano di runtime. Per su Cassandra, consulta Informazioni il piano di runtime.
Cassandra è un servizio che richiede molte risorse e non deve essere implementato in un pod con altri ambienti ibridi i servizi di machine learning. A seconda del carico, ti consigliamo di scalare il numero di nodi Cassandra nell'anello verso il basso in un cluster Kubernetes.
Il processo generale per lo scale down di un anello Cassandra è:
- Assicurati che il cluster Cassandra sia integro e abbia spazio di archiviazione sufficiente per supportare lo scale down.
- Aggiorna la proprietà
cassandra.replicaCount
inoverrides.yaml
. - Applica l'aggiornamento della configurazione.
- Elimina la richiesta di volume permanente o il volume, a seconda della configurazione del cluster.
Informazioni importanti
- Se qualsiasi nodo diverso dai nodi da dismettere non è integro, non continuare. Kubernetes non sarà in grado di eseguire il downgrade dei pod dal cluster.
- Fai sempre fare lo scale down o lo scale up di un fattore di tre nodi.
Esegui il downgrade di Cassandra
- Verifica che il cluster sia integro e che tutti i nodi siano attivi e in esecuzione, come illustrato di seguito
un esempio mostra:
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-f1.672367e6f 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
- Determina se il cluster Cassandra dispone di spazio di archiviazione sufficiente per supportare lo scale down. Dopo la scalabilità
i nodi Cassandra non dovrebbero occupare più del 75% dello spazio di archiviazione.
Ad esempio, se il cluster ha sei nodi Cassandra e sono tutti pieni approssimativamente al 50%, lo scale down a tre nodi lascerebbe tutti e tre al 100%, il che non lascerebbe alcuno spazio la continuità delle operazioni.
Se invece hai 9 nodi Cassandra, tutti pieni all'incirca al 50%, con downscaling a 6 nodi ogni nodo rimanente sarà pieno circa il 75%. Puoi eseguire il downgrade.
- Aggiorna o aggiungi la proprietà
cassandra.replicaCount
inoverrides.yaml
. Ad esempio, se il conteggio attuale dei nodi è 9, modificalo in 6:cassandra: replicaCount: 6 #
- Applica la modifica alla configurazione al cluster:
helm upgrade datastore apigee-datastore/ \ --namespace apigee \ --atomic \ -f OVERRIDES_FILE.yaml
- Verifica che tutti i restanti nodi Cassandra siano in esecuzione:
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
- Verifica che il valore
cassandra.replicaCount
corrisponda al numero di nodi restituiti dal comandonodetool status
.Ad esempio, se hai fatto lo scale down di Cassandra a sei nodi:
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 1.65.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
- Dopo aver ridotto la scalabilità del cluster Cassandra, verifica che pvcs (PersistentVolumeClaim)
corrispondono ai nodi Cassandra rimanenti.
Trova i nomi dei PVC:
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 questo esempio non dovresti vedere i file PVC corrispondenti ai tre nodi con scalabilità ridotta:
cassandra-data-apigee-cassandra-8
cassandra-data-apigee-cassandra-7
cassandra-data-apigee-cassandra-6