Virtualizacion General

WhiteBox ESXi

En la red podemos encontrar infinidad de artículos que hacen referencia a como montarte tu propia whitebox ESXi, pero hay pocos en español. En los siguientes artículos voy a hacer referencia a mi propia whitebox esxi.

¿Qué es una Whitebox ESXi?

En la comunidad virtual, se denomina whitebox esxi a un ordenador montado con componentes compatibles con ESXi pero que no son un sistema propiamente validado y presente en la HCL de VMware (Hardware compatibility list). El motivo de montar estos sistemas, principalmente, es crear un laboratorio de pruebas para practicar, aprender, o incluso el ahorro de dinero utilizando componentes menos caros o con un nivel de soporte inferior a servidores que pueden vender HP o Dell, por ejemplo.

En mi caso, he estado un tiempo utilizando mi propio equipo de sobremesa (Intel i7-4770S con 16GB de RAM y un pendrive USB) hasta que la cantidad de memoria ram ha sido insuficiente para todas las cosas que quería probar. Así pues, en Octubre de 2014 he decidido renovar la Whitebox ESXi y comprar nuevo hardware dedicado para ella.

Los componentes elegidos no son los más baratos. Ya he tenido anteriormente whitebox con componentes de escritorio y no quería verme limitado a los 32GB de RAM que ofrecen la mayoría de placas base de sobremesa. Además, quería gestion remota usando IPMI para poder colocar el equipo en un sitio apartado de la casa donde no moleste (en el salón).

Mi primera opción fue una placa base con Intel Avoton C2750. Tienen 8 cores, un bajísimo consumo y soportan hasta 64GB de RAM ECC. El problema es que el rendimiento es bajísimo y conseguir la placa es bastante complicado.

Finalmente he optado por los siguientes componentes:

Placa Supermicro X10SRi-F270€

  • Tamaño ATX. No quiero cajas gigantes por casa. Ya tengo una.
  • 2 puertos LAN gigabit Intel i350, con soporte directo de ESXi
  • 10 puertos SATA3. Les conectaré un par de SSD que tengo por casa y 3 discos SATA.
  • 2 puertos USB 3.0 traseros, por si me interesa algún día hacer algo con passthrough
  • Puerto USB 3.0 interno en el que se puede conectar un pendrive para arrancar el ESXi
  • 8 slots de memoria. Es el principal motivo por el que me decantado por la plataforma Xeon / LGA2011.
  • LAN dedicada para IPMI de Supermicro, una garantía de buen funcionamiento para manejarlo remotamente con Linux, como es mi caso. También sirve para encender, apagar y arrancar isos en remoto en el equipo.

Procesador Intel Xeon E5-2620 v3400€

  • 6 cores, 12 hilos con Hyperthreading.
  • Consumo moderado-bajo, 85W de TDP máximo.
  • Soporta VT-x, VT-d y AES-NI
  • IMPORTANTE: Si vas a comprar una placa, revisa bien el tipo de anclaje para disipador que lleva. Puedes ver como los agujeros para los tornillos de mi socket son rectangulares. Se denomina LGA2011 Narrow ILM. Hay otra variante denominada LGA2011 Square ILM. No todos los disipadores valen para todos los sockets 2011. Lo que si puedo decirte es que los disipadores Narrow ILM 2011 es compatible con placas Narrow ILM 2011 para Xeon v3, al igual que los Square ILM 2011 son compatibles con placas Square ILM 2011 para Xeon v3.

whitebox ESXi

4x 16GB Samsung DDR4 1.2v – 800€
No quería dejar el equipo sin opciones de ampliación de memoria. Así que he ido a por estos módulos de 16GB. Son lo que más disparado de precio me ha parecido, pero llevaba muchos meses queriendo comprar el equipo y no quería retrasarlo más.

whitebox ESXi

 

Fuente de alimentacion Cooler Master V550s60€
En las reviews que he visto, es la que mejor estabilidad de señal da, es muy eficiente (80 plus gold) y está dentro de lo que tenia pensado gastarme en la fuente de alimentación. Es semi modular por lo que puedo librarme de parte de los cables que no utilizo.

whitebox ESXi

 

