Questo argomento spiega come eseguire lo scale up di Cassandra orizzontalmente e verticalmente e come eseguire lo scale down di Cassandra.
Scalabilità orizzontale di Cassandra
Per eseguire lo scaling di Cassandra orizzontalmente
- Assicurati che il pool di nodi
apigee-data
abbia una capacità aggiuntiva, se necessario, prima di eseguire il ridimensionamento di Cassandra. Consulta anche Configurare i pool di nodi dedicati. - Imposta il valore della proprietà di configurazione
cassandra.replicaCount
nel file delle sostituzioni. Il valore direplicaCount
deve essere un multiplo di3
. Per determinare il valorereplicaCount
che preferisci, tieni conto di quanto segue:- Stimare le richieste di traffico per i proxy.
- Esegui un test di carico e fai previsioni ragionevoli sull'utilizzo della CPU.
- Puoi specificare valori
replicaCount
diversi in regioni diverse. - In futuro, potrai espandere
replicaCount
nel file delle sostituzioni.
Per informazioni su questa proprietà, consulta il riferimento per le proprietà di configurazione. Vedi anche Gestire i componenti del piano di runtime.
- Applica le modifiche. Ad esempio:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
Scalabilità verticale di Cassandra
Questa sezione spiega come eseguire la scalabilità verticale dei pod Cassandra per soddisfare requisiti di CPU e memoria più elevati.
Panoramica
Per un deployment di produzione ibrido di Apigee, ti consigliamo di creare almeno due pool di nodi distinti: uno per i servizi con stato (Cassandra) e uno per i servizi senza stato (runtime). Ad esempio, consulta i requisiti dei cluster di produzione GKE.
Per il pool di nodi Cassandra stateful, ti consigliamo di iniziare con 8 core CPU e 30 GB di memoria. Una volta eseguito il provisioning del pool di nodi, queste impostazioni non possono essere modificate. Consulta anche Configurare Cassandra per la produzione.
Se devi eseguire lo scale up dei pod Cassandra per soddisfare requisiti di CPU e memoria più elevati, segui i passaggi descritti in questo argomento.
Eseguire l'upgrade dei pod Cassandra
Per aumentare la CPU e la memoria per il pool di nodi con stato utilizzato per Cassandra:
- Segui le istruzioni della piattaforma Kubernetes per aggiungere un nuovo pool di nodi al cluster. Le piattaforme supportate sono elencate 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 delle sostituzioni per utilizzare il nuovo pool di nodi per Cassandra e
aggiorna le risorse del pod in base al numero di CPU e alle dimensioni della memoria incrementate 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 delle sostituzioni al cluster:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
Al termine di questi passaggi, i pod Cassandra inizieranno a eseguire il trasferimento al nuovo pool di nodi.
Riduzione della scalabilità di Cassandra
Apigee Hybrid utilizza un anello di nodi Cassandra come StatefulSet. Cassandra fornisce uno spazio di archiviazione persistente per determinate entità Apigee nel piano di runtime. Per maggiori informazioni su Cassandra, consulta Informazioni sul piano di runtime.
Cassandra è un servizio che richiede molte risorse e non deve essere implementato in un pod con altri servizi ibridi. A seconda del carico, ti consigliamo di ridurre il numero di nodi Cassandra nell'anello nel tuo cluster.
La procedura generale per ridurre le dimensioni di un anello Cassandra è la seguente:
- Assicurati che il cluster Cassandra sia in stato operativo e disponga di spazio di archiviazione sufficiente per supportare il ridimensionamento verso il basso.
- 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 un nodo diverso da quelli da ritirare non è integro, non continuare. Kubernetes non potrà eseguire il ridimensionamento dei pod dal cluster.
- Esegui sempre fare lo scale down o verso l'alto per un fattore di tre nodi.
Esegui il ridimensionamento di Cassandra verso il basso
- Verifica che il cluster sia integro e che tutti i nodi siano attivi e in esecuzione, come mostrato nell'esempio seguente:
kubectl get pods -n APIGEE_NAMESPACE -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
==================== 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-1kubectl -n APIGEE_NAMESPACE exec -it apigee-cassandra-default-0 nodetool status
Datacenter: dc-us-east1
- Determina se il cluster Cassandra dispone di spazio di archiviazione sufficiente per supportare il ridimensionamento verso il basso. Dopo la riduzione, i nodi Cassandra non devono avere più del 75% dello spazio di archiviazione occupato.
Ad esempio, se il tuo cluster ha 6 nodi Cassandra e sono tutti occupati per circa il 50%, il ridimensionamento a tre nodi lascerebbe tutti e tre al 100%, il che non lascerebbe spazio per il funzionamento continuo.
Tuttavia, se disponi di 9 nodi Cassandra, tutti occupati per circa il 50%, il ridimensionamento a 6 nodi lascerebbe ogni nodo rimanente occupato per circa il 75%. Puoi ridurre le dimensioni.
- Aggiorna o aggiungi la proprietà
cassandra.replicaCount
nel fileoverrides.yaml
. Ad esempio, se il numero di nodi corrente è 9, impostalo su 6:cassandra: replicaCount: 6 #
- Applica la modifica della configurazione al cluster:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
- Verifica che tutti i nodi Cassandra rimanenti siano in esecuzione:
kubectl get pods -n APIGEE_NAMESPACE -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 ridotto Cassandra a sei nodi:
kubectl exec apigee-cassandra-default-0 -n APIGEE_NAMESPACE -- 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 le dimensioni del cluster Cassandra, verifica che i pvcs (PersistentVolumeClaim)
corrispondano ai nodi Cassandra rimanenti.
Ottieni i nomi dei PVC:
kubectl get pvc -n APIGEE_NAMESPACE
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 PVC corrispondenti ai tre nodi ridotti:
cassandra-data-apigee-cassandra-8
cassandra-data-apigee-cassandra-7
cassandra-data-apigee-cassandra-6