Vmware lanza VMware View4

Vmware presenta esta semana la nueva versión de su producto de virtualización de escritorios. En sus primeras versiones denominada VDI y actualmente View 4.

Esta versión, ha sido denominada 4, para incidir en la relación y solidez de la familia de productos creada  entorno a vSphere 4.

La anterior versión del producto fue ya una revolución, pero esta parece llegar cargada de mejoras.

La mas llamativa y que puede revolucionar ciertos escenarios es la inclusión de un nuevo protocolo PCoIP (PC over IP, según reza un vídeo del fabricante).

Las versiones anteriores de VMware View, utilizaban RDP (remote desktop protocol), para acceder a los escritorios mediante el cliente de acceso.

El nuevo protocolo se adapta tanto a las características del puesto al que se servirá la conexión, así como las características de la red en cada momento, de modo que flexibiliza el uso, permitiendo que los componentes core tengan prioridad y sirviendo el modo baja calidad/prioridad, otro tipo de contenidos mientras haya problemas con la red. Todo ello con el objetivo final de producir una sensación y usos optimizados de cara al usuario, que percibirá una mayor fluidez, mas intensa cuando se trate de contenidos multimedia, streaming y similares. Además soporta múltiples monitores en el lado del cliente, así como conexión directa a impresoras, escáneres o dispositivos de almacenamiento conectados al dispositivo cliente.

Ecosistema VMware View 4

Todo ello, hace que el producto sea hoy viable en entornos en los que hasta ahora le eran imposibles.

Incluye, aun de forma experimental, la característica “Offline Desktop”, que permite a usuarios móviles, llevarse el escritorio sin conexión a la empresa para ser sincronizado cunado este conecta de nuevo a la misma.

También incluye soporte experimental para MS Windows 7, a falta que un volumen suficientemente sólido de usuarios valide la configuración y pase a considerarse característica “full support”.

Aplicaciones/add-ons como ThinkApp y Composer han sido mejoradas hacia la nueva versión pero no aportan nada espectacularmente revolucionario, si bien, hay que reconocer que lo que ambos productos aportan lo es ya de por si, incluso en versiones anteriores.

VMware View 4, está disponible en dos versiones: Enterprise y Premium, siendo esta última la más completa.

La diferencia principal entre ambas reside en que la versión Premium incluye Composer, ThinkApp y Offline Desktop.

Vmware indica en la publicidad del producto que es la única plataforma capaz de arrancar hasta 1000 máquinas de forma simultánea, sin pérdida de rendimiento.

Así mismo el número máximo de escritorios  recomendado a gestionar por una sola consola pasa a ser de 10.000, lo que permite darse cuenta de la escalabilidad del producto.

Desde vSolutions.es ofrecemos escritorios y servidores remotos para que nuestros clientes  puedan trabajar en la nube. Evitando así inversiones en hardware y software, con la confianza que ofrece saber que sus sistemas y datos, siempre cifrados,  residen en CPDs de alta disponibilidad.

Ratios de consolidación de servidores mediante virtualización

El responsable de una empresa que gestionaba 3800 servidores físicos me comentaba, hace algo más de un par de años, que volumen de servidores creía, a groso modo, que podría eliminar, en caso de adoptar de forma masiva la Virtualizacion.

En aquella época, una menor experiencia en este tipo de proyectos así como la falta de conocimiento de la carga que soportaba cada servidor, el tipo de aplicaciones que corrían sobre estos y muchos otros aspectos no me permitía decir una cifra, pero sí que le hice ver que podría quitar más de un 60% del total.

Esta empresa, que cuenta con más de 150 informáticos para desempeño de funciones internas, llevó a cabo el proceso, consiguiendo un ratio de consolidación que permitió dejar toda la infraestructura en menos de 270 servidores.