Disipador Noctua NH-U12DX i460€
Es el tercer disipador Noctua que compro y estoy muy contento con el. Es silencioso y de los pocos compatibles con el anclaje LGA 2011 Narrow ILM.

Whitebox ESXi

Caja Bitfenix Comrade 35€

Es una caja de tamaño pequeño, media torre. Blanca, imprescindible para mis whiteboxes 🙂 El precio es muy contenido, 34€. Viene con un ventilador bastante ruidoso que pienso sustituir en un futuro no muy lejano. Además he tenido que tapar con plástico no conductor un par de apoyos que vienen para placas ATX, ya que no coincidian con la placa supermicro y no quiero cortocircuitos que puedan romper la placa base. Aqui dejo una foto de como lo he solventado.

whitebox ESXi

 

Switch TP Link – TL-SG108E – 32€

Se trata de un switch de 8 puertos gigabit, de bajo consumo. Tiene el cuerpo de metal, bastante sólido, no tiene ventilador y dispone de una serie de funciones propias de switches administrados.

VLANes en los puertos, LACP (trunking) entre puertos, limitación de ancho de banda… Todo se hace mediante una aplicación de Windows que puedo confirmar que funciona con WINE (para los usuarios de linux).

TL-SG108E(UN)1.0-A

Además, este equipo utilizará como almacenamiento un NAS QNAP TS-853 Pro, con 4 discos WD Red de 4TB y 1 SSD de 60GB para cache. También está en juego un UPS Cyberpower de 800VA.

El coste total del equipo es de 1667€. Como decía anteriormente, no está en el segmento económico de las white boxes. Sin embargo, creo que he encontrado un equipo bastante potente que me va a dar bastante jugo para probar cosas y preparar recertificaciones.

¿Cuanto consume una whitebox?

Tengo un medidor de consumo eléctrico en la toma de corriente en la que se enchufan los siguientes dispositivos:

  • TV Samsung 46″ (standby al medir)
  • Barra de sonido Samsung con SW activo (standby al medir).
  • Playstation 3 (standby al medir).
  • WhiteBox.
  • NAS QNAP TS-853.
  • Switch 8 puertos.

El consumo medido es de 95-105W con una VM funcionando en el QNAP y otra en la Whitebox. Me consta que el QNAP consume en torno a 30-40W el solito. Tomando como precio por kWh 0.15 centimos, tenerlo todo funcionando cuesta 10 euros al mes. Por supuesto no estará siempre funcionando, pero incluso en ese caso extremo, no es una barbaridad de dinero.

 

 

 

Agregar un disco duro en caliente a VM Linux

En ocasiones podemos vernos en la situacion de que necesitamos espacio extra temporal para una máquina virtual Linux. Podemos agregar un disco duro en caliente y obtener capacidad extra de la siguiente forma:

1. Seleccionamos la máquina virtual encendida y pulsamos en Edit Settings y pulsamos el botón Add

añadir disco duro a VM linux

3. Seleccionamos Hard disk

añadir disco duro a VM linux

4. Dejamos la opcion por defecto “Create a new virtual disk

añadir disco duro a VM linux

5. Elegimos un tamaño para el nuevo disco que vamos a conectar a la VM

añadir disco duro a VM linux

6. Dejamos las opciones por defecto de disco SCSI

añadir disco duro a VM linux

7. Finalizamos el proceso

añadir disco duro a VM linux

Hasta aquí nada nuevo ni sorprendente. Ahora si vamos a la máquina es probable que ni con dmesg ni con fdisk seamos capaces de ver el nuevo disco.

Forzar un scan en el bus scsi para que linux detecte el nuevo disco duro

Primero tenemos que localizar el numero de controladora a la que tenemos conectado el disco duro de sistema y que hemos utilizado para añadir el disco extra, para ello ejecutaremos:

Si nos fijamos en el id del disco del sistema operativo, es 0:0:0:0. Esto está en una notación H:B:L:T donde:

H es Host Adapter, número de controladora, el que nos interesa, B es Bus o Channel, L es LUN y T es Target.

Así bien, hemos de forzar a Linux a enviar un rescan al adaptador SCSI número 0.

Si volvemos a ejecutar dmesg, podremos ver como ha detectado nuestro nuevo disco

