🥇Esperienza di utilizzo di CEPH

Quando i dati superano la capacità di un singolo disco, è il momento di pensare al RAID. Da bambino ho spesso sentito dai più grandi: «un giorno il RAID sarà solo un ricordo, gli storage a oggetti conquisteranno il mondo, e tu non saprai nemmeno cosa sia CEPH»; perciò, la prima cosa che ho fatto nella mia vita indipendente è stata creare il mio cluster. L'obiettivo dell'esperimento era familiarizzare con il funzionamento interno di Ceph e capire i limiti della sua applicazione. È giustificato implementare Ceph nelle medie imprese e nelle piccole? Dopo alcuni anni di utilizzo e un paio di perdite irreversibili di dati, sono emerse delle comprensioni sulle complessità, dimostrando che non è tutto così chiaro. Le peculiarità di CEPH creano ostacoli alla sua diffusione e a causa di ciò gli esperimenti si sono arenati. Di seguito viene fornita una descrizione di tutti i passaggi affrontati, i risultati ottenuti e le conclusioni tirate. Se persone competenti condivideranno esperienze e chiariranno alcuni punti, sarò grato.

Nota: i commentatori hanno segnalato errori gravi in alcune assunzioni, che richiedono una revisione dell'intero articolo.

Strategia CEPH

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

Prendiamo in considerazione il caso più semplice con due dischi identici. Da essi si può sia assemblare un RAID 1, sia configurare un cluster con N=2: il risultato sarà lo stesso. Se ci sono tre dischi di dimensioni diverse, è facile creare un cluster con N=2: parte dei dati saranno sui dischi 1 e 2, parte sui dischi 1 e 3, e parte sui dischi 2 e 3, mentre con RAID non è così (si può assemblare un tale RAID, ma sarebbe una forzatura). Se i dischi sono ancora di più, è possibile creare un RAID 5; in CEPH esiste un analogo — erasure_code, che contraddice le precedenti concezioni degli sviluppatori e perciò non è considerato. Il RAID 5 presuppone che ci sia un numero ridotto di dischi e che tutti siano in buone condizioni. In caso di guasto di uno, gli altri devono resistere fino a quando il disco non viene sostituito e i dati non vengono ripristinati. CEPH, invece, con N>=3 incoraggia l'uso di dischi vecchi; in particolare, se si mantengono diversi dischi buoni per conservare una copia dei dati, mentre le restanti due-tre copie sono conservate su un gran numero di dischi vecchi, le informazioni saranno al sicuro, poiché finché i dischi nuovi sono vivi non ci sono problemi, ma se uno di essi si rompe, un guasto simultaneo di tre dischi con più di cinque anni di vita, preferibilmente, provenienti da server diversi, è un evento estremamente improbabile.

Nella distribuzione delle copie c'è una sottigliezza. Per impostazione predefinita si presume che i dati siano suddivisi in un numero più elevato (~100 per disco) di gruppi di distribuzione PG, ognuno dei quali è duplicato su alcuni dischi. Supponiamo che K=6, N=2; in tal caso, con il guasto di due dischi qualsiasi, i dati andranno certamente persi, poiché per legge di probabilità si troverà almeno una PG che si posizionerà proprio su quei due dischi. E la perdita di un gruppo rende inaccessibili tutti i dati nel pool. Se invece i dischi vengono suddivisi in tre coppie e si consente di memorizzare i dati solo sui dischi all'interno di una coppia, tale distribuzione risulta anche resistente al guasto di un qualsiasi disco; tuttavia, in caso di guasto di due dischi, la probabilità di perdita dei dati non è del 100%, ma solo del 3/15, e anche con il guasto di tre dischi — solo del 12/20. Da qui, l'entropia nella distribuzione dei dati non favorisce la tolleranza ai guasti. Notiamo anche che per un server di file, la memoria RAM libera aumenta notevolmente 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 del cluster rispetto a un server singolo e, tanto più, rispetto a un NAS hardware, dove viene integrato un volume di memoria molto ridotto.

Da ciò deriva che CEPH è un buon modo, con un investimento minimo, per creare un sistema di archiviazione dati affidabile su decine di TB utilizzando hardware obsoleto, con possibilità di scalabilità (qui, chiaramente, saranno necessari alcuni costi, ma non elevati rispetto agli storage commerciali).

Implementazione del cluster

Per l'esperimento prenderemo un computer dismesso Intel DQ57TM + Intel core i3 540 + 16 GB di RAM. Organizzeremo quattro dischi da 2 TB in modo simile al RAID10; dopo un successo nel test, aggiungeremo un secondo nodo e altrettanti dischi.

