iVentoy - Caso de consultoría

iVentoy

Vamos a ver.
Esto aún no es la panacea que os creéis.
El producto lo veo inestable aún, meses después de su lanzamiento.
Pero da igual. Os muestro mi laboratorio de pruebas.

Preparativos

Además de lo comentado en el artículo anterior, sobre como voy a surtir de material al entorno, lo que voy a hacer es preparar el laboratorio.
Y para ello voy a declarar el siguiente entorno, por seguridad, por comodidad, y porque mis laboratorios no son de juguete, me interesa que sean exportables a entornos reales y no a un “Quita el cortafuegos que seguro que así funciona”.

Así que:

• Redes de gestión y producción segregadas
• Conectividad con el repositorio asegurada
• Dimensionamiento de clientes y servidor acorde al tráfico esperado
• Parámetros de red acordes a las necesidades
• Red escalable y gestionable
• Configuración de la electrónica de red (física y virtual) acorde a las necesidades por los diferentes estándares

Empezamos:

Redes de gestión y producción segregadas

Es obvio que voy a gestionar el servidor, y si es necesario, el contenedor, por red.
Tal como comenté en el capítulo de redes sobre la categorización de las mismas, mi vista servidorcentrica me va a asignar al menos 2 redes, 3 en este caso, pero que voy a simplificar a 2.
Una pata de gestión, por donde se accede a la interfaz de la máquina virtual donde voy a publicar el ssh, los puertos del contenedor y los puertos del servicio web de iVentoy, y ya de paso, aunque debería ir por almacenamiento, aprovechando que ya lo tengo, la conexión sshfs desde la máquina iVentoy al host ESXi. Mucha gestión hay ahí.
Y una pata de producción, puesto que el producto de la máquina es plataformar, no enseñar una web de configuración, con el resto de los puertos y servicios que se crean y gestionan desde iVentoy.

Conectividad con el repositorio

Como ya he comentado en el artículo anterior , y en el punto anterior también, es una red de gestión conectando con otra red de gestión por interfaces de gestión.

Dimensionamiento de clientes y servidor acorde al tráfico esperado. En esto, prueba y error.
No hay documentación al respecto, pero para el servidor, mínimo 2 vcpu y 4 Gb de ram. Parece mucho pero con menos, revienta constantemente, en físico. En contenedor hará falta seguramente un poco más.
En cuanto a lo del tráfico esperado, una red virtual no tiene límites (mas allá de la capacidad de conmutación del host en su parte de red virtual) así que podríamos considerar que mínimo tarjetas e1000e (1 Gb) o vmxnet3 (10 Gb).

Parámetros de red acordes a las necesidades

¿Pero más parámetros de red? ¿En serio?
Si. Y en serie, y en paralelo.
A ver, que igual que lo que ya he comentado antes, sobre redes y demás, vamos a hacer algo un poco más especial, por qué lo merece, lo necesita.
La red de producción estará segregada como ya he comentado antes, y tendrá una característica especial adicional, una VLAN, por hechos tan sencillos como separar completamente el tráfico, y por cosas como las ya explicadas en el capítulo que hice sobre las VLAN .

Red escalable y gestionable

Más parametrización de red. Obvio.
En el primer punto ya he explicado la arquitectura básica, la cual, al estar definida como he descrito, nos va a permitir varias cosas, como no perder la gestión por congestión de las interfaces de red y otros problemas. Y también el broadcast, el ruido de red que se va a generar en producción, que quede limitado y acotado por su propio adaptador, su VLAN, y una sorpresa añadida.
La red va a ser escalable, puesto que la red de producción tendrá su cabecera en la VM en capa 3, y en el host, y en su portgroup, en capa 2, por lo que la VLAN quedará extendida desde el ESXi al switch y si, esto ya lo he explicado en el capítulo del podcast que hice sobre las VLAN .

Configuración de la electrónica de red (física y virtual) acorde a las necesidades por los diferentes estándares

He dejado para el final las cosas más oscuras de la red, como por ejemplo el hecho de que tenemos que tocar valores de MTU (no lo he hecho en este laboratorio), los valores de seguridad del portgroup y algún detallito más.

