SUSE Enterprise Storage 6

Guide de déploiement

Guide de déploiementSUSE Enterprise Storage 6par Tomáš Bažant, Jana Haláčková, Alexandra Settle, et Sven Seeberg

Date de publication : 04/07/2021

SUSE LLC1800 South Novell PlaceProvo, UT 84606USA

https://documentation.suse.com

Copyright © 2021 SUSE LLC

Copyright © 2016, RedHat, Inc, et contributeurs.

Le texte et les illustrations de ce document sont sous licence Creative Commons Attribution-Share

Alike  4.0 International («  CC-BY-SA  »). Une explication de CC-BY-SA est disponible à l'adresse http://

creativecommons.org/licenses/by-sa/4.0/legalcode . Conformément à CC-BY-SA, si vous distribuez ce

document ou une adaptation de celui-ci, vous devez fournir l'URL de la version d'origine.

Red Hat, Red Hat Enterprise Linux, le logo Shadowman, JBoss, MetaMatrix, Fedora, le logo Innity et RHCE

sont des marques commerciales de Red Hat, Inc., déposées aux États-Unis et dans d'autres pays. Linux®

est une marque déposée de Linus Torvalds aux États-Unis et dans d'autres pays. Java® est une marque

déposée d'Oracle et/ou de ses sociétés aliées. XFS® est une marque commerciale de Silicon Graphics

International Corp. ou de ses liales aux États-Unis et dans d'autres pays. Toutes les autres marques sont

la propriété de leur détenteur respectif.

Pour les marques commerciales SUSE, consultez le site Web http://www.suse.com/company/legal/ . Toutes

les autres marques de fabricants tiers sont la propriété de leur détenteur respectif. Les symboles de marque

commerciale (®,™, etc.) indiquent des marques commerciales de SUSE et de ses liales. Des astérisques (*)

désignent des marques commerciales de fabricants tiers.

Toutes les informations de cet ouvrage ont été regroupées avec le plus grand soin. Cela ne garantit

cependant pas sa complète exactitude. Ni SUSE LLC, ni les sociétés aliées, ni les auteurs, ni les traducteurs

ne peuvent être tenus responsables des erreurs possibles ou des conséquences qu'elles peuvent entraîner.

Table des matières

À propos de ce guide x1 Documentation disponible x

2 Commentaires xi

3 Conventions relatives à la documentation xi

4 À propos de la réalisation de ce manuel xii

5 Contributeurs Ceph xii

I SUSE ENTERPRISE STORAGE 1

1 SUSE Enterprise Storage 6 et Ceph 21.1 Fonctions de Ceph 2

1.2 Composants de base 3

RADOS 3 • CRUSH 4 • Noeuds et daemons Ceph 5

1.3 Structure de stockage 7

Pool 7 • Groupe de placement 7 • Exemple 7

1.4 BlueStore 9

1.5 Informations complémentaires 11

2 Configuration matérielle requise etrecommandations 12

2.1 Configurations d'architecture multiples 12

2.2 Configuration minimale de la grappe 12

2.3 Noeuds de stockage des objets 13

Configuration minimale requise 13 • Taille minimale du

disque 14 • Taille recommandée pour les périphériques WAL et DB

iv Guide de déploiement

de BlueStore 14 • Utilisation des disques SSD pour les journaux

OSD 15 • Nombre maximal recommandé de disques 15

2.4 Noeuds de moniteur 16

2.5 Noeuds Object Gateway 16

2.6 Noeuds MDS 17

2.7 Salt Master 17

2.8 Noeuds iSCSI 17

2.9 Recommandations concernant le réseau 17

Ajout d'un réseau privé à une grappe en cours d'exécution 18 • Noeuds de

moniteur sur des sous-réseaux distincts 19

2.10 Limitations relatives à la dénomination 19

2.11 Noeuds OSD et Monitor partageant un même serveur 20

2.12 Configuration recommandée de la grappe de production 20

2.13 SUSE Enterprise Storage 6 et autres produits SUSE 21

SUSE Manager 21

3 Configuration haute disponibilité du noeudAdmin 22

3.1 Aperçu de la grappe HA pour le noeud Admin 22

3.2 Création d'une grappe HA avec le noeud Admin 23

4 Privilèges des utilisateurs et invites decommande 25

4.1 Commandes associées à Salt/DeepSea 25

4.2 Commandes associées à Ceph 25

4.3 Commandes Linux générales 26

4.4 Informations complémentaires 27

v Guide de déploiement

II DÉPLOIEMENT ET MISE À NIVEAU DE LA GRAPPE 28

5 Déploiement avec DeepSea/Salt 295.1 Lecture des notes de version 30

5.2 Présentation de DeepSea 30

Organisation et emplacements importants 32 • Ciblage des minions 32

5.3 Déploiement de la grappe 35

5.4 Interface de ligne de commande de DeepSea 44

Interface de ligne de commande de DeepSea : mode de

surveillance 45 • Interface de ligne de commande de DeepSea : mode

autonome 45

5.5 Configuration et personnalisation 48

Fichier policy.cfg 48 • Groupes d'unités 53 • Ajustement de

ceph.conf avec des paramètres personnalisés 63

6 Mise à jour à partir de versions précédentes 64

6.1 Points à prendre en compte avant la mise à niveau 64

6.2 Sauvegarde des données de grappe 69

6.3 Migration de ntpd vers chronyd 69

6.4 Application des correctifs à la grappe avant la mise à niveau 70

Dépôts logiciels requis 71 • Systèmes de préparation de

dépôt 71 • Application des derniers correctifs à toute la grappe 72

6.5 Vérification de l'environnement actuel 72

6.6 Vérification de l'état de la grappe 73

6.7 Mise à niveau hors ligne des grappes CTDB 74

6.8 Mise à niveau par noeud - Procédure de base 75

Mise à niveau manuelle d'un noeud à l'aide du DVD du programme

d'installation 75 • Mise à niveau de noeud à l'aide du système de migration

de distribution SUSE 77

6.9 Mise à niveau du noeud Admin 79

vi Guide de déploiement

6.10 Mise à niveau des noeuds Ceph Monitor/Ceph Manager 80

6.11 Mise à niveau des serveurs de métadonnées 80

6.12 Mise à niveau des Ceph OSD 82

6.13 Migration des OSD vers BlueStore 86

6.14 Mises à niveau des noeuds d'application 87

6.15 Mise à jour de policy.cfg et déploiement de Ceph Dashboard à l'aidede DeepSea 88

6.16 Migration des déploiements basés sur le profil vers les groupesd'unités 90

Analyse de la disposition actuelle 91 • Création de groupes

d'unités correspondant à la disposition actuelle 91 • Déploiement

OSD 92 • Configurations plus complexes 93

7 Personnalisation de la configuration par défaut 94

7.1 Utilisation de fichiers de configuration personnalisés 94

Désactivation d'une étape du déploiement 94 • Remplacement

d'une étape du déploiement 95 • Modification d'une étape du

déploiement 97 • Modification d'une phase du déploiement 98 • Mises

à jour et redémarrages pendant la phase 0 99

7.2 Modification de la configuration découverte 101

Activation du protocole IPv6 pour le déploiement de grappe Ceph 103

III INSTALLATION DE SERVICES SUPPLÉMENTAIRES 104

8 Installation des services permettant d'accéder à vosdonnées 105

9 Ceph Object Gateway 106

9.1 Installation manuelle d'Object Gateway 107

Configuration d'Object Gateway 107

vii Guide de déploiement

10 Installation de la passerelle iSCSI 114

10.1 Stockage de blocs iSCSI 114

Cible iSCSI du kernel Linux 115 • Initiateurs iSCSI 115

10.2 Informations générales sur ceph-iscsi 116

10.3 Considérations sur le déploiement 118

10.4 Installation et configuration 118

Déploiement de la passerelle iSCSI sur une grappe Ceph 119 • Création

d'images RBD 119 • Exportation d'images RBD via

iSCSI 119 • Authentification et contrôle d'accès 121 • Paramètres

avancés 122

10.5 Exportation d'images de périphérique de bloc RADOS à l'aide de tcmu-runner 126

11 Installation de CephFS 127

11.1 Scénarios CephFS pris en charge et conseils 127

11.2 Serveur de métadonnées Ceph 128

Ajout d'un serveur de métadonnées 128 • Configuration d'un serveur de

métadonnées 128

11.3 CephFS 135

Création de CephFS 135 • Taille de la grappe du MDS 136 • Grappe du

MDS et mises à jour 137 • Disposition des fichiers 138

12 Installation de NFS Ganesha 144

12.1 Préparation 144

Informations générales 144 • Résumé des conditions requises 145

12.2 Exemple d'installation 145

12.3 Configuration haute disponibilité active-passive 146

Installation classique 146 • Nettoyage des ressources 149 • Configuration

d'une ressource ping 149 • NFS Ganesha HA et DeepSea 150

viii Guide de déploiement

12.4 Configuration active-active 150

Conditions préalables 151 • Configuration de NFS

Ganesha 151 • Remplissage de la base de données de

bonus de grappe 153 • Redémarrage des services NFS

Ganesha 153 • Conclusion 154

12.5 Pour plus d'informations 154

IV DÉPLOIEMENT DE GRAPPES SUR SUSE CAAS PLAFORM 4 (AVANT-PREMIÈRE TECHNOLOGIQUE) 155

13 SUSE Enterprise Storage 6 sur une grappe KubernetesSUSE CaaS Platform 4 156

13.1 Considérations 156

13.2 Conditions préalables 156

13.3 Obtention des manifestes Rook 157

13.4 Installation 157

Configuration 157 • Création de l'opérateur Rook 159 • Création de la

grappe Ceph 159

13.5 Utilisation de Rook comme stockage pour le workload Kubernetes 160

13.6 Désinstallation de Rook 161

A Mises à jour de maintenance de Ceph basées sur lesversions intermédiaires « Nautilus » en amont 162

Glossaire 165

B Mises à jour de la documentation 168

B.1 Mise à jour de maintenance de la documentation SUSE EnterpriseStorage 6 168

B.2 Juin 2019 (version de SUSE Enterprise Storage 6) 169

ix Guide de déploiement

À propos de ce guide

