miércoles, 28 de abril de 2010

VDI... ¿De qué estamos hablando? - Parte I

Efectivamente, esta es la pregunta. Cuando hablamos de Virtual Desktop Infrastructure... ¿de qué hablamos? Respondamos a esta pregunta al final del tercer post de esta serie.

Desde mi punto de vista, y acepto correcciones, aprecio, al menos, dos aproximaciones al concepto de desktop virtual.

La primera la denominaré, siguiendo la nomenclatura inglesa, Hosted Virtual Desktop. Entiendo por ello a un conjunto de máquinas virtuales que se ejecutan en un host más o menos central (Siempre es posible su distribución geográfica) a los que los usuarios acceden a través de un protocolo de presentación remoto (léase RDP, CTX, HDX, PCoIP, etc).

A la segunda, siguiendo el anglicismo más o menos extendido, la nominaremos Desktop Virtualization. Según mi entender, se basa en la ejecución del puesto cliente de un hypervisor de tipo 1 (es decir, sin sistema operativo más o menos funcional debajo) que permitirá la ejecución de una o varias máquinas virtuales en el desktop del usuario.

Por una de esas casualidades de este mundo en el que vivimos, ayer "conocí" a Guise Bule, un experto en esto de VDI con el que, durante unas horas, intercambiamos via email nuestras impresiones sobre la tecnología VDI, y he de reconocer que este artículo va dedicado a él. Reconozco sin ningún tipo de reparo que me ha hecho evaluar mis opiniones sobre el Desktop Virtual.

En este momento, el futuro del desktop del usuario está en evaluación. Tras dos o tres decenas en las que Microsoft consiguió arrancar la inteligencia del host para llevarlo a la mesa del usuario (cosa que le agradezco profundamente) nos vamos dando cuenta de que gran parte del esfuerzo que invertimos el personal de IT va dirigido al mantenimiento de un elemento ajeno a los sistemas centrales, pero que actúa como "puerta" entre el usuario y estos. Como ejemplo baste decir que da igual la maravillosa infraestructura Exchange que hayamos montado si el usuario no consigue que Windows arranque y le permita acceder a Outlook (o a Explorer, si usa webmail). Desde cierto punto de vista (más fílosófico que técnico), esto suena a franco retroceso: Potenciamos e invertimos en los servicios centrales para terminar dependiendo de algo que casi se ha convertido en un electrodoméstico: El PC.

No hace demasiado, soluciones del tipo Citrix o Terminal Server surgieron como alternativa al "poder" del PC del usuario: Mediante la instalación de un cliente de presentación remota conseguimos que el frontal al usuario de las aplicaciones se mantuviera en un entorno controlado, y convertimos al PC en un casi tonto terminal de un sistema central que el personal de IT cuidaba y administraba como el resto de los servidores. Tuve la suerte en esa época de participar en un par de proyectos bastante importantes relacionados con la implantación de este tipo de infraestructuras, y de vivir en primer plano la lucha constante que el personal de IT mantenía (antes de la implantación de Citrix) porque los PC funcionasen. Hablo de épocas de Windows 3.11 y Windows 95.

Descubrí en ese momento que la implantación de Citrix Metaframe simplemente diluía el problema en el caso de que el usuario usase un PC. Sólo desaparecía en el momento que al usuario se le instalaba un WinTerminal (alguno de mis lectores sabrá de qué hablo). Incluso en este último caso, y cumpliendo mi máxima de que las nuevas tecnologías sólo traen nuevos problemas, aparecía el problema de la gestión de los WinTerminals: Configuración de sesiones, actualizaciones, etc.

Aún asumiendo los inconvenientes de este tipo de solución, nos encontrábamos que la centralización de aplicaciones en un terminal server nos obligó a la creación de un nuevo rol. Hasta entonces, existía una clara diferencia entre el personal de sistemas (que administraba sistemas operativos y aplicaciones "core") y el de helpdesk (que implantaba y mantenía las aplicaciones "edge", es decir, las que usaba el usuario). A partir de la implementación de los terminal servers, fué necesario, o bien crear una nueva figura de "Administrador de aplicaciones de desktop en servidores", o traspasar a los administradores de sistemas la responsabilidad de hacer, por ejemplo, que Office se ejecutase sin problemas en un servidor de terminales. Aunque tuve la suerte de participar como consultor y no como implantador en esos proyectos, reconozco lo agonizante que puede resultar ver 30 o 40 instancias de Word, Excel o Access en el gestor de tareas de un servidor Windows. Por otro lado, no todas las aplicaciones funcionaban correctamente en una sesión Terminal Server... de hecho ni siquiera estaban diseñadas para ello (algunas versiones de Office, por ejemplo), y en algunos casos, el fallo de una instancia de una de las aplicaciones instaladas en el Terminal Server ocasionaba el colapso completo del servidor.

