¿Y ahora dónde estamos?
Con esto de lo virtual, muchas de las cosas que conocíamos han cambiado. Ni los servidores son lo que eran, ni parece que los desktop tampoco.
La virtualización del desktop, es decir, coger un sistema operativo cliente, instalarlo en una máquina virtual y usarlo como de un desktop físico se tratara tampoco es nada nuevo. Por allá por el 99, con las primeras betas de VMware Workstation unop ya hacía sus pinitos virtualizando un XP bajo RedHat linux para usarlo como entorno de pruebas de aplicaciones portadas de Linux a Windows (¡¡un sistema de control de un telescopio, ni más ni menos!!).
Componentes de una solución de desktop virtual.
Tomando la diferenciación que hice en el post anterior respecto a los "tipos" de Desktop Virtual que percibo, necesitaremos los siguientes ingredientes para "cocinar" nuestra infraestructura:
Hosted Virtual Desktop (Desktop Virtual Hospedado)
1. Licenciamiento "VDI aware" del Sistema operativo de desktop a usar.
2. Hardware de servidor con muchos cores y mucha memoria.
3. Hypervisor (más o menos gratuíto)
4. Plataforma de gestión de los desktop virtuales. (gestiona las copias maestras, asigna los accesos y provisiona los desktops. Más o menos caro, según fabricante)
5. Almacenamiento Enterprise (compartido o no. Gigabyte caro en comparación con el Gigabyte de un desktop)
6. Broker de conexiones (El elemento que permite conectar a nuestros usuarios con el desktop que le corresponde, y suministra el protocolo de presentación - del que hablaremos en la tercera parte de esta serie - y que se licencia de maneras variopintas)
Virtualización en el desktop Cliente - (Client Desktop Virtualization)
1. Hardware de cliente "VDI-aware". Esto, por el momento, nos obliga a adquirir equipos con tecnología que nos permita desplegar desplegar y gestionar ese desktop virtualizador. No se requiere únicamente la presencia de extensiones que faciliten la virtualización asistida por hardware. Como ejemplo, la respuesta de Intel se llama vPro ... la de AMD... Buena pregunta.
2. Licencia NO OEM del sistema operativo de desktop (sustancialmente más cara que la incorporada en el equipo. Entiendo, y algún pajarito así me lo confirma) que esto puede cambiar en breve.
3. Hypervisor de Cliente y/o Sistema operativo Host. Dependiendo de si el hypervisor de cliente es tipo 2 o tipo 1 (ver Hypervisores en Wikipedia), tendremos que adquirir (desde coste cero en el caso de Linux a algunos dólares en otros) una licencia de sistema operativo que nos permita ejecutar el hypervisor en nuestro desktop.
4. Plataforma de gestión. Sí, no nos escapamos de ella. Se ocupará de la gestión del hardware del desktop, del despliegue y gestión de las imágenes de desktop virtuales y de la gestión del hypervisor de cliente.
5. Almacenamiento. La posibilidad de concurrencia de tareas de I/O, ya sea por la actividad propia del hypervisor, la paralelización de la ejecución de las imágenes virtuales con otros procesos (despliegue de imágenes, seguridad embebida en el hypervisor, etc), requerirá de discos más rápidos (o más inteligentes) en los desktops, para evitar retrasos en el acceso a disco.
Como aspectos comunes, añadamos una licencia de antivirus (o dos, si el hypervisor es tipo 2), especialmente en entornos donde el sistema operativo virtualizado sea Windows.
A cambio de todo esto, y de su consecuente factura.. ¿qué obtenemos?
La virtualización ofrece al desktop una serie de ventajas sobre las soluciones aplicadas y descritas en la primera parte del artículo. Hagamos un breve repaso.
El sistema operativo cliente sigue siendo el mismo: Ventaja evidente. No es necesario adaptar al usuario a nuevos entornos (Citrix/Terminal Services sí requería que el usuario supiese un poco de qué iba el tema). Tampoco es necesario "mezclar" los tradicionales mundos de Sistemas (Un terminal server no es más que un Windows Server que hay que administrar como tal) con el de Desktop (Windows XP tiene su propia problemática, bastante diferenciada de la de los servidores), con lo cual, a priorí, tanto el cambio organizativo dentro del departamento IT como de la percepción subjetiva del usuario, es mínimo).
Hardware totalmente estándard en los desktop: El hardware virtual es homogéneo, lo que reduce los esfuerzos de maquetación y definición de "gold copies". No más toneladas de drivers, archivos de sysprep personalizados, u hora tras hora actualizando.
Despliegue rápido: Así mismo, la propia naturaleza de la máquina virtual (un fichero en disco), junto con las opciones de personalización del sistema opertativo (en el mundo Windows, sysprep, por ejemplo) simplifica in extremis el despliegue de nuevos desktops a velocidades y con una simplicidad sin precedentes.
Rendimiento: Los desktop virtuales, en cualquiera de sus variantes, suministran un rendimiento más que aceptable para las aplicaciones empresariales (negocio y/u ofimática).
Eliminación del desktop inteligente: En el modelo de Desktop hospedado (es decir, el que se ejecuta en un datacenter), el PC puede ser eliminado de la mesa del usario, substituyéndolo por un terminal (sí, tan terminal como una VT220), eliminado gran parte (no todos) de los costes asociados tradicionalmente al PC. También aporta su toque "verde" (Green/IT) al disminuir el consumo eléctrico y las emisiones de dióxido de carbono. En el aspecto presupuestario, aparte de que el terminal suele ser más económico que el PC (con "suele" quiero decir que hay muchos que lo son, pero otros que no), las reduciones de costes de mantenimiento, energía, junto con un alargamiento substancial de la vida del activo (no es necesario cambiar el terminal cada cuatro años, ya que lo que cambia es la máquina virtual) reduce los costos de almacenaje, reciclado y las provisiones por amortización.
No obstante, la propia naturaleza del entorno virtual hace que otros procesos y productos que deben instalarse en ese desktop virtual (para mantener la funcionalidad de ese desktop) creen nuevos problemas asociados a la "virtualidad" del entorno. Lo dicho, nuevas tecnologías, nuevos problemas. Reflejemos algunos.
Licenciamiento: Este es el primero y más evidente de los nuevos problemas. En un entorno físico, es bastante probable que el fabricante os incluyese la licencia de Windows en el PC que le compramos... en el virtual, y siguiendo los licenciamientos que Microsoft ofrece para entornos virtuales, ahora pasamos a pagar un derecho de uso anual que puede costarnos entre 23 y 110$ por año, dependiendo de nuestro acuerdo de licenciamiento con Microsoft (aquí un link explicatorio). A este coste hemos de añadir, ya sea nuestra infraestructura hospedada o no, el coste de la solución de virtualización (Hypervisor de cliente, Broker, etc), que puede llegar hasta los 130$ por virtual desktop. Así mismo, dada la "virtualidad" del desktop (ahora está y, voilá, ahora no está) el número de licencias a adquirir puede resultar difuso. Lo mismo se extiende a las aplicaciones y demás software.
Provisionamiento - Proceso administrativo: Vaya, hasta ahora, los departamentos de compras tenían "tiempo" para asimilar los costes y demás que implican un nuevo puesto de trabajo.... pero ¿ahora que los podemos crear en cuestión de segundos?. ¿Cómo resolvemos el papeleo de la adquisición y asignación de licencias, inclusión en inventario, etc.. ? Los modelos de licenciamiento deben adpatarse a la realidad de un entorno desktop cambiante y "on demand". Por otro lado, la imputación de coste del PC a la unidad de negocio también debe redefinirse. Si les convencimos para que apostaran por Virtual Desktop como solución a los problemas del desktop (no incluyo el económico, ya que está por ver que efectivamente esto sea más barato), debemos demostrárselo de alguna manera. (¿Pay per use, imputación de costes por consumos, etc?)
Provisionamiento - Procesos técnicos: Antes, si un usuario requería un PC para mañana, el usuario se "fastidiaba" y se esperaba las dos semanas de rigor para su adquisición, y el problema se solucionaba con aprox. unos 600€ (el coste, más o menos, de un desktop corporativo). En un entorno virtual, el añadir un desktop más a una infraestructura sobrecargada puede implicar varios miles de euros. El método de "compro cuando necesito" bastante habitual en sistemas no se adapta demasiado bien a este entorno cambiante. Las previsiones (y la adaptación a ellas) alcanzan en este entorno una importancia crucial. ASí mismo el hardware a usar para virtualizar desktops debe tener en cuenta estas premisas: Altamente escalable, Alta granularidad en el coste (es preferible crecer de 1000 en 100 euros que de 10000 en 10000), lo que hace a plataformas como los "big nodes" poco ideales para este entorno, haciendo de mis odiados blades una plataforma adaptable para esta "misión". En lo concerniente al almacenamiento, tecnologías cono SATA, Deduplicación y cloning se hacen fundamentales, tanto por coste como por funcionalidad. En lo que al Desktop Virtual Local se refiere, el transferir una imagen de unos cuantos gigas para actualizar la imagen local de la VM tampoco deja de ser un problema.
Seguridad vs Rendimiento: Evidentemente, un desktop conlleva un antivirus, pero... ¿evaluamos correctamente la carga de trabajo que supone un antivirus en una máquina virtual?. Si un escaneo programado de antivirus puede "bloquear" mi PC físico... ¿qué no hará en un virtual? Evidentemente, el efecto es distinto dependiendo de la tecnología que usemos. En un entorno hosted, un escaneo de antivirus en nuestros 300 desktops virtuales en simultáneo puede suponer una carga estresante para nuestra infraestructura, que puede afectar a la operatividad del usuario. En un virtual desktop local, la concurrencia de dos escaneos en dos máquinas virtuales (o el de una sola) puede afectar negativamente a la otra, y, consecuentemente, a la experiencia del usuario.
En un entorno de Virtual Desktop hospedado, una solución pasa por desplazar la seguridad del desktop al perímetro: Mantener aisladas las redes de desktops virtuales utilizando un UTM (Unified Threat Management) para garantizar la seguridad del desktop. Si a esto le añadimos la facilidad de despliegue del desktop en caso de infección (no desinfectas el desktop, lo re-creas), y salvando el aspecto de la identidad del usuario (de la que hablaremos en otro capítulo), es posible obtener un entorno más ligero y con un esquema centralizado (y perimetral) de seguridad.
En el Virtual Desktop Local, la cosa se complica, ya que desplazar la seguridad hacia el perímetro no siempre es la solución, y no siempre es implementable.
Inciativas como vSafe, de VMware (aunque desconozco si ya hay algún producto que haga uso de este API) prometen: Desplazar la seguridad hacia el hypervisor (que al fin y al cabo está incluso por debajo de los root kits) suena interesante. De esta manera podríamos "vacunar" a la infraestructura, y no a la VM. Esta podría ser la solución común tanto para los hosted virtual desktops como para los locales.
Interacción con el usuario: Por un lado, el uso de dispositivos de usuario (como un pen drive, un scaner o una impresora, un iPod/Pad o una blackberry) depende en gran manera de la capacidad de implementar USB sobre IP (en caso de los hosted) o de usar directamente mediante un arbitrador los puertos USB del host. Otros dispositivos, como puenden ser grabadoras de CD/DVD presentan algunos problemas, en especial en el caso de los hosted virtual desktops: el mapeo USB via IP puede inducir latencias que son normales en IP, pero no están soportadas en USB. Yo, en algún caso, ¡¡¡he tenido que utilizar iSCSI para solucionarlo!!!. Por suerte, hay productos y tecnologías en el mercado que, poco a poco, van solucionando esta problemática.
El problema de la identidad: Este punto podría dar lugar a un capítulo de esta serie en exclusiva, pero prometí que serían sólo tres, y la presentación será la temática del tercer y último de esta serie. Entendamos como identidad del usuario no sólo sus credenciales de acceso, sino al conjunto de configuraciones e información relacionada con él (su configuración de correo, su perfil de usuario, su carpeta "Home" o su fondo de pantalla). Mientras que en entornos Unix suele bastar con redireccionar la carpeta home del usuario a un servidor NFS, en el entorno Windows no es tan sencillo. Aunque existe la posibilidad de redirigir las carpetas de usuario a un servidor de ficheros, muchas aplicaciones requieren de DLL's o ejecutables que no se almacenan en el perfil del usuario, y que consecuentemente, no funcionan al cambiar de PC. Aquí es donde la virtualización de aplicaciones (yo prefiero llamarla containerización) resulta de ayuda. Conseguir que una aplicación se ejecute en lugar de instalarse, y que la configuración específica del usuario se almacene en una unidad de red abre inmensas posibilidades en entornos desktop sin persistencia. Otras soluciones pasan por implementar desktops no persistentes a nivel de sistema operativo pero sí a nivel de configuraciones de usuario (vease el modelo de VMware Composer), pero personalmente ya he pillado algún que otro fallo, y el proceso en sí me parece demasiado agresivo. Eso, evidentemente, aplica a los desktop virtuales hospedados.... ¿pero qué pasa con los locales?
Creo que pasa por soluciones tipo Microsoft Mesh o Dropbox, que ahora solucionan el problema a nivel de ficheros, pero aplicada a la identidad del usuario. Imaginemos un servicio que permitiera almacenar nuestras preferencias de aplicación y configuraciones específicas en la "nube"....
Pienso que el problema de la identidad debe solucionarlo el sistema operativo, no la plataforma de virtualización. Los SS.OO y las aplicaciones, deben enfrentar seriamente el concepto de identidad flotante, como concepto independiente del hardware (real o no) de la máquina donde se hospeden. Me atrevería a decir incluso que deberían tener en cuenta hasta la ausencia de inteligencia en la máquina, es decir, que nuestra identidad en Windows XP, por ejemplo, pudiese ser compartida por Office 2010 web edition.
Seguimos en unos días.
Un saludo.
No hay comentarios:
Publicar un comentario