Expérience d'exploitation de CEPH

Lorsque les données dépassent la capacité d'un disque, il est temps de penser au RAID. Dans mon enfance, j'entendais souvent de la part des anciens : « un jour, le RAID disparaîtra, les stockages d'objets envahiront le monde, et tu ne sauras même pas ce qu'est CEPH » — c'est pourquoi la première chose que j'ai faite dans ma vie d'adulte a été de créer mon propre cluster. L'objectif de l'expérience était de me familiariser avec le fonctionnement interne de ceph et de comprendre les limites de son application. À quel point l'intégration de ceph est-elle justifiée dans les PME et les TPE ? Après plusieurs années d'exploitation et quelques pertes de données irréversibles, une compréhension des subtilités s'est dégagée : ce n'est pas si simple. Les caractéristiques de CEPH créent des obstacles à sa diffusion, et à cause de cela, les expériences ont abouti à une impasse. Ci-dessous, je présente la description de toutes les étapes, les résultats obtenus et les conclusions tirées. Je serais reconnaissant aux personnes averties de partager leur expérience et d'éclaircir certains points.

Remarque : les commentateurs ont signalé des erreurs graves dans certaines hypothèses, nécessitant une révision de l'ensemble de l'article.

Stratégie CEPH

Le cluster CEPH regroupe un nombre arbitraire de K disques de taille quelconque et stocke les données sur ceux-ci, en dupliquant chaque morceau (4 Mo par défaut) un nombre donné de N fois.

Considérons le cas le plus simple avec deux disques identiques. À partir de ceux-ci, il est possible de créer soit un RAID 1, soit un cluster avec N=2 — le résultat sera le même. Si nous avons trois disques de tailles différentes, il est facile de former un cluster avec N=2 : une partie des données sera sur les disques 1 et 2, une autre partie sur 1 et 3, et une autre encore sur 2 et 3, tandis qu'un RAID ne pourra pas être établi (il est possible de créer un tel RAID, mais cela relèverait de l'absurde). Si le nombre de disques augmente, il est alors possible de créer un RAID 5 ; dans CEPH, il existe un équivalent — erasure_code, qui contredit les concepts précédents des développeurs, et donc n'est pas pris en compte. Le RAID 5 suppose qu'il y a un petit nombre de disques, et que tous sont en bon état. En cas de défaillance d'un disque, les autres doivent tenir jusqu'à ce que le disque soit remplacé et les données restaurées sur celui-ci. En revanche, CEPH, lorsque N>=3, encourage l'utilisation de vieux disques, en particulier si l'on garde plusieurs disques en bon état pour stocker une seule copie des données, tandis que les deux ou trois autres copies sont conservées sur un grand nombre de vieux disques, alors les informations resteront en sécurité, car tant que les nouveaux disques sont en service, il n'y a pas de problème. Et si l'un d'eux tombe en panne, une défaillance simultanée de trois disques âgés de plus de cinq ans, et de préférence provenant de serveurs différents, est un événement extrêmement peu probable.

La distribution des copies présente une subtilité. Par défaut, il est supposé que les données sont partagées en deux groupes de distribution PG (environ 100 par disque), chacun étant dupliqué sur certains disques. Supposons que K=6, N=2. Dans ce cas, si deux disques quelconques tombent en panne, les données sont garanties perdues, car selon la théorie des probabilités, il y aura au moins une PG qui se trouve sur ces deux disques. Et la perte d'un groupe rend toutes les données dans le pool inaccessibles. Si les disques sont divisés en trois paires et que l'on autorise le stockage des données uniquement sur les disques d'une paire, alors cette distribution est également résiliente à la défaillance d'un disque, mais en cas de défaillance de deux, la probabilité de perte de données n'est pas de 100%, mais seulement de 3/15, et même en cas de défaillance de trois disques — seulement 12/20. D'où, l'entropie dans la distribution des données ne contribue pas à la résilience. Notons également que pour un serveur de fichiers, la mémoire vive libre augmente considérablement la rapidité de réponse. Plus il y a de mémoire dans chaque nœud, et plus il y a de mémoire dans tous les nœuds — plus cela sera rapide. C'est sans aucun doute un avantage du cluster par rapport à un serveur unique et, encore plus, à un NAS matériel, où on intègre un volume mémoire très réduit.

