Juan Perón expone sobre la necesidad de integrar la lucha a la vez que explica cómo reemplazar las unidades de disco NVMe en Ubuntu Server.
¡Trabajadores!
Las dicotomías del Mundo parecen impulsar al hombre hacia su final destrucción. Se lo ha apremiado artificialmente hacia un híper-consumismo cuyo único sentido es generar una clase de ultra-ricos solventados por una descomunión de ultra-pobres. A su vez, ello ha requerido de la súper-explotación de los recursos ecológicos de nuestro Planeta, y de la ultra-dependencia política de los Pueblos que lo componen.
La acción irresoluta del hombre contra el hombre parece querer consumar una lucha enconada, y se le ha ofrecido como solución la competencia entre esclavos por el afecto de un amo al que siquiera conocen, y de cuyos frutos jamás podrán gozar. Muy pocos guardar alguna duda que el diseño mismo de esta lid es el culpable de estas circunstancias.
Ante estas construcciones artificiosas no podemos mas que valernos de la conciencia natural de los Pueblos, que por instinto han comprendido que todo lo perderán si no asocian a su existir mancomunado una prédica social de integración, en un sentir que - si no es humano - al menos ha de ser justo.
Hemos hallado coto a esta situación en la Justicia Social. En esto no he sido los únicos, pero si hemos sido los primeros en desarrollarla e implementarla en este rincón del Globo.
Es indudable que desde un comienzo nos dimos en tornar realidad efectiva una solución de memoria de masa en base a discos rígidos con acceso al Pueblo. Esto ha sido así porque oligárquicas compañías sin Patria ni Bandera que lo intentaban lo hacían con el único propósito de robar datos y explotar metadatos.
Nuestro mérito en un clúster de datos para el Pueblo nos permite en cambio almacenar para trabajar, y resguardar para luchar. Tal ha sido nuestra previsión, y no nos hemos equivocado.
Cuando surgió la necesidad, contábamos ya con una herramienta, que de afilarse puede constituir un arma. Es que nuestro servidor Ubuntu de acceso popular en las redes de datos no contaba con la posibilidad de instalarle novedosos discos NVMe, sino que daba uso a las sencillas unidades SATA en forma de discos rígidos mecánicos. Pero la expansión que permite un Justicialismo en anhelo de lucha le permite integrar una placa controladora para discos NVMe que permite darle al Pueblo aquello a lo que antes sólo accedía el oligarca. Es posible así munirle hasta cuatro discos de estado sólido NVMe. Con unidades de 240GB cada uno permitían totalizar próximo a un Terabyte, erogando una velocidad cinco veces superior a la de los discos de estado sólido SATA2, y unas veinticinco
veces superior a las de los viejos discos rígidos mecánicos, a la vez que se guardaba la información del daño esperable y lógico al que la someten las operaciones mecánicas. Por demás, su funcionamiento es totalmente silencioso.
La Doctrina que hemos creado permanece irresoluta, pero el avance de la técnica puesta a nuestra disposición nos permite tomar la decisión de reemplazar dichas unidades de referencia por cuatro más veloces y mayores, cada una ya de 2 Terabytes. Para ello recurriremos a desacoplarlas de la controladora, y operarlas individualmente según un modo de redundancia RAID que creamos convenientes para nuestras necesidades. Las viejas unidades de 240 nos servirán perfectamente para nuevas laptops "de combate" que disponían de los zócalos pertinentes pero no de discos.
Si bien el armado de cero de un servidor o un clúster RAID no opone gran resistencias, el planteo de reemplazar las unidades NVMe del conjunto de arranque RAID1 en Ubuntu Server (con datos propios y ajenos) constituye en cambio un desafío mucho mayor, al que debemos encarar como si de discos rígidos en uso se tratara. No es algo que puede hacerse "a tontas y a locas": en efecto, debemos hacer caso al procedimiento de realizar una copia de resguardo, tomar nota del particionado actual las unidades, y luego reemplazarlas físicamente, para sincronizar las unidades nuevas.
En este caso el servidor contaba con Ubuntu Server en cuatro unidades de disco de estado sólido NVMe, conocidas como nvme0n1, nvme1n1, nvme2n1 y nvme3n1, divididas en pares según el estándar raid1 (según este, las particiones de las unidades se duplican pero el uso equivale al del disco de menor capacidad del conjunto).
El par de unidades de 240GB que forman el conjunto raid1 cuentan con particionado para que las mismas operen de unidades de arranque, según la siguiente estructura:
UEFI 512M
md0 / boot 1GB
md1 / LVM <resto del disco>
La idea es replicar esto en las unidades NVMe nuevas.
Antes de comenzar, instalaremos en el servidor los programas de administración de discos (si es que no los tuviésemos a mano ya):
sudo apt install mdadm parted smartctl sfdisk efibootmgr
En primer lugar probamos que todas las unidades NVMe se encuentren realmente montados y en línea como deberían. Para ello introducimos el comando:
cat /proc/mdstat
...ante lo cual el sistema nos devuelve algo como:
Personalities : [raid1] [linear] [multipath] [raid0] [raid6] [raid5] [raid4] [raid10]
md0 : active raid1 nvme0n1p2[3] nvme1n1p2[2]
x blocks super 1.2 [2/2] [UU]
md1 : active raid1 nvme1n1p3[2] nvme0n1p3[3]
x blocks super 1.2 [2/2] [UU]
bitmap: 3/7 pages [12KB], xKB chunk
Esto nos asegura que las unidades de disco se encuentran montadas como conjunto raid1. Debe indicarnos [UU] y no [U_] o algo similar.
Es prudente utilizar por ejemplo el comando smartctl -ia /dev/nvme0, smartctl -ia /dev/nvme1, etc, con el fin de tomar nota de los números de serie de las unidades. En mi caso particular permite delimitar esto con seguridad cuál unidad NVMe específica es la que se reemplaza (ya que físicamente son todas iguales, y el orden de los conectores en la placa controladora no es correlativo, por alguna decisión de diseño).
Acto seguido, como generamos una copia de respaldo de la partición EFI de 512MB que contiene el sector de arranque, la cual necesitaremos posteriormente (no viene mas resguardarla en un pendrive):
dd if=/dev/nvme0n1p1 bs=4M of=/root/PARTICION_EFI.img
Escogemos ahora algunas de las unidades y la ponemos fuera de línea (una de las ventajas interesantes de las unidades NMEe):
mdadm /dev/md0 --fail /dev/nvme0n1p2 --remove nvme0n1p2
mdadm /dev/md1 --fail /dev/nvme0n1p3 --remove nvme0n1p3
Ahora reemplazamos físicamente una de las unidades NMVe en el servidor. Ya que estamos puede ser una buena idea actualizar el firmware de la unidad nueva (si es que existe un binario disponible en el sitio del fabricante). En este caso las unidades se colocan en uno de los cuatro zócalos de la controladora tras remover un disipador metálico atornillado y ajustar un pin de retención.
Una vez emplazada la nueva unidad NVMe, colocada la placa nuevamente e iniciado el servidor desde la unidad restante, copiaremos la tabla de particiones de dicha unidad restante (que era un RAID duplicado) a la nueva. Y a continuación generaremos nuevos UUIDs (identificadores únicos de unidad) nuevas para todas sus particiones:
sfdisk -d /dev/nvme1n1 | sfdisk /dev/nvme0n1
sgdisk -G /dev/nvme0n1
Hecho esto, podremos volver a agregar estas dispositivos al conjunto del RAID1:
mdadm --manage /dev/md0 --add /dev/nvme0n1p2
mdadm --manage /dev/md1 --add /dev/nvme0n1p3
Tras este procedimiento, el RAID comenzará lógicamente a sincronizar en segundo plano todas las particiones a la unidad "pelada", como un loco (le llevará un tiempo). Podríamos monitorear el status de dicha reconstrucción del RAID introduciendo un comando como:
watch cat /proc/mdstat
Si la reconstrucción RAID se ve sumamente lenta, es probable que se encuentre limitada por software en el servidor a velocidades de unos 200 MB/segundo (11 GB/minuto, algo típico para evitar sobre-exigir de las unidades de disco de estado sólido, y no presentar inconvenientes en el caso de ambientes de acceso en red). Sin embargo, en este caso de mantenimiento vigilado podríamos solicitar que la carga máxima de trabajo de la unidad se eleve muy por encima de tal valor de precaución, lo que podría redundar en una velocidad máxima por ejemplo 1.600MB/segundo (~94 GB/minuto, dependiendo de la velocidad del controlador de discos). Esto podría hacerse con:
echo 1600000 > /proc/sys/dev/raid/speed_limit_max
De esta forma podremos lograr una sincronización completa de 1TB en 11 o 12 minutos, a costa de una mayor generación de calor. Naturalmente podríamos escoger un valor de 800000 como compromiso; en operación normal con Ubuntu, prácticamente no genera calor. En este caso, el disipador provisto redunda en una buena refrigeración momentánea (las unidades NVMe en este regímen generan bastante más calor, y el disipador lo contiene momentáneamente por unos siete y ocho minutos).
Una vez que la reconstrucción RAID haya concluido, necesitaremos reparar la EFI, comenzando por copiar de nuevo la imagen de partición EFI que respaldamos anteriormente:
dd if=/root/PARTICION_EFI.img bs=4M of=/dev/nvme0n1p1
Asimismo, debemos reparar el arrancador grub:
update-grub
grub-install /dev/nvme0n1
Y finalmente reinstalamos la opción de arranque UEFI. En Ubuntu esto se hace con:
efibootmgr -v | grep ubuntu # solo muestra una entrada
efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "ubuntu" --loader "\EFI\ubuntu\shimx64.efi"
Una vez concluido esto, deberíamos contar dos entradas "ubuntu" en el efibootmgr, una para cada unidad NVMe. Esto debería ser todo para un simple reemplazo de unidades en el RAID1.
Como comprobación cruzamos los dedos e intentamos reiniciar el servidor, de modo de asegurar que el arranque con UEFI se produce correctamente desde cualquiera de los dos unidades NMVe.
Naturalmente, si necesitáramos reemplazar otras unidades en un conjunto con mayor número de discos deberíamos seguir el mismo procedimiento funcional, utilizando en cambio el designador de unidad nvme1n1.
Redimensionado de Disco NVMe
En este caso particular, las nuevas unidades NVMe no sin similares, sino mayores que las anteriores, lo que permiten incrementar el tamaño del conjunto RAID1 hasta 1 terabyte. Para delimitar este cambio habremos de utilizar el programa parted. Primero sacamos de línea la unidad y luego la abrimos con parted:
mdadm /dev/md1 --fail /dev/nvme0n1p3 --remove nvme0n1p3
parted /dev/nvme0n1
Y usamos el comando resizepart del programa parted para cambiar el tamaño de la partición desde los ~240GB anteriores hasta los ~1960GB.
Conforme lo hayamos definido, agregamos el disco nuevamente al conjunto RAID1:
mdadm --manage /dev/md1 --add /dev/nvme0n1p3
Ahora aguardamos que se produzca la resincronización del RAID (podemos usar cat /proc/mdstat para comprobarlo) y luego agrandamos el conjunto RAID con el comando grow hasta su máximo posible:
mdadm --grow /dev/md1 --size=max
Luego, necesitaremos reformular el tamaño del sistema de archivo.
En el caso de que hubiese sido particionado de tipo GPT simplemente deberíamos ejecutar
resize2fs /dev/md1
Sin embargo, en este caso que el esquema RAID cuenta con una estructura de particionado LVM mas avanzado, al cual se adosan las un particionado de formato ext4, por lo cual utilizamos:
pvresize /dev/md1
lvextend -L +1G /dev/vg-md1/lv-root
resize2fs /dev/vg-md1/lv-root
No hay comentarios:
Publicar un comentario