Passer au contenu principal

Déploiement de redimensionnement

AVERTISSEMENT
  • Seule la mise à l'échelle est supportée.
  • La procédure de mise à l’échelle de Thingpark Enterprise dépend de la fonctionnalité de redimensionnement de volume du fournisseur de stockage du cluster Kubernetes. Si la fonctionnalité est Supportée, le déploiement sera mis à l’échelle sans interruption de service. Dans le cas contraire, il sera nécessaire de sauvegarder puis de restaurer le déploiement.

Planification de la montée en charge​

Avant de commencer la procédure :

  • Assurez-vous que votre licence correspond aux capacités du déploiement cible.

  • Assurez-vous que le cluster Kubernetes peut planifier les ressources de calcul supplémentaires requises par le segment cible (exprimées dans la matrice de dimensionnement). La montée en charge a également un impact sur le coût de stockage en nécessitant plus d’espace disque.

  • Récupérez vos fichiers de référence de personnalisation values-data-stack.yaml et values-thingpark-stack.yaml contenant la configuration de votre déploiement. Mettez à jour ces fichiers avec le nouveau fichier de profil :

    • Récupérer la nouvelle configuration de dimensionnement
    # Value in m,l,xl
    export SEGMENT=l
    export RELEASE=8.0.x
    export CONFIG_REPO_BASEURL=https://raw.githubusercontent.com/actility/thingpark-enterprise-kubernetes/v$RELEASE
    curl -O $CONFIG_REPO_BASEURL/values/sizing/values-$SEGMENT-segment.yaml

    Utilisez yq pour fusionner les fichiers de configuration :

    yq eval-all '. as $item ireduce ({}; . * $item)' values-storage.yaml \
    values-default-priority-class.yaml values-$SEGMENT-segment.yaml values-data-stack.yaml \
    | tee values-data-stack-all.yaml
    yq eval-all '. as $item ireduce ({}; . * $item)' values-storage.yaml \
    values-lb.yaml values-default-priority-class.yaml values-$SEGMENT-segment.yaml \
    values-thingpark-stack.yaml | tee values-thingpark-stack-all.yaml

Option A : Mise à l’échelle sans interruption​

Prérequis​

  • Le cluster Kubernetes doit utiliser un fournisseur de stockage Supportant le redimensionnement de volume.
  • StorageClass doit être configuré avec allowVolumeExpansion: true
  • Si l’opérateur strimzi n’a pas été installé à l’aide du chart Helm thingpark-data-controller, il doit être configuré avec createGlobalResources=true
  • Identifiez le nouveau dimensionnement des disques pour les composants suivants dans vos fichiers de configuration personnalisés
    • mariadb-galera : clé mariadb-galera.persistence.size
    • lrc : clé lrc.persistence.size

