Esperienza con CEPH

Quando ci sono più dati di quelli che possono stare su un disco, è il momento di pensare al RAID. Da bambino, sentivo spesso dai miei anziani: "un giorno RAID sarà una cosa del passato, l'archiviazione di oggetti riempirà il mondo e non saprai nemmeno cosa sia CEPH", quindi la prima cosa nella mia vita indipendente era creare il mio cluster. Lo scopo dell'esperimento era conoscere la struttura interna di cefalo e comprenderne l'ambito di applicazione. Quanto è giustificata l'implementazione di Ceph nelle piccole e medie imprese? Dopo diversi anni di attività e un paio di perdite irreversibili di dati, è emersa la comprensione delle complessità che non tutto è così semplice. Le peculiarità del CEPH pongono ostacoli alla sua adozione su vasta scala e, a causa di ciò, gli esperimenti sono giunti a un vicolo cieco. Di seguito è riportata una descrizione di tutti i passaggi effettuati, del risultato ottenuto e delle conclusioni tratte. Se le persone esperte condividessero la loro esperienza e spiegassero alcuni punti, sarei grato.

Nota: i commentatori hanno identificato gravi errori in alcune ipotesi che richiedono la revisione dell'intero articolo.

Strategia CEPH

Il cluster CEPH combina un numero arbitrario K di dischi di dimensione arbitraria e memorizza i dati su di essi, duplicando ogni pezzo (4 MB per impostazione predefinita) un dato numero N volte.

Consideriamo il caso più semplice con due dischi identici. Da essi puoi assemblare RAID 1 o un cluster con N=2: il risultato sarà lo stesso. Se ci sono tre dischi e sono di dimensioni diverse, allora è facile assemblare un cluster con N=2: alcuni dati saranno sui dischi 1 e 2, alcuni saranno sui dischi 1 e 3 e altri saranno su 2 e 3, mentre RAID no (puoi assemblare un RAID del genere, ma sarebbe una perversione). Se ci sono ancora più dischi, è possibile creare RAID 5; CEPH ha un analogo - erasure_code, che contraddice i primi concetti degli sviluppatori e quindi non viene considerato. RAID 5 presuppone la presenza di un numero limitato di unità, tutte in buone condizioni. Se uno fallisce, gli altri devono resistere finché il disco non viene sostituito e i dati vengono ripristinati su di esso. CEPH, con N>=3, incoraggia l'uso di vecchi dischi, in particolare, se si conservano diversi dischi validi per memorizzare una copia dei dati e si memorizzano le restanti due o tre copie su un gran numero di vecchi dischi, allora le informazioni sarà al sicuro, poiché per ora sono vivi nuovi dischi: non ci sono problemi e se uno di essi si rompe, il guasto simultaneo di tre dischi con una durata di servizio superiore a cinque anni, preferibilmente da server diversi, è estremamente improbabile evento.

C'è una sottigliezza nella distribuzione delle copie. Per impostazione predefinita, si presuppone che i dati siano divisi in più gruppi di distribuzione PG (~100 per disco), ciascuno dei quali è duplicato su alcuni dischi. Diciamo K=6, N=2, quindi se due dischi qualsiasi si guastano, i dati verranno sicuramente persi, poiché secondo la teoria della probabilità, ci sarà almeno un PG che verrà posizionato su questi due dischi. E la perdita di un gruppo rende non disponibili tutti i dati nel pool. Se i dischi sono divisi in tre coppie e i dati possono essere archiviati solo sui dischi all'interno di una coppia, tale distribuzione è anche resistente al guasto di un disco qualsiasi, ma se due dischi si guastano, la probabilità di perdita di dati non è 100%, ma solo 3/15, e anche in caso di guasto di tre dischi - solo 12/20. Pertanto, l’entropia nella distribuzione dei dati non contribuisce alla tolleranza agli errori. Si noti inoltre che per un file server, la RAM libera aumenta significativamente la velocità di risposta. Maggiore è la memoria in ciascun nodo e maggiore è la memoria in tutti i nodi, più veloce sarà. Questo è senza dubbio un vantaggio di un cluster rispetto a un singolo server e, ancora di più, di un NAS hardware, dove è integrata una quantità di memoria molto ridotta.

Ne consegue che CEPH è un buon modo per creare un sistema di archiviazione dati affidabile per decine di TB con la possibilità di scalare con un investimento minimo da apparecchiature obsolete (qui, ovviamente, saranno richiesti costi, ma piccoli rispetto ai sistemi di archiviazione commerciali).

Implementazione del cluster

