Migra tus SD y USB a algo más robusto @ Samquejo | 2022-01-20T00:00:01+01:00 | 9 minutos de lectura | Actualizado en 2022-01-20T10:44:00+01:00

Vmware dice que se acabó el ahorrar en discos instalando en SD o USB

Hoy toco esta problemática porque llevo un par de semanas haciendo pruebas a ver si consigo llegar a algún sitio.
Es un esbozo de la opinión que me he formado a costa de leer los originales, cosa que siempre es bueno tomar de referencia.

La documentación original se encuentra aquí.

Un poco de contexto

Aún recuerdo como si fuera ayer cuando había que reparticionar el esquema de instalación por defecto de ESX 3 y 3.5 porque daba ciertos problemas como por ejemplo fallar en las integraciones de dataprotector.

En aquella época, montaba discos SAS de entre 33 y 146 GB de tamaño, y el esquema quedaba algo como:

Tipo Partición Tamaño Punto de montaje
Primaria /dev/cciss/c0d0p1 5120MB /
Primaria /dev/cciss/c0d0p2 1600MB Swap
Primaria /dev/cciss/c0d0p3 Resto
Extendida /dev/cciss/c0d0p5 4096MB /var
Extendida /dev/cciss/c0d0p6 2048MB /home
Extendida /dev/cciss/c0d0p7 2048MB /opt
Extendida /dev/cciss/c0d0p8 2048MB /tmp
Extendida /dev/cciss/c0d0p9 Resto VMFS-3

Mis servidores, Compaq, luego HP y después HPE, usaban una controladora RAID muy clásica, la Compaq Smart Array, que evolucionaría con el paso del tiempo a las ya conocidas, pero dejar la reseña me parece divertido.

El caso es que eso ya dejaba comprometidos 17 GB de instalación dejando el resto como datastore local.
Eso ya descartaba en su momento las SD, puesto que era difícil encontrar por encima de 4 GB con un rendimiento superior al de un disquete, o USB con un rendimiento mejor que los 1.1 y claro, todos los discos duros por debajo de esos 33 GB lo que obligó a descartar equipos, los que menos rendimiento podrían dar, y el almacenamiento menos adecuado. Evolución y actualización.

La llegada de ESXi dejó de lado la base de RedHat que acompañó al ESX hasta la versión 4, y sus requisitos de particionado.
De hecho, ESXi 4, 4.1 y, no lo he probado, 3.5, era posible dejarlo funcionando en un disco de 4 GB, por USB, SD o cualquier controladora, como las CCISS o las SATA integradas.

Esa rebaja de requisitos fue un ahorro a cambio de no tener un datastore local (que por otro lado también era un ahorro de dolores de cabeza en instalaciones extensas).
De hecho, en paralelo, empezaron a darse las configuraciones de Boot-from-SAN, que ya explicaré en su momento, pero que básicamente era ofrecer por la SAN un disco de cabina, de entre 5 y 20 GB, que junto con HBAs con roms decentes, o incluso NICs con capacidad de HBA, o incluso CNAs ya más avanzadas, permitieron realizar el arranque desde cabina, con más ahorro aún.
Algún día meteré contenido de mundodisco, pero aún no, queda poder mostrarlo.

El caso es que incluso después de esto, salió otra alternativa.
A partir de la versión 5 de vcenter se permitió otro tipo de gestión del arranque y que espero que siga vigente durante mucho tiempo.
Se trata del las instalaciones “stateless”, y el arranque se realiza desde una imagen del sistema, por PXE, y scripts de configuración.
Eso también lo dejo para otra ocasión puesto que lo merece.

Una de las diferencias más evidentes entre ESX, y ESXi a partir de la versión 5 es el uso de del disco RAM, razón por la cual hemos visto avisos en las controladoras de disco, SD, USB o cualquier otro sistema, en los que la pérdida del dispositivo (o su desconexión) no es problema para la continuidad del servicio en los servidores ESXi incluso hasta la versión 7.0.2 siempre que no tengamos VSAN o NSX.

primera captura

Lo dicho, parece que el cambio de esquema ha venido a dejar de lado una de las principales aportaciones a la resiliencia que tiene el servidor.

