Quan hi ha més dades de les que poden cabre en un disc, és hora de pensar en RAID. De petit, sovint vaig sentir als meus grans: "un dia RAID serà cosa del passat, l'emmagatzematge d'objectes omplirà el món i ni tan sols saps què és CEPH", així que el primer a la meva vida independent. era crear el meu propi clúster. L'objectiu de l'experiment era familiaritzar-se amb l'estructura interna de ceph i comprendre l'abast de la seva aplicació. Què tan justificada està la implantació de ceph a les mitjanes empreses i a les petites? Després de diversos anys de funcionament i un parell de pèrdues de dades irreversibles, va sorgir la comprensió de les complexitats que no tot és tan senzill. Les peculiaritats de CEPH plantegen barreres per a la seva adopció generalitzada i, per això, els experiments han arribat a un carreró sense sortida. A continuació es descriuen tots els passos realitzats, el resultat obtingut i les conclusions extretes. Si persones amb coneixements comparteixen la seva experiència i expliquen alguns punts, estaré agraït.
Nota: els comentaristes han identificat errors greus en alguns dels supòsits que requereixen una revisió de tot l'article.
Estratègia CEPH
El clúster CEPH combina un nombre arbitrari K de discos de mida arbitrària i emmagatzema dades en ells, duplicant cada peça (4 MB per defecte) un nombre determinat N vegades.
Considerem el cas més simple amb dos discs idèntics. A partir d'ells podeu muntar RAID 1 o un clúster amb N=2; el resultat serà el mateix. Si hi ha tres discos i són de diferents mides, llavors és fàcil muntar un clúster amb N=2: algunes de les dades estaran als discs 1 i 2, algunes estaran als discs 1 i 3, i algunes estaran a 2 i 3, mentre que RAID no ho farà (pots muntar un RAID d'aquest tipus, però seria una perversió). Si encara hi ha més discs, és possible crear RAID 5; CEPH té un codi analògic: erasure_code, que contradiu els primers conceptes dels desenvolupadors i, per tant, no es té en compte. RAID 5 suposa que hi ha un nombre reduït de unitats, totes elles en bon estat. Si un falla, els altres han d'aguantar fins que es substitueix el disc i se li restauren les dades. CEPH, amb N>=3, fomenta l'ús de discs antics, en particular, si conserveu diversos discs bons per emmagatzemar una còpia de dades i emmagatzemeu les dues o tres còpies restants en un gran nombre de discs antics, la informació serà segur, ja que ara per ara els nous discs estan vius: no hi ha problemes, i si un d'ells es trenca, la fallada simultània de tres discos amb una vida útil de més de cinc anys, preferiblement de diferents servidors, és molt poc probable. esdeveniment.
Hi ha una subtilesa en la distribució de còpies. Per defecte, s'assumeix que les dades es divideixen en més (~100 per disc) grups de distribució PG, cadascun dels quals es duplica en alguns discs. Suposem que K=6, N=2, aleshores, si dos discs qualsevol falla, es garanteix la pèrdua de dades, ja que segons la teoria de la probabilitat, hi haurà almenys un PG que s'ubicarà en aquests dos discs. I la pèrdua d'un grup fa que totes les dades del grup no estiguin disponibles. Si els discs es divideixen en tres parells i les dades només es permeten emmagatzemar-se en discs dins d'un parell, llavors aquesta distribució també és resistent a la fallada d'un disc, però si dos discos fallen, la probabilitat de pèrdua de dades no és. 100%, però només 3/15, i fins i tot en cas de fallada tres discos: només 12/20. Per tant, l'entropia en la distribució de dades no contribueix a la tolerància a fallades. Tingueu en compte també que per a un servidor de fitxers, la memòria RAM lliure augmenta significativament la velocitat de resposta. Com més memòria hi hagi a cada node i com més memòria tingui tots els nodes, més ràpid serà. Sens dubte, aquest és un avantatge d'un clúster sobre un únic servidor i, encara més, d'un NAS de maquinari, on hi ha una quantitat molt petita de memòria integrada.
Es dedueix que CEPH és una bona manera de crear un sistema d'emmagatzematge de dades fiable per a desenes de TB amb la capacitat d'escalar amb una inversió mínima d'equips obsolets (aquí, per descomptat, caldran costos, però petits en comparació amb els sistemes d'emmagatzematge comercials).
Implementació del clúster
Per a l'experiment, agafem un ordinador fora de servei Intel DQ57TM + Intel core i3 540 + 16 GB de RAM. Organitzarem quatre discos de 2 TB en alguna cosa com RAID10, després d'una prova satisfactòria afegirem un segon node i el mateix nombre de discos.
Instal·lació de Linux. La distribució requereix la capacitat de personalitzar-se i ser estable. Debian i Suse compleixen els requisits. Suse té un instal·lador més flexible que us permet desactivar qualsevol paquet; Malauradament, no vaig poder esbrinar quins es podrien llençar sense danyar el sistema. Instal·leu Debian mitjançant debootstrap buster. L'opció min-base instal·la un sistema trencat que no té controladors. La diferència de mida en comparació amb la versió completa no és tan gran com per molestar. Com que el treball es realitza en una màquina física, vull fer instantànies, com en màquines virtuals. Aquesta opció la proporciona LVM o btrfs (o xfs o zfs; la diferència no és gran). Les instantànies de LVM no són un punt fort. Instal·leu btrfs. I el carregador d'arrencada es troba a l'MBR. No té sentit desordenar un disc de 50 MB amb una partició FAT quan el podeu introduir a una àrea de taula de particions d'1 MB i assignar tot l'espai per al sistema. Va ocupar 700 MB al disc. No recordo quant té la instal·lació bàsica de SUSE, crec que és d'uns 1.1 o 1.4 GB.
Instal·leu CEPH. Ignorem la versió 12 al repositori debian i ens connectem directament des del lloc 15.2.3. Seguim les instruccions de la secció "Instal·lar CEPH manualment" amb les següents advertències:
- Abans de connectar el dipòsit, heu d'instal·lar gnupg wget ca-certificates
- Després de connectar el dipòsit, però abans d'instal·lar el clúster, s'omet la instal·lació de paquets: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- En instal·lar CEPH, per motius desconeguts, intentarà instal·lar lvm2. En principi, no és una llàstima, però la instal·lació falla, així que CEPH tampoc s'instal·larà.
Aquest pedaç ha ajudat:
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
Visió general del clúster
ceph-osd - s'encarrega d'emmagatzemar dades al disc. Per a cada disc, s'inicia un servei de xarxa que accepta i executa peticions de lectura o escriptura en objectes. Es creen dues particions al disc. Un d'ells conté informació sobre el clúster, el número de disc i les claus del clúster. Aquesta informació d'1 KB es crea una vegada en afegir un disc i mai s'ha observat que canvia. La segona partició no té sistema de fitxers i emmagatzema dades binàries CEPH. La instal·lació automàtica en versions anteriors va crear una partició xfs de 100 MB per a la informació del servei. Vaig convertir el disc a MBR i només vaig assignar 16 MB: el servei no es queixa. Crec que xfs es podria substituir per ext sense cap problema. Aquesta partició està muntada a /var/lib/…, on el servei llegeix informació sobre l'OSD i també troba una referència al dispositiu de bloc on s'emmagatzemen les dades binàries. Teòricament, podeu col·locar fitxers auxiliars immediatament a /var/lib/… i assignar tot el disc per a les dades. Quan es crea un OSD mitjançant ceph-deploy, es crea automàticament una regla per muntar la partició a /var/lib/…, i l'usuari ceph també té drets per llegir el dispositiu de bloc desitjat. Si instal·leu manualment, ho heu de fer vosaltres mateixos; la documentació no ho diu. També és recomanable especificar el paràmetre de destinació de memòria osd perquè hi hagi prou memòria física.
ceph-mds. A un nivell baix, CEPH és l'emmagatzematge d'objectes. La capacitat de bloquejar l'emmagatzematge es redueix a emmagatzemar cada bloc de 4 MB com a objecte. L'emmagatzematge de fitxers funciona amb el mateix principi. Es creen dos grups: un per a metadades i l'altre per a dades. Es combinen en un sistema de fitxers. En aquest moment, es crea algun tipus de registre, de manera que si suprimiu el sistema de fitxers, però manteniu els dos grups, no podreu restaurar-lo. Hi ha un procediment per extreure fitxers per blocs, no l'he provat. El servei ceph-mds és responsable de l'accés al sistema de fitxers. Cada sistema de fitxers requereix una instància separada del servei. Hi ha una opció "índex", que us permet crear l'aspecte de diversos sistemes de fitxers en un, tampoc no s'ha provat.
Ceph-mon: aquest servei emmagatzema un mapa del clúster. Inclou informació sobre tots els OSD, un algorisme per distribuir PG en OSD i, el més important, informació sobre tots els objectes (els detalls d'aquest mecanisme no em queden clars: hi ha un directori /var/lib/ceph/mon/…/). store.db, conté un fitxer gran de 26 MB, i en un grup d'objectes de 105K, resulta ser una mica més de 256 bytes per objecte: crec que el monitor emmagatzema una llista de tots els objectes i els PG en què estan localitzats). El dany a aquest directori provoca la pèrdua de totes les dades del clúster. Per tant, es va arribar a la conclusió que CRUSH mostra com es troben les PG a l'OSD i com es troben els objectes a les PG: s'emmagatzemen centralment dins de la base de dades, per molt que els desenvolupadors eviten aquesta paraula. Com a resultat, en primer lloc, no podem instal·lar el sistema en una unitat flaix en mode RO, ja que la base de dades s'està enregistrant constantment, es necessita un disc addicional per a aquests (gairebé més d'1 GB), en segon lloc, cal tenir un copieu en temps real aquesta base. Si hi ha diversos monitors, la tolerància a errors s'assegura automàticament, però en el nostre cas només hi ha un monitor, com a màxim dos. Hi ha un procediment teòric per restaurar un monitor basat en dades OSD, hi vaig recórrer tres vegades per diferents motius, i tres vegades no hi havia missatges d'error, ni dades. Malauradament, aquest mecanisme no funciona. O operem una partició en miniatura a l'OSD i muntem un RAID per emmagatzemar la base de dades, cosa que sens dubte tindrà un efecte molt dolent en el rendiment, o bé assignem almenys dos suports físics fiables, preferiblement USB, per no ocupar ports.
rados-gw: exporta l'emmagatzematge d'objectes mitjançant el protocol S3 i similar. Crea moltes piscines, no està clar per què. No vaig experimentar gaire.
ceph-mgr - En instal·lar aquest servei, s'inicien diversos mòduls. Un d'ells és l'escala automàtica que no es pot desactivar. S'esforça per mantenir la quantitat correcta de PG/OSD. Si voleu controlar la proporció manualment, podeu desactivar l'escala per a cada grup, però en aquest cas el mòdul es bloqueja amb una divisió per 0 i l'estat del clúster es converteix en ERROR. El mòdul està escrit en Python, i si hi comenteu la línia necessària, això comporta la seva desactivació. Massa mandra per recordar els detalls.
Llista de fonts utilitzades:
Llistes de scripts:
Instal·lació del sistema mitjançant 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 6Creeu un clúster
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@rbd1Afegint OSD (part)
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@$osdnumResum
El principal avantatge de màrqueting de CEPH és CRUSH, un algorisme per calcular la ubicació de les dades. Els monitors distribueixen aquest algorisme als clients, després del qual els clients sol·liciten directament el node desitjat i l'OSD desitjat. CRUSH no garanteix cap centralització. És un petit fitxer que fins i tot podeu imprimir i penjar a la paret. La pràctica ha demostrat que CRUSH no és un mapa exhaustiu. Si destruïu i recreeu els monitors, mantenint tots els OSD i CRUSH, això no és suficient per restaurar el clúster. D'això es conclou que cada monitor emmagatzema algunes metadades sobre tot el clúster. La petita quantitat d'aquestes metadades no imposa restriccions a la mida del clúster, però requereix garantir-ne la seguretat, la qual cosa elimina l'estalvi de disc instal·lant el sistema en una unitat flaix i exclou clústers amb menys de tres nodes. La política agressiva del desenvolupador pel que fa a les funcions opcionals. Lluny del minimalisme. La documentació és a nivell de "gràcies pel que tenim, però és molt, molt escassa". S'ofereix la possibilitat d'interactuar amb serveis a un nivell baix, però la documentació toca aquest tema de manera massa superficial, de manera que és més probable que un no que un sí. Pràcticament no hi ha possibilitats de recuperar dades d'una situació d'emergència.
Opcions per a més accions: abandoneu CEPH i utilitzeu el btrfs multidisc banal (o xfs, zfs), obteniu informació nova sobre CEPH, que us permetrà operar-lo en les condicions especificades, proveu d'escriure el vostre propi emmagatzematge com a avançat. formació.
Font: www.habr.com