Quando i dati superano la capacità di un singolo disco, è il momento di considerare il RAID. Da bambino, spesso sentivo dai più grandi: «un giorno il RAID sarà obsoleto, gli storage a oggetti conquisteranno il mondo, e tu non saprai nemmeno cos'è CEPH»; così, la prima cosa che ho fatto nella mia vita autonoma è stata creare il mio cluster. L'obiettivo dell'esperimento era familiarizzare con il funzionamento interno di Ceph e comprendere i suoi ambiti di applicazione. Quanto è giustificato l'uso di Ceph nelle medie imprese, e nelle piccole? Dopo alcuni anni di utilizzo e un paio di perdite irreversibili di dati, ho acquisito consapevolezza delle sottili complessità e che non è tutto così chiaro. Le peculiarità di CEPH ostacolano la sua diffusione e a causa di esse gli esperimenti sono giunti a un vicolo cieco. Di seguito è riportata una descrizione di tutti i passaggi affrontati, il risultato ottenuto e le conclusioni tratte. Se persone esperte potessero condividere le loro esperienze e chiarire alcuni punti, sarei grato.
Nota: i commentatori hanno evidenziato gravi errori in alcune assunzioni, che richiedono una revisione dell'intero articolo.
Strategia CEPH
Il cluster CEPH unisce un numero arbitrario di dischi di dimensioni variabili e archivia i dati su di essi, duplicando ogni pezzo (4 MB per impostazione predefinita) un numero N di volte.
Consideriamo il caso più semplice con due dischi identici. Da questi, è possibile formare un RAID 1 o un cluster con N=2 – in entrambi i casi il risultato sarà lo stesso. Se i dischi sono tre e di dimensioni diverse, è facile formare un cluster con N=2: parte dei dati sarà sui dischi 1 e 2, parte su 1 e 3, e parte su 2 e 3, mentre un RAID non è possibile (si può formare un RAID del genere, ma sarebbe un'anomalia). Se ci sono ancora più dischi, è possibile creare un RAID 5, per CEPH c'è un analogo – erasure_code, che contraddice le precedenti concezioni degli sviluppatori e quindi non viene considerato. Il RAID 5 presuppone un numero ridotto di dischi, tutti in buone condizioni. In caso di guasto di uno, gli altri devono resistere fino alla sostituzione del disco e al ripristino dei dati. CEPH, d'altra parte, con N>=3, incoraggia l'uso di dischi usati, in particolare, se si mantiene una buona quantità di dischi per memorizzare una copia dei dati, mentre le altre due o tre copie vengono conservate su un gran numero di dischi usati, le informazioni saranno al sicuro, poiché finché i dischi nuovi sono operativi, non ci sono problemi; se uno di essi si guasta, la contemporanea rottura di tre dischi con un'età superiore ai cinque anni, preferibilmente provenienti da server diversi, è un evento estremamente improbabile.
Nella distribuzione delle copie esiste una sottigliezza. Di default, si presume che i dati siano divisi in un numero maggiore (~100 per disco) di gruppi di distribuzione PG, ognuno dei quali è duplicato su alcuni dischi. Supponiamo K=6, N=2, allora in caso di guasto di due dischi qualsiasi, i dati andranno sicuramente perduti, poiché la teoria delle probabilità indicherebbe che ci sarà almeno un PG posizionato proprio su quei due dischi. E la perdita di un gruppo rende inaccessibili tutti i dati nel pool. Se invece i dischi sono divisi in tre coppie e si consente di memorizzare i dati solo sui dischi all'interno di una coppia, tale distribuzione risulta ugualmente resiliente al guasto di un qualsiasi disco, però in caso di guasto di due, la probabilità di perdita dei dati non è del 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 resilienza ai guasti. Si noti inoltre che per un server di file, una maggiore memoria RAM disponibile aumenta significativamente la velocità di risposta. Maggiore è la memoria in ogni nodo e maggiore è la memoria in tutti i nodi, più veloce sarà il sistema. Questo è indubbiamente un vantaggio del cluster rispetto a un singolo server e, tanto più, rispetto a un NAS hardware, che integra un volume di memoria molto limitato.
Da ciò si evince che CEPH è un ottimo modo per creare un sistema di archiviazione dati affidabile da decine di TB con investimenti minimi a partire da hardware obsoleto, con possibilità di scalabilità (qui, certo, saranno necessari dei costi, ma contenuti rispetto ai sistemi di archiviazione commerciale).
Implementazione del cluster
Per l'esperimento utilizzeremo un computer dismesso Intel DQ57TM + Intel core i3 540 + 16 GB di RAM. Organizeremo quattro dischi da 2 TB in una configurazione simile al RAID10, e dopo un test riuscito aggiungeremo un secondo nodo e altri dischi.
Installiamo Linux. Il sistema operativo deve essere personalizzabile e stabile. I requisiti sono soddisfatti da Debian e Suse. Suse ha un'installazione più flessibile, che consente di disattivare qualsiasi pacchetto; sfortunatamente, non sono riuscito a capire quali si possano rimuovere senza compromettere il sistema. Installiamo Debian tramite debootstrap buster. L'opzione min-base installa un sistema non funzionante, privo di driver. La differenza di dimensioni rispetto alla versione completa non è così grande da giustificare la complicazione. Poiché il lavoro viene svolto su una macchina fisica, è utile fare snapshot, come si farebbe su macchine virtuali. Questa possibilità è offerta da LVM o btrfs (o xfs, o zfs — la differenza non è molta). Con LVM, gli snapshot non sono il punto di forza. Optiamo per btrfs. E il bootloader — in MBR. Non ha senso riempire il disco con 50 MB di partizione FAT, quando si può includere nella tabella delle partizioni in 1 MB e dedicare tutto lo spazio al sistema. Ha occupato 700 MB sul disco. Non ricordo quanto occupa l'installazione base di SUSE — mi sembra circa 1.1 o 1.4 GB.
Installiamo CEPH. Ignoriamo la versione 12 nel repository Debian e ci colleghiamo direttamente al sito 15.2.3. Seguiamo le istruzioni nella sezione "installiamo CEPH manualmente" con le seguenti note:
- 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
- Durante l'installazione di CEPH, per motivi non chiari, cercherà di installare lvm2. In linea di massima, non è un problema, ma l'installazione termina con un errore, quindi anche CEPH non verrà installato.
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 — gestisce la memorizzazione dei dati su disco. Per ogni disco viene avviato un servizio di rete che accetta ed esegue richieste di lettura o scrittura su oggetti. Sul disco vengono creatte due partizioni. Una di esse contiene informazioni sul cluster, sul numero del disco e sulle chiavi del cluster. Queste informazioni, della dimensione di 1 KB, vengono create una sola volta quando si aggiunge un disco e non ho mai notato cambiamenti successivi. Nella seconda partizione non c'è un file system e vengono memorizzati dati binari CEPH. Le installazioni automatiche delle versioni precedenti creavano una partizione xfs di dimensioni 100 MB per le informazioni di servizio. Ho convertito il disco in MBR e ho allocato solo 16 MB — il servizio non si lamenta. Penso che senza problemi xfs potrebbe essere sostituito anche da ext. Questa partizione viene montata in /var/lib/…, dove il servizio legge le informazioni sull'OSD e trova anche il riferimento al dispositivo a blocchi dove sono memorizzati i dati binari. Teoricamente, si potrebbero posizionare direttamente i dati ausiliari in /var/lib/…, e riservare l'intero disco per i dati. Quando si crea un OSD tramite ceph-deploy, viene automaticamente creata una regola per montare la partizione in /var/lib/…, e vengono assegnati i diritti all'utente ceph per la lettura del dispositivo a blocchi necessario. Durante l'installazione manuale, è necessario farlo manualmente; nella documentazione non viene menzionato. È anche consigliabile specificare il parametro osd memory target, in modo che ci sia sufficiente memoria fisica.
ceph-mds. A livello base, CEPH è uno storage object. La possibilità di storage a livello block si riduce a salvare ogni blocco di 4MB come oggetto. Lo storage file funziona sulla stessa base. Si creano due pool: uno per i metadati e l'altro per i dati. Questi vengono combinati in un file system. In questo momento, viene creata una sorta di registrazione; quindi, se si elimina il file system ma si conservano entrambi i pool, non sarà possibile recuperarlo. Esiste una procedura per estrarre file a livello di blocchi, che non è stata testata. La gestione dell'accesso al file system è affidata al servizio ceph-mds. Per ogni file system è necessario un'istanza separata del servizio. C'è un'opzione "indice" che consente di creare una sorta di più file system in uno — anche questa non è stata testata.
ceph-mon — questo servizio memorizza 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: c'è un catalogo /var/lib/ceph/mon/.../store.db, all'interno del quale si trova un grande file — 26MB, e nel cluster ci sono 105K oggetti, risultando in poco più di 256 byte per oggetto; penso che il monitor memorizzi un elenco di tutti gli oggetti e dei PG in cui si trovano). La corruzione di questo catalogo porta alla perdita di tutti i dati nel cluster. Da ciò si deduce che CRUSH mostra come i PG siano disposti sugli OSD e come gli oggetti siano disposti sui PG — vengono memorizzati centralmente all'interno del database, nonostante gli sviluppatori cerchino di evitare questa parola. Di conseguenza, innanzitutto, non possiamo installare il sistema su una chiavetta USB in modalità RO, poiché nel database avviene una scrittura continua; è necessario un disco aggiuntivo per questi (difficilmente più di 1 GB); in secondo luogo, è necessario avere una copia di questo database in tempo reale. Se ci sono più monitor, la tolleranza agli errori è garantita automaticamente, ma nel nostro caso c'è un solo monitor, al massimo due. Esiste una procedura teorica per il ripristino del monitor basata sui dati degli OSD; ci ho provato tre volte per diversi motivi, e tre volte non ci sono stati messaggi di errore, così come dati. Sfortunatamente, questo meccanismo non funziona. O sfruttiamo una partizione miniaturizzata sugli OSD e creiamo un RAID per memorizzare il database, il che sicuramente influenzerà negativamente le prestazioni, oppure dedichiamo almeno due supporti fisici affidabili, preferibilmente USB, per non occupare le porte.
rados-gw — esporta lo storage oggetti tramite il protocollo S3 e simili. Crea molteplici pool, senza un chiaro motivo. Non ho sperimentato molto.
ceph-mgr — durante l'installazione di questo servizio, vengono avviati diversi moduli. Uno di essi è l'autoscale, che non è disattivabile. Cerca di mantenere il giusto numero di PG/OSD. Se desideri gestire manualmente il rapporto, puoi disabilitare la scalabilità per ogni pool, ma in tal caso il modulo genera un errore di divisione per zero e lo stato del cluster diventa ERROR. Il modulo è scritto in Python e se si commenta la riga necessaria, ciò porta alla sua disattivazione. Dettagli che non ho voglia di ricordare.
Elenco delle fonti utilizzate:
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 6Creazione 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@rbd1Aggiunta 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@$osdnumRiepilogo
Il principale vantaggio di marketing di CEPH è il CRUSH, un algoritmo per il calcolo della posizione dei dati. I monitor condividono questo algoritmo con i clienti, che possono quindi richiedere direttamente il nodo desiderato e l'OSD correlato. CRUSH garantisce l'assenza di centralizzazione. È un file di dimensioni ridotte, che si può persino stampare e appendere al muro. Tuttavia, l'esperienza ha dimostrato che CRUSH non costituisce una mappa esaustiva. Se si distruggono e ricreano i monitor, mantenendo tutti gli OSD e il CRUSH, ciò non è sufficiente per il ripristino del cluster. Da ciò deriva che ogni monitor contiene alcune metadata riguardanti l'intero cluster. La modesta quantità di questi metadata non impone limiti sulle dimensioni del cluster, ma richiede la loro conservazione, il che esclude il risparmio di spazio disco installando il sistema su una chiavetta USB e il funzionamento di cluster con meno di tre nodi. La politica del sviluppatore riguardo le funzionalità opzionali è molto aggressiva. Si è lontani dal minimalismo. La documentazione è a livello: 'siamo già grati per ciò che c'è, ma è estremamente scarsa'. È prevista la possibilità di interazione con i servizi a basso livello, ma la documentazione tocca questo argomento in modo troppo superficiale, quindi è più probabile che non sia possibile. Praticamente nessuna possibilità di recuperare dati da una situazione anomala.
Opzioni per i prossimi passi: rinunciare a CEPH e utilizzare un comune btrfs multi-disco (o xfs, zfs), acquisire nuove informazioni su CEPH che consentano di utilizzarlo nelle condizioni indicate, provare a scrivere un proprio sistema di archiviazione come forma di aggiornamento delle competenze.
Fonte: habr.com
