Accéder au contenuNavigation Accéder à la page : page précédente [raccourci clavier p] / page suivante [raccourci clavier n]
documentation.suse.com / Documentation de SUSE Enterprise Storage 7 / Guide de déploiement / Mise à jour à partir de versions précédentes / Mise à niveau à partir d'une version précédente
S'applique à SUSE Enterprise Storage 7

7 Mise à niveau à partir d'une version précédente

Ce chapitre présente les étapes requises pour mettre à niveau SUSE Enterprise Storage 6 vers la version 7.

La mise à niveau inclut les tâches suivantes :

  • mise à niveau de Ceph Nautilus vers Octopus ;

  • passage de l'installation et de l'exécution de Ceph via des paquetages RPM à l'exécution dans des conteneurs ;

  • suppression complète de DeepSea et remplacement par ceph-salt et cephadm.

Avertissement
Avertissement

Les informations de mise à niveau de ce chapitre s'appliquent uniquement aux mises à niveau de DeepSea vers cephadm. N'essayez pas de suivre ces instructions si vous souhaitez déployer SUSE Enterprise Storage sur la plate-forme SUSE CaaS.

Important
Important

La mise à niveau des versions SUSE Enterprise Storage antérieures à la version 6 n'est pas prise en charge. Vous devez d'abord passer à la dernière version SUSE Enterprise Storage 6, puis suivre les étapes de ce chapitre.

7.1 Avant la mise à niveau

Les tâches suivantes doivent être effectuées avant de commencer la mise à niveau. Cette opération peut être effectuée à tout moment pendant la durée de vie de SUSE Enterprise Storage 6.

7.1.1 Considérations

Avant la mise à niveau, veillez à lire les sections suivantes pour vous assurer que vous comprenez toutes les tâches à exécuter.

  • Lisez les notes de version : elles contiennent des informations supplémentaires sur les modifications apportées depuis la version précédente de SUSE Enterprise Storage. Consultez les notes de version pour vérifier les aspects suivants :

    • votre matériel doit tenir compte de certaines considérations spéciales ;

    • les paquetages logiciels utilisés ont été considérablement modifiés ;

    • des précautions spéciales sont nécessaires pour votre installation.

    Les notes de version incluent également des informations de dernière minute qui, faute de temps, n'ont pas pu être intégrées au manuel. Elles contiennent également des notes concernant les problèmes connus.

    Les notes de version de SES 7 sont disponibles en ligne à l'adresse https://www.suse.com/releasenotes/.

    En outre, après avoir installé le paquetage release-notes-ses à partir de l'espace de stockage SES 7, vous trouverez les notes de version en local dans le répertoire /usr/share/doc/release-notes ou en ligne à l'adresse https://www.suse.com/releasenotes/.

  • Lisez le Chapitre 5, Déploiement avec cephadm pour vous familiariser avec ceph-salt et l'orchestrateur Ceph, et en particulier prendre connaissance des informations sur les spécifications de service.

  • La mise à niveau de la grappe peut prendre beaucoup de temps : environ le temps nécessaire pour mettre à niveau une machine multiplié par le nombre de noeuds de la grappe.

  • Vous devez d'abord mettre à niveau Salt Master, puis remplacer DeepSea par ceph-salt et cephadm ensuite. Vous ne pourrez pas commencer à utiliser le module orchestrateur cephedm tant que vous n'aurez pas mis à niveau toutes les instances de Ceph Manager.

  • La mise à niveau de l'utilisation des RPM Nautilus vers les conteneurs Octopus doit s'effectuer en une seule étape. Cela signifie mettre à niveau un noeud entier à la fois, et non un daemon à la fois.

  • La mise à niveau des services principaux (MON, MGR, OSD) s'effectue de façon ordonnée. Chaque service est disponible pendant la mise à niveau. Les services de passerelle (Metadata Server, Object Gateway, NFS Ganesha, iSCSI Gateway) doivent être redéployés après la mise à niveau des services principaux. Un certain temps hors service existe pour chacun des services suivants :

    • Important
      Important

      Les instances de Metadata Server et d'Object Gateway sont hors service à partir du moment où les noeuds sont mis à niveau de SUSE Linux Enterprise Server 15 SP1 vers SUSE Linux Enterprise Server 15 SP2 jusqu'au redéploiement des services à la fin de la procédure de mise à niveau. Il est particulièrement important de garder cela à l'esprit si ces services cohabitent avec des MON, des MGR ou des OSD, car dans ce cas, ils peuvent être hors service pendant toute la durée de la mise à niveau de la grappe. En cas de problème, envisagez de déployer ces services séparément sur des noeuds supplémentaires avant de procéder à la mise à niveau, afin qu'ils soient hors service le moins longtemps possible. Il s'agit de la durée de la mise à niveau des noeuds de passerelle, et non de la durée de la mise à niveau de l'ensemble de la grappe.

    • Les instances NFS Ganesha and iSCSI Gateway ne sont hors service que pendant le redémarrage des noeuds lors de la mise à niveau de SUSE Linux Enterprise Server 15 SP1 vers SUSE Linux Enterprise Server 15 SP2, puis brièvement lors du redéploiement de chaque service en mode conteneurisé.