Los cambios y el por qué

Los cambios en el disco de arranque, instalado, de un ESXi han venido cocinándose a fuego lento desde hace muchas versiones y revisiones, y junto a ello, el incremento del IO de disco sobre este tipo de dispositivos.

Lo que en un linux estándar encontraríamos en las ubicaciones LSB, en ESXi están alteradas dado que las particiones también son bastante suyas.
El dispositivo de arranque, igual que en los equipos de red, o echando un poco de imaginación, asemejándose a las BIOS duales, tiene dos particiones raíz, llamadas “bootbank”, las mismas que permiten seleccionar una u otra en caso de fallo de una posible actualización o corrupción.
Esas composiciones, reconfiguraciones y reparticionado cocinadas a fuego lento ha llegado, según el artículo, y el blog, a su límite dado que con la inclusión de agentes propios, como el de NSX o VSAN, o en la época de ESXi 4.1 a 5.5, como los agentes de autodeploy, VCNS y sobre todo, porque Vmware “quiere” ampliar el ecosistema de agentes con agentes de terceros e integraciones que ahora mismo no son posibles del todo.

Tenemos las dos primeras particiones, además de la de boot y bueno, aunque la documentación y la realidad no terminan de cuadrar, voy a tratar de resumir en esta tabla toda esta información.

