Lo que nadie te va a contar sobre las consecuencias negativas de la virtualización.

463741502c1ef58458437425e3c67529

”En las batallas te das cuenta de que los planes son inservibles, pero hacer planes indispensable”, Dwight E. Eisenhower.

463741502c1ef58458437425e3c67529

Como bien decía Eisenhower, aunque no te vaya a hacer falta (o así lo crees), planifica y organiza, organiza y muchas veces, lidiar con nuestros entornos virtuales me han parecido algo parecido a batallas. Me explico:

¿La virtualización tiene sus partes negativas?

Como todo en esta vida, no todo son albricias, todo tiene su “bueno, pero ademas…”.

En este caso estamos ante una tecnología que como hemos visto en otros posts, “todo son facilidades”, bueno, hasta que nos topamos con el “sprawl”. Este término inglés lo podríamos trducir por “expandirse”, “extenderse” o “desparramarse” y estoy seguro que muchos de vosotros, en cuanto entremos en harina lo reconoceréis fácilmente.

¿QUÉ ES EL VM SPRAWL?

VM sprawl es un fenómeno que ocurre cuando el numero de VMs en un sistema llega a tal punto que el administrador no puede gestionarlo de forma eficiente, bien por el numero de VMs que gestiona y no tiene identificadas, bien porque a veces (demasiadas) no sabe ni lo que hace ahí esa VM.

el porque del “sprawl”

El Correo electrónico es un buen símil del sprawl en el mundo virtualizado. Empezó cuando el señor A quería decirle algo al señor B, sobre un tema interesante. La facilidad con la que se ha podido obtener cuentas de email para todo el mundo y la necesidad de comunicarse entre los humanos ha hecho que nuestras bandejas de Inbox, hoy por hoy, sean casi ingobernables.

Creo que una vez se ha virtualizado un entorno, se entra en un nuevo paradigma parecido al de “barra libre” (en unos casos más en unos casos menos, de todo he visto)

  • Se crea un nuevo paradigma. “Mira, no necesitamos casi nada, en 15 minutos podemos tener un server para ti”.
  • Necesito una maquina. La quiero ya, no es necesario esperar al servidor. Mira clóname ésta y ya la limpiaré yo.
  • Gradualmente esta “resistencia” va cayendo y de forma gradual van apareciendo  máquinas que al final perdemos el control
  • De la misma forma que ocurre su creación “por las prisas”, la organización, “por las prisas” olvida que hay ahí recursos usado o pero aún, funcionando, consumiendo tensión eléctrica del Host, de la aclimatación de aire, etc. que se podrían evitar.

CONSECUENCIAS DEL SPRAWL

Las consecuencias del sprawl son todas ellas económicas en su raíz, pero vamos a enumerarlas para una mayor claridad:

  • Máquinas Zombies. Máquinas en marcha que nadie accede a ellas, ya no se utilizan pero estan ahí. Malgastan disco, CPU y memoria
  • Snapshots no controlados. Nos consumen espacio en disco no necesario y cuanto mas tardemos en quitarlos, más nos va a costar en quitarlo, en tiempo de proceso y complicaciones
  • Máquinas paradas o suspendidas. Igual que el primer concepto, sólo que si no se usan, ¿por qué están ahí?. Malgastan disco
  • Vmdks o ficheros huérfanos. En distintos movimientos de las VMs fallidos, o en algun “crash”, es relativamente fácil que nos hayan quedado ficheros y discos “huérfanos” que no dependen de nadie. Malgastan espacio
  • Tener cuidado con el “Thin Provisioning”. Thin Provisioning es lo más alejado de “shot & forget” pues aunque tiene definido X espacio, realmente está ocupando X/Y pero nada va a impedir que el usuario, aplicación o “dueño” de la VM nos reduzca drásticamente la Y al hacer un volcado de una BBDD o de una aplicación
  • Licencias de aplicación. Si tenemos máquinas que no estamos usando, las licencias que puede haber en estas VMs se prodrían reutilizar en otra VM o lugar
  • VMs con memoria o CPU sobredimensionada. En Virtualización, la expresión menos es más toma su más alto sentido. Si sobredimensionamos en CPU una VM veremos como su rendimiento puede decaer debido al fenómeno llamado “co-stop”. Mal uso de CPU y/o memoria.