Il en ressort que CEPH est un bon moyen, avec un investissement minimal, d'utiliser du matériel obsolète pour créer un système de stockage de données fiable de plusieurs To, avec possibilité d'évoluer (il est vrai que des coûts seront nécessaires, mais ils sont négligeables par rapport aux systèmes de stockage d'entreprise).

Mise en œuvre du cluster

Pour l'expérience, prenons un ordinateur mis au rebut : Intel DQ57TM + Intel core i3 540 + 16 Go de RAM. Nous organiserons quatre disques de 2 To en un semblant de RAID10, après un test réussi, nous ajouterons un deuxième nœud et autant de disques.

Installation de Linux. Le système doit permettre la personnalisation et être stable. Debian et Suse répondent à ces exigences. Suse dispose d'un installateur plus flexible, permettant de désactiver n'importe quel paquet ; malheureusement, je n'ai pas réussi à comprendre lesquels pouvaient être supprimés sans nuire au système. Nous installons Debian via debootstrap buster. L'option min-base installe un système non fonctionnel, manquant de pilotes. La différence de taille par rapport à la version complète n'est pas si grande pour nous en préoccuper. Comme le travail se fait sur une machine physique, nous voulons faire des instantanés, comme sur des machines virtuelles. Cela peut être réalisé soit par LVM, soit par btrfs (ou xfs, ou zfs — la différence n'est pas grande). Les instantanés ne sont pas le point fort de LVM. Nous choisissons btrfs. Et le chargeur d’amorçage se met dans le MBR. Il n'y a pas de sens à encombrer le disque avec une partition FAT de 50 Mo, lorsqu'il est possible de l'intégrer dans un espace de 1 Mo de la table des partitions et de consacrer tout l'espace au système. Cela a occupé 700 Mo sur le disque. Je ne me souviens plus de la taille de l'installation de base de SUSE — je pense qu'elle est d'environ 1.1 ou 1.4 Go.

Installation de CEPH. Nous ignorons la version 12 dans le dépôt debian et la téléchargeons directement depuis le site 15.2.3. Nous suivons les instructions de la section « installation manuelle de CEPH » avec les réserves suivantes :

• Avant de connecter le dépôt, il est nécessaire d'installer gnupg wget ca-certificates
• Après avoir connecté le dépôt, mais avant l'installation du cluster, l'installation des paquets est omise : apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• Lors de l'installation de CEPH, pour des raisons inexplicables, lvm2 tentera de s'installer. En principe, cela ne dérange pas, mais l'installation échoue, donc CEPH ne s'installera pas non plus.

  Ce patch a aidé :

  cat < /var/lib/dpkg/status
  Package: lvm2
  Status: install ok installed
  Priority: important
  Section: admin
  Installed-Size: 0
  Maintainer: Debian Adduser Developers 
  Architecture: all
  Multi-Arch: foreign
  Version: 113.118
  Description: No-install
  EOF
  

Aperçu du cluster

