Repensando VDI - Parte II

En el post anterior de esta serie os proponía una reflexión sobre los despliegues VDI. En este, vamos a aplicar las ideas expuestas a un caso particular.

Escenario.

Hagamos números para un despliegue de VDI de unos 200 desktops con capacidad de tolerancia a fallos de al menos la mitad de la infraestructura. Tenemos tres gold images (copias maestras) de unos 40 Gb y pretendemos utilizar tecnología de linked clones para al menos el 80% (unos 160 desktops). El resto, son desktop completos.

Localizaciones.

El 100% de los usuarios accederán desde las 3 oficinas de la compañía, (aproximadamente, 60 usuarios por localización), aunque se estima que diez usuarios requerirán acceso más o menos constante desde localizaciones móviles. A corto plazo, se pretende extender el número de oficinas (entre 3 y 15 personas) en varios países europeos.

Aplicaciones.

Aparte de las ofimáticas (Microsoft Office y Open Office en algunos casos), hay que añadir el ERP corporativo, bases de datos Access para algunos departamentos, tres aplicaciones específicas del negocio basadas en web.

Otras actividades.

La navegación web y las descargas de ciertos documentos y archivos debe ser fluída, ya que gran parte de la actividad de la compañía se basa en el procesamiento de datos externos.

Experiencia de usuario.

En lo referente a la experiencia de usuario, nuestro entorno requerirá que al menos un 10% de nuestros usuarios dispongan de audio bidireccional para telefonía IP (disponemos, por ejemplo, de un Asterisk usando softphones), y al menos unos 15 usuarios requerirán de capacidades medias de manipulación de gráficos (composición de documentos ricos y/o manipulación de imágenes). La impresión (sí, señor, el eterno dolor de cabeza) se realiza en impresoras conectadas a servidores de impresión IP. El uso de dispositivos USB se limita a pen-drives y, opcionalmente, alguna cámara digital para la adquisición de fotografías previamente tomadas con estas. Se requiere de interacción entre determinados puestos locales y los desktops virtuales, al menos durante el primer año. Esta interacción se basa en el traspaso de datos entre la aplicación de un cliente y los empleados de la compañía desplazados al mismo.

Servidores.

Para ello utilizaremos tres host con las siguientes características

- 2 Procesadores de 12 cores

- 96 Gb de RAM

- 2 Fiber channel dual de 4 Gb

- RAID 1 x 3 discos de 73

El equipo seleccionado es un dell R715, equipado con dos Opteron 6180SE de 12 cores, doble fuente de alimentación.

Según el configurador de Dell (por poner un ejemplo), cada host nos cuesta unos 13.072€ (Calculemos un +- 15% entre descuentos y preferencias de configuración)

Con esta configuración, en la que minimizamos el número de host para evitar problemas con el licenciamiento, ya sea del hypervisor o plataforma de gestión, el coste de los host se eleva a 39.216€, lo que nos supone, aproximadamente, unos 196€ por desktop en lo referente a los servidores.

Almacenamiento.

Pasemos al almacenamiento. Una cabina de gama media-alta, con soporte FC y su correspondiente switch puede rondar los 30.000-40.000€ (dependiendo, claro, del fabricante).

Los IOPS (Input/Output Operations per Second)

Los IOPS (Input/Output Operations per Second) también serán determinantes a la hora de configurar el número de discos y los RAIDs correspondientes. Sumerjámonos en el siempre interesante mundo del almacenamiento.

Los discos.

Como referencia, tengamos en cuenta los IOPS medios de los discos actualmente en el mercado:

RPM	IOPS
SSD	4000-6000
15.000	170-180
10.000	110-130
7.200	70-78
5.400	45-50

Para los que nos gusta calcular estas cosas, si queremos tener una estimación de IOPS de nuestros discos, usaremos los siguientes parámetros para evaluar los IOPS de nuestros discos)

Velocidad de rotación: Número de revoluciones por minuto que dan los platos de los discos. Este parámetro está íntimamente relacionado con los otros dos que usaremos para el cálculo: Latencia Media y Tiempo medio de búsqueda.

Latencia media: Es el tiempo que tarda un sector del disco determinado en posicionarse bajo la cabeza de lectura/escritura del disco.

Tiempo medio de búsqueda: Es el tiempo medio que la cabeza tarda en posicionarse sobre un sector determinado para escribir o leer.

IOPS aproximados= Divide 1 por la suma de la latencia media del disco en milisegundos (aL) más el tiempo médio de búsqueda del disco también en miligegundos (aS)

IOPS=1/(aL+aS)

El gran Scott Lowe nos lo explica claramente en este post publicado en TechRepublic., Así mismo en el siguiente artículo en zdnet hay más datos interesantes sobre las RPM.

El RAID

Adicionalmente, hemos de contar con la posible penalización en escritura que el RAID de nuestra cabina nos imponga. Es importante tener claro que el RAID nos penalizará en escritura, mientras que puede (dependiendo del tipo de RAID) beneficiarnos en escritura. En un RAID0, por ejemplo, las operaciones de lectura se realizarán a la velocidad de uno de los discos de la SAN, ya que al estar los datos almacenados en un solo disco, estos nos serán devueltos a la velocidad del mismo. En un RAID 5, sin embargo, son todos los discos del RAID los que nos devuelven el dato, ya que este está dividido entre ellos).

A efectos de escritura, la siguiente tabla ilustra las distintas penalizaciones que, desde el punto de vista de la escritura, nos imponen los diferentes tipos de RAID.