Nombre Contenido Rengo de tamaño Punto de montaje
Boot EFI Sistema EFI 100MB
Bootbank-0 Sistema base principal 500MB-4096MB /bootbank
/vmfs/volumes/BOOTBANK1
Bootbank-1 Sistema base alternativo 500MB-4096MB /altbootbank
/vmfs/volumes/BOOTBANK2
OSDATA Datos de solo lectura 2996MB-120GB Múltiples puntos de montaje, entre ellos las iso de vmtools
Datos del consolidado del ramdisk /var y logs
/vmfs/volumes/LOCKER-**********
Datastore Datastore local siempre y cuando exista espacio y limitado por el rendimiento del dispositivo Resto por encima de 128GB /vmfs/volumes/**********

Creo que esto ya es denso, pero ¿por qué dejarlo?

Resumen de causas

La decisión ha debido venir del análisis de causa raíz de los expedientes de soporte cursados por los clientes, y de los diferentes datos arrojados por los sistemas CEIP de los múltiples productos que llaman a casa, porque sabéis que llaman a casa, basta con leer la documentación y los avisos durante la instalación.

Pues eso, que en resumen tenemos 4 causas, o más bien el artículo destaca 4 causas. Traduzco, y no del idioma original, si no quitando la palabrería excesiva.

1- IO de disco y necesidad de persistencia.
Aceptamos barco. Necesito que, en caso de aislamiento del host por algún problema de red justo antes de reventar dando un pantallazo rosa, que escriba los logs en algún sitio donde luego poder recuperarlos.
Sobre todo, si estamos hablando de que los que van a escribir, además de VSAN y NSX, serán los agentes de terceros, los cuales no siempre se van a ajustar al syslog o a SNMP.
La verdad es que puedo reconocer que una cola de disco de una controladora SATA, SCSI, SAS, o de cualquier HBA siempre va a ser mejor que una controladora USB o de host PCMCIA, o de tipo SDIO, más que nada porque sabemos que Vmware no tiene ningún interés en mejorar el soporte de USB en sus ESXi.
De hecho, choca que pidan discos flash, SSD y que sean de los decentes por lo menos, de cualquiera de los protocolos o incluso pidan NVMe PCIe, y a la vez, en el mismo saco, pongan los SATADOM, que no han evolucionado prácticamente nada desde su invención, superados por los SSD SATA.
2- IO de disco en dispositivos endebles.
Volvemos a lo mismo, la partición OSDATA tiene que ser persistente, de cualquier forma.
Y por supuesto, tienen que soportar una frecuencia de escritura, y el aumento de volumen de las mismas.
Tanto USB como SD no tienen capacidad, por los temas ya hablados, y algo más que desarrollaré cuando hable de los discos en Vmware.
3- Monitorización eficaz y prevención de errores en esos dispositivos endebles.
Es cierto que los dispositivos USB o SD van a tener una difícil monitorización, precisamente por el hecho de que dichos dispositivos no soportan la monitorización por el estandar S.M.A.R.T. ni avisan de fallo.
¿Cuantas veces se ha quedado un USB o una microSD en modo solo lectura? ¿O directamente sin acceso?
Yo mismo tengo unos 4 o 5 pinchos, un puñado de tarjetas y al menos un disco SATA SSD y otro mSATA.
4- Supuesta deficiencia de calidad en esos dispositivos endebles.
No solo de esos dispositivos si no también dee supuestos SSD o peor, que he visto reventar a los 2 minutos, sin previo aviso. El mundo del disco es un universo denso y lleno de riesgos.
El hecho de ir a SLC no termina de garantizar gran cosa sobre los MLC.
Existen gamas más o menos industriales que son superiores en muchos aspectos a las supuestas gamas profesionales de gaming y similar. Es bueno no asumir que ambos mercados tienen equivalencias.

Futuro

El el futuro vSphere 8, ESXi 8, no va a dejar instalarse en un pincho USB, así que mínimo nos va a consumir un puerto SATA.
Lo que no termina de quedar claro es si va a ser posible mantener el arranque desde SD si podemos migrar el OSDATA a otro dispositivo. Esto puede ser relevante con actualizaciones desde ESXi 7, pero dudas me entran en casos de instalaciones nuevas si no queda claro el procedimiento de instalación personalizada y su particionado.
He hablado de Boot-from-SAN como una solución, y Vmware la reconoce como solución válida, aunque habrá que redimensionar muchísimas de esas instalaciones donde la media no supera los 20 GB.

Viendo esto, y que a Vmware no le ha temblado el pulso en otras ocasiones pero viendo esto muy gordo, tanto en costes de hardware como en otras cuestiones, lo veo un poco farol, pero dependerá de la masa de clientes que puedan quedarse fuera y sin soporte.

Ampliaré esto, cuando pueda, y termine de hacer mis pruebas, pero sin duda, tanto el KB que he indicado al principio como el blog al que hace referencia, son muy útiles y esclarecedores.

Por cierto, hay un aviso enorme en el que han dejado claro que no se aceptan conversores de formato, por lo que me olvido de cajas de discos externas, como mis Orico 2259RC3, sean vía USB, USB 3, USB-C o Thunderbolt.


YoVirtualizador en formato podcast. Ahora también en Sospechosos Habituales: https://feedpress.me/sospechososhabituales
Y sin más, os dejo los enlaces:

Web: https://www.yovirtualizador.com
Grupo de telegram: https://t.me/grupovirtualizador
Podcast: https://www.ivoox.com/podcast-yovirtualizador_fg_f1563806_filtro_1.xml
Canal de youtube: https://www.youtube.com/channel/UC0R70cABSsmC6TFyXth0qPg
Enlace de afiliados de amazon: https://amzn.to/3gX3HmK
Enlace de referidos de la Asociación Podcast: https://www.asociacionpodcast.es/registrarse/socio/?coupon=SB6A70

© 2019 - 2024 YoVirtualizador

Powered by Hugo with theme Dream.

avatar

El blog de YoVirtualizadorTu podcast y blog de confianza

Acerca de YoVirtualizador

YoVirtualizador es la marca de varios proyectos

Podcast de informática profesional. Canal de Youtube sobre el blog, el podcast y de temática profesional. Blog de contenido diverso, con temática BOFH y técnica.

Gracias por la lectura.

Política de comentarios

En YoVirtualizador todos los comentarios serán bienvenidos pero moderados.

Respetos guardan respetos.

El contenido irrelevante u ofensivo será eliminado.

Galletas

Política de cookies

En YoVirtualizador no usamos cookies para nada, pero los servicios de discus y analytics recopilan datos en servidores ajenos a YoVirtualizador sin que yo pueda hacer nada.

Este aviso es sólo porque algún político tenía que justificar su existencia.

Si hace clic en un enlace de afiliado y compra un producto o servicio, es posible que ese comerciante nos pague una tarifa.