FORMAS SENCILLAS DE MITIGARLO

Aunque ya existen herramientas encargadas de ello como los “Virtual Machine Lifecicle Managemente” (VMLM), es cierto que en general son productos con un precio elevado que hace que desistamos en plantearnos la compra de uno de ellos.

No obstante hay formas y metodologías que nos permiten mitigar el sprawl y todas ellas se basan en una, organización:

  • Crear plantillas de las máquinas que vamos a usar normalmente y que estén “homologadas” por la dirección de TI de la empresa (si la empresa usa Ubuntu, pues una plantilla de Ubuntu, así no tendremos Debian, Fedora y  Ubuntu mezclados por ahí salvo en los casos que sea preciso.
  • Dar los permisos de crear nuevas VMs al SysAdmin.
  • Establecer un formulacio y su circuito de petición de VM nueva, donde debe especificarse que Departamento y que persona va a ser el “propietario” de la VM, el propósito de la máquina y si interacciona con otra y sobre todo la fecha de expiración de la VM
  • Con este documento y la autorización del CIO, el SysAdmin procederá al alta de la VM.
  • Tras inventariar la VM, introducirá los TAGS en la misma de Dpto, propietario y sobre todo la fecha de expiración.
  • Tendrá que haber alguien o hacer un script para que vaya “delatando” las VM que se hallan en período “post-produccion”. Puestos en contacto con el propietario se acordará su ampliación del tiempo de producción o su borrado.

No nos debe extrañar que haya “fecha de caducidad” en las VM. Como decíamos, una de las potencias de la virtualización es la facilidad de creación de VMs, se utilizan y acto seguido , cuando no son necesarias, “ahí quedan”, utilizando unos preciados cursos no baratos precisamente.

Evidentement esto se debe conjugar con unas auditorías internas utilizando herramientas o scripts capaces de localizar disco huerfanos, etc.

¿SOLO EN VIRTUALIZACION?

No, no es un mal “endémico” de la virtualización. Tal como puedes ver en las referencias, ya existía el server sprawl en el entorno físico que se definía como una pobre utilización, no controlados ni organizados, de los recursos de IT de los que disponía una entidad.

De ahí venimos, y “esas lluvias, estos barros”, pero vemos que ahora el sprawl se expande a La Cloud.

Gracias a la facilidad que comporta, estamos llegando a hacer deploy en breve tiempo en Amazón AWS, mientras tenemos una máquina en Amazon y algunas en algún service provider. Las probamos, vemos como funcionan y ahí se nos quedan. Esto en cuanto a Infraestructura as a Service (IaaS), pero seamos conscientes de lo que estamos haciendo en la parte Software as a Service (SaaS). Es típico que alguien esté fuera de tiempo y una solución en la cloud le ayude de forma importante y tirando de Paypal o de tarjeta la contratemos en minutos. Y lo más fácil es que ahí se quede.

Osea, te recomiendo que revises tu cuenta de Paypal o tu extracto de la Visa para ir detectando estos “Zombies” que te van debilitando la cartera.

CONCLUSIONES

Queda claro el alcance del VM Sprawl. No es la primera vez que somos requeridos para evaluar la expansion de un entorno y terminar haciendo una consultoría sobre la adecuación del uso de los recursos.

Desde Orbal nos preocupa mucho este fenómeno y es algo que hacemos difusión especial para que todas vuestras infraestructuras funcionen lo mejor posible y os den a vuestras empresas el ROI que ofrecimos al mover vuestro entorno físico a entorno virtual.

Por otro lado estamos trabajando en un proyecto para controlar el VM sprawl. Si alguien está interesado en el tema, estamos a vuestra disposición en este link

Recomendación: el sprawl es muy peligroso y traicionero. Llega el día en que se precisan una serie de recursos para un proyecto y salta la pregunta ¿Donde fueron nuestros recursos? y el SysAdmin no tendrá la respuesta adecuada para esta pregunta, cosa que será peligrosa. Aplicad todos los medios para mantener bajo control vuestra infraestructura.

Take care

JM

Foto: Morguefile

Referencias:

  • Server Sprawl de Anil Desai
  • Virtual machine sprawl prevention: Best practices.
  • VMware. Controlling Virtual machine Sprawl


Source: jmgriscom

About the Author