En un artículo anterior, examiné la posibilidad de crear un servidor NFS tolerante a fallas usando DRBD y Proxmox. Resultó bastante bien, pero no descansaremos en nuestros laureles y ahora trataremos de "exprimir todos los jugos" de nuestro almacenamiento.
En este artículo, le diré cómo crear un objetivo iSCSI tolerante a fallas de esta manera, que usaremos LVM para cortar en trozos pequeños y usarlo para máquinas virtuales.
Es este enfoque el que reducirá la carga y aumentará la velocidad de acceso a los datos varias veces, esto es especialmente beneficioso cuando no se requiere un acceso competitivo a los datos, por ejemplo, en el caso de que necesite organizar el almacenamiento para máquinas virtuales.
Algunas palabras sobre DRBD
DRBD es una solución bastante simple y madura, el código de la octava versión se adopta como parte del kernel de Linux. De hecho, representa un espejo de red RAID1. La novena versión introdujo soporte para quórum y replicación con más de dos nodos.
De hecho, le permite combinar dispositivos de bloque en varios nodos físicos en una red compartida común.
Usando DRBD puedes lograr configuraciones muy interesantes. Hoy hablaremos sobre iSCSI y LVM.
Puede obtener más información al respecto leyendo mi artículo anterior , donde describí esta solución en detalle.
Algunas palabras sobre iSCSI
iSCSI es un protocolo de entrega de dispositivos de bloque a través de una red.
A diferencia de NBD, admite autorización, resuelve fallas de red sin problemas y admite muchas otras funciones útiles, y lo más importante es que muestra un muy buen rendimiento.
Hay una gran cantidad de sus implementaciones, algunas de ellas también están incluidas en el kernel y no requieren dificultades especiales para su configuración y conexión.
Algunas palabras sobre LVM
Vale la pena mencionar que LINBIT tiene su propia solución para Proxmox, debería funcionar de inmediato y permitir lograr un resultado similar, pero en este artículo no me gustaría centrarme solo en Proxmox y describir alguna solución más universal que sea adecuada tanto para Proxmox como para Cualquier otra cosa, en este ejemplo, proxmox se usa solo como un medio de orquestación de contenedores, de hecho, puede reemplazarlo con otra solución, por ejemplo, lanzar contenedores con un objetivo en Kubernetes.
En cuanto a Proxmox específicamente, funciona bien con LUN y LVM compartidos, utilizando solo sus propios controladores estándar.
Las ventajas de LVM incluyen el hecho de que su uso no es algo revolucionario nuevo e insuficientemente utilizado, sino que, por el contrario, muestra estabilidad en seco, que generalmente se requiere del almacenamiento. Vale la pena mencionar que LVM se usa bastante activamente en otros entornos, por ejemplo, en OpenNebula o Kubernetes, y es bastante compatible allí.
Por lo tanto, recibirá un almacenamiento universal que se puede usar en diferentes sistemas (no solo en proxmox), utilizando solo controladores listos para usar, sin ninguna necesidad especial de modificarlo con un archivo.
Desafortunadamente, al elegir una solución para el almacenamiento, siempre tiene que hacer algunos compromisos. Entonces, aquí, esta solución no le dará la misma flexibilidad que, por ejemplo, Ceph.
El tamaño del disco virtual está limitado por el tamaño del grupo LVM, y el área marcada para un disco virtual específico se reasignará necesariamente; esto mejora en gran medida la velocidad de acceso a los datos, pero no permite Thin-Provisioning (cuando el disco virtual ocupa menos espacio de lo que realmente es). Vale la pena mencionar que el rendimiento de LVM disminuye bastante cuando se usan instantáneas, y por lo tanto, la posibilidad de su uso gratuito a menudo se elimina.
Sí, LVM admite grupos de Thin-Provision que carecen de este inconveniente, pero desafortunadamente su uso solo es posible en el contexto de un nodo y no hay forma de compartir un grupo de Thin-Provision para varios nodos en el clúster.
Pero a pesar de estas deficiencias, debido a su simplicidad, LVM todavía no permite a los competidores evitarlo y sacarlo completamente del campo de batalla.
Con una sobrecarga bastante pequeña, LVM aún proporciona una solución muy rápida, estable y bastante flexible.
Esquema general
- Tenemos tres nodos
- Cada nodo tiene un dispositivo drbd distribuido.
- En la parte superior del dispositivo drbd, se inicia un contenedor LXC con un objetivo iSCSI.
- El objetivo está conectado a los tres nodos.
- Se ha creado un grupo LVM en el objetivo conectado.
- Si es necesario, el contenedor LXC puede moverse a otro nodo, junto con el objetivo iSCSI
Personalización
Descubrimos 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, verifique si todo está bien con él:
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 tgt1 drbdadm secondary tgt1
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 objetivo iSCSI 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=tgt1 \ --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 objetivo iSCSI.
De todo el conjunto de objetivos , elegí istgt , ya que tiene el mayor rendimiento y funciona en el espacio del usuario.
Ahora iniciemos sesión en nuestro contenedor:
pct exec 101 bash
Instalar actualizaciones e istgt :
apt-get update apt-get -y upgrade apt-get -y install istgt
Cree un archivo que le entregaremos a través de la red:
mkdir -p /data fallocate -l 740G /data/target1.img
Ahora necesitamos escribir una configuración para istgt /etc/istgt/istgt.conf :
[Global] Comment "Global section" NodeBase "iqn.2018-07.org.example.tgt1" PidFile /var/run/istgt.pid AuthFile /etc/istgt/auth.conf MediaDirectory /var/istgt LogFacility "local7" Timeout 30 NopInInterval 20 DiscoveryAuthMethod Auto MaxSessions 16 MaxConnections 4 MaxR2T 32 MaxOutstandingR2T 16 DefaultTime2Wait 2 DefaultTime2Retain 60 FirstBurstLength 262144 MaxBurstLength 1048576 MaxRecvDataSegmentLength 262144 InitialR2T Yes ImmediateData Yes DataPDUInOrder Yes DataSequenceInOrder Yes ErrorRecoveryLevel 0 [UnitControl] Comment "Internal Logical Unit Controller" AuthMethod CHAP Mutual AuthGroup AuthGroup10000 Portal UC1 127.0.0.1:3261 Netmask 127.0.0.1 [PortalGroup1] Comment "SINGLE PORT TEST" Portal DA1 192.168.1.11:3260 [InitiatorGroup1] Comment "Initiator Group1" InitiatorName "ALL" Netmask 192.168.1.0/24 [LogicalUnit1] Comment "Hard Disk Sample" TargetName disk1 TargetAlias "Data Disk1" Mapping PortalGroup1 InitiatorGroup1 AuthMethod Auto AuthGroup AuthGroup1 UseDigest Auto UnitType Disk LUN0 Storage /data/target1.img Auto
Reiniciar istgt:
systemctl restart istgt
Esto completa la configuración del objetivo
Configuración HA
Ahora podemos pasar a la configuración de HA-manager . Creemos un grupo HA separado para nuestro dispositivo:
ha-manager groupadd tgt1 --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=tgt1 --max_relocate=3 --max_restart=3
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.
Abrir iSCSI
Como no utilizamos rutas múltiples, en nuestro caso se recomienda deshabilitar las comprobaciones de conexión periódicas en los clientes, así como aumentar los tiempos de espera para la recuperación de la sesión en /etc/iscsi/iscsid.conf .
node.conn[0].timeo.noop_out_interval = 0 node.conn[0].timeo.noop_out_timeout = 0 node.session.timeo.replacement_timeout = 86400
Uso
Proxmox
El objetivo iSCSI resultante puede conectarse inmediatamente a Proxmox, sin olvidar desmarcar Usar LUN directamente .
Inmediatamente después de eso, será posible crear LVM encima, no olvides marcar la casilla compartida :
Otros ambientes
Si planea usar esta solución en un entorno diferente, es posible que necesite instalar una extensión de clúster para LVM en el momento en que haya dos implementaciones. CLVM y lvmlockd .
La configuración de CLVM no es trivial y requiere un administrador de clúster que funcione.
Mientras que como segundo método, lvmlockd aún no se ha probado completamente y apenas comienza a aparecer en repositorios estables.
Recomiendo leer un excelente artículo sobre bloqueo en LVM
Cuando se usa LVM con Proxmox, no se requiere la adición de clúster, ya que proxmox proporciona la administración del volumen, que actualiza y monitorea los metadatos de LVM de forma independiente. Lo mismo se aplica a OpenNebula , como lo indica claramente la documentación oficial .