No hace falta explicar la disminución de costes a todos los niveles, pero es mas increíble cuando, en una conversación reciente, me comentan que el retorno de inversión incluyendo el total de costes del proyecto, formación de personal, adecuación de los centro de datos a las nuevas necesidades y demás…fue menor a 18 meses!!!

Por no hablar de que hoy en día TODAS sus aplicaciones pasan por disponer de un estatus de “alta disponibilidad”, mucho mayor que el de  entonces y que los despliegues que antes costaban semanas se realizan en pocos minutos u horas.

Todo esto, no es más que otro caso (ni más ni menos curioso), de los beneficios de la Virtualizacion.

Lo que si me siguen preguntando hoy en día son algunas cosas como:

• En general (que peligro tiene este principio de frase), cuantos servidores se pueden ejecutar por cada uno físico?
• En mi entorno solamente disponemos de X (número bajo)  servidores físicos. Es rentable la virtualización en mi caso?

Dado que no espero que mis interlocutores cambien sus preguntas, será más fácil decir, que una cifra teórica, factible y que seguro que difiere de su caso concreto… podría ser de 7 a 1 (consolidar 7 servidores físicos en 1, aunque algunos me tachen de proporcionar un valor muy conservador y que digan que a veces hasta 20 a 1…). Pero claro, esta afirmación, es solo para callar las preguntas tan repetitivas. Cada caso es diferente y requiere de análisis previo para poder ofrecer un ratio estimado de consolidación.

La segunda pregunta, es más fácil de responder hoy en día que hace algún tiempo, gracias a las nuevas suites y versiones que VMware ha puesto en el mercado.

Si bien, depende de la criticidad y necesidades de cada entorno, podemos decir que  hay entornos en los que se puede acometer un proyecto básico de virtualización a coste cero en el apartado licencias (que es el punto al que se refieren dichas preguntas).

Desde ESXi, que es un hipervisor gratuito, muy efectivo y con capacidad para ser integrado en los entornos más exigentes, hasta vSphere4 en su versión Enterprise plus, existe un gran abanico de capacidades, funcionalidad y precio asociado.

Hoy cualquier empresa debería plantearse la migración a un entorno virtualizado, pudiendo agregar o escalar a entornos más complejos y costosos “en lo referente a la adquisición inicial de licencias”, que no en explotación cuyo coste disminuye conforme agregamos funcionalidad.

Desde los sistemas de backup, las redes, el almacenamiento o la puesta en marcha de nuevos proyectos son áreas (y solo por citar algunas), que se benefician de estas tecnologías.

Si a esto sumamos la independencia de hardware, el que cada fabricante de hipervisor (Citrix, Microsoft, VMware) está en constante guerra con el resto y ello ha hecho que la mayoría dispongan de medios para convertir las VMs de otros fabricantes a su entorno, y que todos ellos buscan desesperadamente el mercado pyme (la gran cuenta hace tiempo que está más que virtualizada)…el que sale ganando, siempre es el usuario final.

vSolutions.es dispone de una infraestructura de servidores consolidada con tecnologías como la mencionada en este post. Ello nos permite ofrecer servicios mas avanzados, a menor coste y con mayores índices de seguridad y disponibilidad. Así, servicios como BKOL se apoyan sobre clusters de servidores en alta disponibilidad con balanceo de carga automático y aprovisionamiento de recursos dinámico.

Sobre el tamaño de las LUN & los Datastores en entornos VMware

Todo administrador de un entorno virtualizado (entendiendo que se entiende con ello, que dispone de almacenamiento consolidado), se plantea la disyuntiva del tamaño de las LUNs y el número de VMs que alojar en cada porción de disco.

Lo mas fácil es ir al extremo y definir una LUN “enorme”, de X terabytes en la que almacenaremos todas las máquinas virtuales.

Este sistema tiene una ventaja, y es que a menor cantidad de LUNs, menor cantidad de trabajo a gestionar tanto en cabina, como a nivel de masking, zoning y por último a nivel de Datastore* el administrador disminuye un área de gestión importante en todo centro de datos.