• Jumbo frames: Para maximizar la capacidad de la red, empezaríamos pasando de 1500 a 9000 para tener un tráfico de red en el que el tamaño del paquete no limite la transferencia, y las tarjetas de red virtuales no se ahoguen en cómputo y gestión de los paquetes TCP. Tocar esto puede dejarte sin red, es un parámetro de capa 1 gestionado la mayoría de las veces en capa 2.
• TCP Offload: Vamos a ver, los drivers son lo que son y tienen las opciones que tienen. Hay cosas que se pueden hacer, y otras que aunque se hagan, como el que ve llover.
• VLAN: Para saber usar esto, hay que saber que son las VLAN . Sin ese conocimiento, mejor cablear por separados.
• Políticas de seguridad y de teaming: Esta parte es específica de VMware. Si hace falta expandir y crecer, necesitaremos tocar cosas aquí, puesto que multicast no es un protocolo que históricamente le guste a la inmensa mayoría de los hypervisores, salvo a Hyper-V que le da igual.

Los parámetros de seguridad deberían quedar:

Puesta en marcha

Preparación del entorno y arranque del aplicativo

Pues ahora que ya he hecho mi grupo de capturas, lo que toca es ponerlas en secuencia, e ir describiendo. Así que si…
Lo primero es que vamos a necesitar una máquina virtual. Fedora server en este caso, y con la modificación que comenté en este artículo .
Para la descarga, simplemente descargar y descomprimir.

La configuración la voy a hacer en mi usuario local, así que voy a mapear el directorio iso que viene del host a mi usuario, así no toco puntos de montajes.
Como he descomprimido en mi home, simplemente elimino el directorio iso y creo un enlace al punto de montaje.

rmdir iso
ln -s /mn/iso ./iso
ls -al

Queda comprobado el enlace simbólico.

Para iniciar, tan solo necesitamos invocar, como dice la documentación, con sudo ./iventoy.sh start. Sudo lo necesita porque usa puertos privilegiados.

La interfaz de usuario está en un puerto http, el 26000. Así que accedemos por navegador a ver que tal es la interfaz.
Lo más notable es que ni pide credenciales ni autenticación ni nada por el estilo.

Explorando la interfaz

Lo que nos importa, es que según informa el primer combo, tenemos correctamente configurada la interfaz de red de gestión, en mi caso en el segmento 10, y de producción, en el segmento 11, y que es la que usará el servicio para contactar con las máquinas a instalar, tanto como virtuales, como físicas (en un futuro).
Tengo definido un rango como disponible para este trabajo. Así pueden coexistir con otras cosas que pueda tener aparcadas en esa red.

Una vez definido el interfaz, la red del segmento 11, vamos a permitir las mac de los dispositivos que voy a instalar, una especie de lista de control de acceso.
Para este caso, las de VMware standalone, las que corresponden 00-0c-29-**-**-** y que curioso, que es la misma que propone el propio iVentoy. A iVentoy le gusta VMware.
Podríamos poner otros rangos, como por ejemplo los de 10-65-**-**-**-** que corresponden a un muy extenso repertorio de tarjetas Intel e1000 o Intel I219.
Una funcionalidad interesante es el uso de listas negras, denegar todo menos algo determinado. Da igual, esto va en gustos.

En la pantalla de configuración, hay dos partes, la de red, donde definir los puertos, que podemos dejar por defecto junto con parámetros de timeout y demás…

Y parámetros del servidor que vamos a usar, en este caso son del DHCP y de su servicio.
Para esta prueba hay 3 posibles configuraciones y la más simple en este desarrollo es usar el servidor interno.
El servidor externo y el externo de red son un DHCP local o remoto y que deben ser modificados para que cumplan con los requisitos de entrega de datos para PXE.
El otro combo que me interesa es el de la imagen EFI.
Tendré que hacer un artículo explicando la historia de estos firmwares pero vamos a tomar como que iPXE (ipxe.efi) es el más universal y actual de los que muestra, quedando SPN (spnonly.efi y spn.efi) como valores de contingencia para ciertos tipos de tarjetas de red. No tengo una lista de lo que funciona con uno o con otro, así que prueba y error.
Solo un truco. Con ipxe cubrimos la inmensa mayoría de los 64 bits, UEFI o no, y spnonly cubriría los legacy y algunos i386.

