Cuando hay más datos de los que caben en un disco, es hora de pensar en RAID. Cuando era niño, a menudo escuchaba de mis mayores: "un día, RAID se convertirá en una cosa del pasado, el almacenamiento de objetos inundará el mundo y ni siquiera sabrá qué es CEPH", por lo que lo primero en una vida independiente estaba creando su propio clúster. El propósito del experimento era familiarizarse con la estructura interna de ceph y comprender el alcance de su aplicación. ¿Qué tan justificada está la introducción de ceph en una mediana empresa, pero en una pequeña? Después de varios años de operación y un par de pérdidas de datos irreversibles, surgió una comprensión de las sutilezas de que no todo es tan simple. Las características de CEPH crean obstáculos para su amplia distribución y, debido a ellas, los experimentos se han detenido. A continuación se describen todos los pasos realizados, el resultado obtenido y las conclusiones extraídas. Si las personas con conocimientos comparten su experiencia y explican algunos puntos, se lo agradeceré.
Nota: Los comentaristas han señalado errores graves en algunas de las suposiciones, lo que requiere una revisión de todo el artículo.
estrategia CEPH
El clúster CEPH combina un número arbitrario K de discos de tamaño arbitrario y almacena datos en ellos, duplicando cada pieza (4 MB por defecto) un número determinado N veces.
Considere el caso más simple con dos discos idénticos. Puede ensamblar un RAID 1 o un clúster con N = 2 a partir de ellos; el resultado será el mismo. Si hay tres discos y son de diferentes tamaños, entonces es fácil ensamblar un clúster con N=2: algunos de los datos estarán en los discos 1 y 2, algunos en el 1 y 3, y algunos en el 2 y 3 , mientras que RAID no lo es (puede recopilar tal RAID, pero sería una perversión). Si hay aún más discos, entonces es posible crear RAID 5, CEPH tiene un código de borrado análogo, que contradice los primeros conceptos de los desarrolladores y, por lo tanto, no se considera. RAID 5 asume que hay una pequeña cantidad de discos y que todos ellos están en buenas condiciones. Si uno falla, el resto debe resistir hasta que se reemplace el disco y se restauren los datos. CEPH, con N>=3, fomenta el uso de discos antiguos, en particular, si mantiene varios discos buenos para almacenar una copia de datos y almacena las dos o tres copias restantes en una gran cantidad de discos antiguos, entonces la información será seguro, porque por ahora los discos nuevos están vivos; no hay problemas, y si uno de ellos se rompe, entonces la falla simultánea de tres discos con una vida útil de más de cinco años, preferiblemente de diferentes servidores, es extremadamente improbable evento.
Hay una sutileza en la distribución de copias. De forma predeterminada, se supone que los datos se dividen en más grupos de distribución de PG (~100 por disco), cada uno de los cuales se duplica en algunos discos. Supongamos que K=6, N=2, entonces si fallan dos discos cualquiera, se garantiza la pérdida de datos, ya que de acuerdo con la teoría de la probabilidad, habrá al menos un PG que se ubicará en estos dos discos. Y la pérdida de un grupo hace que todos los datos del grupo sean inaccesibles. Si los discos se dividen en tres pares y se les permite almacenar datos solo en discos dentro de un par, dicha distribución también es resistente a la falla de cualquier disco, pero si fallan dos, la probabilidad de pérdida de datos no es del 100%, pero solo 3/15, e incluso en caso de falla tres discos, solo 12/20. Por lo tanto, la entropía en la distribución de datos no contribuye a la tolerancia a fallas. También tenga en cuenta que para un servidor de archivos, la memoria RAM libre aumenta en gran medida la capacidad de respuesta. Cuanta más memoria haya en cada nodo y más memoria en todos los nodos, más rápido será. Esta es sin duda la ventaja de un clúster sobre un único servidor y, además, un NAS de hardware, donde se construye una cantidad muy pequeña de memoria.
De ello se deduce que CEPH es una buena manera de crear un sistema de almacenamiento confiable para decenas de TB con la posibilidad de escalar con una inversión mínima a partir de equipos obsoletos (aquí, por supuesto, se requerirán costos, pero pequeños en comparación con los sistemas de almacenamiento comerciales).
Implementación de clústeres
Para el experimento, tomemos una computadora fuera de servicio Intel DQ57TM + Intel core i3 540 + 16 GB de RAM. Organizamos cuatro discos de 2 TB en algo así como RAID10, después de una prueba exitosa agregaremos un segundo nodo y la misma cantidad de discos.
Instalar Linux. Se requiere que la distribución sea personalizable y estable. Debian y Suse cumplen los requisitos. Suse tiene un instalador más flexible que le permite deshabilitar cualquier paquete; desafortunadamente, no pude entender cuáles se pueden desechar sin dañar el sistema. Instale Debian a través de Debootstrap Buster. La opción min-base instala un sistema que no funciona y carece de controladores. La diferencia de tamaño con respecto a la versión completa no es tan grande como para molestar. Dado que el trabajo se realiza en una máquina física, quiero tomar instantáneas, al igual que en las máquinas virtuales. Ya sea LVM o btrfs (o xfs o zfs, la diferencia no es grande) brinda esa oportunidad. Las instantáneas no son el fuerte de LVM. Instalar btrfs. Y el gestor de arranque está en el MBR. No tiene sentido obstruir un disco de 50 MB con una partición FAT cuando puede insertarlo en un área de tabla de partición de 1 MB y asignar todo el espacio para el sistema. Tomó 700 MB en el disco. Cuánto tiene la instalación base de SUSE: no recuerdo, parece, alrededor de 1.1 o 1.4 GB.
Instalar CEPH. Ignoramos la versión 12 en el repositorio de debian y nos conectamos directamente desde el sitio 15.2.3. Seguimos las instrucciones de la sección "Instalación manual de CEPH" con las siguientes advertencias:
- Antes de conectar el repositorio, debe instalar gnupg wget ca-certificates
- Después de conectar el repositorio, pero antes de instalar el clúster, se omite la instalación del paquete: apt -y --no-install-recommends install ceph-common ceph-mon ceph-osd ceph-mds ceph-mgr
- En el momento de la instalación de CEPH, por razones desconocidas, intentará instalar lvm2. En principio, no es una pena, pero la instalación falla, por lo que CEPH tampoco se instalará.
Este parche ayudó:
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
Descripción general del clúster
ceph-osd - responsable de almacenar datos en el disco. Para cada disco, se inicia un servicio de red que acepta y ejecuta solicitudes para leer o escribir objetos. Se crean dos particiones en el disco. Uno de ellos contiene información sobre el clúster, el número de disco y las claves del clúster. Esta información de 1 KB se crea una vez al agregar un disco y nunca se notó que cambia nuevamente. La segunda partición no tiene sistema de archivos y almacena datos binarios CEPH. La instalación automática en versiones anteriores creaba una partición xfs de 100 MB para la información del servicio. Convertí el disco a MBR y asigné solo 16 MB; el servicio no se queja. Creo que, sin problemas, se podría reemplazar xfs por ext. Esta partición está montada en /var/lib/… donde el servicio lee información sobre el OSD y también encuentra un enlace al dispositivo de bloque donde se almacenan los datos binarios. Teóricamente, puede colocar inmediatamente los auxiliares en / var / lib / ... y asignar todo el disco para datos. Al crear un OSD a través de ceph-deploy, se crea automáticamente una regla para montar una partición en /var/lib/… y se asignan los derechos al usuario de ceph para leer el dispositivo de bloque deseado. Con una instalación manual, debe hacerlo usted mismo, la documentación no lo dice. También es recomendable especificar el parámetro de destino de memoria osd para que haya suficiente memoria física.
ceph-mds. En un nivel bajo, CEPH es almacenamiento de objetos. La capacidad de almacenamiento de bloques se reduce a guardar cada bloque de 4 MB como un objeto. El almacenamiento de archivos funciona según el mismo principio. Se crean dos grupos: uno para metadatos y otro para datos. Se combinan en un sistema de archivos. En este momento, se crea algún tipo de registro, por lo que si elimina el sistema de archivos, pero guarda ambos grupos, no podrá restaurarlo. Hay un procedimiento para extraer archivos en bloques, no lo he probado. El servicio ceph-mds es responsable de acceder al sistema de archivos. Cada sistema de archivos requiere una instancia separada del servicio. Hay una opción de "índice" que le permite crear una apariencia de varios sistemas de archivos en uno, tampoco probado.
ceph-mon: este servicio mantiene un mapa del clúster. Incluye información sobre todos los OSD, el algoritmo de distribución de PG en el OSD y, lo que es más importante, información sobre todos los objetos (los detalles de este mecanismo no me quedan claros: hay un /var/lib/ceph/mon/…/ directorio store.db, contiene un archivo grande de 26 MB, y en un grupo de 105K objetos, resulta un poco más de 256 bytes por objeto. Creo que el monitor mantiene una lista de todos los objetos y el PG en el que ellos mienten). El daño a este directorio da como resultado la pérdida de todos los datos en el clúster. A partir de aquí, se concluyó que CRUSH muestra cómo se ubican los PG de acuerdo con OSD y cómo se ubican los objetos de acuerdo con PG: se almacenan centralmente dentro de la base de datos, sin importar cómo los desarrolladores eviten esta palabra. Como resultado, en primer lugar, no podemos instalar el sistema en una unidad flash en modo RO, ya que la base de datos se escribe constantemente, se necesita un disco adicional para estos (apenas más de 1 GB), y en segundo lugar, es necesario tener una copia en tiempo real de esta base. Si hay varios monitores, la tolerancia a fallas se proporciona automáticamente, pero en nuestro caso solo hay un monitor, máximo dos. Hay un procedimiento teórico para restaurar un monitor basado en datos OSD, recurrí a él tres veces por varias razones, y tres veces sin mensajes de error, así como datos también. Desafortunadamente, este mecanismo no funciona. O operamos una partición OSD en miniatura y ensamblamos un RAID para almacenar la base de datos, lo que probablemente tendrá un efecto muy negativo en el rendimiento, o asignamos al menos dos medios físicos confiables, preferiblemente USB, para que los puertos no ocupen.
rados-gw: exporta el almacenamiento de objetos utilizando el protocolo S3 y similares. Crea muchas piscinas, no está claro por qué. Realmente no experimenté.
ceph-mgr: la instalación de este servicio inicia varios módulos. Uno de ellos es el escalado automático no deshabilitado. Se esfuerza por mantener el número correcto de PG/OSD. Si desea controlar la proporción manualmente, puede deshabilitar el escalado para cada grupo, pero en este caso el módulo cae con una división por 0 y el estado del clúster se convierte en ERROR. El módulo está escrito en python, y si comenta la línea necesaria en él, esto lleva a su cierre. Demasiado perezoso para recordar los detalles.
Lista de fuentes utilizadas:
Listados de guiones:
Instalación del sistema a través de 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@rbd1Adición de 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@$osdnumResumen
La principal ventaja de marketing de CEPH es CRUSH, un algoritmo para calcular la ubicación de los datos. Los monitores propagan este algoritmo a los clientes, después de lo cual los clientes solicitan directamente el nodo deseado y el OSD deseado. CRUSH no proporciona centralización. Es un archivo pequeño que incluso puedes imprimir y colgar en la pared. La práctica ha demostrado que CRUSH no es un mapa exhaustivo. Destruir y volver a crear los monitores manteniendo todos los OSD y CRUSH no es suficiente para restaurar el clúster. De esto se concluye que cada monitor almacena algunos metadatos sobre todo el clúster. La cantidad insignificante de estos metadatos no impone restricciones en el tamaño del clúster, pero requiere su seguridad, lo que elimina el ahorro de disco debido a la instalación del sistema en una unidad flash y excluye los clústeres con menos de tres nodos. Política de desarrollador agresiva con respecto a las características opcionales. Lejos del minimalismo. Documentación al nivel: “gracias por lo que es, pero muy, muy escasamente”. Se proporciona la capacidad de interactuar con los servicios a un nivel bajo, pero la documentación es demasiado superficial sobre este tema, por lo que es más probable que no que sí. Prácticamente no hay posibilidad de recuperar datos de una situación de emergencia.
Opciones para acciones adicionales: abandone CEPH y use los btrfs multidisco banales (o xfs, zfs), aprenda nueva información sobre CEPH, que le permitirá operarlo en las condiciones especificadas, intente escribir su propio almacenamiento como un entrenamiento avanzado .
Fuente: habr.com