Los siguientes pasos que deberás seguir tras agregar un disco duro en caliente a VM Linux son particionar el disco con fdisk y formatear la particion para posteriormente montarla en un punto de montaje que hayas elegido. Eso ya deberías saber hacerlo 🙂

Almacenamiento para virtualización

Cada vez que tengo que asesorar a alguien cuando me consultan por cuestiones de virtualización, nunca me canso de insistir de la importancia del almacenamiento para la virtualización.

Almacenamiento para virtualización

Almacenamiento Local

El almacenamiento local en los propios hipervisores es muy válido para comenzar tu andadura en el mundo de la virtualización. Te permite ir experimentando y aprendiendo para tener soltura y enfrentarte a algunos problemas sin invertir mucho dinero en la infraestructura de almacenamiento.

Almacenamiento local se refiere a utilizar discos duros en los propios hipervisores para crear lo que conocemos como datastores. Un datastore es un volumen de datos en el que almacenamos los archivos propios de las maquinas virtuales. Es como un volumen de disco normal en cualquier sistema operativo, pero solo puede verlo el hipervisor.

Por ejemplo. Pongamos que vas a dedicar cuatro servidores de 1U a virtualización. Utilizarás las bahías de disco de cada uno de esos servidores para almacenar las máquinas virtuales que se ejecutarán en cada uno de ellos.

Antes de continuar, es importantísimo dejar claro que no cualquier equipo sirve para virtualizar. No uses placas base de escritorio ni bajo coste. Usa una controladora RAID buena. Nada de Intel Matrix ni JMicron. Esto es debido a que ESXi no incluye soporte para muchas de las controladoras de bajo coste cuando trabajan en modo RAID, y poner un equipo en producción sin RAID cuando alojas en el varios servidores virtualizados no es una opción sensata.

Elección de controladora de discos para virtualización

Personalmente, últimamente tengo buenas experiencias con las controladoras Dell PERC H710 y HP SMART Array P420i. Por el otro lado, tengo muy malos recuerdos de la Dell PERC H200 con un rendimiento insubriblemente lento.

Un aspecto MUY IMPORTANTE en el almacenamiento para virtualización es la memoria caché de la controladora. Se trata de un módulo de memoria incorporado en la controladora que permite almacenar temporalmente los datos antes de enviarlos a disco. Al hacer de punto intermedio entre el servidor y los discos, y tener una velocidad de lectura y escritura muy superior, permite mejorar en gran medida la cantidad de operaciones por segundo (IOPS) que obtenemos de los discos duros. Si bien 512 MB son adecuados, si tenemos opción de adquirir una controladora con 1 GB o 2 GB de caché, mejor que mejor.

Las controladoras tradicionales tenían memoria RAM común para su caché, por lo que neceistaban de un módulo de batería que suministrara alimentación a dicha memoria RAM en caso de cortes de alimentación (que se fuera la luz). En las controladoras más modernas, esta memoria caché es de tipo Flash o NVRAM y ya no es necesaria la batería extra.

Elección de discos para virtualización

A la hora de virtualizar y conforme vayamos agregando máquinas virtuales a nuestro host, podremos ver que el acceso a disco de un entorno virtualizado mixto suele ser aleatorio. De nada nos va a servir que nuestros discos sean capaces de ofrecer 120 Mbytes/segundo si luego no pueden ir más allá de 100 operaciones por segundo cuando 10 máquinas virtuales estén queriendo leer y escribir de forma simultánea en ellos.

Si bien podemos apoyarnos en la controladora de discos con caché para mejorar el rendimiento, no debemos escatimar en los discos que le conectamos. Si nuestro entorno va a ser un laboratorio o un entorno de desarrollo con poca carga de compilaciones, podemos elegir discos sata, de 7200 rpm y cuantos más mejor (llenar todas las bahías disponibles es una buena opción). Si vamos a tener servidores de producción, elegir discos SAS de 15.000 rpm no es ninguna tontería.

Si te lo puedes permitir, piensa en discos SSD. Pero ten presente que no debes escatimar en ellos. Muchos SSD de escritorio pueden acabar en disgusto por no tener una calidad adecuada, sobre todo en el firmware que controla los errores. Usa RAID1 o RAID1+0 para garantizar tus datos ante un posible fallo de uno de ellos.