1. Montée en charge de la pile de données​

  1. Mettez à jour les Persistent Volume Claims de mariadb-galera avec la valeur mariadb-galera.persistence.size

    kubectl patch -n $NAMESPACE pvc data-mariadb-galera-0 -p '{"spec":{"resources":{"requests":{"storage":"<new_size>Gi"}}}}'
    kubectl patch -n $NAMESPACE pvc data-mariadb-galera-1 -p '{"spec":{"resources":{"requests":{"storage":"<new_size>Gi"}}}}'
    kubectl patch -n $NAMESPACE pvc data-mariadb-galera-2 -p '{"spec":{"resources":{"requests":{"storage":"<new_size>Gi"}}}}'
    Example to scale up to profile l
    kubectl patch -n $NAMESPACE pvc data-mariadb-galera-0 -p '{"spec":{"resources":{"requests":{"storage":"15Gi"}}}}'
    kubectl patch -n $NAMESPACE pvc data-mariadb-galera-1 -p '{"spec":{"resources":{"requests":{"storage":"15Gi"}}}}'
    kubectl patch -n $NAMESPACE pvc data-mariadb-galera-2 -p '{"spec":{"resources":{"requests":{"storage":"15Gi"}}}}'

    Surveillez que le contrôleur de stockage augmente progressivement chaque PVC.

    kubectl -n $NAMESPACE describe pvc data-mariadb-galera-0
    kubectl -n $NAMESPACE describe pvc data-mariadb-galera-1
    kubectl -n $NAMESPACE describe pvc data-mariadb-galera-2
    Example with AWS EBS storage controller
    Name:          data-mariadb-galera-0
    Namespace:     devops-test-resizing
    StorageClass:  thingpark-csi-gp2-xfs
    Status:        Bound
    Volume:        pvc-9a33ed9f-5439-473c-8c5f-03c83ae58b2e
    Labels:        app.kubernetes.io/instance=tpe-data
                   app.kubernetes.io/managed-by=Helm
                   app.kubernetes.io/name=mariadb-galera
    Annotations:   pv.kubernetes.io/bind-completed: yes
                   pv.kubernetes.io/bound-by-controller: yes
                   volume.beta.kubernetes.io/storage-provisioner: ebs.csi.aws.com
                   volume.kubernetes.io/selected-node: ip-10-252-3-105.eu-west-1.compute.internal
                   volume.kubernetes.io/storage-provisioner: ebs.csi.aws.com
    Finalizers:    [kubernetes.io/pvc-protection]
    Capacity:      15Gi
    Access Modes:  RWO
    VolumeMode:    Filesystem
    Used By:       mariadb-galera-0
    Events:
    Type    Reason                      Age    From                                                                                    Message
    ----    ------                      ----   ----                                                                                    -------
    Normal  WaitForFirstConsumer        13m    persistentvolume-controller                                                             waiting for first consumer to be created before binding
    Normal  Provisioning                13m    ebs.csi.aws.com_ebs-csi-controller-6f854796-5dx5n_888c33a4-9e9b-4fb7-82ce-006130b6851d  External provisioner is provisioning volume for claim "devops-test-resizing/data-mariadb-galera-0"
    Normal  ExternalProvisioning        13m    persistentvolume-controller                                                             Waiting for a volume to be created either by the external provisioner 'ebs.csi.aws.com' or manually by the system administrator. If volume creation is delayed, please verify that the provisioner is running and correctly registered.
    Normal  ProvisioningSucceeded       13m    ebs.csi.aws.com_ebs-csi-controller-6f854796-5dx5n_888c33a4-9e9b-4fb7-82ce-006130b6851d  Successfully provisioned volume pvc-9a33ed9f-5439-473c-8c5f-03c83ae58b2e
    Normal  Resizing                    2m56s  external-resizer ebs.csi.aws.com                                                        External resizer is resizing volume pvc-9a33ed9f-5439-473c-8c5f-03c83ae58b2e
    Normal  ExternalExpanding           2m56s  volume_expand                                                                           waiting for an external controller to expand this PVC
    Normal  FileSystemResizeRequired    2m50s  external-resizer ebs.csi.aws.com                                                        Require file system resize of volume on node
    Normal  FileSystemResizeSuccessful  2m14s  kubelet                                                                                 MountVolume.NodeExpandVolume succeeded for volume "pvc-9a33ed9f-5439-473c-8c5f-03c83ae58b2e" ip-10-252-3-105.eu-west-1.compute.internal

  2. Préparer la ressource psmdb pour l’extension

    kubectl patch -n $NAMESPACE psmdb mongo-replicaset --type='json' -p='[{"op": "add", "path": "/spec/enableVolumeExpansion", "value": true}]'

  3. Supprimez le StatefulSet mariadb-galera avec cascad=orphan

    kubectl -n $NAMESPACE delete sts --cascade=orphan mariadb-galera

  4. Mettez à jour (Mettre à jour) la release Helm tpe-data avec le fichier de personnalisation mis à jour avec le nouveau profil de dimensionnement

    helm upgrade  tpe-data -n $NAMESPACE  actility/thingpark-data -f values-data-stack-all.yaml

  5. Vérifiez que tous les PVC sont correctement mis à jour au dimensionnement cible

    kubectl -n $NAMESPACE get pvc
    NAME                                 STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS            VOLUMEATTRIBUTESCLASS   AGE
    data-0-kafka-cluster-kafka-0         Bound    pvc-742f63b3-514d-49b8-aaf8-9bf3b79f5d79   20Gi       RWO            thingpark-csi-gp2-xfs   <unset>                 18h
    data-0-kafka-cluster-kafka-1         Bound    pvc-dcc644e3-1735-40de-8eb0-cf84797530b3   20Gi       RWO            thingpark-csi-gp2-xfs   <unset>                 18h
    data-kafka-cluster-zookeeper-0       Bound    pvc-316e3a1a-aee0-4591-a59e-137a9330b40f   5Gi        RWO            thingpark-csi-gp2-xfs   <unset>                 18h
    data-kafka-cluster-zookeeper-1       Bound    pvc-a062ee17-f8b9-4b48-9103-d0d964817b47   5Gi        RWO            thingpark-csi-gp2-xfs   <unset>                 18h
    data-kafka-cluster-zookeeper-2       Bound    pvc-11b7cb24-3085-4ae7-85e7-6a845aacf626   5Gi        RWO            thingpark-csi-gp2-xfs   <unset>                 18h
    data-mariadb-galera-0                Bound    pvc-f0921f31-827c-43f1-937c-2845da9995bd   15Gi       RWO            thingpark-csi-gp2-xfs   <unset>                 17h
    data-mariadb-galera-1                Bound    pvc-0d3b5f4a-94df-4546-aacf-8aed80ee661b   15Gi       RWO            thingpark-csi-gp2-xfs   <unset>                 17h
    data-mariadb-galera-2                Bound    pvc-279907b9-bdf4-4de9-b514-b60570aaf35d   15Gi       RWO            thingpark-csi-gp2-xfs   <unset>                 17h
    data-zookeeper-0                     Bound    pvc-b26a6f85-dc31-468d-9eb9-8edd7b03247e   5Gi        RWO            thingpark-csi-gp2-xfs   <unset>                 18h
    data-zookeeper-1                     Bound    pvc-eaa40aa9-368d-4919-8873-056a375dcec5   5Gi        RWO            thingpark-csi-gp2-xfs   <unset>                 18h
    data-zookeeper-2                     Bound    pvc-0023eed1-3af1-4a89-bc9b-67d16f479f28   5Gi        RWO            thingpark-csi-gp2-xfs   <unset>                 18h
    mongod-data-mongo-replicaset-rs0-0   Bound    pvc-02cbe222-4ea2-41e2-bf95-40ec13f2cf0e   25Gi       RWO            thingpark-csi-gp2-xfs   <unset>                 16h
    mongod-data-mongo-replicaset-rs0-1   Bound    pvc-c014cdbb-fbfc-4d41-9f26-1085a9bbd88e   25Gi       RWO            thingpark-csi-gp2-xfs   <unset>                 16h