Per l'esperimento prendiamo un computer dismesso Intel DQ57TM + Intel core i3 540 + 16 GB di RAM. Organizzeremo quattro dischi da 2 TB in qualcosa come RAID10, dopo un test riuscito aggiungeremo un secondo nodo e lo stesso numero di dischi.

Installazione di Linux. La distribuzione richiede la capacità di personalizzazione ed essere stabile. Debian e Suse soddisfano i requisiti. Suse ha un programma di installazione più flessibile che ti consente di disabilitare qualsiasi pacchetto; Purtroppo non sono riuscito a capire quali potessero essere gettati via senza danneggiare il sistema. Installa Debian usando debootstrap buster. L'opzione min-base installa un sistema danneggiato privo di driver. La differenza di dimensioni rispetto alla versione completa non è così grande da disturbare. Dato che il lavoro viene svolto su una macchina fisica, voglio scattare delle istantanee, come sulle macchine virtuali. Questa opzione è fornita da LVM o btrfs (o xfs o zfs - la differenza non è grande). Le istantanee LVM non sono un punto di forza. Installa btrfs. E il bootloader è nell'MBR. Non ha senso ingombrare un disco da 50 MB con una partizione FAT quando è possibile inserirlo in un'area della tabella delle partizioni da 1 MB e allocare tutto lo spazio per il sistema. Ha occupato 700 MB su disco. Non ricordo quanto abbia l’installazione base di SUSE, penso che sia circa 1.1 o 1.4 GB.

Installa CEPH. Ignoriamo la versione 12 nel repository Debian e ci colleghiamo direttamente dal sito 15.2.3. Seguiamo le istruzioni della sezione "Installazione manuale di CEPH" con le seguenti avvertenze:

• Prima di connettere il repository, è necessario installare gnupg wget ca-certificates
• Dopo aver connesso il repository, ma prima di installare il cluster, l'installazione dei pacchetti viene omessa: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
• Durante l'installazione di CEPH, per ragioni sconosciute, tenterà di installare lvm2. In linea di principio, non è un peccato, ma l’installazione fallisce, quindi neanche CEPH verrà installato.

  Questa patch ha aiutato:

  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
  

Panoramica del cluster

ceph-osd - è responsabile della memorizzazione dei dati su disco. Per ciascun disco viene avviato un servizio di rete che accetta ed esegue richieste di lettura o scrittura su oggetti. Sul disco vengono create due partizioni. Uno di essi contiene informazioni sul cluster, sul numero del disco e sulle chiavi del cluster. Queste informazioni da 1 KB vengono create una volta quando si aggiunge un disco e non è mai stata notata alcuna modifica. La seconda partizione non ha file system e memorizza i dati binari CEPH. L'installazione automatica nelle versioni precedenti creava una partizione xfs da 100 MB per le informazioni sul servizio. Ho convertito il disco in MBR e ho assegnato solo 16 MB: il servizio non si lamenta. Penso che xfs potrebbe essere sostituito con ext senza problemi. Questa partizione è montata in /var/lib/…, dove il servizio legge le informazioni sull'OSD e trova anche un riferimento al dispositivo a blocchi in cui sono archiviati i dati binari. In teoria, puoi posizionare immediatamente i file ausiliari in /var/lib/… e allocare l'intero disco per i dati. Quando si crea un OSD tramite ceph-deploy, viene creata automaticamente una regola per montare la partizione in /var/lib/… e all'utente ceph vengono assegnati anche i diritti per leggere il dispositivo a blocchi desiderato. Se esegui l'installazione manualmente, devi farlo da solo; la documentazione non lo dice. È inoltre consigliabile specificare il parametro di destinazione della memoria osd in modo che ci sia memoria fisica sufficiente.

cefal-mds. A un livello basso, CEPH è l'archiviazione di oggetti. La possibilità di bloccare l'archiviazione si riduce alla memorizzazione di ciascun blocco da 4 MB come oggetto. L'archiviazione dei file funziona secondo lo stesso principio. Vengono creati due pool: uno per i metadati, l'altro per i dati. Sono combinati in un file system. In questo momento viene creato un tipo di record, quindi se elimini il file system, ma mantieni entrambi i pool, non sarai in grado di ripristinarlo. Esiste una procedura per estrarre i file per blocchi, non l'ho testata. Il servizio ceph-mds è responsabile dell'accesso al file system. Ogni file system richiede un'istanza separata del servizio. Esiste un'opzione "indice" che consente di creare l'apparenza di più file system in uno, anch'essa non testata.