Almacenamiento compartido

El almacenamiento compartido es la norma cuando un entorno virtualizado alcanza unas dimensiones medianas. Facilita muchas tareas, sobre todo las relacionadas con el balanceo de recursos y alta disponibilidad.

Se trata de equipos específicamente dedicados a almacenamiento que prestan acceso a otros servidores mediante una conexion de red, ya sea ethernet o de fibra.

La elección del medio queda a criterio del usuario. Personalmente, me inclino por soluciones basadas en TCP/IP como NFS, aunque en algunos casos utilizo / he utilizado iSCSI. Las soluciones basadas en Fiber Channel llevan aparejado un coste superior en infraestructura de red para soportarlas.

Conectividad de almacenamiento compartido

El almacenamiento compartido, dependiendo de la gama en que nos fijemos, puede tener una o varias controladoras, que son las encargadas de comunicarse con los hosts y trasladar sus peticiones a los discos que tiene conectados. En el caso del almacenamiento de gama baja, nos encontraremos siempre con una controladora. En la gama alta, encontraremos a partir de 2 controladoras para arriba.

Almacenamiento con una única controladora

Cuando nuestro almacenamiento es entry level o gama baja, debemos asumir que no dispondremos de alta disponibilidad para los siguientes escenarios:

  • Actualizaciones de firmware de la controladora
  • Fallos y reinicios de la misma.

Esto no debe frenarnos para desplegar un almacenamiento compartido del estilo de Synology, por ejemplo, en un entorno en el que podamos asumir esos riesgos.  Tan solo debemos por precaución asegurarnos de que dispone como mínimo de dos puertos ethernet diferentes que podemos configurar con un channel bonding (LACP 802.3ad) en modo activo-pasivo.

Para configurar de la mejor forma posible un almacenamiento compartido para virtualización lo conectaremos de la siguiente manera:

Escenario con 2 switches diferentes para conectar nuestra controladora

Con esta configuración sobreviviríamos sin problema a la caida del switch 2 y tendríamos un tiempo de convergencia de HA en caso de que se nos fuese el Switch 1 mientras el almacenamiento hace activa la ip 10.10.10.1 en su tarjeta de red secundaria, conectada al Switch 2.

Ejemplo de almacenamiento de gama baja Synology

synology-delantesynology-detras

No nos confundamos, dentro de los equipos básicos se trata de uno avanzado, ya que tiene capacidad para poner 2 SSD como caché de lectura para iSCSI, y doble fuente de alimentación, importante y a veces olvidado. Podemos ver que tiene 4 puertos gigabit con los que podríamos conseguir 2 grupos de 2 interfaces activo-pasivo mediante LACP, por ejemplo. También tiene dos conectores a la derecha de los ethernet para conectar bandejas de discos que permitirían al almacenamiento crecer en capacidad.

¿Qué le falta?

Dos controladoras. En el momento en que este equipo se ponga en producción, no podrá actualizarse ni parchearse sin una parada de servicio o mover todos sus datos a otro almacenamiento mediante técnicas del estilo Storage vMotion.
También le faltan funciones como deduplicación o compresión automática de los datos.
No trabaja con un sistema de archivos del estilo de ZFS con checksums de los bloques de datos por lo que es incapaz de detectar degradación de los datos a lo largo del tiempo por el Bit Flip Error o Rot Bit.
Creo recordar que tampoco ofrece un sistema de replicación a nivel de bloques y se queda en el RSYNC.
Tampoco tiene capacidad de hacer snapshots del contenido.
No dispone de caché más allá de su memoria RAM y ésta no se encuentra respaldada por ninguna batería en caso de fallo de alimentación.

¿Que ventajas tiene?

Cuesta menos de 3000 euros con dos fuentes de alimentación y capacidad para 12 discos. Te da la posibilidad de poner 2 SSD como cache de lectura si usas iSCSI y su panel de control permite añadir cosas como servidor DNS, de correo, radius, LDAP. A mi me gusta mucho este aparatito (tengo dos en el trabajo) pero no pondría mis máquinas de producción en el.

Almacenamiento con más de una controladora

Los arrays de discos para almacenamiento compartido para virtualización suelen tener un tamaño de a partir de 2U de rack y disponer de varios puertos ethernet de 1Gbps o 10Gbps.

