Lorsqu'il y a plus de données qu'il n'en faut sur un disque, il est temps de penser au RAID. Enfant, j'entendais souvent de la part de mes aînés : "un jour, le RAID appartiendra au passé, le stockage d'objets inondera le monde, et vous ne savez même pas ce qu'est le CEPH", donc la première chose dans une vie indépendante créait votre propre cluster. Le but de l'expérience était de se familiariser avec la structure interne de ceph et de comprendre la portée de son application. Dans quelle mesure l'introduction de ceph est-elle justifiée dans une entreprise moyenne, mais dans une petite entreprise ? Après plusieurs années de fonctionnement et quelques pertes de données irréversibles, une compréhension des subtilités est apparue que tout n'est pas si simple. Les caractéristiques du CEPH créent des obstacles à sa large diffusion et, à cause d'elles, les expériences sont au point mort. Vous trouverez ci-dessous une description de toutes les étapes franchies, du résultat obtenu et des conclusions tirées. Si des personnes bien informées partageront leur expérience et expliqueront certains points, je leur en serai reconnaissant.
Remarque : Les commentateurs ont souligné de graves erreurs dans certaines des hypothèses, nécessitant une révision de l'intégralité de l'article.
Stratégie CEPH
Le cluster CEPH combine un nombre arbitraire K de disques de taille arbitraire et y stocke des données, dupliquant chaque morceau (4 Mo par défaut) un nombre donné N fois.
Considérons le cas le plus simple avec deux disques identiques. Vous pouvez soit assembler un RAID 1 ou un cluster avec N = 2 à partir d'eux - le résultat sera le même. S'il y a trois disques, et qu'ils sont de tailles différentes, alors il est facile d'assembler un cluster avec N=2 : certaines données seront sur les disques 1 et 2, certaines sur 1 et 3, et certaines sur 2 et 3 , alors que RAID n'est pas (vous pouvez collecter un tel RAID, mais ce serait une perversion). S'il y a encore plus de disques, alors il est possible de créer RAID 5, CEPH a un analogue - erasure_code, qui contredit les premiers concepts des développeurs, et n'est donc pas pris en compte. RAID 5 suppose qu'il y a un petit nombre de disques et qu'ils sont tous en bon état. Si l'un tombe en panne, le reste doit tenir jusqu'à ce que le disque soit remplacé et que les données y soient restaurées. CEPH, avec N>=3, encourage l'utilisation d'anciens disques, en particulier si vous conservez plusieurs bons disques pour stocker une copie de données, et stockez les deux ou trois copies restantes sur un grand nombre d'anciens disques, alors l'information sera en sécurité, car pour l'instant de nouveaux disques sont en vie - il n'y a pas de problèmes, et si l'un d'eux tombe en panne, la panne simultanée de trois disques d'une durée de vie de plus de cinq ans, de préférence de serveurs différents, est extrêmement improbable événement.
Il y a une subtilité dans la distribution des copies. Par défaut, on suppose que les données sont divisées en plusieurs groupes de distribution PG (~100 par disque), chacun étant dupliqué sur certains disques. Supposons que K = 6, N = 2, alors si deux disques tombent en panne, les données sont garanties d'être perdues, car selon la théorie des probabilités, il y aura au moins un PG qui sera situé sur ces deux disques. Et la perte d'un groupe rend toutes les données du pool inaccessibles. Si les disques sont divisés en trois paires et autorisés à stocker des données uniquement sur les disques d'une paire, une telle distribution résiste également à la défaillance d'un disque, mais si deux échouent, la probabilité de perte de données n'est pas de 100%, mais seulement 3/15, et même en cas d'échec trois disques - seulement 12/20. Par conséquent, l'entropie dans la distribution des données ne contribue pas à la tolérance aux pannes. Notez également que pour un serveur de fichiers, la RAM libre augmente considérablement la réactivité. 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 ce sera rapide. C'est sans aucun doute l'avantage d'un cluster par rapport à un serveur unique et, qui plus est, à un NAS matériel, où une très petite quantité de mémoire est intégrée.
Il s'ensuit que CEPH est un bon moyen de créer un système de stockage fiable pour des dizaines de To avec la possibilité de mise à l'échelle avec un investissement minimal à partir d'équipements obsolètes (ici, bien sûr, des coûts seront nécessaires, mais faibles par rapport aux systèmes de stockage commerciaux).
Mise en œuvre du cluster
Pour l'expérience, prenons un ordinateur hors service Intel DQ57TM + Intel core i3 540 + 16 Go de RAM. Nous organisons quatre disques de 2 To en quelque chose comme RAID10, après un test réussi, nous ajouterons un deuxième nœud et le même nombre de disques.
Installez Linux. La distribution doit être personnalisable et stable. Debian et Suse répondent aux exigences. Suse dispose d'un programme d'installation plus flexible qui vous permet de désactiver n'importe quel package ; malheureusement, je ne pouvais pas comprendre lesquels peuvent être jetés sans endommager le système. Installez Debian via debootstrap buster. L'option min-base installe un système qui ne fonctionne pas et qui manque de pilotes. La différence de taille par rapport à la version complète n'est pas assez grande pour déranger. Étant donné que le travail est effectué sur une machine physique, je souhaite prendre des instantanés, tout comme sur des machines virtuelles. LVM ou btrfs (ou xfs ou zfs - la différence n'est pas grande) offre une telle opportunité. Les instantanés ne sont pas le point fort de LVM. Installez btrfs. Et le chargeur de démarrage est dans le MBR. Cela n'a aucun sens d'encombrer un disque de 50 Mo avec une partition FAT lorsque vous pouvez le pousser dans une zone de table de partition de 1 Mo et allouer tout l'espace pour le système. Il a fallu 700 Mo sur le disque. Combien l'installation de base de SUSE a - je ne me souviens pas, semble-t-il, d'environ 1.1 ou 1.4 Go.
Installez CEPH. Nous ignorons la version 12 dans le dépôt debian et nous nous connectons directement depuis le site 15.2.3. Nous suivons les instructions de la section "Installation manuelle de CEPH" avec les mises en garde suivantes :
- Avant de connecter le référentiel, vous devez installer gnupg wget ca-certificates
- Après avoir connecté le référentiel, mais avant d'installer le cluster, l'installation du package est omise : apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Au moment de l'installation de CEPH, pour des raisons inconnues, il essaiera d'installer lvm2. En principe, ce n'est pas dommage, mais l'installation échoue, donc CEPH ne s'installera pas non plus.
Ce correctif a aidé :
cat << EOF >> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers <[email protected]> Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
Présentation du cluster
ceph-osd - responsable du stockage des données sur le disque. Pour chaque disque, un service réseau est démarré qui accepte et exécute les demandes de lecture ou d'écriture sur les objets. Deux partitions sont créées sur le disque. L'un d'eux contient des informations sur le cluster, le numéro de disque et les clés de cluster. Ces informations de 1 Ko sont créées une fois lors de l'ajout d'un disque et ne changent plus jamais. La deuxième partition n'a pas de système de fichiers et stocke les données binaires CEPH. 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 alloué seulement 16 Mo - le service ne se plaint pas. Je pense que, sans problème, xfs pourrait être remplacé par ext. Cette partition est montée dans /var/lib/… où le service lit les informations sur l'OSD et trouve également un lien vers le périphérique bloc où les données binaires sont stockées. Théoriquement, vous pouvez immédiatement en placer des auxiliaires dans / var / lib / ... et allouer tout le disque aux données. Lors de la création d'un OSD via ceph-deploy, une règle est automatiquement créée pour monter une partition dans /var/lib/…, et les droits de l'utilisateur ceph sont attribués pour lire le périphérique bloc souhaité. Avec une installation manuelle, vous devez le faire vous-même, la documentation n'en parle pas. Il est également conseillé de spécifier le paramètre osd memory target afin qu'il y ait suffisamment de mémoire physique.
ceph-mds. À un niveau inférieur, CEPH est un stockage d'objets. La capacité de stockage de blocs se résume à enregistrer chaque bloc de 4 Mo en tant qu'objet. Le stockage de fichiers fonctionne sur le même principe. Deux pools sont créés : un pour les métadonnées, l'autre pour les données. Ils sont combinés dans un système de fichiers. À ce moment, une sorte d'enregistrement est créé, donc si vous supprimez le système de fichiers, mais enregistrez les deux pools, vous ne pourrez pas le restaurer. Il existe une procédure pour extraire les fichiers par blocs, je ne l'ai pas testée. Le service ceph-mds est responsable de l'accès au système de fichiers. Chaque système de fichiers nécessite une instance distincte du service. Il existe une option "index" qui vous permet de créer un semblant de plusieurs systèmes de fichiers en un - également non testé.
ceph-mon - Ce service conserve une carte du cluster. Il comprend des informations sur tous les OSD, l'algorithme de distribution PG dans l'OSD et, surtout, des informations sur tous les objets (les détails de ce mécanisme ne me sont pas clairs : il existe un /var/lib/ceph/mon/…/ répertoire store.db, il contient un gros fichier de 26 Mo, et dans un cluster de 105K objets, il s'avère un peu plus de 256 octets par objet - je pense que le moniteur conserve une liste de tous les objets et le PG dans lequel ils mentent). L'endommagement de ce répertoire entraîne la perte de toutes les données du cluster. De là, il a été conclu que CRUSH montre comment les PG sont localisés selon l'OSD et comment les objets sont localisés selon le PG - ils sont stockés de manière centralisée dans la base de données, peu importe comment les développeurs évitent ce mot. Par conséquent, d'une part, nous ne pouvons pas installer le système sur un lecteur flash en mode RO, car la base de données est constamment écrite, un disque supplémentaire est nécessaire pour ceux-ci (à peine plus de 1 Go), et d'autre part, il est nécessaire d'avoir une copie en temps réel de cette base. S'il y a plusieurs moniteurs, la tolérance aux pannes est fournie automatiquement, mais dans notre cas, il n'y a qu'un seul moniteur, maximum deux. Il existe une procédure théorique pour restaurer un moniteur basé sur les données OSD, j'y ai eu recours trois fois pour diverses raisons, et trois fois aucun message d'erreur, ainsi que des données aussi. Malheureusement, ce mécanisme ne fonctionne pas. Soit on exploite une partition OSD miniature et on monte un RAID pour stocker la base de données, ce qui aura probablement un très mauvais effet sur les performances, soit on alloue au moins deux supports physiques fiables, de préférence USB, pour que les ports ne prennent pas en charge.
rados-gw - exporte le stockage d'objets à l'aide du protocole S3, etc. Crée beaucoup de piscines, on ne sait pas pourquoi. Je n'ai pas vraiment expérimenté.
ceph-mgr - L'installation de ce service démarre plusieurs modules. L'un d'eux est la mise à l'échelle automatique non désactivée. Il s'efforce de maintenir le nombre correct de PG/OSD. Si vous souhaitez contrôler le ratio manuellement, vous pouvez désactiver la mise à l'échelle pour chaque pool, mais dans ce cas, le module tombe avec une division par 0 et l'état du cluster devient ERROR. Le module est écrit en python, et si vous commentez la ligne nécessaire, cela conduit à son arrêt. Trop paresseux pour se souvenir des détails.
Liste des sources utilisées:
Listes de script :
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 << EOF > /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 << EOF >> /var/lib/dpkg/status
Package: lvm2
Status: install ok installed
Priority: important
Section: admin
Installed-Size: 0
Maintainer: Debian Adduser Developers <[email protected]>
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 <[email protected]>
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 6Créer un 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 << EOF > /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
# dashboard
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@rbd1Ajout 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@$osdnumRésumé
Le principal avantage marketing de CEPH est CRUSH, un algorithme de calcul de localisation des données. Les moniteurs propagent cet algorithme aux clients, après quoi les clients demandent directement le nœud souhaité et l'OSD souhaité. CRUSH ne fournit aucune centralisation. C'est un petit fichier que vous pouvez même imprimer et accrocher au mur. La pratique a montré que CRUSH n'est pas une carte exhaustive. Détruire et recréer les moniteurs tout en conservant tous les OSD et CRUSH n'est pas suffisant pour restaurer le cluster. On en conclut que chaque moniteur stocke des métadonnées sur l'ensemble du cluster. La quantité insignifiante de ces métadonnées n'impose pas de restrictions sur la taille du cluster, mais elle nécessite leur sécurité, ce qui élimine les économies de disque dues à l'installation du système sur un lecteur flash et exclut les clusters de moins de trois nœuds. Politique de développement agressive concernant les fonctionnalités facultatives. Loin du minimalisme. Documentation au niveau : "merci pour ce que c'est, mais très, très maigrement." La capacité d'interagir avec les services à un niveau bas est fournie, mais la documentation est trop superficielle sur ce sujet, donc plus probablement non que oui. Pratiquement aucune chance de récupérer les données d'une situation d'urgence.
Options pour une action ultérieure : abandonnez CEPH et utilisez le btrfs multidisque banal (ou xfs, zfs), apprenez de nouvelles informations sur CEPH, ce qui vous permettra de le faire fonctionner dans les conditions spécifiées, essayez d'écrire votre propre stockage en tant que formation avancée .
Source: habr.com