Ceph-mon: questo servizio memorizza una mappa del cluster. Include informazioni su tutti gli OSD, un algoritmo per la distribuzione dei PG negli OSD e, soprattutto, informazioni su tutti gli oggetti (i dettagli di questo meccanismo non mi sono chiari: esiste una directory /var/lib/ceph/mon/…/ store.db, contiene un file grande da 26 MB e in un cluster di 105 oggetti risulta essere poco più di 256 byte per oggetto - penso che il monitor memorizzi un elenco di tutti gli oggetti e i PG in cui si trovano). Il danneggiamento di questa directory comporta la perdita di tutti i dati nel cluster. Da qui la conclusione che CRUSH mostra come si trovano i PG sull'OSD e come si trovano gli oggetti sui PG: sono memorizzati centralmente all'interno del database, non importa quanto gli sviluppatori evitino questa parola. Di conseguenza, in primo luogo, non possiamo installare il sistema su una chiavetta in modalità RO, poiché il database viene costantemente registrato, per questo è necessario un disco aggiuntivo (poco più di 1 GB), in secondo luogo, è necessario disporre di un copiare in tempo reale questa base. Se sono presenti più monitor, la tolleranza agli errori viene garantita automaticamente, ma nel nostro caso è presente un solo monitor, al massimo due. Esiste una procedura teorica per ripristinare un monitor basata sui dati OSD, vi ho fatto ricorso tre volte per vari motivi e tre volte non ci sono stati né messaggi di errore né dati. Purtroppo questo meccanismo non funziona. O gestiamo una partizione in miniatura sull'OSD e assembliamo un RAID per archiviare il database, il che avrà sicuramente un effetto molto negativo sulle prestazioni, oppure allochiamo almeno due supporti fisici affidabili, preferibilmente USB, in modo da non occupare le porte.

rados-gw: esporta l'archiviazione di oggetti tramite il protocollo S3 e simili. Crea molte piscine, non è chiaro il motivo. Non ho sperimentato molto.

ceph-mgr: durante l'installazione di questo servizio, vengono avviati diversi moduli. Uno di questi è la scalabilità automatica che non può essere disabilitata. Si impegna a mantenere la quantità corretta di PG/OSD. Se desideri controllare manualmente il rapporto, puoi disabilitare il ridimensionamento per ciascun pool, ma in questo caso il modulo si blocca con una divisione per 0 e lo stato del cluster diventa ERROR. Il modulo è scritto in Python e se commenti la riga necessaria al suo interno, ciò porta alla sua disabilitazione. Troppo pigro per ricordare i dettagli.

Elenco delle fonti utilizzate:

Installazione del CEPH
Ripristino da un guasto completo del monitor

Elenchi degli script:

Installazione del sistema tramite 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 6

Crea un gruppo

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

Aggiunta OSD (parte)

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

Riassunto

Il principale vantaggio di marketing di CEPH è CRUSH, un algoritmo per il calcolo della posizione dei dati. I monitor distribuiscono questo algoritmo ai client, dopodiché i client richiedono direttamente il nodo desiderato e l'OSD desiderato. CRUSH garantisce l'assenza di centralizzazione. È un piccolo file che puoi persino stampare e appendere al muro. La pratica ha dimostrato che CRUSH non è una mappa completa. Se distruggi e ricrea i monitor, mantenendo tutti gli OSD e CRUSH, questo non sarà sufficiente per ripristinare il cluster. Da ciò si conclude che ciascun monitor memorizza alcuni metadati sull'intero cluster. La piccola quantità di questi metadati non impone restrizioni sulla dimensione del cluster, ma richiede di garantirne la sicurezza, il che elimina il risparmio sul disco installando il sistema su un'unità flash ed esclude i cluster con meno di tre nodi. La politica aggressiva dello sviluppatore riguardo alle funzionalità opzionali. Lontano dal minimalismo. La documentazione è al livello di “grazie per quello che abbiamo, ma è molto, molto scarsa”. Viene fornita la possibilità di interagire con servizi di basso livello, ma la documentazione tocca questo argomento in modo troppo superficiale, quindi è più probabile un no che un sì. Non c'è praticamente alcuna possibilità di recuperare i dati da una situazione di emergenza.

Opzioni per ulteriori azioni: abbandonare CEPH e utilizzare il banale multi-disco btrfs (o xfs, zfs), scoprire nuove informazioni su CEPH, che vi permetteranno di utilizzarlo nelle condizioni specificate, provare a scrivere il proprio spazio di archiviazione come avanzato formazione.

Fonte: habr.com