Remarque: Les commentateurs ont signalé de graves erreurs dans certaines des hypothèses qui nécessitent une révision de l'article entier.
Stratégie CEPH
Le cluster CEPH combine un nombre arbitraire de K disques de taille arbitraire et stocke des données sur eux, dupliquant chaque morceau (4 Mo par défaut) un nombre spécifié N fois.
Prenons le cas le plus simple avec deux disques identiques. À partir d'eux, vous pouvez soit assembler un RAID 1, soit un cluster avec N = 2 - 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 des données seront sur les disques 1 et 2, certaines sur les disques 1 et 3, et d'autres sur 2 et 3, tandis que RAID ne le sera 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 code analogique - erasure_code, qui contredit les premiers concepts des développeurs, et n'est donc pas pris en compte. RAID 5 suppose que vous disposez d'un petit nombre de disques et qu'ils sont tous en bon état. En cas d'échec, le reste doit tenir jusqu'à ce que le disque soit remplacé et que les données y soient restaurées. Le CEPH, pour N> = 3, encourage l'utilisation d'anciens disques, en particulier,si vous conservez plusieurs bons disques pour stocker une copie des données et stockez les deux ou trois copies restantes sur un grand nombre d'anciens disques, alors les informations seront en sécurité, car tant que les nouveaux disques sont en vie, il n'y a pas de problèmes, et si l'un d'eux casse, alors l'échec simultané trois disques avec une durée de vie de plus de cinq ans, de préférence à partir de différents serveurs - un événement extrêmement improbable.
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 d'eux étant dupliqué sur certains disques. Supposons que K = 6, N = 2, puis si deux disques tombent en panne, les données sont garanties d'être perdues, car, selon la théorie des probabilités, il y a au moins une PG qui sera située 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 ne permettent que le stockage des données sur des disques au sein d'une même paire, alors 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 de 3/15, et même en cas de défaillance 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 égalementque pour un serveur de fichiers, la RAM gratuite augmente considérablement la vitesse de réponse. Plus il y a de mémoire dans chaque nœud et plus de mémoire dans tous les nœuds - plus vite. C'est sans aucun doute l'avantage d'un cluster sur un seul serveur et, de plus, d'un NAS matériel, où une très petite quantité de mémoire est embarquée.
Il s'ensuit que le CEPH est un bon moyen avec un investissement minimal provenant d'équipements obsolètes pour créer un système de stockage fiable pour des dizaines de TB avec la capacité d'évoluer (ici, bien sûr, cela nécessitera des coûts, mais petits par rapport aux systèmes de stockage commerciaux).
Implémentation de cluster
Pour l'expérience, prenez un ordinateur Intel DQ57TM + Intel core i3 540 + 16 Go de RAM mis hors service. Nous organiserons quatre disques de 2 To dans une sorte de 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 nécessite une personnalisation et une stabilité. Les exigences sont Debian et Suse. Suse a un programme d'installation plus flexible pour désactiver n'importe quel paquet; Malheureusement, je ne pouvais pas comprendre ce qui peut être jeté sans nuire au système. Nous installons 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 si grande qu'elle dérange. Puisque le travail est effectué sur une machine physique, je souhaite faire des instantanés comme sur des machines virtuelles. Soit LVM ou btrfs (ou xfs ou zfs - la différence n'est pas grande) offre une telle opportunité. Les instantanés LVM ne sont pas un point fort. Nous mettons btrfs. Et le chargeur de démarrage est dans le MBR. Cela n'a aucun sens d'obstruer un disque de 50 Mo avec une partition FAT,lorsque vous pouvez le pousser dans une zone de 1 Mo de la table de partition et allouer tout l'espace pour le système. Utilisé sur disque 700 Mo. De combien l'installation de base de SUSE a - je ne me souviens pas, semble-t-il, d'environ 1,1 ou 1,4 Go.
Installation de CEPH. Ignorez la version 12 dans le référentiel Debian et créez un lien directement depuis le site 15.2.3. Nous suivons les instructions de la section "Installer CEPH manuellement" avec les mises en garde suivantes:
- Avant de connecter le référentiel, vous devez installer les certificats ca gnupg wget
- Après avoir connecté le référentiel, mais avant d'installer le cluster, l'installation des packages est omise: apt -y --no-install-recommend install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Au moment de l'installation, ceph-osd essaiera d'installer lvm2 pour des raisons (déjà compréhensibles). Il n'y a aucun besoin urgent de cela. Si vous rencontrez des problèmes lors de l'installation d'un paquet, vous pouvez l'abandonner en supprimant la dépendance dans / var / lib / dpkg / status pour ceph-osd.
Un patch moins humain a été utilisé lors de la rédaction de l'article:cat << EOF >> /var/lib/dpkg/status Package: lvm2 Status: install ok installed Priority: important Section: admin Installed-Size: 0 Maintainer: Debian Adduser Developers <adduser@packages.debian.org> Architecture: all Multi-Arch: foreign Version: 113.118 Description: No-install EOF
Présentation du cluster
ceph-osd - est responsable du stockage des données sur le disque. Un service réseau est démarré pour chaque disque, qui accepte et exécute les demandes de lecture ou d'écriture sur les objets. Cet article décrit le stockage bluestore comme le niveau le plus bas. Les fichiers de service sont créés dans le répertoire de service qui décrivent l'ID de cluster, le stockage, son type, etc., ainsi que le fichier de bloc requis - ces fichiers ne sont pas modifiés. Si le fichier est physique, osd y créera un système de fichiers et accumulera des données. Si le fichier est un lien, les données seront dans l'appareil vers lequel le lien pointe. En plus du périphérique principal, block.db - métadonnées (RocksDB) et block.wal - log (journal d'écriture anticipée RocksDB) peuvent être spécifiés en plus. Si aucun périphérique supplémentaire n'est spécifié, les métadonnées et le journal seront stockés dans le périphérique principal.Il est très important de garder une trace de la disponibilité de l'espace libre pour RocksDB, sinon l'OSD ne démarrera pas!
Dans la création osd standard dans les anciennes versions, le disque est divisé en deux sections: la première est de 100 Mo xfs, montée dans / var / lib / ... et contient des informations de service, la seconde est donnée au stockage principal. La nouvelle version utilise lvm.
Théoriquement, vous ne pouvez pas monter une partition miniature, mais placez les fichiers dans / var / lib / ..., en les dupliquant sur tous les nœuds, et sélectionnez le disque entier pour les données sans créer d'en-tête GPT ou LVM. Lorsque vous ajoutez manuellement l'OSD, vous devez vous assurer que l'utilisateur ceph dispose des autorisations d'écriture pour bloquer les périphériques avec des données, et le répertoire de données de service est automatiquement monté dans / var / lib ... si vous décidez de les placer là. Il est également conseillé de spécifier le paramètre de cible de mémoire osd afin qu'il y ait suffisamment de mémoire physique.
ceph-mds. À un faible niveau, CEPH est le stockage d'objets. Le stockage des blocs est réduit au stockage de chaque bloc de 4 Mo en tant qu'objet. Le stockage de fichiers fonctionne de la même manière. Deux pools sont créés: l'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éée, donc si vous supprimez le système de fichiers, mais que vous conservez les deux pools, vous ne pourrez pas le restaurer. Il existe une procédure d'extraction de fichiers par blocs, non testée. Le service ceph-mds est responsable de l'accès au système de fichiers. Une instance distincte du service est requise pour chaque système de fichiers. Il existe une option "rank", qui vous permet de créer un semblant de plusieurs systèmes de fichiers en un - également non testé.
ceph-mon - ce service stocke une carte de 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 sont pas clairs pour moi: il y a un répertoire /var/lib/ceph/mon/.../store.db, dedans il y a un gros fichier - 26 Mo, et dans un cluster de 105K objets, un peu plus de 256 octets par objet sont obtenus - je pense que le moniteur stocke une liste de tous les objets et PG dans lesquels ils se trouvent). L'endommagement de ce répertoire entraîne la perte de toutes les données du cluster. Par conséquent, il a été conclu que CRUSH montre comment les PG sont situés sur l'OSD et comment les objets sont situés sur le PG - dans la base de données (la conclusion s'est avérée incorrecte, ce qu'elle contient exactement nécessite une clarification). Par conséquent, premièrement, nous ne pouvons pas installer le système sur une clé USB en mode RO, car la base de données est constamment écrite,vous avez besoin d'un disque supplémentaire pour ces données (à peine plus de 1 Go), et deuxièmement, vous devez avoir une copie de cette base de données en temps réel. S'il y a plusieurs moniteurs, la tolérance aux pannes est due à eux, mais s'il y a un moniteur, deux au maximum, la protection des données doit être assurée. Il existe une procédure théorique pour récupérer un moniteur basé sur les données OSD, au moment où il s'est avéré être restauré au niveau de l'objet, le système de fichiers n'a pas été restauré pour le moment. Jusqu'à présent, vous ne pouvez pas vous fier à ce mécanisme.au moment où il a été restauré au niveau de l'objet, le système de fichiers n'a pas été restauré pour le moment. Jusqu'à présent, vous ne pouvez pas vous fier à ce mécanisme.au moment où il a été restauré au niveau de l'objet, le système de fichiers n'a pas été restauré au moment actuel. Jusqu'à présent, vous ne pouvez pas vous fier à ce mécanisme.
rados-gw - exporte le stockage d'objets via le protocole S3 et autres. Crée de nombreuses piscines, on ne sait pas pourquoi. Je n'ai pas beaucoup expérimenté.
ceph-mgr - Lors de l'installation de ce service, plusieurs modules sont démarrés. L'un d'eux est la mise à l'échelle automatique qui n'est pas désactivée. Il s'efforce de maintenir la quantité correcte de PG / OSD. Si vous souhaitez gérer le ratio manuellement, vous pouvez interdire la mise à l'échelle pour chaque pool, mais dans ce cas, le module tombe en divisant par 0 et l'état du cluster devient ERREUR. Le module est écrit en python, et si vous commentez la ligne nécessaire, cela conduit à sa désactivation. Les détails sont trop paresseux pour se souvenir.
Références:
Installation de CEPH
Récupération après une panne complète du moniteur
Article sur BlueStore dans Ceph
Description de l'architecture ceph. Sage A. Weil
Listes de scripts:
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 <adduser@packages.debian.org>
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 <adduser@packages.debian.org>
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
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@rbd1
OSD ()
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
Le principal avantage marketing de CEPH est CRUSH, un algorithme de calcul de localisation de données. Les moniteurs distribuent cet algorithme aux clients, après quoi les clients demandent directement le nœud nécessaire et l'OSD nécessaire. CRUSH garantit qu'il n'y a pas de centralisation. C'est un petit fichier que vous pouvez au moins imprimer et accrocher au mur. La pratique a montré que CRUSH n'est pas une carte exhaustive. Si vous détruisez et recréez des moniteurs, en conservant tous les OSD et CRUSH, cela ne suffit pas pour restaurer le cluster. À partir de là, il a été conclu que chaque moniteur stockait des métadonnées sur l'ensemble du cluster. Une quantité insignifiante de ces métadonnées n'impose pas de restrictions sur la taille du cluster, mais nécessite d'assurer leur sécurité, ce qui élimine les économies de disque en installant le système sur une clé USB et exclut les clusters avec moins de trois nœuds.Politique de développeur agressive concernant les fonctionnalités optionnelles. Loin du minimalisme. Documentation au niveau: "pour ce que nous avons - merci déjà, mais très, très rare." La capacité d'interagir avec les services à un bas niveau est fournie, mais la documentation est trop superficielle sur ce sujet, donc plus probablement non que oui. Il n'y a presque aucune chance de récupération de données dans une situation d'urgence (grâce aux explications de la communauté, il y a encore une chance).Il n'y a pratiquement aucune chance de récupérer des données dans une situation d'urgence (grâce aux explications de la communauté, la chance demeure).Il n'y a presque aucune chance de récupération de données en situation d'urgence (grâce aux explications de la communauté, il y a encore une chance).
Options pour d'autres actions: abandonnez CEPH et utilisez les btrfs multi-disques banaux (ou xfs, zfs), apprenez de nouvelles informations sur CEPH, qui vous permettront de l'exploiter dans les conditions spécifiées, essayez d'écrire votre propre stockage en tant que mise à niveau.