Archivos Mensuales: marzo 2018

Cuando zfs se hace el pool un lío porque hemos hecho demasiados experimentos

Instalar una Debian 9 con zfs en la raíz es, si no rápido, al menos relativamente indoloro gracias a la guía que mantiene zfsonlinux en Github.

Aunque esa guía es enormemente concienzuda en cosas como limpiar bien los discos antes de usarlos, no puede protegernos de nuestra propia impaciencia y de que nos encontremos con restos de una instalación anterior. Si esto sucede, puede darse el caso de que al arrancar el kernel, se queje de que no puede importar un pool que está en un estado calamitoso, y zpool import nos sacará dos pools donde esperábamos uno: El bueno, y el malo, resto de un intento anterior, que además tiene una pinta bastante fea. Claro: hemos escrito otro encima… Pero no en las mismas particiones.

Carallo, ¿y qué hacemos? Nos hemos tirado horas preparando el servidor, luego haciendo la instalación (que finalmente sale bien a la tercera, claro)… Y no queremos empezar desde cero.

Como hay un dios para los informáticos y ayer estaba de guardia, sucedió que el pool bueno es un mirror, y el pool malo está en una partición de uno de los miembros del mirror, según nos ha informado diligentemente el mencionado zpool import. Y para algo tienen que servir los mirror, ¿no es cierto?

Pues hala, nos cargamos el principio del disco que tiene el zpool chungo, donde están el MBR, la tabla de particiones y las etiquetas de los vdevs de zfs:

dd if=/dev/zero of=/dev/sda bs=512 count=2000

Miramos cómo de largo es:

cat /sys/bus/scsi/devices/0\:0\:0\:0/block/sda/size
11721045168

(el angelito en cuestión es un WD Red de 6 TB)

Y nos cargamos también el final, donde hay guardadas las copias de las etiquetas de los vdevs de zfs:

dd if=/dev/zero of=/dev/sda bs=512 count=2000 skip=11721043168

rearrancamos, y genial: El servidor arranca desde el siguiente disco (porque hemos tenido la precaución de pedir a grub que escriba el MBR en todos ellos), el pool malo ha desaparecido, el bueno se monta solito (informando de que se encuentra un poco mal, y de que hagamos algo al respecto) y el sistema arranca. Nos hemos ganado el salario de hoy.

Los controladores virtuales en máquinas virtuales

«Modern OS should use virtio-scsi anyways«. Esta cita de Tom, de Proxmox, originalmente en su foro, suena a buena idea. Ya que hemos sustituído una controladora SCSI (SATA para nosotros, los humildes), con su correspondiente disco, por una mera simulación software de la misma y un trocito de un disco más grande, suena correcto que el controlador por el que el virtual pide sus operaciones sea virtual.

Hay varias razones para ello. La más sencilla es que una controladora virtual (una LSI, por ejemplo, que es una de las más populares) no deja de ser un software cuya tarea es interpretar lo que pide el sistema virtualizado, usando unos comandos que se diseñaron pensando en discos que giran y tienen cabezas magnéticas, y convertirlo a lo que el hipervisor ofrece. Esto último, cada vez más, son discos que se parecen mucho más a la memoria RAM que a lo que tenían en mente los que diseñaron el protocolo SCSI para discos. Entonces, podemos librarnos de un montón de trabajo en todos y cada uno de los accesos del virtual al disco si simplemente cogemos lo que el virtual quiere y directamente se lo damos al hipervisor en su lenguaje nativo. Menos uso de recursos, menos código y menos complejo, igual a menos errores. ¿Algún inconveniente?

Claro que sí. La cosa tiene sus inconvenientes. Los aficionados a la retroinformática («mi ERP requiere Windows Server 2003») descubrirán en seguida que los sistemas operativos diseñados hace quince años no llevan controladores para almacenamiento virtualizado. Oh, por supuesto hay solución: No hay más que bajarse la ISO con los últimos controladores, meterla en el CD virtual, e instalar. Si se trata de una máquina que ya existe, solo queda pegar el cambiazo. Ya de paso, podemos meter el controlador de red virtual. Este último mejorará un pelo el rendimiento y uso de recursos de la red, a cambio de… Su propio interface, por supuesto. Ah, ¿que estábamos hablando de una máquina virtual que ya existe? En ese caso, el ejercicio de malabarismo para cambiar uno por otro sin perder la conexión, lo dejo de manos del lector.

Feliz cumpleaños, Víctor.

Configurar un RAID de HP que corre ESXi

Supongamos que tenemos un servidor HP corriendo ESXi felizmente, accediendo a almacenamiento por red. Y supongamos que se nos ocurre la feliz idea de recopilar unos cuantos de esos discos SAS que tenemos por ahí cogiendo polvo desde que los sustituímos por unos humildes SATA que, siendo mucho menos pijos pero de estado sólido, les han dado una paliza horrorosa en consumo y rendimiento. A la vez.

Quizá el servidor en cuestión está ocupado haciendo lo que hacen los servidores con ESXi normalmente en un entorno de alojamiento en centro de datos, es decir, servir webs con WordPress y rechazar spam. Y nos da cosita interrumpir este feliz quehacer cotidiano solo porque hemos tenido una ocurrencia más.

HP ofrece, al igual que Dell y otros fabricantes, una herramienta para configurar sus controladoras mientras corren lo que sea que están corriendo. En el caso de HP, se puede encontrar fácilmente buscando por HPE Smart Storage Administrator (HPE SSA) CLI for VMware en la web del servicio técnico de HPE. Esto nos ofrecerá un vib, que podemos burguesamente scp al servidor en cuestión y seguidamente

esxcli software vib install -v ssacli-2.65.7.0-5.5.0.vib

(por ejemplo).

La documentación de esta herramienta es todo lo completa y farragosa que acostumbran los grandes fabricantes. Pero, por resumir una larga y diagonal lectura:

A ver, ¿qué hay aquí?

/opt/smartstorageadmin/ssacli/bin/ssacli controller all show config

A ver, quiero un RAID

# /opt/smartstorageadmin/ssacli/bin/ssacli controller slot=0 create type=ld drives=allunassigned raid=10

Y así se teje. Seguidamente, nos vamos a nuestro cliente de vmware obsoleto favorito, creamos un vmfs, y a correr.