information

Si mongod-data-mongo-replicaset-rs0-* ou data-0-kafka-cluster-kafka-* ne sont pas correctement mis à jour, vérifiez respectivement les journaux des pods de déploiement psmdb-operator et strimzi-cluster-operator avant de contacter le Support.

2. Montée en charge de la pile Thingpark Enterprise​

Cette section n’est pas requise si la taille du disque lrc n’est pas modifiée (par exemple passage du profil m au profil l). Si lrc.persistence.size est modifiée par le nouveau profil, mettez à jour le PVC approprié.

  1. Mettez à jour les Persistent Volume Claims de lrc avec la valeur lrc.persistence.size

    kubectl patch -n $NAMESPACE pvc data-lrc-0 -p '{"spec":{"resources":{"requests":{"storage":"<new_size>Gi"}}}}'
    kubectl patch -n $NAMESPACE pvc data-lrc-1 -p '{"spec":{"resources":{"requests":{"storage":"<new_size>Gi"}}}}'

    Surveillez que le contrôleur de stockage augmente progressivement chaque PVC.

    kubectl -n $NAMESPACE describe pvc data-lrc-0
    kubectl -n $NAMESPACE describe pvc data-lrc-1

  2. Lorsque le redimensionnement du volume persistant est terminé, supprimez le StatefulSet lrc avec cascad=orphan

    kubectl -n $NAMESPACE delete sts --cascade=orphan lrc

  3. Enfin, mettez à jour la release Helm tpe avec le fichier de personnalisation mis à jour :

helm upgrade -i tpe --debug --timeout 20m -n $NAMESPACE \
  actility/thingpark-enterprise --version $THINGPARK_ENTERPRISE_VERSION \
  -f values-thingpark-stack-all.yaml

Option B : Mise à l’échelle avec sauvegarde et restauration​

La procédure de mise à l'échelle consiste à :

  1. Sauvegardez vos données du déploiement initial,
  2. Désinstallez les piles ThingPark Enterprise et ThingPark Data,
  3. Installez un nouveau déploiement vide de ThingPark Enterprise,
  4. Restaurez les données de la sauvegarde effectuée à l'Étape 1
ATTENTION

  • Il s'agit d'une opération majeure avec les impacts suivants :

    • Interruption de service pour les flux API/GUI et passerelle
    • Des paquets peuvent être perdus ou en file d'attente lors du redéploiement

  • La même version de ThingPark Enterprise doit être utilisée pour déployer l'infrastructure mise à l'échelle.

  • La sauvegarde doit être effectuée le plus proche possible de la désinstallation

1. Sauvegarder les données​

  1. Exécuter le script de sauvegarde en utilisant le point d'API exec de Kubernetes

    export NAMESPACE=thingpark-enterprise
    kubectl exec -it -n $NAMESPACE deploy/tp-backup-controller -- tp-backup -o backup

  2. Notez le nom de la sauvegarde pour la restauration

    kubectl exec -it -n $NAMESPACE deploy/tp-backup-controller -- tp-backup -o list

2) Désinstaller​

  1. Commencez par désinstaller les charts

    helm -n $NAMESPACE uninstall tpe tpe-controllers tpe-data tpe-data-controllers

  2. Supprimez l'espace de noms (nécessaire pour nettoyer toutes les données persistantes)

    kubectl delete ns $NAMESPACE

3) Nouveau déploiement de la version Helm​

En utilisant les fichiers de personnalisation values-data-stack-all.yaml et values-thingpark-stack-all.yaml récupérés précédemment, suivez la Procédure de déploiement pour redéployer ThingPark Enterprise sur votre cluster.

AVERTISSEMENT
  • Définissez la variable d'environnement RELEASE avec la même version du déploiement précédent de ThingPark Enterprise
  • Définissez la variable d'environnement SEGMENT avec le dimensionnement ciblé

5. Restauration de données​

Déclenchez la restauration des données (la commande demandera une confirmation) en utilisant le nom initial de la sauvegarde :

kubectl exec -it -n $NAMESPACE deploy/tp-backup-controller -- tp-backup -o restore -b %backup name%
Dernière mise à jour sur
Copyright © 2025 Actility
Sur cette page