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!