7.1.2 Sauvegarde de la configuration et des données de grappe

Nous vous recommandons vivement de sauvegarder l'ensemble de la configuration et des données de la grappe avant la mise à niveau vers SUSE Enterprise Storage 7. Pour savoir comment sauvegarder toutes vos données, consultez https://documentation.suse.com/ses/6/html/ses-all/cha-deployment-backup.html.

7.1.3 Vérification des étapes de la mise à niveau précédente

Si vous avez au préalable effectué une mise à niveau à partir de la version 5, vérifiez que la mise à niveau vers la version 6 a bien abouti :

Vérifiez l'existence du fichier /srv/salt/ceph/configuration/files/ceph.conf.import.

Ce fichier est créé par le processus engulf lors de la mise à niveau de SUSE Enterprise Storage 5 vers la version 6. L'option configuration_init: default-import est définie dans le répertoire /srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml.

Si l'option configuration_init reste définie sur default-import, la grappe utilise ceph.conf.import comme fichier de configuration, au lieu du fichier ceph.conf par défaut de DeepSea, qui est compilé à partir des fichiers dans le répertoire /srv/salt/ceph/configuration/files/ceph.conf.d/.

Par conséquent, vous devez rechercher les configurations personnalisées potentielles dans ceph.conf.import et, éventuellement, les déplacer dans l'un des fichiers du répertoire /srv/salt/ceph/configuration/files/ceph.conf.d/.

Supprimez ensuite la ligne configuration_init: default-import du répertoire /srv/pilleur/ceph/proposals/config/stack/default/ceph/cluster.yml.

7.1.4 Mise à jour des noeuds de la grappe et vérification de l'état de santé de la grappe

Vérifiez que les dernières mises à jour de SUSE Linux Enterprise Server 15 SP1 et SUSE Enterprise Storage 6 sont toutes appliquées à tous les noeuds de la grappe :

root # zypper refresh && zypper patch

Une fois les mises à jour appliquées, vérifiez l'état de santé de la grappe :

cephuser@adm > ceph -s

7.1.5 Vérification de l'accès aux dépôts logiciels et aux images de conteneur

Vérifiez que chaque noeud de la grappe a accès aux dépôts logiciels SUSE Linux Enterprise Server 15 SP2 et SUSE Enterprise Storage 7, ainsi qu'au registre des images de conteneur.

7.1.5.1 Dépôts logiciels

Si tous les noeuds sont enregistrés auprès de SCC, vous pouvez utiliser la commande zypper migration pour effectuer la mise à niveau. Pour plus d'informations, consultez https://documentation.suse.com/sles/15-SP2/html/SLES-all/cha-upgrade-online.html#sec-upgrade-online-zypper.

Si les noeuds ne sont pas enregistrés auprès de SCC, désactivez tous les dépôts logiciels existants et ajoutez les dépôts Pool et Updates pour chacune des extensions suivantes :

  • SLE-Product-SLES/15-SP2

  • SLE-Module-Basesystem/15-SP2

  • SLE-Module-Server-Applications/15-SP2

  • SUSE-Enterprise-Storage-7

7.1.5.2 Images de conteneur

Tous les noeuds de la grappe doivent accéder au registre des images de conteneur. Dans la plupart des cas, vous utiliserez le registre SUSE public à l'adresse registration.suse.com. Les images suivantes sont nécessaires :

  • registry.suse.com/ses/7/ceph/ceph

  • registry.suse.com/ses/7/ceph/grafana

  • registry.suse.com/caasp/v4.5/prometheus-server

  • registry.suse.com/caasp/v4.5/prometheus-node-exporter

  • registry.suse.com/caasp/v4.5/prometheus-alertmanager

Vous pouvez également, par exemple pour les déploiements à vide, configurer un registre local et vérifier que vous disposez de l'ensemble approprié d'images de conteneur. Pour plus d'informations sur la configuration d'un registre d'images de conteneur local, reportez-vous à la Section 5.3.2.11, « Configuration du registre de conteneurs ».

7.2 Mise à niveau de Salt Master

