Escalamiento de Cassandra

En este tema, se describe cómo escalar Cassandra de forma horizontal y vertical, y cómo reducir la escala verticalmente de Cassandra.

Escala Cassandra de forma horizontal

Escala Cassandra horizontalmente

Asegúrate de que tu grupo de nodos apigee-data tenga capacidad adicional, según sea necesario, antes del escalamiento de Cassandra. Consulta también Configura grupos de nodos dedicados.
Establece el valor de la propiedad de configuración cassandra.replicaCount en tu archivo de anulaciones. El valor de replicaCount debe ser un múltiplo de 3. Para determinar el valor replicaCount deseado, considera lo siguiente:
- Estima las demandas de tráfico para tus proxies.
- Realiza una prueba de carga y haz predicciones razonables sobre el uso de CPU.
- Puedes especificar diferentes valores replicaCount en diferentes regiones.
- Puedes expandir el replicaCount en el futuro en el archivo de anulación.
Para obtener información sobre esta propiedad, consulta la referencia de propiedad de configuración. Consulta también Administra los componentes del plano del entorno de ejecución.

Nota: El factor de replicación predeterminado para todos los espacios de clave es tres. Como resultado, recomendamos el escalamiento de las réplicas según un factor de tres.
Aplica los cambios. Por ejemplo:
```
helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE.yaml
```
Nota: Si ves un error que dice Error: UPGRADE FAILED: "datastore" has no deployed releases, reemplaza upgrade por install y vuelve a intentar aplicar el comando.

Escala Cassandra forma vertical

En esta sección, se explica cómo escalar de manera vertical los Pods de Cassandra para cumplir con los requisitos de CPU y memoria más altos.

Descripción general

En el caso de una implementación de producción de Apigee Hybrid, recomendamos que crees al menos dos grupos de nodos diferentes: uno para los servicios con estado (Cassandra) y otro para los servicios sin estado (entorno de ejecución). Por ejemplo, consulta Requisitos de los clústeres de producción de GKE.

Para el grupo de nodos de Cassandra con estado, recomendamos comenzar con 8 núcleos de CPU y 30 GB de memoria. Una vez que se aprovisiona el grupo de nodos, no se puede cambiar esta configuración. Consulta también Configura Cassandra para la producción.

Si necesitas escalar verticalmente los pods de Cassandra para cumplir con los requisitos de CPU y memoria más altos, sigue los pasos que se describen en este tema.

Escala de forma vertical los pods de Cassandra

Sigue estos pasos a fin de aumentar la CPU y la memoria para el grupo de nodos con estado usado para Cassandra:

Sigue las instrucciones de la plataforma de Kubernetes para agregar un nuevo grupo de nodos al clúster. Las plataformas compatibles se enumeran en las instrucciones de instalación.

Verifica que el grupo de nodos nuevo esté listo:

kubectl get nodes -l NODE_POOL_LABEL_NAME=NODE_POOL_LABEL_VALUE

Comando de ejemplo:

kubectl get nodes -l cloud.google.com/gke-nodepool=apigee-data-new

Salida de ejemplo:

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

Actualiza el archivo de anulaciones a fin de usar el nuevo grupo de nodos para Cassandra y actualiza los recursos del Pod al mayor recuento de CPU y el tamaño de memoria que deseas usar. Por ejemplo, para un clúster de GKE, usa una configuración similar a la siguiente: Si estás en otra plataforma de Kubernetes, debes ajustar el valor apigeeData.key según corresponda:

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

Por ejemplo:

nodeSelector:
  requiredForScheduling: true
  apigeeData:
    key: "cloud.google.com/gke-nodepool"
    value: "apigee-data-new"

cassandra:
  resources:
    requests:
      cpu: 14
      memory: 16Gi

Aplica el archivo de manifiesto al clúster:

helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE.yaml

Cuando completes estos pasos, los Pods de Cassandra comenzarán a propagarse al nuevo grupo de nodos.

Reduce el escalamiento de Cassandra

Apigee Hybrid usa un anillo de nodos de Cassandra como un StatefulSet. Cassandra proporciona almacenamiento persistente para ciertas entidades de Apigee en el plano de entorno de ejecución. Para obtener más información sobre Cassandra, consulta Información sobre el plano de entorno de ejecución.

Cassandra es un servicio con uso intensivo de recursos y no se debe implementar en un Pod con cualquier otro servicio híbrido. Según la carga, te recomendamos escalar la cantidad de nodos de Cassandra en el círculo de abajo en tu clúster.

El proceso general para reducir el escalamiento de un anillo de Cassandra es el siguiente:

Asegúrate de que el clúster de Cassandra esté en buen estado y que tenga suficiente almacenamiento para admitir la reducción del escalamiento.
Actualiza la propiedad cassandra.replicaCount en overrides.yaml.
Aplica la actualización de configuración.
Borra el volumen o la reclamación de volumen persistente, según la configuración de tu clúster.

Qué debes saber

Si alguno de los nodos, que no es el que se retirará de servicio, está en mal estado, no continúes. Kubernetes no podrá reducir la escala de los Pods desde el clúster.
Siempre reduce la escala de forma horizontal o vertical utilizando un factor de tres nodos.

Escalamiento descendente de Cassandra

Verifica si el clúster está en buen estado y que todos los nodos estén en funcionamiento, como se muestra en el siguiente ejemplo:

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

kubectl -n APIGEE_NAMESPACE exec -it apigee-cassandra-default-0 nodetool status
Datacenter: dc-us-east1
====================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Dirección       Carga        Tokens       Propios  (efectivos)  ID de host                               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


PRECAUCIÓN: Si el clúster no está en buen estado o al menos un nodo

no está en funcionamiento, no continúes con este proceso.

Asegúrate de que el clúster de Cassandra tenga suficiente almacenamiento para admitir la reducción de la escala. Después de reducir el escalamiento, los nodos de Cassandra no deberían tener más del 75% de su almacenamiento lleno.
Por ejemplo, si tu clúster tiene 6 nodos de Cassandra y están casi un 50% llenos, la reducción de escala a tres nodos dejaría los tres al 100%, pero no dejaría espacio para la operación continua.

Sin embargo, si tienes 9 nodos Cassandra (con aproximadamente el 50% llenos), la reducción de escala a 6 nodos dejan cada nodo restante con alrededor del 75% completo. Puede reducir la escala.

Nota: Es común mantener los nodos de Cassandra en múltiplos de tres.
Actualiza o agrega la propiedad cassandra.replicaCount en el archivo overrides.yaml. Por ejemplo, si el recuento de nodos actual es 9, cámbialo a 6:
```
cassandra:
  replicaCount: 6 # 
```

Aplica el cambio de configuración al clúster.

helm upgrade datastore apigee-datastore/ \
  --namespace APIGEE_NAMESPACE \
  --atomic \
  -f OVERRIDES_FILE.yaml

Verifica que todos los nodos de Cassandra restantes se estén ejecutando:

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 que el valor cassandra.replicaCount sea igual a la cantidad de nodos que muestra el comando nodetool status.

Por ejemplo, si redujiste la escala de Cassandra a seis nodos:

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

Después de reducir la escala del clúster de Cassandra, verifica que el pvcs (PersistentVolumeClaim) corresponda a los nodos restantes de Cassandra.

Obtén los nombres de los 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

En este ejemplo, no deberías ver pcscs que correspondan con los tres nodos inferiores:

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