Ten los pies en el suelo. Hace falta mucha transferencia de datos para saturar un enlace de 10Gbps, por lo que en muchas ocasiones para entornos pequeños-medianos puede servir conectar el array de discos mediante enlaces de 1Gbps. Mi recomendación aquí es que no escatimes en puertos de switch y como mínimo configures dos puertos para cada controladora para lograr alta disponibilidad en caso de que se caiga un switch.

Para lograr esta redundancia conectaremos una de las controladoras al switch A y otra al switch B y repetiremos el mismo proceso con la otra controladora.

Montaremos un LACP (802.3ad) de tipo activo-pasivo en las controladoras. De este modo, no necesitaremos un channel entre los dos switches que suele requerir un coste extra en características de los switches.

Respetando este esquema de conexiones, si se cae uno de los switches, tan solo tendremos que hacer failover en una de las controladoras. El tiempo de convergencia de las controladoras dependen de cada fabricante y deberá ser consultado con el mismo. Normalmente no se deberían perder más de 2-3 segundos de conectividad, algo perfectamente asumible por el hipervisor.

Ejemplo de almacenamiento compartido de gama media, un Netapp FAS2240-2

Realmente es la gama baja de Netapp, pero por características, entra dentro de la gama media

netapp-delante

netapp-detras

Podemos ver las dobles controladoras independientes e idénticas. En caso de fallo, podrías sacar físicamente la rota y reemplazarla sin apagar el equipo. En el momento del fallo el equipo balancea todo el servicio a la controladora que sobrevive y llama al fabricante para que (si pagas el mantenimiento) te envíen automáticamente una pieza de reemplazo. Esto ocurre también con los discos, fuentes de alimentación, etc.

Podemos observar también que tiene cuatro puertos gigabit a la derecha del todo, junto a otros dos en los que podemos conectar SFP y dotar al equipo de 4 puertos de 10gbps. También lleva puertos de administración dedicados para poder conectarlos a una red OBSN y otros dos puertos para conectar bandejas de discos adicionales.

Dispone de 12 GB de caché NVRAM (resistente a fallos de alimentación) que se replican entre ambas controladoras por un canal privado interno (6GB+6GB utilizables).

En el apartado de software, incorpora deduplicación de datos (escanea los discos en bloques de 4KB y si encuentra bloques repetidos, deja solo una copia y ahorra bastante espacio). Compresión de datos al vuelo, snapshots inmediatos, replicación a nivel de bloque síncrona en otro equipo remoto…

¿Cual es el problema?

Que vale en torno a 40 mil euros y el soporte anual sale por los 2000.

Genial, y ¿cual elijo?

La pregunta del millón. Valora la dependencia que tienes de la virtualización, que parte de tu sueldo pagará a fin de mes. Ten presente también que riesgos son asumibles y cuales no. Conociendo tu infraestructura también podrás saber si no tiene sentido tener un almacenamiento para virtualización con varias controladoras si resulta que solo tienes un switch al que conectarlo.

Recomiendo siempre que se pueda, optemos por la doble fuente de alimentación siempre que pueda cambiarse en caliente. Si una se quema, podremos reemplazarla sin un apagado del equipo. La cache SSD que empiezan a incorporar equipos superiores de la gama baja es muy interesante por un precio irrisorio.

Valora los costes de los mantenimientos, así como de ampliaciones. No escatimes en discos duros. No los compres de escritorio, de los de 100 euros por 4 TB. Los discos NO son iguales. Un disco enterprise está pensado para funcionar 24/7 y lleva firmwares diferentes optimizados sobre todo en la detección y corrección de errores.

Espero que este post te haya servido para conocer algún aspecto nuevo sobre el almacenamiento compartido.

Consejos para hacer backup de tus máquinas virtuales

Disponer de una infraestructura virtualizada puede darte una gran flexibilidad y agilidad a la hora de desplegar nuevos servicios. También puede llevarte a la catástrofe en un momento si no dispones de backups de los equipos que te llevaría horas (o días e incluso semanas) restaurar.

Consejos para hacer backup tus máquinas virtuales y no encontrarte con sorpresas

Separa los backups en diferentes trabajos