La procédure suivante décrit le processus de mise à niveau de Salt Master :

  1. Mettez à niveau le système d'exploitation sous-jacent vers SUSE Linux Enterprise Server 15 SP2 :

    • Pour les grappes dont l'ensemble des noeuds sont enregistrés auprès de SCC, exécutez zypper migration.

    • Pour les grappes dont les noeuds ont des dépôts logiciels assignés manuellement, exécutez zypper dup suivi de reboot.

  2. Désactivez les phases DeepSea pour éviter toute utilisation accidentelle. Ajoutez le contenu suivant à /srv/pillar/ceph/stack/global.yml :

    stage_prep: disabled
    stage_discovery: disabled
    stage_configure: disabled
    stage_deploy: disabled
    stage_services: disabled
    stage_remove: disabled

    Enregistrez le fichier et appliquez les modifications :

    root@master # salt '*' saltutil.pillar_refresh
  3. Si vous n'utilisez pas d'images de conteneur de registry.suse.com, mais plutôt le registre configuré localement, modifiez /srv/pillar/ceph/stack/global.yml pour indiquer à DeepSea l'image de conteneur Ceph et le registre utiliser. Par exemple, pour utiliser 192.168.121.1:5000/my/ceph/image, ajoutez les lignes suivantes :

    ses7_container_image: 192.168.121.1:5000/my/ceph/image
    ses7_container_registries:
      - location: 192.168.121.1:5000

    Enregistrez le fichier et appliquez les modifications :

    root@master # salt '*' saltutil.refresh_pillar
  4. Assimilez la configuration existante :

    cephuser@adm > ceph config assimilate-conf -i /etc/ceph/ceph.conf
  5. Vérifiez l'état de la mise à niveau. Il est possible que votre sortie soit différente en fonction de la configuration de votre grappe :

    root@master # salt-run upgrade.status
    The newest installed software versions are:
     ceph: ceph version 15.2.2-60-gf5864377ab (f5864377abb5549f843784c93577980aa264b9bc) octopus (stable)
     os: SUSE Linux Enterprise Server 15 SP2
    Nodes running these software versions:
     admin.ceph (assigned roles: master, prometheus, grafana)
    Nodes running older software versions must be upgraded in the following order:
     1: mon1.ceph (assigned roles: admin, mon, mgr)
     2: mon2.ceph (assigned roles: admin, mon, mgr)
     3: mon3.ceph (assigned roles: admin, mon, mgr)
     4: data4.ceph (assigned roles: storage, mds)
     5: data1.ceph (assigned roles: storage)
     6: data2.ceph (assigned roles: storage)
     7: data3.ceph (assigned roles: storage)
     8: data5.ceph (assigned roles: storage, rgw)

7.3 Mise à niveau des noeuds MON, MGR et OSD

Mettez à niveau les noeuds Ceph Monitor, Ceph Manager et OSD un par un. Pour chaque service, procédez comme suit :

  1. Si vous mettez à niveau un noeud OSD, évitez de marquer l'OSD comme sorti pendant la mise à niveau en exécutant la commande suivante :

    cephuser@adm > ceph osd add-noout SHORT_NODE_NAME

    Remplacez SHORT_NODE_NAME par le nom abrégé du noeud tel qu'il apparaît dans la sortie de la commande ceph osd tree. Dans l'entrée suivante, les noms d'hôte abrégés sont ses-min1 et ses-min2

    root@master # ceph osd tree
    ID   CLASS  WEIGHT   TYPE NAME       STATUS  REWEIGHT  PRI-AFF
     -1         0.60405  root default
    -11         0.11691      host ses-min1
      4    hdd  0.01949          osd.4       up   1.00000  1.00000
      9    hdd  0.01949          osd.9       up   1.00000  1.00000
     13    hdd  0.01949          osd.13      up   1.00000  1.00000
    [...]
     -5         0.11691      host ses-min2
      2    hdd  0.01949          osd.2       up   1.00000  1.00000
      5    hdd  0.01949          osd.5       up   1.00000  1.00000
    [...]
  2. Mettez à niveau le système d'exploitation sous-jacent vers SUSE Linux Enterprise Server 15 SP2 :

    • Si les noeuds de la grappe sont tous enregistrés auprès de SCC, exécutez zypper migration.

    • Si les noeuds de la grappe ont des dépôts logiciels assignés manuellement, exécutez zypper dup suivi de reboot.

  3. Une fois le noeud redémarré, conteneurisez tous les daemons MON, MGR et OSD existants sur ce noeud en exécutant la commande suivante sur Salt Master :

    root@master # salt MINION_ID state.apply ceph.upgrade.ses7.adopt

    Remplacez MINION_ID par l'ID du minion que vous mettez à niveau. Vous pouvez obtenir la liste des ID de minion en exécutant la commande salt-key -L sur Salt Master.

    Astuce
    Astuce

    Pour voir l'état et la progression de l'adoption, consultez Ceph Dashboard ou exécutez l'une des commandes suivantes sur Salt Master :

    root@master # ceph status
    root@master # ceph versions
    root@master # salt-run upgrade.status
  4. Une fois l'adoption terminée, désélectionnez l'indicateur noout si vous mettez à niveau un noeud OSD :

    cephuser@adm > ceph osd rm-noout SHORT_NODE_NAME

