Probablemente, todos los que al menos una vez se quedaron perplejos por la búsqueda de almacenamiento definido por software de alto rendimiento tarde o temprano escucharon acerca de DRBD , o tal vez incluso lo trataron.
Es cierto que en la cima de la popularidad de Ceph y GlusterFS , que funcionan bastante bien en principio, y lo más importante desde el primer momento, todos se olvidaron un poco. Además, la versión anterior no admitía la replicación en más de dos nodos, y debido a esto, a menudo se encontraban problemas con el cerebro dividido , lo que claramente no aumentaba su popularidad.
La solución realmente no es nueva, pero sí bastante competitiva. Con costos relativamente bajos para CPU y RAM, DRBD proporciona una sincronización realmente rápida y segura a nivel de dispositivo de bloque . Durante todo este tiempo, los desarrolladores de LINBIT - DRBD no se detienen y lo refinan constantemente. Comenzando con la versión DRBD9 , deja de ser solo un espejo de red y se convierte en algo más.
En primer lugar, la idea de crear un único dispositivo de bloque distribuido para varios servidores ha retrocedido en segundo plano, y ahora LINBIT está tratando de proporcionar herramientas para orquestar y administrar muchos dispositivos drbd en un clúster que se crean sobre particiones LVM y ZFS .
Por ejemplo, DRBD9 admite hasta 32 réplicas, RDMA, nodos sin disco y nuevas herramientas de orquestación que le permiten usar instantáneas, migración en línea y mucho más.
A pesar de que DRBD9 tiene herramientas de integración con Proxmox , Kubernetes , OpenStack y OpenNebula , en este momento están en algún modo de transición, cuando las nuevas herramientas aún no son compatibles en todas partes, y las antiguas se anunciarán como obsoletas muy pronto. Estos son DRBDmanage y Linstor .
Aprovecharé este momento para no entrar en detalles de cada uno de ellos, sino para examinar con más detalle la configuración y los principios de trabajo con DRBD9 . Todavía tiene que resolverlo, aunque solo sea porque la configuración tolerante a fallas del controlador Linstor implica instalarlo en uno de estos dispositivos.
En este artículo, me gustaría informarle sobre DRBD9 y la posibilidad de su uso en Proxmox sin complementos de terceros.
DRBDmanage y Linstor
En primer lugar, vale la pena mencionar una vez más sobre DRBDmanage , que se integra muy bien en Proxmox . LINBIT proporciona un complemento DRBDmanage listo para usar para Proxmox que le permite utilizar todas sus funciones directamente desde la interfaz de Proxmox .
Se ve realmente increíble, pero desafortunadamente tiene algunas desventajas.
- Primero, los nombres de volumen etiquetados, el grupo LVM o el grupo ZFS deben llamarse
drbdpool . - Incapacidad para usar más de un grupo por nodo
- Debido a los detalles de la solución, el volumen del controlador solo puede estar en un LVM normal y no de otra manera
- Fallas periódicas en dbus , que DRBDmanage utiliza de cerca para interactuar con los nodos.
Como resultado, LINBIT decidió reemplazar toda la lógica compleja de DRBDmanage con una aplicación simple que se comunica con los nodos usando una conexión tcp regular y funciona sin ninguna magia allí. Entonces estaba Linstor .
Linstor realmente funciona muy bien. Desafortunadamente, los desarrolladores eligieron Java como el idioma principal para escribir el servidor Linstor, pero no dejes que esto te asuste, ya que a Linstor solo le preocupa distribuir configuraciones DRBD y cortar particiones LVM / ZFS en los nodos.
Ambas soluciones son gratuitas y se distribuyen bajo la licencia GPL3 gratuita .
Puede leer sobre cada uno de ellos y sobre cómo configurar el complemento mencionado anteriormente para Proxmox en el wiki oficial de Proxmox
Servidor NFS de conmutación por error
Desafortunadamente, al momento de escribir, Linstor solo tiene integración con Kubernetes . Pero a fin de año, se esperan controladores para el resto de los sistemas Proxmox , OpenNebula , OpenStack .
Pero hasta ahora no existe una solución preparada, pero de alguna manera no nos gusta la anterior. Intentemos usar DRBD9 de la manera tradicional para organizar el acceso NFS a una partición compartida.
Sin embargo, esta solución también demostrará no estar exenta de ventajas, ya que el servidor NFS le permitirá organizar el acceso competitivo al sistema de archivos del repositorio desde varios servidores sin la necesidad de sistemas de archivos de clúster complejos con DLM, como OCFS y GFS2.
En este caso, podrá cambiar las funciones del nodo primario / secundario simplemente migrando el contenedor con el servidor NFS en la interfaz Proxmox.
También puede almacenar cualquier archivo dentro de este sistema de archivos, así como discos virtuales y copias de seguridad.
En caso de que use Kubernetes , podrá organizar el acceso ReadWriteMany para sus PersistentVolumes .
Contenedores Proxmox y LXC
Ahora la pregunta es: ¿por qué Proxmox?
En principio, para construir dicho esquema, podríamos usar Kubernetes, así como el esquema habitual con un administrador de clúster. Pero Proxmox proporciona una interfaz lista para usar, muy multifuncional y al mismo tiempo simple e intuitiva para casi todo lo que necesita. Está listo para usar, es capaz de agruparse y es compatible con el mecanismo de cercado basado en softdog. Y cuando usa contenedores LXC, le permite lograr tiempos de espera mínimos al cambiar.
La solución resultante no tendrá un solo punto de falla .
De hecho, utilizaremos Proxmox principalmente como un administrador de clúster , donde podemos considerar un contenedor LXC separado como un servicio que se ejecuta en un clúster HA clásico, solo con la diferencia de que el contenedor también viene con su sistema raíz . Es decir, no necesita instalar varias instancias de servicio en cada servidor por separado, solo puede hacerlo una vez dentro del contenedor.
Si alguna vez trabajó con el software de administración de clúster y proporcionó HA para aplicaciones, comprenderá lo que quiero decir.
Esquema general
Nuestra solución se parecerá al esquema de replicación estándar de una base de datos.
- Tenemos tres nodos
- Cada nodo tiene un dispositivo drbd distribuido.
- El dispositivo tiene un sistema de archivos normal ( ext4 )
- Solo un servidor puede ser maestro
- El servidor NFS en el contenedor LXC se inicia en el asistente.
- Todos los nodos acceden al dispositivo estrictamente a través de NFS.
- Si es necesario, el asistente puede moverse a otro nodo, junto con el servidor NFS
DRBD9 tiene una característica muy interesante que simplifica enormemente todo:
El dispositivo drbd se convierte automáticamente en Primario en el momento en que está montado en algún nodo. Si el dispositivo está marcado como Primario , cualquier intento de montarlo en otro nodo generará un error de acceso. Esto garantiza el bloqueo y la protección garantizada contra el acceso simultáneo al dispositivo.
¿Por qué todo esto se simplifica enormemente? Porque cuando el contenedor se inicia, Proxmox monta automáticamente este dispositivo y se convierte en primario en este nodo, y cuando el contenedor se detiene, lo desmonta por el contrario y el dispositivo vuelve a ser secundario .
Por lo tanto, ya no tenemos que preocuparnos por cambiar los dispositivos primarios / secundarios , Proxmox lo hará automáticamente , ¡Hurra!
Configuración DRBD
Bueno, hemos descubierto la idea. Ahora pasemos a la implementación.
Por defecto , la octava versión de drbd se suministra con el kernel de Linux , desafortunadamente no nos conviene y necesitamos instalar la novena versión del módulo.
Conecte el repositorio de LINBIT e instale todo lo que necesita:
wget -O- https://packages.linbit.com/package-signing-pubkey.asc | apt-key add - echo "deb http://packages.linbit.com/proxmox/ proxmox-5 drbd-9.0" \ > /etc/apt/sources.list.d/linbit.list apt-get update && apt-get -y install pve-headers drbd-dkms drbd-utils drbdtop
pve-headers : pve-headers kernel necesarios para compilar el módulodrbd-dkms - módulo de kernel en formato DKMSdrbd-utils - utilidades básicas de gestión de DRBDdrbdtop es una herramienta interactiva como top solo para DRBD
Después de instalar el módulo, comprobaremos si todo está en orden:
Si ve la octava versión en la salida del comando, entonces algo salió mal y se carga el módulo del núcleo en el árbol . Compruebe el dkms status averiguar cuál es el motivo.
Cada nodo que tengamos tendrá el mismo dispositivo drbd ejecutándose sobre las particiones regulares. Primero necesitamos preparar esta sección para drbd en cada nodo.
Dicha partición puede ser cualquier dispositivo de bloque , puede ser lvm, zvol, una partición de disco o todo el disco. En este artículo usaré un disco nvme separado con una partición en drbd: /dev/nvme1n1p1
Vale la pena señalar que los nombres de los dispositivos tienden a cambiar a veces, por lo que es mejor tomarlo inmediatamente como un hábito para usar un enlace simbólico constante al dispositivo.
Puede encontrar un enlace simbólico para /dev/nvme1n1p1 esta manera:
Describimos nuestro recurso en los tres nodos:
Es recomendable utilizar una red separada para la sincronización drbd.
Ahora cree los metadatos para drbd y ejecútelo:
Repita estos pasos en los tres nodos y verifique el estado:
Ahora nuestro disco inconsistente está en los tres nodos, esto se debe a que drbd no sabe qué disco debe tomarse como el original. Debemos marcar uno de ellos como Primario para que su estado se sincronice con los otros nodos:
drbdadm primary --force nfs1 drbdadm secondary nfs1
Inmediatamente después de esto, comenzará la sincronización :
No tenemos que esperar a que termine y podemos llevar a cabo más pasos en paralelo. Se pueden ejecutar en cualquier nodo , independientemente de su estado actual del disco local en DRBD. Todas las solicitudes serán redirigidas automáticamente al dispositivo con el estado UpToDate .
No olvide activar la ejecución automática del servicio drbd en los nodos:
systemctl enable drbd.service
Configurar un contenedor LXC
Omitiremos la parte de configuración del clúster Proxmox de tres nodos, esta parte está bien descrita en la wiki oficial
Como dije antes, nuestro servidor NFS funcionará en un contenedor LXC . Mantendremos el contenedor en el dispositivo /dev/drbd100 que acabamos de crear.
Primero necesitamos crear un sistema de archivos en él:
mkfs -t ext4 -O mmp -E mmp_update_interval=5 /dev/drbd100
Proxmox por defecto incluye protección multimount a nivel del sistema de archivos, en principio, podemos prescindir de él, porque DRBD tiene su propia protección por defecto, simplemente prohíbe el segundo primario para el dispositivo, pero la precaución no nos perjudica.
Ahora descargue la plantilla de Ubuntu:
# wget http://download.proxmox.com/images/system/ubuntu-16.04-standard_16.04-1_amd64.tar.gz -P /var/lib/vz/template/cache/
Y crea nuestro contenedor a partir de él:
pct create 101 local:vztmpl/ubuntu-16.04-standard_16.04-1_amd64.tar.gz \ --hostname=nfs1 \ --net0=name=eth0,bridge=vmbr0,gw=192.168.1.1,ip=192.168.1.11/24 \ --rootfs=volume=/dev/drbd100,shared=1
En este comando, indicamos que el sistema raíz de nuestro contenedor estará en el dispositivo /dev/drbd100 y agregaremos el parámetro shared=1 para permitir la migración del contenedor entre nodos.
Si algo salió mal, siempre puede solucionarlo a través de la interfaz Proxmox o en la /etc/pve/lxc/101.conf contenedor /etc/pve/lxc/101.conf
Proxmox desempaquetará la plantilla y preparará el sistema raíz del contenedor para nosotros. Después de eso podemos lanzar nuestro contenedor:
pct start 101
Configurar un servidor NFS.
De forma predeterminada, Proxmox no permite que el servidor NFS se ejecute en el contenedor, pero hay varias formas de habilitarlo.
Una de ellas es simplemente agregar lxc.apparmor.profile: unconfined a la /etc/pve/lxc/100.conf nuestro contenedor /etc/pve/lxc/100.conf .
O podemos habilitar NFS para todos los contenedores de forma continua, para esto necesitamos actualizar la plantilla estándar para LXC en todos los nodos, agregar las siguientes líneas a /etc/apparmor.d/lxc/lxc-default-cgns :
mount fstype=nfs, mount fstype=nfs4, mount fstype=nfsd, mount fstype=rpc_pipefs,
Después de los cambios, reinicie el contenedor:
pct shutdown 101 pct start 101
Ahora iniciemos sesión:
pct exec 101 bash
Instalar actualizaciones y servidor NFS :
apt-get update apt-get -y upgrade apt-get -y install nfs-kernel-server
Crea una exportación :
echo '/data *(rw,no_root_squash,no_subtree_check)' >> /etc/exports mkdir /data exportfs -a
Configuración HA
Al momento de escribir este artículo, proxmox HA-manager tiene un error que no permite que el contenedor HA complete su trabajo con éxito, como resultado de lo cual los procesos del espacio del kernel del servidor nfs que no se eliminaron por completo impiden que el dispositivo drbd salga de Secundario . Si ya se ha encontrado con tal situación, no debe entrar en pánico y simplemente ejecutar killall -9 nfsd en el nodo donde se lanzó el contenedor y luego el dispositivo drbd debería "liberarse" y se irá a Secundario .
Para corregir este error, ejecute los siguientes comandos en todos los nodos:
sed -i 's/forceStop => 1,/forceStop => 0,/' /usr/share/perl5/PVE/HA/Resources/PVECT.pm systemctl restart pve-ha-lrm.service
Ahora podemos pasar a la configuración de HA-manager . Creemos un grupo HA separado para nuestro dispositivo:
ha-manager groupadd nfs1 --nodes pve1,pve2,pve3 --nofailback=1 --restricted=1
Nuestro recurso solo funcionará en los nodos especificados para este grupo. Agregue nuestro contenedor a este grupo:
ha-manager add ct:101 --group=nfs1 --max_relocate=3 --max_restart=3
Eso es todo. Simple, ¿verdad?
La bola nfs resultante se puede conectar inmediatamente a Proxmox para almacenar y ejecutar otras máquinas virtuales y contenedores.
Recomendaciones y puesta a punto
DRBD
Como señalé anteriormente, siempre es recomendable usar una red separada para la replicación. Es muy recomendable utilizar adaptadores de red de 10 gigabits , de lo contrario, se encontrará con la velocidad del puerto.
Si la replicación parece lo suficientemente lenta, pruebe algunas de las opciones para DRBD . Aquí está la configuración, que en mi opinión es óptima para mi red 10G :
# cat /etc/drbd.d/global_common.conf global { usage-count yes; udev-always-use-vnr; } common { handlers { } startup { } options { } disk { c-fill-target 10M; c-max-rate 720M; c-plan-ahead 10; c-min-rate 20M; } net { max-buffers 36k; sndbuf-size 1024k; rcvbuf-size 2048k; } }
Puede obtener más información sobre cada parámetro de la documentación oficial de DRBD.
Servidor nfs
Para acelerar el funcionamiento del servidor NFS, puede ayudar aumentar el número total de instancias del servidor NFS en ejecución. Por defecto, 8 , personalmente, me ayudó a aumentar este número a 64 .
Para lograr esto, actualice el parámetro RPCNFSDCOUNT=64 en /etc/default/nfs-kernel-server .
Y reinicia los demonios:
systemctl restart nfs-utils systemctl restart nfs-server
NFSv3 vs NFSv4
¿Conoces la diferencia entre NFSv3 y NFSv4 ?
- NFSv3 es un protocolo sin estado; como regla, tolera mejor las fallas y se recupera más rápido.
- NFSv4 es un protocolo con estado , funciona más rápido y se puede vincular a ciertos puertos tcp, pero debido a la presencia de estado es más sensible a fallas. También tiene la capacidad de usar autenticación usando Kerberos y muchas otras características interesantes.
Sin embargo, cuando ejecuta showmount -e nfs_server , se utiliza el protocolo NFSv3. Proxmox también usa NFSv3. NFSv3 también se usa comúnmente para organizar máquinas de arranque en red.
En general, si no tiene una razón particular para usar NFSv4, intente usar NFSv3 ya que es menos doloroso por cualquier falla debido a la falta de un estado como tal.
Puede montar la bola usando NFSv3 especificando el parámetro -o vers=3 para el comando de montaje :
mount -o vers=3 nfs_server:/share /mnt
Si lo desea, puede deshabilitar NFSv4 para el servidor, para hacer esto, agregue la --no-nfs-version 4 a la variable --no-nfs-version 4 y reinicie el servidor, por ejemplo:
RPCNFSDCOUNT="64 --no-nfs-version 4"
iSCSI y LVM
Del mismo modo, se puede configurar un demonio tgt normal dentro del contenedor, iSCSI producirá un rendimiento significativamente mayor para las operaciones de E / S, y el contenedor funcionará de manera más fluida porque el servidor tgt funciona completamente en el espacio del usuario.
Por lo general, un LUN exportado se corta en muchas piezas con LVM . Sin embargo, hay varios matices a tener en cuenta, por ejemplo: cómo se proporcionan bloqueos LVM para compartir un grupo exportado en varios hosts.
Quizás estos y otros matices que describiré en el próximo artículo .