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-datatenga 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.replicaCounten tu archivo de anulaciones. El valor dereplicaCountdebe ser un múltiplo de3. Para determinar el valorreplicaCountdeseado, 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
replicaCounten diferentes regiones. - Puedes expandir el
replicaCounten 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.
- Aplica los cambios. Por ejemplo:
helm upgrade datastore apigee-datastore/ \ --namespace APIGEE_NAMESPACE \ --atomic \ -f OVERRIDES_FILE.yaml
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.keysegú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.replicaCountenoverrides.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
- 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.
- Actualiza o agrega la propiedad
cassandra.replicaCounten el archivooverrides.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.replicaCountsea igual a la cantidad de nodos que muestra el comandonodetool 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-8cassandra-data-apigee-cassandra-7cassandra-data-apigee-cassandra-6