Los 3 principales temores de los CIOs sobre virtualizar

Siempre hablamos de los beneficios de virtualizar, de las características, de lo nuevo, de lo mejor, pero en el caso de hoy voy a tratar algo distinto, ¿donde están los verdaderos temores de aquellos que aún no han adoptado la virtualización?, luego de más de 7 años virtualizando, les paso una descripción de donde están centrados los principales temores de los CIOs.

Performance

El primer interrogante que tienen está directamente relacionado con el rendimiento o la performance de sus aplicaciones.

Siempre surge el mismo desafío cuando se hace participar al área de desarrollo, porque los mismos entienden que bajo ese concepto, sus servidores perderán potencia a comparación de sus anteriores pares físicos y por consiguiente todas sus pruebas de desarrollo se verán altamente perjudicadas. Ni hablar de la oposición rotunda por “default” que tienen los DBA (en especial los que tienen su preferencia por oracle).

Para responder a los miedos sobre performance voy a dividir el tema en tres partes básicas; cpu, memoria y disco.

• Cpu,

El manejo de la cpu se realiza bajo un componente llamado “scheduler” el cual se encarga de realizar la asignación de cada core en un intervalo aproximado de 20 msg. Si uno toma datos de performance sobre los sistemas actuales, el promedio no supera el 15 % de uso de cpu.

Otro dato no menor, es que las aplicaciones están mal desarrolladas, si, lamento ser algo crudo con los desarrolladores (van a pensar que tengo algo personal con ellos), pero la realidad es que ninguna hace uso eficiente de los múltiples threads, es decir los varios cores de un sistema.

Si consideramos esta aclaración veremos que las compañías están comprando mayor cantidad de procesamiento (ej: quad core ) solo para gastar más plata en adquisición de cpus y el resumen de la cuenta de luz.

No recomiendo para nada que los jefes de infraestructura confronten con los jefes de desarrollo sobre el porque no se desarrolla en múltiples hilos, dado que seguramente lleve a ambos al caos o incuso no sea un problema propio de desarrollo sinó de la tecnología que soporta dicha aplicación (llamese sistema operativo base, aplication server, etc); pero desde luego,  10 años y 7 virtualizando me han demostrado eso, los multicore no se están usan para nada.

Ahora bien, si hay casos donde las aplicaciones lo usaran, por medio de SMP (tecnología para presentar múltiples procesadores virtuales a una maquina virtual) se podrían tranquilamente crear hasta cuatro virtual cpus para cada maquina virtual y resolver tranquilamente el tema.

• Memoria,

La memoria  se optimiza perfectamente,  muchos de  los usuarios de VMware ven que sus sistemas bootean mas rápido o que incluso sus aplicaciones funcionan mejor. Hay una relación directa entre la memoria y la maquina virtual, es decir conviene tener sistemas con mucha memoria y cpus para almacenar mayor cantidad de maquinas virtuales, y luego asignar a estas la memoria que quiero (no voy a discutir el tema de shares, limits y reservations), pero si quiero explicar que es el TPS (transparent page sharing).

El TPS tiene por definición el eliminar las páginas de memoria redundantes, generalmente estas páginas son datos en memoria llevados en modo read only o código . Cuando una página es identificada como existente en la memoria del esx, dicha pagina es referenciada en el bloque de memoria que le corresponde a la VM, y en definitiva solo se hace el mapeo. Si ustedes usaran maquinas virtuales estandarizadas con el mismo nivel de service pack o kernel, podrán imaginarse lo que ahorrarán en memoria, es por ese motivo que pueden llegar a poner más de 32 maquinas virtuales en un equipo con 16 gigas de memoria y funcionar perfectamente.

Ahora si una de esas páginas debiera modificarse, el hypervisor notara la diferencia y generará una nueva página y la guardará en su propio espacio en memoria, la técnica suena simple pero es avanzada y el principal driver es el uso de una tabla de hash para cada frame de memoria.

El concepto es claro, ahorro de memoria en base a no realizar sobreescrituras superfluas.

Además de ese método, está el método de memory balloning conocido gracias al proceso vmmemctrl que se ejecutara en las maquinas virtuales (incluido dentro de las VMware tools). Simple, si el esx no tiene más memoria se enviará lo que se necesite al storage para paginar utilizando métodos de locación y reclamación para manejarla.