SUSE Enterprise Storage 6 est une extension de SUSE Linux Enterprise Server 15 SP1. Il réunit lescapacités du projet de stockage Ceph (http://ceph.com/ ), l'ingénierie d'entreprise et le supportde SUSE. SUSE Enterprise Storage 6 permet aux organisations informatiques de déployer unearchitecture de stockage distribuée capable de prendre en charge un certain nombre de casd'utilisation à l'aide de plates-formes matérielles courantes.

Ce guide vous aide à comprendre le concept de SUSE Enterprise Storage 6 en mettant l'accentsur la gestion et l'administration de l'infrastructure Ceph. Il montre également comment utiliserCeph avec d'autres solutions connexes, telles que KVM ou OpenStack.

Un grand nombre de chapitres de ce manuel contiennent des liens vers d'autres ressourcesdocumentaires, notamment une documentation supplémentaire, disponible sur le système, ainsique la documentation disponible sur Internet.

Pour plus d'informations sur la documentation associée à votre produit et pour lesdernières mises à jour de cette documentation, reportez-vous au site http://www.suse.com/

documentation .

1 Documentation disponibleLes manuels suivants sont disponibles pour ce produit :

Manuel « Guide d'administration »

Ce guide décrit diverses tâches administratives généralement eectuées après l'installation.Il présente également les étapes d'intégration de Ceph avec les solutions de virtualisationtelles que libvirt , Xen ou KVM, et les moyens d'accéder aux objets stockés dans la grappevia les passerelles iSCSI et RADOS.

Guide de déploiement

Ce guide parcourt les étapes d'installation de la grappe Ceph et de tous les services liésà Ceph. Il illustre également une structure de grappe Ceph de base et vous fournit laterminologie associée.

Les versions HTML des manuels relatifs au produit se trouvent sur le système installé, sous /usr/share/doc/manual . Trouvez les dernières mises à jour de la documentation à l'adressehttp://www.suse.com/documentation où vous pouvez télécharger les manuels de votre produitdans plusieurs formats.

x Documentation disponible SES 6

2 CommentairesPour soumettre vos commentaires, vous disposez de plusieurs options :

Bogues et demandes d'amélioration

Pour connaître les services et les options de support disponibles pour votre produit, visitezle site http://www.suse.com/support/ .Pour signaler des bogues concernant un composant du produit, connectez-vous àNovell Customer Center depuis http://www.suse.com/support/ et sélectionnez My Support(Mon support) Service Request (Requête de service).

Commentaires utilisateur

Nous sommes à l'écoute de vos commentaires et suggestions concernant ce manuel et lesautres documentations fournies avec ce produit. Utilisez la fonction des commentaires desutilisateurs située en bas de chaque page de la documentation en ligne ou accédez au sitehttp://www.suse.com/documentation/feedback.html , puis saisissez vos commentaires.

Messagerie

Pour formuler des commentaires sur la documentation de ce produit, vous pouvezégalement envoyer un message électronique à l'adresse doc-team@suse.de . Veillez àinclure le titre du document, la version du produit et la date de publication de ladocumentation. Pour signaler des erreurs ou proposer des améliorations, veuillez fournirune brève description du problème et mentionner le numéro de section et la page (ou URL)correspondants.

3 Conventions relatives à la documentationLes conventions typographiques suivantes s'appliquent dans ce manuel :

/etc/passwd  : noms de répertoires et de chiers

espace réservé : remplacez espace réservé par la valeur réelle

PATH : variable d'environnement PATH

ls , --help : commandes, options et paramètres

user : utilisateurs ou groupes

Alt , Alt – F1 : touche ou combinaison de touches sur lesquelles appuyer ; les touchesapparaissent en majuscules comme sur un clavier

xi Commentaires SES 6

Fichier, Fichier Enregistrer sous : options de menu, boutons

Pingouins qui dansent (chapitre Pingouins, ↑Autre manuel) : référence au chapitre d'un autremanuel.

4 À propos de la réalisation de ce manuelCet ouvrage a été rédigé sous GeekoDoc, un sous-ensemble de DocBook (voir http://

www.docbook.org ). Les chiers XML source ont été validés par xmllint , traités par xsltprocet convertis en XSL-FO grâce à une version personnalisée des feuilles de style de Norman Walsh.Le PDF nal peut être formaté via FOP depuis Apache ou XEP à partir de RenderX. Les outils decréation et de publication utilisés pour produire ce manuel sont disponibles dans le paquetagedaps . DocBook Authoring and Publishing Suite (DAPS) est développé en tant que logiciel OpenSource. Pour plus d'informations, reportez-vous à l'adresse http://daps.sf.net/ .

5 Contributeurs CephLe projet Ceph et sa documentation sont le résultat du travail de centaines de contributeurs etd'organisations. Pour plus d'informations, reportez-vous au site https://ceph.com/contributors/ .

xii À propos de la réalisation de ce manuel SES 6

I SUSE Enterprise Storage

1 SUSE Enterprise Storage 6 et Ceph 2

2 Configuration matérielle requise et recommandations 12

3 Configuration haute disponibilité du noeud Admin 22

4 Privilèges des utilisateurs et invites de commande 25

1 SUSE Enterprise Storage 6 et Ceph

SUSE Enterprise Storage (SES) 6 est un système de stockage distribué conçu pour l'évolutivité,la abilité et les performances, et basé sur la technologie Ceph. Une grappe Ceph peut êtreexécutée sur des serveurs courants dans un réseau standard comme Ethernet. La grappe évoluefacilement vers des milliers de serveurs (appelés plus tard noeuds) et dans la plage de pétaoctets.Contrairement aux systèmes conventionnels qui possèdent des tables d'allocation pour stockeret récupérer des données, Ceph utilise un algorithme déterministe pour allouer du stockage desdonnées et ne dispose d'aucune structure centralisée des informations. Ceph suppose que, dansles grappes de stockage, l'ajout ou la suppression de matériel est la règle, et non l'exception.La grappe Ceph automatise les tâches de gestion telles que la distribution et la redistributiondes données, la réplication des données, la détection des échecs et la récupération. Ceph peutà la fois s'autoréparer et s'autogérer, ce qui se traduit par une réduction des frais administratifset budgétaires.

Ce chapitre fournit un aperçu global de SUSE Enterprise  Storage 6 et décrit brièvement leséléments les plus importants.

AstuceDepuis SUSE  Enterprise  Storage  5, la seule méthode de déploiement de grappesest DeepSea. Reportez-vous au Chapitre  5, Déploiement avec DeepSea/Salt pour plusd'informations sur le processus de déploiement.

1.1 Fonctions de CephL'environnement Ceph possède les fonctions suivantes :

Évolutivité

Ceph peut s'adapter à des milliers de noeuds et gérer le stockage dans la plage de pétaoctets.

Matériel courant

Aucun matériel spécial n'est requis pour exécuter une grappe Ceph. Pourplus d'informations, reportez-vous au Chapitre  2, Configuration matérielle requise et

recommandations

Autogestion

2 Fonctions de Ceph SES 6

La grappe Ceph est autogérée. Lorsque des noeuds sont ajoutés ou supprimés ou échouent,la grappe redistribue automatiquement les données. Elle a également connaissance desdisques surchargés.

Aucun point d'échec unique

Aucun noeud d'une grappe ne stocke les informations importantes de manière isolée. Vouspouvez congurer le nombre de redondances.

Logiciels Open Source

Ceph est une solution logicielle Open Source et indépendante du matériel ou defournisseurs spéciques.

1.2 Composants de basePour tirer pleinement parti de la puissance de Ceph, il est nécessaire de comprendre certainsdes composants et concepts de base. Cette section présente certaines parties de Ceph qui sontsouvent référencées dans d'autres chapitres.

1.2.1 RADOS

Le composant de base de Ceph est appelé RADOS (Reliable Autonomic Distributed Object Store)(Zone de stockage des objets distribués autonome able). Il est chargé de gérer les donnéesstockées dans la grappe. Les données de Ceph sont généralement stockées en tant qu'objets.Chaque objet se compose d'un identicateur et des données.

RADOS fournit les méthodes d'accès suivantes aux objets stockés qui couvrent de nombreux casd'utilisation :

Object Gateway

Object Gateway est une passerelle HTTP REST pour la zone de stockage des objets RADOS.Elle permet un accès direct aux objets stockés dans la grappe Ceph.

Périphérique de bloc RADOS

Les périphériques de bloc RADOS (RADOS Block Devices, RBD) sont accessibles commen'importe quel autre périphérique de bloc. Ils peuvent être utilisés, par exemple, encombinaison avec libvirt à des ns de virtualisation.

CephFS

3 Composants de base SES 6

Le système de chiers Ceph est un système de chiers compatible POSIX.

librados

librados est une bibliothèque pouvant être utilisée avec de nombreux langages deprogrammation pour créer une application capable d'interagir directement avec la grappede stockage.

librados est utilisé par Object Gateway et les RBD alors que CephFS s'interface directementavec RADOS Figure 1.1, « Interfaces avec la zone de stockage des objets Ceph ».

RADOS

FIGURE 1.1T : INTERFACES AVEC LA ZONE DE STOCKAGE DES OBJETS CEPH

1.2.2 CRUSH

Au coeur d'une grappe Ceph se trouve l'algorithme CRUSH. CRUSH est l'acronyme de ControlledReplication Under Scalable Hashing (Réplication contrôlée sous hachage évolutif). CRUSH est unefonction qui gère l'allocation de stockage et nécessite relativement peu de paramètres. Celasignie que seule une petite quantité d'informations est nécessaire pour calculer la position destockage d'un objet. Les paramètres sont une carte actuelle de la grappe, comprenant l'état desanté, certaines règles de placement dénies par l'administrateur et le nom de l'objet qui doitêtre stocké ou récupéré. Avec ces informations, tous les noeuds de la grappe Ceph sont en mesurede calculer l'emplacement auquel un objet et ses répliques sont stockés. Cela rend l'écriture oula lecture des données très ecace. CRUSH tente de distribuer équitablement les données surtous les noeuds de la grappe.

La carte CRUSH contient tous les noeuds de stockage et les règles de placement déniespar l'administrateur pour le stockage des objets dans la grappe. Elle dénit une structurehiérarchique qui correspond généralement à la structure physique de la grappe. Par exemple,les disques contenant des données sont dans des hôtes, les hôtes sont dans des racks, les racks

4 CRUSH SES 6

dans des rangées et les rangées dans des centres de données. Cette structure peut être utiliséepour dénir des domaines de défaillance. Ceph s'assure ensuite que les réplications sont stockéessur diérentes branches d'un domaine de défaillance spécique.

Si le domaine de défaillance est déni sur le niveau rack, les réplications d'objets sontréparties sur diérents racks. Cela peut limiter les interruptions de service provoquées par uncommutateur défaillant sur un rack. Si une unité de distribution de l'alimentation dessert unerangée de racks, le domaine de défaillance peut être déni sur rangée. En cas de défaillancede l'unité de distribution de l'alimentation, les données répliquées sont toujours disponibles surles autres rangées.

1.2.3 Noeuds et daemons Ceph

Dans Ceph, les noeuds sont des serveurs fonctionnant pour la grappe. Ils peuvent exécuter diverstypes de daemons. Il est recommandé de n'exécuter qu'un seul type de daemon sur chaque noeud,à l'exception des daemons Ceph Manager qui peuvent être colocalisés avec des daemons CephMonitor. Chaque grappe nécessite au moins des daemons Ceph Monitor, Ceph Manager, et CephOSD :

Noeud Admin

Le noeud Admin est un noeud de la grappe Ceph sur lequel le service Salt Master est encours d'exécution. Le noeud Admin est un point central de la grappe Ceph, car il gère lesautres noeuds de la grappe en interrogeant et en instruisant leurs services de minion Salt.En général, il inclut également d'autres services, par exemple l'interface utilisateur WebCeph Dashboard avec le tableau de bord Grafana et le toolkit de surveillance Prometheus.

Ceph Monitor

Les noeuds Ceph Monitor (souvent abrégés en MON) gèrent des informations sur l'état desanté de la grappe, une carte de tous les noeuds et des règles de distribution des données(reportez-vous à la Section 1.2.2, « CRUSH »).En cas de défaillance ou de conit, les noeuds Ceph Monitor de la grappe décident, à lamajorité, des informations qui sont correctes. Pour former une majorité admissible, il estrecommandé de disposer d'un nombre impair de noeuds Ceph Monitor et au minimum detrois d'entre eux.Si plusieurs sites sont utilisés, les noeuds Ceph Monitor doivent être distribués sur unnombre impair de sites. Le nombre de noeuds Ceph Monitor par site doit être tel que plusde 50 % des noeuds Ceph Monitor restent fonctionnels en cas de défaillance d'un site.

5 Noeuds et daemons Ceph SES 6

Ceph Manager

Ceph  Manager (MGR) collecte les informations d'état de l'ensemble de la grappe. Ledaemon Ceph Manager s'exécute parallèlement aux daemons Ceph Monitor. Il fournit unesurveillance supplémentaire et assure l'interface avec les systèmes de surveillance et degestion externes.Ceph Manager ne requiert aucune conguration supplémentaire : il sut de s'assurer qu'ils'exécute. Vous pouvez le déployer en tant que rôle distinct à l'aide de DeepSea.

Ceph OSD

Ceph OSD est un daemon qui gère des périphériques de stockage d'objets (Object StorageDevices, OSD) qui sont des unités de stockage physiques ou logiques (disques durs oupartitions). Les périphériques de stockage d'objets peuvent être des disques/partitionsphysiques ou des volumes logiques. Le daemon prend également en charge la réplicationet le rééquilibrage des données en cas d'ajout ou de suppression de noeuds.Les daemons Ceph OSD communiquent avec les daemons Ceph Monitor et leur fournissentl'état des autres daemons OSD.

Pour utiliser CephFS, Object Gateway, NFS  Ganesha ou la passerelle iSCSI, des noeudssupplémentaires sont requis :

Serveur de métadonnées (MDS)

Les serveurs de métadonnées stockent des métadonnées pour CephFS. En utilisant un MDS,vous pouvez exécuter des commandes du système de chiers de base, par exemple ls ,sans surcharger la grappe.

Object Gateway

Object Gateway est une passerelle HTTP REST pour la zone de stockage des objets RADOS.Elle est compatible avec OpenStack Swift et Amazon S3, et possède sa propre gestion desutilisateurs.

NFS Ganesha

NFS Ganesha fournit un accès NFS à Object Gateway ou à CephFS. NFS Ganesha s'exécutedans l'espace utilisateur au lieu de l'espace kernel, et interagit directement avec ObjectGateway ou CephFS.

Passerelle iSCSI

iSCSI est un protocole de réseau de stockage qui permet aux clients d'envoyer descommandes SCSI à des périphériques de stockage SCSI (cibles) sur des serveurs distants.

Passerelle Samba

6 Noeuds et daemons Ceph SES 6

La passerelle Samba ore un accès SAMBA aux données stockées sur CephFS.

1.3 Structure de stockage

1.3.1 Pool

Les objets qui sont stockés dans une grappe Ceph sont placés dans des réserves. Les réservesreprésentent les partitions logiques de la grappe vers le monde extérieur. Pour chaque réserve,un ensemble de règles peut être déni, par exemple, combien de réplications de chaque objetdoivent exister. La conguration standard des réserves est appelée réserve répliquée.

Les réserves contiennent généralement des objets, mais peuvent également être conguréespour agir de la même manière qu'un RAID 5. Dans cette conguration, les objets sont stockéssous forme de tranches avec d'autres tranches de codage. Les tranches de codage contiennentles informations redondantes. Le nombre de données et les tranches de codage peuvent êtredénis par l'administrateur. Dans cette conguration, les réserves sont appelées réserves codéesà eacement.

1.3.2 Groupe de placement

Les groupes de placement (PG) sont utilisés pour la distribution des données au sein d'une réserve.Lorsque vous créez une réserve, un certain nombre de groupes de placement sont dénis.Les groupes de placement sont utilisés en interne pour grouper des objets et sont un facteurimportant en termes de performances d'une grappe Ceph. Le groupe de placement d'un objetest déterminé par le nom de l'objet.

1.3.3 Exemple

Cette section fournit un exemple simplié de la façon dont Ceph gère les données (reportez-vousà la Figure 1.2, « Exemple de Ceph à petite échelle »). Cet exemple ne représente pas une congurationrecommandée pour une grappe Ceph. La conguration matérielle comprend trois noeuds destockage ou noeuds Ceph OSD ( Hôte  1 , Hôte  2 , Hôte  3 ). Chaque noeud comporte troisdisques durs qui sont utilisés comme OSD ( osd.1 à osd.9 ). Les noeuds Ceph Monitor sontignorés dans cet exemple.

7 Structure de stockage SES 6

Remarque : diérence entre Ceph OSD et OSDAlors que Ceph OSD ou daemon Ceph OSD fait référence à un daemon exécuté sur unnoeud, le terme OSD fait référence au disque logique avec lequel le daemon interagit.

La grappe comporte deux réserves, Réserve A et Réserve B . Alors que Réserve A ne répliqueles objets que deux fois, la résilience pour Réserve B est plus importante et comporte troisréplications pour chaque objet.

Lorsqu'une application place un objet dans une réserve, par exemple via l'API REST, un groupede placement ( PG1 à PG4 ) est sélectionné en fonction de la réserve et du nom de l'objet.L'algorithme CRUSH calcule ensuite les OSD sur lesquels l'objet est stocké, en fonction du groupede placement qui contient l'objet.

Dans cet exemple, le domaine de défaillance est déni sur le niveau hôte. Cela garantit que lesréplications d'objets sont stockées sur des hôtes diérents. En fonction du niveau de réplicationdéni pour une réserve, l'objet est stocké sur deux ou trois OSD utilisés par le groupe deplacement.

Une application qui écrit un objet interagit uniquement avec un Ceph  OSD, le Ceph  OSDprimaire. Le Ceph  OSD primaire se charge de la réplication et conrme l'achèvement duprocessus d'écriture une fois que tous les autres OSD ont stocké l'objet.

Si osd.5 échoue, tous les objets du PG1 sont toujours disponibles sur osd.1 . Dès que la grappeidentie un échec d'OSD, un autre OSD prend le relais. Dans cet exemple osd.4 est utilisé enremplacement d' osd.5 . Les objets stockés sur osd.1 sont ensuite répliqués sur osd.4 pourrestaurer le niveau de la réplication.

8 Exemple SES 6

FIGURE 1.2T : EXEMPLE DE CEPH À PETITE ÉCHELLE

Si un nouveau noeud avec de nouveaux OSD est ajouté à la grappe, la carte de la grappe vachanger. La fonction CRUSH renvoie alors des emplacements diérents pour les objets. Les objetsqui reçoivent de nouveaux emplacements seront déplacés. Ce processus aboutit à une utilisationéquilibrée de tous les OSD.

1.4 BlueStoreBlueStore est une nouvelle interface dorsale de stockage par défaut pour Ceph depuis la version 5de SUSE Enterprise Storage. Il ore de meilleures performances que FileStore, une somme decontrôle de données complète et une compression intégrée.

9 BlueStore SES 6

BlueStore gère un, deux ou trois périphériques de stockage. Dans le cas le plus simple, BlueStoreutilise un seul périphérique de stockage primaire. Le périphérique de stockage est normalementpartitionné en deux parties :

1. Une petite partition nommée BlueFS qui met en oeuvre des fonctionnalités de type systèmede chiers requises par RocksDB.

2. Le reste du périphérique est généralement une grande partition occupant le reste dupériphérique. Il est géré directement par BlueStore et contient toutes les données réelles.Ce périphérique primaire est normalement identié par un lien symbolique de bloc dansle répertoire de données.

Il est également possible de déployer BlueStore sur deux périphériques supplémentaires :

Un périphérique WAL peut être utilisé pour le journal interne ou le journal d'écriture anticipéede BlueStore. Il est identié par le lien symbolique block.wal dans le répertoire de données.Il n'est utile d'utiliser un périphérique WAL distinct que si le périphérique est plus rapide que lepériphérique primaire ou le périphérique DB, par exemple dans les cas suivants :

Le périphérique WAL est une interface NVMe, le périphérique DB est un disque SSD et lepériphérique de données est un disque SSD ou un disque HDD.

Les périphériques WAL et DB sont des disques SSD distincts et le périphérique de donnéesest un disque SSD ou un disque HDD.

Un périphérique  DB peut être utilisé pour stocker les métadonnées internes de BlueStore.BlueStore (ou plutôt, la base de données RocksDB intégrée) mettra autant de métadonnées quepossible sur le périphérique DB pour améliorer les performances. Encore une fois, il n'est utilede déployer un périphérique DB partagé que s'il est plus rapide que le périphérique primaire.

Astuce : planification de la taille du périphérique DBPlaniez minutieusement la taille du périphérique DB pour qu'elle soit susante. Si lepériphérique DB sature, les métadonnées débordent sur le périphérique primaire, ce quidégrade considérablement les performances de l'OSD.

Vous pouvez vérier si une partition WAL/DB est pleine et déborde avec la commandeceph daemon osd.ID perf dump . La valeur slow_used_bytes indique la quantité dedonnées qui déborde :

cephadm@adm > ceph daemon osd.ID perf dump | jq '.bluefs'

10 BlueStore SES 6

"db_total_bytes": 1073741824,"db_used_bytes": 33554432,"wal_total_bytes": 0,"wal_used_bytes": 0,"slow_total_bytes": 554432,"slow_used_bytes": 554432,

1.5 Informations complémentaires

Ceph, en tant que projet communautaire, dispose de sa propre documentation enligne. Pour les rubriques non trouvées dans ce manuel, reportez-vous au site http://

docs.ceph.com/docs/master/ .

La publication d'origine CRUSH: Controlled, Scalable, Decentralized Placement of ReplicatedData (CRUSH : placement contrôlé, évolutif et décentralisé des données répliquées) parS.A.  Weil, S.A.  Brandt, E.L.  Miller, C.  Maltzahn fournit des informations utiles sur lefonctionnement interne de Ceph. Il est surtout recommandé de le lire lors du déploiementde grappes à grande échelle. La publication peut être consultée à l'adresse http://

www.ssrc.ucsc.edu/papers/weil-sc06.pdf .

SUSE Enterprise Storage peut être utilisé avec des distributions non-SUSE OpenStack. Lesclients Ceph doivent être à un niveau compatible avec SUSE Enterprise Storage.

RemarqueSUSE prend en charge le composant serveur du déploiement Ceph et le client estpris en charge par le fournisseur de la distribution OpenStack.

11 Informations complémentaires SES 6

2 Configuration matérielle requise etrecommandations

La conguration matérielle requise de Ceph dépend fortement du workload des E/S. Laconguration matérielle requise et les recommandations suivantes doivent être considéréescomme un point de départ de la planication détaillée.

En général, les recommandations données dans cette section dépendent du processus. Siplusieurs processus sont situés sur la même machine, les besoins en UC, RAM, disque et réseaudoivent être additionnés.

2.1 Configurations d'architecture multiplesSUSE Enterprise Storage prend en charge les architectures x86 et Arm. Si nous considéronschaque architecture, il est important de noter que d'un point de vue du nombre de coeurs parOSD, de la fréquence et de la mémoire RAM, il n'y a pas de diérence réelle entre les architecturesde processeurs en termes de dimensionnement.

Comme pour les processeurs x86 plus petits (non-serveurs), les coeurs basés sur Arm moinsperformants peuvent ne pas fournir une expérience optimale, en particulier lorsqu'ils sont utiliséspour des réserves codées à eacement.

2.2 Configuration minimale de la grappeAu moins 4 noeuds OSD, avec 8 disques OSD chacun, sont requis.

Trois noeuds de moniteur Ceph (disque SSD requis pour l'unité du système d'exploitationdédié).

Les noeuds Passerelles iSCSI, Object Gateway et MDS nécessitent 4  Go de RAMincrémentielle et quatre coeurs.

Les noeuds Ceph Monitor, Object Gateway et MDS nécessitent un déploiement redondant.

Un noeud Admin distinct est requis, avec 4 Go de RAM, quatre coeurs et 1 To de capacité.Il s'agit généralement du noeud Salt Master. Les services et passerelles Ceph, tels que CephMonitor, Ceph Manager, MDS, Ceph OSD, Object Gateway ou NFS Ganesha, ne sont paspris en charge sur le noeud Admin.

12 Configurations d'architecture multiples SES 6

2.3 Noeuds de stockage des objets

2.3.1 Configuration minimale requise

Recommandations au niveau processeur :

1x thread d'UC 2 GHz par disque rotatif

2x threads d'UC 2 GHz par disque SSD

4x threads d'UC 2 GHz par disque NVMe

Réseaux 10 GbE séparés (public/client et interface dorsale), 4x 10 GbE requis, 2x 25 GbErecommandés.

Mémoire RAM totale requise = nombre d'OSD x (1 Go + osd_memory_target ) + 16 GoReportez-vous au Manuel « Guide d'administration », Chapitre 16 « Configuration de la grappe

Ceph », Section 16.2.1 « Dimensionnement automatique des caches » pour plus de détails surosd_memory_target .

Disques OSD dans les congurations JBOD ou les congurations RAID-0 individuelles.

Le journal OSD peut résider sur le disque OSD.

Les disques OSD doivent être exclusivement utilisés par SUSE Enterprise Storage.

Disque/SSD dédié au système d'exploitation, de préférence dans une conguration RAID 1.

Si cet hôte OSD héberge une partie d'une réserve de cache utilisée pour la hiérarchisationdu cache, allouez au moins 4 Go de RAM supplémentaires.

Les moniteurs Ceph, la passerelle et les serveurs de métadonnées peuvent résider sur lesnoeuds de stockage des objets.

Pour des raisons de performances des disques, nous vous recommandons d'utiliser dumatériel sans système d'exploitation pour les noeuds OSD, plutôt que des machinesvirtuelles.

13 Noeuds de stockage des objets SES 6

2.3.2 Taille minimale du disque

Il existe deux types d'espace disque requis pour l'exécution sur un OSD : l'espace pour le journaldu disque (pour FileStore) ou le périphérique WAL/DB (pour BlueStore) et l'espace primairepour les données stockées. La valeur minimale (et par défaut) pour le journal/WAL/DB est de6 Go. L'espace minimum pour les données est de 5 Go, car les partitions inférieures à 5 Go sontautomatiquement assignées à une pondération de 0.

Ainsi, bien que l'espace disque minimal pour un OSD soit de 11 Go, il est recommandé de nepas utiliser un disque inférieur à 20 Go, même à des ns de test.

2.3.3 Taille recommandée pour les périphériques WAL et DB deBlueStore

Astuce : pour plus d'informationsReportez-vous à la Section 1.4, « BlueStore » pour plus d'informations sur BlueStore.

Nous vous recommandons de réserver 4  Go pour le périphérique WAL. La taillerecommandée pour DB est de 64 Go pour la plupart des workloads.

Si vous envisagez de placer les périphériques  WAL et DB sur le même disque, il estrecommandé d'utiliser une partition unique pour les deux périphériques, plutôt qued'utiliser une partition distincte pour chacun. Cela permet à Ceph d'utiliser également lepériphérique DB pour les opérations WAL. La gestion de l'espace disque est donc plusecace, car Ceph n'utilise la partition DB pour le WAL qu'en cas de nécessité. Un autreavantage est que la probabilité que la partition WAL soit pleine est très faible, et lorsqu'ellen'est pas entièrement utilisée, son espace n'est pas gaspillé, mais utilisé pour les opérationsde DB.Pour partager le périphérique DB avec le WAL, ne spéciez pas le périphérique WAL etindiquez uniquement le périphérique DB.Pour plus d'informations sur la spécication d'une disposition OSD, reportez-vous à laSection 5.5.2, « Groupes d'unités ».

14 Taille minimale du disque SES 6

2.3.4 Utilisation des disques SSD pour les journaux OSD

Les disques SSD n'ont pas de pièces mobiles. Cela réduit le temps d'accès aléatoire et la latencede lecture tout en accélérant le débit de données. Comme leur prix par Mo est signicativementplus élevé que le prix des disques durs tournants, les disques SSD ne conviennent que pour unstockage plus petit.

Les OSD peuvent connaître une amélioration signicative des performances en stockant leurjournal sur un disque SSD et les données d'objet sur un disque dur distinct.

Astuce : partage d'un disque SSD pour plusieurs journauxComme les données de journal occupent relativement peu d'espace, vous pouvez monterplusieurs répertoires de journaux sur un seul disque SSD. N'oubliez pas qu'avec chaquejournal partagé, les performances du disque  SSD se dégradent. Il est déconseillé departager plus de six journaux sur le même disque SSD et 12 sur des disques NVMe.

2.3.5 Nombre maximal recommandé de disques

Vous pouvez avoir autant de disques sur un serveur que ce dernier l'autorise. Il existe quelquesaspects à considérer lorsque vous planiez le nombre de disques par serveur :

Bande passante du réseau. Plus vous avez de disques sur un serveur, plus il y a de donnéesà transférer via la ou les cartes réseau pour les opérations d'écriture sur disque.

Mémoire. Plus de 2 Go de RAM sont utilisés pour le cache BlueStore. Avec la valeur pardéfaut de l'option osd_memory_target , à savoir 4 Go, le système dispose d'une taille decache de départ raisonnable pour les supports rotatifs. Si vous utilisez des disques SSDou NVMe, pensez à augmenter la taille du cache et l'allocation de RAM par OSD and'optimiser les performances.

Tolérance aux pannes. Si le serveur complet tombe en panne, plus il comporte de disques,plus le nombre d'OSD perdus temporairement par la grappe est important. En outre, pourmaintenir les règles de réplication en cours d'exécution, vous devez copier toutes lesdonnées du serveur en panne vers les autres noeuds de la grappe.

15 Utilisation des disques SSD pour les journaux OSD SES 6

2.4 Noeuds de moniteur

Au moins trois noeuds de moniteur Ceph sont requis. Le nombre de moniteurs doit toujoursêtre impair (1+2n).

4 Go de RAM.

Processeur à quatre coeurs logiques.

Un SSD ou un autre type de support de stockage susamment rapide est vivementrecommandé pour les moniteurs, en particulier pour le chemin /var/lib/ceph sur chaquenoeud de moniteur, car le quorum peut être instable avec des latences de disque élevées.Deux disques en conguration RAID  1 sont recommandés pour la redondance. Il estrecommandé d'utiliser des disques distincts ou au moins des partitions de disque distinctespour les processus Monitor, an de protéger l'espace disque disponible du moniteur contredes phénomènes tels que le grossissement excessif du chier journal.

Il ne doit y avoir qu'un seul processus Monitor par noeud.

La combinaison des noeuds OSD, Monitor ou Object Gateway n'est prise en charge que sides ressources matérielles susantes sont disponibles. Cela signie que les besoins de tousles services doivent être additionnés.

Deux interfaces réseau liées à plusieurs commutateurs.

2.5 Noeuds Object GatewayLes noeuds Object Gateway doivent comporter six à huit coeurs d'UC et 32 Go de RAM (64 Gorecommandés). Lorsque d'autres processus sont colocalisés sur la même machine, leurs besoinsdoivent être additionnés.

16 Noeuds de moniteur SES 6

2.6 Noeuds MDSLe dimensionnement approprié des noeuds MDS (Metadata Server, Serveur de métadonnées)dépend du cas d'utilisation spécique. En règle générale, plus le nombre de chiers ouvertsque le serveur de métadonnées doit traiter est important, plus l'UC et la RAM requises sontimportantes. La conguration minimale requise est la suivante :

3 Go de RAM pour chaque daemon MDS.

Interface réseau liée.

2,5 GHz d'UC avec au moins 2 coeurs.

2.7 Salt MasterAu moins 4 Go de RAM et une UC quadruple coeur sont requis. Cela inclut l'exécution de CephDashboard sur le noeud Admin. Pour les grappes de grande taille avec des centaines de noeuds,6 Go de RAM sont conseillés.

2.8 Noeuds iSCSILes noeuds iSCSI doivent comporter six à huit coeurs d'UC et 16 Go de RAM.

2.9 Recommandations concernant le réseauL'environnement réseau dans lequel vous envisagez d'exécuter Ceph doit idéalement être unensemble lié d'au moins deux interfaces réseau divisées logiquement en une partie publiqueet une partie interne approuvée en utilisant des VLAN. Le mode de liaison recommandé est802.3ad, si possible, pour fournir une bande passante et une résilience maximales.

Le VLAN public sert à fournir le service aux clients, alors que la partie interne assure lescommunications réseau Ceph authentiées. La raison principale en est que, bien que Cephfournisse une authentication et une protection contre les attaques une fois que les clés secrètessont en place, les messages utilisés pour congurer ces clés peuvent être transférés ouvertementet sont vulnérables.

17 Noeuds MDS SES 6

Astuce : noeuds configurés via DHCPSi les noeuds de stockage sont congurés via DHCP, les timeouts par défaut peuvent nepas être susants pour que le réseau soit conguré correctement avant le démarragedes diérents daemons Ceph. Dans ce cas, les daemons Ceph MON et OSD ne démarrentpas correctement (l'exécution de systemctl status ceph\* provoquera des erreurs detype « unable to bind » [liaison impossible]). Pour éviter ce problème, il est recommandéd'augmenter le timeout du client DHCP à au moins 30 secondes sur chaque noeud devotre grappe de stockage. Pour ce faire, vous pouvez modier les paramètres suivantssur chaque noeud :

Dans /etc/sysconfig/network/dhcp , dénissez

DHCLIENT_WAIT_AT_BOOT="30"

Dans /etc/sysconfig/network/config , dénissez

WAIT_FOR_INTERFACES="60"

2.9.1 Ajout d'un réseau privé à une grappe en cours d'exécution

Si vous ne spéciez pas de réseau pour la grappe lors du déploiement de Ceph, il suppose unenvironnement de réseau public unique. Bien que Ceph fonctionne parfaitement avec un réseaupublic, ses performances et sa sécurité s'améliorent lorsque vous dénissez un second réseaude grappe privé. Pour prendre en charge deux réseaux, chaque noeud Ceph doit disposer d'aumoins deux cartes réseau.

Vous devez apporter les modications suivantes à chaque noeud Ceph. Ces modications sontrelativement rapides à apporter à une petite grappe, mais peuvent prendre beaucoup de tempssi votre grappe est composée de centaines ou de milliers de noeuds.

1. Arrêtez les services associés à Ceph sur chaque noeud de la grappe.Ajoutez une ligne à /etc/ceph/ceph.conf pour dénir le réseau de la grappe, parexemple :

cluster network = 10.0.0.0/24

Si vous devez assigner des adresses  IP statiques ou remplacer les paramètres clusternetwork , vous pouvez le faire avec la variable facultative cluster addr .

18 Ajout d'un réseau privé à une grappe en cours d'exécution SES 6

2. Vériez que le réseau privé de la grappe fonctionne comme prévu au niveau du systèmed'exploitation.

3. Démarrez les services associés à Ceph sur chaque noeud de la grappe.

root # systemctl start ceph.target

2.9.2 Noeuds de moniteur sur des sous-réseaux distincts

Si les noeuds de moniteur se trouvent sur plusieurs sous-réseaux, par exemple s'ils se trouventdans des pièces diérentes et sont desservis par des commutateurs diérents, vous devezcorriger le chier ceph.conf en conséquence. Par exemple, si les noeuds ont les adresses IP192.168.123.12, 1.2.3.4 et 242.12.33.12, ajoutez les lignes suivantes à la section global  :

[global][...]mon host = 192.168.123.12, 1.2.3.4, 242.12.33.12mon initial members = MON1, MON2, MON3[...]

En outre, si vous devez spécier une adresse ou un réseau public par moniteur, vous devezajouter une section [mon.X] pour chaque moniteur :

[mon.MON1]public network = 192.168.123.0/24

[mon.MON2]public network = 1.2.3.0/24

[mon.MON3]public network = 242.12.33.12/0

2.10 Limitations relatives à la dénominationCeph ne prend généralement pas en charge les caractères non-ASCII dans les chiers deconguration, les noms de réserve, les noms d'utilisateur, etc. Lors de la conguration d'unegrappe Ceph, il est recommandé d'utiliser uniquement des caractères alphanumériques simples(A-Z, a-z, 0-9) et des ponctuations minimales (« . », « - », « _ ») dans tous les noms d'objet/deconguration Ceph.

19 Noeuds de moniteur sur des sous-réseaux distincts SES 6

2.11 Noeuds OSD et Monitor partageant un mêmeserveurBien qu'il soit techniquement possible d'exécuter les noeuds Ceph OSD et Monitor sur le mêmeserveur dans des environnements de test, il est vivement recommandé de disposer d'un serveurdistinct pour chaque noeud de moniteur en production. La principale raison est la performance :plus la grappe comporte d'OSD, plus le nombre d'opérations d'E/S que les noeuds de moniteurdoivent eectuer est grand. Et lorsqu'un serveur est partagé entre un noeud de moniteur etplusieurs OSD, les opérations d'E/S des OSD constituent un facteur limitant pour le noeud demoniteur.

Une autre considération consiste à savoir s'il faut partager des disques entre un OSD, un noeudde moniteur et le système d'exploitation sur le serveur. La réponse est simple : si possible, dédiezun disque distinct à l'OSD et un serveur distinct au noeud de moniteur.

Bien que Ceph prenne en charge les OSD basés sur les répertoires, un OSD doit toujours avoirun disque dédié autre que celui du système d'exploitation.

AstuceS'il est vraiment nécessaire d'exécuter l'OSD et le noeud de moniteur sur le même serveur,exécutez le noeud de moniteur sur un disque distinct en montant le disque dans lerépertoire /var/lib/ceph/mon pour obtenir de meilleures performances.

2.12 Configuration recommandée de la grappe deproduction

Sept noeuds de stockage des objets

Aucun noeud n'excède environ 15 % du stockage total

10 Gigabit Ethernet (quatre réseaux physiques liés à plusieurs commutateurs)

Au moins 56 OSD par grappe de stockage

Disques OS RAID 1 pour chaque noeud de stockage OSD

Disques SSD pour journal avec un ratio journal SSD à OSD de 6:1

20 Noeuds OSD et Monitor partageant un même serveur SES 6

1,5 Go de RAM par To de capacité OSD brute pour chaque noeud de stockage desobjets

2 GHz par OSD pour chaque noeud de stockage des objets

Noeuds d'infrastructure physique dédiés

Trois noeuds de moniteur Ceph : 4 Go de RAM, processeur à 4 coeurs, disques SSDRAID 1

Un noeud de gestion de SES : 4 Go de RAM, processeur à 4 coeurs, disques SSD RAID 1

Déploiement physique redondant des noeuds de passerelle ou MDS :

Noeuds Object Gateway : 32 Go de RAM, processeur à 8 coeurs, disques SSDRAID 1

Noeuds Passerelle iSCSI : 16 Go de RAM, processeur à 4 coeurs, disques SSDRAID 1

Noeuds MDS (un actif/un de secours) : 32 Go de RAM, processeur à 8 coeurs,disques SSD RAID 1

2.13 SUSE Enterprise Storage 6 et autres produitsSUSECette section contient des informations importantes sur l'intégration deSUSE Enterprise Storage 6 à d'autres produits SUSE.

2.13.1 SUSE Manager

SUSE  Manager et SUSE  Enterprise  Storage n'étant pas intégrés, SUSE  Manager ne peutactuellement pas gérer une grappe SUSE Enterprise Storage.

21 SUSE Enterprise Storage 6 et autres produits SUSE SES 6

3 Configuration haute disponibilité du noeud Admin

Le noeud Admin est un noeud de la grappe Ceph sur lequel le service Salt Master s'exécute. Lenoeud Admin est un point central de la grappe Ceph, car il gère les autres noeuds de la grappeen interrogeant et en instruisant leurs services de minion Salt. En général, il inclut égalementd'autres services, par exemple l'interface utilisateur Ceph Dashboard avec le tableau de bordGrafana et le toolkit de surveillance Prometheus.

En cas de défaillance du noeud Admin, vous devez généralement fournir un nouveau matérielpour le noeud et restaurer la pile de conguration complète de la grappe à partir d'unesauvegarde récente. Cette méthode prend énormément de temps et provoque l'interruption dela grappe.

Pour éviter le temps hors service de la grappe Ceph causé par la défaillance du noeud Admin,il est recommandé d'utiliser une grappe haute disponibilité (High Availability, HA) pour lenoeud Admin Ceph.

3.1 Aperçu de la grappe HA pour le noeud AdminLe principe d'une grappe HA est qu'en cas de défaillance d'un noeud de la grappe, un autre noeudprend automatiquement en charge son rôle, y compris le noeud Admin virtualisé. De cette façon,les autres noeuds de la grappe Ceph ne remarquent pas la défaillance du noeud Admin.

La solution HA minimale pour le noeud Admin requiert le matériel suivant :

Deux serveurs sans système d'exploitation en mesure d'exécuter SUSE Linux Enterpriseavec l'extension haute disponibilité et de virtualiser le noeud Admin.

Deux ou plusieurs chemins de communication réseau redondants, par exemple via la liaisonde périphérique réseau.

Un stockage partagé pour héberger les images de disque de la machine virtuelle dunoeud Admin. Le stockage partagé doit être accessible depuis les deux serveurs. Il peuts'agir, par exemple, d'une exportation NFS, d'un partage Samba ou d'une cible iSCSI.

Pour plus de détails sur les conditions requises de la grappe, reportez-vous à la page https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/

sec_ha_inst_quick_req.html .

22 Aperçu de la grappe HA pour le noeud Admin SES 6

FIGURE 3.1T : GRAPPE HAUTE DISPONIBILITÉ À 2 NOEUDS POUR LE NOEUD ADMIN

3.2 Création d'une grappe HA avec le noeud AdminLa procédure suivante résume les étapes les plus importantes de la création d'une grappe hautedisponibilité pour la virtualisation du noeud Admin. Pour plus d'informations, reportez-vousaux liens indiqués.

1. Congurez une grappe haute disponibilité à 2  noeuds de base avec un stockagepartagé comme décrit dans le manuel https://www.suse.com/documentation/sle-ha-15/

book_sleha_quickstarts/data/art_sleha_install_quick.html .

2. Sur les deux noeuds de la grappe, installez tous les paquetages requis pour l'exécutionde l'hyperviseur  KVM et du toolkit libvirt comme décrit dans le manuel https://

www.suse.com/documentation/sles-15/book_virt/data/sec_vt_installation_kvm.html .

3. Sur le premier noeud de la grappe, créez une machine virtuelle  KVM en utilisantlibvirt comme décrit dans le manuel https://www.suse.com/documentation/sles-15/

book_virt/data/sec_libvirt_inst_vmm.html . Utilisez le stockage partagé préconguré pourstocker les images de disque de la machine virtuelle.

4. Une fois la conguration de la machine virtuelle terminée, exportez sa conguration dansun chier XML sur le stockage partagé. Utilisez la syntaxe suivante.

root # virsh dumpxml VM_NAME > /path/to/shared/vm_name.xml

23 Création d'une grappe HA avec le noeud Admin SES 6

5. Créez une ressource pour la machine virtuelle du noeud  Admin. Reportez-vous à l'adresse https://www.suse.com/documentation/sle-ha-15/book_sleha_guide/data/

cha_conf_hawk2.html pour des informations générales sur la création de ressourceshaute disponibilité. Des informations détaillées sur la création de ressources pourune machine virtuelle  KVM sont décrites à l'adresse http://www.linux-ha.org/wiki/

VirtualDomain_%28resource_agent%29 .

6. Sur l'invité de la machine virtuelle qui vient d'être créé, déployez le noeud  Admin, ycompris les services supplémentaires dont vous avez besoin. Suivez les étapes appropriéesde la Section 5.3, « Déploiement de la grappe ». En même temps, déployez les noeuds de lagrappe Ceph restants sur les serveurs de grappe non-HA.

24 Création d'une grappe HA avec le noeud Admin SES 6

4 Privilèges des utilisateurs et invites de commande

En tant qu'administrateur de grappe Ceph, vous congurez et ajustez le comportement de lagrappe en exécutant des commandes spéciques. Il existe plusieurs types de commandes dontvous avez besoin :

4.1 Commandes associées à Salt/DeepSeaCes commandes vous aident à déployer ou à mettre à niveau la grappe Ceph, à exécuterdes commandes simultanément sur plusieurs noeuds de la grappe (ou tous), ou à ajouter ousupprimer des noeuds de la grappe. Les plus fréquemment utilisées sont salt , salt-run etdeepsea . Vous devez exécuter les commandes Salt sur le noeud Salt Master (voir Section 5.2,

« Présentation de DeepSea » pour les détails) en tant qu'utilisateur root . Ces commandes sontintroduites avec l'invite suivante :

root@master #

Par exemple :

root@master # salt '*.example.net' test.ping

4.2 Commandes associées à CephIl s'agit de commandes de niveau inférieur pour congurer et aner tous les aspects de la grappeet de ses passerelles sur la ligne de commande. Citons notamment les suivantes : ceph , rbd ,radosgw-admin ou crushtool .

Pour exécuter les commandes associées à Ceph, vous devez disposé d'un accès en lecture à uneclé Ceph. Les fonctionnalités de la clé dénissent alors vos privilèges au sein de l'environnementCeph. Une option consiste à exécuter les commandes Ceph en tant qu'utilisateur root (ou viasudo ) et à employer le trousseau de clés par défaut sans restriction « ceph.client.admin.key ».

L'option plus sûre et recommandée est de créer une clé individuelle plus restrictive pour chaqueadministrateur et de la placer dans un répertoire où les utilisateurs peuvent la lire, par exemple :

~/.ceph/ceph.client.USERNAME.keyring

25 Commandes associées à Salt/DeepSea SES 6

Astuce : chemin des clés CephPour utiliser un administrateur et un trousseau de clés personnalisés, vous devez spécierle nom d'utilisateur et le chemin d'accès à la clé chaque fois que vous exécutez lacommande ceph à l'aide des options -n client.NOM_UTILISATEUR et --keyringCHEMIN/VERS/TROUSSEAU .

Pour éviter cela, incluez ces options dans la variable CEPH_ARGS des chiers ~/.bashrcdes diérents utilisateurs.

Bien que vous puissiez exécuter les commandes associées à Ceph sur n'importe quel noeud de lagrappe, nous vous recommandons de les lancer sur le noeud Admin. Dans cette documentation,nous employons l'utilisateur cephadm pour exécuter les commandes. Elles sont donc introduitesavec l'invite suivante :

cephadm@adm >

Par exemple :

cephadm@adm > ceph auth list

Astuce : commandes de noeuds spécifiquesSi la documentation vous demande d'exécuter une commande sur un noeud de la grappeavec un rôle spécique, cela sera réglé par l'invite. Par exemple :

cephadm@mon >

4.3 Commandes Linux généralesLes commandes Linux non associées à Ceph ou à DeepSea, telles que mount , cat ou openssl ,sont introduites avec les invites cephadm@adm > ou root # , selon les privilèges que lacommande concernée nécessite.

26 Commandes Linux générales SES 6

4.4 Informations complémentairesPour plus d'informations sur la gestion des clés Ceph, reportez-vous à la Manuel «  Guide

d'administration », Chapitre 8 « Authentification avec cephx », Section 8.2 « Gestion des clés ».

27 Informations complémentaires SES 6

II Déploiement et mise à niveau de lagrappe

5 Déploiement avec DeepSea/Salt 29

6 Mise à jour à partir de versions précédentes 64

7 Personnalisation de la configuration par défaut 94

5 Déploiement avec DeepSea/Salt

Salt avec DeepSea est une pile de composants qui vous permet de déployer et gérer uneinfrastructure de serveur. Cet ensemble est très évolutif, rapide et relativement facile à mettreen route. Lisez les considérations suivantes avant de démarrer le déploiement de la grappe avecSalt :

Les minions Salt sont les noeuds contrôlés par un noeud dédié appelé Salt Master. Lesminions Salt possèdent des rôles, par exemple Ceph OSD, Ceph Monitor, Ceph Manager,Object Gateway, Passerelle iSCSI ou NFS Ganesha.

Une instance Salt Master exécute son propre minion Salt. Cela est requis pour l'exécutionde tâches privilégiées, par exemple la création, l'autorisation et la copie de clés versdes minions, an que les minions distants n'aient jamais besoin d'exécuter des tâchesprivilégiées.

Astuce : partage de plusieurs rôles par serveurVous obtiendrez les meilleures performances de votre grappe Ceph lorsque chaquerôle est déployé sur un noeud distinct. Toutefois, les déploiements réels nécessitentparfois le partage d'un noeud entre plusieurs rôles. Pour éviter les problèmes liés auxperformances et à la procédure de mise à niveau, ne déployez pas le rôle Ceph OSD,Serveur de métadonnées ou Ceph Monitor sur le noeud Admin.

Les minions Salt doivent résoudre correctement le nom d'hôte de Salt Master sur le réseau.Par défaut, ils recherchent le nom d'hôte salt , mais vous pouvez spécier tout autrenom d'hôte accessible par le réseau dans le chier /etc/salt/minion . Reportez-vous àla Section 5.3, « Déploiement de la grappe ».

29 SES 6

5.1 Lecture des notes de versionLes notes de version contiennent des informations supplémentaires sur les modicationsapportées depuis la version précédente de SUSE  Enterprise  Storage. Consultez les notes deversion pour vérier les aspects suivants :

Votre matériel doit tenir compte de certaines considérations spéciales.

Les paquetages logiciels utilisés ont été considérablement modié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 lesproblèmes connus.

Après avoir installé le paquetage release-notes-ses , les notes de version sont disponiblesen local dans le répertoire /usr/share/doc/release-notes ou en ligne à l'adresse https://

www.suse.com/releasenotes/ .

5.2 Présentation de DeepSeaL'objectif de DeepSea est de faire gagner du temps à l'administrateur et d'eectuer en touteconance des opérations complexes sur une grappe Ceph.

Ceph est une solution logicielle très congurable. Elle accroît la liberté et la responsabilité desadministrateurs système.

La conguration minimale de Ceph est adaptée à des ns de démonstration, mais ne présentepas les fonctions particulièrement intéressantes de Ceph que vous pouvez voir avec un grandnombre de noeuds.

DeepSea collecte et stocke des données sur des serveurs individuels, tels que les adresses et nomsde périphérique. Pour un système de stockage distribué tel que Ceph, il peut y avoir des centainesd'éléments de ce type à collecter et stocker. Collecter des informations et saisir des donnéesmanuellement dans un outil de gestion de la conguration est fastidieux et sujet à erreurs.

Les étapes nécessaires pour préparer les serveurs, collecter la conguration ainsi que congureret déployer Ceph sont pour la plupart les mêmes. Cependant, cela ne concerne pas la gestiondes fonctions distinctes. Pour les opérations quotidiennes, la possibilité d'ajouter simplement dumatériel à une fonction donnée et de l'enlever correctement est une condition requise.

30 Lecture des notes de version SES 6

DeepSea répond à ces observations par la stratégie suivante : DeepSea consolide les décisions del'administrateur dans un seul chier. Les décisions incluent l'assignation des grappes, des rôleset des prols. DeepSea rassemble chaque ensemble de tâches dans un objectif simple. Chaqueobjectif est une phase :

DESCRIPTION DES PHASES DE DEEPSEA

Phase  0  : la préparation. Lors de cette phase, toutes les mises à jour requises sontappliquées et votre système peut être redémarré.

Important : réexécution de la phase 0 après le redémarragedu noeud AdminSi, au cours de la phase 0, le noeud Admin redémarre pour charger la nouvelleversion du kernel, vous devez à nouveau exécuter la phase 0, sinon les minions nesont pas ciblés.

Phase 1  : la découverte. Au cours de cette phase, tout le matériel de votre grappe estdétecté et les informations nécessaires pour la conguration Ceph sont collectées. Pour plusd'informations concernant la conguration, reportez-vous à la Section 5.5, « Configuration et

personnalisation ».

Phase 2  : la conguration. Vous devez préparer les données de conguration dans unformat particulier.

Phase 3 : le déploiement. Vous créez une grappe Ceph de base avec les services Cephobligatoires. Reportez-vous à la Section 1.2.3, « Noeuds et daemons Ceph » pour leur liste.

Phase  4  : les services. Des fonctions supplémentaires de Ceph, comme iSCSI, ObjectGateway et CephFS, peuvent être installées lors de cette phase. Chacune est facultative.

Phase 5 : phase de suppression. Cette phase n'est pas obligatoire et, lors de la congurationinitiale, elle n'est généralement pas nécessaire. Dans cette phase, les rôles des minions etde la conguration en grappe sont supprimés. Vous devez exécuter cette phase lorsquevous devez supprimer un noeud de stockage de votre grappe. Pour plus d'informations,reportez-vous au Manuel « Guide d'administration », Chapitre 2 « Administration de grappe Salt »,

Section 2.3 « Suppression et réinstallation de noeuds de grappe ».

31 Présentation de DeepSea SES 6

5.2.1 Organisation et emplacements importants

Salt dispose de plusieurs emplacements standard et de plusieurs conventions de dénominationutilisés sur le noeud maître :

/srv/pillar

Le répertoire stocke les données de conguration des minions de votre grappe. Pillar estune interface permettant de fournir des valeurs de conguration globales à tous les minionsde votre grappe.

/srv/salt/

Le répertoire stocke les chiers d'état Salt (également appelés chiers sls). Les chiersd'état sont des descriptions formatées des états dans lesquels la grappe doit se trouver.

/srv/module/runners

Le répertoire stocke des scripts Python appelés runners (exécuteurs). Les exécuteurs sontexécutés sur le noeud maître.

/srv/salt/_modules

Le répertoire stocke des scripts Python appelés modules. Les modules sont appliqués à tousles minions de la grappe.

/srv/pillar/ceph

Le répertoire est utilisé par DeepSea. Les données de conguration collectées sont stockéesici.

/srv/salt/ceph

Un répertoire utilisé par DeepSea. Il stocke des chiers SLS pouvant présenter diérentsformats, mais chaque sous-répertoire contient des chiers SLS. Chaque sous-répertoire necontient qu'un seul type de chier SLS. Par exemple, /srv/salt/ceph/stage contient leschiers d'orchestration exécutés par salt-run state.orchestrate .

5.2.2 Ciblage des minions

Les commandes DeepSea sont exécutées via l'infrastructure Salt. Lorsque vous utilisez lacommande salt , vous devez spécier un ensemble de minions Salt que la commande aecte.Nous décrivons l'ensemble des minions comme une cible pour la commande salt . Les sectionssuivantes décrivent les méthodes possibles pour cibler les minions.

32 Organisation et emplacements importants SES 6

5.2.2.1 Mise en correspondance du nom du minion

Vous pouvez cibler un minion ou un groupe de minions en faisant correspondre leurs noms.Le nom d'un minion est généralement le nom d'hôte court du noeud sur lequel est exécuté leminion. Il s'agit d'une méthode générale de ciblage de Salt, non liée à DeepSea. Vous pouvezutiliser la syntaxe générique, les expressions régulières ou des listes pour limiter l'étendue desnoms de minion. La syntaxe générale est la suivante :

root@master # salt target example.module

Astuce : grappe Ceph uniquementSi tous les minions Salt de votre environnement appartiennent à votre grappe Ceph,vous pouvez remplacer en toute sécurité target par '*' an d'inclure tous les minionsenregistrés.

Faire correspondre tous les minions du domaine example.net (en supposant que les noms desminions soient identiques à leurs noms d'hôte « complet ») :

root@master # salt '*.example.net' test.ping

Faire correspondre les minions « web1 » à « web5 » :

root@master # salt 'web[1-5]' test.ping

Faire correspondre les minions «  web1-prod  » et «  web1-devel  » à l'aide d'une expressionrégulière :

root@master # salt -E 'web1-(prod|devel)' test.ping

Faire correspondre une simple liste de minions :

root@master # salt -L 'web1,web2,web3' test.ping

Faire correspondre tous les minions de la grappe :

root@master # salt '*' test.ping

33 Ciblage des minions SES 6

5.2.2.2 Ciblage avec un grain DeepSea

Dans un environnement hétérogène géré par Salt dans lequel SUSE Enterprise Storage 6 estdéployé sur un sous-ensemble de noeuds en plus d'autres solutions de grappe, vous devezmarquer les minions pertinents en leur appliquant un grain « deepsea  » avant d'exécuter laphase 0 de DeepSea. De cette manière, vous pouvez facilement cibler les minions DeepSea dansles environnements où la correspondance par le nom du minion est problématique.

Pour appliquer le grain « deepsea » à un groupe de minions, exécutez :

root@master # salt target grains.append deepsea default

Pour supprimer le grain « deepsea » d'un groupe de minions, exécutez :

root@master # salt target grains.delval deepsea destructive=True

Après avoir appliqué le grain « deepsea » aux minions pertinents, vous pouvez les cibler commesuit :

root@master # salt -G 'deepsea:*' test.ping

La commande suivante est un équivalent :

root@master # salt -C 'G@deepsea:*' test.ping

5.2.2.3 Définition de l'option deepsea_minions

La conguration de la cible de l'option deepsea_minions est une condition requise desdéploiements DeepSea. DeepSea l'utilise pour instruire les minions lors de l'exécution des phases(pour plus d'informations, reportez-vous à la section Description des phases de DeepSea).

Pour dénir ou modier l'option deepsea_minions , modiez le chier /srv/pillar/ceph/deepsea_minions.sls de Salt Master et ajoutez ou remplacez la ligne suivante :

deepsea_minions: target

Astuce : cible deepsea_minionsComme valeur target (cible) de l'option deepsea_minions , vous pouvez utilisern'importe quelle méthode de ciblage : Mise en correspondance du nom du minion et Ciblage

avec un grain DeepSea.

Faire correspondre tous les minions Salt de la grappe :

deepsea_minions: '*'

34 Ciblage des minions SES 6

Faire correspondre tous les minions avec le grain « deepsea » :

deepsea_minions: 'G@deepsea:*'

5.2.2.4 Complément d'informations

Vous pouvez utiliser des méthodes plus avancées pour cibler les minions en utilisantl'infrastructure Salt. La page du manuel « deepsea-minions » vous donne plus de détails sur leciblage DeepSea ( man 7 deepsea_minions ).

5.3 Déploiement de la grappeLe processus de déploiement de la grappe comporte plusieurs phases. Tout d'abord, vous devezpréparer tous les noeuds de la grappe en congurant Salt, puis déployer et congurer Ceph.

Astuce : déploiement des noeuds de moniteur sans définitiondes profils OSDSi vous devez ignorer la dénition des rôles de stockage pour OSD comme décrit à laSection 5.5.1.2, « Assignation de rôle » et commencer par déployer les noeuds Ceph Monitor,vous pouvez le faire en dénissant la variable DEV_ENV .

Cela permet de déployer des moniteurs sans la présence du répertoire role-storage/ ,ainsi que de déployer une grappe Ceph avec au moins un rôle de stockage, de moniteuret de gestionnaire.

Pour dénir la variable d'environnement, activez-la globalement en la dénissant dansle chier /srv/pillar/ceph/stack/global.yml , ou dénissez-la pour la session Shellactuelle uniquement :

root@master # export DEV_ENV=true

À titre d'exemple, /srv/pillar/ceph/stack/global.yml peut être créé avec le contenusuivant :

DEV_ENV: True

35 Déploiement de la grappe SES 6

La procédure suivante décrit en détail la préparation de la grappe.

1. Installez et enregistrez SUSE  Linux  Enterprise  Server  15  SP1 avec l'extensionSUSE Enterprise Storage 6 sur chaque noeud de la grappe.

2. Vériez que les produits appropriés sont installés et enregistrés en répertoriant les dépôtslogiciels existants. Exécutez zypper lr-E et comparez la sortie avec la liste suivante :

SLE-Product-SLES15-SP1-Pool SLE-Product-SLES15-SP1-Updates SLE-Module-Server-Applications15-SP1-Pool SLE-Module-Server-Applications15-SP1-Updates SLE-Module-Basesystem15-SP1-Pool SLE-Module-Basesystem15-SP1-Updates SUSE-Enterprise-Storage-6-Pool SUSE-Enterprise-Storage-6-Updates

3. Congurez les paramètres réseau, y compris la résolution de nom DNS appropriée surchaque noeud. Salt Master et tous les minions Salt doivent se résoudre mutuellementpar leur nom d'hôte. Pour plus d'informations sur la conguration d'un réseau,reportez-vous à l'adresse https://www.suse.com/documentation/sles-15/book_sle_admin/

data/sec_network_yast.html Pour plus d'informations sur la conguration d'unserveur  DNS, reportez-vous à l'adresse https://www.suse.com/documentation/sles-15/

book_sle_admin/data/cha_dns.html .

4. Sélectionnez un(e) ou plusieurs serveurs horaires/réserves et synchronisez l'heurelocale par rapport à ces derniers/dernières. Vériez que le service de synchronisationhoraire est activé à chaque démarrage du système. Vous pouvez utiliser la commandeyast ntp-client trouvée dans un paquetage yast2-ntp-client pour congurer lasynchronisation horaire.

AstuceLes machines virtuelles ne sont pas des sources NTP ables.

Pour plus d'informations sur la conguration de NTP, reportez-vous à l'adresse https://

www.suse.com/documentation/sles-15/book_sle_admin/data/sec_ntp_yast.html .

5. Installez les paquetages salt-master et salt-minion sur le noeud Salt Master :

root@master # zypper in salt-master salt-minion

36 Déploiement de la grappe SES 6

Vériez si le service salt-master est activé et démarré, puis activez-le et démarrez-le,le cas échéant :

root@master # systemctl enable salt-master.serviceroot@master # systemctl start salt-master.service

6. Si vous envisagez d'utiliser un pare-feu, vériez si les ports 4505 et 4506 du noeud SaltMaster sont ouverts pour tous les noeuds minions Salt. Si les ports sont fermés, vous pouvezles ouvrir à l'aide de la commande yast2 firewall en autorisant le service SaltStack.

Avertissement : les phases de DeepSea échouent avec unpare-feuLes phases de déploiement de DeepSea échouent si le pare-feu est actif (outout simplement conguré). Pour eectuer correctement les phases, vous devezdésactiver le pare-feu en exécutant

root # systemctl stop firewalld.service

ou dénir l'option FAIL_ON_WARNING sur «  False  » dans /srv/pillar/ceph/stack/global.yml  :

FAIL_ON_WARNING: False

7. Installez le paquetage salt-minion sur tous les noeuds des minions.

root@minion > zypper in salt-minion

Assurez-vous que le nom de domaine complet de chaque noeud peut être résolu surl'adresse IP du réseau public par tous les autres noeuds.

8. Congurez tous les minions (y compris le minion maître) pour vous connecter au maître.Si votre instance Salt Master n'est pas accessible par le nom d'hôte salt , modiez lechier /etc/salt/minion ou créez un chier /etc/salt/minion.d/master.conf avecle contenu suivant :

master: host_name_of_salt_master

37 Déploiement de la grappe SES 6

Si vous avez apporté des modications aux chiers de conguration ci-dessus, redémarrezle service Salt sur tous les minions Salt :

root@minion > systemctl restart salt-minion.service

9. Vériez que le service salt-minion est activé et démarré sur tous les noeuds. Activezet démarrez-le, le cas échéant :

root # systemctl enable salt-minion.serviceroot # systemctl start salt-minion.service

10. Vériez l'empreinte digitale de chaque minion Salt et acceptez toutes les clés Salt sur SaltMaster si les empreintes digitales correspondent.

RemarqueSi l'empreinte de minion Salt revient vide, vériez que le minion Salt a uneconguration Salt Master et qu'il peut communiquer avec Salt Master.

Achez l'empreinte digitale de chaque minion :

root@master # salt-call --local key.fingerlocal:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

Après avoir collecté les empreintes digitales de tous les minions Salt, répertoriez lesempreintes de toutes les clés de minions non acceptées sur Salt Master :

root@master # salt-key -F[...]Unaccepted Keys:minion1:3f:a3:2f:3f:b4:d3:d9:24:49:ca:6b:2c:e1:6c:3f:c3:83:37:f0:aa:87:42:e8:ff...

Si les empreintes des minions correspondent, acceptez-les :

root@master # salt-key --accept-all

11. Vériez que les clés ont été acceptées :

root@master # salt-key --list-all

38 Déploiement de la grappe SES 6

12. Avant de déployer SUSE Enterprise Storage  6, eacez manuellement tous les disques.Pensez à remplacer « X » par la lettre du disque correct :

a. Arrêtez tous les processus qui utilisent le disque spécique.

b. Vériez si des partitions sur le disque sont montées et démontez-les le cas échéant.

c. Si le disque est géré par LVM, désactivez et supprimez la totalité del'infrastructure  LVM. Pour plus d'informations, reportez-vous à l'adresse https://

www.suse.com/documentation/sles-15/book_storage/data/cha_lvm.html .

d. Si le disque fait partie de MD  RAID, désactivez le RAID. Pour plusd'informations, reportez-vous à l'adresse https://www.suse.com/documentation/

sles-15/book_storage/data/part_software_raid.html .

e. Astuce : redémarrage du serveurSi vous recevez des messages d'erreur tels que « partition in use » (partitionen cours d'utilisation) ou « kernel cannot be updated with the new partitiontable  » (le kernel ne peut pas être mis à jour avec la nouvelle table departitions) durant les étapes suivantes, redémarrez le serveur.

Eacez le début de chaque partition (en tant que root ) :

for partition in /dev/sdX[0-9]*do dd if=/dev/zero of=$partition bs=4096 count=1 oflag=directdone

f. Eacez le début de l'unité :

root # dd if=/dev/zero of=/dev/sdX bs=512 count=34 oflag=direct

g. Eacez la n de l'unité :

root # dd if=/dev/zero of=/dev/sdX bs=512 count=33 \ seek=$((`blockdev --getsz /dev/sdX` - 33)) oflag=direct

h. Vériez que l'unité est vide (sans structure GPT) à l'aide de l'une des commandesci-dessous :

root # parted -s /dev/sdX print free

39 Déploiement de la grappe SES 6

ou

root # dd if=/dev/sdX bs=512 count=34 | hexdump -Croot # dd if=/dev/sdX bs=512 count=33 \ skip=$((`blockdev --getsz /dev/sdX` - 33)) | hexdump -C

13. Éventuellement, si vous devez précongurer les paramètres réseau de la grappeavant que le paquetage deepsea soit installé, créez manuellement le chier /srv/pilier/ceph/stack/ceph/cluster.yml et dénissez les options cluster_network: etpublic_network: . Notez que le chier ne sera pas écrasé après avoir installé deepsea .

Astuce : activation du protocole IPv6Si vous devez activer l'adressage réseau IPv6, reportez-vous à la Section  7.2.1,

« Activation du protocole IPv6 pour le déploiement de grappe Ceph ».

14. Installez DeepSea sur le noeud Salt Master :

root@master # zypper in deepsea

15. La valeur du paramètre master_minion est dérivée dynamiquement du chier /etc/salt/minion_id sur Salt Master. Si vous devez remplacer la valeur découverte, modiezle chier /srv/pillar/ceph/stack/global.yml et dénissez une valeur pertinente :

master_minion: MASTER_MINION_NAME

Si votre instance Salt Master est accessible via diérents noms d'hôte, utilisez le nom duminion Salt pour la grappe de stockage tel que renvoyé par la commande salt-key -L .Si vous avez utilisé le nom d'hôte par défaut pour votre Salt Master, salt, dans le domaineses, alors le chier se présente comme suit :

master_minion: salt.ses

À présent, vous pouvez déployer et congurer Ceph. Sauf indication contraire, toutes les étapessont obligatoires.

40 Déploiement de la grappe SES 6

Remarque : conventions relatives à la commande saltIl existe deux façons d'exécuter salt-run state.orch   : une avec« stage. NUMÉRO_PHASE  », l'autre avec le nom de la phase. Les deux notations ont la mêmeincidence et c'est à vous de choisir la commande que vous préférez.

PROCÉDURE 5.1T : EXÉCUTION DES PHASES DE DÉPLOIEMENT

1. Assurez-vous que les minions Salt appartenant à la grappe Ceph sontcorrectement ciblés par l'option deepsea_minions dans le chier /srv/pillar/

ceph/deepsea_minions.sls . Reportez-vous à la Section  5.2.2.3, «  Définition de l'option

deepsea_minions » pour plus d'informations.

2. Par défaut, DeepSea déploie des grappes Ceph avec des prols réglés actifs sur les noeudsCeph Monitor, Ceph Manager et Ceph OSD. Dans certains cas, vous devrez peut-êtreeectuer le déploiement sans prols réglés. Pour ce faire, placez les lignes suivantes dansle chier /srv/pillar/ceph/stack/global.yml avant d'exécuter les phases DeepSea :

alternative_defaults: tuned_mgr_init: default-off tuned_mon_init: default-off tuned_osd_init: default-off

3. Facultatif : créez des volumes secondaires Btrfs pour /var/lib/ceph/ . Cette étape doitêtre exécutée avant la phase 0 de DeepSea. Pour migrer les répertoires existants ou pourplus de détails, reportez-vous au Manuel « Guide d'administration », Chapitre 25 « Conseils et

astuces », Section 25.6 « Sous-volume Btrfs pour /var/lib/ceph sur les noeuds Ceph Monitor ».Appliquez les commandes suivantes à chacun des minions Salt :

root@master # salt 'MONITOR_NODES' saltutil.sync_allroot@master # salt 'MONITOR_NODES' state.apply ceph.subvolume

RemarqueLa commande Ceph.subvolume crée /var/lib/ceph en tant que sous-volume Btrfs@/var/lib/ceph .

Le nouveau sous-volume est maintenant monté et /etc/fstab est mis à jour.

41 Déploiement de la grappe SES 6

4. Préparez la grappe. Pour plus d'informations, reportez-vous à la section Description des

phases de DeepSea.

root@master # salt-run state.orch ceph.stage.0

ou

root@master # salt-run state.orch ceph.stage.prep

Remarque : exécution ou surveillance des phases à l'aidede l'interface de ligne de commande (CLI) de DeepSeaÀ l'aide de l'interface de ligne de commande de DeepSea, vous pouvez suivrela progression de l'exécution des phases en temps réel. Pour ce faire, exécutezl'interface de ligne de commande de DeepSea en mode de surveillance ou exécutez laphase directement par le biais de l'interface de ligne de commande de DeepSea. Pourplus d'informations, reportez-vous à la Section 5.4, « Interface de ligne de commande

de DeepSea ».

5. La phase de découverte collecte les données à partir de tous les minions et crée desfragments de conguration qui sont stockés dans le répertoire /srv/pillar/ceph/proposals . Les données sont stockées au format YAML dans des chiers *.sls ou *.yml.Exécutez la commande suivante pour déclencher la phase de découverte :

root@master # salt-run state.orch ceph.stage.1

ou

root@master # salt-run state.orch ceph.stage.discovery

6. Une fois la commande précédente terminée, créez un chier policy.cfg dans /srv/pillar/ceph/proposals . Pour plus d'informations, reportez-vous à la Section  5.5.1,

« Fichier policy.cfg ».

AstuceSi vous devez modier le paramètre réseau de la grappe, modiez /srv/

pillar/ceph/stack/ceph/cluster.yml et ajustez les lignes commençant parcluster_network: et public_network: .

42 Déploiement de la grappe SES 6

7. La phase de conguration analyse le chier policy.cfg et fusionne les chiers inclusdans leur forme nale. La grappe et le contenu lié au rôle sont placés dans /srv/pillar/ceph/cluster , tandis que le contenu spécique à Ceph est placé dans /srv/pillar/ceph/stack/default .Exécutez la commande suivante pour déclencher la phase de conguration :

root@master # salt-run state.orch ceph.stage.2

ou

root@master # salt-run state.orch ceph.stage.configure

L'étape de conguration peut prendre plusieurs secondes. Une fois la commande terminée,vous pouvez acher les données Pillar pour les minions spéciés (par exemple, nommésceph_minion1 , ceph_minion2 , etc.) en exécutant :

root@master # salt 'ceph_minion*' pillar.items

Astuce : modification de la disposition de l'OSDSi vous souhaitez modier la disposition par défaut de l'OSD et la conguration desgroupes d'unités, suivez la procédure décrite dans la Section 5.5.2, « Groupes d'unités ».

Remarque : écrasement des valeurs par défautDès la n de la commande, vous pouvez acher la conguration par défaut et lamodier pour l'adapter à vos besoins. Pour plus d'informations, reportez-vous auChapitre 7, Personnalisation de la configuration par défaut.

8. À présent, vous exécutez la phase de déploiement. À ce stade, Pillar est validé et lesdaemons Ceph Monitor et Ceph OSD sont lancés :

root@master # salt-run state.orch ceph.stage.3

ou

root@master # salt-run state.orch ceph.stage.deploy

43 Déploiement de la grappe SES 6

La commande peut prendre plusieurs minutes. Si elle échoue, vous devez résoudre leproblème et exécuter de nouveau les phases précédentes. Une fois que la commande aréussi, exécutez la commande suivante pour vérier l'état :

cephadm@adm > ceph -s

9. La dernière étape du déploiement de la grappe Ceph est la phase services. Au cours decette phase, vous instanciez des services actuellement pris en charge : Passerelle iSCSI,CephFS, Object Gateway et NFS Ganesha. C'est également lors de cette phase que les porte-clés d'autorisation, les services de démarrage et les réserves nécessaires sont créés. Pourdémarrer la phase, exécutez la commande suivante :

root@master # salt-run state.orch ceph.stage.4

ou

root@master # salt-run state.orch ceph.stage.services

Selon la conguration, la commande peut s'exécuter pendant plusieurs minutes.

10. Avant de continuer, nous vous recommandons fortement d'activer le module de télémétrieCeph. Pour plus d'informations et des instructions, reportez-vous au Manuel «  Guide

d'administration », Chapitre 10 « Modules Ceph Manager », Section 10.2 « Module de télémétrie ».

5.4 Interface de ligne de commande de DeepSeaDeepSea fournit également un outil d'interface de ligne de commande (CLI) qui permet àl'utilisateur de surveiller ou d'exécuter des phases tout en visualisant la progression de l'exécutionen temps réel. Vériez que le paquetage deepsea-cli est installé avant que vous exécutiezl'exécutable deepsea .

Deux modes sont pris en charge pour visualiser la progression de l'exécution d'une phase :

MODES DE L'INTERFACE DE LIGNE DE COMMANDE DE DEEPSEA

Monitoring mode (Mode de surveillance) : visualise la progression de l'exécution d'unephase DeepSea déclenchée par la commande salt-run émise dans une autre session determinal.

Stand-alone mode (Mode autonome) : exécute une phase de DeepSea tout en fournissantune visualisation en temps réel des étapes de ses composants lors de leur exécution.

44 Interface de ligne de commande de DeepSea SES 6

Important : commandes de l'interface de ligne de commandede DeepSeaLes commandes de l'interface de ligne de commande de DeepSea peuvent uniquementêtre exécutées sur le noeud Salt Master avec des privilèges root .

5.4.1 Interface de ligne de commande de DeepSea : mode desurveillance

La surveillance de la progression fournit une visualisation en temps réel détaillée de ce qui seproduit lors de l'exécution des phases à l'aide des commandes salt-run state.orch dansd'autres sessions de terminal.

Astuce : démarrage de la surveillance dans une nouvellesession de terminalVous devez lancer la surveillance avant l'exécution de salt-run state.orch an quela surveillance puisse détecter le début de l'exécution de la phase.

Si vous démarrez la surveillance après l'émission de la commande salt-run state.orch ,aucune progression de l'exécution ne s'ache.

Vous pouvez démarrer le mode de surveillance en exécutant la commande suivante :

root@master # deepsea monitor

Pour plus d'informations sur les options de ligne de commande disponibles de la commandedeepsea monitor , consultez sa page du manuel :

root@master # man deepsea-monitor

5.4.2 Interface de ligne de commande de DeepSea : modeautonome

En mode autonome, l'interface de ligne de commande de DeepSea peut être utilisée pour exécuterune phase DeepSea, achant son exécution en temps réel.

45 Interface de ligne de commande de DeepSea : mode de surveillance SES 6

La commande permettant d'exécuter une phase DeepSea à partir de l'interface de ligne decommande de DeepSea a la forme suivante :

root@master # deepsea stage run stage-name

où stage-name (nom-phase) correspond à la manière dont les chiers d'état d'orchestrationSalt sont référencés. Par exemple, la phase deploy, qui correspond au répertoire situé dans /srv/salt/ceph/stage/deploy , est référencée en tant que ceph.stage.deploy.

Cette commande est une alternative aux commandes basées sur Salt pour exécuter les phases deDeepSea (ou tout chier d'état d'orchestration DeepSea).

La commande deepsea stage run ceph.stage.0 équivaut à salt-run state.orchceph.stage.0 .

Pour plus d'informations sur les options de ligne de commande disponibles acceptées par lacommande deepsea stage run , consultez sa page du manuel :

root@master # man deepsea-stage run

46 Interface de ligne de commande de DeepSea : mode autonome SES 6

La gure suivante illustre un exemple de sortie de l'interface de ligne de commande de DeepSealors de l'exécution de la Phase 2 :

FIGURE 5.1T : SORTIE DE LA PROGRESSION DE L'EXÉCUTION DE LA PHASE DE L'INTERFACE DE LIGNE DECOMMANDE DE DEEPSEA

5.4.2.1 Alias stage run de l'interface de ligne de commande de DeepSea

Pour les utilisateurs avancés de Salt, nous prenons également en charge un alias pour l'exécutiond'une phase de DeepSea qui se sert de la commande Salt utilisée pour exécuter une phase,par exemple, salt-run state.orch stage-name (nom-phase), en tant que commande del'interface de ligne de commande de DeepSea.

Exemple :

root@master # deepsea salt-run state.orch stage-name

47 Interface de ligne de commande de DeepSea : mode autonome SES 6

5.5 Configuration et personnalisation

5.5.1 Fichier policy.cfg

Le chier de conguration /srv/pillar/ceph/proposals/policy.cfg est utilisé pourdéterminer les rôles des noeuds de grappe spéciques. Par exemple, quels noeuds font oce deCeph OSD ou Ceph Monitor. Modiez le chier policy.cfg an de reéter la congurationen grappe de votre choix. L'ordre des sections est arbitraire, mais le contenu des lignes inclusesécrase les clés correspondantes du contenu des lignes précédentes.

Astuce : exemples de fichiers policy.cfgVous pouvez trouver plusieurs exemples de chiers de stratégie complets dans lerépertoire /usr/share/doc/packages/deepsea/examples/ .

5.5.1.1 Assignation de grappes

Dans la section cluster, vous sélectionnez des minions pour votre grappe. Vous pouvezsélectionner tous les minions, ou vous pouvez mettre en liste noire ou en liste blanche certainsd'entre eux. Vous trouverez ci-dessous des exemples pour une grappe appelée ceph.

Pour inclure tous les minions, ajoutez les lignes suivantes :

cluster-ceph/cluster/*.sls

Pour placer en liste blanche un minion spécique :

cluster-ceph/cluster/abc.domain.sls

ou un groupe de minions, vous pouvez utiliser la correspondance de syntaxe générique Shell :

cluster-ceph/cluster/mon*.sls

Pour placer des minions en liste noire, dénissez-les sur unassigned  :

cluster-unassigned/cluster/client*.sls

48 Configuration et personnalisation SES 6

5.5.1.2 Assignation de rôle

Cette section vous ore plus de détails sur l'assignation de « rôles » aux noeuds de votre grappe.Un « rôle », dans ce contexte, signie le service que vous devez exécuter sur le noeud, tel queCeph Monitor, Object Gateway ou Passerelle iSCSI. Aucun rôle n'est assigné automatiquement,seuls les rôles ajoutés au chier policy.cfg sont déployés.

L'assignation suit le modèle suivant :

role-ROLE_NAME/PATH/FILES_TO_INCLUDE

Où les éléments ont la signication et les valeurs suivantes :

ROLE_NAME (NOM_RÔLE) est l'un des éléments suivants  : master, admin, mon, mgr,storage, mds, igw, rgw, ganesha, grafana ou prometheus.

PATH (CHEMIN) est un chemin de répertoire relatif permettant d'accéder aux chiers .slsou .yml. Dans le cas des chiers .sls, il s'agit généralement de cluster , tandis que leschiers .yml sont situés dans stack/default/ceph/minions .

FILES_TO_INCLUDE (FICHIERS_À_INCLURE) sont les chiers d'état Salt ou les chiersde conguration YAML. Ils sont normalement composés des noms d'hôte des minionsSalt, par exemple ses5min2.yml . La syntaxe générique de Shell peut servir pour unecorrespondance plus spécique.

Vous trouverez ci-dessous un exemple de chaque rôle :

master : le noeud dispose de porte-clés admin pour toutes les grappes Ceph. Actuellement,une grappe Ceph unique est prise en charge. Comme le rôle master est obligatoire, ajouteztoujours une ligne similaire à la suivante :

role-master/cluster/master*.sls

admin : le minion disposera d'un porte-clés admin. Vous dénissez le rôle comme suit :

role-admin/cluster/abc*.sls

mon : le minion fournit le service de surveillance de la grappe Ceph. Ce rôle requiert lesadresses des minions assignés. À partir de SUSE Enterprise Storage 5, les adresses publiquessont calculées dynamiquement et ne sont plus nécessaires dans l'interface Pillar de Salt.

role-mon/cluster/mon*.sls

L'exemple assigne le rôle de surveillance à un groupe de minions.

49 Fichier policy.cfg SES 6

mgr : daemon Ceph Manager qui collecte toutes les informations d'état de l'ensemble de lagrappe. Déployez-le sur tous les minions sur lesquels vous envisagez de déployer le rôleCeph Monitor.

role-mgr/cluster/mgr*.sls

storage : utilisez ce rôle pour spécier les noeuds de stockage.

role-storage/cluster/data*.sls

mds : le minion fournit le service de métadonnées prenant en charge CephFS.

role-mds/cluster/mds*.sls

igw : le minion va faire oce de passerelle iSCSI. Ce rôle requiert les adresses des minionsassignés. Par conséquent, vous devez également inclure les chiers du répertoire stack  :

role-igw/cluster/*.sls

rgw : le minion va agir en tant qu'Object Gateway :

role-rgw/cluster/rgw*.sls

ganesha : le minion va agir comme un serveur NFS Ganesha. Le rôle « ganesha » nécessiteun rôle « rgw » ou « mds » dans la grappe, sinon la validation échoue à la phase 3.

role-ganesha/cluster/ganesha*.sls

Pour installer correctement NFS Ganesha, une conguration supplémentaire est nécessaire.Si vous souhaitez utiliser NFS  Ganesha, lisez le Chapitre  12, Installation de NFS  Ganesha

avant d'exécuter les phases  2 et 4. Toutefois, il est possible d'installer NFS  Ganeshaultérieurement.Dans certains cas, il peut être utile de dénir des rôles personnalisés pour les noeudsNFS Ganesha. Pour plus d'informations, reportez-vous au Manuel « Guide d'administration »,

Chapitre 21 «  NFS Ganesha  : exportation de données Ceph via NFS  », Section  21.3 «  Rôles NFS

Ganesha personnalisés ».

grafana, prometheus  : ce noeud ajoute des graphiques Grafana basés sur les alertesPrometheus adressées à Ceph Dashboard. Pour une description détaillée, reportez-vous auManuel « Guide d'administration », Chapitre 22 « Ceph Dashboard ».

role-grafana/cluster/grafana*.sls

50 Fichier policy.cfg SES 6

role-prometheus/cluster/prometheus*.sls

Remarque : plusieurs rôles pour un noeud de grappeVous pouvez assigner plusieurs rôles à un même noeud. Par exemple, vous pouvezassigner les rôles « mds » aux noeuds de moniteur :

role-mds/cluster/mon[1,2]*.sls

5.5.1.3 Configuration commune

La section de conguration commune inclut des chiers de conguration générés au cours dela découverte (phase  1). Ces chiers de conguration stockent des paramètres comme fsidou public_network . Pour inclure la conguration commune Ceph requise, ajoutez les lignessuivantes :

config/stack/default/global.ymlconfig/stack/default/ceph/cluster.yml

5.5.1.4 Filtrage d'éléments

Parfois, il n'est pas pratique d'inclure tous les chiers d'un répertoire donné avec la syntaxegénérique *.sls. L'analyseur de chiers policy.cfg comprend les ltres suivants :

Avertissement : techniques avancéesCette section décrit les techniques de ltrage pour les utilisateurs avancés. Lorsqu'il n'estpas utilisé correctement, le ltrage peut entraîner des problèmes, par exemple dans le casoù votre numérotation des noeuds change.

slice=[start:end]

Utilisez le ltre slice pour inclure uniquement les éléments start à end-1. Notez que leséléments du répertoire donné sont triés dans l'ordre alphanumérique. La ligne suivanteinclut les troisième au cinquième chiers du sous-répertoire role-mon/cluster/  :

role-mon/cluster/*.sls slice[3:6]

51 Fichier policy.cfg SES 6

re=regexp

Utilisez le ltre d'expression régulière pour inclure uniquement les éléments correspondantaux expressions données. Par exemple :

role-mon/cluster/mon*.sls re=.*1[135]\.subdomainX\.sls$

5.5.1.5 Exemple de fichier policy.cfg

Voici un exemple de chier policy.cfg de base :

## Cluster Assignmentcluster-ceph/cluster/*.sls 1

## Roles# ADMINrole-master/cluster/examplesesadmin.sls 2

role-admin/cluster/sesclient*.sls 3

# MONrole-mon/cluster/ses-example-[123].sls 4

# MGRrole-mgr/cluster/ses-example-[123].sls 5

# STORAGErole-storage/cluster/ses-example-[5,6,7,8].sls 6

# MDSrole-mds/cluster/ses-example-4.sls 7

# IGWrole-igw/cluster/ses-example-4.sls 8

# RGWrole-rgw/cluster/ses-example-4.sls 9

# COMMONconfig/stack/default/global.yml 10

config/stack/default/ceph/cluster.yml 11

1 Indique que tous les minions sont inclus dans la grappe Ceph. Si vous ne souhaitez pasinclure certains minions dans la grappe Ceph, utilisez :

cluster-unassigned/cluster/*.sls

52 Fichier policy.cfg SES 6

cluster-ceph/cluster/ses-example-*.sls

La première ligne marque tous les minions comme non assignés. La deuxième ligneremplace les minions correspondant à « ses-example-*.sls » et les assigne à la grappe Ceph.

2 Le minion appelé « examplesesadmin » a le rôle maître (master). Cela signie, par ailleurs,qu'il obtiendra les clés admin de la grappe.

3 Tous les minions correspondant à « sesclient* » obtiennent également les clés admin.

4 Tous les minions correspondant à « ses-example-[123] » (vraisemblablement trois minions :ses-example-1, ses-example-2 et ses-example-3) sont congurés en tant que noeuds MON.

5 Tous les minions correspondant à «  ses-example-[123]  » (tous les noeuds MON dansl'exemple) seront congurés en tant que noeuds MGR.

6 Tous les minions correspondant à «  ses-example-[5,6,7,8]  » seront congurés commenoeuds de stockage.

7 Le minion « ses-example-4 » aura le rôle MDS.

8 Le minion « ses-example-4 » aura le rôle IGW.

9 Le minion « ses-example-4 » aura le rôle RGW.

10 Signie que nous acceptons les valeurs par défaut pour des paramètres de congurationcommune tels que fsid et public_network .

11 Signie que nous acceptons les valeurs par défaut pour des paramètres de congurationcommune tels que fsid et public_network .

5.5.2 Groupes d'unités

Les groupes d'unités (« DriveGroups ») spécient les dispositions des OSD dans la grappe Ceph. Ilssont dénis dans un seul chier /srv/salt/ceph/configuration/files/drive_groups.yml .

Un administrateur doit spécier manuellement un groupe d'OSD interdépendants (OSD hybridesdéployés sur des disques SSD et sur des disques rotatifs) ou qui partagent les mêmes optionsde déploiement (par exemple, même magasin d'objets, même option de chirement, OSDautonomes). Pour éviter de lister explicitement les périphériques, les groupes d'unités utilisentune liste d'éléments de ltre qui correspondent à quelques champs sélectionnés de rapportsd'inventaire de ceph-volume . Dans le cas le plus simple, il pourrait s'agir du drapeau«  rotational  » (rotatif - tous les disques SSD doivent être des périphériques de base dedonnées « db_devices  »  ; tous les disques rotatifs doivent être des périphériques de données

53 Groupes d'unités SES 6

« data_devices ») ou quelque chose de plus impliqué comme des chaînes « model » ou des tailles.DeepSea fournit le code qui traduit ces groupes d'unités en listes de périphériques réelles pourinspection par l'utilisateur.

Voici une procédure simple qui illustre le workow de base lors de la conguration des groupesd'unités :

1. Inspectez les propriétés de vos disques telles qu'elles sont renvoyées par la commandeceph-volume . Seules ces propriétés sont acceptées par les groupes d'unités :

root@master # salt-run disks.details

2. Ouvrez le chier YAML /srv/salt/ceph/configuration/files/drive_groups.yml etadaptez-le à vos besoins. Reportez-vous à la Section 5.5.2.1, « Spécification ». Pensez à utiliserdes espaces au lieu des tabulations. Pour des exemples plus avancés, reportez-vous à laSection 5.5.2.4, « Exemples ». L'exemple suivant inclut toutes les unités disponibles pour Cephen tant qu'OSD :

default_drive_group_name: target: '*' data_devices: all: true

3. Vériez les nouvelles dispositions :

root@master # salt-run disks.list

Cet exécuteur vous renvoie une structure de disques correspondants en fonction de vosgroupes d'unités. Si vous n'êtes pas satisfait du résultat, répétez l'étape précédente.

Astuce : rapport détailléEn plus de l'exécuteur disks.list , un autre exécuteur disks.report fournit unrapport détaillé de ce qui se passera lors du prochain appel de la phase 3 de DeepSea.

root@master # salt-run disks.report

4. Déployez les OSD. Lors du prochain appel de la phase 3 de DeepSea, les disques OSDseront déployés en fonction de vos spécications de groupe d'unités.

54 Groupes d'unités SES 6

5.5.2.1 Spécification

/srv/salt/ceph/configuration/files/drive_groups.yml accepte les options suivantes :

drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION db_devices: drive_spec: DEVICE_SPECIFICATION wal_devices: drive_spec: DEVICE_SPECIFICATION block_wal_size: '5G' # (optional, unit suffixes permitted) block_db_size: '5G' # (optional, unit suffixes permitted) osds_per_device: 1 # number of osd daemons per device format: # 'bluestore' or 'filestore' (defaults to 'bluestore') encryption: # 'True' or 'False' (defaults to 'False')

Pour les congurations FileStore, drive_groups.yml peut se présenter comme suit :

drive_group_default_name: target: * data_devices: drive_spec: DEVICE_SPECIFICATION journal_devices: drive_spec: DEVICE_SPECIFICATION format: filestore encryption: True

5.5.2.2 Périphériques de disques correspondants

Vous pouvez décrire les spécications à l'aide des ltres suivants :

Par modèle de disque :

model: DISK_MODEL_STRING

Par fournisseur de disque :

vendor: DISK_VENDOR_STRING

55 Groupes d'unités SES 6

Astuce : chaîne de fournisseur en minusculesInscrivez toujours la valeur DISK_VENDOR_STRING

(CHAÎNE_FOURNISSEUR_DISQUE) en minuscules.

Selon qu'un disque est rotatif ou non. Les disques SSD et NVME ne sont pas rotatifs.

rotational: 0

Déployez un noeud à l'aide de tous les disques disponibles pour les OSD :

data_devices: all: true

En outre, vous pouvez limiter le nombre de disques correspondants :

limit: 10

5.5.2.3 Filtrage des périphériques par taille

Vous pouvez ltrer les périphériques de disque par leur taille, soit en fonction d'une taille précise,soit selon une plage de tailles. Le paramètre size: (taille :) accepte les arguments sous la formesuivante :

« 10G » : inclut les disques d'une taille exacte.

« 10G:40G » : inclut les disques dont la taille est dans la plage.

« :10G » : inclut les disques dont la taille est inférieure ou égale à 10 Go.

« 40G: » : inclut les disques dont la taille est égale ou supérieure à 40 Go.

EXEMPLE 5.1T : CORRESPONDANCE PAR TAILLE DE DISQUE

drive_group_default: target: '*' data_devices: size: '40TB:' db_devices: size: ':2TB'

56 Groupes d'unités SES 6

Remarque : guillemets requisLorsque vous utilisez le délimiteur « : », vous devez entourer la taille par des guillemetssimples, faute de quoi le signe deux-points est interprété comme un nouveau hachage deconguration.

Astuce : abréviations des unitésAu lieu de (G)igaoctets, vous pouvez spécier les tailles en (M)égaoctets ou en(T)éraoctets.

5.5.2.4 Exemples

Cette section comprend des exemples de diérentes congurations OSD.

EXEMPLE 5.2T : CONFIGURATION SIMPLE

Cet exemple décrit deux noeuds avec la même conguration :

20 HDD

Fournisseur : Intel

Modèle : SSD-123-foo

Taille : 4 To

2 SSD

Fournisseur : Micron

Modèle : MC-55-44-ZX

Taille : 512 Go

Le chier drive_groups.yml correspondant se présentera comme suit :

drive_group_default: target: '*' data_devices: model: SSD-123-foo db_devices: model: MC-55-44-XZ

57 Groupes d'unités SES 6

Une telle conguration est simple et valide. Le problème est qu'un administrateur peutajouter des disques de fournisseurs diérents par la suite et ceux-ci ne seront pas inclus.Vous pouvez améliorer cela en limitant les ltres aux propriétés de base des unités :

drive_group_default: target: '*' data_devices: rotational: 1 db_devices: rotational: 0

Dans l'exemple précédent, nous imposons de déclarer tous les périphériques rotatifscomme « périphériques de données » et tous les périphériques non rotatifs seront utiliséscomme « périphériques partagés » (wal, db).

Si vous savez que les unités de plus de 2 To seront toujours les périphériques de donnéesplus lents, vous pouvez ltrer par taille :

drive_group_default: target: '*' data_devices: size: '2TB:' db_devices: size: ':2TB'

EXEMPLE 5.3T : CONFIGURATION AVANCÉE

Cet exemple décrit deux congurations distinctes : 20 HDD devraient partager 2 SSD,tandis que 10 SSD devraient partager 2 NVMe.

20 HDD

Fournisseur : Intel

Modèle : SSD-123-foo

Taille : 4 To

12 SSD

Fournisseur : Micron

Modèle : MC-55-44-ZX

Taille : 512 Go

2 NVMe

58 Groupes d'unités SES 6

Fournisseur : Samsung

Modèle : NVME-QQQQQ-987

Taille : 256 Go

Une telle conguration peut être dénie avec deux dispositions comme suit :

drive_group: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ

drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: vendor: samsung size: 256GB

EXEMPLE 5.4T : CONFIGURATION AVANCÉE AVEC DES NOEUDS NON UNIFORMES

Les exemples précédents supposaient que tous les noeuds avaient les mêmes unités.Cependant, ce n'est pas toujours le cas :

Noeuds 1 à 5 :

20 HDD

Fournisseur : Intel

Modèle : SSD-123-foo

Taille : 4 To

2 SSD

Fournisseur : Micron

Modèle : MC-55-44-ZX

Taille : 512 Go

59 Groupes d'unités SES 6

Noeuds 6 à 10 :

5 NVMe

Fournisseur : Intel

Modèle : SSD-123-foo

Taille : 4 To

20 SSD

Fournisseur : Micron

Modèle : MC-55-44-ZX

Taille : 512 Go

Vous pouvez utiliser la clé « target » dans la disposition pour cibler des noeuds spéciques.La notation de cible Salt aide à garder les choses simples :

drive_group_node_one_to_five: target: 'node[1-5]' data_devices: rotational: 1 db_devices: rotational: 0

suivi de

drive_group_the_rest: target: 'node[6-10]' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo

EXEMPLE 5.5T : CONFIGURATION EXPERTE

Tous les cas précédents supposaient que les WAL et les DB utilisaient le mêmepériphérique. Il est cependant possible également de déployer le WAL sur un périphériquedédié :

20 HDD

60 Groupes d'unités SES 6

Fournisseur : Intel

Modèle : SSD-123-foo

Taille : 4 To

2 SSD

Fournisseur : Micron

Modèle : MC-55-44-ZX

Taille : 512 Go

2 NVMe

Fournisseur : Samsung

Modèle : NVME-QQQQQ-987

Taille : 256 Go

drive_group_default: target: '*' data_devices: model: MC-55-44-XZ db_devices: model: SSD-123-foo wal_devices: model: NVME-QQQQ-987

EXEMPLE 5.6T : CONFIGURATION COMPLEXE (ET PEU PROBABLE)

Dans la conguration suivante, nous essayons de dénir :

20 HDD soutenus par 1 NVMe

2 HDD soutenus par 1 SSD (db) et 1 NVMe (wal)

8 SSD soutenus par 1 NVMe

2 SSD autonomes (chirés)

1 HDD est de rechange et ne doit pas être déployé

Le résumé des unités utilisées est le suivant :

23 HDD

61 Groupes d'unités SES 6

Fournisseur : Intel

Modèle : SSD-123-foo

Taille : 4 To

10 SSD

Fournisseur : Micron

Modèle : MC-55-44-ZX

Taille : 512 Go

1 NVMe

Fournisseur : Samsung

Modèle : NVME-QQQQQ-987

Taille : 256 Go

La dénition des groupes d'unités sera la suivante :

drive_group_hdd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: NVME-QQQQ-987

drive_group_hdd_ssd_nvme: target: '*' data_devices: rotational: 0 db_devices: model: MC-55-44-XZ wal_devices: model: NVME-QQQQ-987

drive_group_ssd_nvme: target: '*' data_devices: model: SSD-123-foo db_devices: model: NVME-QQQQ-987

62 Groupes d'unités SES 6

drive_group_ssd_standalone_encrypted: target: '*' data_devices: model: SSD-123-foo encryption: True

Il reste un HDD dans la mesure où le chier est en cours d'analyse du haut vers le bas.

5.5.3 Ajustement de ceph.conf avec des paramètrespersonnalisés

Si vous avez besoin de placer des paramètres personnalisés dans le chier de congurationceph.conf , reportez-vous au Manuel «  Guide d'administration  », Chapitre 2 «  Administration de

grappe Salt », Section 2.13 « Ajustement de ceph.conf avec des paramètres personnalisés » pour plusd'informations.

63 Ajustement de ceph.conf avec des paramètres personnalisés SES 6

6 Mise à jour à partir de versions précédentes

Ce chapitre présente les étapes requises pour mettre à niveau SUSE Enterprise Storage 5.5 versla version 6. Notez qu'en fait, la version 5.5 est une version 5 avec tous les derniers correctifsappliqués.

Remarque : la mise à niveau à partir de versions plus anciennesn'est pas prise en chargeLa mise à niveau des versions SUSE Enterprise Storage antérieures à la version 5.5 n'estpas prise en charge. Vous devez d'abord passer à la dernière version SUSE EnterpriseStorage 5.5, puis suivre les étapes de ce chapitre.

6.1 Points à prendre en compte avant la mise àniveau

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

Votre matériel doit tenir compte de certaines considérations spéciales.

Les paquetages logiciels utilisés ont été considérablement modié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, fautede temps, n'ont pas pu être intégrées au manuel. Elles contiennent également des notesconcernant les problèmes connus.

64 Points à prendre en compte avant la mise à niveau SES 6

Après avoir installé le paquetage release-notes-ses , les notes de version sontdisponibles en local dans le répertoire /usr/share/doc/release-notes ou en ligne àl'adresse https://www.suse.com/releasenotes/ .

Si vous avez au préalable eectué une mise à niveau à partir de la version 4, vériez quela mise à niveau vers la version 5 a bien abouti :

Vériez l'existence du chier suivant :

/srv/salt/ceph/configuration/files/ceph.conf.import

Il est créé par le processus d'importation (« engulf ») au cours de la mise à niveau deSES 4 vers la version 5. En outre, l'option configuration_init: default-importest dénie dans le chier suivant :

/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

Si l'option configuration_init reste dénie sur default-import , la grappeutilise ceph.conf.import comme chier de conguration, au lieu du chierceph.conf par défaut de DeepSea, qui est compilé à partir des chiers dans lerépertoire suivant :

/srv/salt/ceph/configuration/files/ceph.conf.d/

Par conséquent, vous devez rechercher les congurations personnalisées potentiellesdans ceph.conf.import et, éventuellement, les déplacer dans l'un des chiers durépertoire suivant :

/srv/salt/ceph/configuration/files/ceph.conf.d/

Ensuite, supprimez la ligne configuration_init: default-import du chiersuivant :

/srv/pillar/ceph/proposals/config/stack/default/ceph/cluster.yml

65 Points à prendre en compte avant la mise à niveau SES 6

Avertissement : configuration par défaut de DeepSeaSi vous ne fusionnez pas la conguration de ceph.conf.import et supprimezl'option configuration_init: default-import , tous les paramètres deconguration par défaut que nous transférons en tant que partie de DeepSea(stockés dans /srv/salt/ceph/configuration/files/ceph.conf.j2 ) neseront pas appliqués à la grappe.

Vériez si la grappe utilise le nouveau type de compartiment « straw2 » :

cephadm@adm > ceph osd crush dump | grep straw

Vériez que le prol « jewel » Ceph est utilisé :

cephadm@adm > ceph osd crush dump | grep profile

En cas d'utilisation d'anciens clients de kernel RBD (antérieurs à SUSE Linux EnterpriseServer 12 SP3), reportez-vous au Manuel « Guide d'administration », Chapitre 12 « Périphérique

de bloc RADOS », Section 12.9 « Assignation RBD à l'aide d'anciens clients de kernel ». Nous vousrecommandons de mettre à niveau les anciens clients de kernel RBD si possible.

Si openATTIC est situé sur le noeud Admin, il sera indisponible après avoir mis à niveau lenoeud. Le nouveau tableau de bord Ceph Dashboard ne sera disponible que lorsque vousl'aurez déployé à l'aide de DeepSea.

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

Un noeud unique ne peut pas être mis à niveau lors de l'exécution de la version précédentede SUSE Linux Enterprise Server, mais doit être redémarré dans le programme d'installationde la nouvelle version. Par conséquent, les services que le noeud fournit ne seront pasdisponibles pendant un certain temps. Les services de grappe de base restent disponibles :par exemple, si un moniteur (MON) est arrêté pendant la mise à niveau, au moins deuxautres moniteurs sont actifs. Malheureusement, les services à instance unique, tels qu'unepasserelle iSCSI unique, ne sont pas disponibles.

66 Points à prendre en compte avant la mise à niveau SES 6

Certains types de daemons dépendent d'autres. Par exemple, les instancesCeph Object Gateway dépendent des daemons Ceph MON et Ceph OSD. Il est recommandéde mettre à niveau les diérentes instances dans l'ordre suivant :

1. Noeud Admin

2. Instances Ceph Monitor/Ceph Manager

3. Serveurs de métadonnées (MDS)

4. Instances Ceph OSD

5. Instances Object Gateway

6. Passerelles iSCSI

7. NFS Ganesha

8. Passerelles Samba

Si vous avez utilisé AppArmor en mode « complain » ou « enforce », vous devez dénir unevariable d'interface Pillar de Salt avant d'eectuer la mise à niveau. Étant donné que SUSELinux Enterprise Server 15 SP1 est fourni avec AppArmor par défaut, la gestion AppArmora été intégrée à la phase 0 de DeepSea. Le comportement par défaut dans SUSE EnterpriseStorage 6 consiste à supprimer AppArmor et les prols associés. Si vous souhaitez conserverle comportement conguré dans SUSE Enterprise Storage 5.5, vériez que l'une des lignessuivantes est présente dans le chier /srv/pillar/ceph/stack/global.yml avant decommencer la mise à niveau :

apparmor_init: default-enforce

ou

apparmor_init: default-complain

À partir de SUSE Enterprise Storage 6, les noms MDS commençant par un chire ne sontplus autorisés de sorte que les daemons MDS refuseront de démarrer. Vous pouvez vériersi vos daemons portent ce type de noms soit en exécutant la commande ceph fs status ,soit en redémarrant un MDS et en consultant ses journaux à la recherche du messagesuivant :

deprecation warning: MDS id 'mds.1mon1' is invalid and will be forbidden in

67 Points à prendre en compte avant la mise à niveau SES 6

a future version. MDS names may not start with a numeric digit.

Si vous repérez le message susmentionné, les noms MDS doivent être migrés avant de tenterune mise à niveau vers SUSE Enterprise Storage 6. DeepSea fournit une orchestration pourautomatiser une telle migration. Le système ajoutera « mds. » au début des noms MDScommençant par un chire :

root@master # salt-run state.orch ceph.mds.migrate-numerical-names

Astuce : configuration personnalisée liée aux noms MDSSi vous avez des paramètres de conguration qui sont liés aux noms MDS et quevos daemons MDS portent des noms commençant par un chire, vériez que vosparamètres de conguration s'appliquent également aux nouveaux noms (avec lepréxe « mds. » ). Voici un exemple de section dans le chier /etc/ceph.conf  :

[mds.123-my-mds] # config setting specific to MDS name with a name starting with a digitmds cache memory limit = 1073741824mds standby for name = 456-another-mds

L'orchestrateur ceph.mds.migrate-numerical-names change le nom de daemonMDS « 123-my-mds » en « mds.123-my-mds ». Vous devez ajuster la congurationpour tenir compte du nouveau nom :

[mds.mds,123-my-mds] # config setting specific to MDS name with the new namemds cache memory limit = 1073741824mds standby for name = mds.456-another-mds

Cela ajoutera les daemons MDS avec les nouveaux noms avant de supprimer les anciensdaemons MDS. Le nombre de daemons MDS va doubler pendant une courte période. Lesclients pourront accéder à CephFS moyennant une brève pause avant le basculement.Planiez donc la migration à des moments où vous vous attendez à peu ou pas de chargede CephFS.

68 Points à prendre en compte avant la mise à niveau SES 6

6.2 Sauvegarde des données de grappeBien que la création de sauvegardes de la conguration et des données d'une grappe ne soitpas obligatoire, nous recommandons vivement de sauvegarder les données de grappe et leschiers de conguration importants. Pour plus d'informations, reportez-vous au Manuel « Guide

d'administration », Chapitre 3 « Sauvegarde de la configuration et des données de grappe ».

6.3 Migration de ntpd vers chronydPour synchroniser l'heure de l'hôte local, SUSE Linux Enterprise Server 15 SP1 n'utilise plusntpd , mais bien chronyd . Vous devez donc migrer le daemon de synchronisation horaire surchaque noeud de la grappe. Vous pouvez eectuer la migration vers chronyd avant de mettreà niveau la grappe, ou mettre à niveau la grappe et réaliser la migration vers chronyd ensuite.

PROCÉDURE 6.1T : MIGRATION VERS chronyd AVANT LA MISE À NIVEAU DE LA GRAPPE

1. Installez le paquetage chrony :

root@minion > zypper install chrony

2. Modiez le chier de conguration de chronyd /etc/chrony.conf et ajoutez les sourcesNTP de la conguration actuelle de ntpd dans /etc/ntp.conf .

Astuce : plus de détails sur la configuration de chronydReportez-vous à la page https://documentation.suse.com/sles/15-SP1/html/SLES-all/

cha-ntp.html pour obtenir plus de détails sur la façon d'inclure des sourceshoraires dans la conguration de chronyd .

3. Désactivez et arrêtez le service ntpd  :

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

4. Démarrez et activez le service chronyd  :

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

5. Vériez le statut de chrony :

root@minion > chronyc tracking

69 Sauvegarde des données de grappe SES 6

PROCÉDURE 6.2T : MIGRATION VERS chronyd APRÈS LA MISE À NIVEAU DE LA GRAPPE

1. Lors de la mise à niveau de la grappe, ajoutez les dépôts logiciels suivants :

SLE-Module-Legacy15-SP1-Pool

SLE-Module-Legacy15-SP1-Updates

2. Mettez à niveau la grappe vers la version 6.

3. Modiez le chier de conguration de chronyd /etc/chrony.conf et ajoutez les sourcesNTP de la conguration actuelle de ntpd dans /etc/ntp.conf .

Astuce : plus de détails sur la configuration de chronydReportez-vous à la page https://documentation.suse.com/sles/15-SP1/html/SLES-all/

cha-ntp.html pour obtenir plus de détails sur la façon d'inclure des sourceshoraires dans la conguration de chronyd .

4. Désactivez et arrêtez le service ntpd  :

root@minion > systemctl disable ntpd.service && systemctl stop ntpd.service

5. Démarrez et activez le service chronyd  :

root@minion > systemctl start chronyd.service && systemctl enable chronyd.service

6. Eectuez la migration de ntpd vers chronyd .

7. Vériez le statut de chrony :

root@minion > chronyc tracking

8. Supprimez les dépôts logiciels hérités que vous avez ajoutés pour garder ntpd dans lesystème pendant le processus de mise à niveau.

6.4 Application des correctifs à la grappe avant lamise à niveauAppliquez les derniers correctifs à tous les noeuds de la grappe avant la mise à niveau.

70 Application des correctifs à la grappe avant la mise à niveau SES 6

6.4.1 Dépôts logiciels requis

Vériez que les dépôts requis sont congurés sur chaque noeud de la grappe. Pour répertoriertous les dépôts disponibles, exécutez la commande suivante :

root@minion > zypper lr

SUSE Enterprise Storage 5.5 nécessite :

SLES12-SP3-Installer-Updates

SLES12-SP3-Pool

SLES12-SP3-Updates

SUSE-Enterprise-Storage-5-Pool

SUSE-Enterprise-Storage-5-Updates

La passerelle NFS/SMB sur SLE-HA sous SUSE Linux Enterprise Server 12 SP3 nécessite :

SLE-HA12-SP3-Pool

SLE-HA12-SP3-Updates

6.4.2 Systèmes de préparation de dépôt

Si vous utilisez l'un des systèmes de préparation de dépôt (SMT, RMT ou SUSE Manager), créezun niveau de correctif gé pour la version actuelle et la nouvelle version de SUSE EnterpriseStorage.

Pour plus d'informations, reportez-vous aux ressources suivantes :

https://www.suse.com/documentation/sles-12/book_smt/data/book_smt.html

https://www.suse.com/documentation/sles-15/book_rmt/data/book_rmt.html

https://www.suse.com/documentation/suse-manager-3/index.html

71 Dépôts logiciels requis SES 6

6.4.3 Application des derniers correctifs à toute la grappe

1. Appliquez les derniers correctifs de SUSE Enterprise Storage 5.5 et SUSE Linux EnterpriseServer 12 SP3 à chaque noeud de la grappe Ceph. Vériez que les bons dépôts logicielssont connectés à chaque noeud de la grappe (voir Section 6.4.1, « Dépôts logiciels requis »)et exécutez la phase 0 de DeepSea :

root@master # salt-run state.orch ceph.stage.0

2. Une fois la phase 0 terminée, vériez que le statut de chaque noeud de la grappe inclut« HEALTH_OK ». Si ce n'est pas le cas, résolvez le problème avant d'éventuels redémarragesau cours des prochaines étapes.

3. Exécutez zypper ps pour rechercher les processus susceptibles de s'exécuter avec desbibliothèques ou des chiers binaires obsolètes, et redémarrez s'il y en a.

4. Vériez que le kernel en cours d'exécution est le plus récent disponible et redémarrez sice n'est pas le cas. Vériez les sorties des commandes suivantes :

cephadm@adm > uname -acephadm@adm > rpm -qa kernel-default

5. Vériez que le paquetage ceph présente la version 12.2.12 ou une version ultérieure.Vériez que le paquetage deepsea présente la version 0.8.9 ou une version ultérieure.

6. Si vous utilisiez des paramètres bluestore_cache , ils ne sont plus de vigueur depuisla version  12.2.10 de ceph . Le nouveau paramètre bluestore_cache_autotune ,qui est déni sur «  true  » par défaut, désactive la dénition manuelle dela taille du cache. Pour activer l'ancien comportement, vous devez congurerbluestore_cache_autotune=false . Reportez-vous au Manuel « Guide d'administration »,

Chapitre 16 « Configuration de la grappe Ceph », Section 16.2.1 « Dimensionnement automatique

des caches » pour obtenir des informations détaillées.

6.5 Vérification de l'environnement actuelSi le système présente des problèmes évidents, corrigez-les avant de commencer la mise àniveau. La mise à niveau ne résout jamais les problèmes système existants.

Vériez les performances de la grappe. Vous pouvez utiliser des commandes telles querados bench , ceph tell osd.* bench ou iperf3 .

72 Application des derniers correctifs à toute la grappe SES 6

Vériez l'accès aux passerelles (telles que la passerelle iSCSI ou Object Gateway) et à RBD.

Documentez les parties spéciques de la conguration système, telles que les détails de laconguration réseau, du partitionnement ou de l'installation.

Utilisez supportconfig pour collecter les informations système importantes etles enregistrer en dehors des noeuds de grappe. Pour plus d'informations,reportez-vous à la page https://www.suse.com/documentation/sles-12/book_sle_admin/

data/sec_admsupport_supportconfig.html .

Assurez-vous que l'espace disque libre sur chaque noeud de la grappe est susant. Pource faire, utilisez la commande df -h . Au besoin, libérez de l'espace disque en supprimantles chiers/répertoires inutiles ou les instantanés obsolètes du système d'exploitation. Sil'espace disque libre n'est pas susant, ne poursuivez pas la mise à niveau tant que vousn'en avez pas libéré susamment.

6.6 Vérification de l'état de la grappe

Vériez la commande cluster health avant de commencer la procédure de mise àniveau. Ne démarrez la mise à niveau qu'une fois que chaque noeud de la grappe renvoie« HEALTH_OK ».

Vérier que tous les services sont en cours d'exécution :

Salt Master et les daemons Salt Master

Les daemons Ceph Monitor et Ceph Manager

Les daemons de serveur de métadonnées (MDS)

Les daemons Ceph OSD

Les daemons Objet Gateway

Les daemons de passerelle iSCSI

Les commandes suivantes fournissent des détails sur l'état de la grappe et la congurationspécique :

ceph -s

73 Vérification de l'état de la grappe SES 6

Renvoie un bref résumé de l'état de santé de la grappe Ceph, des services en coursd'exécution, de l'utilisation des données et des statistiques E/S. Vériez que l'état signaléest « HEALTH_OK » avant de commencer la mise à niveau.

ceph health detail

Renvoie les détails si l'état de santé de la grappe Ceph n'est pas correct.

ceph versions

Renvoie les versions des daemons Ceph en cours d'exécution.

ceph df

Renvoie la quantité d'espace disque total et d'espace disque libre sur la grappe. Necommencez pas la mise à niveau si l'espace disque libre de la grappe est inférieur à 25 %de l'espace disque total.

salt '*' cephprocesses.check results=true

Renvoie les processus Ceph en cours d'exécution et leur PID triés par minions Salt.

ceph osd dump | grep ^flags

Vériez la présence des drapeaux « recovery_deletes » et « purged_snapdirs ». Si ce n'est pasle cas, vous pouvez forcer un nettoyage sur tous les groupes de placement en exécutant lacommande suivante. Soyez conscient que ce nettoyage forcé peut avoir un impact négatifsur les performances de vos clients Ceph.

cephadm@adm > ceph pg dump pgs_brief | cut -d " " -f 1 | xargs -n1 ceph pg scrub

6.7 Mise à niveau hors ligne des grappes CTDBCTDB fournit une base de données mise en grappe utilisée par les passerelles Samba. Le protocoleCTDB est très simple et ne prend pas en charge les grappes de noeuds qui communiquent avecdiérentes versions de protocole. Par conséquent, les noeuds CTDB doivent être mis hors ligneavant d'eectuer une mise à niveau.

74 Mise à niveau hors ligne des grappes CTDB SES 6

6.8 Mise à niveau par noeud - Procédure de basePour garantir la disponibilité des services de grappe de base pendant la mise à niveau, vousdevez mettre à niveau les noeuds de la grappe de manière séquentielle, un par un. Il existe deuxfaçons d'eectuer la mise à niveau d'un noeud : à l'aide du DVD du programme d'installation ouen utilisant le système de migration de distribution.

Après la mise à niveau de chaque noeud, nous vous recommandons d'exécuter rpmconfigcheckpour rechercher les éventuels chiers de conguration mis à jour qui ont été modiéslocalement. Si la commande renvoie une liste de noms de chiers avec un suxe .rpmnew ,.rpmorig ou .rpmsave , comparez ces chiers avec les chiers de conguration actuelspour vérier qu'aucun changement local n'a été perdu. Si nécessaire, mettez à jour leschiers concernés. Pour plus d'informations sur l'utilisation des chiers .rpmnew , .rpmoriget .rpmsave , reportez-vous à la page https://documentation.suse.com/sles/15-SP1/single-html/

SLES-admin/#sec-rpm-packages-manage .

Astuce : paquetages orphelinsUne fois qu'un noeud a été mis à niveau, un certain nombre de paquetages présentent unétat « orphaned » (orphelin), sans dépôt parent. Cela est dû au fait que les paquetagesassociés à python3 ne rendent pas les paquetages python2 obsolètes.

Pour plus d'informations sur la liste des paquetages orphelins, reportez-vous à la page https://www.suse.com/documentation/sles-15/book_sle_admin/data/

sec_zypper.html#sec_zypper_softup_orphaned .

6.8.1 Mise à niveau manuelle d'un noeud à l'aide du DVD duprogramme d'installation

1. Redémarrez le noeud à partir du DVD/de l'image du programme d'installation de SUSELinux Enterprise Server 15 SP1.

2. Sélectionnez Upgrade (Mise à niveau) dans le menu de démarrage.

3. Sur l'écran Select the Migration Target (Sélectionner la cible de la migration), vériez que« SUSE Linux Enterprise Server 15 SP1 » est sélectionné et cochez la case Manually Adjustthe Repositories for Migration (Ajuster manuellement les dépôts pour la migration).

75 Mise à niveau par noeud - Procédure de base SES 6

FIGURE 6.1T : SÉLECTION DE LA CIBLE DE LA MIGRATION

4. Sélectionnez les modules suivants pour installation :

SUSE Enterprise Storage 6 x86_64

Basesystem Module 15 SP1 x86_64

Desktop Applications Module 15 SP1 x86_64

Legacy Module 15 SP1 x86_64

Server Applications Module 15 SP1 x86_64

5. Sur l'écran Previously Used Repositories (Dépôts utilisés précédemment), vériez que lesbons dépôts sont sélectionnés. Si le système n'est pas enregistré avec SCC/SMT, vous devezajouter les dépôts manuellement.SUSE Enterprise Storage 6 nécessite :

SLE-Module-Basesystem15-SP1-Pool

SLE-Module-Basesystem15-SP1-Updates

SLE-Module-Server-Applications15-SP1-Pool

SLE-Module-Server-Applications15-SP1-Updates

76 Mise à niveau manuelle d'un noeud à l'aide du DVD du programme d'installation SES 6

SLE-Module-Desktop-Applications15-SP1-Pool

SLE-Module-Desktop-Applications15-SP1-Updates

SLE-Product-SLES15-SP1-Pool

SLE-Product-SLES15-SP1-Updates

SLE15-SP1-Installer-Updates

SUSE-Enterprise-Storage-6-Pool

SUSE-Enterprise-Storage-6-Updates

Si vous avez l'intention d'eectuer la migration de ntpd vers chronyd après la migrationde SES (voir Section 6.3, « Migration de ntpd vers chronyd »), incluez les dépôts suivants :

SLE-Module-Legacy15-SP1-Pool

SLE-Module-Legacy15-SP1-Updates

La passerelle NFS/SMB sur SLE-HA sous SUSE Linux Enterprise Server 15 SP1 nécessite :

SLE-Product-HA15-SP1-Pool

SLE-Product-HA15-SP1-Updates

6. Passez en revue les paramètres d'installation et démarrez la procédure d'installation encliquant sur Update (Mise à jour).

6.8.2 Mise à niveau de noeud à l'aide du système de migration dedistribution SUSE

Le système de migration de distribution (Distribution Migration System, DMS) fournit un cheminde mise à niveau pour un système SUSE Linux Enterprise installé devant passer d'une versionmajeure à une autre. La procédure suivante utilise DMS pour mettre à niveau SUSE EnterpriseStorage 5.5 vers la version 6 et eectuer également la migration sous-jacente de SUSE LinuxEnterprise Server 12 SP3 vers SUSE Linux Enterprise Server 15 SP1.

Reportez-vous à la page https://documentation.suse.com/suse-distribution-migration-system/1.0/

single-html/distribution-migration-system/ pour obtenir des informations générales et détailléessur DMS.

77 Mise à niveau de noeud à l'aide du système de migration de distribution SUSE SES 6

1. Installez les paquetages RPM de migration. Ils règlent le chargeur de démarrage GRUBpour déclencher automatiquement la mise à niveau lors du prochain redémarrage. Installezles paquetages SLES15-SES-Migration et suse-migration-sle15-activation :

root@minion > zypper install SLES15-SES-Migration suse-migration-sle15-activation

2. a. Si le noeud mis à niveau est enregistré avec un système de préparation de dépôttel que SCC, SMT, RMT ou SUSE Manager, créez le chier /etc/sle-migration-service.yml avec le contenu suivant :

use_zypper_migration: truepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules

b. Si le noeud mis à niveau n'est pas enregistré avec un système de préparation de dépôttel que SCC, SMT, RMT ou SUSE Manager, eectuez les modications suivantes :

i. Créez le chier /etc/sle-migration-service.yml avec le contenu suivant :

use_zypper_migration: falsepreserve: rules: - /etc/udev/rules.d/70-persistent-net.rules

ii. Désactivez ou supprimez les dépôts SLE 12 SP3 et SES 5, puis ajoutez les dépôtsSLE 15 SP1 et SES 6. Pour obtenir la liste des dépôts associés, reportez-vous àla Section 6.4.1, « Dépôts logiciels requis ».

3. Redémarrez pour lancer la mise à niveau. Pendant l'exécution de la mise à niveau,vous pouvez vous connecter au noeud mis à niveau via ssh en tant qu'utilisateurde la migration à l'aide de la clé SSH existante du système hôte comme décrità la page https://documentation.suse.com/suse-distribution-migration-system/1.0/single-

html/distribution-migration-system/ . Pour SUSE Enterprise Storage, si vous disposez d'unaccès physique ou d'un accès console direct à la machine, vous pouvez également vousconnecter en tant qu'utilisateur root à la console système en utilisant le mot de passesesupgrade . Le noeud redémarre automatiquement après la mise à niveau.

78 Mise à niveau de noeud à l'aide du système de migration de distribution SUSE SES 6

Astuce : échec de la mise à niveauSi la mise à niveau échoue, consultez le chier journal /var/log/

distro_migration.log . Résolvez le problème, réinstallez les paquetages RPM demigration et redémarrez le noeud.

6.9 Mise à niveau du noeud AdminLes commandes suivantes continuent de fonctionner même si les minions Salt exécutentdes anciennes versions de Ceph et Salt : salt '*' test.ping et ceph status

Après la mise à niveau du noeud Admin, openATTIC ne sera plus installé.

Si le noeud Admin hébergeait SMT, eectuez sa migration vers RMT (voir https://

www.suse.com/documentation/sles-15/book_rmt/data/cha_rmt_migrate.html ).

Utilisez la procédure décrite à la Section 6.8, « Mise à niveau par noeud - Procédure de

base ».

Astuce : statut des noeuds de la grappeUne fois le noeud Admin mis à niveau, vous pouvez exécuter la commande salt-run upgrade.status pour acher des informations utiles sur les noeuds de la grappe.La commande répertorie les versions Ceph et OS de tous les noeuds, et recommandel'ordre dans lequel mettre à niveau les éventuels noeuds qui exécutent encore d'anciennesversions.

root@master # salt-run upgrade.statusThe newest installed software versions are: ceph: ceph version 14.2.1-468-g994fd9e0cc (994fd9e0ccc50c2f3a55a3b7a3d4e0ba74786d50) nautilus (stable) os: SUSE Linux Enterprise Server 15 SP1

Nodes running these software versions: admin.ceph (assigned roles: master) mon2.ceph (assigned roles: admin, mon, mgr)

Nodes running older software versions must be upgraded in the following order: 1: mon1.ceph (assigned roles: admin, mon, mgr) 2: mon3.ceph (assigned roles: admin, mon, mgr)

79 Mise à niveau du noeud Admin SES 6

3: data1.ceph (assigned roles: storage)[...]

6.10 Mise à niveau des noeuds Ceph Monitor/CephManager

Si votre grappe n'utilise pas les rôles MDS, mettez à niveau les noeuds MON/MGR unpar un.

Si votre grappe utilise les rôles MDS et que ces derniers sont situés sur la même machineque les rôles MON/MGR, vous devez réduire la grappe MDS, puis mettre à niveau lesnoeuds colocalisés. Pour plus d'informations, reportez-vous à la Section 6.11, « Mise à niveau

des serveurs de métadonnées ».

Si votre grappe utilise les rôles MDS et qu'ils s'exécutent sur des serveurs dédiés, mettezà niveau tous les noeuds MON/MGR un par un, puis réduisez la grappe MDS et mettez-la à niveau. Pour plus d'informations, reportez-vous à la Section 6.11, « Mise à niveau des

serveurs de métadonnées ».

Remarque : mise à niveau de Ceph MonitorEn raison d'une limitation dans la conception de Ceph Monitor, une fois que deux noeudsMON ont été mis à niveau vers SUSE Enterprise Storage 6 et ont formé un quorum, letroisième noeud MON (alors qu'il est encore sous SUSE Enterprise Storage 5.5) ne rejointpas la grappe MON en cas de redémarrage pour une raison quelconque, y compris unredémarrage du noeud. Par conséquent, lorsque deux noeuds MON ont été mis à niveau,il est préférable de mettre à niveau le reste dès que possible.

Utilisez la procédure décrite à la Section 6.8, « Mise à niveau par noeud - Procédure de base ».

6.11 Mise à niveau des serveurs de métadonnéesVous devez réduire la grappe des serveurs de métadonnées (Metadata Server, MDS). En raisonde fonctionnalités incompatibles entre les versions SUSE Enterprise Storage 5.5 et 6, les anciensdaemons MDS s'arrêtent dès qu'ils détectent qu'un MDS de niveau SES 6 rejoint la grappe. Par

80 Mise à niveau des noeuds Ceph Monitor/Ceph Manager SES 6

conséquent, il est nécessaire de réduire la grappe MDS à un seul MDS actif (et aucun à l'état deveille) pour la durée des mises à niveau des noeuds MDS. Dès que le deuxième noeud est mis àniveau, vous pouvez étendre à nouveau la grappe MDS.

AstuceSur une grappe MDS très chargée, vous devrez peut-être réduire la charge (par exemple,en arrêtant des clients) an qu'un seul MDS actif soit en mesure de gérer le workload.

1. Notez la valeur actuelle de l'option max_mds  :

cephadm@adm > ceph fs get cephfs | grep max_mds

2. Réduisez la grappe MDS si vous avez plus d'un daemon MDS actif, autrement dit max_mdsest > 1. Pour réduire la grappe MDS, exécutez la commande suivante :

cephadm@adm > ceph fs set FS_NAME max_mds 1

FS_NAME est le nom de votre instance CephFS (« cephfs » par défaut).

3. Recherchez le noeud hébergeant l'un des daemons MDS en veille. Consultez la sortie de lacommande ceph fs status et démarrez la mise à niveau de la grappe MDS sur ce noeud.

cephadm@adm > ceph fs statuscephfs - 2 clients======+------+--------+--------+---------------+-------+-------+| Rank | State | MDS | Activity | dns | inos |+------+--------+--------+---------------+-------+-------+| 0 | active | mon1-6 | Reqs: 0 /s | 13 | 16 |+------+--------+--------+---------------+-------+-------++-----------------+----------+-------+-------+| Pool | type | used | avail |+-----------------+----------+-------+-------+| cephfs_metadata | metadata | 2688k | 96.8G || cephfs_data | data | 0 | 96.8G |+-----------------+----------+-------+-------++-------------+| Standby MDS |+-------------+| mon3-6 || mon2-6 |+-------------+

81 Mise à niveau des serveurs de métadonnées SES 6

Dans cet exemple, vous devez commencer la procédure de mise à niveau sur le noeud« mon3-6 » ou « mon2-6 ».

4. Mettez à niveau le noeud avec le daemon MDS en veille. Une fois que le noeud MDS misà niveau a démarré, les daemons MDS obsolètes s'arrêtent automatiquement. À ce stade,les clients peuvent connaître une brève interruption du service CephFS.Utilisez la procédure décrite à la Section 6.8, « Mise à niveau par noeud - Procédure de

base ».

5. Mettez à niveau les noeuds MDS restants.

6. Réinitialisez la valeur max_mds à la conguration souhaitée :

cephadm@adm > ceph fs set FS_NAME max_mds ACTIVE_MDS_COUNT

6.12 Mise à niveau des Ceph OSDPour chaque noeud de stockage, procédez comme suit :

1. Identiez les daemons OSD qui s'exécutent sur un noeud particulier :

cephadm@osd > ceph osd tree

2. Dénissez le drapeau « noout » pour chaque daemon OSD sur le noeud en cours de miseà niveau :

cephadm@osd > ceph osd add-noout osd.OSD_ID

Par exemple :

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd add-noout osd.$i; done

Vériez avec l'une des commandes suivantes :

cephadm@osd > ceph health detail | grep noout

ou

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da

82 Mise à niveau des Ceph OSD SES 6

health: HEALTH_WARN 6 OSDs or CRUSH {nodes, device-classes} have {NOUP,NODOWN,NOIN,NOOUT} flags set

3. Créez des chiers /etc/ceph/osd/json pour tous les OSD existants en exécutant lacommande suivante sur le noeud qui va être mis à niveau :

cephadm@osd > ceph-volume simple scan --force

4. Mettez à niveau le noeud OSD. Utilisez la procédure décrite à la Section 6.8, « Mise à

niveau par noeud - Procédure de base ».

5. Activez tous les OSD détectés sur le système :

cephadm@osd > ;ceph-volume simple activate --all

Astuce : activation individuelle de partitions de donnéesSi vous souhaitez activer des partitions de données individuellement, vous deveztrouver la commande ceph-volume appropriée pour chaque partition. RemplacezX1 par la lettre/le numéro correct de la partition :

cephadm@osd > ceph-volume simple scan /dev/sdX1

Par exemple :

cephadm@osd > ceph-volume simple scan /dev/vdb1[...]--> OSD 8 got scanned and metadata persisted to file:/etc/ceph/osd/8-d7bd2685-5b92-4074-8161-30d146cd0290.json--> To take over management of this scanned OSD, and disable ceph-diskand udev, run:--> ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290

La dernière ligne de la sortie contient la commande pour activer la partition :

cephadm@osd > ceph-volume simple activate 8 d7bd2685-5b92-4074-8161-30d146cd0290[...]--> All ceph-disk systemd units have been disabled to prevent OSDsgetting triggered by UDEV events[...]Running command: /bin/systemctl start ceph-osd@8--> Successfully activated OSD 8 with FSID

83 Mise à niveau des Ceph OSD SES 6

d7bd2685-5b92-4074-8161-30d146cd0290

6. Vériez que le noeud OSD démarre correctement après le redémarrage.

7. Traitez le message « Legacy BlueStore stats reporting detected on XX OSD(s) » (Créationde rapports de statistiques BlueStore hérités sur XX OSD) :

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)

Cet avertissement est normal lors de la mise à niveau de Ceph vers la version 14.2.2. Vouspouvez le désactiver en entrant ceci :

bluestore_warn_on_legacy_statfs = false

La résolution appropriée de ce problème consiste à exécuter la commande suivante surtous les OSD pendant qu'ils sont arrêtés :

cephadm@osd > ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-XXX

Voici un script de programme auxiliaire qui exécute ceph-bluestore-tool repair pourtous les OSD sur le noeud NODE_NAME  :

OSDNODE=OSD_NODE_NAME;\ for OSD in $(ceph osd ls-tree $OSDNODE);\ do echo "osd=" $OSD;\ salt $OSDNODE cmd.run 'systemctl stop ceph-osd@$OSD';\ salt $OSDNODE cmd.run 'ceph-bluestore-tool repair --path /var/lib/ceph/osd/ceph-$OSD';\ salt $OSDNODE cmd.run 'systemctl start ceph-osd@$OSD';\ done

8. Annulez la dénition du drapeau « noout » pour chaque daemon OSD sur le noeud quiest mis à niveau :

cephadm@osd > ceph osd rm-noout osd.OSD_ID

84 Mise à niveau des Ceph OSD SES 6

Par exemple :

cephadm@osd > for i in $(ceph osd ls-tree OSD_NODE_NAME);do echo "osd: $i"; ceph osd rm-noout osd.$i; done

Vériez avec la commande suivante :

cephadm@osd > ceph health detail | grep noout

Remarque :

cephadm@osd > ceph –scluster: id: 44442296-033b-3275-a803-345337dc53da health: HEALTH_WARN Legacy BlueStore stats reporting detected on 6 OSD(s)

9. Vériez le statut de la grappe. Il ressemblera à la sortie suivante :

cephadm@osd > ceph statuscluster: id: e0d53d64-6812-3dfe-8b72-fd454a6dcf12 health: HEALTH_WARN 3 monitors have not enabled msgr2

services: mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h) mgr: mon2(active, since 22m), standbys: mon1, mon3 osd: 30 osds: 30 up, 30 in

data: pools: 1 pools, 1024 pgs objects: 0 objects, 0 B usage: 31 GiB used, 566 GiB / 597 GiB avail pgs: 1024 active+clean

10. Vériez que tous les noeuds OSD ont été redémarrés et que les OSD ont démarréautomatiquement après le redémarrage.

85 Mise à niveau des Ceph OSD SES 6

6.13 Migration des OSD vers BlueStoreOSD BlueStore est une nouvelle interface dorsale pour les daemons OSD. Il s'agit de l'option pardéfaut depuis la version 5 de SUSE Enterprise Storage. Comparé à FileStore, qui stocke des objetsen tant que chiers dans un système de chiers XFS, BlueStore peut fournir des performancesaccrues, car il stocke les objets directement sur le périphérique de bloc sous-jacent. BlueStoreutilise également d'autres fonctions, telles que la compression intégrée et les écrasements EC,qui ne sont pas disponibles avec FileStore.

En particulier pour BlueStore, un OSD dispose d'un périphérique « wal » (Write Ahead Log) etd'un périphérique « db » (base de données RocksDB). La base de données RocksDB conserve lesmétadonnées pour un OSD BlueStore. Ces deux périphériques résident sur le même périphériquequ'un OSD par défaut, mais peuvent être placés sur des supports diérents, plus rapides parexemple.

Dans SUSE Enterprise Storage  5, FileStore et BlueStore sont tous deux pris en charge et ilest possible que les OSD FileStore et BlueStore coexistent dans une seule grappe. Pendantla procédure de mise à niveau de SUSE  Enterprise  Storage, les OSD FileStore ne sont pasautomatiquement convertis en OSD BlueStore. Sachez que les fonctions spéciques à BlueStorene seront pas disponibles sur les OSD qui n'ont pas été migrés vers BlueStore.

Avant la conversion vers BlueStore, les OSD doivent exécuter SUSE Enterprise Storage 5. Laconversion est un processus lent, car toutes les données sont réécrites deux fois. Bien que leprocessus de migration puisse prendre beaucoup de temps, il n'y a pas d'interruption de la grappeet tous les clients peuvent continuer à y accéder pendant cette période. Cependant, attendez-vousà des performances inférieures pendant la durée de la migration. Cela est dû au rééquilibrageet au renvoi des données de la grappe.

Utilisez la procédure suivante pour migrer les OSD FileStore vers BlueStore :

Astuce : désactivation des mesures de sécuritéLes commandes Salt nécessaires pour exécuter la migration sont bloquées par des mesuresde sécurité. Pour désactiver ces précautions, exécutez la commande suivante :

root@master # salt-run disengage.safety

Reconstruisez les noeuds avant de continuer :

root@master # salt-run rebuild.node TARGET

86 Migration des OSD vers BlueStore SES 6

Vous pouvez également choisir de reconstruire chaque noeud individuellement. Parexemple :

root@master # salt-run rebuild.node data1.ceph

rebuild.node supprime et recrée toujours tous les OSD sur le noeud.

ImportantSi un seul OSD ne parvient pas eectuer la conversion, une nouvelle exécution dela reconstruction détruit les OSD BlueStore déjà convertis. Au lieu de relancer lareconstruction, vous pouvez exécuter la commande suivante :

root@master # salt-run disks.deploy TARGET

Après la migration vers BlueStore, le nombre d'objets restera le même et l'utilisation du disquesera presque la même.

6.14 Mises à niveau des noeuds d'applicationMettez à niveau les noeuds d'application dans l'ordre suivant :

1. Object Gateway

Si les passerelles Object Gateway ont devant elles un équilibreur de charge, il doitêtre possible de les mettre à niveau de façon progressive sans interruption de service.

Vériez que les daemons Object Gateway s'exécutent après chaque mise à niveau eteectuez un test avec le client S3/Swift.

Utilisez la procédure décrite à la Section 6.8, « Mise à niveau par noeud - Procédure

de base ».

2. Passerelles iSCSI

87 Mises à niveau des noeuds d'application SES 6

Si les initiateurs iSCSI sont congurés avec multipath, il doit être possible de mettreà niveau les passerelles iSCSI de façon progressive sans interruption de service.

Vériez que le daemon lrbd est en cours d'exécution après chaque mise à niveauet testez avec l'initiateur.

Utilisez la procédure décrite à la Section 6.8, « Mise à niveau par noeud - Procédure

de base ».

3. NFS Ganesha. Utilisez la procédure décrite à la Section 6.8, « Mise à niveau par noeud

- Procédure de base ».

4. Passerelles Samba. Utilisez la procédure décrite à la Section 6.8, « Mise à niveau par

noeud - Procédure de base ».

6.15 Mise à jour de policy.cfg et déploiement deCeph Dashboard à l'aide de DeepSeaSur le noeud Admin, éditez /srv/pillar/ceph/proposals/policy.cfg et appliquez lesmodications suivantes :

Important : absence de nouveaux servicesPendant la mise à niveau de la grappe, n'ajoutez pas de nouveaux services au chierpolicy.cfg . Modiez l'architecture de la grappe uniquement lorsque la mise à niveauest terminée.

1. Supprimez role-openattic .

2. Ajoutez role-prometheus et role-grafana au noeud sur lequel Prometheus et Grafanasont installés, généralement le noeud Admin.

3. Le rôle profile-NOM_PROFIL est maintenant ignoré. Ajoutez le nouveau rôlecorrespondant, ligne role-storage . Par exemple, pour l'élément existant :

profile-default/cluster/*.sls

88 Mise à jour de policy.cfg et déploiement de Ceph Dashboard à l'aide de DeepSea SES 6

Ajoutez :

role-storage/cluster/*.sls

4. Synchronisez tous les modules Salt :

root@master # salt '*' saltutil.sync_all

5. Mettez à jour l'interface Pillar de Salt en exécutant les phases 1 et 2 de DeepSea :

root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2

6. Nettoyez openATTIC :

root@master # salt OA_MINION state.apply ceph.rescind.openatticroot@master # salt OA_MINION state.apply ceph.remove.openattic

7. Annulez la dénition du grain « restart_igw » pour empêcher la phase 0 de redémarrer lapasserelle iSCSI, qui n'est pas encore installée :

Salt mastersalt '*' grains.delkey restart_igw

8. Enn, exécutez les phases 0 à 4 de DeepSea :

root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

Astuce : erreurs « subvolume missing » (sous-volumemanquant) lors de la phase 3La phase 3 de DeepSea peut échouer avec une erreur similaire à la suivante :

subvolume : ['/var/lib/ceph subvolume missing on 4510-2', \'/var/lib/ceph subvolume missing on 4510-1', \[...]'See /srv/salt/ceph/subvolume/README.md']

89 Mise à jour de policy.cfg et déploiement de Ceph Dashboard à l'aide de DeepSea SES 6

Dans ce cas, vous devez modier /srv/pillar/ceph/stack/global.yml etajouter la ligne suivante :

subvolume_init: disabled

Ensuite, rafraîchissez l'interface Pillar de Salt et réexécutez la phase 3 de DeepSea :

root@master # salt '*' saltutil.refresh_pillar root@master # salt-run state.orch ceph.stage.3

Une fois la phase 3 de DeepSea réussie, Ceph Dashboard sera en cours d'exécution.Reportez-vous au Manuel « Guide d'administration », Chapitre 22 « Ceph Dashboard »

pour un aperçu détaillé des fonctionnalités de Ceph Dashboard.

Pour répertorier les noeuds exécutant le tableau de bord, exécutez la commandesuivante :

cephadm@adm > ceph mgr services | grep dashboard

Pour répertorier les informations d'identication d'administration, exécutez lacommande suivante :

root@master # salt-call grains.get dashboard_creds

9. Redémarrez les services Object Gateway de manière séquentielle pour utiliser le serveurWeb « beast » au lieu du serveur « civetweb » obsolète :

root@master # salt-run state.orch ceph.restart.rgw.force

10. Avant de continuer, nous vous recommandons fortement d'activer le module de télémétrieCeph. Pour plus d'informations et des instructions, reportez-vous au Manuel «  Guide

d'administration », Chapitre 10 « Modules Ceph Manager », Section 10.2 « Module de télémétrie ».

6.16 Migration des déploiements basés sur le profilvers les groupes d'unitésDans SUSE Enterprise Storage 5.5, DeepSea proposait des « prols » pour décrire la disposition devos OSD. À partir de SUSE Enterprise Storage 6, nous sommes passés à une approche diérente,à savoir les Groupes d'unités (plus de détails à la Section 5.5.2, « Groupes d'unités »).

90 Migration des déploiements basés sur le profil vers les groupes d'unités SES 6

RemarqueLa migration vers la nouvelle approche n'est pas immédiatement obligatoire. Desopérations destructrices, telles que salt-run osd.remove , salt-run osd.replaceou salt-run osd.purge sont toujours disponibles. Toutefois, l'ajout de nouveaux OSDnécessite votre intervention.

En raison de l'approche diérente de ces implémentations, nous ne proposons pas de cheminde migration automatisé. Cependant, nous orons une variété d'outils (exécuteurs Salt) pourrendre la migration aussi simple que possible.

6.16.1 Analyse de la disposition actuelle

Pour acher les informations sur les OSD actuellement déployés, utilisez la commande suivante :

root@master # salt-run disks.discover

Vous pouvez également inspecter le contenu des chiers dans les répertoires /srv/pillar/ceph/proposals/profile-*/ . Ils ont une structure similaire à la suivante :

ceph: storage: osds: /dev/disk/by-id/scsi-drive_name: format: bluestore /dev/disk/by-id/scsi-drive_name2: format: bluestore

6.16.2 Création de groupes d'unités correspondant à la dispositionactuelle

Reportez-vous à la Section 5.5.2.1, « Spécification » pour plus d'informations sur les groupes d'unités.

La diérence entre un nouveau déploiement et un scénario de mise à niveau est que les unitésà migrer sont déjà « utilisées ». Étant donné que la commande

root@master # salt-run disks.list

recherche uniquement les disques inutilisés, employez

root@master # salt-run disks.list include_unavailable=True

91 Analyse de la disposition actuelle SES 6

Ajustez les groupes d'unités jusqu'à ce qu'ils correspondent à votre conguration actuelle. Pourune représentation plus visuelle de ce qui va se passer, utilisez la commande suivante. Notezqu'elle ne renvoie aucune sortie s'il n'y a pas de disque libre :

root@master # salt-run disks.report bypass_pillar=True

Si vous avez vérié que vos groupes d'unités sont correctement congurés et que voussouhaitez appliquer la nouvelle approche, supprimez les chiers du répertoire /srv/pillar/ceph/proposals/profile-NOM_PROFIL/ , supprimez les lignes correspondantes profile-

NOM_PROFIL/cluster/*.sls du chier /srv/pillar/ceph/proposals/policy.cfg , puisexécutez la phase 2 de DeepSea pour rafraîchir l'interface Pillar de Salt.

root@master # salt-run state.orch ceph.stage.2

Vériez le résultat en exécutant les commandes suivantes :

root@master # salt target_node pillar.get ceph:storageroot@master # salt-run disks.report

Avertissement : configuration incorrecte des groupes d'unitésSi vos groupes d'unités ne sont pas correctement congurés et que votre congurationcomporte des disques de rechange, ils seront déployés de la manière dont vous les avezspéciés. Nous recommandons d'exécuter la commande suivante :

root@master # salt-run disks.report

6.16.3 Déploiement OSD

Pour les cas simples tels que les OSD autonomes, la migration se fera au l du temps. Chaquefois que vous supprimerez ou remplacerez un OSD de la grappe, il sera substitué par un nouvelOSD basé sur LVM.

Astuce : migration vers le format LVMChaque fois qu'un OSD « hérité » unique doit être remplacé sur un noeud, tous les OSDqui partagent des périphériques avec lui doivent être migrés vers le format basé sur LVM.

À des ns d'exhaustivité, envisagez de migrer les OSD sur l'ensemble du noeud.

92 Déploiement OSD SES 6

6.16.4 Configurations plus complexes

Si vous disposez d'une conguration plus sophistiquée que de simples OSD autonomes, parexemple des périphériques WAL/DB dédiés ou des OSD chirés, la migration ne peut se produireque lorsque tous les OSD aectés à cet appareil WAL/DB sont supprimés. Cela est dû à lacommande ceph-volume qui crée des volumes logiques (Logical Volume, LV) sur les disquesavant le déploiement. Cela empêche l'utilisateur de mélanger les déploiements basés sur lapartition avec les déploiements basés sur LV. Dans de tels cas, il est préférable de supprimermanuellement tous les OSD qui sont assignés à un appareil WAL/DB et de les redéployer à l'aidede l'approche Groupes d'unités.

93 Configurations plus complexes SES 6

7 Personnalisation de la configuration par défaut

Vous pouvez modier la conguration en grappe par défaut créée à la phase 2 (reportez-vous àla Description des phases de DeepSea). Par exemple, vous devrez peut-être modier les paramètresréseau ou le logiciel installé par défaut sur le noeud Admin. Vous pouvez eectuer la premièreopération en modiant l'interface Pillar mise à jour après la phase 2, tandis que la deuxièmeopération est généralement eectuée en créant un chier sls personnalisé et en l'ajoutant àPillar. Les détails sont décrits dans les sections suivantes.

7.1 Utilisation de fichiers de configurationpersonnalisésCette section répertorie plusieurs tâches nécessitant l'ajout/la modication de vos propreschiers sls . Ce type de procédure est généralement utilisé lorsque vous devez modier leprocessus de déploiement par défaut.

Astuce : préfixe des fichiers .sls personnalisésVos chiers .sls personnalisés appartiennent au même sous-répertoire que les chiers .slsde DeepSea. Pour éviter d'écraser vos chiers .sls par ceux éventuellement ajoutés depuisle paquetage DeepSea, ajoutez la chaîne custom- au début de leur nom.

7.1.1 Désactivation d'une étape du déploiement

Si vous eectuez une tâche spécique en dehors du processus de déploiement de DeepSea et quevous devez par conséquent l'ignorer, créez un chier « no-operation » en suivant cet exemple :

PROCÉDURE 7.1T : DÉSACTIVATION DE LA SYNCHRONISATION HORAIRE

1. Créez le chier /srv/salt/ceph/time/disabled.sls avec le contenu suivant etenregistrez-le :

disable time setting:test.nop

94 Utilisation de fichiers de configuration personnalisés SES 6

2. Modiez le chier /srv/pillar/ceph/stack/global.yml , ajoutez la ligne suivante etenregistrez-le :

time_init: disabled

3. Vériez l'opération en rafraîchissant Pillar et en exécutant l'étape :

root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.timeadmin.ceph: Name: disable time setting - Function: test.nop - Result: Clean

Summary for admin.ceph------------Succeeded: 1Failed: 0------------Total states run: 1

Remarque : ID uniqueL'ID de tâche « disable time setting » (désactiver le paramètre horaire) peut êtren'importe quel message unique au sein d'un chier sls . Évitez les collisions d'IDen spéciant des descriptions uniques.

7.1.2 Remplacement d'une étape du déploiement

Si vous devez remplacer le comportement par défaut d'une étape spécique par uncomportement personnalisé, créez un chier sls personnalisé avec le contenu deremplacement.

Par défaut, /srv/salt/ceph/pool/default.sls crée une image RBD appelée « demo ». Dansnotre exemple, nous ne souhaitons pas que cette image soit créée, mais nous avons besoin dedeux images : « archive1 » et « archive2 ».

PROCÉDURE 7.2T : REMPLACEMENT DE L'IMAGE RBD DEMO PAR DEUX IMAGES RBD PERSONNALISÉES

1. Créez le chier /srv/salt/ceph/pool/custom.sls avec le contenu suivant etenregistrez-le :

wait:

95 Remplacement d'une étape du déploiement SES 6

module.run: - name: wait.out - kwargs: 'status': "HEALTH_ERR" 1

- fire_event: True

archive1: cmd.run: - name: "rbd -p rbd create archive1 --size=1024" 2

- unless: "rbd -p rbd ls | grep -q archive1$" - fire_event: True

archive2: cmd.run: - name: "rbd -p rbd create archive2 --size=768" - unless: "rbd -p rbd ls | grep -q archive2$" - fire_event: True

1 Le module wait se met en pause jusqu'à ce que la grappe Ceph n'ait plus l'étatHEALTH_ERR . Dans les nouvelles installations, une grappe Ceph peut avoir cet étatjusqu'à ce qu'un nombre susant d'OSD soient disponibles et que la création desréserves soit terminée.

2 La commande rbd n'est pas idempotente. Si la même commande de création estréexécutée après l'apparition de l'image, l'état Salt échoue. L'instruction unlessempêche une telle situation.

2. Pour appeler le chier personnalisé qui vient d'être créé au lieu du chier par défaut, vousdevez modier le chier /srv/pillar/ceph/stack/ceph/cluster.yml , ajouter la lignesuivante et l'enregistrer :

pool_init: custom

3. Vériez l'opération en rafraîchissant Pillar et en exécutant l'étape :

root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool

Remarque : autorisationLa création de réserves ou d'images requiert une autorisation. Le minion admin.cephdispose d'un porte-clés admin.

96 Remplacement d'une étape du déploiement SES 6

Astuce : autre moyenUne autre option consiste à modier la variable dans le chier /srv/pillar/

ceph/stack/ceph/roles/master.yml . L'utilisation de ce chier permet de réduirel'encombrement des données de Pillar pour les autres minions.

7.1.3 Modification d'une étape du déploiement

Parfois, vous pouvez avoir besoin d'une étape spécique pour eectuer des tâchessupplémentaires. Il est déconseillé de modier le chier d'état associé, car cela pourraitcompliquer une future mise à niveau. Au lieu de cela, créez un chier distinct pour eectuerles tâches supplémentaires identiques à celles décrites à la Section 7.1.2, « Remplacement d'une

étape du déploiement ».

Nommez le nouveau chier sls de manière conviviale. Par exemple, si vous devez créer deuximages RBD en plus de l'image demo, nommez le chier archive.sls .

PROCÉDURE 7.3T : CRÉATION DE DEUX IMAGES RBD SUPPLÉMENTAIRES

1. Créez le chier /srv/salt/ceph/pool/custom.sls avec le contenu suivant etenregistrez-le :

include: - .archive - .default

Astuce : priorité de l'inclusionDans cet exemple, Salt crée les images archive, puis l'image demo. L'ordre n'a pasd'importance dans cet exemple. Pour modier l'ordre, inversez les lignes aprèsl'instruction include: .

Vous pouvez ajouter la ligne include directement au chier archive.sls ettoutes les images sont ainsi créées. Toutefois, quel que soit l'emplacement de laligne include, Salt traite tout d'abord les étapes du chier inclus. Bien que cecomportement puisse être remplacé par les instructions requires et order, un chierdistinct incluant les autres instructions garantit l'ordre et réduit les risques deconfusion.

97 Modification d'une étape du déploiement SES 6

2. Modiez le chier /srv/pillar/ceph/stack/ceph/cluster.yml , ajoutez la lignesuivante et enregistrez-le :

pool_init: custom

3. Vériez l'opération en rafraîchissant Pillar et en exécutant l'étape :

root@master # salt target saltutil.pillar_refreshroot@master # salt 'admin.ceph' state.apply ceph.pool

7.1.4 Modification d'une phase du déploiement

Si vous devez ajouter une étape de déploiement complètement distincte, créez trois nouveauxchiers  : un chier sls qui exécute la commande, un chier d'orchestration et un chierpersonnalisé qui aligne la nouvelle étape sur les étapes de déploiement d'origine.

Par exemple, si vous devez exécuter logrotate sur tous les minions dans le cadre de la phasede préparation :

Tout d'abord, créez un chier sls et incluez la commande logrotate .

PROCÉDURE 7.4T : EXÉCUTION DE logrotate SUR TOUS LES MINIONS SALT

1. Créez un répertoire, par exemple /srv/salt/ceph/logrotate .

2. Créez le chier /srv/salt/ceph/logrotate/init.sls avec le contenu suivant etenregistrez-le :

rotate logs: cmd.run: - name: "/usr/sbin/logrotate /etc/logrotate.conf"

3. Vériez que la commande fonctionne sur un minion :

root@master # salt 'admin.ceph' state.apply ceph.logrotate

Comme le chier d'orchestration doit être exécuté avant toutes les autres étapes de préparation,ajoutez-le à la phase 0 Prep :

1. Créez le chier /srv/salt/ceph/stage/prep/logrotate.sls avec le contenu suivantet enregistrez-le :

logrotate: salt.state:

98 Modification d'une phase du déploiement SES 6

- tgt: '*' - sls: ceph.logrotate

2. Vériez que le chier d'orchestration fonctionne :

root@master # salt-run state.orch ceph.stage.prep.logrotate

Le dernier chier est le chier personnalisé qui inclut l'étape supplémentaire avec les étapesd'origine :

1. Créez le chier /srv/salt/ceph/stage/prep/custom.sls avec le contenu suivant etenregistrez-le :

include: - .logrotate - .master - .minion

2. Remplacez le comportement par défaut : Modiez le chier /srv/pillar/ceph/stack/global.yml , ajoutez la ligne suivante et enregistrez-le :

stage_prep: custom

3. Vériez que la phase 0 fonctionne :

root@master # salt-run state.orch ceph.stage.0

Remarque : pourquoi global.yml ?Le chier global.yml est préféré au chier cluster.yml , car, pendant la phaseprep, aucun minion n'appartient à la grappe Ceph et n'a accès à des paramètres decluster.yml .

7.1.5 Mises à jour et redémarrages pendant la phase 0

Au cours de la phase 0 (voir la section Description des phases de DeepSea pour plus d'informationssur les phases DeepSea), les minions Salt Master et Salt peuvent redémarrer si des paquetagesrécemment mis à jour, par exemple kernel , nécessitent un redémarrage du système.

Le comportement par défaut consiste à installer les nouvelles mises à jour disponibles et à nepas redémarrer les noeuds, même en cas de mises à jour de kernel.

99 Mises à jour et redémarrages pendant la phase 0 SES 6

Vous pouvez modier le comportement de mise à jour/redémarrage par défaut de la phase 0 deDeepSea en ajoutant/modiant les options stage_prep_master et stage_prep_minion dansle chier /srv/pillar/ceph/stack/global.yml . _prep_master dénit le comportement deSalt Master, tandis que stage_prep_minion congure le comportement de tous les minions.Tous les paramètres disponibles sont les suivants :

default

Installe les mises à jour sans redémarrer.

default-update-reboot

Installe les mises à jour et redémarre le système après la mise à jour.

default-no-update-reboot

Redémarre sans installer les mises à jour.

default-no-update-no-reboot

N'installe pas de mises à jour et ne redémarre pas.

Par exemple, pour empêcher les noeuds de grappe d'installer des mises à jour et de redémarrer,modiez le chier /srv/pillar/ceph/stack/global.yml et ajoutez les lignes suivantes :

stage_prep_master: default-no-update-no-rebootstage_prep_minion: default-no-update-no-reboot

Astuce : valeurs et fichiers correspondantsLes valeurs stage_prep_master correspondent aux noms de chiers situés dans /srv/salt/ceph/stage/0/master , tandis que les valeurs stage_prep_minion correspondentaux chiers dans /srv/salt/ceph/stage/0/minion  :

root@master # ls -l /srv/salt/ceph/stage/0/masterdefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]

root@master # ls -l /srv/salt/ceph/stage/0/miniondefault-no-update-no-reboot.slsdefault-no-update-reboot.slsdefault-update-reboot.sls[...]

100 Mises à jour et redémarrages pendant la phase 0 SES 6

7.2 Modification de la configuration découverteAprès avoir terminé la phase 2, vous souhaiterez peut-être modier la conguration découverte.Pour acher les paramètres actuels, exécutez :

root@master # salt target pillar.items

La sortie de la conguration par défaut pour un seul minion est généralement similaire à cequi suit :

---------- available_roles: - admin - mon - storage - mds - igw - rgw - client-cephfs - client-radosgw - client-iscsi - mds-nfs - rgw-nfs - master cluster: ceph cluster_network: 172.16.22.0/24 fsid: e08ec63c-8268-3f04-bcdb-614921e94342 master_minion: admin.ceph mon_host: - 172.16.21.13 - 172.16.21.11 - 172.16.21.12 mon_initial_members: - mon3 - mon1 - mon2 public_address: 172.16.21.11 public_network: 172.16.21.0/24 roles:

101 Modification de la configuration découverte SES 6

- admin - mon - mds time_server: admin.ceph time_service: ntp

Les paramètres mentionnés ci-dessus sont distribués sur plusieurs chiers de conguration. Lastructure de répertoires avec ces chiers est dénie dans le répertoire /srv/pillar/ceph/stack/stack.cfg . Les chiers suivants décrivent généralement votre grappe :

/srv/pillar/ceph/stack/global.yml  : le chier a une incidence sur tous les minionsde la grappe Salt.

/srv/pillar/ceph/stack/ceph/cluster.yml   : le chier a une incidence sur tous lesminions de la grappe Ceph appelée ceph .

/srv/pillar/ceph/stack/ceph/roles/role.yml  : a une incidence sur tous les minionsqui sont assignés au rôle spécique dans la grappe ceph .

/srv/pillar/ceph/stack/cephminions/ID_MINION/yml  : a une incidence sur le minionconcerné.

Remarque : écrasement des répertoires par des valeurs pardéfautIl existe une arborescence de répertoire parallèle qui stocke la conguration par défautdans /srv/pillar/ceph/stack/default . Ne modiez pas les valeurs, car elles serontécrasées.

La procédure standard de modication de la conguration collectée est la suivante :

1. Recherchez l'emplacement de l'élément de conguration que vous devez modier. Parexemple, si vous devez modier un paramètre lié à une grappe, tel qu'un réseau de grappe,modiez le chier /srv/pillar/ceph/stack/ceph/cluster.yml .

2. Enregistrez le chier.

3. Vériez les modications en exécutant :

root@master # salt target saltutil.pillar_refresh

102 Modification de la configuration découverte SES 6

puis

root@master # salt target pillar.items

7.2.1 Activation du protocole IPv6 pour le déploiement de grappeCeph

Étant donné que l'adressage réseau IPv4 est plus répandu, vous devez activer IPv6 commepersonnalisation. DeepSea ne propose pas de fonction de découverte automatique de l'adressageIPv6.

Pour congurer IPv6, dénissez les variables public_network et cluster_network dans lechier /srv/pillar/ceph/stack/global.yml sur des sous-réseaux IPv6 valides. Par exemple :

public_network: fd00:10::/64cluster_network: fd00:11::/64

Exécutez ensuite la phase 2 de DeepSea et vériez que les informations réseau correspondentau paramètre. La phase 3 générera le chier ceph.conf avec les drapeaux nécessaires.

Important : pas de prise en charge de la double pileCeph ne prend pas en charge la double pile  ; il n'est pas possible d'exécuter Cephsimultanément sur IPv4 et IPv6. La validation DeepSea rejettera une discordance entrepublic_network et cluster_network , ou au sein de l'une de ces variables. L'exemplesuivant échouera à la validation.

public_network: "192.168.10.0/24 fd00:10::/64"

Astuce : évitez d'utiliser des adresses fe80::/10 link-localÉvitez d'utiliser des adresses fe80::/10 link-local . Toutes les interfaces réseau ontune adresse fe80 assignée et nécessitent un qualicatif d'interface pour un routageapproprié. Assignez des adresses IPv6 attribuées à votre site ou envisagez d'utiliserfd00:/8 . Celles-ci font partie de l'adressage local unique (ULA) et ne sont pas routablesglobalement.

103 Activation du protocole IPv6 pour le déploiement de grappe Ceph SES 6

III Installation de servicessupplémentaires

8 Installation des services permettant d'accéder à vos données 105

9 Ceph Object Gateway 106

10 Installation de la passerelle iSCSI 114

11 Installation de CephFS 127

12 Installation de NFS Ganesha 144

8 Installation des services permettant d'accéder à vosdonnées

Après avoir déployé la grappe SUSE  Enterprise  Storage  6, vous devrez peut-être installerdes logiciels supplémentaires pour accéder à vos données, tels qu'Object  Gateway ou lapasserelle iSCSI, ou vous pouvez déployer un système de chiers en grappe sur la grappe Ceph.Ce chapitre traite essentiellement de l'installation manuelle. Si vous disposez d'une grappedéployée à l'aide de Salt, reportez-vous au Chapitre 5, Déploiement avec DeepSea/Salt pour obtenirune procédure d'installation de passerelles spéciques ou du système CephFS.

105 SES 6

9 Ceph Object Gateway

Ceph Object Gateway est une interface de stockage des objets construite au-dessus de librgwpour fournir aux applications une passerelle RESTful vers les grappes Ceph. Elle prend en chargedeux interfaces :

Compatible avec S3 : fournit une fonctionnalité de stockage des objets avec une interfacecompatible avec un vaste sous-ensemble de l'API RESTful Amazon S3.

Compatible avec Swift : fournit une fonctionnalité de stockage des objets avec une interfacecompatible avec un vaste sous-ensemble de l'API OpenStack Swift.

Le daemon Object Gateway utilise l'interface client HTTP « Beast » par défaut. Celle-ci emploie labibliothèque Boost.Beast pour l'analyse HTTP et la bibliothèque Boost.Asio pour les opérationsE/S réseau asynchrones.

Étant donné que la passerelle Object Gateway fournit des interfaces compatibles avecOpenStack Swift et Amazon S3, elle possède sa propre gestion des utilisateurs. Object Gatewaypeut stocker des données dans la même grappe que celle utilisée pour stocker des donnéesprovenant de clients CephFS ou de clients RBD. Les API S3 et Swift partagent un espace de nomscommun, vous pouvez donc écrire des données avec une API et les récupérer avec l'autre.

Important : Object Gateway déployé par DeepSeaObject Gateway est installé en tant que rôle DeepSea. Vous n'avez donc pas besoin del'installer manuellement.

Pour installer Object Gateway au cours du déploiement de la grappe, reportez-vous à laSection 5.3, « Déploiement de la grappe ».

Pour ajouter un nouveau noeud avec l'instance Object Gateway à la grappe, reportez-vousau Manuel « Guide d'administration », Chapitre 2 « Administration de grappe Salt », Section 2.2

« Ajout de nouveaux rôles à des noeuds ».

106 SES 6

9.1 Installation manuelle d'Object Gateway

1. Installez Object Gateway sur un noeud qui n'utilise pas le port 80. La commande suivantepermet d'installer tous les composants requis :

cephadm@ogw > sudo zypper ref && zypper in ceph-radosgw

2. Si le serveur Apache de l'instance Object Gateway précédente est en cours d'exécution,arrêtez-le et désactivez le service concerné :

cephadm@ogw > sudo systemctl stop disable apache2.service

3. Modiez /etc/ceph/ceph.conf et ajoutez les lignes suivantes :

[client.rgw.gateway_host] rgw frontends = "beast port=80"

AstuceSi vous souhaitez congurer Object Gateway/Beast pour une utilisation avec lechirement SSL, modiez la ligne en conséquence :

rgw frontends = beast ssl_port=7480 ssl_certificate=PATH_TO_CERTIFICATE.PEM

4. Redémarrez le service Object Gateway.

cephadm@ogw > sudo systemctl restart ceph-radosgw@rgw.gateway_host

9.1.1 Configuration d'Object Gateway

Plusieurs étapes sont nécessaires pour congurer une passerelle Object Gateway.

107 Installation manuelle d'Object Gateway SES 6

9.1.1.1 Configuration de base

La conguration d'une passerelle Ceph  Object  Gateway requiert une grappe de stockageCeph Storage Cluster en cours d'exécution. La passerelle Ceph Object Gateway est un client de lagrappe Ceph Storage Cluster. En tant que client de la grappe Ceph Storage Cluster, elle nécessite :

Un nom d'hôte pour l'instance de passerelle, par exemple gateway .

Un nom d'utilisateur de grappe de stockage avec les autorisations appropriées et un porte-clés.

Des réserves pour stocker ses données.

Un répertoire de données de l'instance de passerelle.

Une entrée d'instance dans le chier de conguration Ceph.

Chaque instance doit disposer d'un nom d'utilisateur et d'une clé pour communiquer avec unegrappe de stockage Ceph. Dans les étapes suivantes, nous utilisons un noeud de moniteurpour créer un porte-clés d'amorçage, puis créons le porte-clés d'utilisateurs de l'instanceObject Gateway en fonction de celui de l'amorçage. Ensuite, nous créons un nom d'utilisateur etune clé client. Puis, nous ajoutons la clé à la grappe de stockage Ceph. Enn, nous distribuonsle porte-clés vers le noeud contenant l'instance de passerelle.

1. Créez un porte-clés pour la passerelle :

cephadm@adm > ceph-authtool --create-keyring /etc/ceph/ceph.client.rgw.keyringcephadm@adm > sudo chmod +r /etc/ceph/ceph.client.rgw.keyring

2. Générez un nom d'utilisateur et une clé Ceph Object Gateway pour chaque instance. Parexemple, nous utiliserons le nom gateway après client.radosgw  :

cephadm@adm > ceph-authtool /etc/ceph/ceph.client.rgw.keyring \ -n client.rgw.gateway --gen-key

3. Ajoutez des fonctionnalités à la clé :

cephadm@adm > ceph-authtool -n client.rgw.gateway --cap osd 'allow rwx' \ --cap mon 'allow rwx' /etc/ceph/ceph.client.rgw.keyring

4. Après avoir créé un porte-clés et une clé pour activer Ceph Object Gateway avec accès àla grappe de stockage Ceph Storage Cluster, ajoutez la clé à cette grappe. Par exemple :

cephadm@adm > ceph -k /etc/ceph/ceph.client.admin.keyring auth add client.rgw.gateway \

108 Configuration d'Object Gateway SES 6

-i /etc/ceph/ceph.client.rgw.keyring

5. Distribuez le porte-clés vers le noeud avec l'instance de passerelle :

cephadm@adm > scp /etc/ceph/ceph.client.rgw.keyring ceph@HOST_NAME:/home/cephcephadm@adm > ssh ceph@HOST_NAMEcephadm@ogw > mv ceph.client.rgw.keyring /etc/ceph/ceph.client.rgw.keyring

Astuce : utilisation d'un porte-clés d'amorçageUne alternative consiste à créer le porte-clés d'amorçage de l'instance Object Gateway,puis à créer le porte-clés de cette dernière à partir de ce porte-clés d'amorçage :

1. Créez un porte-clés d'amorçage de l'instance Object Gateway sur un des noeuds demoniteur :

cephadm@mon > ceph \ auth get-or-create client.bootstrap-rgw mon 'allow profile bootstrap-rgw' \ --connect-timeout=25 \ --cluster=ceph \ --name mon. \ --keyring=/var/lib/ceph/mon/ceph-NODE_HOST/keyring \ -o /var/lib/ceph/bootstrap-rgw/keyring

2. Créez le répertoire /var/lib/ceph/radosgw/ceph-NOM_RGW pour stocker letrousseau de clés d'amorçage :

cephadm@mon > mkdir \/var/lib/ceph/radosgw/ceph-RGW_NAME

3. Créez un trousseau de clés Object Gateway à partir du trousseau de clés d'amorçagenouvellement créé :

cephadm@mon > ceph \ auth get-or-create client.rgw.RGW_NAME osd 'allow rwx' mon 'allow rw' \ --connect-timeout=25 \ --cluster=ceph \ --name client.bootstrap-rgw \ --keyring=/var/lib/ceph/bootstrap-rgw/keyring \ -o /var/lib/ceph/radosgw/ceph-RGW_NAME/keyring

109 Configuration d'Object Gateway SES 6

4. Copiez le trousseau de clés de la passerelle Object  Gateway vers l'hôte de lapasserelle :

cephadm@mon > scp \/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring \RGW_HOST:/var/lib/ceph/radosgw/ceph-RGW_NAME/keyring

9.1.1.2 Création de réserves (facultatif)

Les passerelles Ceph  Object  Gateway nécessitent des réserves de la grappe de stockageCeph Storage Cluster pour stocker des données spéciques de la passerelle. Si l'utilisateur quevous avez créé possède les autorisations appropriées, la passerelle crée automatiquement lesréserves. Toutefois, vériez que vous avez déni un nombre de groupes de placement par défautapproprié par réserve dans le chier de conguration Ceph.

Les noms de réserve suivent la syntaxe ZONE_NAME.POOL_NAME (NOM_ZONE, NOM_RÉSERVE).Lorsque vous congurez une passerelle avec la région et la zone par défaut, le nom de zone pardéfaut est « default » comme dans notre exemple :

.rgw.rootdefault.rgw.controldefault.rgw.metadefault.rgw.logdefault.rgw.buckets.indexdefault.rgw.buckets.data

Pour créer manuellement les réserves, reportez-vous au Manuel « Guide d'administration », Chapitre

11 « Gestion des réserves de stockage », Section 11.2.2 « Création d'une réserve ».

Important : Object Gateway et les réserves codées à eacementSeule la réserve default.rgw.buckets.data peut être de type « codée à eacement ».Toutes les autres réserves doivent être répliquées, sinon la passerelle n'est pas accessible.

110 Configuration d'Object Gateway SES 6

9.1.1.3 Ajout d'une configuration de passerelle à Ceph

Ajoutez la conguration de passerelle Ceph Object Gateway au chier de conguration Ceph.La conguration de passerelle Ceph  Object  Gateway nécessite l'identication de l'instanceCeph  Object  Gateway. Ensuite, spéciez le nom d'hôte où vous avez installé le daemonCeph Object Gateway, un porte-clés (pour utilisation avec cephx) et éventuellement un chierjournal. Par exemple :

[client.rgw.INSTANCE_NAME]host = HOST_NAMEkeyring = /etc/ceph/ceph.client.rgw.keyring

Astuce : fichier journal Object GatewayPour remplacer le chier journal par défaut Object Gateway, incluez ce qui suit :

log file = /var/log/radosgw/client.rgw.INSTANCE_NAME.log

La partie [client.rgw.*] de l'instance de passerelle identie cette partie du chier deconguration Ceph comme congurant un client de la grappe de stockage Ceph Storage Clusteroù le type de client est un daemon Ceph Object Gateway (radosgw). Le nom de l'instance suit.Par exemple :

[client.rgw.gateway]host = ceph-gatewaykeyring = /etc/ceph/ceph.client.rgw.keyring

RemarqueNOM_HÔTE doit correspondre au nom d'hôte de votre machine, à l'exclusion du nom dedomaine.

Puis, désactivez print continue . Si vous l'avez déni sur true (vrai), vous pouvez rencontrerdes problèmes avec les opérations PUT :

rgw print continue = false

111 Configuration d'Object Gateway SES 6

Pour utiliser une passerelle Ceph Object Gateway avec des appels au sous-domaine  S3 (parexemple http://bucketname.hostname ), vous devez ajouter le nom DNS de la passerelle sousla section [client.rgw.gateway] du chier de conguration Ceph :

[client.rgw.gateway]...rgw dns name = HOST_NAME

Vous devriez également envisager d'installer un serveur  DNS tel que Dnsmasq sur votre ouvos machines client lorsque vous utilisez la syntaxe http://BUCKET_NAME.HOST_NAME (http://NOM_COMPARTIMENT.NOM_HÔTE). Le chier dnsmasq.conf doit inclure les paramètressuivants :

address=/HOST_NAME/HOST_IP_ADDRESSlisten-address=CLIENT_LOOPBACK_IP

Ensuite, ajoutez l'adresse IP CLIENT_LOOPBACK_IP (IP_BOUCLE_CLIENT) en tant que premierserveur DNS sur la ou les machines client.

9.1.1.4 Création du répertoire de données

Les scripts de déploiement peuvent ne pas créer le répertoire de données par défaut deCeph Object Gateway. Créez des répertoires de données pour chaque instance d'un daemonradosgw si ce n'est déjà fait. Les variables host du chier de conguration Ceph déterminentl'hôte qui exécute chaque instance d'un daemon radosgw. Le format type spécie le daemonradosgw, le nom de la grappe et l'ID du daemon.

root # mkdir -p /var/lib/ceph/radosgw/CLUSTER_ID

En utilisant les exemples de paramètres ceph.conf ci-dessus, vous devez exécuter ce qui suit :

root # mkdir -p /var/lib/ceph/radosgw/ceph-radosgw.gateway

9.1.1.5 Redémarrage des services et démarrage de la passerelle

Pour vous assurer que tous les composants ont rechargé leurs congurations, il est recommandéde redémarrer votre service Ceph Storage Cluster. Ensuite, démarrez le service radosgw . Pourplus d'informations, reportez-vous au Manuel « Guide d'administration », Chapitre 4 « Introduction »

et au Manuel « Guide d'administration », Chapitre 17 « Ceph Object Gateway », Section 17.3 « Exploitation

du service Object Gateway ».

112 Configuration d'Object Gateway SES 6

Lorsque le service est en cours d'exécution, vous pouvez eectuer une requête GET anonymepour vérier si la passerelle renvoie une réponse. Une requête HTTP simple au nom de domainedoit renvoyer les éléments suivants :

<ListAllMyBucketsResult> <Owner> <ID>anonymous</ID> <DisplayName/> </Owner> <Buckets/></ListAllMyBucketsResult>

113 Configuration d'Object Gateway SES 6

10 Installation de la passerelle iSCSI

iSCSI est un protocole SAN (sous-réseau de stockage) qui permet aux clients (appelés initiateurs)d'envoyer des commandes SCSI aux périphériques de stockage SCSI (cibles) sur des serveursdistants. SUSE Enterprise Storage 6 comprend une interface qui ouvre la gestion du stockageCeph aux clients hétérogènes, tels que Microsoft  Windows* et VMware*  vSphere, via leprotocole iSCSI. L'accès iSCSI multipath assure la disponibilité et l'évolutivité à ces clients, et leprotocole iSCSI standard fournit également une couche supplémentaire d'isolation de sécuritéentre les clients et la grappe SUSE Enterprise Storage 6. La fonction de conguration est nomméeceph-iscsi . À l'aide de la fonction ceph-iscsi , les administrateurs du stockage Ceph peuventdénir des volumes à allocation dynamique, hautement disponibles et répliqués, prenant encharge les instantanés en lecture seule, les clones en lecture-écriture et le redimensionnementautomatique avec le périphérique de bloc RADOS (RADOS Block Device, RBD) de Ceph. Lesadministrateurs peuvent ensuite exporter des volumes via un seul hôte de passerelle ceph-iscsi ou via plusieurs hôtes de passerelle prenant en charge le basculement multipath. Leshôtes Linux, Microsoft  Windows et VMware peuvent se connecter aux volumes à l'aide duprotocole  iSCSI, ce qui les rend disponibles comme tout autre périphérique de bloc  SCSI.Cela signie que les clients de SUSE  Enterprise  Storage  6 peuvent exécuter ecacementun sous-système d'infrastructure de stockage de blocs complet sur Ceph, qui ore toutes lesfonctionnalités et avantages d'un SAN conventionnel, ce qui permet une croissance future.

Ce chapitre présente des informations détaillées permettant de congurer une infrastructure degrappe Ceph avec une passerelle iSCSI an que les hôtes clients puissent utiliser des donnéesstockées à distance en tant que périphériques de stockage locaux à l'aide du protocole iSCSI.

10.1 Stockage de blocs iSCSIiSCSI est une implémentation de la commande SCSI (Small Computer System Interface) dénieen utilisant le protocole Internet (IP), spécié dans la norme RFC 3720. iSCSI est implémentécomme un service dans lequel un client (initiateur) se connecte à un serveur (cible) via unesession sur le port TCP 3260. L'adresse IP et le port d'une cible iSCSI sont appelés « portail iSCSI »,où une cible peut être exposée via un ou plusieurs portails. La combinaison d'une cible et d'unou de plusieurs portails est appelée le groupe de portails cible (TPG).

114 Stockage de blocs iSCSI SES 6

Le protocole de couche de liaison de données sous-jacent pour iSCSI est généralement Ethernet.Plus spéciquement, les infrastructures iSCSI modernes utilisent des réseaux 10 Gigabit Ethernetou plus rapides pour un débit optimal. Une connectivité 10  Gigabit Ethernet entre lapasserelle iSCSI et la grappe Ceph de l'interface dorsale est fortement recommandée.

10.1.1 Cible iSCSI du kernel Linux

La cible iSCSI du kernel Linux s'appelait à l'origine LIO pour linux-iscsi.org, le domaine et le siteWeb d'origine du projet. Pendant un certain temps, pas moins de quatre implémentations decibles iSCSI concurrentes étaient disponibles pour la plate-forme Linux, mais LIO a nalementprévalu en tant que cible de référence iSCSI unique. Le code du kernel principal de LIO utilisele nom simple, mais quelque peu ambigu « target », en faisant la distinction entre « target core »et une variété de modules cibles d'interface client et d'interface dorsale.

Le module d'interface client le plus couramment utilisé est sans doute iSCSI. Toutefois, LIOprend également en charge Fibre Channel (FC), Fibre Channel sur Ethernet (FCoE) et plusieursautres protocoles d'interface client. Pour l'instant, seul le protocole iSCSI est pris en charge parSUSE Enterprise Storage.

Le module d'interface dorsale cible le plus fréquemment utilisé est celui qui est capable deréexporter simplement n'importe quel périphérique de bloc disponible sur l'hôte cible. Ce moduleest nommé iblock. Cependant, LIO dispose également d'un module d'interface dorsale spéciqueà RBD prenant en charge l'accès E/S multipath parallélisé aux images RBD.

10.1.2 Initiateurs iSCSI

Cette section présente des informations succinctes sur les initiateurs iSCSI utilisés sur les plates-formes Linux, Microsoft Windows et VMware.

10.1.2.1 Linux

L'initiateur standard de la plate-forme Linux est open-iscsi . open-iscsi lance le daemoniscsid , que l'utilisateur peut ensuite utiliser pour découvrir des cibles iSCSI sur n'importe quelportail donné, se connecter à des cibles et assigner des volumes iSCSI. iscsid communique avecla mi couche SCSI pour créer des périphériques de bloc du kernel que ce dernier peut ensuite

115 Cible iSCSI du kernel Linux SES 6

traiter comme n'importe quel autre périphérique de bloc SCSI du système. L'initiateur open-iscsi peut être déployé en association avec l'outil Device Mapper Multipath ( dm-multipath )capable de fournir un périphérique de bloc iSCSI hautement disponible.

10.1.2.2 Microsoft Windows et Hyper-V

L'initiateur  iSCSI par défaut pour le système d'exploitation Microsoft  Windows estl'initiateur iSCSI de Microsoft. Le service iSCSI peut être conguré via une interface graphique(GUI) et prend en charge les E/S multipath pour une haute disponibilité.

10.1.2.3 VMware

L'initiateur  iSCSI par défaut pour VMware  vSphere et ESX est l'initiateur  iSCSI du logicielVMware ESX, vmkiscsi . Lorsque qu'il est activé, il peut être conguré à partir du client vSphereou à l'aide de la commande vmkiscsi-tool . Vous pouvez ensuite formater les volumes destockage connectés via l'adaptateur de disque vSphere iSCSI avec VMFS et les utiliser commetout autre périphérique de stockage VM. L'initiateur VMware prend également en charge les E/S multipath pour une haute disponibilité.

10.2 Informations générales sur ceph-iscsiLa fonction ceph-iscsi associe les avantages des périphériques de bloc RADOS à la polyvalenceomniprésente du protocole iSCSI. En utilisant ceph-iscsi sur un hôte de la cible iSCSI (connusous le nom de passerelle iSCSI), toute application qui a besoin d'utiliser le stockage de blocspeut bénécier de Ceph, même si elle n'utilise pas un protocole de client Ceph. Au lieu decela, les utilisateurs peuvent utiliser le protocole iSCSI ou tout autre protocole d'interface clientcible pour se connecter à une cible LIO, ce qui traduit toutes les E/S cibles en opérations destockage RBD.

116 Informations générales sur ceph-iscsi SES 6

FIGURE 10.1T : GRAPPE CEPH AVEC UNE PASSERELLE ISCSI UNIQUE

ceph-iscsi est intrinsèquement hautement disponible et prend en charge les opérationsmultipath. Ainsi, les hôtes initiateurs en aval peuvent utiliser plusieurs passerelles iSCSI pour lahaute disponibilité et l'évolutivité. Lors de la communication avec une conguration iSCSI avecplus d'une passerelle, les initiateurs peuvent équilibrer la charge des requêtes iSCSI sur plusieurspasserelles. En cas d'échec d'une passerelle, d'inaccessibilité temporaire ou de désactivation pourmaintenance, les E/S continuent de manière transparente via une autre passerelle.

FIGURE 10.2T : GRAPPE CEPH AVEC PLUSIEURS PASSERELLES ISCSI

117 Informations générales sur ceph-iscsi SES 6

10.3 Considérations sur le déploiementUne conguration minimale de SUSE  Enterprise  Storage  6 avec ceph-iscsi comprend lescomposants suivants :

Une grappe de stockage Ceph. La grappe Ceph consiste en un minimum de quatre serveursphysiques hébergeant au moins huit daemons de stockage des objets (Object StorageDaemon, OSD) chacun. Dans une telle conguration, les trois noeuds  OSD doublentégalement en tant qu'hôte Monitor (MON).

Un serveur cible iSCSI exécutant la cible iSCSI LIO, congurée via ceph-iscsi .

Un hôte initiateur  iSCSI, exécutant open-iscsi (Linux), l'initiateur Microsoft  iSCSI(Microsoft Windows) ou toute autre implémentation d'initiateur iSCSI compatible.

La conguration recommandée en production pour SUSE Enterprise Storage 6 avec ceph-iscsiest constituée des éléments suivants :

Une grappe de stockage Ceph. Une grappe Ceph de production est constituée de n'importequel nombre de noeuds OSD (généralement plus de 10), chacun exécutant généralement10 à 12 OSD, avec pas moins de trois hôtes MON dédiés.

Plusieurs serveurs cibles iSCSI exécutant la cible iSCSI LIO, congurés via ceph-iscsi .Pour une reprise après échec et un équilibrage de charge  iSCSI, ces serveurs doiventexécuter un kernel prenant en charge le module target_core_rbd . Des paquetages demise à jour sont disponibles à partir du canal de maintenance SUSE Linux Enterprise Server.

N'importe quel nombre d'hôtes initiateurs iSCSI exécutant open-iscsi (Linux), l'initiateurMicrosoft  iSCSI (Microsoft  Windows) ou toute autre implémentation d'initiateur  iSCSIcompatible.

10.4 Installation et configurationCette section décrit les étapes d'installation et de conguration d'une passerelle iSCSI en plusde SUSE Enterprise Storage.

118 Considérations sur le déploiement SES 6

10.4.1 Déploiement de la passerelle iSCSI sur une grappe Ceph

Vous pouvez déployer la passerelle iSCSI au cours du processus de déploiement de la grappeCeph ou l'ajouter à une grappe existante à l'aide de DeepSea.

Pour inclure la passerelle iSCSI au cours du processus de déploiement de la grappe, reportez-vous à la Section 5.5.1.2, « Assignation de rôle ».

Pour ajouter la passerelle  iSCSI à une grappe existante, reportez-vous au Manuel «  Guide

d'administration », Chapitre 2 « Administration de grappe Salt », Section 2.2 « Ajout de nouveaux rôles

à des noeuds ».

10.4.2 Création d'images RBD

Les images RBD sont créées dans la zone de stockage Ceph et ensuite exportées vers iSCSI. Ilest recommandé d'utiliser une réserve RADOS dédiée à cette n. Vous pouvez créer un volumeà partir de n'importe quel hôte pouvant se connecter à votre grappe de stockage à l'aide del'utilitaire de ligne de commande Ceph rbd . Pour cela, le client doit avoir au moins un chierde conguration ceph.conf minimal et les informations d'identication d'authentication CephXappropriées.

Pour créer un volume pour l'exportation ultérieure via iSCSI, utilisez la commande rbd createen spéciant la taille du volume en mégaoctets. Par exemple, pour créer un volume de 100 Gonommé « testvol » dans la réserve intitulée « iscsi-images », exécutez la commande suivante :

cephadm@adm > rbd --pool iscsi-images create --size=102400 'testvol'

10.4.3 Exportation d'images RBD via iSCSI

Pour exporter des images RBD via iSCSI, vous pouvez utiliser l'interface Web Ceph Dashboard oul'utilitaire gwcli ceph-iscsi . Dans cette section, nous nous concentrons sur gwcli uniquementet indiquons comment créer une cible iSCSI qui exporte une image RBD à l'aide de la ligne decommande.

RemarqueSeules les fonctions d'image RBD suivantes sont prises en charge : layering , striping(v2) , exclusive-lock , fast-diff et data-pool . Les images RBD pour lesquellesd'autres fonctions sont activées ne peuvent pas être exportées.

119 Déploiement de la passerelle iSCSI sur une grappe Ceph SES 6

En tant qu'utilisateur root , démarrez l'interface de ligne de commande de la passerelle iSCSI :

root # gwcli

Accédez à iscsi-targets et créez une cible nommée iqn.2003-01.org.linux-

iscsi.iscsi.x86:testvol  :

gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> create iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol

Créez les passerelles iSCSI en spéciant le nom de la passerelle ( name ) et l'adresse IP ( ip ) :

gwcli > /iscsi-targets> cd iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/gatewaysgwcli > /iscsi-target...tvol/gateways> create iscsi1 192.168.124.104gwcli > /iscsi-target...tvol/gateways> create iscsi2 192.168.124.105

AstuceUtilisez la commande help pour acher la liste des commandes disponibles sur le noeudde conguration actuel.

Ajoutez l'image RBD avec le nom « testvol » dans la réserve « iscsi-images » :

gwcli > /iscsi-target...tvol/gateways> cd /disksgwcli > /disks> attach iscsi-images/testvol

Assignez l'image RBD à la cible :

gwcli > /disks> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/disksgwcli > /iscsi-target...testvol/disks> add iscsi-images/testvol

RemarqueVous pouvez utiliser des outils de niveau inférieur, tels que targetcli , pour interrogerla conguration locale, mais pas pour la modier.

AstuceVous pouvez utiliser la commande ls pour examiner la conguration. Certains noeudsde conguration prennent également en charge la commande info , qui permet d'acherdes informations plus détaillées.

120 Exportation d'images RBD via iSCSI SES 6

Notez que, par défaut, l'authentication ACL est activée de sorte que cette cible n'est pasencore accessible. Reportez-vous à la Section 10.4.4, « Authentification et contrôle d'accès » pour plusd'informations sur l'authentication et le contrôle d'accès.

10.4.4 Authentification et contrôle d'accès

L'authentication iSCSI est exible et couvre de nombreuses possibilités d'authentication.

10.4.4.1 Pas d'authentification

«  No Authentication  » (Pas d'authentication) signie que tout initiateur sera en mesured'accéder à n'importe quelle unité logique sur la cible correspondante. Vous pouvez activerl'option « No authentication » en désactivant l'authentication ACL :

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> auth disable_acl

10.4.4.2 Authentification ACL

Lors de l'utilisation de l'authentication ACL basée sur le nom de l'initiateur, seuls les initiateursdénis sont autorisés à se connecter. Vous pouvez dénir un initiateur comme suit :

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hostsgwcli > /iscsi-target...testvol/hosts> create iqn.1996-04.de.suse:01:e6ca28cc9f20

Les initiateurs dénis pourront se connecter, mais n'auront accès qu'aux images RBD qui leuront été explicitement ajoutées :

gwcli > /iscsi-target...:e6ca28cc9f20> disk add rbd/testvol

10.4.4.3 Authentification CHAP

En plus de l'ACL, vous pouvez activer l'authentication CHAP en spéciant un nom d'utilisateuret un mot de passe pour chaque initiateur :

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvol/hosts/iqn.1996-04.de.suse:01:e6ca28cc9f20gwcli > /iscsi-target...:e6ca28cc9f20> auth username=common12 password=pass12345678

121 Authentification et contrôle d'accès SES 6

RemarqueLes noms d'utilisateur doivent comporter entre 8 et 64 caractères, et ne peuvent contenirque des lettres et les signes « . », « @ », « - », « _ » et « : ».

Les mots de passe doivent comporter entre 12 et 16 caractères, et ne peuvent contenirque des lettres et les signes « @ », « - », « _ » et « / ».

Éventuellement, vous pouvez aussi activer l'authentication mutuelle CHAP en spéciant lesparamètres mutual_username et mutual_password dans la commande auth .

10.4.4.4 Découverte et authentification mutuelle

L'authentication de la découverte est indépendante des méthodes d'authentication précédentes.Elle nécessite des informations d'identication pour la navigation, est facultative et peut êtrecongurée comme suit :

gwcli > /> cd /iscsi-targetsgwcli > /iscsi-targets> discovery_auth username=du123456 password=dp1234567890

RemarqueLes noms d'utilisateur doivent comporter entre 8 et 64 caractères, et ne peuvent contenirque des lettres et les signes « . », « @ », « - », « _ » et « : ».

Les mots de passe doivent comporter entre 12 et 16 caractères, et ne peuvent contenirque des lettres et les signes « @ », « - », « _ » et « / ».

Éventuellement, vous pouvez aussi spécier les paramètres mutual_username etmutual_password dans la commande discovery_auth .

L'authentication de découverte peut être désactivée à l'aide de la commande suivante :

gwcli > /iscsi-targets> discovery_auth nochap

10.4.5 Paramètres avancés

ceph-iscsi peut être conguré avec des paramètres avancés qui sont ensuite transmis à lacible des E/S LIO. Les paramètres sont divisés en paramètres « target » (cible) et « disk » (disque).

122 Paramètres avancés SES 6

AvertissementSauf indication contraire, il est déconseillé de modier ces paramètres par rapport à leurvaleur par défaut.

10.4.5.1 Paramètres de cible

Vous pouvez acher la valeur de ces paramètres à l'aide de la commande info  :

gwcli > /> cd /iscsi-targets/iqn.2003-01.org.linux-iscsi.iscsi.x86:testvolgwcli > /iscsi-target...i.x86:testvol> info

Vous pouvez modier un paramètre à l'aide de la commande reconfigure  :

gwcli > /iscsi-target...i.x86:testvol> reconfigure login_timeout 20

Les paramètres « target » disponibles sont les suivants :

default_cmdsn_depth

Profondeur de CmdSN (numéro de séquence de commande) par défaut. Limite le nombrede requêtes qu'un initiateur iSCSI peut avoir en attente à tout moment.

default_erl

Niveau de la récupération d'erreur par défaut.

login_timeout

Valeur de timeout de connexion en secondes.

netif_timeout

Timeout d'échec de la carte d'interface réseau en secondes.

prod_mode_write_protect

Si dénie sur 1, empêche les écritures sur les LUN (numéros d'unité logique).

10.4.5.2 Paramètres de disque

Vous pouvez acher la valeur de ces paramètres à l'aide de la commande info  :

gwcli > /> cd /disks/rbd/testvolgwcli > /disks/rbd/testvol> info

123 Paramètres avancés SES 6

Vous pouvez modier un paramètre à l'aide de la commande reconfigure  :

gwcli > /disks/rbd/testvol> reconfigure rbd/testvol emulate_pr 0

Les paramètres « disk » disponibles sont les suivants :

block_size

Taille du bloc du périphérique sous-jacent.

emulate_3pc

Si dénie sur 1, active l'option Third Party Copy (Copie tierce).

emulate_caw

Si dénie sur 1, active l'option Compare and Write (Comparer et écrire).

emulate_dpo

Si dénie sur 1, active l'option Disable Page Out (Désactiver la sortie de page).

emulate_fua_read

Si dénie sur 1, active la lecture pour l'option Force Unit Access (Forcer l'accès aux unités).

emulate_fua_write

Si dénie sur 1, active l'écriture pour l'option Force Unit Access (Forcer l'accès aux unités).

emulate_model_alias

Si dénie sur 1, utilise le nom du périphérique d'interface dorsale pour l'alias du modèle.

emulate_pr

Si dénie sur 0, la prise en charge des réservations SCSI, y compris les réservations degroupe persistantes, est désactivée. La passerelle iSCSI SES peut alors ignorer l'état deréservation, ce qui améliore la latence des requêtes.

AstuceIl est recommandé de dénir backstore_emulate_pr sur 0 si les initiateurs iSCSI n'ontpas besoin de la prise en charge des réservations SCSI.

emulate_rest_reord

Si dénie sur 0, le modicateur d'algorithme de le d'attente comporte une réorganisationrestreinte.

emulate_tas

124 Paramètres avancés SES 6

Si dénie sur 1, active l'option Task Aborted Status (État Tâche abandonnée).

emulate_tpu

Si dénie sur 1, active l'option Thin Provisioning Unmap (Annulation d'assignation duprovisioning léger).

emulate_tpws

Si dénie sur 1, active l'option Thin Provisioning Write Same (Écriture identiqueprovisioning léger).

emulate_ua_intlck_ctrl

Si dénie sur 1, active l'option Unit Attention Interlock (Interverrouillage attention unité).

emulate_write_cache

Si dénie sur 1, active l'option Write Cache Enable (Écriture sur le cache activée).

enforce_pr_isids

Si dénie sur 1, applique les ISID de réservation persistante.

is_nonrot

Si dénie sur 1, le backstore est un périphérique non rotationnel.

max_unmap_block_desc_count

Nombre maximal de descripteurs de bloc pour UNMAP (Annuler l'assignation).

max_unmap_lba_count:

Nombre maximal de LBA pour UNMAP (Annuler l'assignation).

max_write_same_len

Longueur maximale pour WRITE_SAME (Écriture identique).

optimal_sectors

Taille de la requête optimale dans les secteurs.

pi_prot_type

Type de protection DIF.

queue_depth

Profondeur de la le d'attente.

unmap_granularity

Granularité UNMAP (Annuler l'assignation).

unmap_granularity_alignment

125 Paramètres avancés SES 6

Alignement de la granularité UNMAP (Annuler l'assignation).

force_pr_aptpl

Si activée, LIO écrira toujours l'état de réservation persistante (persistent reservation) dansle stockage persistant, que le client l'ait demandé ou non via aptpl=1 . Cela n'a aucuneet avec l'interface dorsale RBD de kernel pour LIO, qui conserve toujours l'état PR.Idéalement, l'option target_core_rbd devrait imposer la valeur « 1  » et générer uneerreur si quelqu'un tente de la désactiver via congfs.

unmap_zeroes_data

Détermine si LIO annoncera LBPRZ aux initiateurs SCSI, indiquant que les zéros serontrelus à partir d'une région suivant UNMAP ou WRITE SAME avec un bit d'annulationd'assignation (« unmap »).

10.5 Exportation d'images de périphérique de blocRADOS à l'aide de tcmu-runnerceph-iscsi prend en charge les backstores rbd (basé sur le kernel) et user:rbd (tcmu-runner), ce qui rend toute la gestion transparente et indépendante du backstore.

Avertissement : aperçu de la technologieLes déploiements de passerelles iSCSI basés sur tcmu-runner représentent actuellementun aperçu de la technologie.

Contrairement aux déploiements de passerelles iSCSI basés sur le kernel, les passerelles iSCSIbasées sur tcmu-runner ne prennent pas en charge les E/S multipath ou les réservationspersistantes SCSI.

Pour exporter une image RBD à l'aide de tcmu-runner , vous devez juste spécier le backstoreuser:rbd lorsque vous attachez le disque :

gwcli > /disks> attach rbd/testvol backstore=user:rbd

RemarqueLors de l'utilisation de tcmu-runner , l'image RBD exportée doit avoir la fonctionexclusive-lock activée.

126 Exportation d'images de périphérique de bloc RADOS à l'aide de tcmu-runner SES 6

11 Installation de CephFS

Le système de chiers de Ceph (CephFS) est un système de chiers compatible POSIX qui utiliseune grappe de stockage Ceph pour stocker ses données. CephFS utilise le même système degrappe que les périphériques de bloc Ceph, que le stockage des objets Ceph avec ses API S3 etSwift ou que les liaisons natives ( librados ).

Pour utiliser CephFS, vous devez disposer d'une grappe de stockage Ceph en cours d'exécutionet d'au moins un serveur de métadonnées Ceph (Ceph Metadata Server) en cours d'exécution.

11.1 Scénarios CephFS pris en charge et conseilsAvec SUSE  Enterprise  Storage  6, SUSE introduit la prise en charge ocielle de nombreuxscénarios dans lesquels le composant évolutif et distribué CephFS est utilisé. Cette rubriquedécrit les limites xes et fournit des conseils pour les cas d'utilisation suggérés.

Un déploiement de CephFS pris en charge doit répondre aux conditions requises suivantes :

Un minimum d'un serveur de métadonnées (MDS). SUSE recommande de déployerplusieurs noeuds avec le rôle MDS. Un seul sera active (actif) et les autres serontpassive (passif). N'oubliez pas de mentionner tous les noeuds MON dans la commandemount lors du montage de CephFS à partir d'un client.

Les clients sont des instances SUSE Linux Enterprise Server 12 SP3 ou version ultérieure,ou SUSE Linux Enterprise Server 15 ou version ultérieure, qui utilisent le pilote du modulede kernel cephfs . Le module FUSE n'est pas pris en charge.

Les quotas CephFS sont pris en charge dans SUSE Enterprise Storage  6 et peuventêtre dénis sur n'importe quel sous-répertoire du système de chiers Ceph. Le quotalimite le nombre d' octets ou de fichiers stockés sous le point spécié dans lahiérarchie de répertoires. Pour plus d'informations, reportez-vous à la section Manuel

« Guide d'administration », Chapitre 19 « Système de fichiers en grappe », Section 19.6 « Définition

des quotas CephFS ».

127 Scénarios CephFS pris en charge et conseils SES 6

CephFS prend en charge les modications de disposition de chier comme expliqué à laSection 11.3.4, « Disposition des fichiers ». Toutefois, alors que le système de chiers est montépar n'importe quel client, de nouvelles réserves de données ne peuvent pas être ajoutéesà un système de chiers CephFS existant ( ceph mds add_data_pool ). Elles peuvent êtreajoutées uniquement lorsque le système de chiers est démonté.

Un minimum d'un serveur de métadonnées (MDS). SUSE recommande de déployerplusieurs noeuds avec le rôle MDS. Par défaut, d'autres daemons MDS démarrent commedaemons en veille , faisant oce de sauvegardes pour le MDS actif. Plusieurs daemonsMDS actifs sont également pris en charge (voir Section 11.3.2, « Taille de la grappe du MDS »).

11.2 Serveur de métadonnées CephLe serveur de métadonnées (MDS) Ceph stocke des métadonnées pour CephFS. Les périphériquesde bloc Ceph et le stockage des objets Ceph n'utilisent pas le MDS. Les MDS permettent auxutilisateurs du système de chiers POSIX d'exécuter des commandes de base, telles que ls oufind , sans imposer une charge importante sur la grappe de stockage Ceph.

11.2.1 Ajout d'un serveur de métadonnées

Vous pouvez déployer le MDS pendant le processus de déploiement de la grappe initial commedécrit à la Section 5.3, « Déploiement de la grappe », ou l'ajouter à une grappe déjà déployée commedécrit dans le Manuel « Guide d'administration », Chapitre 2 « Administration de grappe Salt », Section 2.1

« Ajout de nouveaux noeuds à la grappe ».

Après avoir déployé votre MDS, autorisez le service Ceph  OSD/MDS dans les paramètres depare-feu du serveur sur lequel le MDS est déployé  : démarrez yast , accédez à Security andUsers Firewall Allowed Services (Sécurité et utilisateurs > Pare-feu > Services autorisés), puisdans le menu déroulant Service to Allow (Service à autoriser), sélectionnez Ceph OSD/MDS. Sile trac complet n'est pas autorisé sur le noeud Ceph MDS, le montage d'un système de chierséchoue, même si d'autres opérations peuvent fonctionner correctement.

11.2.2 Configuration d'un serveur de métadonnées

Vous pouvez aner le comportement du MDS en insérant les options appropriées dans le chierde conguration ceph.conf .

128 Serveur de métadonnées Ceph SES 6

PARAMÈTRES DU SERVEUR DE MÉTADONNÉES

mon force standby active

Si ce paramètre est déni sur « true » (valeur par défaut), les moniteurs forcent l'activationde l'état de secours avec relecture. Il est conguré sous les sections [mon] ou [global] .

mds cache memory limit

Limite de mémoire logique (en octets) que le MDS applique à son cache. Lesadministrateurs doivent l'utiliser à la place de l'ancien paramètre mds cache size . Lavaleur par défaut est de 1 Go.

mds cache reservation

Réservation du cache (mémoire ou inodes) que le cache du MDS gère. Lorsque le MDScommence à atteindre sa réservation, il rappelle l'état du client jusqu'à ce que sa taille decache diminue pour restaurer la réservation. La valeur par défaut est 0,05.

mds cache size

Nombre d'inodes à mettre en cache. 0 (valeur par défaut) indique un nombre illimité. Il estrecommandé d'utiliser le paramètre mds cache memory limit pour limiter la quantitéde mémoire employée par le cache MDS.

mds cache mi

Point d'insertion pour les nouveaux éléments dans l'algorithme LRU du cache (à partir duhaut). La valeur par défaut est 0,7.

mds dir commit ratio

Fraction du répertoire devant être altérée avant que Ceph valide le recours à une mise àjour complète au lieu d'une mise à jour partielle. La valeur par défaut est 0,5.

mds dir max commit size

Taille maximale d'une mise à jour de répertoire avant que Ceph la divise en transactionsplus petites. La valeur par défaut est 90 Mo.

mds decay halflife

Demi-vie de la température du cache MDS. La valeur par défaut est 5.

mds beacon interval

Fréquence en secondes des messages de signal envoyés au moniteur. La valeur par défautest 4.

mds beacon grace

129 Configuration d'un serveur de métadonnées SES 6

Délai sans signal avant que Ceph déclare un MDS comme étant lent à réagir (« laggy ») etle remplace éventuellement. La valeur par défaut est 15.

mds blacklist interval

Durée dans la liste noire pour les MDS ayant échoué dans l'assignation OSD. Ce paramètrecontrôle le temps durant lequel les daemons MDS ayant échoué restent dans la liste noirede l'assignation OSD. Il n'a aucun eet sur le délai qu'un élément reste dans la liste noirelorsque c'est l'administrateur qui l'y a mis manuellement. Par exemple, la commande cephosd blacklist add continue d'utiliser le délai par défaut de maintien dans la liste noire.La valeur par défaut est 24 * 60.

mds reconnect timeout

Délai d'attente en secondes pour la reconnexion des clients en cas de redémarrage du MDS.La valeur par défaut est 45.

mds tick interval

Fréquence à laquelle le MDS eectue les tâches périodiques internes. La valeur par défautest 5.

mds dirstat min interval

Intervalle minimal en secondes pour essayer d'éviter de propager de manière ascendantedes statistiques récursives dans l'arborescence. La valeur par défaut est 1.

mds scatter nudge interval

Rapidité avec laquelle les changements de dirstat se propagent de manière ascendante. Lavaleur par défaut est 5.

mds client prealloc inos

Nombre de numéros d'inode à préaecter par session client. La valeur par défaut est 1000.

mds early reply

Détermine si le MDS doit permettre aux clients de consulter les résultats de requête avantleur validation dans le journal. La valeur par défaut est « true ».

mds use tmap

Permet d'utiliser l'assignation générique pour les mises à jour de répertoire. La valeur pardéfaut est « true ».

mds default dir hash

Fonction à utiliser pour hacher les chiers sur diérents fragments de répertoire. La valeurpar défaut est 2 (c'est-à-dire « rjenkins »).

130 Configuration d'un serveur de métadonnées SES 6

mds log skip corrupt events

Détermine si le MDS doit essayer d'ignorer les événements de journal corrompus pendantla relecture du journal. La valeur par défaut est « false ».

mds log max events

Nombre maximal d'événements dans le journal avant l'initiation du troncage. Dénir ceparamètre sur -1 (valeur par défaut) permet de désactiver les limites.

mds log max segments

Nombre maximal de segments (objets) dans le journal avant l'initiation du troncage. Dénirce paramètre sur -1 permet de désactiver les limites. La valeur par défaut est 30.

mds log max expiring

Nombre maximal de segments à faire expirer en parallèle. La valeur par défaut est 20.

mds log eopen size

Nombre maximal d'inodes dans un événement Eopen. La valeur par défaut est 100.

mds bal sample interval

Détermine la fréquence de l'échantillonnage de la température de répertoire pour lesdécisions de fragmentation. La valeur par défaut est 3.

mds bal replicate threshold

Température maximale avant que Ceph tente de répliquer les métadonnées sur d'autresnoeuds. La valeur par défaut est 8000.

mds bal unreplicate threshold

Température minimale avant que Ceph cesse de répliquer les métadonnées sur d'autresnoeuds. La valeur par défaut est 0.

mds bal split size

Taille maximale du répertoire avant le MDS divise un fragment de répertoire en bits pluspetits. La valeur par défaut est 10000.

mds bal split rd

Température de lecture de répertoire maximale avant que Ceph divise un fragment derépertoire. La valeur par défaut est 25000.

mds bal split wr

Température d'écriture de répertoire maximale avant que Ceph divise un fragment derépertoire. La valeur par défaut est 10000.

131 Configuration d'un serveur de métadonnées SES 6

mds bal split bits

Nombre de bits pour diviser un fragment de répertoire. La valeur par défaut est 3.

mds bal merge size

Taille minimale de répertoire avant que Ceph tente de fusionner les fragments de répertoireadjacents. La valeur par défaut est 50.

mds bal interval

Fréquence en secondes d'échanges de workload entre les MDS. La valeur par défaut est 10.

mds bal fragment interval

Délai en secondes entre le moment auquel un fragment peut être divisé ou fusionné, etl'exécution du changement de fragmentation. La valeur par défaut est 5.

mds bal fragment fast factor

Rapport selon lequel les fragments peuvent dépasser la taille de fractionnement avantqu'une scission soit exécutée immédiatement, en ignorant l'intervalle de fragmentation. Lavaleur par défaut est 1.5.

mds bal fragment size max

Taille maximale d'un fragment avant que toute nouvelle entrée soit rejetée avec une erreurENOSPC. La valeur par défaut est 100000.

mds bal idle threshold

Température minimale avant que Ceph migre une sous-arborescence vers son parent. Lavaleur par défaut est 0.

mds bal mode

Méthode de calcul de la charge MDS :

0 = Hybride.

1 = Taux de requêtes et latence.

2 = Charge du processeur.

La valeur par défaut est 0.

mds bal min rebalance

Température minimale de la sous-arborescence avant que Ceph eectue une migration. Lavaleur par défaut est 0,1.

mds bal min start

132 Configuration d'un serveur de métadonnées SES 6

Température minimale de la sous-arborescence avant que Ceph eectue une recherche desous-arborescence. La valeur par défaut est 0,2.

mds bal need min

Fraction minimale de la taille de la sous-arborescence cible pour accepter. La valeur pardéfaut est 0,8.

mds bal need max

Fraction maximale de la taille de la sous-arborescence cible pour accepter. La valeur pardéfaut est 1,2.

mds bal midchunk

Ceph migrera n'importe quelle sous-arborescence qui est supérieure à cette fraction de lataille de la sous-arborescence cible. La valeur par défaut est 0.3.

mds bal minchunk

Ceph ignorera n'importe quelle sous-arborescence qui est inférieure à cette fraction de lataille de la sous-arborescence cible. La valeur par défaut est 0,001.

mds bal target removal min

Nombre minimal d'itérations d'équilibreur avant que Ceph supprime une ancienne cibleMDS de l'assignation MDS. La valeur par défaut est 5.

mds bal target removal max

Nombre maximal d'itérations d'équilibreur avant que Ceph supprime une ancienne cibleMDS de l'assignation MDS. La valeur par défaut est 10.

mds replay interval

Intervalle d'interrogation du journal en mode de secours avec relecture (« hot standby »).La valeur par défaut est 1.

mds shutdown check

Intervalle d'interrogation du cache pendant l'arrêt du MDS. La valeur par défaut est 0.

mds thrash fragments

Permet à Ceph de fragmenter ou de fusionner des répertoires de manière aléatoire. Lavaleur par défaut est 0.

mds dump cache on map

Permet à Ceph de vider le contenu du cache MDS dans un chier sur chaque assignationMDS. La valeur par défaut est « false ».

133 Configuration d'un serveur de métadonnées SES 6

mds dump cache after rejoin

Permet à Ceph de vider le contenu du cache MDS dans un chier après avoir rejoint lecache pendant la récupération. La valeur par défaut est « false ».

mds standby for name

Permet à un daemon MDS de servir de solution de secours pour un autre daemon MDSdont le nom est spécié dans ce paramètre.

mds standby for rank

Permet à un daemon MDS de servir de solution de secours pour un daemon MDS dont lerang est spécié dans ce paramètre. La valeur par défaut est -1.

mds standby replay

Détermine si un daemon Ceph MDS doit interroger et relire le journal d'un MDS actif (« hotstandby »). La valeur par défaut est « false ».

mds min caps per client

Dénit le nombre minimal de fonctionnalités qu'un client peut détenir. La valeur par défautest 100.

mds max ratio caps per client

Dénit le rapport maximal de fonctionnalités actuelles pouvant être rappelées en cas depression sur le cache MDS. La valeur par défaut est 0,8.

PARAMÈTRES DE L'OUTIL DE JOURNALISATION DU SERVEUR DE MÉTADONNÉES

journaler write head interval

Fréquence de mise à jour de l'objet principal du journal. La valeur par défaut est 15.

journaler prefetch periods

Nombre de périodes de segment à lire à l'avance en cas de relecture du journal. La valeurpar défaut est 10.

journal prezero periods

Nombre de périodes de segment à mettre à zéro avant la position d'écriture. La valeur pardéfaut est 10.

journaler batch interval

Latence supplémentaire maximale en secondes subie articiellement. La valeur par défautest 0,001.

journaler batch max

Nombre maximal d'octets selon lequel le vidage est diéré. La valeur par défaut est 0.

134 Configuration d'un serveur de métadonnées SES 6

11.3 CephFSLorsque vous disposez d'une grappe de stockage Ceph saine avec au moins un serveur demétadonnées Ceph, vous pouvez créer et monter le système de chiers Ceph. Assurez-vous quevotre client dispose d'une connectivité réseau et d'un porte-clés d'authentication approprié.

11.3.1 Création de CephFS

CephFS nécessite au moins deux réserves RADOS  : une pour les données et l'autre pour lesmétadonnées. Lorsque vous congurez ces réserves, vous pouvez envisager :

L'utilisation d'un niveau de réplication supérieur pour la réserve de métadonnées, cartoute perte de données dans cette réserve peut rendre l'ensemble du système de chiersinaccessible.

L'utilisation d'un stockage à faible latence, tel que des disques  SSD pour la réserve demétadonnées, car cela améliore la latence observée des opérations du système de chierssur les clients.

Lorsque vous assignez un role-mds dans le chier policy.cfg , les réserves requises sontautomatiquement créées. Vous pouvez créer manuellement les réserves cephfs_data etcephfs_metadata pour l'optimisation manuelle des performances avant la conguration duserveur de métadonnées. DeepSea ne crée pas ces réserves si elles existent déjà.

Pour plus d'informations sur la gestion des réserves, reportez-vous au Manuel «  Guide

d'administration », Chapitre 11 « Gestion des réserves de stockage ».

Pour créer les deux réserves requises (par exemple, cephfs_data et cephfs_metadata) avec lesparamètres par défaut à utiliser avec CephFS, exécutez les commandes suivantes :

cephadm@adm > ceph osd pool create cephfs_data pg_numcephadm@adm > ceph osd pool create cephfs_metadata pg_num

Il est possible d'utiliser des réserves EC au lieu des réserves répliquées. Il est recommandé den'utiliser les réserves EC que pour les exigences de performances faibles et les accès aléatoirespeu fréquents, tels que le stockage à froid, les sauvegardes et l'archivage. CephFS sur lesréserves EC nécessite l'activation de BlueStore et l'option allow_ec_overwrite doit être déniepour la réserve. Cette option peut être dénie en exécutant ceph osd pool set ec_poolallow_ec_overwrites true .

135 CephFS SES 6

Le codage à eacement ajoute un overhead considérable aux opérations du système de chiers,notamment aux petites mises à jour. Cet overhead est inhérent à l'utilisation du codage àeacement en tant que mécanisme de tolérance aux pannes. Cette restriction est le compromispermettant de réduire considérablement l'overhead de l'espace de stockage.

Lorsque les réserves sont créées, vous pouvez activer le système de chiers avec la commandeceph fs new  :

cephadm@adm > ceph fs new fs_name metadata_pool_name data_pool_name

Par exemple :

cephadm@adm > ceph fs new cephfs cephfs_metadata cephfs_data

Vous pouvez vérier que le système de chiers a été créé en répertoriant tous les CephFSdisponibles :

cephadm@adm > ceph fs ls name: cephfs, metadata pool: cephfs_metadata, data pools: [cephfs_data ]

Lorsque le système de chiers est créé, votre MDS peut basculer à l'état actif. Par exemple, dansun système MDS unique :

cephadm@adm > ceph mds state5: 1/1/1 up

Astuce : plus de rubriquesVous pouvez trouver plus d'informations sur des tâches spéciques, par exemple lemontage, le démontage et la conguration avancée de CephFS dans le Manuel « Guide

d'administration », Chapitre 19 « Système de fichiers en grappe ».

11.3.2 Taille de la grappe du MDS

Une instance CephFS peut être desservie par plusieurs daemons  MDS actifs. Tous lesdaemons MDS actifs assignés à une instance CephFS se partagent l'arborescence de répertoires dusystème de chiers entre eux et répartissent ainsi la charge des clients simultanés. Pour pouvoirajouter un daemon MDS actif à une instance CephFS, une mise en veille est nécessaire. Lancezun daemon supplémentaire ou utilisez une instance existante de mise en veille.

La commande suivante ache le nombre actuel de daemons MDS actifs et passifs.

136 Taille de la grappe du MDS SES 6

cephadm@adm > ceph mds stat

La commande suivante dénit le nombre de MDS actifs sur deux dans une instance de systèmede chiers.

cephadm@adm > ceph fs set fs_name max_mds 2

An de réduire la grappe MDS avant une mise à jour, deux étapes sont nécessaires. Tout d'abord,dénissez max_mds pour qu'il ne reste qu'une seule instance :

cephadm@adm > ceph fs set fs_name max_mds 1

Ensuite, désactivez explicitement les autres daemons MDS actifs :

cephadm@adm > ceph mds deactivate fs_name:rank

où rank est le numéro d'un daemon MDS actif d'une instance de système de chiers, allant de0 à max_mds -1.

Nous recommandons de laisser au moins un MDS comme un daemon de secours.

11.3.3 Grappe du MDS et mises à jour

Au cours des mises à jour de Ceph, les drapeaux de fonction sur une instance de systèmede chiers peuvent changer (généralement en ajoutant de nouvelles fonctions). Les daemonsincompatibles (par exemple, les versions antérieures) ne sont pas en mesure de fonctionner avecun jeu de fonctions incompatibles et refusent de démarrer. Cela signie que la mise à jour et leredémarrage d'un daemon peuvent entraîner l'arrêt de tous les autres daemons non encore misà jour et leur refus de démarrer. Pour cette raison, il est recommandé de réduire la grappe duMDS actif à une seule instance et d'arrêter tous les daemons de secours avant de mettre à jourCeph. Les étapes manuelles de cette procédure de mise à jour sont les suivantes :

1. Mettez à jour les paquetages liés à Ceph à l'aide de la commande zypper .

2. Réduisez la grappe MDS active comme décrit ci-dessus à une seule instance et arrêtez tousles daemons MDS de secours en utilisant leurs unités systemd sur tous les autres noeuds :

cephadm@mds > systemctl stop ceph-mds\*.service ceph-mds.target

3. Ensuite, redémarrez le seul daemon MDS restant, en le faisant redémarrer à l'aide duchier binaire mis à jour.

137 Grappe du MDS et mises à jour SES 6

cephadm@mds > systemctl restart ceph-mds\*.service ceph-mds.target

4. Redémarrez tous les autres daemons MDS et redénissez le paramètre max_mds souhaité.

cephadm@mds > systemctl start ceph-mds.target

Si vous utilisez DeepSea, ce dernier suit cette procédure dans les cas où le paquetage ceph a étémis à jour au cours des phases 0 et 4. Il est possible d'eectuer cette procédure alors que l'instanceCephFS est montée sur des clients et que les E/S sont en cours d'exécution. Notez toutefois qu'ily aura une pause d'E/S très brève pendant le redémarrage du MDS actif. La récupération desclients s'eectue automatiquement.

Il est recommandé de réduire la charge d'E/S autant que possible avant de mettre à jour unegrappe du MDS. Une grappe du MDS inactive sera soumise à cette procédure de mise à jourplus rapidement. À l'inverse, sur une grappe fortement chargée avec plusieurs daemons MDS, ilest essentiel de réduire la charge à l'avance pour éviter qu'un seul daemon MDS soit submergépar les E/S en cours.

11.3.4 Disposition des fichiers

La disposition d'un chier contrôle la façon dont son contenu est assigné aux objets Ceph RADOS.Vous pouvez lire et écrire la disposition d'un chier à l'aide des attributs étendus virtuels (abrégésen xattrs).

Le nom de ces attributs de disposition varie selon qu'il s'agit d'un chier normal ou d'unrépertoire. Les attributs étendus virtuels de disposition des chiers normaux se nommentceph.file.layout , tandis que ceux des répertoires s'appellent ceph.dir.layout . Dans lesexemples se référant à ceph.file.layout , pensez à remplacer la partie .dir. de manièreappropriée lorsque vous travaillez avec des répertoires.

11.3.4.1 Champs de disposition

Les champs d'attributs suivants sont reconnus :

pool

ID ou nom d'une réserve RADOS dans laquelle les objets de données d'un chier serontstockés.

pool_namespace

138 Disposition des fichiers SES 6

Espace de noms RADOS au sein d'une réserve de données dans lequel les objets serontécrits. Ce paramètre est vide par défaut, autrement dit le système utilise l'espace de nompar défaut.

stripe_unit

Taille en octets d'un bloc de données utilisé dans la distribution RAID 0 d'un chier. Toutesles unités de segment d'un chier ont la même taille. La dernière unité de segment estgénéralement incomplète : elle représente les données à la n du chier ainsi que l'espaceinutilisé restant jusqu'à la n de la taille de l'unité de segment xe.

stripe_count

Nombre d'unités de segment consécutives qui constituent un « segment » de chier RAID 0.

object_size

Taille en octets des objets RADOS dans lesquels les données de chier sont tranchées.

Astuce : tailles des objetsRADOS applique une limite congurable sur la taille des objets. Si vous augmentezla taille des objets CephFS au-delà de cette limite, il se peut que les opérationsd'écriture échouent. Le paramètre OSD est osd_max_object_size , qui est de128 Mo par défaut. Les objets RADOS très volumineux peuvent empêcher le bonfonctionnement de la grappe, de sorte qu'il est déconseillé d'augmenter la limite detaille des objets au-delà de la valeur par défaut.

11.3.4.2 Lecture de la disposition avec getfattr

Utilisez la commande getfattr pour lire les informations de disposition d'un chier d'exemplefile en tant que chaîne unique :

root # touch fileroot # getfattr -n ceph.file.layout file# file: fileceph.file.layout="stripe_unit=4194304 stripe_count=1 object_size=419430

Pour lire des champs de disposition individuels :

root # getfattr -n ceph.file.layout.pool file# file: file

139 Disposition des fichiers SES 6

ceph.file.layout.pool="cephfs_data"root # getfattr -n ceph.file.layout.stripe_unit file# file: fileceph.file.layout.stripe_unit="4194304"

Astuce : ID ou nom de réserveLors de la lecture de dispositions, la réserve est généralement indiquée par son nom.Toutefois, dans de rares cas, lorsque les réserves viennent tout juste d'être créées, ellespeuvent être identiées par leur ID.

Les répertoires n'ont pas de disposition explicite tant qu'elle n'est pas personnalisée. Lestentatives de lecture de la disposition échouent si celle-ci n'a jamais été modiée : cela indiqueque le système va utiliser la disposition du répertoire ancêtre suivant doté d'une dispositionexplicite.

root # mkdir dirroot # getfattr -n ceph.dir.layout dirdir: ceph.dir.layout: No such attributeroot # setfattr -n ceph.dir.layout.stripe_count -v 2 dirroot # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 pool=cephfs_data"

11.3.4.3 Écriture de dispositions avec setfattr

Utilisez la commande setfattr pour modier les champs de disposition d'un chier d'exemplefile  :

cephadm@adm > ceph osd lspools0 rbd1 cephfs_data2 cephfs_metadataroot # setfattr -n ceph.file.layout.stripe_unit -v 1048576 fileroot # setfattr -n ceph.file.layout.stripe_count -v 8 file# Setting pool by ID:root # setfattr -n ceph.file.layout.pool -v 1 file# Setting pool by name:root # setfattr -n ceph.file.layout.pool -v cephfs_data file

140 Disposition des fichiers SES 6

Remarque : fichier videLorsque les champs de disposition d'un chier sont modiés à l'aide de setfattr , cechier doit être vide, faute de quoi cela génère une erreur.

11.3.4.4 Nettoyage des dispositions

Si vous souhaitez supprimer une disposition explicite d'un répertoire d'exemple mydir et revenirà l'héritage de la disposition de son ancêtre, exécutez la commande suivante :

root # setfattr -x ceph.dir.layout mydir

De même, si vous avez déni l'attribut « pool_namespace » et que vous souhaitez modier ladisposition pour utiliser l'espace de noms par défaut à la place, exécutez la commande suivante :

# Create a directory and set a namespace on itroot # mkdir mydirroot # setfattr -n ceph.dir.layout.pool_namespace -v foons mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a pool_namespace=foons"

# Clear the namespace from the directory's layoutroot # setfattr -x ceph.dir.layout.pool_namespace mydirroot # getfattr -n ceph.dir.layout mydirceph.dir.layout="stripe_unit=4194304 stripe_count=1 object_size=4194304 \ pool=cephfs_data_a"

11.3.4.5 Héritage des dispositions

Les chiers héritent de la disposition de leur répertoire parent au moment de leur création.Toutefois, les modications ultérieures apportées à la disposition du répertoire parent n'aectentpas les enfants :

root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# file1 inherits its parent's layoutroot # touch dir/file1

141 Disposition des fichiers SES 6

root # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# update the layout of the directory before creating a second fileroot # setfattr -n ceph.dir.layout.stripe_count -v 4 dirroot # touch dir/file2

# file1's layout is unchangedroot # getfattr -n ceph.file.layout dir/file1# file: dir/file1ceph.file.layout="stripe_unit=4194304 stripe_count=2 object_size=4194304 \ pool=cephfs_data"

# ...while file2 has the parent directory's new layoutroot # getfattr -n ceph.file.layout dir/file2# file: dir/file2ceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"

Les chiers créés en tant que descendants du répertoire héritent également de sa disposition siles répertoires intermédiaires n'ont pas de disposition dénie :

root # getfattr -n ceph.dir.layout dir# file: dirceph.dir.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"root # mkdir dir/childdirroot # getfattr -n ceph.dir.layout dir/childdirdir/childdir: ceph.dir.layout: No such attributeroot # touch dir/childdir/grandchildroot # getfattr -n ceph.file.layout dir/childdir/grandchild# file: dir/childdir/grandchildceph.file.layout="stripe_unit=4194304 stripe_count=4 object_size=4194304 \ pool=cephfs_data"

11.3.4.6 Ajout d'une réserve de données au serveur de métadonnées

Avant de pouvoir utiliser une réserve avec CephFS, vous devez l'ajouter au serveur demétadonnées :

cephadm@adm > ceph fs add_data_pool cephfs cephfs_data_ssdcephadm@adm > ceph fs ls # Pool should now show up.... data pools: [cephfs_data cephfs_data_ssd ]

142 Disposition des fichiers SES 6

Astuce : clés CephxAssurez-vous que vos clés Cephx permettent au client d'accéder à la nouvelle réserve.

Vous pouvez ensuite mettre à jour la disposition d'un répertoire dans CephFS de sorte qu'il utilisela réserve récemment ajoutée :

root # mkdir /mnt/cephfs/myssddirroot # setfattr -n ceph.dir.layout.pool -v cephfs_data_ssd /mnt/cephfs/myssddir

Tous les nouveaux chiers créés dans ce répertoire hériteront désormais de sa disposition etplaceront leurs données dans votre réserve récemment ajoutée. Vous remarquerez peut-êtreque le nombre d'objets dans votre réserve de données primaire continue d'augmenter, même sides chiers sont créés dans la réserve que vous venez d'ajouter. C'est normal : les données dechiers sont stockées dans la réserve spéciée par la disposition, mais une petite quantité demétadonnées est conservée dans la réserve de données primaire pour tous les chiers.

143 Disposition des fichiers SES 6

12 Installation de NFS Ganesha

NFS  Ganesha fournit un accès  NFS à Object Gateway ou à CephFS. DansSUSE  Enterprise  Storage  6, les versions  3 et 4 de NFS sont prises en charge. NFS  Ganeshas'exécute dans l'espace utilisateur au lieu de l'espace kernel, et interagit directement avec ObjectGateway ou CephFS.

Avertissement : accès interprotocoleLes clients CephFS et NFS natifs ne sont pas limités par les verrouillages de chiers obtenusvia Samba, et inversement. Les applications qui s'appuient sur le verrouillage de chiersinterprotocole peuvent présenter des altérations des données si les chemins de partageSamba soutenus par CephFS sont accessibles par d'autres moyens.

12.1 Préparation

12.1.1 Informations générales

Pour déployer NFS  Ganesha, vous devez ajouter un élément role-ganesha à votre chier/srv/pillar/ceph/proposals/policy.cfg . Pour plus d'informations, reportez-vous à laSection 5.5.1, « Fichier policy.cfg ». NFS Ganesha a également besoin d'un role-rgw ou d'unrole-mds présent dans le chier policy.cfg .

Bien qu'il soit possible d'installer et d'exécuter le serveur NFS Ganesha sur un noeud Ceph déjàexistant, il est recommandé de l'exécuter sur un hôte dédié disposant d'un accès à la grappeCeph. Les hôtes du client ne font généralement pas partie de la grappe, mais ils doivent disposerd'un accès réseau au serveur NFS Ganesha.

Pour activer le serveur NFS Ganesha à tout moment après l'installation initiale, ajoutez le role-ganesha au chier policy.cfg et réexécutez au moins les phases 2 et 4 de DeepSea. Pour plusd'informations, reportez-vous à la Section 5.3, « Déploiement de la grappe ».

NFS Ganesha est conguré via le chier /etc/ganesha/ganesha.conf qui existe sur le noeudNFS Ganesha. Toutefois, ce chier est écrasé chaque fois que la phase 4 de DeepSea est exécutée.Par conséquent, il est recommandé de modier le modèle utilisé par Salt, qui est le chier /

144 Préparation SES 6

srv/salt/ceph/ganesha/files/ganesha.conf.j2 sur Salt Master. Pour plus d'informationssur le chier de conguration, reportez-vous au Manuel « Guide d'administration », Chapitre 21 « NFS

Ganesha : exportation de données Ceph via NFS », Section 21.2 « Configuration ».

12.1.2 Résumé des conditions requises

Les conditions suivantes doivent être remplies avant de pouvoir exécuter les phases 2 et 4 deDeepSea pour installer NFS Ganesha :

Au moins un noeud doit être assigné au role-ganesha .

Vous ne pouvez dénir qu'un seul role-ganesha par minion.

NFS Ganesha a besoin d'une instance Object Gateway ou de CephFS pour fonctionner.

L'instance NFS basée sur le kernel doit être désactivée sur les minions dotés du rôle role-ganesha .

12.2 Exemple d'installationCette procédure fournit un exemple d'installation qui utilise à la fois la passerelle Object Gatewayet les couches d'abstraction du système de chiers (FSAL) CephFS de NFS Ganesha.

1. Si vous ne l'avez pas encore fait, exécutez les phases 0 et 1 de DeepSea avant de poursuivrecette procédure.

root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1

2. Après avoir exécuté la phase  1 de DeepSea, modiez le chier /srv/pillar/ceph/proposals/policy.cfg et ajoutez la ligne

role-ganesha/cluster/NODENAME

Remplacez NODENAME (NOM_NOEUD) par le nom d'un noeud de la grappe.Vériez également qu'un role-mds et un role-rgw sont assignés.

3. Exécutez au moins les phases 2 et 4 de DeepSea. L'exécution de la phase 3 entre les deuxest recommandée.

145 Résumé des conditions requises SES 6

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3 # optional but recommendedroot@master # salt-run state.orch ceph.stage.4

4. Vériez que NFS Ganesha fonctionne en contrôlant que le service NFS Ganesha est encours d'exécution sur le noeud de minion :

root@master # salt -I roles:ganesha service.status nfs-ganeshaMINION_ID: True

12.3 Configuration haute disponibilité active-passiveCette section fournit un exemple de conguration active-passive à deuxnoeuds des serveurs NFS  Ganesha. La conguration requiert l'extensionSUSE Linux Enterprise High Availability Extension. Les deux noeuds sont appelés earth etmars .

Important : colocalisation des servicesLes services qui ont leur propre tolérance aux pannes et leur propre équilibrage de lacharge ne doivent pas être exécutés sur des noeuds de grappe qui sont délimités pour lesservices de basculement. Par conséquent, n'exécutez pas les services Ceph Monitor, MDS,iSCSI ou Ceph OSD sur des congurations haute disponibilité.

Pour plus d'informations sur l'extension SUSE  Linux  Enterprise  High  Availability  Extension,reportez-vous à l'adresse https://www.suse.com/documentation/sle-ha-15/ .

12.3.1 Installation classique

Dans cette conguration, earth a l'adresse IP 192.168.1.1 et mars 192.168.1.2 .

Par ailleurs, deux adresses IP virtuelles ottantes sont utilisées, permettant aux clients de seconnecter au service indépendamment du noeud physique sur lequel il s'exécute. L'adresse IP192.168.1.10 est utilisée pour l'administration des grappes avec Hawk2 et 192.168.2.1 estutilisée exclusivement pour les exportations NFS. Cela facilite l'application des restrictions desécurité ultérieurement.

146 Configuration haute disponibilité active-passive SES 6

La procédure suivante décrit l'exemple d'installation. Pour plus d'informations, reportez-vous à l'adresse https://www.suse.com/documentation/sle-ha-15/book_sleha_quickstarts/data/

art_sleha_install_quick.html .

1. Préparez les noeuds NFS Ganesha sur Salt Master :

a. Exécutez les phases 0 et 1 de DeepSea.

root@master # salt-run state.orch ceph.stage.0root@master # salt-run state.orch ceph.stage.1

b. Assignez aux noeuds earth et mars le role-ganesha dans le chier /srv/pillar/ceph/proposals/policy.cfg  :

role-ganesha/cluster/earth*.slsrole-ganesha/cluster/mars*.sls

c. Exécutez les phases 2 à 4 de DeepSea.

root@master # salt-run state.orch ceph.stage.2root@master # salt-run state.orch ceph.stage.3root@master # salt-run state.orch ceph.stage.4

2. Enregistrez l'extension SUSE Linux Enterprise High Availability Extension sur earth etmars .

root # SUSEConnect -r ACTIVATION_CODE -e E_MAIL

3. Installez ha-cluster-bootstrap sur les deux noeuds :

root # zypper in ha-cluster-bootstrap

4. a. Initialisez la grappe sur earth  :

root@earth # ha-cluster-init

b. Permettez à mars de rejoindre la grappe :

root@mars # ha-cluster-join -c earth

5. Vériez l'état de la grappe. Vous devriez voir deux noeuds ajoutés à la grappe :

root@earth # crm status

147 Installation classique SES 6

6. Sur les deux noeuds, désactivez le lancement automatique du service NFS Ganesha audémarrage :

root # systemctl disable nfs-ganesha

7. Lancez le shell crm sur earth  :

root@earth # crm configure

Les commandes suivantes sont exécutées avec le shell crm.

8. Sur earth , exécutez le shell  crm an d'exécuter les commandes suivantes permettantde congurer la ressource pour les daemons NFS Ganesha en tant que clone du type deressource systemd :

crm(live)configure# primitive nfs-ganesha-server systemd:nfs-ganesha \op monitor interval=30scrm(live)configure# clone nfs-ganesha-clone nfs-ganesha-server meta interleave=truecrm(live)configure# commitcrm(live)configure# status 2 nodes configured 2 resources configured

Online: [ earth mars ]

Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ]

9. Créez une IPAddr2 primitive avec le shell crm :

crm(live)configure# primitive ganesha-ip IPaddr2 \params ip=192.168.2.1 cidr_netmask=24 nic=eth0 \op monitor interval=10 timeout=20

crm(live)# statusOnline: [ earth mars ]Full list of resources: Clone Set: nfs-ganesha-clone [nfs-ganesha-server] Started: [ earth mars ] ganesha-ip (ocf::heartbeat:IPaddr2): Started earth

10. Pour congurer une relation entre le serveur NFS Ganesha et l'adresse IP virtuelle ottante,nous utilisons la colocalisation et le classement.

148 Installation classique SES 6

crm(live)configure# colocation ganesha-ip-with-nfs-ganesha-server inf: ganesha-ip nfs-ganesha-clonecrm(live)configure# order ganesha-ip-after-nfs-ganesha-server Mandatory: nfs-ganesha-clone ganesha-ip

11. Utilisez la commande mount à partir du client pour vous assurer que la conguration dela grappe est terminée :

root # mount -t nfs -v -o sync,nfsvers=4 192.168.2.1:/ /mnt

12.3.2 Nettoyage des ressources

En cas d'échec de NFS Ganesha sur l'un des noeuds, par exemple earth , résolvez le problèmeet nettoyez la ressource. Ce n'est que lorsque la ressource est nettoyée qu'elle peut eectuer unbasculement vers earth en cas d'échec de NFS Ganesha au niveau de mars .

Pour nettoyer la ressource :

root@earth # crm resource cleanup nfs-ganesha-clone earthroot@earth # crm resource cleanup ganesha-ip earth

12.3.3 Configuration d'une ressource ping

Il peut arriver que le serveur ne puisse pas contacter le client en raison d'un problème réseau.Une ressource ping peut détecter et atténuer ce problème. La conguration de cette ressourceest facultative.

1. Dénissez la ressource ping :

crm(live)configure# primitive ganesha-ping ocf:pacemaker:ping \ params name=ping dampen=3s multiplier=100 host_list="CLIENT1 CLIENT2" \ op monitor interval=60 timeout=60 \ op start interval=0 timeout=60 \ op stop interval=0 timeout=60

host_list est une liste d'adresses IP séparées par des espaces. Une ressource ping serarégulièrement envoyée aux adresses IP pour vérier les pannes du réseau. Si un client doittoujours avoir accès au serveur NFS, ajoutez-le à la liste host_list .

149 Nettoyage des ressources SES 6

2. Créez un clone :

crm(live)configure# clone ganesha-ping-clone ganesha-ping \ meta interleave=true

3. La commande suivante crée une contrainte pour le service NFS Ganesha. Elle impose auservice de se déplacer vers un autre noeud lorsque host_list est inaccessible.

crm(live)configure# location nfs-ganesha-server-with-ganesha-ping nfs-ganesha-clone \ rule -inf: not_defined ping or ping lte 0

12.3.4 NFS Ganesha HA et DeepSea

DeepSea ne prend pas en charge la conguration NFS Ganesha HA. Pour empêcher l'échec deDeepSea après la conguration de NFS Ganesha HA, excluez le démarrage et l'arrêt du serviceNFS Ganesha à partir de la phase 4 de DeepSea :

1. Copiez /srv/salt/ceph/ganesha/default.sls vers /srv/salt/ceph/ganesha/

ha.sls .

2. Supprimez l'entrée .service du chier /srv/salt/ceph/ganesha/ha.sls an qu'il seprésente comme suit :

include:- .keyring- .install- .configure

3. Ajoutez la ligne suivante à /srv/pillar/ceph/stack/global.yml  :

ganesha_init: ha

12.4 Configuration active-activeCette section fournit un exemple de conguration NFS Ganesha active-active simple. L'objectifest de déployer deux serveurs NFS Ganesha superposés au-dessus du même CephFS existant. Lesserveurs correspondent à deux noeuds de grappe Ceph avec des adresses séparées. Les clientsdoivent être répartis entre eux manuellement. Dans cette conguration, un « basculement  »désigne le démontage et le remontage manuels de l'autre serveur sur le client.

150 NFS Ganesha HA et DeepSea SES 6

12.4.1 Conditions préalables

Pour notre exemple de conguration, vous avez besoin des éléments suivants :

Une grappe Ceph en cours d'exécution. Reportez-vous à la Section 5.3, « Déploiement de la

grappe » pour plus de détails sur le déploiement et la conguration de la grappe Ceph àl'aide de DeepSea.

Au moins une instance CephFS congurée. Reportez-vous au Chapitre  11, Installation de

CephFS pour plus de détails sur le déploiement et la conguration de CephFS.

Deux noeuds de grappe Ceph avec NFS Ganesha déployé. Reportez-vous au Chapitre 12,

Installation de NFS Ganesha pour plus de détails sur le déploiement de NFS Ganesha.

Astuce : utilisez des serveurs dédiésBien que les noeuds NFS Ganesha puissent partager des ressources avec d'autresservices associés à Ceph, nous vous recommandons d'utiliser des serveurs dédiéspour de meilleures performances.

Après avoir déployé les noeuds NFS Ganesha, vériez que la grappe est opérationnelle et queles réserves CephFS par défaut sont là :

cephadm@adm > rados lspoolscephfs_datacephfs_metadata

12.4.2 Configuration de NFS Ganesha

Vériez que les deux noeuds NFS Ganesha ont le chier /etc/ganesha/ganesha.conf installé.Ajoutez les blocs suivants, s'ils n'existent pas encore, au chier de conguration, an d'activerRADOS comme interface dorsale de récupération de NFS Ganesha.

NFS_CORE_PARAM{ Enable_NLM = false; Enable_RQUOTA = false; Protocols = 4;}NFSv4{

151 Conditions préalables SES 6

RecoveryBackend = rados_cluster; Minor_Versions = 1,2;}CACHEINODE { Dir_Chunk = 0; NParts = 1; Cache_Size = 1;}RADOS_KV{ pool = "rados_pool"; namespace = "pool_namespace"; nodeid = "fqdn" UserId = "cephx_user_id"; Ceph_Conf = "path_to_ceph.conf"}

Vous pouvez trouver les valeurs de rados_pool et pool_namespace en vériant la ligne déjàexistante dans la conguration du formulaire :

%url rados://rados_pool/pool_namespace/...

La valeur de l'option nodeid correspond au nom de domaine complet de la machine, et la valeurdes options UserId et Ceph_Conf est disponible dans le bloc RADOS_URLS déjà existant.

Étant donné que les versions héritées de NFS nous empêchent de supprimer la période bonus demanière précoce et prolongent donc un redémarrage serveur, nous désactivons les options deNFS antérieures à la version 4.2. Nous désactivons également une grosse partie du caching deNFS Ganesha puisque les bibliothèques Ceph eectuent déjà un caching agressif.

L'interface dorsale de récupération «  rados_cluster  » stocke ses informations dans les objetsRADOS. Bien que cela ne représente pas un gros volume de données, nous voulons qu'elles soienthautement disponibles. Nous utilisons la réserve de métadonnées CephFS à cette n et déclaronsun nouvel espace de noms « ganesha » au sein de cette réserve an d'établir une séparation parrapport aux objets CephFS.

Remarque : ID de noeud de grappeLa majeure partie de la conguration est identique entre les deux hôtes, mais l'optionnodeid dans le bloc « RADOS_KV » doit être une chaîne unique pour chaque noeud. Pardéfaut, NFS Ganesha dénit nodeid sur le nom d'hôte du noeud.

Si vous devez utiliser des valeurs xes diérentes des noms d'hôte, vous pouvez parexemple dénir nodeid = 'a' sur un noeud et nodeid = 'b' sur l'autre.

152 Configuration de NFS Ganesha SES 6

12.4.3 Remplissage de la base de données de bonus de grappe

Nous devons vérier que tous les noeuds de la grappe se connaissent. Pour ce faire, nous utilisonsun objet RADOS qui est partagé entre les hôtes. NFS Ganesha utilise cet objet pour communiquerl'état actuel concernant une période bonus.

Le paquetage nfs-ganesha-rados-grace contient un outil de ligne de commande pourinterroger et manipuler cette base de données. Si le paquetage n'est pas installé sur au moins undes noeuds, installez-le avec la commande suivante :

root # zypper install nfs-ganesha-rados-grace

Nous allons utiliser la commande pour créer la base de données et ajouter les deux IDde noeud ( nodeid ). Dans notre exemple, les deux noeuds NFS Ganesha sont nommésses6min1.example.com et ses6min2.example.com . Sur l'un des hôtes NFS Ganesha, exécutezla commande suivante :

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min1.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganesha add ses6min2.example.comcephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=1 rec=0======================================================ses6min1.example.com Eses6min2.example.com E

Cela crée la base de données de bonus et y ajoute à la fois «  ses6min1.example.com  » et«  ses6min2.example.com  ». La dernière commande vide l'état actuel. Les hôtes récemmentajoutés sont toujours considérés comme appliquant la période bonus, de sorte qu'ils ont tous deuxle drapeau « E ». Les valeurs « cur » et « rec » montrent les périodes actuelles et de récupération,ce qui nous permet de déterminer quels sont les hôtes autorisés à eectuer la récupération etquand.

12.4.4 Redémarrage des services NFS Ganesha

Sur les deux noeuds NFS Ganesha, redémarrez les services associés :

root # systemctl restart nfs-ganesha.service

Une fois les services redémarrés, vériez la base de données de bonus :

cephadm@adm > ganesha-rados-grace -p cephfs_metadata -n ganeshacur=3 rec=0

153 Remplissage de la base de données de bonus de grappe SES 6

======================================================ses6min1.example.comses6min2.example.com

Remarque : eacement du drapeau « E »Notez que les deux noeuds ont eacé leur drapeau « E », indiquant qu'ils n'appliquentplus la période bonus et sont maintenant en mode de fonctionnement normal.

12.4.5 Conclusion

Après avoir terminé toutes les étapes précédentes, vous pouvez monter le NFS exporté à partirde l'un des deux serveurs NFS Ganesha et eectuer des opérations NFS normales sur ces derniers.

Notre exemple de conguration suppose que si l'un des deux serveurs NFS Ganesha tombe enpanne, vous le redémarrez manuellement dans les 5 minutes. Après 5 minutes, le serveur demétadonnées peut annuler la session que le client NFS Ganesha détenait et tout l'état qui lui étaitassocié. Si les fonctionnalités de la session sont annulées avant que le reste de la grappe entredans la période bonus, les clients du serveur risquent de ne pas être en mesure de récupérerla totalité de leur état.

12.5 Pour plus d'informationsPour plus d'informations, reportez-vous au Manuel « Guide d'administration », Chapitre 21 « NFS

Ganesha : exportation de données Ceph via NFS ».

154 Conclusion SES 6

IV Déploiement de grappes sur SUSECaaS Plaform 4 (avant-premièretechnologique)

13 SUSE Enterprise Storage  6 sur une grappe Kubernetes SUSE CaaSPlatform 4 156

13 SUSE Enterprise Storage 6 sur une grappeKubernetes SUSE CaaS Platform 4

Avertissement : avant-première technologiqueL'exécution d'une grappe Ceph conteneurisée sur SUSE CaaS Platform est une avant-première technologique. Ne déployez pas cette approche sur une grappe Kubernetes enproduction.

Ce chapitre décrit comment déployer SUSE Enterprise Storage 6 sur une grappe KubernetesSUSE CaaS Platform 4 conteneurisée.

13.1 ConsidérationsAvant de commencer le déploiement, considérez les points suivants :

Pour exécuter Ceph dans Kubernetes, SUSE Enterprise Storage 6 utilise un projet en amontappelé Rook (https://rook.io/ ).

Selon la conguration, Rook peut consommer tous les disques inutilisés sur tous les noeudsd'une grappe Kubernetes.

L'installation des conteneurs privilégiés.

13.2 Conditions préalablesAvant de commencer le déploiement, vous devez disposer des éléments suivants :

une grappe SUSE CaaS Platform 4 en cours d'exécution ;

des noeuds de travail SUSE CaaS Platform  4 avec un certain nombre de disquessupplémentaires attachés en tant que stockage pour la grappe Ceph.

156 Considérations SES 6

13.3 Obtention des manifestes RookL'orchestrateur Rook utilise des chiers de conguration au format YAML appelés manifestes. Lesmanifestes dont vous avez besoin sont inclus dans le paquetage RPM rook-k8s-yaml . Installez-le en exécutant la commande suivante :

root # zypper install rook-k8s-yaml

13.4 InstallationRook-Ceph comprend deux composants principaux : l'opérateur (« operator ») qui est géré parKubernetes et permet la création de grappes Ceph et la grappe (« cluster ») Ceph proprementdite, qui est créée et partiellement gérée par l'opérateur.

13.4.1 Configuration

13.4.1.1 Configuration globale

Les manifestes utilisés dans cette conguration installent tous les composants Rook et Ceph dansl'espace de noms « rook-ceph ». Si vous avez besoin de le changer, adaptez en conséquence toutesles références à l'espace de noms dans les manifestes Kubernetes.

Selon les fonctions de Rook que vous prévoyez d'utiliser, modiez la conguration de la stratégiede sécurité des pods (« Pod Security Policy ») dans common.yaml pour limiter les exigences desécurité de Rook. Suivez les commentaires dans le chier manifeste.

13.4.1.2 Configuration de l'opérateur

Le manifeste operator.yaml congure l'opérateur Rook. Normalement, vous n'avez pas besoinde le modier. Pour plus d'informations, reportez-vous aux commentaires dans le chiermanifeste.

157 Obtention des manifestes Rook SES 6

13.4.1.3 Configuration de la grappe Ceph

Le manifeste cluster.yaml est responsable de la conguration de la grappe Ceph réelle quis'exécutera dans Kubernetes. Pour une description détaillée de toutes les options disponibles,reportez-vous à la documentation Rook en amont à la page https://rook.io/docs/rook/v1.0/ceph-

cluster-crd.html .

Par défaut, Rook est conguré pour utiliser tous les noeuds qui ne sont pas marquésavec l'option node-role.kubernetes.io/master:NoSchedule et obéiront aux paramètresde placement congurés (voir https://rook.io/docs/rook/v1.0/ceph-cluster-crd.html#placement-

configuration-settings ). L'exemple suivant désactive un tel comportement et n'utilise que lesnoeuds explicitement répertoriés dans la section « nodes » :

storage: useAllNodes: false nodes: - name: caasp4-worker-0 - name: caasp4-worker-1 - name: caasp4-worker-2

RemarquePar défaut, Rook est conguré pour utiliser tous les disques libres et vides sur chaquenoeud à des ns de stockage Ceph.

13.4.1.4 Documentation

La documentation Rook-Ceph en amont à la page https://rook.github.io/docs/rook/master/

ceph-storage.html contient des informations plus détaillées sur la conguration dedéploiements plus avancés. Utilisez-la comme référence pour comprendre les bases deRook-Ceph avant d'élaborer des congurations plus complexes.

Pour plus de détails sur le produit SUSE CaaS Platform, reportez-vous à la page https://

www.suse.com/documentation/suse-caasp .

158 Configuration SES 6

13.4.2 Création de l'opérateur Rook

Installez les composants communs Rook-Ceph, les rôles CSI et l'opérateur Rook-Ceph enexécutant la commande suivante sur le noeud maître SUSE CaaS Platform :

root # kubectl apply -f common.yaml -f operator.yaml

common.yaml crée alors l'espace de noms «  rook-ceph  », les dénitions de ressourcespersonnalisées (CRD) Ceph (voir https://kubernetes.io/docs/concepts/extend-kubernetes/api-

extension/custom-resources/ ) pour que Kubernetes ait connaissance des objets Ceph (parexemple, «  CephCluster  »), ainsi que les rôles RBAC et les stratégies de sécurité des pods(voir https://kubernetes.io/docs/concepts/policy/pod-security-policy/ ) qui sont nécessaires pourpermettre à Rook de gérer les ressources spéciques à la grappe.

Astuce : utilisation de hostNetwork et de hostPortsPermettre l'emploi de hostNetwork est nécessaire en cas d'utilisation de hostNetwork:true dans la dénition de ressource de grappe. De même, il est nécessaire d'autoriserl'utilisation de hostPorts dans PodSecurityPolicy .

Vériez l'installation en exécutant kubectl get pods -n rook-ceph sur le noeud maître SUSECaaS Platform, par exemple :

root # kubectl get pods -n rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h

13.4.3 Création de la grappe Ceph

Après avoir modié cluster.yaml en fonction de vos besoins, vous pouvez créer la grappeCeph. Exécutez la commande suivante sur le noeud maître SUSE CaaS Platform :

root # kubectl apply -f cluster.yaml

159 Création de l'opérateur Rook SES 6

Surveillez l'espace de noms «  rook-ceph  » pour voir la création de la grappe Ceph. Vousremarquerez autant d'instances Ceph Monitor que le nombre conguré dans le manifestecluster.yaml (3 par défaut), une instance Ceph Manager et autant de Ceph OSD que vousavez de disques libres.

Astuce : pods OSD temporairesPendant l'amorçage de la grappe Ceph, vous constaterez que certains pods nommés rook-ceph-osd-prepare-NOM-NOEUD s'exécutent un moment, puis s'arrêtent avec le statut« Completed » (Terminé). Comme leur nom l'indique, ces pods provisionnent les CephOSD. Ils se ferment sans être supprimés an que vous puissiez inspecter leurs journauxlorsqu'ils ont ni. Par exemple :

root # kubectl get pods --namespace rook-cephNAME READY STATUS RESTARTS AGErook-ceph-agent-57c9j 1/1 Running 0 22hrook-ceph-agent-b9j4x 1/1 Running 0 22hrook-ceph-mgr-a-6d48564b84-k7dft 1/1 Running 0 22hrook-ceph-mon-a-cc44b479-5qvdb 1/1 Running 0 22hrook-ceph-mon-b-6c6565ff48-gm9wz 1/1 Running 0 22hrook-ceph-operator-cf6fb96-lhbj7 1/1 Running 0 22hrook-ceph-osd-0-57bf997cbd-4wspg 1/1 Running 0 22hrook-ceph-osd-1-54cf468bf8-z8jhp 1/1 Running 0 22hrook-ceph-osd-prepare-caasp4-worker-0-f2tmw 0/2 Completed 0 9m35srook-ceph-osd-prepare-caasp4-worker-1-qsfhz 0/2 Completed 0 9m33srook-ceph-tools-76c7d559b6-64rkw 1/1 Running 0 22hrook-discover-mb8gv 1/1 Running 0 22hrook-discover-tztz4 1/1 Running 0 22h

13.5 Utilisation de Rook comme stockage pour leworkload KubernetesRook vous permet d'utiliser trois types diérents de stockage :

Stockage d'objets

Le stockage d'objets expose une API S3 à la grappe de stockage an que les applicationspuissent placer des données et en obtenir. Pour une description détaillée, reportez-vous àla page https://rook.io/docs/rook/v1.0/ceph-object.html .

160 Utilisation de Rook comme stockage pour le workload Kubernetes SES 6

Système de fichiers partagé

Un système de chiers partagé peut être monté avec des autorisations de lecture/écritureà partir de plusieurs pods. Cela est utile pour les applications qui sont mises en grappeavec un système de chiers partagé. Pour une description détaillée, reportez-vous à la pagehttps://rook.io/docs/rook/v1.0/ceph-filesystem.html .

Stockage de bloc

Le stockage en bloc vous permet de monter le stockage sur un seul pod. Pourune description détaillée, reportez-vous à la page https://rook.io/docs/rook/v1.0/ceph-

block.html .

13.6 Désinstallation de RookPour désinstaller Rook, procédez comme suit :

1. Supprimez toutes les applications Kubernetes qui consomment du stockage Rook.

2. Supprimez tous les artefacts de stockage d'objets, de chiers et/ou de blocs que vous avezcréés selon les explications de la Section 13.5, « Utilisation de Rook comme stockage pour le

workload Kubernetes ».

3. Supprimez la grappe Ceph, l'opérateur et les ressources associées :

root # kubectl delete -f cluster.yamlroot # kubectl delete -f operator.yamlroot # kubectl delete -f common.yaml

4. Supprimez les données sur les hôtes :

root # rm -rf /var/lib/rook

5. Si nécessaire, eacez les disques qui ont été utilisés par Rook. Pour plus d'informations,reportez-vous à la page https://rook.io/docs/rook/master/ceph-teardown.html .

161 Désinstallation de Rook SES 6

A Mises à jour de maintenance de Ceph basées surles versions intermédiaires « Nautilus » en amont

Plusieurs paquetages clés de SUSE Enterprise Storage  6 sont basés sur la série de versionsNautilus de Ceph. Lorsque le projet Ceph (https://github.com/ceph/ceph ) publie de nouvellesversions intermédiaires dans la série Nautilus, SUSE Enterprise Storage 6 est mis à jour pourgarantir que le produit bénécie des derniers rétroports de fonctionnalités et correctifs de boguesen amont.

Ce chapitre contient des résumés des changements notables contenus dans chaque versionintermédiaire en amont qui a été ou devrait être incluse dans le produit.

Version intermédiaire Nautilus 14.2.4Cette version intermédiaire corrige une régression sérieuse constatée dans la versionintermédiaire 14.2.3. Cette régression n'a pas aecté les clients SUSE Enterprise Storage, carnous n'avons pas livré de version basée sur 14.2.3.

Version intermédiaire Nautilus 14.2.3

Cette version intermédiaire corrige une vulnérabilité par déni de service selon laquelle unclient non authentié de Ceph Object Gateway pouvait déclencher un crash à partir d'uneexception non interceptée.

Les clients librbd basés sur Nautilus peuvent désormais ouvrir des images sur les grappesJewel.

L'option num_rados_handles a été supprimée. Si vous utilisiez une valeurnum_rados_handles supérieure à 1, multipliez vos paramètres objecter_inflight_opset objecter_inflight_op_bytes par l'ancienne valeur num_rados_handles and'obtenir le même comportement de limitation.

Le mode sécurisé du protocole Messenger v2 n'est plus expérimental avec cette version. Ils'agit désormais du mode de connexion préféré pour les moniteurs.

162 Version intermédiaire Nautilus 14.2.4 SES 6

La valeur osd_deep_scrub_large_omap_object_key_threshold a été abaissée an dedétecter plus facilement un objet avec un grand nombre de clé omap.

Ceph Dashboard permet désormais de ne plus acher les notications Prometheus.

Version intermédiaire Nautilus 14.2.2

Les commandes associées à no{up,down,in,out} ont été réorganisées. Il existemaintenant deux manières de dénir les drapeaux no{up,down,in,out} , à savoirl'ancienne commande

ceph osd [un]set FLAG

qui établit les drapeaux à l'échelle de la grappe, et la nouvelle commande

ceph osd [un]set-group FLAGS WHO

qui détermine les drapeaux par lots en fonction de la granularité de n'importe quelle classede périphériques ou n'importe quel noeud CRUSH.

radosgw-admin introduit deux sous-commandes qui permettent la gestion d'objetsobsolètes expirés susceptibles d'être laissés après un repartitionnement de compartimentdans les versions antérieures d'Object Gateway. Une sous-commande liste ces objets etl'autre les supprime.

Les versions précédentes de Nautilus (14.2.1 et 14.2.0) présentent un problème dans lamesure où le déploiement d'un seul OSD BlueStore Nautilus nouveau sur une grappe mise àniveau (c'est-à-dire une grappe qui a été initialement déployée avant Nautilus) interromptles statistiques d'utilisation de la réserve signalées par ceph df . Tant que tous les OSD n'ontpas été reprovisionnés ou mis à jour (via ceph-bluestore-tool repair ), les statistiquesde la réserve achent des valeurs inférieures à la réalité. Ce problème est résolu dans laversion intermédiaire 14.2.2, de sorte que la grappe ne passe à l'utilisation des statistiques

163 Version intermédiaire Nautilus 14.2.2 SES 6

par réserve plus précises qu'une fois que tous les OSD disposent d'une version 14.2.2 ouultérieure, font partie du stockage de bloc et ont été mis à jour via la fonction de réparations'ils ont été créés avant Nautilus.

La valeur par défaut pour mon_crush_min_required_version est passée de firefly àhammer , ce qui signie que la grappe émettra un avertissement concernant l'état de santé sivos variables CRUSH sont plus anciennes que Hammer. Généralement, une petite quantitéde données (mais non nulle) est rééquilibrée en basculant vers les variables Hammer.Si possible, nous vous recommandons de dénir le client le plus ancien autorisé surhammer , voire un client ultérieur. Pour vérier quel est le client le plus ancien autoriséactuellement, exécutez la commande suivante :

cephadm@adm > ceph osd dump | grep min_compat_client

Si la valeur actuelle est antérieure à hammer , exécutez la commande suivante pourdéterminer s'il est prudent d'eectuer ce changement en contrôlant si aucun client antérieurà Hammer n'est actuellement connecté à la grappe :

cephadm@adm > ceph features

Le type de compartiment CRUSH plus récent straw2 a été introduit dans Hammer. Si vousconstatez que tous les clients sont Hammer, voire plus récents, cela vous permet d'utiliserde nouvelles fonctionnalités uniquement prises en charge pour les compartiments straw2 ,y compris le mode crush-compat pour l'équilibreur (Manuel « Guide d'administration  »,

Chapitre 10 « Modules Ceph Manager », Section 10.1 « Équilibreur »).

Pour des informations détaillées sur le correctif, reportez-vous à la page https://

download.suse.com/Download?buildid=D38A7mekBz4~ .

Version intermédiaire Nautilus 14.2.1Il s'agit de la première version intermédiaire après la version d'origine de Nautilus (14.2.0). Laversion d'origine (en disponibilité générale, autrement dit « General Availability », GA) de SUSEEnterprise Storage 6 était basée sur cette version intermédiaire.

164 Version intermédiaire Nautilus 14.2.1 SES 6

Glossaire

Général

Arborescence de routageTerme donné à tout diagramme qui montre les diérentes routes qu'un récepteur peutexécuter.

CompartimentPoint qui regroupe d'autres noeuds dans une hiérarchie d'emplacements physiques.

Important : à ne pas confondre avec les compartiments S3Les compartiments S3 ou conteneurs représentent des termes diérents désignant desdossiers pour le stockage d'objets.

CRUSH, carte CRUSHControlled Replication Under Scalable Hashing (Réplication contrôlée sous hachage évolutif) :algorithme qui détermine comment stocker et récupérer des données en calculant lesemplacements de stockage de données. CRUSH requiert une assignation de votre grappepour stocker et récupérer de façon pseudo-aléatoire des données dans les OSD avec unedistribution uniforme des données sur l'ensemble de la grappe.

Ensemble de règlesRègles qui déterminent le placement des données d'une réserve.

NoeudDésigne une machine ou serveur dans une grappe Ceph.

Noeud AdminNoeud à partir duquel vous exécutez l'utilitaire ceph-deploy pour déployer Ceph sur lesnoeuds OSD.

Noeud de moniteur, MONNoeud de grappe qui gère les assignations de l'état de la grappe, notamment l'assignationdu moniteur ou l'assignation OSD.

165 SES 6

Noeud OSDNoeud de grappe qui stocke des données, gère la réplication de données, la récupération, leremplissage, le rééquilibrage et qui fournit des informations de surveillance aux moniteursCeph en contrôlant d'autres daemons Ceph OSD.

OSDAbréviation correspondant, selon le contexte, à Object Storage Device (périphérique destockage d'objets) ou Object Storage Daemon (daemon de stockage d'objets). Le daemon ceph-osd est le composant de Ceph chargé de stocker les objets sur un système de chiers localet de fournir un accès à ces objets via le réseau.

PGPlacement Group (Groupe de placement)  : sous-division d'une réserve utilisée à des nsd'optimisation des performances.

RéservePartitions logiques pour le stockage d'objets, tels que des images disque.

Termes spécifiques à Ceph

AlertmanagerBinaire unique qui gère les alertes envoyées par le serveur Prometheus et avertit l'utilisateurnal.

GrafanaSolution de surveillance et d'analyse de base de données.

Grappe de stockage CephEnsemble de base du logiciel de stockage qui stocke les données de l'utilisateur. Un telensemble comprend des moniteurs Ceph et des OSD.

Connu sous le nom de « magasin d'objets Ceph » (« Ceph Object Store »).

PrometheusToolkit de surveillance et d'alerte des systèmes.

166 SES 6

Termes spécifiques à Object Gateway

Module de synchronisation de l'archivageModule permettant de créer une zone Object Gateway pour conserver l'historique desversions d'objets S3.

Object GatewayComposant de passerelle S3/Swift pour le magasin d'objets Ceph.

167 SES 6

B Mises à jour de la documentation

Ce chapitre répertorie les modications de contenu pour ce document depuis la publicationde la dernière mise à jour de maintenance de SUSE Enterprise Storage  5. Vouspouvez trouver les modications liées au déploiement de la grappe qui s'appliquent auxversions précédentes à l'adresse https://www.suse.com/documentation/suse-enterprise-storage-5/

book_storage_deployment/data/ap_deploy_docupdate.html .

Le document a été mis à jour aux dates suivantes :

Section B.1, « Mise à jour de maintenance de la documentation SUSE Enterprise Storage 6 »

Section B.2, « Juin 2019 (version de SUSE Enterprise Storage 6) »

B.1 Mise à jour de maintenance de la documentationSUSE Enterprise Storage 6MISES À JOUR GÉNÉRALES

Suggestion d'exécuter rpmconfigcheck pour éviter de perdre des modications locales àla Section 6.8, « Mise à niveau par noeud - Procédure de base » (https://jira.suse.com/browse/

SES-348 ).

Ajout du Manuel « Guide d'administration », Chapitre 15 « Amélioration des performances avec le

cache LVM » (https://jira.suse.com/browse/SES-269 ).

Ajout du Chapitre 13, SUSE Enterprise Storage 6 sur une grappe Kubernetes SUSE CaaS Platform 4

(https://jira.suse.com/browse/SES-720 ).

CORRECTIONS DE BOGUES

Ajout d'une astuce sur la surveillance du statut des noeuds de grappe lors de la miseà niveau à la Section  6.9, «  Mise à niveau du noeud Admin  » (https://bugzilla.suse.com/

show_bug.cgi?id=1154568 ).

Ajout de la Section 6.8.2, « Mise à niveau de noeud à l'aide du système de migration de distribution

SUSE » (https://bugzilla.suse.com/show_bug.cgi?id=1154438 ).

Organisation séquentielle du chapitre sur la mise à niveau, Chapitre 6, Mise à jour à partir de

versions précédentes (https://bugzilla.suse.com/show_bug.cgi?id=1144709 ).

168 Mise à jour de maintenance de la documentation SUSE Enterprise Storage 6 SES 6

Ajout de l'entrée de journal de modication (« changelog ») pour Ceph 14.2.4 (https://

bugzilla.suse.com/show_bug.cgi?id=1151881 ).

Uniformisation du nom de la réserve « cephfs_metadata » dans les exemples au Chapitre 12,

Installation de NFS Ganesha (https://bugzilla.suse.com/show_bug.cgi?id=1148548 ).

Mise à jour de la Section  5.5.2.1, «  Spécification  » pour inclure des valeurs plus réalistes(https://bugzilla.suse.com/show_bug.cgi?id=1148216 ).

Ajout de deux nouveaux dépôts pour « Module-Desktop », étant donné que nos clientsutilisent principalement des interfaces graphiques (GUI), à la Section 6.8.1, « Mise à niveau

manuelle d'un noeud à l'aide du DVD du programme d'installation » (https://bugzilla.suse.com/

show_bug.cgi?id=1144897 ).

deepsea-cli n'est pas une dépendance de deepsea à la Section 5.4, « Interface de ligne de

commande de DeepSea » (https://bugzilla.suse.com/show_bug.cgi?id=1143602 ).

Ajout d'une astuce pour migrer ntpd vers chronyd à la Section 6.1, « Points à prendre en

compte avant la mise à niveau » (https://bugzilla.suse.com/show_bug.cgi?id=1135185 ).

Ajout de Manuel «  Guide d'administration  », Chapitre 2 «  Administration de grappe Salt  »,

Section  2.15 «  Désactivation des profils réglés  » (https://bugzilla.suse.com/show_bug.cgi?

id=1130430 ).

Suggestion de migration de l'ensemble du noeud OSD à la Section 6.16.3, « Déploiement OSD »

(https://bugzilla.suse.com/show_bug.cgi?id=1138691 ).

Ajout d'un point sur la migration des noms MDS à la Section 6.1, « Points à prendre en compte

avant la mise à niveau » (https://bugzilla.suse.com/show_bug.cgi?id=1138804 ).

B.2 Juin 2019 (version de SUSE Enterprise Storage 6)MISES À JOUR GÉNÉRALES

Ajout de la Section 5.5.2, « Groupes d'unités » (jsc#SES-548).

Réécriture du Chapitre 6, Mise à jour à partir de versions précédentes (jsc#SES-88).

Ajout de la Section 7.2.1, « Activation du protocole IPv6 pour le déploiement de grappe Ceph »

(jsc#SES-409).

169 Juin 2019 (version de SUSE Enterprise Storage 6) SES 6

Dénition du stockage de bloc comme interface dorsale de stockage par défaut(Fate#325658).

Suppression de toutes les références à la documentation externe en ligne, remplacée parle contenu pertinent (Fate#320121).

CORRECTIONS DE BOGUES

Ajout d'informations sur AppArmor lors de la mise à niveau à la Section 6.1, « Points à prendre

en compte avant la mise à niveau » (https://bugzilla.suse.com/show_bug.cgi?id=1137945 ).

Ajout d'informations sur la non-prise en charge de la mise à niveau en ligne par lesgrappes CDTB à la Section 6.1, « Points à prendre en compte avant la mise à niveau » (https://

bugzilla.suse.com/show_bug.cgi?id=1129108 ).

Ajout d'informations concernant la colocalisation des services Ceph sur les congurationshaute disponibilité à la Section 12.3, « Configuration haute disponibilité active-passive » (https://

bugzilla.suse.com/show_bug.cgi?id=1136871 ).

Ajout d'un conseil sur les paquetages orphelins à la Section 6.8, « Mise à niveau par noeud -

Procédure de base » (https://bugzilla.suse.com/show_bug.cgi?id=1136624 ).

Mise à jour de profile-* avec role-storage dans l'Astuce  : déploiement des

noeuds de moniteur sans définition des profils  OSD (https://bugzilla.suse.com/show_bug.cgi?

id=1138181 ).

Ajout de la Section 6.16, « Migration des déploiements basés sur le profil vers les groupes d'unités »

(https://bugzilla.suse.com/show_bug.cgi?id=1135340 ).

Ajout de la Section  6.11, «  Mise à niveau des serveurs de métadonnées  » (https://

bugzilla.suse.com/show_bug.cgi?id=1135064 ).

Nécessité de réduire la grappe MDS à la Section 6.1, « Points à prendre en compte avant la mise

à niveau » (https://bugzilla.suse.com/show_bug.cgi?id=1134826 ).

Fichier de conguration remplacé par /srv/pillar/ceph/stack/global.yml (https://

bugzilla.suse.com/show_bug.cgi?id=1129191 ).

Mise à jour de diérentes parties du Manuel «  Guide d'administration  », Chapitre

20 «  Exportation des données ceph via Samba  » (https://bugzilla.suse.com/show_bug.cgi?

id=1101478 ).

170 Juin 2019 (version de SUSE Enterprise Storage 6) SES 6

Suppression de master_minion.sls à la Section 5.3, « Déploiement de la grappe » (https://

bugzilla.suse.com/show_bug.cgi?id=1090921 ).

Mention du paquetage deepsea-cli à la Section 5.4, « Interface de ligne de commande de

DeepSea » (https://bugzilla.suse.com/show_bug.cgi?id=1087454 ).

171 Juin 2019 (version de SUSE Enterprise Storage 6) SES 6