7.4 Mise à niveau des noeuds de passerelle

Mettez ensuite à niveau vos noeuds de passerelle distincts (Metadata Server, Object Gateway, NFS Ganesha ou iSCSI Gateway). Mettez à niveau le système d'exploitation sous-jacent vers SUSE Linux Enterprise Server 15 SP2 pour chaque noeud :

  • Si les noeuds de la grappe sont tous enregistrés auprès de SUSE Customer Center, exécutez la commande zypper migration.

  • Si les noeuds de la grappe ont des dépôts logiciels assignés manuellement, exécutez la commande zypper dup suivie de reboot.

Cette étape s'applique également à tous les noeuds qui font partie de la grappe, mais qui n'ont pas encore de rôle assigné (en cas de doute, consultez la liste des hôtes sur Salt Master fournie par la commande salt-key -L et comparez-la à la sortie de la commande salt-run upgrade.status).

Une fois le système d'exploitation mis à niveau sur tous les noeuds de la grappe, l'étape suivante consiste à installer le paquetage ceph-salt et à appliquer la configuration de la grappe. Les services de passerelle proprement dits sont redéployés en mode conteneurisé à la fin de la procédure de mise à niveau.

Note
Note

Les services Metadata Server et Object Gateway sont indisponibles à partir de la mise à niveau vers SUSE Linux Enterprise Server 15 SP2 jusqu'à leur redéploiement à la fin de la procédure de mise à niveau.

7.5 Installation de ceph-salt et application de la configuration de la grappe

Avant de lancer la procédure d'installation de ceph-salt et d'appliquer la configuration de la grappe, vérifiez l'état de la grappe et de la mise à niveau en exécutant les commandes suivantes :

root@master # ceph status
root@master # ceph versions
root@master # salt-run upgrade.status
  1. Supprimez les tâches cron rbd_exporter et rgw_exporter créées par DeepSea. Sur Salt Master en tant que root, exécutez la commande crontab -e pour modifier le fichier crontab. Supprimez les éléments suivants, le cas échéant :

    # SALT_CRON_IDENTIFIER:deepsea rbd_exporter cron job
    */5 * * * * /var/lib/prometheus/node-exporter/rbd.sh > \
     /var/lib/prometheus/node-exporter/rbd.prom 2> /dev/null
    # SALT_CRON_IDENTIFIER:Prometheus rgw_exporter cron job
    */5 * * * * /var/lib/prometheus/node-exporter/ceph_rgw.py > \
     /var/lib/prometheus/node-exporter/ceph_rgw.prom 2> /dev/null
  2. Exportez la configuration de la grappe de DeepSea en exécutant les commandes suivantes :

    root@master # salt-run upgrade.ceph_salt_config > ceph-salt-config.json
    root@master # salt-run upgrade.generate_service_specs > specs.yaml
  3. Désinstallez DeepSea et installez ceph-salt sur Salt Master :

    root@master # zypper remove 'deepsea*'
    root@master # zypper install ceph-salt
  4. Redémarrez Salt Master et synchronisez les modules Salt :

    root@master # systemctl restart salt-master.service
    root@master # salt \* saltutil.sync_all
  5. Importez la configuration de la grappe de DeepSea dans ceph-salt :

    root@master # ceph-salt import ceph-salt-config.json
  6. Générez des clés SSH pour la communication des noeuds de la grappe :

    root@master # ceph-salt config /ssh generate
    Astuce
    Astuce

    Vérifiez que la configuration de la grappe a bien été importée de DeepSea et spécifiez les options potentiellement manquantes :

    root@master # ceph-salt config ls

    Pour une description complète de la configuration de la grappe, reportez-vous à la Section 5.3.2, « Configuration des propriétés de grappe ».

  7. Appliquez la configuration et activez cephamp :

    root@master # ceph-salt apply
  8. Si vous devez fournir une URL de registre local de conteneurs et des informations d'identification d'accès, suivez les étapes décrites à la Section 5.3.2.11, « Configuration du registre de conteneurs ».

  9. Si vous n'utilisez pas d'images de conteneur de registry.suse.com, mais plutôt le registre configuré localement, indiquez à Ceph quelle image de conteneur utiliser en exécutant

    root@master # ceph config set global container_image IMAGE_NAME

    Par exemple :

    root@master # ceph config set global container_image 192.168.121.1:5000/my/ceph/image
  10. Arrêtez et désactivez les daemons ceph-crash de SUSE Enterprise Storage 6. Les nouvelles formes conteneurisées de ces daemons seront lancées automatiquement plus tard.

    root@master # salt '*' service.stop ceph-crash
    root@master # salt '*' service.disable ceph-crash

