10 Mise à niveau de SUSE Enterprise Storage 6 vers la version 7.1 #
Ce chapitre présente les étapes requises pour mettre à niveau SUSE Enterprise Storage 6 vers la version 7.1.
La mise à niveau inclut les tâches suivantes :
mise à niveau de Ceph Nautilus vers Pacific ;
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-saltet cephadm.
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.
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.
10.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.
La migration OSD de FileStore vers BlueStore doit avoir été effectuée avant la mise à niveau, car FileStore n'est pas pris en charge dans SUSE Enterprise Storage 7.1. Pour plus d'informations concernant BlueStore et sur la procédure de migration à partir de FileStore, consultez le site https://documentation.suse.com/ses/6/single-html/ses-deployment/#filestore2bluestore
Si vous exécutez une grappe plus ancienne qui utilise toujours des OSD
ceph-disk, vous devez passer àceph-volumeavant la mise à niveau. Pour plus de détails, consultez le site https://documentation.suse.com/ses/6/single-html/ses-deployment/#upgrade-osd-deployment.
10.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.1 sont disponibles en ligne à l'adresse https://www.suse.com/releasenotes/.
De plus, après avoir installé le paquetage release-notes-ses à partir du dépôt SES 7.1, les notes de version sont disponibles en local dans le répertoire
/usr/share/doc/release-notesou en ligne à l'adresse https://www.suse.com/releasenotes/.Lisez la Partie II, « Déploiement de la grappe Ceph » pour vous familiariser avec
ceph-saltet 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-saltet cephadm. Vous ne pourrez pas commencer à utiliser le module orchestrateur cephadm tant que vous n'aurez pas mis à niveau tous les noeuds de Ceph Manager.La mise à niveau de l'utilisation des RPM Nautilus vers les conteneurs Pacific doit s'effectuer en une seule étape. Il convient donc de 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
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 SP3 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 ces derniers risquent aussi d'être hors service pendant toute la durée de la mise à niveau de la grappe. Si cette mise hors service vous semble problématique, envisagez de déployer ces services séparément sur des noeuds supplémentaires avant de procéder à la mise à niveau, afin leur mise hors service dure moins longtemps. 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 et 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 SP3, puis brièvement lors du redéploiement de chaque service en mode conteneurisé.
10.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 de commencer votre mise à niveau vers SUSE Enterprise Storage 7.1. Pour savoir comment sauvegarder toutes vos données, consultez le site https://documentation.suse.com/ses/6/single-html/ses-admin/#cha-deployment-backup.
10.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.
10.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 :
# zypper refresh && zypper patch
Reportez-vous au site https://documentation.suse.com/ses/6/html/ses-all/storage-salt-cluster.html#deepsea-rolling-updates pour obtenir des informations détaillées sur la mise à jour des noeuds de grappe.
Une fois les mises à jour appliquées, redémarrez Salt Master, synchronisez les nouveaux modules Salt et vérifiez l'état de santé de la grappe :
root@master #systemctl restart salt-master.serviceroot@master #salt '*' saltutil.sync_allcephuser@adm >ceph -s
10.1.4.1 Désactivation des clients non sécurisés #
Depuis la version 14.2.20 de Nautilus, un nouvel avertissement relatif à l'état de santé vous informe que les clients non sécurisés sont autorisés à rejoindre la grappe. Cet avertissement est activé par défaut. Ceph Dashboard affiche la grappe dans l'état HEALTH_WARN. La ligne de commande vérifie l'état de la grappe comme suit :
cephuser@adm > ceph status
cluster:
id: 3fe8b35a-689f-4970-819d-0e6b11f6707c
health: HEALTH_WARN
mons are allowing insecure global_id reclaim
[...]Cet avertissement signifie que les moniteurs Ceph autorisent toujours les anciens clients non corrigés à se connecter à la grappe. De cette façon, les clients existants peuvent toujours se connecter pendant la mise à niveau de la grappe, mais le système vous avertit qu'un problème doit être résolu. Une fois la grappe et tous les clients mis à niveau vers la dernière version de Ceph, interdisez les clients non corrigés en exécutant la commande suivante :
cephuser@adm > ceph config set mon auth_allow_insecure_global_id_reclaim false10.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 SP3 et SUSE Enterprise Storage 7.1, ainsi qu'au registre des images de conteneur.
10.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 le site https://documentation.suse.com/sles/15-SP3/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-SP3
SLE-Module-Basesystem/15-SP3
SLE-Module-Server-Applications/15-SP3
SUSE-Enterprise-Storage-7.1
10.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.1/ceph/ceph
registry.suse.com/ses/7.1/ceph/grafana
registry.suse.com/ses/7.1/ceph/prometheus-server
registry.suse.com/ses/7.1/ceph/prometheus-node-exporter
registry.suse.com/ses/7.1/ceph/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 7.2.10, « Utilisation du registre de conteneurs ».
10.2 Mise à niveau de Salt Master #
La procédure suivante décrit le processus de mise à niveau de Salt Master :
Mettez à niveau le système d'exploitation sous-jacent vers SUSE Linux Enterprise Server 15 SP3 :
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 dupsuivi dereboot.
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_refreshSi 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.ymlpour indiquer à DeepSea l'image de conteneur Ceph et le registre utiliser. Par exemple, pour utiliser192.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
Si vous devez spécifier des informations d'authentification pour le registre, ajoutez le bloc
ses7_container_registry_auth:, par exemple :ses7_container_image: 192.168.121.1:5000/my/ceph/image ses7_container_registries: - location: 192.168.121.1:5000 ses7_container_registry_auth: registry: 192.168.121.1:5000 username: USER_NAME password: PASSWORD
Enregistrez le fichier et appliquez les modifications :
root@master #salt '*' saltutil.refresh_pillarAssimilez la configuration existante :
cephuser@adm >ceph config assimilate-conf -i /etc/ceph/ceph.confVé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 16.2.7-640-gceb23c7491b (ceb23c7491bd96ab7956111374219a4cdcf6f8f4) pacific (stable) os: SUSE Linux Enterprise Server 15 SP3 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)
10.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 :
Avant d'adopter un noeud OSD, vous devez effectuer une conversion de format des noeuds OSD pour améliorer la comptabilisation des données OMAP. Vous pouvez le faire en exécutant la commande suivante sur le noeud Admin :
cephuser@adm >ceph config set osd bluestore_fsck_quick_fix_on_mount trueLes noeuds OSD seront convertis automatiquement une fois leur adoption terminée.
NoteLa conversion peut prendre un certain temps (quelques minutes à plusieurs heures), selon la quantité de données OMAP que contient le disque dur associé. Pour plus d'informations, reportez-vous à la page https://docs.ceph.com/en/latest/releases/pacific/#upgrading-non-cephadm-clusters.
Si vous mettez à niveau un noeud OSD, évitez de marquer l'OSD comme
sortipendant la mise à niveau en exécutant la commande suivante :cephuser@adm >ceph osd add-noout SHORT_NODE_NAMERemplacez 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 sontses-min1etses-min2root@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 [...]Mettez à niveau le système d'exploitation sous-jacent vers SUSE Linux Enterprise Server 15 SP3 :
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 dupsuivi dereboot.
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.adoptRemplacez 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 -Lsur Salt Master.AstucePour 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 statusroot@master #ceph versionsroot@master #salt-run upgrade.statusUne fois l'adoption terminée, désélectionnez l'indicateur
nooutsi vous mettez à niveau un noeud OSD :cephuser@adm >ceph osd rm-noout SHORT_NODE_NAME
10.4 Mise à niveau des noeuds de passerelle #
Mettez ensuite à niveau vos noeuds de passerelle distincts (passerelle Samba, serveur de métadonnées, Object Gateway, NFS Ganesha ou passerelle iSCSI). Mettez à niveau le système d'exploitation sous-jacent vers SUSE Linux Enterprise Server 15 SP3 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 dupsuivie dereboot.
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).
Lorsque le système d'exploitation a été 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.
Les services Metadata Server et Object Gateway sont indisponibles à partir de la mise à niveau vers SUSE Linux Enterprise Server 15 SP3 jusqu'à leur redéploiement à la fin de la procédure de mise à niveau.
10.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 statusroot@master #ceph versionsroot@master #salt-run upgrade.status
Supprimez les tâches cron
rbd_exporteretrgw_exportercréées par DeepSea. Sur Salt Master en tant queroot, exécutez la commandecrontab -epour 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
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.jsonroot@master #salt-run upgrade.generate_service_specs > specs.yamlDésinstallez DeepSea et installez
ceph-saltsur Salt Master :root@master #zypper remove 'deepsea*'root@master #zypper install ceph-saltRedémarrez Salt Master et synchronisez les modules Salt :
root@master #systemctl restart salt-master.serviceroot@master #salt \* saltutil.sync_allImportez la configuration de la grappe de DeepSea dans
ceph-salt:root@master #ceph-salt import ceph-salt-config.jsonGénérez des clés SSH pour la communication des noeuds de la grappe :
root@master #ceph-salt config /ssh generateAstuceVé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 lsPour une description complète de la configuration de la grappe, reportez-vous à la Section 7.2, « Configuration des propriétés de grappe ».
Appliquez la configuration et activez cephamp :
root@master #ceph-salt applySi 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 7.2.10, « Utilisation du registre de conteneurs ».
Si vous n'utilisez pas d'images de conteneur de
registry.suse.com, mais plutôt le registre configuré en local, indiquez à Ceph quelle image de conteneur utiliser en exécutantroot@master #ceph config set global container_image IMAGE_NAMEPar exemple :
root@master #ceph config set global container_image 192.168.121.1:5000/my/ceph/imageArrêtez et désactivez les daemons
ceph-crashde SUSE Enterprise Storage 6. Les nouvelles formes conteneurisées de ces daemons seront lancées automatiquement plus tard.root@master #salt '*' service.stop ceph-crashroot@master #salt '*' service.disable ceph-crash
10.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).
Mettez l'orchestrateur en pause :
cephuser@adm >ceph orch pauseSur 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)AstuceSi vous n'exécutez pas le registre d'images de conteneur par défaut
registration.suse.com, vous devez spécifier l'image à utiliser sur chaque commande, par exemple :cephuser@adm >cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-server:2.32.1 \ adopt --style=legacy --name prometheus.$(hostname)cephuser@adm >cephadm --image 192.168.121.1:5000/ses/7.1/ceph/prometheus-alertmanager:0.21.0 \ adopt --style=legacy --name alertmanager.$(hostname)cephuser@adm >cephadm --image 192.168.121.1:5000/ses/7.1/ceph/grafana:7.5.12 \ adopt --style=legacy --name grafana.$(hostname)Les images de conteneur requises et leurs versions respectives sont répertoriées dans le Section 16.1, « Configuration d'images personnalisées ou locales ».
Supprimez Node-Exporter de tous les noeuds. Node-Exporter ne doit pas nécessairement être migré et est réinstallé en tant que conteneur lorsque le fichier
specs.yamlest appliqué.>sudozypper rm golang-github-prometheus-node_exporterVous pouvez également supprimer Node-Exporter de tous les noeuds simultanément à l'aide de Salt sur le noeud Admin :
root@master #salt '*' pkg.remove golang-github-prometheus-node_exporterAppliquez les spécifications de service que vous avez précédemment exportées de DeepSea :
cephuser@adm >ceph orch apply -i specs.yamlAstuceSi vous n'exécutez pas le registre d'images de conteneur par défaut
registration.suse.com, mais un registre de conteneurs local, configurez cephadm pour utiliser l'image de conteneur du registre local pour le déploiement de Node-Exporter avant de déployer Node-Exporter. Dans le cas contraire, vous pouvez sans problème passer cette étape et ignorer l'avertissement suivant.cephuser@adm >ceph config set mgr mgr/cephadm/container_image_node_exporter QUALIFIED_IMAGE_PATHAssurez-vous que toutes les images de conteneur des services de surveillance pointent vers le registre local, et pas seulement vers celui de Node-Exporter. Cette étape vous oblige à le faire uniquement pour Node-Exporter, mais il est conseillé de définir toutes les images de conteneur de surveillance dans cephadm pour qu'elles pointent vers le registre local à ce stade.
Si vous ne le faites pas, les nouveaux déploiements de services de surveillance ainsi que les redéploiements utiliseront la configuration par défaut de cephadm et il se peut que vous ne puissiez plus déployer de services (dans le cas de déploiements à vide) ou avec des services déployés avec des versions mixtes.
La procédure de configuration de cephadm pour utiliser les images de conteneur du registre local est décrite dans le Section 16.1, « Configuration d'images personnalisées ou locales ».
Relancez l'orchestrateur :
cephuser@adm >ceph orch resume
10.7 Redéploiement du service de passerelle #
10.7.1 Mise à niveau de la passerelle Object Gateway #
Dans SUSE Enterprise Storage 7.1, 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 la fonctionnalité multisite, vous pouvez utiliser la valeur par défaut pour les noms de domaine, de groupe de zones et de zone.
Créez un domaine :
cephuser@adm >radosgw-admin realm create --rgw-realm=REALM_NAME --defaultVous 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_NAMEcephuser@adm >radosgw-admin zone rename \ --rgw-zone default \ --zone-new-name ZONE_NAME \ --rgw-zonegroup=ZONEGROUP_NAMEConfigurez 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 --defaultConfigurez 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
systemactivé. Il s'agit généralement de l'utilisateuradmin. Pour obtenir les clés ACCESS_KEY et SECRET_KEY, exécutezradosgw-admin user info --uid admin --rgw-zone=NOM_ZONE.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 --defaultValidez 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 8.3.4, « Déploiement d'instances Object Gateway » et appliquez-le.
cephuser@adm > ceph orch apply -i RGW.yml10.7.2 Mise à niveau de NFS Ganesha #
NFS Ganesha prend en charge les versions 4.1 et ultérieures de NFS. Il ne prend pas en charge la version 3 de NFS.
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.
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 faire une copie des objets de configuration d'exportation et 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.confPour 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-4Pour 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; donecephuser@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, tout service NFS Ganesha existant doit être arrêté, puis remplacé par un conteneur géré par cephadm.
Arrêtez et désactivez le service NFS Ganesha existant :
cephuser@adm >systemctl stop nfs-ganeshacephuser@adm >systemctl disable nfs-ganeshaUne 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_idqui 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, reportez-vous à la Section 8.2, « Spécification de service et de placement ».
Appliquez la spécification de placement :
cephuser@adm >ceph orch apply -i FILENAME.yamlConfirmez 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.1/ceph/ceph:latest 8b4be7c42abd c8b75d7c8f0dRé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.
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-')Copiez les objets RADOS par daemon :
cephuser@adm >for obj in $DAEMON_OBJS; do rados $RADOS_ARGS get $obj $obj; donecephuser@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-node3Triez et fusionnez en une seule liste d'exportations :
cephuser@adm >cat conf-* | sort -u > conf-nfs.SERVICE_IDcephuser@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"Écrivez le nouveau fichier de configuration commun NFS Ganesha :
cephuser@adm >rados $RADOS_ARGS put conf-nfs.SERVICE_ID conf-nfs.SERVICE_IDNotifiez le daemon NFS Ganesha :
cephuser@adm >rados $RADOS_ARGS notify conf-nfs.SERVICE_ID conf-nfs.SERVICE_IDNoteCette 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é.
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.rpmsaveSupprimez les paramètres hérités de la grappe de l'instance Ceph Dashboard :
cephuser@adm >ceph dashboard reset-ganesha-clusters-rados-pool-namespace
10.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.
Exécutez la commande
ceph fs lspour 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 ]Créez un nouveau fichier de spécification de service
mds.ymlcomme décrit à la Section 8.3.3, « Déploiement de serveurs de métadonnées » en utilisant le nom du système de fichiers commeservice_idet 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
Exécutez la commande
ceph orch apply -i mds.ymlpour appliquer la spécification de service et démarrer les daemons MDS.
10.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.
Arrêtez et désactivez les daemons iSCSI existants sur chaque noeud de passerelle iSCSI :
>sudosystemctl stop rbd-target-gw>sudosystemctl disable rbd-target-gw>sudosystemctl stop rbd-target-api>sudosystemctl disable rbd-target-apiCréez une spécification de service pour la passerelle iSCSI comme décrit à la Section 8.3.5, « Déploiement de passerelles iSCSI ». Pour ce faire, vous avez besoin des paramètres
pool,trusted_ip_listetapi_*du fichier/etc/ceph/iscsi-gateway.cfgexistant. 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.cfgcontient 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.ymlsuivant :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-----NoteLes paramètres
pool,trusted_ip_list,api_port,api_user,api_password,api_securesont identiques à ceux du fichier/etc/ceph/iscsi-gateway.cfg. Les valeursssl_certetssl_keypeuvent ê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 lignesssl_cert:etssl_key:(voir le contenu du fichieriscsi.ymlci-dessus).Exécutez la commande
ceph orch apply -i iscsi.ymlpour appliquer la spécification de service et démarrer les daemons de la passerelle iSCSI.Supprimez l'ancien paquetage ceph-iscsi de chacun des noeuds de passerelle iSCSI existants :
cephuser@adm >zypper rm -u ceph-iscsi
10.8 Nettoyage après mise à niveau #
Après la mise à niveau, effectuez les opérations de nettoyage suivantes :
Vérifiez que la grappe a bien été mise à niveau en vérifiant la version actuelle de Ceph :
cephuser@adm >ceph versionsAssurez-vous qu'aucun ancien OSD ne rejoindra la grappe :
cephuser@adm >ceph osd require-osd-release pacificDéfinissez le mode
pg_autoscale_modedes réserves existantes si nécessaire :ImportantDans SUSE Enterprise Storage 6, les réserves avaient le paramètre
pg_autoscale_modedéfini surwarnpar 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.1, l'optionpg_autoscale_modeest définie suronpar 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ètrepg_autoscale_modedes réserves existantes. Si vous souhaitez le régler suronpour 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 ».
Évitez les clients de versions antérieures à Luminous :
cephuser@adm >ceph osd set-require-min-compat-client luminousActivez le module de l'équilibreur :
cephuser@adm >ceph balancer mode upmapcephuser@adm >ceph balancer onPour plus de détails, reportez-vous au Section 29.1, « Équilibreur ».
Vous pouvez éventuellement activer le module de télémétrie :
cephuser@adm >ceph mgr module enable telemetrycephuser@adm >ceph telemetry onPour plus de détails, reportez-vous au Section 29.2, « Activation du module de télémétrie ».