Configurar Cassandra para el entorno de producción

En este tema se describen los pasos obligatorios y recomendados para configurar el componente de la base de datos Cassandra en una instalación de producción de Apigee hybrid.

Configuraciones obligatorias

Debes tener las siguientes configuraciones.

Asegurar la alta disponibilidad

Los clústeres de Cassandra necesitan tres zonas de disponibilidad para mantener la disponibilidad en un entorno de producción. Si una zona deja de funcionar, las demás seguirán respondiendo a las solicitudes mientras la zona que ha fallado vuelve a estar online. Si dos o más zonas dejan de funcionar, Cassandra no podrá responder a las solicitudes hasta que al menos dos zonas estén online. Apigee recomienda que las zonas vuelvan a estar online en un plazo de tres horas para minimizar el riesgo de que falten actualizaciones de datos.

Configurar los ajustes de almacenamiento de Cassandra

Para una instalación de producción de Apigee hybrid, Google recomienda que añada los siguientes ajustes de almacenamiento y de montículo al archivo de anulaciones y que los aplique al clúster: 

cassandra:
  ...
  replicaCount: 3
  storage:
    storageclass: your-preferred-ssd-storage #If not using default storage for your cluster
    capacity: 500Gi
  resources:
    requests:
      cpu: 7
      memory: 15Gi
  maxHeapSize: 8192M
  heapNewSize: 1200M

Aplica los cambios en Cassandra con el siguiente comando: 

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

replicaCount

El valor de replicaCount debe ser un múltiplo de 3. Para determinar el valor de replicaCount que quieres, ten en cuenta lo siguiente:

  • Estima las demandas de tráfico de tus proxies.
  • Realiza pruebas de carga y haz predicciones razonables sobre el uso de la CPU.
  • Puedes especificar diferentes valores de replicaCount en distintas regiones.
  • Puedes ampliar el replicaCount en el futuro en tu archivo de anulaciones.

storageclass

En el entorno de producción, el almacenamiento de Cassandra debe ser un StorageClass SSD. Define el valor de storageclass si no utilizas la clase de almacenamiento de Kubernetes predeterminada para tu clúster. Puedes comprobar la StorageClass predeterminada con el siguiente comando.

kubectl get storageclass

La salida debería tener un aspecto similar a este: 

NAME                     PROVISIONER             RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
premium-rwo              pd.csi.storage.gke.io   Delete          WaitForFirstConsumer   true                   6d23h
standard                 kubernetes.io/gce-pd    Delete          Immediate              true                   6d23h
standard-rwo (default)   pd.csi.storage.gke.io   Delete          WaitForFirstConsumer   true                   6d23h

Sigue las instrucciones de la sección Configuración de StorageClass si quieres cambiar la clase de almacenamiento predeterminada de Kubernetes.

Para comprobar la configuración actual de storageclass, ejecuta el siguiente comando en tu clúster: 

kubectl get pvc -n NAMESPACE cassandra-data-apigee-cassandra-default-0 -o=jsonpath="{['.spec.storageClassName', '.metadata.annotations.volume\.beta\.kubernetes\.io/storage-class']}"

storageSize

Para las instalaciones de producción, Google recomienda un tamaño de almacenamiento de al menos 500 Gi (gibibytes). Puedes cambiar el tamaño del almacenamiento en función de las necesidades de almacenamiento de tu clúster. Consulta las instrucciones de Ampliar volúmenes persistentes de Cassandra para cambiar el tamaño del almacenamiento.

Para comprobar el ajuste de tamaño de almacenamiento actual, ejecuta el siguiente comando en tu clúster: 

kubectl get pvc -n NAMESPACE cassandra-data-apigee-cassandra-default-0 -o=jsonpath='{.spec.resources.requests.storage}'

cpu y memory

Para las instalaciones de producción, Google recomienda al menos 7 CPUs y un mínimo de 15 Gi (gibibytes) por pod. Al especificar cassandra.resources.requests.cpu y cassandra.resources.requests.memory, ten en cuenta el volumen de tráfico y las demandas de CPU y memoria de tus proxies.

