Repensando VDI - Parte III y final

Bueno… como vimos en los post anteriores, ya tenemos en la mano el diseño de una solución VDI para nuestro proyecto en particular. Ahora, antes de lanzarnos a hacer pedidos parémonos a reflexionar.

Para unos doscientos desktops disponemos encima de la mesa de tres servidores de alta gama, una SAN en la que hemos perdido un entretenido rato en diseñar nuestra SAN teniendo en cuenta aspectos como los IOPS.

Por otro lado, y como parte de un buen diseño, vemos que la granularidad en la escalabilidad de la solución se nos torna baja. Me explico… para 10 desktops más, hemos de adquirir un equipo similar, con un coste que os recuerdo roza los 14K.

Además, y desde el punto de vista de la gestión, hemos añadido la gestión de la SAN y del almacenamiento, lo que dependiendo del departamento de IT del cliente, supone una nueva carga de trabajo, que requerirá cierta monitorización y ajustes durante la vida del entorno.

Todo esto que resumo en unas cuantas líneas supone un nuevo sistema crítico en el entorno del cliente, con los mismos, si no mayores, requerimientos de gestión y monitorización que su entorno de servidores…. Y todo para un entorno, el de PCs, que no requiere, en un entorno de desktop físico, de tanto nivel de administración y conocimiento de las tecnologías implicadas.

Keep it simple

Quizá debamos revisar nuestra concepción de un entorno como el que nos ocupa. Empecemos por los servidores.

Es indiscutible, al menos bajo los parámetros tradicionales, que la densidad es el secreto del éxito en un entorno VDI. Es decir, cuántos más VM “metamos” en un servidor, mejor… ¿mejor?. Servidores más grandes son más caros, y ante el fallo de uno, el impacto es mayor: Enel ejemplo en el que estamos trabajando en el que hemos añadido un tercer servidor sólo por si acaso (recordemos que la pregunta no es si fallará, sino cuando lo hará). Este tercer servidor además nos permite asumir sin paradas las tareas de mantenimiento de la infraestructura, lo que sigue obligándonos a desconectar a cien usuarios de uno de ellos para que se conecten a otro. Así mismo, y tal y como recordamos antes, la granularidad es baja: Ampliamos nuestra infraestructura por mor a la uniformidad de entornos de 100 en 100 desktops.

Por otro lado, el almacenamiento. Según nuestros cálculos, necesitamos al menos 15 discos para satisfacer el hambre de IOPS de nuestra instalación. Nos vemos dimensionando una SAN de un coste respetable (discos de 15K, multipath, etc) únicamente por las necesidades de IOPS….

Servidores: Enanos vs Gigantes

Si incrementamos el número de nodos, disminuyendo a la par la especialización del hardware (nada de memoria ECC, SATA en lugar de SAS, Placas base de desktop con procesadores de alto rendimiento) observamos  que,  a igual número de cores y memoria, la factura baja sustancialmente… más que nada en lo referente a la redundancia. Si sustituimos cada nodo de los antes descritos por 4 0 5 Core I7 980/990 con 24 Gb de RAM, el importe de la factura en lo referente a servidores descenderá bastante, manteniendo (e incluso decrementando) el número de desktops por core. El coste de la redundancia (ese servidor extra) también se reduce (ya que la configuración propuesta cuesta posiblemente entre tres y cinco veces menos).

Almacenamiento: Divide y vencerás.

Respecto al almacenamiento…. Olvidémonos de la SAN. Discos locales SSD de hasta un Tb en / si queremos, configuración RAID. Hoy en día un disco SSD de 500 Gb (que nos va a dar más IOPS que TODA una SAN tradicional)  de 500 MB/sec de lectura/escritura, ronda los 1200€… más que suficiente para un entorno de 20-30 desktops por servidor.  Discos algo más modestos del orden de 300 Gb con ratios de 270/205 MB/s de lectura y escritura rondan los 50 0€.

Un equipo de estas características (dependiendo de si ponemos o no el disco SSD en RAID) puede oscilar entre los 2000 y 3000€. Si volvemos  al coste de los servidores propuestos (13K por servidor x 3), vemos que con el mismo presupuesto (39000€), podremos adquirir  entre  13 y 19 de estos equipos, suministrando entre 78 cores/ 312 Gb de RAM y 114 cores con 459 Gb de RAM comparados con los 72 Cores y 288 Gb de RAM de la solución inicial. En lo referente al almacenamiento,  la solución SSD provee entre 3000 y 6000 IOPS por microservidor frente a 3500-4000 para toda la infraestructura del ejemplo inicial.

¡Almacenamiento local! ¿Vade retro?