Por último, en la gestión de imágenes, luego en el log se verá más claro, podemos ver las imágenes disponibles.
En este caso iVentoy lee desde su directorio iso, que es un enlace simbólico a mi punto de montaje del sshfs que procede del ESXi, por lo que iVentoy está leyendo (y en solo lectura) del datastore del host.
Esto si es ahorro. No lo hagáis en producción real.

Una vez revisado todo esto, volvemos a la ventana principal, la del boot, y podemos darle a iniciar. Lo cual ya nos permite ponernos a instalar máquinas remotas, por red, sin pinchos, sin iso, sin casi nada.

No sin antes echar un ojo al log, en ./log/log.txt así que hacemos un simple tail -f ./log/log.txt & en consola para ir viendo que se cuece, como por ejemplo el análisis que hace de las imágenes iso.

Una vez que presenta el banner, lo podemos dar por arrancado y disponible, e incluso ya voy viendo cosas en el log porque ya hay una máquina virtual pidiendo cosas en el segmento.

Y ahí está, una máquina virtual sin sistema operativo disponible, pero arrancando por iPXE una vez que un servidor le ha ofrecido IP tras validar la mac, y ha empezado a transmitir el firmware.

Primera prueba

Una vez hecho, iVentoy cargará su cargador de red, que se trae la información del catálogo, y la muestra en la consola como si hubiéramos pinchado el disco directamente.

Elegimos un sistema, una iso, con la que arrancar.
Esto va a producir 2 cosas, al menos.

• El servidor boot va a poner a disposición del cliente pxe una URL conformada según el estándar, con todos los ficheros de la iso.
• El arranque PXE va a empezar a pedir el contenido de la iso

El estándar es un simple servidor http, en este caso por el puerto 16000, y con una estructura determinada.

Por cierto, podemos ver datos relevantes en la pantalla de boot, como la mac, la dirección, datos de identidad física del cliente…

Probando otra imagen a ver que funciona

Como las pruebas hasta ahora no han sido muy felices, voy con Fedora 38 KDE, que su instalador tiene otro concepto.

Tiene pinta de arrancar correctamente, al menos como live, así que voy a pedir que instale.

Y toma que si instala, que ha instalado y sin rechistar, ni protestar.
Al menos tenemos una lista decente de isos que funcionan, y son:

Fedora 38 kde
Windows 10 22h2
Windows 11
Windows server 2022 y 2019 (varias versiones)

Y Debian… Bueno, siempre podré probar de nuevo, pero esta vez su versión live, con calamares como instalador.

Estado y comportamiento del servidor

Vamos a analizar ahora el comportamiento del host, y de varios parámetros a ver que tal…

En esta captura vemos la máquina virtual, su interfaz de red, una estadística simple.
Y lo primero que me importa es el tráfico, el consumo de red, que como estoy con discos mecánicos, no espero que llegue al 100% de red, pero se ven perfectamente los flujos y los tiempos en comparación de mis dos primeras pruebas, en naranja la fallida de Debian y en azul la correcta de Fedora.

A ojos del host vemos todo mucho más claro, las ráfagas del primer intento con Debian, donde no ha conseguido instalarse, y el flujo continuo de red en la interfaz de management del host durante la instalación de fedora, recordemos que accedo desde la VM al host por sshfs y las vm se comunican entre ellas por la misma interfaz en este caso.

Y por último, CPU, que como estoy con 2 vm, una con 2 vcpu, otra con otras 2, la consola de servicio y una conexión sshfs… Pues eso, una sobresuscripción de 3:1 en cpu que como veréis apenas afecta al desempeño de este equipo tan modesto pero que sirve perfectamente de laboratorio.

Y no me queda más que analizar ni nada. Seguiré probando más imágenes ISO y a ver que funciona y que no.

Enlaces

YoVirtualizador en formato podcast. Ahora también en Sospechosos Habituales: https://wt.territoriolinux.es/rss/short.xml
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://youtube.com/@yovirtualizador
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