Para comprobar la configuración actual de la CPU, ejecuta el siguiente comando en tu clúster: 

kubectl get pods -n NAMESPACE apigee-cassandra-default-0 -o=jsonpath='{.spec.containers[].resources.requests.cpu}'

Para comprobar la configuración de memoria actual, ejecuta el siguiente comando en tu clúster: 

kubectl get pods -n NAMESPACE apigee-cassandra-default-0 -o=jsonpath='{.spec.containers[].resources.requests.memory}'

maxHeapSize y heapNewSize

Estas propiedades determinan la cantidad máxima de memoria asignada a los procesos de Cassandra y la cantidad en la que se aumenta la memoria, respectivamente, en megabytes (los tamaños del montículo se especifican en megabytes, no en mebibytes). En los entornos de producción, Google recomienda los siguientes valores:

  • maxHeapSize: 8192M
  • heapNewSize: 1200M

Consulta la documentación de tu proveedor de la plataforma de Kubernetes para obtener los valores óptimos del tamaño del montículo.

Para comprobar la configuración actual de maxHeapSize, ejecuta el siguiente comando en tu clúster: 

kubectl get sts -n NAMESPACE apigee-cassandra-default -o=jsonpath='{.spec.template.spec.containers[].env[?(@.name=="MAX_HEAP_SIZE")]}'

Para comprobar la configuración actual de heapNewSize, ejecuta el siguiente comando en tu clúster: 

kubectl get sts -n NAMESPACE apigee-cassandra-default -o=jsonpath='{.spec.template.spec.containers[].env[?(@.name=="HEAP_NEWSIZE")]}'

Para obtener más información sobre estos ajustes de propiedad, consulta la referencia de la propiedad de configuración.

Usar el almacenamiento SSD para las implementaciones de producción

En el caso de la base de datos Cassandra, el runtime híbrido solo admite el uso de volúmenes persistentes creados dinámicamente para almacenar datos. No se admiten unidades de disco de estado sólido (SSD) locales.

Si no tienes configurada una unidad SSD para Cassandra, debes configurar una definición de StorageClass que esté respaldada por una unidad de estado sólido (SSD) y convertirla en la clase predeterminada. Para obtener instrucciones detalladas, consulta la configuración de StorageClass.

Sigue las instrucciones de la sección Configuración de StorageClass si quieres cambiar la clase de almacenamiento predeterminada de Kubernetes.

En esta sección se describen las configuraciones recomendadas para Cassandra.

Configurar una programación de copias de seguridad diaria

En caso de que se produzca un problema con Cassandra multirregional debido a una configuración incorrecta, Google no podrá restaurar los datos de tiempo de ejecución, lo que provocará una pérdida de datos permanente.

Para evitar la pérdida de datos, configura una programación de copias de seguridad diaria. Monitoriza el tamaño y la frecuencia de las copias de seguridad, y asegúrate de recibir una notificación cuando falle el proceso de creación de copias de seguridad.

Cumplir los requisitos mínimos de clúster de Cassandra

Sigue la configuración mínima de clústeres para Cassandra.

Tratar todos los entornos orientados al cliente como entornos de producción

Aunque tu instalación híbrida se considere "no productiva", es posible que necesites ajustes listos para producción. Por ejemplo, las interrupciones en las instalaciones de las pruebas de aceptación de usuarios (UAT) deben activar incidentes de alta prioridad.

Usa ajustes listos para producción incluso en instalaciones híbridas orientadas al cliente que no sean de producción. Te recomendamos que sigas los mismos principios en todos los entornos orientados a los clientes que en los servidores de producción, tal como se indica en este artículo. En concreto, sigue los principios de recuperación tras desastres con replicaCount y regiones. Para obtener más información, consulta Configurar los ajustes de almacenamiento de Cassandra.