No tiene porqué. Hay cierta tendencia a reevaluar el valor del almacenamiento local, sobre todo con SSD, en entornos VDI. Citrix ya plantea usar los discos locales de los servidores como caché para eliminar accesos a la SAN/NAS (Intellicache), y otras tecnologías más disruptivas como nutanix ya hablan directamente de sustituir a la SAN/NAS como almacenamiento de runtime de entornos de virtual desktops.

Caso aparte es el de Kaviza, recientemente adquirida por Citrix, que con su concepto de Grid elimina la necesidad de almacenamiento compartido.

Brokers.

Xendesktop.

Mediante el uso de Intellicaché, nos podemos plantear el uso de un servidor NFS que almacene las gold copy para que posteriormente Intellicache las despliegue en los SSD locales: Cualquier NAS tipo IOMEGA Storcenter, TheCus o similar, que nos suministran NFS a costes inferiores a los 1200€ resulta suficiente. También Windows 2008 nos ofrece un servidor NFS de alto rendimiento, con el añadido de que esta misma máquina puede usarse para los perfiles de los usuarios.

Kaviza.

Kaviza parte de la premisa de que no existe almacenamiento compartido, aunque puede usarse. El controlador de Kaviza se instala en cada uno de los equipos como una máquina virtual, se agrupan entre ellos en un grid, y hagas lo que hagas en uno de ellos, se replica al grid sin configuración adicional. Así mismo el grid se encarga de proveer de tolerancia a fallos, redirigiendo al usuario de un nodo al otro en caso de caída del primero. Esta característica nos permite reducir el número de microservers, al no ser necesarios más de uno o dos para proveer de tolerancia a fallos al entorno. Así mismo, el grid se encarga de replicar las gold images entre todos sus miembros sin necesidad de configuración extra.

Otra ventaja de kaviza es el hecho de no requerir plataforma de gestión de hypervisor (vCenter o similar) ya que habla directamente con cada hypervisor.

En el caso de kaviza, los microservers irían equipados con un disco adicional SATA para almacenar el appliance y las gold copys (no vamos a desperdiciar SSD en eso, ¿no?)

Ya hablaré sobre kaviza en mayor profundidas en futuros post.

El hypervisor.

Bueno, este entorno evidentemente eleva el número de licencias de los hipervisores, aunque en determinado caso, el de ESX, nos puede reducir la cuenta gracias al maravilloso licenciamiento que nos ha calzado VMware… básicamente porque cada host se mantiene en los límites de memoria de la edición más económica (que además no incluye nada que necesitemos, incluyendo vMotion o HA).

Foto final

Pues venga, dibujemos el entorno final:

A simple vista se percibe la sencillez del modelo. Es un modelo en una sola capa, y que escala añadiendo unidades adicionales a un coste limitado. Cada ampliación incrementa los IOPS globales del sistema con una granularidad elevada (15-25 desktops), y a un coste totalmente mantenible. Eliminamos la SAN y la red FC de la ecuación, creando un entorno simple de gestionar, y dependiendo del broker elegido, puede ser mantenido por personal no experto en entornos virtuales.

Evolución del modelo.

Sobre este modelo se me ocurre que, al ser la unidad de crecimiento tan económica.... ¿porqué no plantearnos un entorno distribuído?

No hace demasiado demostraba a alguien que en un entorno VDI el movimiento de datos entre el puesto local (ficheros, corta y pega, etc) puede suponer un gran impacto en la infraestructura de acceso a los VDI. Su uno de nuestros usuarios decide subir desde su PC una imagen ISO de 2 Gb desde su disco local, el resto de los usuarios lo van a sufrir a menos que establezcamos mecanismos de control de ancho de banda más o menos avanzados para impedirlo. En escenarios donde hay grandes grupos de usuarios que acceden a los VDI contra el centro de datos, el ancho de banda y los protocolos de display remoto deben ser exprimidos al máximo para facilitar una experiencia de usuario cercana a la que está habituado. Mientras nadie se plantea localizar servidores de gama alta en oficinas de 20-30 usuarios, este entorno (especialmente  con los brokers nombrados), nos permiten desplegar "caches" locales a costes razonables, eliminando la necesidad de dispositivos de control de ancho de banda y mejorando la experiencia del usuario al acceder a los desktops a velocidad LAN.

Este tipo de arquitecturas no debieran de sorprendernos... sin ir más lejos ya hace mucho que los accesos a internet utilizan proxyes o las centralitas IP cuelgan de una central.

Conclusión.

Alguien que conozco siempre me dice que hay más de una manera de coger un pájaro, y no deberíamos olvidar que la tecnología no debiera estar limitada a los pdf de los fabricantes. ¡Nos pagan para pensar!