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

septiembre 27, 2016 — por Josep Maria0

main

Assoc. Cat. VirtualitzacióCloudConsultoríaCPDEstrategia de EmpresaMetodologíaVeeamVirtualizacionVMware

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

septiembre 27, 2016 — por Josep Maria0

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

 

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

463741502c1ef58458437425e3c67529¿La virtualización tiene sus partes negativas?

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

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 traducir 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.
  • Normalmente no se tiene conocimiento de cuantos recursos de infraestructura “reales” podemos servir.

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 y overhead
  • 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 y pueden ser un dolor fuerte de cabeza organizativamente.
  • 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 Y que al inicio generalmente es mucho menor que X, lo cual, haciendo numeros de ocupación nos dara una cifra usada baja, aunque la definición sea mucho más alta, pero nada va a impedir que el usuario, aplicación o “dueño” de la VM nos incremente 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 Management” (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 qué Departamento y qué 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, ni 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 Amazon 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 sobre el tema que va a ser interesante, si alguien está interesado en el tema, aquí estamos a vuestra disposición.

Recomendación. El sprawl puede ser muy perjudicial y traicionero. No te lo esperas y llega el día en que la empresa precisa una serie de recursos para un proyecto y salta la pregunta ¿No tenemos recursos? ¿Donde fueron a parar?. Si el SysAdmin no tiene la respuesta adecuada preparada para esta pregunta, 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.
  • Veeam. How to avoid VM sprawl and improve resource utilization in VMware and Veeam backup infrastructures
  • VMware. Controlling Virtual machine Sprawl

Dejar comentario

Tu dirección de correo no será publicada Los campos requeridos están marcados con *

14 + diecisiete =