Comment j’ai déployé Ceph en PROD : épisode 3

La journée précédente s’est achevée sur l’ajout des monitors au sein du cluster Ceph, malheureusement sans succès.

Réseautons une dernière fois

Si vous avez bien lu l’épisode précédent, vous devriez vous souvenir du postulat final: « le datacenter 3 semble isolé par rapport au reste du réseau ». Toutefois, les serveurs présents dans le fameux datacenter étant tous accessibles en SSH, répondent au ping. En revanche, impossible pour les monitors présents sur place de rejoindre le cluster.

Afin d’obtenir de meilleures performances, les cartes réseaux des différents serveurs composant le cluster Ceph ont été configurées avec l’option « Jumbo Frame » activée. Cette option permet de transmettre des paquets IP de plus 1500 Bytes (la taille d’un paquet ip standard), en l’occurrence les cartes sont configurées pour transmettre des paquets de 9’000 Bytes. Pré-requis non négligeable, si vous voulez utiliser les jumbos frames entre deux équipements, TOUS les équipements réseaux éventuellement traversés par des « trames géantes » doivent supporter les paquets de 9’000 Bytes.

Vous l’aurez compris, le switch à l’entrée du datacenter 3 ne supporte pas les Jumbo Frames actuellement. Cette option n’a, de plus, pas pu être activée car celle-ci engendre le redémarrage du switch. Opération délicate compte tenu du fait que des installations de production sont directement reliées au dit switch.

La seule option viable actuellement fut la désactivation des trames géantes sur l’intégralité du cluster Ceph. Suite à cette manipulation, le troisième et dernier monitor fut intégré au quorum sans aucun problème. Les choses sérieuses peuvent commencer !

Au tour des OSDs

Notre cluster met actuellement à disposition la capacité de stockage incroyable de 0.00 GB, c’est tout à fait normal, il est pour l’instant uniquement composé de monitors.

[cephdeploy@CephAdmin clusterceph]$ ceph -s
    cluster XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
     health HEALTH_ERR
            64 pgs are stuck inactive for more than 300 seconds
            64 pgs stuck inactive
            64 pgs stuck unclean
            no osds
     monmap e1: 3 mons at {monitorETL=XX.XX.XX.XX:6789/0,monitorSTA=XX.XX.XX.XX:6789/0,monitorUMA=XX.XX.XX.XX:6789/0}
            election epoch 6, quorum 0,1,2 monitorETL,monitorSTA,monitorUMA
     osdmap e1: 0 osds: 0 up, 0 in
            flags sortbitwise,require_jewel_osds
      pgmap v2: 64 pgs, 1 pools, 0 bytes data, 0 objects
            0 kB used, 0 kB / 0 kB avail
                  64 creating

Ajoutons notre premier serveur composé de 12 disque durs de 6TB chacun. Pour ce faire, la commande ceph-deploy suivante ajoute le disque dur souhaité au cluster Ceph :

ceph-deploy osd prepare {server-name}:{disk-name}:{disk-journal-name}

Voici un petit rappel de la composition en disques de chaque serveur :

Liste des disques sur chaque serveur…

Les 12 disques durs (de sdc à sdn) stockent leurs journaux sur un SSD NVMe, ici appelé nvme0n1. Vous pouvez d’ailleurs voir que 4 disques font actuellement parti du cluster (sdc, sdd, sde et sdf) avec leurs journaux respectifs (nvme0n1p1,nvme0n1p2,nvme0n1p3,nvme0n1p4).

Ajoutons un cinquième disque au cluster à l’aide de la commande « ceph-deploy osd prepare » décrite plus haut:

Une fois le disque formaté et configuré par ceph-deploy, celui-ci est intégré au cluster :

Le cluster fait maintenant 27TB. Il reste à répéter l’opération pour les 31 disques restants.

Le compte est bon, 196TB d’espace brut et 36 disques présents dans le cluster. Vérifions l’attribution des disque au sein des serveurs OSD :

Chaque serveur est bien composé de 12 disques et Ceph a bien créé 3 serveurs.

Les pools

Créons maintenant les pools requis pour l’utilisation de CephFS.

Un « pool » au sens Ceph est un regroupement de données accessibles via une méthode bien particulière. Ceph offre l’accès aux données stockées dans un « pool » via trois protocoles différents, le block storage, l’object storage ou via un file system (CephFS). Il est également possible de définir un niveau de réplication propre à chaque pool.

Dans le cas qui nous intéresse nous allons créer un pool en « replica 3 » qui sera accessible via CephFS, l’accès en mode file system donc. Pour ce faire la commande « ceph osd pool » s’utilise ainsi:

ceph osd pool create {pool-name} {pg-num}

J’ai donc créé le pool CephFS ainsi:

ceph osd pool create backup 1024

Puisqu’il s’agit d’un pool CephFS, un deuxième pool doit être créé pour stocker les métadonnées des futurs fichiers stockés :

ceph osd pool create backup_metadata 1024

« 1024 » est le nombre de groupes de placement compris dans le pool, cette valeur est calculée ainsi (choisir la puissance de deux la plus proche du résultat) :

             (OSDs * 100)
Total PGs = -------------
               Replicas

Un groupe de placement permet à Ceph de repartir les objets sur les différents OSD du cluster.

CephFS

Maintenant que les deux pools sont créés, nous pouvons initialiser CephFS. La première étape consiste à créer des serveurs « mds ». Les mds (metadata server) gèrent les métadonnées indispensables au bon fonctionnement de CephFS. Ces métadonnées sont stockées dans le pool créé précédemment portant le nom de « backup_metadata ».

Un mds peut être créé directement avec « ceph-deploy » comme suit :

ceph-deploy mds create {host-name}

Afin d’éviter tout SPOF (single point of failure), trois mds ont été créés. Un mds par serveur déjà utilisé comme monitor.

ceph-deploy mds create monitorSTA
ceph-deploy mds create monitorETL
ceph-deploy mds create monitorUMA

Actuellement, avec Ceph Jewel, les serveurs mds fonctionnent en actif-passif voir même en actif-passif-passif dans le cas présent. La documentation Ceph ne conseille pour l’instant pas l’utilisation de plusieurs mds actifs pour une utilisation en environnement de production. Les mds sont maintenant prêts à prendre en charge le pool CephFS :

La capture d’écran ci-dessus montre que le serveurUMA est le mds actif actuellement. Deux autres serveurs mds sont actuellement « up » mais en « standby » prêts à prendre le relais si le serveur actif devait subir une avarie.

Créons sans plus tarder le système de fichier CephFS comme suit :

ceph fs new backup backup_metadata backup

Le système de fichiers qui s’appelle « backup » stocke ses métadonnées dans le pool « backup_metadata » et les données sont stockées dans le pool « backup ».

Comment j’ai déployé Ceph en PROD : les épisodes

Episode 1

Episode 2

Episode 3

0 réponses

Répondre

Se joindre à la discussion ?
Vous êtes libre de contribuer !

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *