Configurer Cassandra pour la production

Cet article décrit les étapes requises et recommandées pour configurer le composant de base de données Cassandra pour une installation en production d'Apigee hybrid.

Configurations requises

Les configurations suivantes sont requises.

Assurer la haute disponibilité

Les clusters Cassandra nécessitent trois zones de disponibilité pour maintenir la disponibilité dans un environnement de production. Si une zone tombe en panne, les zones restantes continueront de répondre aux requêtes pendant sa remise en ligne. Si deux zones ou plus tombent en panne, Cassandra ne pourra pas répondre aux requêtes tant qu'au moins deux zones ne seront pas en ligne. Apigee recommande de remettre les zones en ligne dans les trois heures afin de minimiser le risque de mises à jour de données manquantes.

Configurer les paramètres de stockage Cassandra

Pour une installation en production d'Apigee hybrid, Google vous recommande d'ajouter les paramètres de stockage et de segment de mémoire suivants à votre fichier de remplacement et de les appliquer au cluster :

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

Appliquez les modifications à Cassandra à l'aide de la commande suivante : 

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

replicaCount

La valeur de replicaCount doit être un multiple de 3. Pour déterminer la valeur replicaCount souhaitée, tenez compte des éléments suivants :

  • Estimez la demande de trafic pour vos proxys.
  • Effectuez des tests de charge et effectuez des prédictions raisonnables sur votre utilisation du processeur.
  • Vous pouvez spécifier différentes valeurs replicaCount dans différentes régions.
  • Vous pouvez développer replicaCount dans le fichier de remplacement.

storageclass

Pour la production, le stockage Cassandra doit être une StorageClass SSD. Définissez la valeur de storageclass si vous n'utilisez pas la StorageClass Kubernetes par défaut pour votre cluster. Vous pouvez vérifier la StorageClass par défaut à l'aide de la commande suivante.

kubectl get storageclass

Le résultat doit se présenter sous la forme suivante : 

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

Suivez les instructions de la page Configuration de StorageClass si vous souhaitez modifier la StorageClass Kubernetes par défaut.

Pour vérifier le paramètre storageclass actuel, exécutez la commande suivante sur votre cluster : 

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

storageSize

Pour les installations de production, Google recommande une taille de stockage d'au moins 500 Gi (gibioctets). Vous pouvez modifier la taille de stockage en fonction des besoins de stockage de votre cluster. Consultez les instructions de la section Développer des volumes persistants Cassandra pour modifier la capacité de stockage.

Pour vérifier le paramètre de taille actuel, exécutez la commande suivante sur votre cluster: 

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

cpu et memory

Pour les installations de production, Google recommande au moins sept processeurs et un minimum de 15 Gi (gibioctets) par pod. Lorsque vous spécifiez cassandra.resources.requests.cpu et cassandra.resources.requests.memory, tenez compte du volume de trafic et des exigences de vos proxys en termes de processeur et de mémoire.

Pour vérifier le paramètre de processeur actuel, exécutez la commande suivante sur votre cluster : 

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

Pour vérifier le paramètre de mémoire actuel, exécutez la commande suivante sur votre cluster : 

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

maxHeapSize et heapNewSize

Ces propriétés déterminent le segment de mémoire maximal alloué aux processus Cassandra et la quantité par laquelle la mémoire est augmentée, respectivement, en mégaoctets (les tailles des segments de mémoire sont spécifiées en mégaoctets, et non en mébioctets). Pour les environnements de production, Google recommande les valeurs suivantes :

  • maxHeapSize: 8192M
  • heapNewSize: 1200M

Consultez la documentation de votre fournisseur de plate-forme Kubernetes pour connaître les valeurs de taille de segments de mémoire optimales.

Pour vérifier le paramètre maxHeapSize actuel, exécutez la commande suivante sur votre cluster : 

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

Pour vérifier le paramètre heapNewSize actuel, exécutez la commande suivante sur votre cluster : 

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

Pour en savoir plus sur ces paramètres de propriété, consultez la documentation de référence sur les propriétés de configuration.

Utiliser le stockage SSD pour les déploiements de production

Pour la base de données Cassandra, l'environnement d'exécution hybride accepte uniquement l'utilisation de volumes persistants créés de manière dynamique pour stocker les données. Les disques durs SSD (Solid-State Disk) locaux ne sont pas compatibles.

Si vous n'avez pas encore configuré de disque SSD pour Cassandra, vous devez configurer une définition StorageClass reposant sur un disque dur SSD et en faire la classe par défaut. Pour connaître la procédure détaillée, consultez la page Configuration de StorageClass.

Suivez les instructions de la page Configuration de StorageClass si vous souhaitez modifier la StorageClass Kubernetes par défaut.

Cette section décrit les configurations recommandées pour Cassandra.

Configurer un planning de sauvegarde quotidien

En cas de problème Cassandra multirégional suite à une mauvaise configuration, Google ne pourra pas restaurer les données d'exécution, ce qui entraînera une perte de données permanente.

Pour éviter de perdre des données, configurez un planning de sauvegarde quotidien. Surveillez la taille et la fréquence de vos sauvegardes, et assurez-vous d'être averti en cas d'échec du pipeline de sauvegarde.

Respecter les conditions minimales requises pour les clusters Cassandra

Suivez la configuration minimale du cluster pour Cassandra.

Traiter tous les environnements visibles par les clients comme des environnements de production

Même si votre installation hybride est considérée comme "non-prod", vous devrez peut-être quand même utiliser des paramètres prêts pour la production. Par exemple, les pannes lors des installations de tests d'acceptation utilisateur (UAT) doivent déclencher des incidents de priorité élevée.

Utilisez des paramètres prêts à la production, même pour les installations hybrides "hors production" destinées aux clients. Nous vous recommandons de respecter les mêmes principes pour tous les environnements destinés aux clients que pour les serveurs de production, comme indiqué dans cet article. En particulier, suivez les principes de reprise après sinistre à l'aide de replicaCount et des régions. Pour en savoir plus, consultez la section Configurer les paramètres de stockage Cassandra.