ceph-osd — est responsable du stockage des données sur le disque. Un service réseau est lancé pour chaque disque, permettant de recevoir et d'exécuter des demandes de lecture ou d'écriture sur des objets. Deux partitions sont créées sur le disque. L'une d'elles contient des informations sur le cluster, le numéro de disque, ainsi que des clés du cluster. Ces informations, d'une taille de 1 Ko, sont créées une fois lors de l'ajout du disque et il n'a jamais été signalé qu'elles changent par la suite. La seconde partition n'a pas de système de fichiers et contient des données binaires CEH. L'installation automatique dans les versions précédentes créait une partition xfs de 100 Mo pour les informations de service. J'ai converti le disque en MBR et réservé 16 Mo seulement — le service ne se plaint pas. Je pense qu'il serait possible de remplacer xfs par ext sans problème. Cette partition est montée dans /var/lib/…, où le service lit les informations sur l'OSD et trouve également le lien vers le dispositif de bloc où sont stockées les données binaires. Théoriquement, il est possible de placer immédiatement les aides dans /var/lib/…, et entièrement allouer le disque pour les données. Lors de la création de l'OSD via ceph-deploy, une règle est automatiquement créée pour monter la partition dans /var/lib/…, et les droits de lecture sur le nécessaire dispositif de bloc sont attribués à l'utilisateur ceph. Lors d'une installation manuelle, cela doit être fait soi-même, ce qui n'est pas mentionné dans la documentation. Il est également souhaitable d'indiquer le paramètre osd memory target pour disposer de suffisamment de mémoire physique.

ceph-mds. À un niveau bas, CEPH est un stockage d'objets. La capacité de stockage des blocs se réduit à la sauvegarde de chaque bloc de 4 Mo sous forme d'objet. Le stockage des fichiers fonctionne de la même manière. Deux pools sont créés : un pour les métadonnées, l'autre pour les données. Ceux-ci sont combinés dans un système de fichiers. À ce moment-là, un enregistrement quelconque est créé, donc si vous supprimez le système de fichiers mais conservez les deux pools, il ne sera pas possible de le restaurer. Il existe une procédure pour extraire des fichiers par blocs, mais je ne l'ai pas testée. L'accès au système de fichiers est géré par le service ceph-mds. Un exemplaire de service séparé est nécessaire pour chaque système de fichiers. Il existe une option « index », qui permet de créer une sorte de plusieurs systèmes de fichiers en un — cela n'a pas été non plus testé.

ceph-mon — ce service stocke la carte du cluster. Il contient des informations sur tous les OSD, l'algorithme de répartition des PG dans les OSD et, surtout, des informations sur tous les objets (les détails de ce mécanisme m'échappent : il y a un répertoire /var/lib/ceph/mon/.../store.db, où se trouve un gros fichier de 26 Mo, et dans le cluster, il y a 105K objets, soit un peu plus de 256 octets par objet. Je pense que le moniteur garde une liste de tous les objets et des PG dans lesquels ils se trouvent). La corruption de ce répertoire entraîne la perte de toutes les données dans le cluster. D'où la conclusion que CRUSH montre comment les PG sont répartis sur les OSD, tandis que les objets sont centralisés dans la base de données, peu importe combien les développeurs tentent d'éviter ce terme. Par conséquent, d'une part, nous ne pouvons pas installer le système sur une clé USB en mode RO, car la base de données nécessite une écriture constante, il faut un disque supplémentaire pour cela (probablement pas plus de 1 Go), et d'autre part, il est essentiel d'avoir en temps réel une copie de cette base. Si plusieurs moniteurs sont présents, la redondance est assurée automatiquement, mais dans notre cas, il n'y a qu'un seul moniteur, au maximum deux. Il existe une procédure théorique de récupération d'un moniteur basée sur les données OSD, que j'ai utilisée trois fois pour différentes raisons, et trois fois sans aucun message d'erreur, ni données non plus. Malheureusement, ce mécanisme ne fonctionne pas. Soit nous utilisons une partition minuscule sur l'OSD et construisons un RAID pour le stockage de la base de données, ce qui aura sûrement un impact très négatif sur les performances, soit nous affectons au moins deux supports physiques fiables, de préférence USB, afin de ne pas occuper les ports.

rados-gw — exporte le stockage d'objets via le protocole S3 et similaire. Crée de nombreux pools, sans explication claire de leur nécessité. Je n'ai pas beaucoup expérimenté.