*Datastore:  De forma simplificada podemos decir que es la nomenclatura utulizada por VMware para designar a cada una de las LUNs visibles, si bien esto tiene ciertos matices que van más allá del objeto de este artículo).

Por contra, con este planteamiento, aparecen diversos problemas, unos menores, otros no tanto que se resuelven o minimizan con un tratamiento del almacenamiento diferente.

Vista de vCenter en el apartado de gestión de Datastores

Según algunos whitepapers de VMware, lo recomendable en general son LUNs de no más de 500 GB, si bien este dato dicho en frío tiene mucho de discutible.

Cuando VMware crea un sistema de archivos sobre cierta LUN, pasamos a denominar a esta como “Datastore” y es a partir de dicho momento en el que podemos hacer uso de la misma.

El sistema de archivos creado se denomina VMFS, y es un tipo de filesystem con capacidad de clustering, acceso múltiple y  concurrente por varias máquinas. Esto permite que en un solo datastore, residan, lean y escriban en un mismo momento varias máquinas virtuales y por tanto convivan de forma “pacífica”.

Lo que hay detrás, es que como consecuencia,  el sistema de archivos tiene que disponer de un sistema de bloqueos muy desarrollado adapado a dicho tipo de acceso y preparado para  un conjunto de máquinas con una fuerte carga de transacciones de disco que incluso puede poner en serios apuros al sistema de disco.

Es por ello que un solo datastore , con un gran número de máquinas virtuales conlleva un mayor número de bloqueos y operaciones concurrentes y por tanto en ciertos “micro-momentos” habrá VMs, a la espera de su tiempo de atención de disco y/o desbloqueo de cierta área del mismo.

Como consecuencia, el rendimiento del sistema de disco con las máquinas virtuales que corren sobre él, se ve decrementado y alguien empieza a pensar que la red SAN no es tan “galáctica” como aquel comercial se empeñaba en aseverar antes de su adquisición.

Otros pensarán que todo es culpa de la capa de virtualización y el modelo tradicional de “una máquina por servidor físico” es totalmente irremplazable.

Es por ello que también hay quien apunta una regla, de forma general, que dicta que en un datastore no se deben acumular más de 10 VMs (y con ello limitar hasta cierto punto el número de colisiones de disco por  área de almacenamiento).

¿Es entonces el tamaño del datastore o el número de VMs, lo que limita el rendimiento del sistema?, como el lector podrá suponer, ni todo es blanco…

Una mezcla de ambos componentes es lo que determina un correcto acceso a disco (prescindiendo en este pequeño examen, el tipo de almacenamiento, rendimientos, tipos de RAID y tecnología de disco, canal de acceso, caches de controladoras, y muchas otras variables a considerar en un proyecto real).

Podría pensarse que si utilizamos LUNs de menos de 500 GB y menos de 10 VMs por LUN, nos acercamos a un modelo simple de acción, pero creo que estamos de acuerdo si preciso que no aporta la misma carga, el servidor Oracle del ERP corporativo que un servidor de impresión, y por tanto será preciso medir las necesidades de acceso a disco de cada servidor y/o aplicación en cada caso para decidir el número de LUNS, las VMs que pueden ser vecinas de piso o aquellas que deben ser realojadas en lugares diferentes y mas “exclusivos” de nuestra red de almacenamiento.

Digamos que la norma a seguir pasa por no rebasar, siempre que sea factible, un 80% del rendimiento del sistema de disco por LUN, y asociar en cada una un conjunto de VMs que en su acceso total medio  no sobrepase un el límite de operaciones por segundo o requerimientos de MB/Seg por encima de la regla de negocio definida.

La contrapartida es cierta y es en la que estás pensando: Hay que crear, administrar y gestionar mas LUNs en el sistema, pero todo sea porque la aplicación de gestión de incidencias no aumente su carga con las  de tipo “esto me va lento…”

