Cando hai máis datos dos que caben nun disco, é hora de pensar en RAID. Cando era neno, a miúdo escoitaba aos meus maiores: "Algún día o RAID será cousa do pasado, o almacenamento de obxectos encherá o mundo e nin sequera sabes o que é CEPH", así que o primeiro na miña vida independente. foi crear o meu propio clúster. O propósito do experimento foi familiarizarse coa estrutura interna do ceph e comprender o alcance da súa aplicación. Como se xustifica a implantación de ceph nas medianas e pequenas empresas? Despois de varios anos de funcionamento e un par de perdas irreversibles de datos, xurdiu a comprensión das complejidades de que non todo é tan sinxelo. As peculiaridades do CEPH supoñen barreiras para a súa adopción xeneralizada e, por mor delas, os experimentos chegaron a un camiño sen saída. A continuación describimos todos os pasos realizados, o resultado obtido e as conclusións extraídas. Se persoas coñecedoras comparten a súa experiencia e explican algúns puntos, estarei agradecido.
Nota: Os comentaristas identificaron erros graves nalgúns dos supostos que requiren a revisión de todo o artigo.
Estratexia CEPH
O clúster CEPH combina un número K arbitrario de discos de tamaño arbitrario e almacena datos neles, duplicando cada peza (4 MB por defecto) un número determinado N veces.
Consideremos o caso máis sinxelo con dous discos idénticos. A partir deles podes montar RAID 1 ou un clúster con N=2; o resultado será o mesmo. Se hai tres discos e son de diferentes tamaños, entón é fácil montar un cluster con N=2: algúns dos datos estarán nos discos 1 e 2, outros nos discos 1 e 3 e outros estarán nos discos 2 e 3. en 5 e 5, mentres que RAID non o fará (podes montar un RAID deste tipo, pero sería unha perversión). Se aínda hai máis discos, entón é posible crear RAID 3; CEPH ten un analóxico - erasure_code, que contradí os primeiros conceptos dos desenvolvedores e, polo tanto, non se considera. RAID XNUMX asume que hai un pequeno número de unidades, todas elas en bo estado. Se un falla, os outros deben aguantar ata que o disco sexa substituído e os datos sexan restaurados nel. CEPH, con N>=XNUMX, fomenta o uso de discos antigos, en particular, se garda varios discos bos para almacenar unha copia de datos e almacena as dúas ou tres copias restantes nun gran número de discos antigos, entón a información estará seguro, xa que de momento os discos novos están vivos: non hai problemas e, se un deles se rompe, o fallo simultáneo de tres discos cunha vida útil de máis de cinco anos, preferiblemente desde servidores diferentes, é moi improbable. evento.
Hai unha sutileza na distribución das copias. Por defecto, asúmese que os datos están divididos en máis (~100 por disco) grupos de distribución PG, cada un dos cales está duplicado nalgúns discos. Digamos K=6, N=2, entón se fallan dous discos calquera, os datos están garantidos, xa que, segundo a teoría da probabilidade, haberá polo menos un PG que estará situado nestes dous discos. E a perda dun grupo fai que todos os datos do grupo non estean dispoñibles. Se os discos están divididos en tres pares e só se permite almacenar os datos en discos dentro dun par, esa distribución tamén é resistente ao fallo dun disco, pero se fallan dous discos, a probabilidade de perda de datos non é. 100%, pero só 3/15, e mesmo en caso de falla tres discos - só 12/20. Polo tanto, a entropía na distribución de datos non contribúe á tolerancia a fallos. Teña en conta tamén que para un servidor de ficheiros, a memoria RAM libre aumenta significativamente a velocidade de resposta. Canta máis memoria hai en cada nodo e canto máis memoria hai en todos os nodos, máis rápido será. Esta é, sen dúbida, unha vantaxe dun clúster sobre un único servidor e, máis aínda, dun NAS de hardware, onde se incorpora unha cantidade moi pequena de memoria.
Polo tanto, CEPH é unha boa forma de crear un sistema de almacenamento de datos fiable para decenas de TB con capacidade de escalar cun investimento mínimo de equipos obsoletos (aquí, por suposto, serán necesarios custos, pero pequenos en comparación cos sistemas de almacenamento comerciais).
Implementación de clústeres
Para o experimento, tomemos un ordenador desmantelado Intel DQ57TM + Intel core i3 540 + 16 GB de RAM. Organizaremos catro discos de 2 TB en algo así como RAID10, despois dunha proba exitosa engadiremos un segundo nodo e o mesmo número de discos.
Instalando Linux. A distribución require a capacidade de personalizar e ser estable. Debian e Suse cumpren os requisitos. Suse ten un instalador máis flexible que che permite desactivar calquera paquete; Desafortunadamente, non puiden descubrir cales se podían tirar sen danar o sistema. Instale Debian usando debootstrap buster. A opción min-base instala un sistema averiado que carece de controladores. A diferenza de tamaño en comparación coa versión completa non é tan grande como para molestar. Dado que o traballo se realiza nunha máquina física, quero facer instantáneas, como nas máquinas virtuais. Esta opción é proporcionada por LVM ou btrfs (ou xfs ou zfs - a diferenza non é grande). As instantáneas de LVM non son un punto forte. Instalar btrfs. E o cargador de arranque está no MBR. Non ten sentido desordenar un disco de 50 MB cunha partición FAT cando pode empurralo nunha área de táboa de particións de 1 MB e asignar todo o espazo para o sistema. Ocupou 700 MB no disco. Non recordo canto ten a instalación básica de SUSE, creo que son 1.1 ou 1.4 GB.
Instalar CEPH. Ignoramos a versión 12 no repositorio debian e conectámonos directamente desde o sitio 15.2.3. Seguimos as instrucións da sección "Instalar CEPH manualmente" coas seguintes advertencias:
- Antes de conectar o repositorio, debes instalar gnupg wget ca-certificates
- Despois de conectar o repositorio, pero antes de instalar o clúster, omítese a instalación de paquetes: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- Ao instalar CEPH, por razóns descoñecidas, tentará instalar lvm2. En principio, non é unha mágoa, pero a instalación falla, polo que CEPH tampouco se instalará.
Este parche axudou:
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ón xeral do clúster
ceph-osd - é responsable de almacenar os datos no disco. Para cada disco, lánzase un servizo de rede que acepta e executa solicitudes de lectura ou escritura en obxectos. No disco créanse dúas particións. Un deles contén información sobre o clúster, o número de disco e as claves do clúster. Esta información de 1 KB créase unha vez ao engadir un disco e nunca se viu que cambia. A segunda partición non ten sistema de ficheiros e almacena datos binarios CEPH. A instalación automática nas versións anteriores creou unha partición xfs de 100 MB para a información do servizo. Convertín o disco a MBR e asignei só 16 MB: o servizo non se queixa. Creo que xfs podería substituírse por ext sen ningún problema. Esta partición está montada en /var/lib/…, onde o servizo le información sobre o OSD e tamén atopa unha referencia ao dispositivo de bloque onde se almacenan os datos binarios. Teoricamente, pode colocar inmediatamente ficheiros auxiliares en /var/lib/… e asignar todo o disco para os datos. Ao crear un OSD mediante ceph-deploy, créase automaticamente unha regra para montar a partición en /var/lib/... e ao usuario de ceph tamén se lle asignan dereitos para ler o dispositivo de bloque desexado. Se instalas manualmente, debes facelo ti mesmo; a documentación non o indica. Tamén é recomendable especificar o parámetro de destino da memoria osd para que haxa memoria física suficiente.
ceph-mds. Nun nivel baixo, CEPH é almacenamento de obxectos. A capacidade de bloquear o almacenamento redúcese a almacenar cada bloque de 4 MB como un obxecto. O almacenamento de ficheiros funciona co mesmo principio. Créanse dous grupos: un para metadatos e outro para datos. Combínanse nun sistema de ficheiros. Neste momento, créase algún tipo de rexistro, polo que se elimina o sistema de ficheiros, pero mantén os dous grupos, non poderás restauralo. Hai un procedemento para extraer ficheiros por bloques, non o probei. O servizo ceph-mds é responsable do acceso ao sistema de ficheiros. Cada sistema de ficheiros require unha instancia separada do servizo. Hai unha opción de "índice", que che permite crear a apariencia de varios sistemas de ficheiros nun só, tampouco probado.
Ceph-mon: este servizo almacena un mapa do clúster. Inclúe información sobre todos os OSD, un algoritmo para distribuír PG en OSD e, o máis importante, información sobre todos os obxectos (non me queda claro os detalles deste mecanismo: hai un directorio /var/lib/ceph/mon/…/). store.db, contén un ficheiro grande de 26 MB, e nun clúster de 105K obxectos, resulta ser algo máis de 256 bytes por obxecto. Creo que o monitor almacena unha lista de todos os obxectos e os PG nos que están situados). O dano a este directorio provoca a perda de todos os datos do clúster. De aí que se chegou a conclusión de que CRUSH mostra como se sitúan as PG no OSD e como se sitúan os obxectos nas PG: almacénanse centralmente dentro da base de datos, por moito que os desenvolvedores eviten esta palabra. Como resultado, en primeiro lugar, non podemos instalar o sistema nunha unidade flash en modo RO, xa que a base de datos está a ser gravada constantemente, é necesario un disco adicional para estes (apenas máis de 1 GB), en segundo lugar, é necesario ter un copia en tempo real esta base. Se hai varios monitores, a tolerancia a fallos está garantida automaticamente, pero no noso caso só hai un monitor, como máximo dous. Hai un procedemento teórico para restaurar un monitor baseado en datos OSD, recorrín a el tres veces por varios motivos, e tres veces non houbo mensaxes de erro, así como ningún dato. Desafortunadamente, este mecanismo non funciona. Ou operamos unha partición en miniatura no OSD e montamos un RAID para almacenar a base de datos, o que seguramente repercutirá moi mal no rendemento, ou ben asignamos polo menos dous medios físicos fiables, preferentemente USB, para non ocupar portos.
rados-gw - exporta almacenamento de obxectos a través do protocolo S3 e similares. Crea moitas piscinas, non está claro por que. Non experimentei moito.
ceph-mgr - Ao instalar este servizo, lánzanse varios módulos. Un deles é a escala automática que non se pode desactivar. Esfórzase por manter a cantidade correcta de PG/OSD. Se queres controlar a proporción manualmente, podes desactivar a escala para cada grupo, pero neste caso o módulo falla cunha división por 0 e o estado do clúster pasa a ser ERROR. O módulo está escrito en Python, e se comentas a liña necesaria nel, isto leva á súa desactivación. Demasiado preguiceiro lembrar os detalles.
Lista de fontes utilizadas:
Listas de guións:
Instalación do sistema mediante 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 6Crear 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@rbd1Engadindo 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@$osdnumResumo
A principal vantaxe de mercadotecnia de CEPH é CRUSH, un algoritmo para calcular a localización dos datos. Os monitores distribúen este algoritmo aos clientes, despois do cal os clientes solicitan directamente o nodo desexado e o OSD desexado. CRUSH garante ningunha centralización. É un pequeno arquivo que incluso podes imprimir e colgar na parede. A práctica demostrou que CRUSH non é un mapa exhaustivo. Se destrúes e recreas os monitores, mantendo todos os OSD e CRUSH, isto non é suficiente para restaurar o clúster. A partir diso conclúese que cada monitor almacena algúns metadatos sobre todo o clúster. A pequena cantidade destes metadatos non impón restricións ao tamaño do clúster, senón que esixe garantir a súa seguridade, o que elimina o aforro de disco ao instalar o sistema nunha unidade flash e exclúe os clústeres con menos de tres nodos. A agresiva política do programador sobre as funcións opcionais. Lonxe do minimalismo. A documentación está a nivel de "grazas polo que temos, pero é moi, moi escasa". Ofrécese a capacidade de interactuar con servizos a un nivel baixo, pero a documentación toca este tema de forma demasiado superficial, polo que é máis probable un non que un si. Non hai practicamente ningunha posibilidade de recuperar datos dunha situación de emerxencia.
Opcións de acción adicional: abandone CEPH e use o btrfs multidisco banal (ou xfs, zfs), descubra nova información sobre CEPH, que lle permitirá operalo nas condicións especificadas, intente escribir o seu propio almacenamento como un dispositivo avanzado. formación.
Fonte: www.habr.com