Cuando los datos exceden la capacidad de un solo disco, es momento de considerar un RAID. En mi infancia, los mayores solían decir: "Un día, el RAID quedará obsoleto, los almacenes de objetos inundarán el mundo, y tú ni siquiera sabrás qué es CEPH". Por eso, lo primero que hice al independizarme fue crear mi propio clúster. El objetivo del experimento fue familiarizarme con la estructura interna de ceph y entender los límites de su aplicación. ¿Es justificada la implementación de ceph en la mediana y la pequeña empresa? Después de varios años de uso y algunas pérdidas irreversibles de datos, se ha adquirido una comprensión de las sutilezas: no todo es tan sencillo. Las características de CEPH plantean obstáculos a su difusión, y por ello, los experimentos han llegado a un callejón sin salida. A continuación, se describe todos los pasos realizados, los resultados obtenidos y las conclusiones tomadas. Agradeceré a quienes tengan conocimiento que compartan sus experiencias y aclaren algunos puntos.
Nota: Los comentaristas señalaron errores graves en algunas suposiciones que requieren una revisión de todo el artículo.
Estrategia CEPH
El clúster CEPH combina una cantidad arbitraria de K discos de tamaño variable y almacena los datos en ellos, duplicando cada fragmento (4 MB por defecto) un número N de veces.
Consideremos el caso más simple con dos discos idénticos. De ellos se puede construir un RAID 1 o un clúster con N=2, el resultado será el mismo. Si hay tres discos de diferentes tamaños, es fácil formar un clúster con N=2: parte de los datos estarán en los discos 1 y 2, parte en 1 y 3, y parte en 2 y 3, mientras que en RAID esto no es así (se puede formar un RAID así, pero sería un abuso). Si hay aún más discos, es posible crear un RAID 5; CEPH tiene un análogo — erasure_code, que contradice los conceptos anteriores de los desarrolladores, y por lo tanto no se considera. RAID 5 asume que hay un número limitado de discos y que todos están en buen estado. Al fallar uno, los demás deben mantenerse hasta que se reemplace el disco y se restauren los datos en él. En cambio, CEPH, con N>=3, fomenta el uso de discos viejos, en particular, si se mantienen varios discos buenos para almacenar una copia de datos, y las otras dos o tres copias se almacenan en un gran número de discos viejos, la información estará segura, ya que mientras los discos nuevos sobrevivan, no hay problemas; y si uno de ellos falla, la falla simultánea de tres discos con una vida útil de más de cinco años, preferiblemente de diferentes servidores, es un evento extremadamente improbable.
En la distribución de copias hay una sutileza. Por defecto, se asume que los datos se dividen en un mayor número de grupos de distribución PG (~100 por disco), cada uno de los cuales se duplica en algunos discos. Supongamos que K=6, N=2, entonces al fallar dos discos cualesquiera, se pierden garantidamente los datos, ya que según la teoría de probabilidades, al menos una PG se encontrará en estos dos discos. La pérdida de un grupo hace que todos los datos en el pool sean inaccesibles. Sin embargo, si se dividen los discos en tres pares y se permite almacenar datos solo en discos dentro de un mismo par, esta distribución también es resistente a la falla de cualquier disco, pero al fallar dos, la probabilidad de pérdida de datos no es del 100%, sino de solo 3/15, y incluso al fallar tres discos, apenas 12/20. Por ende, la entropía en la distribución de datos no contribuye a la resistencia a fallos. También notamos que para un servidor de archivos, la memoria RAM libre incrementa significativamente la velocidad de respuesta. Cuanta más memoria haya en cada nodo, y cuanta más memoria haya en todos los nodos, más rápida será. Sin duda, esta es una ventaja del clúster frente a un servidor único y, más aún, a un NAS de hardware, que incorpora una cantidad muy pequeña de memoria.
De aquí se deduce que CEPH es una buena manera de crear un sistema de almacenamiento de datos confiable de decenas de TB con mínimas inversiones a partir de hardware obsoleto, con posibilidad de escalabilidad (aunque aquí, se requerirán costos, pero menores en comparación con los sistemas de almacenamiento comercial).
Implementación del clúster
Para el experimento, tomaremos una computadora desechada Intel DQ57TM + Intel Core i3 540 + 16 GB de RAM. Organizaremos cuatro discos de 2 TB en una especie de RAID10, tras la prueba exitosa, añadiremos un segundo nodo y otros tantos discos.
Instalamos Linux. Se requiere que la distribución tenga capacidad de personalización y estabilidad. Debian y Suse cumplen con estos requisitos. Suse tiene un instalador más flexible que permite deshabilitar cualquier paquete; desafortunadamente, no pude entender cuáles se pueden omitir sin dañar el sistema. Instalamos Debian a través de debootstrap buster. La opción min-base instala un sistema no operativo, que carece de controladores. La diferencia en tamaño en comparación con la versión completa no es tan grande como para preocuparse. Como el trabajo se realiza en una máquina física, quiero hacer instantáneas, como en las máquinas virtuales. Esta posibilidad la ofrece LVM o btrfs (o xfs, o zfs; la diferencia no es significativa). LVM no es muy fuerte en instantáneas. Instalamos btrfs. Y el gestor de arranque — en MBR. No tiene sentido clutter el disco con 50 MB de partición FAT, cuando se puede meter en un área de 1 MB de la tabla de particiones y destinar todo el espacio al sistema. Ocupó 700 MB en el disco. No recuerdo cuánto ocupa la instalación básica de SUSE; parece que alrededor de 1.1 o 1.4 GB.
Instalamos CEPH. Ignoramos la versión 12 en el repositorio de Debian y la descargamos directamente del sitio 15.2.3. Seguimos las instrucciones de la sección “instalamos CEPH manualmente” con las siguientes salvedades:
- Antes de conectar el repositorio, es necesario instalar gnupg wget ca-certificates.
- Después de conectar el repositorio, pero antes de la instalación del clúster, se omitió la instalación de los paquetes: 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 me importa, pero la instalación falla, por lo que CEPH tampoco se instalará.
Este parche ayudó:
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
Resumen del clúster
ceph-osd — se encarga del almacenamiento de datos en disco. Para cada disco se inicia un servicio de red, que recibe y ejecuta peticiones para leer o escribir en objetos. En el disco se crean dos particiones. Una de ellas contiene información sobre el clúster, el número del disco, así como las claves del clúster. Esta información de 1KB se crea una vez al añadir el disco y nunca más se ha notado que cambie. En la segunda partición no hay sistema de archivos y se almacenan datos binarios de CEPH. La instalación automática en versiones anteriores creaba una partición xfs de 100MB para información de servicio. Convertí el disco a MBR y asigné solo 16MB; el servicio no se queja. Creo que sin problemas xfs podría ser reemplazado por ext. Esta partición se monta en /var/lib/…, donde el servicio lee la información sobre OSD, así como encuentra el enlace al dispositivo de bloque donde se almacenan los datos binarios. Teóricamente, se podrían colocar los auxiliares directamente en /var/lib/…, y reservar todo el disco para datos. Al crear OSD mediante ceph-deploy, se crea automáticamente una regla para montar la partición en /var/lib/…, y también se asignan los derechos al usuario ceph para leer el dispositivo de bloque necesario. En una instalación manual, es necesario hacerlo uno mismo; no está mencionado en la documentación. También es recomendable especificar el parámetro osd memory target para asegurarse de tener suficiente memoria física.
ceph-mds. A un nivel bajo, CEPH es un almacenamiento de objetos. La capacidad de almacenamiento en bloque se reduce a la recopilación de cada bloque de 4MB como un objeto. El almacenamiento de archivos funciona con el mismo principio. Se crean dos pools: uno para metadatos y otro para datos. Estos se combinan en un sistema de archivos. En este momento, se crea algún registro, por lo que si se elimina el sistema de archivos pero se mantienen ambos pools, no será posible recuperarlo. Hay un procedimiento para extraer archivos por bloques, pero no lo he probado. El acceso al sistema de archivos está a cargo del servicio ceph-mds. Para cada sistema de archivos, se requiere una instancia separada de este servicio. Hay una opción de "índice" que permite crear una especie de varios sistemas de archivos en uno — tampoco se ha probado.
ceph-mon — este servicio almacena el mapa del clúster. Incluye información sobre todos los OSD, el algoritmo de distribución de PG en OSD y, lo más importante, información sobre todos los objetos (los detalles de este mecanismo no me quedan claros: hay un directorio /var/lib/ceph/mon/.../store.db, donde se almacena un gran archivo — 26MB, y en el clúster hay 105K objetos, lo que resulta en poco más de 256 bytes por objeto; creo que el monitor mantiene una lista de todos los objetos y los PG en los que se encuentran). La corrupción de este directorio resulta en la pérdida de todos los datos en el clúster. De esto se deduce que CRUSH indica cómo están ubicados los PG en OSD, así como cómo están ubicados los objetos en PG — se almacenan de manera centralizada en la base de datos, aunque los desarrolladores traten de evitar esa palabra. Como consecuencia, primero, no podemos instalar el sistema en un flash en modo RO, ya que se está realizando escritura constante en la base de datos; se necesita un disco adicional para esto (probablemente no más de 1 GB), y segundo, es necesario tener una copia de esta base de datos en tiempo real. Si hay varios monitores, la tolerancia a fallos se asegura automáticamente, pero en nuestro caso hay un solo monitor, máximo — dos. Existe un procedimiento teórico para recuperar el monitor basándose en los datos de OSD, he recurrido a él tres veces por diferentes razones y en las tres ocasiones no hubo mensajes de error, así como tampoco datos. Desafortunadamente, este mecanismo no funciona. O explotamos una pequeña partición en OSD y recopilamos RAID para almacenar la base de datos, lo que sin duda afectará negativamente al rendimiento, o asignamos al menos dos soportes físicos confiables, preferiblemente USB, para no ocupar los puertos.
rados-gw — exporta almacenamiento de objetos mediante el protocolo S3 y similares. Crea múltiples pools, sin una razón clara. No he experimentado mucho.
ceph-mgr — al instalar este servicio se activan varios módulos. Uno de ellos es autoscale, que no se puede desactivar. Se esfuerza por mantener la cantidad correcta de PG/OSD. Si se desea gestionar la proporción manualmente, se puede prohibir la escalabilidad para cada pool, pero en ese caso el módulo falla al dividir por 0, y el estado del clúster se convierte en ERROR. El módulo está escrito en Python, y si se comenta la línea correspondiente, se desactiva. Es perezoso recordar los detalles.
Lista de fuentes utilizadas:
Listados de scripts:
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 subvolumen crear $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
Paquete: lvm2
Estado: instalado ok
Prioridad: importante
Sección: admin
Tamaño-instalado: 0
Mantenedor: Debian Adduser Developers
Arquitectura: all
Multi-Arch: foreign
Versión: 113.118
Descripción: No-install
Paquete: sudo
Estado: instalado ok
Prioridad: importante
Sección: admin
Tamaño-instalado: 0
Mantenedor: Debian Adduser Developers
Arquitectura: all
Multi-Arch: foreign
Versión: 113.118
Descripción: 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 6Creación del 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 < /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@rbd1Agregar 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@$osdnumCurrículum
La principal ventaja de marketing de CEPH es CRUSH, un algoritmo para calcular la ubicación de los datos. Los monitores distribuyen este algoritmo a los clientes, quienes luego solicitan directamente el nodo y el OSD necesarios. CRUSH asegura la descentralización. Consiste en un pequeño archivo que se puede imprimir y colgar en la pared. La práctica ha demostrado que CRUSH no es un mapa exhaustivo. Si se destruyen y recrean los monitores, manteniendo todos los OSD y CRUSH, esto no es suficiente para restaurar el clúster. De aquí se deduce que en cada monitor se almacenan algunos metadatos sobre todo el clúster. Un volumen insignificante de estos metadatos no impone limitaciones sobre el tamaño del clúster, pero requiere asegurar su preservación, lo que excluye el ahorro de disco al instalar el sistema en una memoria USB y excluye clústeres con menos de tres nodos. Política agresiva del desarrollador respecto a las características opcionales. Lejos del minimalismo. Documentación a nivel de: 'por lo que hay, ya es un agradecimiento, pero es muy, muy escasa'. Se prevé la posibilidad de interactuar con el servicio en un nivel bajo, pero la documentación solo toca este tema de manera superficial, por lo que más bien es un no que un sí. Prácticamente no hay posibilidades de recuperar datos de una situación anómala.
Opciones para proceder: abandonar CEPH y optar por un simple btrfs de múltiples discos (o xfs, zfs), obtener nueva información sobre CEPH que permita usarlo en las condiciones indicadas, intentar como mejora profesional escribir su propio almacenamiento.
Fuente: habr.com