No hagas un backup de todo del tirón. Es absurdo. Acabarás con unos trabajos de backup interminables y poco flexibles a la hora de pausarlos. Las ventanas de mantenimiento / deduplicación y checks de integridad también se alargarán.
Si pierdes un juego de backups, es preferible perder solo una porción de ellos que no la totalidad. Hacer un full backup de todas tus máquinas virtuales puede ser bastante impactante en tu entorno.
Tienes servidores que cambian con mucha frecuencia y otros que los tocas cada 2 años. Adapta tus trabajos a esto.

Frecuencia y programación horaria:

No todas tus máquinas tienen la misma prioridad, ni frecuencia de actualización.

    • Tu entorno de desarrollo sufre cambios continuamente, puede tener sentido planificar una copia diaria de todas las máquinas críticas para el equipo de desarrolladores.
    • Tu entorno de preproducción seguramente sufra pocas modificaciones, tan solo cuando una versión de código es suficientemente buena como para llegar allí. Una copia semanal puede ser suficiente. Tampoco necesitas demasiada retención dado que es un entorno que varía poco.
    • Tu entorno de producción cambia menos que el de producción, pero la frecuencia de los backups y retención de los mismos dependerá de si las máquinas virtuales almacenan datos o información cambiante sensible, o si son meramente trabajadores que usan un directorio externo compartido.

Ten presente la carga de tus servidores para programar los backups.

    • Los backups del entorno de desarrollo los suelo lanzar a las 23h, que ya no suele haber nadie trabajando.
    • Los backups de preproducción yo suelo configurarlos el fin de semana, por la mañana.
    • Los backups de producción los suelo configurar de madrugada, y NUNCA haciendo todas las máquinas de un tipo a la vez. Nunca se hace backup concurrente de todos los servidores web, o todos los radius, etc. De hecho procuro no hacer de más de una máquina de cada tipo a la vez.

Haz copia de las nuevas máquinas virtuales

Curiosamente, las máquinas tienden a multiplicarse. Ya seas tu quien las cree, o el equipo de desarrollo, nunca te olvides de revisar periódicamente si estás haciendo copia de seguridad de las máquinas virtuales más recientes.

No escatimes en el almacenamiento que destines a hacer el backup

Tu sistema de backup es el seguro de vida de tu negocio en caso de desastre. No te la juegues usando el almacenamiento más barato disponible.

El proceso de backup, comprobación de datos periódica es bastante intensivo con el almacenamiento, cuanto más rápido vaya, menos durarán tus backups, más rápido se harán las verificaciones, etc.

Si llega el día en que quieras restaurar máquinas virtuales desde tu backup, hasta un dispositivo conectado por 10G te va a parecer lento cuando tengas muchos ojos pendientes de tí.

Haz pruebas de restauración periódicas

En mas de una ocasión he detectado un problema en los backups al ir a hacer una prueba de restauración.

No necesitas reemplazar tus servidores de producción, tan solo restaura con un nombre diferente y enciende el equipo restaurado con las tarjetas de red desconectadas. Dormirás más tranquilo al ver que todo se restaura bien.

Yo hago pruebas de restauración de una máquina aleatoria de cada trabajo de backup como mínimo una vez al mes.

Haz copias de lo que no son las máquinas virtuales propiamente

Si usas vSphere, como es mi caso, haz copias DIARIAS de tu base de datos de vCenter.

Haz copias diarias también de tu base de datos de Single Sign On si usas 5.1, y de los certificados y archivo de base de datos de SSO si usas vSphere 5.5

La regla del 3-2-1

Hay una regla muy antigua que dice que has de mantener TRES copias de tus datos en DOS soportes físicos diferentes, UNO de los cuales has de enviar fuera de tus instalaciones.

Para muchos entornos esto puede resultar excesivo, pero yo recomiendo mantener como mínimo una copia en el datacenter + otra off site.

Usa las copias incrementales y tecnologías de deduplicación siempre que sea posible

La deduplicación puede hacerte ahorrar enormes cantidades de espacio a la hora de hacer tus backups. Hablamos de meter en 2 TB de espacio deduplicado información como para restaurar 10 TB de máquinas virtuales completas. Las copias de seguridad incrementales también reducen en gran parte la duración en tiempo y tamaño de los backups, usando tecnologías como el CBT (Changed block tracking).