Stiamo installando Linux. Dal distributore richiediamo la possibilità di personalizzazione e stabilità. Debian e Suse soddisfano questi requisiti. Suse ha un installer più flessibile, che consente di disattivare qualsiasi pacchetto; purtroppo, non sono riuscito a capire quali si possano eliminare senza danneggiare il sistema. Installiamo Debian tramite debootstrap buster. L'opzione min-base installa un sistema non funzionante, mancante di driver. La differenza in dimensione rispetto alla versione completa non è così grande da giustificare il problema. Poiché il lavoro viene svolto su una macchina fisica, vogliamo fare snapshot, come nelle macchine virtuali. Questa possibilità è offerta da LVM o btrfs (o xfs o zfs — le differenze non sono significative). Gli snapshot non sono il punto forte di LVM. Installiamo btrfs. E il bootloader — in MBR. Non ha senso intasare il disco con una partizione FAT di 50 MB quando si può inserirla in un'area di 1 MB della tabella delle partizioni ed esaurire tutto lo spazio per il sistema. Ha occupato 700 MB sul disco. Quanto occupa l'installazione di base di SUSE — non me lo ricordo, mi sembra circa 1.1 o 1.4 GB.

Stiamo installando CEPH. Ignoriamo la versione 12 nel repository debian e colleghiamoci direttamente dal sito 15.2.3. Seguiamo le istruzioni nella sezione "installiamo CEPH manualmente" con le seguenti avvertenze:

Prima di collegare il repository, è necessario installare gnupg wget ca-certificates
Dopo aver collegato il repository, ma prima di installare il cluster, è stata omessa l'installazione dei pacchetti: apt -y —no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr

Al momento dell'installazione di CEPH, per motivi poco chiari, cercherà di installare lvm2. In linea di massima, non è un problema, ma l'installazione si interrompe con un errore, quindi anche CEPH non si installerà.

Questo patch ha aiutato:

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

Panoramica del cluster

ceph-osd — si occupa della memorizzazione dei dati su disco. Per ogni disco viene avviato un servizio di rete che riceve e esegue le richieste di lettura o scrittura sugli oggetti. Sul disco vengono creati due partizioni. Una di esse contiene informazioni sul cluster, sul numero del disco e le chiavi del cluster. Queste informazioni, della dimensione di 1KB, sono create una sola volta al momento dell'aggiunta del disco e non ho mai notato modifiche. Nella seconda partizione non c'è un file system e vengono memorizzati i dati binari di CEPH. L'installazione automatica nelle versioni precedenti creava una partizione xfs di 100MB per le informazioni di servizio. Ho convertito il disco in MBR e ho allocato solo 16MB — il servizio non si lamenta. Penso che senza problemi l'xfs potrebbe essere sostituito con l'ext. Questa partizione è montata in /var/lib/…, dove il servizio legge le informazioni sull'OSD e trova il riferimento al dispositivo a blocchi dove sono memorizzati i dati binari. Teoricamente, si possono posizionare subito gli ausiliari in /var/lib/…, mentre l'intero disco potrebbe essere dedicato ai dati. Quando si crea un OSD tramite ceph-deploy, viene automaticamente creata una regola per montare la partizione in /var/lib/…, e inoltre vengono assegnati i diritti all'utente ceph per la lettura del dispositivo a blocchi necessario. In un'installazione manuale, è necessario farlo da soli, nella documentazione non è specificato. È anche consigliabile specificare il parametro osd memory target, affinché ci sia abbastanza memoria fisica.

ceph-mds. A un livello basso, CEPH è un sistema di archiviazione a oggetti. La possibilità di archiviazione a blocchi si riduce al salvataggio di ogni blocco di 4MB come oggetto. Funziona secondo lo stesso principio anche l'archiviazione dei file. Vengono creati due pool: uno per i metadati, l'altro per i dati. Questi vengono uniti in un file system. In quel momento viene creata una sorta di registrazione, quindi se si elimina il file system, ma si mantengono entrambi i pool, non sarà possibile recuperarlo. Esiste una procedura per l'estrazione di file per blocchi, che non ho testato. L'accesso al file system è gestito dal servizio ceph-mds. Per ogni file system è necessario un'istanza separata del servizio. Esiste un'opzione "indice" che consente di creare una sorta di più file system in uno — nemmeno questa è stata testata.