7.6 Mise à niveau et adoption de la pile de surveillance

La procédure suivante adopte tous les composants de la pile de surveillance (voir Chapitre 16, Surveillance et alertes pour plus de détails).

  1. Mettez l'orchestrateur en pause :

    cephuser@adm > ceph orch pause
  2. Sur le noeud qui exécute Prometheus, Grafana et Alertmanager (l'instance Salt Master par défaut), exécutez les commandes suivantes :

    cephuser@adm > cephadm adopt --style=legacy --name prometheus.$(hostname)
    cephuser@adm > cephadm adopt --style=legacy --name alertmanager.$(hostname)
    cephuser@adm > cephadm adopt --style=legacy --name grafana.$(hostname)
    Astuce
    Astuce

    Si vous n'exécutez pas le registre d'images de conteneur par défaut registration.suse.com, vous devez spécifier l'image à utiliser, par exemple :

    cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-server:2.18.0 \
      adopt --style=legacy --name prometheus.$(hostname)
    cephuser@adm > cephadm --image 192.168.121.1:5000/caasp/v4.5/prometheus-alertmanager:0.16.2 \
      adopt --style=legacy --name alertmanager.$(hostname)
    cephuser@adm > cephadm --image 192.168.121.1:5000/ses/7/ceph/grafana:7.0.3 \
     adopt --style=legacy --name grafana.$(hostname)

    Pour plus d'informations sur l'utilisation des images de conteneur personnalisées ou locales, voir Section 16.1, « Configuration d'images personnalisées ou locales ».

  3. Supprimez le service Node-Exporter. Il ne doit pas nécessairement être migré et il sera réinstallé en tant que conteneur lorsque le fichier specs.yaml sera appliqué.

    tux > sudo zypper rm golang-github-prometheus-node_exporter
  4. Appliquez les spécifications de service que vous avez précédemment exportées de DeepSea :

    cephuser@adm > ceph orch apply -i specs.yaml
  5. Relancez l'orchestrateur :

    cephuser@adm > ceph orch resume

7.7 Redéploiement du service de passerelle

7.7.1 Mise à niveau de la passerelle Object Gateway

Dans SUSE Enterprise Storage 7, les passerelles Object Gateway sont toujours configurées avec un domaine, ce qui permet une utilisation sur plusieurs sites (voir Section 21.13, « Passerelles Object Gateway multisites » pour plus de détails) à l'avenir. Si vous avez utilisé une configuration Object Gateway monosite dans SUSE Enterprise Storage 6, procédez comme suit pour ajouter un domaine. Si vous ne prévoyez pas d'utiliser à proprement parler la fonctionnalité multisite, vous pouvez utiliser la valeur par défaut pour les noms de domaine, de groupe de zones et de zone.

  1. Créez un domaine :

    cephuser@adm > radosgw-admin realm create --rgw-realm=REALM_NAME --default
  2. Vous pouvez éventuellement renommer la zone et le groupe de zones par défaut.

    cephuser@adm > radosgw-admin zonegroup rename \
     --rgw-zonegroup default \
     --zonegroup-new-name=ZONEGROUP_NAME
    cephuser@adm > radosgw-admin zone rename \
     --rgw-zone default \
     --zone-new-name ZONE_NAME \
     --rgw-zonegroup=ZONEGROUP_NAME
  3. Configurez le groupe de zones maître :

    cephuser@adm > radosgw-admin zonegroup modify \
     --rgw-realm=REALM_NAME \
     --rgw-zonegroup=ZONEGROUP_NAME \
     --endpoints http://RGW.EXAMPLE.COM:80 \
     --master --default
  4. Configurez la zone maître. Pour ce faire, vous aurez besoin des clés ACCESS_KEY et SECRET_KEY d'un utilisateur Object Gateway avec l'indicateur system activé. Il s'agit généralement de l'utilisateur admin. Pour obtenir les clés ACCESS_KEY et SECRET_KEY, exécutez radosgw-admin user info --uid admin.

    cephuser@adm > radosgw-admin zone modify \
     --rgw-realm=REALM_NAME \
     --rgw-zonegroup=ZONEGROUP_NAME \
     --rgw-zone=ZONE_NAME \
     --endpoints http://RGW.EXAMPLE.COM:80 \
     --access-key=ACCESS_KEY \
     --secret=SECRET_KEY \
     --master --default
  5. Validez la configuration mise à jour :

    cephuser@adm > radosgw-admin period update --commit

Pour conteneuriser le service Object Gateway, créez son fichier de spécification comme décrit à la Section 5.4.3.4, « Déploiement d'instances Object Gateway » et appliquez-le.

cephuser@adm > ceph orch apply -i RGW.yml

7.7.2 Mise à niveau de NFS Ganesha

Les paragraphes qui suivent expliquent comment migrer un service NFS Ganesha existant qui exécute Ceph Nautilus vers un conteneur NFS Ganesha qui exécute Ceph Octopus.

Avertissement
Avertissement

La documentation suivante implique que vous ayez déjà mis à niveau les services Ceph principaux.

NFS Ganesha stocke la configuration par daemon supplémentaire et l'exporte dans une réserve RADOS. La réserve RADOS configurée se trouve sur la ligne watch_url du bloc RADOS_URLS dans le fichier ganesha.conf. Par défaut, cette réserve est nommée ganesha_config

Avant de tenter une migration, nous vous recommandons vivement de copier les objets de configuration d'exportation et de daemon situés dans la réserve RADOS. Pour localiser la réserve RADOS configurée, exécutez la commande suivante :

cephuser@adm > grep -A5 RADOS_URLS /etc/ganesha/ganesha.conf

Pour répertorier le contenu de la réserve RADOS :

cephuser@adm > rados --pool ganesha_config --namespace ganesha ls | sort
  conf-node3
  export-1
  export-2
  export-3
  export-4

Pour copier les objets RADOS :

cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
cephuser@adm > OBJS=$(rados $RADOS_ARGS ls)
cephuser@adm > for obj in $OBJS; do rados $RADOS_ARGS get $obj $obj; done
cephuser@adm > ls -lah
total 40K
drwxr-xr-x 2 root root 4.0K Sep 8 03:30 .
drwx------ 9 root root 4.0K Sep 8 03:23 ..
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node2
-rw-r--r-- 1 root root 90 Sep 8 03:30 conf-node3
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-1
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-2
-rw-r--r-- 1 root root 350 Sep 8 03:30 export-3
-rw-r--r-- 1 root root 358 Sep 8 03:30 export-4

Pour chaque noeud, un service NFS Ganesha existant doit être arrêté, puis remplacé par un conteneur géré par cephadm.

  1. Arrêtez et désactivez le service NFS Ganesha existant :

    cephuser@adm > systemctl stop nfs-ganesha
    cephuser@adm > systemctl disable nfs-ganesha
  2. Une fois le service NFS Ganesha existant arrêté, vous pouvez en déployer un nouveau dans un conteneur à l'aide de cephadm. Pour ce faire, vous devez créer une spécification de service contenant un service_id qui sera utilisé pour identifier cette nouvelle grappe NFS, le nom d'hôte du noeud que nous migrons répertorié comme hôte dans la spécification de placement, ainsi que la réserve RADOS et l'espace de noms qui contient les objets d'exportation NFS configurés. Par exemple :

    service_type: nfs
    service_id: SERVICE_ID
    placement:
      hosts:
      - node2
      pool: ganesha_config
      namespace: ganesha

    Pour plus d'informations sur la création d'une spécification de placement, voir Section 5.4.2, « Spécification de service et de placement ».

  3. Appliquez la spécification de placement :

    cephuser@adm > ceph orch apply -i FILENAME.yaml
  4. Confirmez que le daemon NFS Ganesha est en cours d'exécution sur l'hôte :

    cephuser@adm > ceph orch ps --daemon_type nfs
    NAME           HOST   STATUS         REFRESHED  AGE  VERSION  IMAGE NAME                                IMAGE ID      CONTAINER ID
    nfs.foo.node2  node2  running (26m)  8m ago     27m  3.3      registry.suse.com/ses/7/ceph/ceph:latest  8b4be7c42abd  c8b75d7c8f0d
  5. Répétez ces étapes pour chaque noeud NFS Ganesha. Il n'est pas nécessaire de créer une spécification de service distincte pour chaque noeud. Il suffit d'ajouter le nom d'hôte de chaque noeud à la spécification de service NFS existante et de l'appliquer à nouveau.

Les exportations existantes peuvent être migrées de deux manières différentes :

  • recréation ou réassignation manuelle à l'aide de Ceph Dashboard ;

  • copie manuelle du contenu de chaque objet RADOS par daemon dans la configuration commune NFS Ganesha nouvellement créée.

Procédure 7.1 : Copie manuelle des exportations dans le fichier de configuration commun NFS Ganesha
  1. Déterminez la liste des objets RADOS par daemon :

    cephuser@adm > RADOS_ARGS="--pool ganesha_config --namespace ganesha"
    cephuser@adm > DAEMON_OBJS=$(rados $RADOS_ARGS ls | grep 'conf-')
  2. Copiez les objets RADOS par daemon :

    cephuser@adm > for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; done
    cephuser@adm > ls -lah
    total 20K
    drwxr-xr-x 2 root root 4.0K Sep 8 16:51 .
    drwxr-xr-x 3 root root 4.0K Sep 8 16:47 ..
    -rw-r--r-- 1 root root 90 Sep 8 16:51 conf-nfs.SERVICE_ID
    -rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node2
    -rw-r--r-- 1 root root 90 Sep 8 16:51 conf-node3
  3. Triez et fusionnez en une seule liste d'exportations :

    cephuser@adm > cat conf-* | sort -u > conf-nfs.SERVICE_ID
    cephuser@adm > cat conf-nfs.foo
    %url "rados://ganesha_config/ganesha/export-1"
    %url "rados://ganesha_config/ganesha/export-2"
    %url "rados://ganesha_config/ganesha/export-3"
    %url "rados://ganesha_config/ganesha/export-4"
  4. Écrivez le nouveau fichier de configuration commun NFS Ganesha :

    cephuser@adm > rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
  5. Notifiez le daemon NFS Ganesha :

    cephuser@adm > rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_ID
    Note
    Note

    Cette opération entraîne le rechargement de la configuration par le daemon.

Une fois le service migré, le service NFS Ganesha basé sur Nautilus peut être supprimé.

  1. Supprimez NFS Ganesha :

    cephuser@adm > zypper rm nfs-ganesha
    Reading installed packages...
    Resolving package dependencies...
    The following 5 packages are going to be REMOVED:
      nfs-ganesha nfs-ganesha-ceph nfs-ganesha-rados-grace nfs-ganesha-rados-urls nfs-ganesha-rgw
    5 packages to remove.
    After the operation, 308.9 KiB will be freed.
    Continue? [y/n/v/...? shows all options] (y): y
    (1/5) Removing nfs-ganesha-ceph-2.8.3+git0.d504d374e-3.3.1.x86_64 .................................................................................................................................................................................................................................................................................................[done]
    (2/5) Removing nfs-ganesha-rgw-2.8.3+git0.d504d374e-3.3.1.x86_64 ..................................................................................................................................................................................................................................................................................................[done]
    (3/5) Removing nfs-ganesha-rados-urls-2.8.3+git0.d504d374e-3.3.1.x86_64 ...........................................................................................................................................................................................................................................................................................[done]
    (4/5) Removing nfs-ganesha-rados-grace-2.8.3+git0.d504d374e-3.3.1.x86_64 ..........................................................................................................................................................................................................................................................................................[done]
    (5/5) Removing nfs-ganesha-2.8.3+git0.d504d374e-3.3.1.x86_64 ......................................................................................................................................................................................................................................................................................................[done]
    Additional rpm output:
    warning: /etc/ganesha/ganesha.conf saved as /etc/ganesha/ganesha.conf.rpmsave
  2. Supprimez les paramètres hérités de la grappe de l'instance Ceph Dashboard :

    cephuser@adm > ceph dashboard reset-ganesha-clusters-rados-pool-namespace

7.7.3 Mise à niveau du serveur de métadonnées

Contrairement aux instances MON, MGR et OSD, le serveur de métadonnées ne peut pas être adopté sur place. Vous devez le redéployer dans des conteneurs à l'aide de l'orchestrateur Ceph.

  1. Exécutez la commande ceph fs ls pour obtenir le nom de votre système de fichiers, par exemple :

    cephuser@adm > ceph fs ls
    name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]
  2. Créez un nouveau fichier de spécification de service mds.yml comme décrit à la Section 5.4.3.3, « Déploiement de serveurs de métadonnées » en utilisant le nom du système de fichiers comme service_id et en spécifiant les hôtes qui exécuteront les daemons MDS. Par exemple :

    service_type: mds
    service_id: cephfs
    placement:
      hosts:
      - ses-min1
      - ses-min2
      - ses-min3
  3. Exécutez la commande ceph orch apply -i mds.yml pour appliquer la spécification de service et démarrer les daemons MDS.