ceph-mgr — lors de l'installation de ce service, plusieurs modules sont lancés. L'un d'eux est l'autoscale, qui ne peut pas être désactivé. Il vise à maintenir le bon nombre de PG/OSD. Si vous souhaitez gérer manuellement le ratio, vous pouvez interdire l'auto-scaling pour chaque pool, mais dans ce cas, le module tombe avec une division par zéro, et le statut du cluster devient ERROR. Le module est écrit en Python, et si vous commentez la ligne pertinente, cela entraîne sa désactivation. Les détails m'ennuient.

Liste des sources utilisées :

Installation de CEPH
Récupération en cas de défaillance totale du moniteur

Listings des scripts :

Installation du système via debootstrap

blkdev=sdb1
mkfs.btrfs -f /dev/$blkdev
mount /dev/$blkdev /mnt
cd /mnt
for i in {@,@var,@home}; do btrfs subvolume create $i; done
mkdir snapshot @/{var,home}
for i in {var,home}; do mount -o bind @${i} @/$i; done
debootstrap buster @ http://deb.debian.org/debian; echo $?
for i in {dev,proc,sys}; do mount -o bind /$i @/$i; done
cp /etc/bash.bashrc @/etc/

chroot /mnt/@ /bin/bash
echo rbd1 > /etc/hostname
passwd
uuid=`blkid | grep $blkdev | cut -d '"' -f 2`
cat < /etc/fstab
UUID=$uuid / btrfs noatime,nodiratime,subvol=@ 0 1
UUID=$uuid /var btrfs noatime,nodiratime,subvol=@var 0 2
UUID=$uuid /home btrfs noatime,nodiratime,subvol=@home 0 2
EOF
cat <> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers 
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install

Package: sudo
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers 
Architecture: all
Multi-Arch: foreign
Version: 113.118
Description: No-install
EOF

exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6

apt -yq install --no-install-recommends linux-image-amd64 bash-completion ed btrfs-progs grub-pc iproute2 ssh smartmontools ntfs-3g net-tools man
exit
grub-install --boot-directory=@/boot/ /dev/$blkdev
init 6

Création du cluster

apt -yq install --no-install-recommends gnupg wget ca-certificates
echo 'deb https://download.ceph.com/debian-octopus/ buster main' >> /etc/apt/sources.list
wget -q -O- 'https://download.ceph.com/keys/release.asc' | apt-key add -
apt update
apt -yq install --no-install-recommends ceph-common ceph-mon

echo 192.168.11.11 rbd1 >> /etc/hosts
uuid=`cat /proc/sys/kernel/random/uuid`
cat < /etc/ceph/ceph.conf
[global]
fsid = $uuid
auth cluster required = cephx
auth service required = cephx
auth client required = cephx
mon allow pool delete = true
mon host = 192.168.11.11
mon initial members = rbd1
mon max pg per osd = 385
osd crush update on start = false
#osd memory target = 2147483648
osd memory target = 1610612736
osd scrub chunk min = 1
osd scrub chunk max = 2
osd scrub sleep = .2
osd pool default pg autoscale mode = off
osd pool default size = 1
osd pool default min size = 1
osd pool default pg num = 1
osd pool default pgp num = 1
[mon]
mgr initial modules = dashboard
EOF

