Questa pagina è stata tradotta dall'API Cloud Translation.

Scalabilità di Cassandra

Questo argomento illustra come fare lo scale up di Cassandra orizzontalmente e verticalmente e come fare lo scale down di Cassandra.

Scalabilità orizzontale di Cassandra

Fare lo scale up di Cassandra orizzontalmente

Assicurati che il pool di nodi apigee-data abbia capacità aggiuntiva, se necessario, prima di scalare Cassandra. Vedi anche Configurazione dei pool di nodi dedicati.
Imposta il valore della proprietà di configurazione cassandra.replicaCount nel file di override. Il valore di replicaCount deve essere un multiplo di 3. Per determinare il valore di replicaCount che preferisci, considera quanto segue:
- Stima la domanda di traffico per i proxy.
- Esegui un test di carico ed effettua previsioni ragionevoli sull'utilizzo della CPU.
- Puoi specificare valori replicaCount diversi a seconda dell'area geografica.
- In futuro potrai espandere replicaCount nel file di override.
Per informazioni su questa proprietà, consulta il riferimento sulla proprietà Configuration. Vedi anche Gestire i componenti del piano di runtime.

Nota: il fattore di replica predefinito per tutti gli spazi delle chiavi è tre. Di conseguenza, consigliamo di scalare le repliche di un fattore 3.
Applica le modifiche. Ad esempio:
```
helm upgrade datastore apigee-datastore/ \
  --namespace apigee \
  --atomic \
  -f OVERRIDES_FILE.yaml
```
Nota: se viene visualizzato un errore che indica Error: UPGRADE FAILED: "datastore" has no deployed releases, sostituisci upgrade con install e riprova a eseguire il comando.

Scalabilità verticale di Cassandra

Questa sezione spiega come scalare verticalmente i pod Cassandra per soddisfare requisiti di CPU e memoria più elevati.

Panoramica

Per un deployment di produzione ibrido 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, consulta Requisiti per i cluster di produzione di GKE.

Per il pool di nodi Cassandra stateful, consigliamo di iniziare con 8 core della CPU e 30 GB di memoria. Una volta eseguito il provisioning del pool di nodi, queste impostazioni non possono essere modificate. Vedi anche Configurare Cassandra per la produzione.

Se hai bisogno di fare lo scale up dei pod Cassandra per soddisfare requisiti di CPU e memoria più elevati, segui i passaggi descritti 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 tua 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 di override per utilizzare il nuovo pool di nodi per Cassandra e aggiorna le risorse pod in base al numero di CPU e alle dimensioni della memoria maggiori che vuoi utilizzare. Ad esempio, per un cluster GKE, utilizza una configurazione simile alla seguente. Se utilizzi un'altra piattaforma Kubernetes, devi regolare il valore di 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 di 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.

Fare lo scale down di Cassandra

Apigee hybrid utilizza un anello di nodi Cassandra come StatefulSet. Cassandra fornisce spazio di archiviazione permanente per determinate entità Apigee sul 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 su un pod con altri servizi ibridi. A seconda del carico, è possibile scalare il numero di nodi Cassandra nell'anello verso il basso nel cluster.

Il processo generale per lo scale down di un anello Cassandra è il seguente:

Assicurati che il cluster Cassandra sia integro e abbia spazio di archiviazione sufficiente per supportare lo scale down.
Aggiorna la proprietà cassandra.replicaCount in overrides.yaml.
Applica l'aggiornamento della configurazione.
Elimina l'attestazione o il volume del volume permanente, a seconda della configurazione del cluster.

Cosa è importante sapere

Se un nodo diverso da quelli da ritirare non è integro, non procedere. Kubernetes non potrà scalare i pod dal cluster.
Fai sempre fare lo scale down o lo scale up di un fattore di tre nodi.

Scalabilità: Cassandra

Verifica che il cluster sia integro e che tutti i nodi siano in esecuzione, come mostrato nell'esempio seguente:

 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 lo scale down, lo spazio di archiviazione dei nodi Cassandra non dovrebbe essere superiore al 75%.
Ad esempio, se il cluster ha 6 nodi Cassandra e sono tutti pieni circa al 50%, il downgrade a tre nodi lascerà tutti e tre al 100%, senza lasciare alcuna stanza per continuare il funzionamento.

Tuttavia, se hai 9 nodi Cassandra, tutti pieni circa il 50%, il ridimensionamento a 6 nodi lascerà tutti i nodi rimanenti circa il 75%. Puoi eseguire il downgrade.

Nota: è pratica comune mantenere i nodi Cassandra in multipli di tre.
Aggiorna o aggiungi la proprietà cassandra.replicaCount nel file overrides.yaml. Ad esempio, se il numero attuale di nodi è 9, cambialo 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 nodi Cassandra rimanenti 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 comando nodetool status.

Ad esempio, se hai scalato Cassandra fino 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 eseguito il downgrade del cluster Cassandra, verifica che i file pvcs (PersistentVolumeClaim) corrispondano ai nodi Cassandra rimanenti.

Procurati i nomi dei PC:

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 valori pvcs corrispondenti ai tre nodi diminuiti:

cassandra-data-apigee-cassandra-8
cassandra-data-apigee-cassandra-7
cassandra-data-apigee-cassandra-6