¿Que porcentaje a reservar para instantáneas en cabina?, ¿disminución de rendimiento asociada a asignación ligera de disco por VM? y ¿como repercute todo lo anterior en el sistema de backup?

Será obejeto de otro artículo , porque este acaba de terminar…;-)

VMware DPM+DRS…una característica “GREEN” de verdad

Hasta que no ha pasado un tiempo tras haber desplegado una solución, no se obtienen datos, cuantitativos, reales, sobre ciertos supuestos beneficios de la misma.

Uno de esos beneficios es la reducción de consumo eléctrico gracias a DPM.

DPM es una característica, ya  en modo “full support” en vSphere, por la que se monitoriza la carga (cantidad de VMs, requeirmientos de CPU, Memoria, Disco, Red…) del sistema y por ende, calcula el número de servidores necesario para soportarla y mantener las reglas de negocio marcadas. De ese modo en los tiempos de caga menores, VMware es capaz de apagar servidores completos e ir encendiéndolos conforme la carga aumenta y se requiere de sus servicios.

Es por ello, que muchas empresas en las que incluso se trabaja a tres turnos (24horas al día), el personal de oficina así como otras áreas nunca es el mismo durante el turno de noche. Por tanto la carga sobre el sistema se reduce al control de cadena, y ciertos servicios críticos.

En casos reales he podido comprobar una reducción de consumo eléctrico de  un 25%  al utilizar esta característica lo que casí por si solo es argumento para migrar a la nueva versión (en VI3 esta característica estaba en modo experimental y por tanto no fiable al 100%).

Cuando una VM se ejecuta sobre un servidor y VMware considera éste es el optimo para su apagado, el sistema DRS, por medio de vMotion cambia la ejecución de la/s máquina/s virtual/es a otro/s de los servidores (tras calcular cual será la nueva y óptima localización de la misma), y todo sin parada de servicio.

Los cálculos referentes a ROI & TCO se mejoran así frente al mismo despliegue de la misma plataforma sobre VI3.

Posiblemente lo primero que viene a la cabeza al leer este artículo, es que esto se cumplirá para entornos con decenas o centenas de servidores pero es posible comprobarlo sobre entornos con menos de 10 servidores físicos, lo que entra dentro del nuestro típico entorno SMB (PYME).

VMware Studio (facilitando la creación de virtual appliances)

Los Virtual Appliances han irrumpido en el entorno IT, con el mismo auge que la tecnología que los soporta (la virtualización).

La facilidad de importar una máquina virtual, con todo lo necesario (aplicaciones, bases de datos, medidas de seguridad,configuraciones específicas al efecto de cada elemento e incluso usuarios de prueba ya predefinidos en algunos casos)  ya preconfigurados y listos para funcionar, permite poner en marcha una máquina de pruebas en menos de 5 minutos con la solución a testear o utilizar.

Los grandes fabricantes de software, servicios así como algunas comunidades del entorno Open Source, ya hace tiempo que distribuyen virtual appliances a fin de distribuir y hacer mas sencilla la inclusión de los nuevos lanzamientos por parte de los departamentos TIC de sus posibles clientes.

Ahora con VMware Studio 2.0 (Aun en fase Beta),  la creación de estos elementos se facilita, automatiza al máximo y permite una menor pérdida de tiempo con respecto a la anterior versión.

Será el momento de que las pequeñas empresas de desarrollo apuesten por distribuir sus demos o aplicaciones con los mismos medios que los Top One de la industria del software?

Por lo menos es una posibilidad a considerar, para acercar mas facilmente sus productos a su mercado potencial.

VMware vSphere. En boca de todos

VMware ha liberado al mercado la última versión de su producto estrella, cambiando incluso de nombre (antes Virtual Infrasturcure 3), que promete muchas y amplias mejoras sobre todo en lo referente a sistemas cloud.