ceph-authtool --create-keyring ceph.mon.keyring --gen-key -n mon. --cap mon 'allow *'
ceph-authtool --create-keyring ceph.client.admin.keyring --gen-key -n client.admin --cap mon 'allow *' --cap osd 'allow *' --cap mds 'allow *' --cap mgr 'allow *'
cp ceph.client.admin.keyring /etc/ceph/
ceph-authtool --create-keyring bootstrap-osd.ceph.keyring --gen-key -n client.bootstrap-osd --cap mon 'profile bootstrap-osd' --cap mgr 'allow r'
cp bootstrap-osd.ceph.keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
ceph-authtool ceph.mon.keyring --import-keyring /etc/ceph/ceph.client.admin.keyring
ceph-authtool ceph.mon.keyring --import-keyring /var/lib/ceph/bootstrap-osd/ceph.keyring
monmaptool --create --add rbd1 192.168.11.11 --fsid $uuid monmap
rm -R /var/lib/ceph/mon/ceph-rbd1/*
ceph-mon --mkfs -i rbd1 --monmap monmap --keyring ceph.mon.keyring
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-mon@rbd1
systemctl start ceph-mon@rbd1
ceph mon enable-msgr2
ceph status

# tableau de bord

apt -yq install --no-install-recommends ceph-mgr ceph-mgr-dashboard python3-distutils python3-yaml
mkdir /var/lib/ceph/mgr/ceph-rbd1
ceph auth get-or-create mgr.rbd1 mon 'allow profile mgr' osd 'allow *' mds 'allow *' > /var/lib/ceph/mgr/ceph-rbd1/keyring
systemctl enable ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1
ceph config set mgr mgr/dashboard/ssl false
ceph config set mgr mgr/dashboard/server_port 7000
ceph dashboard ac-user-create root 1111115 administrator
systemctl stop ceph-mgr@rbd1
systemctl start ceph-mgr@rbd1

Ajout d'OSD (partie)

apt install ceph-osd

osdnum=`ceph osd create`
mkdir -p /var/lib/ceph/osd/ceph-$osdnum
mkfs -t xfs /dev/sda1
mount -t xfs /dev/sda1 /var/lib/ceph/osd/ceph-$osdnum
cd /var/lib/ceph/osd/ceph-$osdnum
ceph auth get-or-create osd.0 mon 'profile osd' mgr 'profile osd' osd 'allow *' > /var/lib/ceph/osd/ceph-$osdnum/keyring
ln -s /dev/disk/by-partuuid/d8cc3da6-02  block
ceph-osd -i $osdnum --mkfs
#chown ceph:ceph /dev/sd?2
chown ceph:ceph -R /var/lib/ceph
systemctl enable ceph-osd@$osdnum
systemctl start ceph-osd@$osdnum

Résumé

Le principal avantage marketing de CEPH est son algorithme CRUSH, qui détermine l'emplacement des données. Les moniteurs transmettent cet algorithme aux clients, qui peuvent ensuite directement demander le nœud et l'OSD souhaités. CRUSH garantit l'absence de centralisation. Il s'agit d'un petit fichier que l'on peut même imprimer et accrocher au mur. La pratique a montré que CRUSH n'est pas une carte exhaustive. Si l'on détruit et recrée les moniteurs tout en conservant tous les OSD et CRUSH, cela ne suffit pas pour restaurer le cluster. Il en résulte que certaines métadonnées sur l'ensemble du cluster sont stockées sur chaque moniteur. Le faible volume de ces métadonnées ne limite pas la taille du cluster, mais nécessite de garantir leur sauvegarde, ce qui exclut l'économie de disque en installant le système sur une clé USB et interdit les clusters avec moins de trois nœuds. La politique agressive du développeur concernant les fonctionnalités optionnelles. Loin du minimalisme. La documentation est au niveau : « Merci pour ce qui existe, mais c'est très, très limité ». Une possibilité d'interaction avec les services à bas niveau est prévue, mais la documentation ne traite ce sujet que de manière superficielle, donc c'est plutôt un non qu'un oui. Il n'y a pratiquement aucune chance de récupérer des données en cas de situation exceptionnelle.

Options pour aller de l'avant : abandonner CEPH et utiliser un banal système multi-disques btrfs (ou xfs, zfs), se renseigner sur de nouvelles informations concernant CEPH qui permettraient de l'exploiter dans les conditions spécifiées, ou essayer d'écrire son propre système de stockage comme moyen d'amélioration des compétences.

Source : habr.com