Estos son mis consejos para hacer backup de tus máquinas virtuales

 

Introducción a la virtualización (I)

Virtualizar tu plataforma de servidores debe tener como objetivo dos cosas:

  • Consolidar recursos: Agrupar cargas de trabajo en menos cantidad de infraestructura.
  • Facilitarte la vida: Debe significar que al final del día has necesitado menos esfuerzo y tiempo para administrar tu infraestructura.

Analiza tu infraestructura actual

En la mayoría de entornos, nos encontramos con N servidores que están prestando diferentes servicios. Para este primer post de introducción a la virtualización, utilizaremos un servicio web en 3 simples capas que conste de los siguientes componentes:

  1. Frontales web
    • Tienen una configuración típica de 4 cores, 4GB RAM sus discos son de 250GB SATA en RAID1 hardware con una controladora básica. Ocupación de disco, no suele estar más allá del 15% salvo que tengamos síndrome de diógenes con los logs.
    • Por lo general un servidor web en una infraestructura de estas dimensiones no tiene mucha carga. Consumen algo de CPU, poca RAM y lo único que necesitan acceder al disco es cuando se reinicia el servidor o cuando se modifican los archivos que están sirviéndose.
  2. Backend
    • Tienen una configuración típica de 4 cores, 8GB RAM sus discos son de 250GB SATA en RAID1 hardware con una controladora básica. Ocupación del disco, no suele estar más allá del 25% salvo que tengamos síndrome de diógenes con los logs.
    • Contienen aplicaciones que interactúan con los frontales web atendiendo sus peticiones, interactúan con terceros como pasarelas de pago o proveedores de logística. También son consumidores de consultas a base de datos. Sus necesidades son habitualmente de memoria RAM, poca CPU salvo cuando se arrancan inicialmente los servicios.
  3. Bases de datos
    • Tienen una configuración típica de 4 cores, 8GB RAM sus discos son de 146 GB SAS en RAID1 hardware con una controladora básica. Ocupación del disco, no debería estar más allá del 50%.
    • Las bases de datos son consumidoras típicas de RAM e I/O de disco.

En total tenemos 8 servidores, metidos en un rack, ocupando 8U de espacio, 8 conexiones de alimentación (16 preferiblemente si hacemos las cosas bien y tenemos fuentes de alimentación redundantes), sus conexiones de red, que pueden variar desde 8 hasta 32 (si separamos el tráfico de gestión del de servicio ya nos plantamos en 8×2, y si además usamos algun tipo de bonding o teaming para tener alta disponibilidad nos plantamos en 8x2x2). Además de esto, tenemos que tener, en el ultimo supuesto, 4 switches dedicados 2+2 a gestión y servicio, por la redundancia. Eso son otras 4U y otros 4 puntos de alimentación en el rack.

Recapitulemos:

  • 8U de servidores + 4U de switches = 12U de rack utilizados.
  • 8 servidores con 4 cores cada uno = 32 CPU cores.
  • 4 servidores con 4 GB de RAM + 4 servidores con 8 GB de RAM = 48GB de RAM.
  • 16 conexiones de alimentación de servidores + 4 de alimentación de switches = 20 tomas de potencia.
  • 6 servidores con un mínimo de 2 discos de 250 GB SATA cada uno para hacer el RAID1=16 discos duros SATA, 4.000 GB de espacio SATA bruto.
  • 2 servidores con un mínimo de 2 discos de 146 GB SAS cada uno para el RAID1 = 4 discos SAS, casi 600GB de espacio SAS bruto.
  • 32 conexiones de red= 32 cables que guiar y etiquetar, 32 puertos de switch que administrar.

 Conoce el uso real de tu infraestructura

Muchas empresas limitan su monitorización a hacer pings a sus servidores o como mucho lanzan peticiones para verificar que el servicio responde. Una parte importante de la monitorización pasa por medir el uso real de recursos que tenemos. Herramientas como Zabbix, Nagios, Pandora, Hyperic, son capaces de almacenar estadísticas de uso de CPU, RAM, Swap, I/O de disco, tráfico de red, uso de espacio en disco y nos pueden ayudar enormemente a valorar el uso real que hacemos de nuestros equipos así como de planificar futuras ampliaciones con tiempo.