ceph-mon — questo servizio conserva la mappa del cluster. Include informazioni su tutti gli OSD, l'algoritmo di distribuzione dei PG negli OSD e, soprattutto, informazioni su tutti gli oggetti (i dettagli di questo meccanismo non mi sono chiari: esiste un catalogo /var/lib/ceph/mon/…/store.db, che contiene un grande file — 26MB, e nel cluster ci sono 105K oggetti, il che porta a poco più di 256 byte per oggetto; penso quindi che il monitor conservi un elenco di tutti gli oggetti e dei PG in cui si trovano). Il danneggiamento di questo catalogo porta alla perdita di tutti i dati nel cluster. Da ciò si deduce che CRUSH mostra come i PG sono distribuiti sugli OSD, mentre come gli oggetti sono distribuiti sui PG è centralmente memorizzato all'interno del database, indipendentemente dal fatto che gli sviluppatori evitino questa parola. Di conseguenza, in primo luogo, non possiamo installare il sistema su una chiavetta USB in modalità RO, poiché nel database si scrive continuamente; serve un disco aggiuntivo per questi dati (difficilmente più di 1 GB); in secondo luogo, è necessario avere una copia di questo database in tempo reale. Se ci sono più monitor, la ridondanza è garantita automaticamente, ma nel nostro caso c'è un solo monitor, al massimo due. Esiste una procedura teorica per ripristinare il monitor basata sui dati degli OSD; mi sono affidato a essa tre volte per vari motivi, e per tre volte senza alcun messaggio di errore, né dati. Sfortunatamente, questo meccanismo non funziona. O sfruttiamo una piccola partizione su OSD e creiamo un RAID per memorizzare il database, il che sicuramente influirà negativamente sulle prestazioni, oppure dedichiamo almeno due supporti fisici affidabili, preferibilmente USB, per non occupare porte.

rados-gw — esporta lo storage a oggetti tramite il protocollo S3 e simili. Crea molti pool, ma non è chiaro a cosa servano. Non ho sperimentato molto.

ceph-mgr — con l'installazione di questo servizio vengono avviati diversi moduli. Uno di questi è l'autoscale, che non può essere disattivato. Si propone di mantenere il numero corretto di PG/OSD. Se si desidera gestire manualmente il rapporto, è possibile disabilitare la scalabilità per ogni pool, ma in questo caso il modulo va in errore a causa di una divisione per zero e lo stato del cluster diventa ERROR. Il modulo è scritto in Python e se si commenta la riga necessaria, questo porta alla sua disattivazione. Non ho voglia di ricordare i dettagli.

Elenco delle fonti utilizzate:

Installazione di CEPH
Ripristino in caso di guasto totale del monitor

Elenco 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 < /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

Creazione del 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

# 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

Riepilogo

Il principale vantaggio di marketing di CEPH è CRUSH, un algoritmo per il calcolo della posizione dei dati. I monitor distribuiscono questo algoritmo ai clienti, i quali richiedono direttamente il nodo e l'OSD necessari. CRUSH garantisce l'assenza di centralizzazione. È un piccolo file che può anche essere stampato e appeso al muro. L'esperienza ha dimostrato che CRUSH non è una mappa esaustiva. Se si distruggono e ricreano i monitor, mantenendo tutti gli OSD e CRUSH, ciò non è sufficiente per ripristinare il cluster. Ne consegue che su ogni monitor vengono memorizzati alcuni metadati su tutto il cluster. Il volume limitato di questi metadati non impone restrizioni sulle dimensioni del cluster, ma richiede di garantirne la sicurezza, escludendo così la possibilità di risparmiare spazio su disco installando il sistema su una chiavetta USB e escludendo cluster con meno di tre nodi. Una politica aggressiva degli sviluppatori riguardo le funzionalità opzionali. Lontano dal minimalismo. La documentazione è a livello: "per ciò che c'è, già grazie, ma molto, molto scarsa". C'è la possibilità di interagire con i servizi a basso livello, ma la documentazione tocca questo argomento in modo troppo superficiale, quindi è più probabile che sia no rispetto a sì. Praticamente nessuna possibilità di recuperare dati da situazioni anomale.

Opzioni per i prossimi passi: abbandonare CEPH e utilizzare un banale file system multi-disco come btrfs (o xfs, zfs), acquisire nuove informazioni su CEPH che consentano di sfruttarlo nelle condizioni specificate, provare a scrivere un proprio sistema di archiviazione come forma di aggiornamento professionale.

Fonte: habr.com