Scaling de Cassandra

Vous consultez actuellement la version 1.9 de la documentation d'Apigee hybrid. Pour en savoir plus, consultez la section Versions compatibles.

Version 1.9 (unsupported)

   Versions compatibles :

• v1.13 (la plus récente)
• v1.12
• v1.11                         
• Liste des versions compatibles

   Versions non compatibles :

• v1.10
• v1.9                                         
• v1.8                                         
• v1.7                                         
• v1.6                                         
• v1.5                                         
• v1.4                                         
• v1.3                                         
• v1.2                                         
• v1.1                                         

Cet article explique comment effectuer un scaling à la hausse horizontal et vertical de Cassandra, et comment effectuer un scaling à la baisse de Cassandra.

Scaling horizontal de Cassandra

Pour effectuer un scaling horizontal de Cassandra

1. Assurez-vous que votre pool de nœuds apigee-data dispose de la capacité supplémentaire nécessaire, avant de procéder au scaling de Cassandra. Consultez également la section Configurer des pools de nœuds dédiés.
2. Définissez la valeur de la propriété de configuration cassandra.replicaCount dans votre fichier de remplacement. 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.

   Pour en savoir plus sur cette propriété, consultez la documentation de référence sur les propriétés de configuration. Consultez également la section Gérer les composants du plan d'exécution.

   Remarque : Le facteur de réplication par défaut pour tous les espaces de clés est de trois. C'est pourquoi nous vous recommandons de procéder au scaling des instances dupliquées avec un facteur de trois.
3. Appliquer les modifications Exemple :

   $APIGEE_HOME/apigeectl apply --datastore -f overrides/overrides.yaml

Scaling vertical de Cassandra

Cette section explique comment effectuer un scaling vertical des pods Cassandra afin de répondre aux exigences de ressources mémoire et de processeur supérieures.

Aperçu

Pour un déploiement de production d'Apigee hybrid, nous vous recommandons de créer au moins deux pools de nœuds distincts : un pour les services avec état (Cassandra) et un pour les services sans état (environnement d'exécution). Pour plus d'informations, consultez par exemple la page Configuration requise pour le cluster de production GKE.

Pour le pool de nœuds avec état Cassandra, nous vous recommandons de commencer avec 8 cœurs de processeur et 30 Go de mémoire. Une fois le pool de nœuds provisionné, ces paramètres ne peuvent plus être modifiés. Consultez également l'article Configurer Cassandra en production.

Si vous devez procéder à un scaling à la hausse des pods Cassandra pour répondre à des exigences plus strictes en termes de processeur et de mémoire, suivez la procédure décrite dans cette section.

Scaling à la hausse des pods Cassandra

Procédez comme suit pour augmenter la quantité de processeur et de mémoire du pool de nœuds avec état utilisé pour Cassandra :

1. Suivez les instructions de votre plate-forme Kubernetes pour ajouter un nouveau pool de nœuds au cluster. Les plates-formes compatibles sont répertoriées dans les instructions d'installation.
2. Vérifiez que le nouveau pool de nœuds est prêt :

   kubectl get nodes -l NODE_POOL_LABEL_NAME=NODE_POOL_LABEL_VALUE

   Exemple de commande :

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

   Exemple de résultat :

   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

3. Mettez à jour votre fichier de remplacement pour utiliser le nouveau pool de nœuds pour Cassandra, et modifiez à la hausse les ressources de pod en fonction du nombre de processeurs et de la taille de mémoire que vous souhaitez utiliser. Par exemple, pour un cluster GKE, vous pouvez baser votre configuration sur la configuration suivante. Si vous utilisez une autre plate-forme Kubernetes, vous devez ajuster la valeur apigeeData.key en conséquence :

   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

   Exemple :

   nodeSelector:
     requiredForScheduling: true
     apigeeData:
       key: "cloud.google.com/gke-nodepool"
       value: "apigee-data-new"
   
   cassandra:
     resources:
       requests:
         cpu: 14
         memory: 16Gi

4. Appliquez le fichier de remplacement au cluster :

   $APIGEECTL_HOME/apigeectl apply -f ./overrides/overrides.yaml --datastore

Une fois ces étapes terminées, les pods Cassandra seront transférés vers le nouveau pool de nœuds.