7.7.4 Mise à niveau de la passerelle iSCSI

Pour mettre à niveau la passerelle iSCSI, vous devez la redéployer dans des conteneurs à l'aide de l'orchestrateur Ceph. Si vous disposez de plusieurs passerelles iSCSI, vous devez les redéployer une par une pour réduire le temps d'indisponibilité du service.

  1. Arrêtez et désactivez les daemons iSCSI existants sur chaque noeud de passerelle iSCSI :

    tux > sudo systemctl stop rbd-target-gw
    tux > sudo systemctl disable rbd-target-gw
    tux > sudo systemctl stop rbd-target-api
    tux > sudo systemctl disable rbd-target-api
  2. Créez une spécification de service pour la passerelle iSCSI comme décrit à la Section 5.4.3.5, « Déploiement de passerelles iSCSI ». Pour ce faire, vous avez besoin des paramètres pool, trusted_ip_list et api_* du fichier /etc/ceph/iscsi-gateway.cfg existant. Si la prise en charge SSL est activée (api_secure = true), vous avez également besoin du certificat SSL (/etc/ceph/iscsi-gateway.crt) et de la clé (/etc/ceph/iscsi-gateway.key).

    Par exemple, si le fichier /etc/ceph/iscsi-gateway.cfg contient ce qui suit :

    [config]
    cluster_client_name = client.igw.ses-min5
    pool = iscsi-images
    trusted_ip_list = 10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202
    api_port = 5000
    api_user = admin
    api_password = admin
    api_secure = true

    Vous devez créer le fichier de spécification de service iscsi.yml suivant :

    service_type: iscsi
    service_id: igw
    placement:
      hosts:
      - ses-min5
    spec:
      pool: iscsi-images
      trusted_ip_list: "10.20.179.203,10.20.179.201,10.20.179.205,10.20.179.202"
      api_port: 5000
      api_user: admin
      api_password: admin
      api_secure: true
      ssl_cert: |
        -----BEGIN CERTIFICATE-----
        MIIDtTCCAp2gAwIBAgIYMC4xNzc1NDQxNjEzMzc2MjMyXzxvQ7EcMA0GCSqGSIb3
        DQEBCwUAMG0xCzAJBgNVBAYTAlVTMQ0wCwYDVQQIDARVdGFoMRcwFQYDVQQHDA5T
        [...]
        -----END CERTIFICATE-----
      ssl_key: |
        -----BEGIN PRIVATE KEY-----
        MIIEvQIBADANBgkqhkiG9w0BAQEFAASCBKcwggSjAgEAAoIBAQC5jdYbjtNTAKW4
        /CwQr/7wOiLGzVxChn3mmCIF3DwbL/qvTFTX2d8bDf6LjGwLYloXHscRfxszX/4h
        [...]
        -----END PRIVATE KEY-----
    Note
    Note

    Les paramètres pool, trusted_ip_list, api_port, api_user, api_password, api_secure sont identiques à ceux du fichier /etc/ceph/iscsi-gateway.cfg. Les valeurs ssl_cert et ssl_key peuvent être copiées à partir du certificat SSL et des fichiers de clé existants. Vérifiez qu'elles sont correctement indentées et que le caractère barre verticale (|) apparaît à la fin des lignes ssl_cert: et ssl_key: (voir le contenu du fichier iscsi.yml ci-dessus).

  3. Exécutez la commande ceph orch apply -i iscsi.yml pour appliquer la spécification de service et démarrer les daemons de la passerelle iSCSI.

  4. Supprimez l'ancien paquetage ceph-iscsi de chacun des noeuds existants de la passerelle iSCSI :

    cephuser@adm > zypper rm -u ceph-iscsi

