Vamos a retomar el caso práctico que nos planteábamos en el post anterior, donde pretendíamos virtualizar parte de un entorno de producción. Tras la definición del ámbito del proyecto, pasemos a definir la infraestructura virtual necesaria.
Servidores físicos.
en el ejemplo que nos ocupa, se pretende virtualizar un total de 31 servidores. Hemos de tener en cuenta que todas estas máquinas dependerán de la integridad de los servidores ESX, con lo cual la tolerancia a fallos ha de ser una premisa del diseño de la instalación.
En el caso que nos ocupa, el planteamiento inicial implica la instalación de dos servidores ESX. Ese es un escenario económico y altamente rentable, que sacrifica rendimiento y tolerancia a fallos en pro de la economía. Intentaremos dibujar otros dos posibles escenarios, que balanceen mejor las prestaciones, la tolerancia a fallos y los costes.
Dos servidores, si... ¿Pero con qué configuración?
nº de procesadores.
VMware (y yo, basándome en la experiencia) recomienda no superar las 8 máquinas virtuales por procesador. Esto ha de tomarse como una norma general con múltiples excepciones: No es lo mismo 8 servidores SQL en cluster que 8 servidores web... de hecho, yo mismo he virtualizado hasta 13 servidores por CPU con rendimientos aceptables. También es importante definir los requerimientos de los entornos virtualizados: No tenemos porqué tener el mismo rendimiento en Desarrollo que en los sistemas de producción... y un RADIUS no requiere lo mismo que un SQL server.
En este caso, yo me inclinaría por servidores biprocesador con dual core, más que por sistemas tetraprocesador. VI3 es uno de los pocos entornos donde las ventajas del crecimiento horizontal son realmente palpables. Recordemos que VI3 nos permite hacer crecer nuestra infraestructura virtual añadiendo nuevas máquinas. Una instalación como la que nos ocupa puede comenzar con dos máquinas y crecer sin que por ello la inversión realizada inicialmente quede obsoleta.
Evidentemente, han de distribuirse los recursos de toda la infraestructura virtual de acuerdo con los requerimientos de cada servidor: Balancear entre distintas CPUs las máquinas con más carga (o requerimientos), un buen diseño de los pools de recursos, y un diseño adecuado de la infraestructura de almacenamiento.
Partiendo de esta base, las máquinas que nos ocupan deberían ir equipadas con dos procesadores dual core, lo que nos daría un total de 8 cores.
En el ejemplo que nos ocupa, nuestra infraestructura virtual soporta (teóricamente) hasta 64 máquinas virtuales (8 por core)... una estimación más realista, teniendo en cuenta que en caso de pérdida de servicio de uno de los servidores ESX (ya sea por incidencia o por trabajos planificados de mantenimiento), nos debería permitir mantener en funcionamiento, al menos, el cincuenta por ciento de los servidores virtuales. Una buena fórmula de cálculo deberia ser la siguiente: Nº de VM/8+(12) CPUs (El OR dependerá de la pasta que tengamos)
Memoria.
La respuesta es fácil: La máxima posible. ESX es, por definición, un gran consumidor de memoria. Apurar al máximo las capacidades de ahorro de memoria del VMware no es una buena idea en entornos de producción. Hemos de tener en cuenta que ESX, por muy maravilloso producto que sea, no es capaz de predecir las necesidades de memoria que una VM tendrá dentro de un segundo. Una buena fórmula de cálculo de la memoria total requerida para nuestra infraestructura virtual es asumir entre 768Mb y 1 Gb por máquina virtual.... lo que no quiere decir que definamos todas nuestras VM con 768Mb o 1 Gb de RAM. Hay un consumo "extra" de memoria por parte de la capa de virtualización... Calculemos aproximadamente entre 512 y 1Gb de consumo de RAM para el ESX.
Red.
La red es otro elemento fundamental en VI3. VI3 ha de suministrar conectividad de red a las máquinas virtuales que aloja, por lo que deberíamos garantizar tanto el ancho de banda como la tolerancia a fallos de la misma. LA red, tradicionalmente, suele ser una gran olvidada en los entornos de proceso de datos: Se compra, se instala y punto. Al ser uno de los sistemas más robustos de toda la infraestructura IT, suele relegarse a esa categoría de sistemas que "nunca fallan", asi que, consecuentemente, nunca se tocan.
VI3 requiere de electrónica de red eficiente, y una configuración adecuada. Mi personal consejo es tirar de electrónica de rendimiento contrastado y con potentes opciones de configuración. En mi caso, utilizo una pareja de Cisco Catalyst 3750.
En este ejemplo hemos de tener en cuenta las siguientes conexiones de red:
Red de VM
Dedicaremos, al menos, dos enlaces Gigabit por servidor ESX para el tráfico de las máquinas virtuales. Esta duplicidad no viene dada tanto por el ancho de banda como por tolerancia. Recordemos que, con 31 VMs en dos máquinas, cada tarjeta de red da servicio a 15 VMs.
Almacenamiento
Tanto si usamos iSCSI como FC, el enlace ha de estar redundado. Si existe algún componente crítico, este es el acceso al almacenamiento. Añadiremos otras dos conexiones para el almacenamiento. es importante que NO COMBINEMOS iSCSI y NFS sobre la misma red. Si pensamos en utilizar iSCSI y NFS a la vez, debemos utilizar interfaces distintas.
VMotion/HA
Aquí, dependiendo de si usamos VMotion, o VMotion y HA, podremos dedicar una o dos tarjetas por máquina. Si sólo utilizamos VMotion para el movimiento de VMs entre servidores, una tarjeta debería ser suficiente, pero si implementamos HA, este enlace se hace crítico.
Consola.
La conexión de consola es la que nos permitirá acceder a los servidores ESX tanto directamente como a través de VirtualCenter, con lo cual, su criticidad es relativa. Me explico. Si un ESX deja de ser gestionado por VC, no se para, lo que significa que no supone un impacto en la operatividad del sistema. En otras palabras, si cae la consola, tendremos tiempo de maldecir, ponernos la chaqueta, salir a por un cigarrillo y hasta tomar un café antes de ir al CPD porque las VM no se han parado. Yo no suelo dedicar una tarjeta específica para la consola, así que suelo añadir una VLAN, ya sea en VMotion o en las VM, para la consola, pero una interface de 100 Mbit/sec no parece a priori un desembolso excesivo, salvo que no tengamos splot PCI libres.
Como resumen, no escapamos con menos de 6 conexiones de red por servidor.... aunque 8 tampoco es un mal número.
Miscelánea.
Cosas interesantes que debería tener nuestro servidor ESX perfecto:
- Consola remota: Si, lo de tener que ir al CPD es pelín incómodo, y además, podemos resfriarnos.
- Remote Power On/Off: Más de lo mismo.
- Disco de arranque en Mirror: Vaya que si nos gastamos una pasta en almacenamiento para VMFS y después los ESX no arrancan porque se nos ha cascado un disco nos va a lucir el pelo.
Almacenamiento.
Siempre he apostado por el uso de SAN para VMware. El uso de un almacenamiento compartido nos abre inmensas posibilidades bajo VI3: La capacidad de movimiento de máquinas virtuales entre ESX's, mayor racionalidad en el uso de almacenamiento, y el coste cada vez más bajo de este tipo de soluciones me parecen razones más que suficientes.
Pero no debemos olvidar la opción NFS que nos brinda ESX. NFS no nos va a dar, ni de lejos, el rendimiento de una SAN FC o iSCSI, pero se plantea como una solución económica para el almacenamiento de Templates, imágenes ISO, etc... y para eso podemos utilizar el espacio de nuestro servidor de ficheros Windows mediante productos gratuítos como el Windows Service for Unix, que nos permite compartir una carpeta de nuestro servidor de ficheros como un share NFS. Creedme... por muy grande que hayamos diseñado nuestra LUN para VMware, siempre, siempre, se nos quedará corta.
En mi caso particular, siempre he preferido iSCSI a FC, tanto por razones de coste como de sencillez y simplicidad de configuración. Una instalación FC requiere, además de las HBA FC (a un buen pico cada una, casi 2000€), hemos de tener en cuenta los switches (los minihubs que incorporan algunos fabricantes no son demasiada buena idea), el multipathing o capacidad para que un host vea una LUN por dos controladores FC y no las gestione como dos LUNS, o el trunking (agrupar dos o más canales FC para que actúen como uno solo) suelen tener un coste adicional. (de hecho, siempre he recomendado a los fabricantes de equipamiento FC que incorporen ya el lector de Visa en sus equipos, dado que para hacer casi cualquier cosa hace falta una licencia). También FC es más lioso de gestionar y configurar, y el conocimiento suele ser específico para cada equipo.
iSCSI ofrece menor rendimiento (unos 800-850 Mb/sec teóricos en enlace de un GbE frente a los 900-950 Mbit/sec de un enlace FC), consumen más recursos de la máquina en el caso de iniciadores software (es la CPU del host la que ha de pelearse con el TCP/IP y los comandos SCSI3), pero en una instalación pequeña (llamo pequeña hasta 6 - 10 servidores conectados a un target iSCSI) el diferencial de rendimiento no suele apreciarse.
Por contra, el uso de Ethernet como medio de acceso al almacenamiento nos ofrece múltiples ventajas: Trunking de hasta 8 canales gigabit Ethernet, cifrado IPsec estándar, autenticación en base a usuario/password, VLAN's (frente a las zones FC, que son un infierno), y todos los mecanismos ya implementados sobre Ethernet: redundancia, autenticación en conexión (802.1x), y opciones avanzadas de monitorización como el sniffing.
Desde el punto de vista de costes y versatilidad, iSCSI también nos ofrece ventajas, al convertir cualquier puerto de red en un punto de acceso al almacenamiento en potencia. Además, el coste de un puerto ethernet de 1 Gbit/sec, incluso en equipos de gama alta, no llega a la mitad del coste final de un puerto FC.
Backup.
Algo que se suele tender a olvidar en los entornos VMware es que hay que sacar copias de las VM. Aquí tenemos dos posibles aproximaciones: Copia individual de cada máquina virtual, o copia total de la infraestructura virtual.
Evidentemente la segunda opción, el sacar una copia del VMfs donde tengamos almacenadas las VM puede parecer la mejor opción: Pocas LUN que copiar y un agente por servidor ESX, pero hay que tener en cuenta otro aspecto ciertamente importante.
Veritas, Legato y demás permiten la realización de copias diferenciales o incrementales, es decir, sólo copian los ficheros que han cambiado desde el último backup total o desde el último incremental realizado. Esto nos permite disminuir las ventanas de backup y ahorrar en disco. Si aplicamos esta filosofía a VMware nos encontraremos con la lindeza de que cada backup diario es, en realidad, un full backup. ¿Porqué? porque los discos virtuales, los vmdk son un fichero.... que cambia cada vez que el SO virtualizado está encendido. Así que el backup de, digamos, 600Gb de VMfs (no, no os asustéis, se llega con facilidad), nos obliga a disponer de .. 4.2Tb de espacio de backup.... por semana.
El uso de snapshots ("fotos" del disco que se pueden mantener a intervalos programables y que pueden ser revertidas), también puede parecer una hermosa solución... si no fuera por un par de detalles. En primer lugar, ningún sistema operativo trabaja directamente con el disco, así que si en un momento dado "congelamos" el disco, es probable que la mitad de los datos estén en la memoria del sistema operativo virtualizado y no en el disco. Esto es lo que se llama un punto de consistencia. Lo ideal sería poder decirle al SO que hiciese un flush antes de que nosotros ordenemos un snapshot del VMfs... es teóricamente posible (un buen sync bajo linux y alguna chapuza bajo windows).... pero ¿Y las aplicaciones?. Oracle o SQL server van por su lado. Un flush del sistema operativo no tiene porqué obligar a SQL, Oracle o Exchange (por poner ejemplos) a volcar todas las transacciones pendientes. Un snapshot en estas condiciones no vaticina nada bueno. Esto es lo que los gurús del backup llaman "Punto de consistencia", es decir, el estado de un servidor (aplicación incluída) en el que el backup es realmente una imagen consistente del sistema.
Para más INRI, algunas tecnologías de snapshot a nivel de LUN hacen cosas realmente graciosas: NetApp, por ejemplo, te "sugiere" reservar X * 2 espacio para el primer snapshot... siendo X el tamaño estimado de la LUN...
Cuando trabajaba con ESX 1.x y 2.x y se me apareción este problemilla, la única solución que se me ocurrió fué hacer un script que suspendiera una VM, sacara backup del disco y del fichero de suspensión (importante, de ahí la negrita), y volviese a hacer un power on.
Con VI3, VMware introduce el VMware Consolidated Backup. VCB permite el backup de las máquinas virtuales sin parada, de manera incremental y a nivel de fichero individual contenido en una VM. Se basa en la existencia de un Backup Proxy, un servidor Windows que accede a las LUNs de VMfs y es capaz de hacer un snapshot consistente de nuestras VM, que extraeremos con nuestro software de copias de seguridad preferido, es decir, sobre este servidor montaremos nuestro agente de Veritas, Legato o lo que tengamos, y VCB se encargará del resto. Esto es lo bonito. Lo feo es que requiere de unas configuraciones la mar de entretenidas, sólo funciona con FC y hay que hacer alguna pirindola para que se hable con el agente de backup. Por el momento estoy en fase de prueba del mismo, así que poco os puedo decir aún. Si antes de que termine con este caso práctico acabo la evaluación, incluiré la configuración... si no, ya tengo tema para otros post.
Tema importantillo... ¿qué licencia adquirir?. Veamos qué nos ofrece VMware.
Dejando aparte, oh cielos, opciones como el Consolidated Backup, nadie que conozca que haya probado vMotion es capaz de vivir sin él. Conozco casos de quién ha licenciado un VI3 standard, y a la hora de licenciar vMotion y demás, se ha llevado la grata sorpresa del latigazo consecuente que VMware ha tenido a bien darle. Para un entorno como el descrito, os recomiendo encarecidamente licenciar enterprise. VMware licencia por CPU física, lo que quiere decir que en nuestro caso, sólo hemos de licenciar 4 procesadores... para nuestra flamante instalación de 8... o de 16, con los quad de Intel en puertas.
Resumen de la instalación.
Servidores.
Dos máquinas dual core bi-procesador con 8 tarjetas de red, disco RAID, doble fuente de alimentación y 16 Gb de RAM.
Equipo Ejemplo.
Servidores: SUN X4100
Tarjeta de red: Intel® PRO/1000 GT Quad Port Server Adapter, Broadcom NetXtreme® Gigabit Ethernet Controller for Servers
iSCSI HBA's: Qlogic QLA4052
Nota: Ojito. El soporte para iSCSI HBA está todavía en fase experimental.
Almacenamiento.
Deberíamos disponer de, al menos, 600 Gb NETOS para nuestra instalación... mi consejo es que compréis algo que escale, al menos, hasta 3 veces esa cantidad.
iSCSI: NetApp FAS270c, NetApp FAS3000, para pruebas y/o preproducción o pequeños entornos, Openfiler, FalconSTOR IPStor, como prueba de concepto, StarWind iSCSI Target.
FC: Las anteriores junto con cualquier solución soportada por VMware.
NFS: NetApp, obviamente, o cualquier producto que sirva NFS... Microsoft Windows Services for Unix
Electrónica de red.
De los 48 puertos no deberíamos bajar, por aquello de no quedarnos cortos y no tener que empezar a "empalmar" switches con uplinks a giga. Si sois de los afortunados que ya tenéis un chasis mediano o grande (un Catalyst 4500, 6000 o un Nortel Passport o similar), provisionad puertos suficientes... si debéis adquirir electrónica, os recomiendo os vayáis a un chasis pequeño, o en su defecto a cualquier switch modular que soporte stacks de alta velocidad. Eso sí, procurad que tenga la opción de la fuente de alimentación rendundante.
Cisco Catalyst 3750-40 TS o superior... un backplane de, al menos 32 Gbit/sec.
Licencias VMware.
Licencia VI3 Enterprise para 4 Procesadores.
Seguiremos hablando.
J. L. Medina