Tipo de RAID	Penalización
RAID 0	0 (Una sola escritura en un disco)
RAID 1	2 (Dos escrituras en dos discos)
RAID 5	4 (lectura dato existente, lectura de paridad, escritura de nuevo dato, escritura de paridad)
RAID 6	6 (lectura de dato existente, lectura de paridad 1, lectura paridad 2, escritura de nuevo dato, escritura de paridad 1, escritura de paridad 2)
RAID 10	2 (igual que RAID 1)
RAID DP	2 (Escritura de dato, Escritura de paridad)

(Se admiten correcciones, opiniones y demás sobre el contenido de esta tabla)

Para más información: Niveles de RAID Estándar, Niveles de RAID no estándar según Wikipedia… recordad que cada fabricante puede “aliñar” los niveles de RAID para obtener un máximo rendimiento.

Para calcular el rendimiento de nuestra SAN el número de discos es crucial. No nos dará los mismos IOPS un volumen de 500Gb formado por 3 discos que por 6.

También el uso del disco es determinante. Me refiero al porcentaje de lecturas frente al de escrituras. No es lo mismo, a efectos de IOPS de la SAN, que el 80% del tiempo nos lo pasemos escribiendo y el 20% leyendo que al contrario (por aquello de las penalizaciones de escritura y beneficios de lectura)

Para no entrar en demasiadas controversias sobre las lecturas y escrituras que genera o no un Virtual Desktop (que dependerán, evidentemente, del diseño de la VM y del “opinador” en cuestión), estimemos un porcentaje de 80% de lecturas por un 20% de escrituras

Para calcularlo, usemos las siguientes fórmulas:

IOPS Brutos= Nº de discos(nD) * los IOPS de cada disco individual(iD)

IOPS Netos=((IOPS brutos * Porcentaje de escritura)/Penalización tipo RAID)+(IOPS Brutos * Porcentaje de lectura)

En base a estos datos, podemos definir una fórmula que nos indique cuántos discos necesitamos para calcular cuántos discos y en qué tipo de RAID hemos de montarlos para obtener un nivel de IOPS determinado.

Nº de discos=((IOPS * Porcentaje de lectura + (IOPS * Porcentaje de escritura * Penalización RAID)/IOPS individuales de cada disco)

Os dejo por aquí otro post que profundiza en los niveles de RAID.

Caches y otras hierbas…

Por si no fuese poco, a todo el lío que os he montado, añadid los caches, etc. Los fabricantes, conscientes de las limitaciones de las IOPS en entornos RAID, intentan minimizar el impacto de estas mediante el uso de Caches. Los que hayáis trabajado con RAID5 (con o sin SAN) estáis acostumbrados al concepto de cache, es decir, la controladora escribe en un caché de RAM alimentado por batería, difiriendo la escritura en el tiempo, de forma que podamos trabajar a velocidades RAM en lugar de a velocidades RAID. El problema es que la RAM se queda corta, así que no es extraño oir hablar de caches en flash, o directamente de un pool de discos SSD donde escribimos (por aquello del tamaño), y la SAN, posteriormente, mueve el contenido de los SSD/Flash a los RAID.´

El impacto de estos métodos en el rendimiento del RAID no son predecibles a priori, ya que dependerá de tamaño del caché, su tecnología y el método que use la SAN para mover los datos del caché a los discos. Vuestro comercial de almacenamiento seguro que dispone de un par de toneladas de PDFs que os lo aclararán.

A lo que íbamos.

Después de tamaño rollazo sobre el tema del almacenamiento (insisto y soy pesado con esto porque si en entornos de servidores es CRUCIAL para alcanzar altos ratios de consolidación, en VDI no os quiero contar), veamos como aplica esto a nuestro caso…

Estimando los requerimientos de IOPS entre 10 y 20 por Desktop (dependerá del sistema operativo, las aplicaciones, dónde se almacenen perfiles y datos y la arquitectura de la VM maestra – en negrita para destacar su importancia), nuestros 200 desktops requerirán de entre 2000 y 4000 IOPS, más incluso dependiendo de las operaciones de encendido, procesos de escaneo de antivirus y operaciones de despliegue masivo.

Si dimensionamos para la media, tendremos unas necesidades de entre 2000 IOPS y hasta 4000 si dimensionamos para el pico. Ahora es el momento de usar la formulita que os dejé para calcular cuántos discos necesitaríamos, me sale (ser admiten correcciones), que para dimensionar al pico (es decir, a 4000), necesito entre 18 y 36 discos de 15000 RPM y 178 IOPS. Una cantidad nada despreciable… Añadidle que los discos vayan en FC… ¿Porqué y no iSCSI? Si estimamos un rango de 10-20 IOPS por segundo en los desktops (más teórico que práctico) y descartamos el pico (lo que implica que en determinados momentos el I/O se habrá colapsado), tendremos que cada host puede generar constantemente unos 1000/2000 IOPS de media. Si el pico (arranque de VDIs, por ejemplo) se elevase al doble (unos 3000 IOPS) la latencia inherente a iSCSI (no olvidemos que sigue siendo IP, además de ser SCSI) puede resultar determinante. No obstante, y para que no se diga, en determinadas configuraciones iSCSI puede obtener rendimientos envidiables (véase 1,000,000 IOPS with iSCSI - That's Not a Typo...) También es verdad que una SAN de esas características no está al alcance de cualquiera…. Salvo que deseemos “montárnosla” por nuestra cuenta.. Ya sea con un servidor Windows Server y el Target iSCSI o con soluciones Open tipo Nexenta, Open-e o similares... opciones nada desdeñables y de las que escribiré otro día.

Bueno. Ya hemos acabado nuestro diseño, y salvo el coste de lo ya definido, ¿ya estamos listos para el despliegue? pues va a ser que la respuesta, en el próximo post.