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
- Assurez-vous que votre pool de nœuds
apigee-datadispose de la capacité supplémentaire nécessaire, avant de procéder au scaling de Cassandra. Consultez également la page Configurer des pools de nœuds dédiés. - Définissez la valeur de la propriété de configuration
cassandra.replicaCountdans votre 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. - 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.
Présentation
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 :
- 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.
- 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
- 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.keyen 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_SIZEExemple :
nodeSelector: requiredForScheduling: true apigeeData: key: "cloud.google.com/gke-nodepool" value: "apigee-data-new" cassandra: resources: requests: cpu: 14 memory: 16Gi - 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
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 :
- Mise hors service d'un nœud Cassandra.
- Mettez à jour la propriété
cassandra.replicaCountdansoverrides.yaml. - Appliquez la mise à jour de la configuration.
- Répétez ces étapes pour chaque nœud que vous souhaitez supprimer.
- Supprimez la demande de volume persistant ou le volume, selon la configuration de votre cluster.
À savoir
- Effectuez cette tâche sur un nœud à la fois avant de passer au nœud suivant.
- 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.
Prérequis
Avant d'effectuer un scaling à la baisse du nombre de nœuds Cassandra contenus dans l'anneau, vérifiez que le cluster est opérationnel et que tous les nœuds fonctionnent correctement, 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
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 700.55 KiB 256 51.6% dc6b7faf-6866-4044-9ac9-1269ebd85dab ra-1 to UN 10.16.11.11 144.36 KiB 256 48.3% c7906366-6c98-4ff6-a4fd-17c596c33cf7 ra-1 UN 10.16.1.11 767.03 KiB 256 49.8% ddf221aa-80aa-497d-b73f-67e576ff1a23 ra-1 UN 10.16.5.13 193.64 KiB 256 50.9% 2f01ac42-4b6a-4f9e-a4eb-4734c24def95 ra-1 UN 10.16.8.15 132.42 KiB 256 50.6% a27f93af-f8a0-4c88-839f-2d653596efc2 ra-1
Mise hors service des nœuds Cassandra
-
Mettez hors service les nœuds Cassandra du cluster à l'aide de la commande nodetool.
kubectl -n yourNamespace exec -it nodeName nodetool decommission
Par exemple, cette commande met hors service
apigee-cassandra-5, le nœud dont le nom contient la valeur la plus élevée :kubectl -n apigee exec -it apigee-cassandra-5 nodetool decommission
- Attendez la fin de la mise hors service et vérifiez que le cluster compte désormais un nœud de moins. Exemple :
kubectl -n yourNamespace exec -it nodeName 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 710.37 KiB 256 59.0% b02089d1-0521-42e1-bbed-900656a58b68 ra-1 UN 10.16.4.6 720.97 KiB 256 61.3% dc6b7faf-6866-4044-9ac9-1269ebd85dab ra-1 UN 10.16.1.11 777.11 KiB 256 58.9% ddf221aa-80aa-497d-b73f-67e576ff1a23 ra-1 UN 10.16.5.13 209.23 KiB 256 62.2% 2f01ac42-4b6a-4f9e-a4eb-4734c24def95 ra-1 UN 10.16.8.15 143.23 KiB 256 58.6% a27f93af-f8a0-4c88-839f-2d653596efc2 ra-1
- Mettez à jour ou ajoutez la propriété
cassandra.replicaCountdans votre fichieroverrides.yaml. Par exemple, si le nombre de nœuds actuel est de 6, remplacez-le par 5 :cassandra: replicaCount: 5 # (n-1 5 in this example)
- Appliquez la modification de configuration à votre cluster comme suit :
./apigeectl apply --datastore namespace/apigee unchanged secret/ssl-cassandra unchanged storageclass.storage.k8s.io/apigee-gcepd unchanged service/apigee-cassandra unchanged statefulset.apps/apigee-cassandra configured
- 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
- Répétez les étapes 1 à 5 pour chaque nœud que vous souhaitez mettre hors service.
- Lorsque vous avez terminé de mettre les nœuds hors service, vérifiez que la valeur
cassandra.replicaCountcorrespond au nombre de nœuds renvoyés par la commandenodetool status.Par exemple, si vous avez effectué un scaling à la baisse des nœuds Cassandra en les faisant passer à trois :
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 710.37 KiB 256 59.0% b02089d1-0521-42e1-bbed-900656a58b68 ra-1 UN 10.16.4.6 720.97 KiB 256 61.3% dc6b7faf-6866-4044-9ac9-1269ebd85dab ra-1 UN 10.16.5.13 209.23 KiB 256 62.2% 2f01ac42-4b6a-4f9e-a4eb-4734c24def95 ra-1
- Une fois le cluster Cassandra réduit, assurez-vous de supprimer la revendication de volume persistant (PersistentVolumeClaim) pour que le prochain événement de scaling à la hausse n'utilise pas le même volume persistant et les données créées précédemment.
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, les revendications de volume persistant suivantes sont associées aux trois nœuds mis hors service :
cassandra-data-apigee-cassandra-5cassandra-data-apigee-cassandra-4cassandra-data-apigee-cassandra-3
- Supprimez les revendications de volume persistant :
kubectl -n yourNamespace delete pvc cassandra-data-apigee-cassandra-5 persistentvolumeclaim "cassandra-data-apigee-cassandra-5" deleted
kubectl -n yourNamespace delete pvc cassandra-data-apigee-cassandra-4 persistentvolumeclaim "cassandra-data-apigee-cassandra-4" deletedkubectl -n yourNamespace delete pvc cassandra-data-apigee-cassandra-3 persistentvolumeclaim "cassandra-data-apigee-cassandra-3" deleted - Vérifiez que la revendication de volume persistant a été supprimée :
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
- Si vous disposez d'une installation d'Anthos, supprimez le volume persistant du cluster Kubernetes d'Anthos en utilisant la même séquence.
Obtenez les noms des volumes persistants :
kubectl get pv -n youNamespace NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-0675a0ff-81a3-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-4 apigee-gcepd 5h pvc-2956cb78-818d-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-1 apigee-gcepd 7h pvc-354afa95-81a3-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-5 apigee-gcepd 5h pvc-79de5407-8190-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-2 apigee-gcepd 7h pvc-d29ba265-81a2-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-3 apigee-gcepd 5h pvc-f9c2a5b9-818c-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-0 apigee-gcepd 7h
Dans cet exemple, les volumes suivants correspondent aux trois nœuds mis hors service :
- 5 :
pvc-354afa95-81a3-11e9-8862-42010a8e014a - 4 :
pvc-0675a0ff-81a3-11e9-8862-42010a8e014a - 3 :
pvc-d29ba265-81a2-11e9-8862-42010a8e014a
- 5 :
- Supprimez les volumes persistants :
kubectl -n yourNamespace delete pv pvc-354afa95-81a3-11e9-8862-42010a8e014a
kubectl -n yourNamespace delete pv pvc-0675a0ff-81a3-11e9-8862-42010a8e014akubectl -n yourNamespace delete pv pvc-d29ba265-81a2-11e9-8862-42010a8e014a - Vérifiez que les volumes persistants ont bien été supprimés :
kubectl get pv -n youNamespace NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE pvc-2956cb78-818d-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-1 apigee-gcepd 7h pvc-79de5407-8190-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-2 apigee-gcepd 7h pvc-f9c2a5b9-818c-11e9-8862-42010a8e014a 100Gi RWO Delete Bound apigee/cassandra-data-apigee-cassandra-default-0 apigee-gcepd 7h