7.8 Nettoyage après mise à niveau

Après la mise à niveau, effectuez les opérations de nettoyage suivantes :

  1. Vérifiez que la grappe a bien été mise à niveau en vérifiant la version actuelle de Ceph :

    cephuser@adm > ceph versions
  2. Assurez-vous qu'aucun ancien OSD ne rejoindra la grappe :

    cephuser@adm > ceph osd require-osd-release octopus
  3. Activez le module de mise à l'échelle automatique :

    cephuser@adm > ceph mgr module enable pg_autoscaler
    Important
    Important

    Dans SUSE Enterprise Storage 6, les réserves avaient le paramètre pg_autoscale_mode défini sur warn par défaut. Cela entraînait un message d'avertissement si le nombre de groupes de placement était sous-optimal, mais la mise à l'échelle automatique ne se produisait pas. Dans SUSE Enterprise Storage 7, l'option pg_autoscale_mode est réglée sur on par défaut pour les nouvelles réserves et les groupes de placement seront mis à l'échelle automatiquement. Le processus de mise à niveau ne modifie pas automatiquement le paramètre pg_autoscale_mode des réserves existantes. Si vous souhaitez le régler sur on pour tirer pleinement parti de la mise à l'échelle automatique, reportez-vous aux instructions figurant dans le Section 17.4.12, « Activation de la mise à l'échelle automatique des groupes de placement ».

    Pour plus de détails, reportez-vous au Section 17.4.12, « Activation de la mise à l'échelle automatique des groupes de placement ».

  4. Évitez les clients de versions antérieures à Luminous :

    cephuser@adm > ceph osd set-require-min-compat-client luminous
  5. Activez le module de l'équilibreur :

    cephuser@adm > ceph balancer mode upmap
    cephuser@adm > ceph balancer on

    Pour plus de détails, reportez-vous au Section 29.1, « Équilibreur ».

  6. Vous pouvez éventuellement activer le module de télémétrie :

    cephuser@adm > ceph mgr module enable telemetry
    cephuser@adm > ceph telemetry on

    Pour plus de détails, reportez-vous au Section 29.2, « Activation du module de télémétrie ».