Igualmente para aquellos que quieran conocer más en detalle en breve voy a realizar un post con el manejo detallado de la memoria ram en VMware ESX.

• Disco,

Cuando hablamos de Virtualización, en la mayorías de los casos hablamos de usar subsistemas de disco (storage), ya sea por ISCI o Fibre Channel. Principalemte si uno agrega más ejes al enclosure, mayor performance este le ofrecerá, segundo, se debe hacer mucho hincapié en cómo se configuran las LUNS y la c la forma de trabajar de las controladoras, por ejemplo NetAPP tiene un manejo de memoria   distinto al resto de los players, lo que significa que para el uso convencional del array, EMC, IBM, NETAPP o HITACHI serán casi iguales, pero a la hora de reconstruir arreglos formados, por ejemplo, sobre raid 5, la reconstrucción cuanta mayor memoria tenga la controladora, más rápido se hará y menos se sentirá.

Generalmente los problemas de IO no son los que fueran a tener, si tienen problemas, seguramente sean de SCSI Reservations por una mala configuración de las LUNS y una mala distribución de las VMs y los ESX.

Seguridad,

La seguridad dentro de un ambiente virtual basado en VMware (es el que más conozco),  radica en tenér adecuadamente configurada la service console (su interfaz de administración) basado en un “muy recortado” kernel de Linux red hat. Es decir que no tiene código sobrante que genere vulnerabilidades, pero que las tiene, las tiene como cualquier soft.  Ahora, si uno implementa un correcto protocolo de segurización de la Service Console, les puedo asegurar que las probabilidades de que alguien gane acceso a un ESX segurizado son casi nulas, distinto es ver lo que se ve diariamente donde el 90% de las instalaciones realizadas están por default.

Desde el lado de las maquinas virtuales  entre sí no saben ni que existen, son archivos encapsulados, y en memoria son instancias separadas o compartidas según si es la misma pagina o no. Ninguna VM puede explotar una vulnerabilidad de  la service console porque cada VM trabaja en su propio espacio de memoria. Conclusión, el ESX y las maquinas VMs son dos mundos separados.

Disponibilidad, único punto de fallas,

Otro cuestionamiento que surge es el único punto de fallas, si cae un ESX con 10 VMs  se caen 10 servidores, en cambio si se cae un solo servidor físico cae ese solo. Previamente antes de implementar la solución de virtualización se deberán hacer exigentes test de stress para verificar que el equipamiento no traiga defectos. Los test se recomiendan correrlos por tiempos no menores a 3 días.

Si consideramos tener un storage de disco y al menos dos ESX server para trabajar en cluster, la caída de un ESX implicará ver una reiniciada forzosa de las 10 VMs y se bootearán en el otro ESX por medio de HA. Todo puede llegar a demorar como máximo 5 minutos. Mi pregunta es, cuanto demorará HP, IBM o DELL en traer los módulos necesarios para reponer la parte dañada de eses único equipo?, mientras uno sufre por un Exchange caído dos  o más horas, yo prefiero tener un pequeño booteo y seguir operando como si nada hubiera sucedido. Algo para recordar es que el uptime de los esx está llegando a ser comparado con los de mainframe.  

Lo importante en este caso es comprender que siempre pueden ocurrir fallas, lo importante es ver como uno se prepara para soportarlas.  De que sirve gastar miles de dólares para que un equipo funcione y si este falla se debe tener que esperar a que el técnico traiga las partes. Para eso conviene virtualizar, aprovechar bien la inversión en dos o tres ESX bien distribuidos con un storage redundante, si algo pasara a un de ellos, no me preocuparía dado que las maquinas virtuales se iniciaran en los otros activos.

Ojo, durante el 2009 se lanzará VMware Fault Tolerance (lo cual les permitirá tener 100% alta disponibilidad (activo-activo).

Conclusión

Comprender que la Virtualización es una tecnología para evitar que nuestros servicios dependan de un hardware específico y realmente el hardware se enfoque a satisfacer necesidades de negocio va  a ser la clave para ver en la Virtualización más que beneficios económicos. Hablamos de transformar al departamento de IT en uno más versátil y dinámico para finalmente convertir nuestro datacenter en una ventaja competitiva real.

Ing. Diego Quintana

VCP-VAC-VTSP