Scaling à la baisse de Cassandra

ATTENTION : Le scaling à la baisse des clusters Cassandra est plus invasive que le scaling à la hausse. Veuillez procéder avec prudence lors du scaling à la baisse

Apigee hybrid utilise un anneau de nœuds Cassandra en tant que StatefulSet. Cassandra fournit un espace de stockage persistant pour certaines entités Apigee sur le plan d'exécution. Pour en savoir plus sur Cassandra, consultez la page À propos du plan d'exécution.

Cassandra est un service nécessitant beaucoup de ressources et ne doit pas être déployé sur un pod avec d'autres services hybrides. En fonction de l'importance de la charge, vous voudrez peut-être effectuer un scaling à la baisse du nombre de nœuds Cassandra contenus dans l'anneau de votre cluster.

Le processus général de scaling à la baisse dans un anneau Cassandra est le suivant :

1. Assurez-vous que le cluster Cassandra est opérationnel et dispose d'un espace de stockage suffisant pour supporter le scaling à la baisse.
2. Mettez à jour la propriété cassandra.replicaCount dans overrides.yaml.
3. Appliquez la mise à jour de la configuration.
4. Supprimez la demande de volume persistant ou le volume, selon la configuration de votre cluster.

À savoir

• Si un nœud autre que le nœud à mettre hors service n'est pas opérationnel, ne poursuivez pas l'opération. Kubernetes ne pourra pas effectuer un scaling à la baisse des pods à partir du cluster.
• Effectuez toujours un scaling à la baisse ou à la hausse selon un facteur de trois nœuds.

Réduire la capacité de Cassandra

1. Vérifiez que le cluster est opérationnel et que tous les nœuds sont en cours d'exécution, comme le montre l'exemple suivant :

    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
   

   ATTENTION : Si le cluster n'est pas opérationnel ou si au moins un nœud ne fonctionne pas correctement, ne poursuivez pas ce processus.
2. Déterminez si le cluster Cassandra dispose d'un espace de stockage suffisant pour supporter le scaling à la baisse. Après cette opération, l'espace de stockage des nœuds Cassandra ne doit pas être occupé à plus de 75 %.

   Par exemple, si votre cluster comporte six nœuds Cassandra et que tous ont un espace de stockage occupé à 50 %, effectuer un scaling à la baisse vers un total de trois nœuds entraînerait une saturation totale de l'espace de stockage (100 %), ce qui ne laisserait aucune place pour les opérations continues.

   En revanche, si vous disposez de neuf nœuds Cassandra (50 % de l'espace de stockage de chacun étant occupé), un scaling à la baisse vers un total de 6 nœuds permet une occupation d'environ 75 % pour chacun d'entre eux. En ce cas, vous pouvez effectuer un scaling à la baisse.

   Remarque : Il est courant de gérer les nœuds Cassandra par multiples de trois.
3. Mettez à jour ou ajoutez la propriété cassandra.replicaCount dans votre fichier overrides.yaml. Par exemple, si le nombre de nœuds actuel est de 9, remplacez-le par 6 :

   cassandra:
     replicaCount: 6 # 

4. Appliquez la modification de configuration à votre cluster comme suit :

   ./apigeectl apply --datastore -f overrides/override.yaml

   namespace/apigee unchanged
   secret/ssl-cassandra unchanged
   storageclass.storage.k8s.io/apigee-gcepd unchanged
   service/apigee-cassandra unchanged
   statefulset.apps/apigee-cassandra configured

5. Vérifiez que tous les nœuds Cassandra restants sont en cours d'exécution :

   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
   
   

6. Vérifiez que la valeur cassandra.replicaCount correspond au nombre de nœuds renvoyés par la commande nodetool status.

   Par exemple, si vous avez effectué un scaling à la baisse des nœuds Cassandra en les faisant passer à six :

   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
   
   

7. Une fois le scaling à la baisse du cluster Cassandra effectué, vérifiez que les revendications de volume persistant (PersistentVolumeClaim) correspondent aux nœuds Cassandra restants.

   Obtenez les noms des revendications de volume persistant :

   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

   Dans cet exemple, vous ne devriez pas voir les revendications de volume persistant correspondant aux trois nœuds retirés :

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