Hay un aspecto importante a tener en cuenta cuando medimos el uso de nuestros equipos. No debemos tomar por lo general la media diaria. Debemos conocer cuales son nuestras horas pico y nuestras horas valle en el servicio. Los sistemas encargados de vender abonos mensuales de transporte, por ejemplo, tendrán mucha mas carga los primeros 4-5 días del mes que a finales. A continuación vemos la gráfica de un servidor web en la que se puede ver claramente este patrón de uso de hora picohora valle:

En la gráfica de CPU podemos ver que aunque la media de uso de CPU es 17%, llegamos al 25% en la hora pico. La línea verde traza la media de los valores mientras que la franja color encarnado muestra la franja de valores máximos y mínimos obtenidos en cada lectura.

Uso de CPU en servidor web

En la gráfica de memoria vemos que el servidor no utiliza nunca más del 21% de su memoria RAM (este equipo tiene 8 GB). En este caso ese 21% correspondía a 1600MB.
Uso de RAM en servidor web

He tomado unos valores de entre 25% y 30% de uso máximo de cpu para web, entre 10% y 15% para los equipos de backend, y 10% para las bases de datos.

consolidacion_modelo_tradicional_2Con estos datos, podemos ver claramente que estamos desperdiciando un montón de capacidad de CPU, así como de casi la mitad de la memoria RAM de los equipos.

Consolidación de recursos

En Virtualización, un host es un servidor físico que aloja guests (máquinas virtuales).

Se conoce como ratio de consolidación la relación entre máquinas virtuales (servidores virtualizados) por cada host físico. Así pues, un ratio de 4:1 indica que hemos metido 4 maquinas virtuales en un host físico.

JAMÁS se debe intentar utilizar al 100% los recursos de un host físico. Eso nos dejaría totalmente expuestos ante momentos de carga extra, degradando el servicio. Yo no recomiendo ir nunca más allá del 60% de uso de CPU en Ghz, ni más allá del 80% de uso de RAM.

Otro aspecto a cuidar cuando virtualizamos es no asignar muchos mas recursos de los que necesitamos. En los ejemplos anteriores vemos claramente que los servidores web consumían 1 de sus 4 cores, y 2 de sus 4 GB. En el caso de backend, 1 de sus 4 cores era de sobra, y con 5GB de RAM les bastaba. Por último, las bases de datos, habrían ido muy sobradas con 1 core y 6 GB de RAM.

La métrica de los IOPS la comentaremos más adelante en otro post dedicado.

Así pues, en nuestro nuevo entorno virtualizado crearemos 4 máquinas virtuales para web, pero con 2 cores y 2 GB de RAM, Backend recibiría 2 máquinas virtuales de 1 core cada una y 5 GB de RAM. Finalmente las bases de datos tendrían 1 core y 6 GB de RAM.

De los 32 cores CPU y 48 GB de RAM que teníamos ocupados antes en diferentes máquinas hemos pasado a tener 12 cores CPU y 30 GB de RAM. Esto corresponde con 4 de los 8 servidores que teníamos instalados inicialmente (sería deseable mover la RAM de los equipos que retiramos a los hosts físicos).

Nuestros 4 hosts físicos tienen doble fuente de alimentación, y separan el tráfico de gestión del de servicio, con doble interfaz para cada propósito.

Beneficios de la consolidación de servidores

  • Hemos pasado de 8 servidores a 4.
  • Hemos pasado de 32 cables y puertos de switch a 16.
  • Hemos pasado de 16 tomas de alimentación a 8.

Además de estos beneficios evidentes, dispondremos de otros como:

  • Posibilidad de clonar un servidor y cambiarle ls ips por otras nuevas para disponer de capacidad adicional manteniendo configuraciones exactamente iguales.
  • Posibilidad de crear backups de la máquina virtual completa, restaurando el servidor exactamente al punto que estaba en diferentes momentos del pasado.

Este sería un primer paso de introducción a la virtualización de los servidores de una pequeña empresa. Posteriormente, las siguientes recomendaciones pasarían por instalar almacenamiento compartido. Eso habilitaría cosas muy interesantes como la alta disponibilidad y lo veremos en un post posterior.