Como anécdota recuerdo que en una posición anterior en una gran compañía, recriminaba al responsable de implantación de aplicaciones en entorno Citrix (título oficinal del profesional en cuestión) que me diera tiempos de implantación de nuevas aplicaciones de un mes. Tras visitarle para invitarle al café de la negociación, me enseñó la granja Citrix, y las configuraciones especiales que tenía que aplicar a más de una aplicación y al sistema cada vez que añadía una. En ese momento le entendí.

En esos momentos no había otra opción, y más de un cliente reportaba una disminución de incidencias de hasta el 60%... número nada despreciable en un entorno, el desktop, que dejaba de estar bajo control en el mismo momento en que se lo instalabas al usuario.

En más de un caso recuerdo que el cliente decidió trasladar TODAS sus aplicaciones (ofimáticas y de negocio) a una granja Citrix, e instruyó a su proveedor de Desktops para que le maquetara los mismos con el cliente ICA instalado.... y una partición de recuperación accesible mediante clave... para que todos los problemas que tuviesen que resolver sus técnicos de campo se resolviesen remaquetando el PC.

Durante bastante tiempo, este tipo de soluciones cubrieron la demanda de un entorno de usuario estable y funcional.... hasta que recordamos que ese PC, por muy tonto que fuese, seguía ejecutando Windows. Y que era infectable por virus que ya no atacaban al PC a través de medios extraíbles, sino a través de la red. Recuerdo una infección de Blaster que paramos con reglas en el switch de nivel tres de la delegación en España de una multinacional... filtrando el tráfico que llegaba por la red corporativa. Hubo que volver a focalizarse en el PC del usuario.

Gestión del desktop.

Los inconvenientes de los servicios centralizados en un terminal server disuadieron a muchos clientes sobre su implementación. Al fin y al cabo, si la aplicación X falla o afecta al S.O., mejor que sólo bloquee el PC del usuario que el servidor donde acceden 30 o 40. Pero claro.... ¿Quién y cómo cuida el desktop?. Controlar el funcionamiento de los desktops, desplegar y actualizar antivirus, mantener inventario del parque y mantener actualizado y configurado el S.O. requería de nuevas aplicaciones: Gestores del Desktop.

Un gestor de desktop no es más que un servidor que recoje datos del parque de desktops. Previamente habrá sido necesario desplegar el agente del gestor, que no es más que, por un lado el chivato que indica al servidor el estado del mismo, y por otro, el ejecutor que instala con privilegios elevados los componentes o actualizaciones que el gestor de desktop considera oportunas. Si hablamos de antivirus centralizado, aplicamos el mismo procedimiento.

Puede darse, y de hecho me he encontrado algún caso, que el coste del S.O., el agente de gestión del desktop, la parte proporcional del Gestor de Desktops, el antivirus, la parte proporcional del gestor de antivirus centralizado, y el plataformado inicial de los PC's del usuario ronden entre el 80 y el 115% del coste del hardware. Nunca me he visto en la necesidad de justificar esto ante un CFO (Director Financiero), pero no debe ser una experiencia agradable.

Renovación tecnológica.

Aparte de la Ley de Moore (esa que dice que cada 18 meses la potencia de los ordenadores se duplica, y que tanto Intel como AMD se encargan de cumplir), las exigencias de los usuarios - que al fin y al cabo son las de negocio - obligan a "repasar" el parque de PC's cada 3 o 4 años. La aplicaicón de un Service Pack de Windows (véase caso del SP3) puede convertir un PC perfectamente operativo con 512 Mb de RAM en una tortuga antediluviana tras la actualización.... Y las release notes no decían nada al respecto. No culpo a los fabricantes, al fin y al cabo deben vender, y para ello deben mejorar su producto... lo que normalmente implica más recursos. No miremos sólo a Windows. Por poner un ejemplo, miremos la diferencia entre Ubuntu 8.04 y Ubuntu 9.10.

Por un lado, IT no puede esperar a la evaluación de un determinado Service Pack o Update, porque normalmente ciertas aplicaciones lo requieren. Por otro, la evaluación de impacto de una actualización no suele tener cabida en las tareas de mantenimiento, y pocas compañías disponen de departamentos especializados.

Conclusión.

Fácil. Una mañana nos despertamos y descubrimos que el 40 - 80% de los recursos humanos de IT se dedican al desktop.... y que un temible 60% del presupuesto de IT se lo "come" los tropecientos PC's de los usuarios.

Seguimos en el próximo episodio.

No hay comentarios: