Escritorios Virtuales en Windows Azure

  • Article

Hola

Durante los últimos años he estado involucrado en mayor o menor medida en diferentes proyectos dirigidos a ofrecer “escritorios en la nube” o plataformas de “Desktop as a Service”. Si bien aplicar un modelo de pago por uso es particularmente complicado en un entorno en el que hay que considerar cosas tan diversas como dispositivos de acceso, datos de usuario, aplicaciones varias, sistemas operativos, servidores, hypervisores, almacenamiento, redes, etc. y tan poco cuantificables como son operaciones y mantenimientos, todo esto ha chocado siempre con un pequeño pero importante matiz legal. Correr Windows Cliente, es decir, Windows XP/Vista/7/8/8.1 sobre una infraestructura compartida entre varios clientes es simplemente ilegal. Dicho de otra manera Windows Client (o la famosa VDA) no se puede adquirir a través de contratos SPLA (Service Provider License Agreement) que es lo mismo que decir que no se puede utilizar en un modelo de pago por uso. Nada impide que te montes una infraestructura de VDI en tu casa, nada impide que montes una infraestructura de VDI dedicada para un tercero, pero no puedes montar una infraestructura de VDI que vaya a ser compartida por diferentes clientes. Y esto obviamente afecta a cualquier Hoster/Service Provider/Cloud Provider, lo que incluye al propio Windows Azure.

Por otro lado, sabemos que existe una alternativa mucho más barata y escalable de ofrecer Escritorios Virtuales y/o Aplicaciones Remotas a usuarios que los vayan a consumir desde diferentes tipos de dispositivos que una despliegue de VDI. Los clásicos Terminal Services / Remote Dektop Services, que además mediante la característica de “Desktop Experience” pueden disfrazarse perfectamente como sus versiones equivalentes de Windows Client (es decir Windows Server 2008 R2 –> Windows 7, Windows Server 2012 –> Windows 8, y Windows Server 2012 R2 –> Windows 8.1). E incluso pueden usarse en un modelo muy similar a un pool de VDI, con un único usuario por escritorio. Esto es además curiosamente mas barato desde el punto de vista de licenciamiento, y por último es perfectamente legal en entornos de hosting compartido a través de las licencias de SPLA de Windows Server y de la CAL de Remote Desktop Services (RDS SAL).

Todo esto esta mucho mejor explicado aquí:

Por último, Microsoft anunció hace unas semanas coincidiendo con en lanzamiento de Windows Server 2012 R2 que las RDSCALs adquiridas a través de los diferentes contratos de volumen con Software Assurance otorgan derechos de uso de este tipo de escritorios no solamente en local sino también en la nube.

Tras estos antecedentes, se trata entonces de montar un escenario completo de escritorios virtuales basados en RDS/Windows Server directamente sobre los servicios de IaaS en Windows Azure. Básicamente la arquitectura no cambia mucho con respecto a cómo se haría en una infraestructura propia, con la salvedad de que nos despreocupamos del montaje de toda la plataforma de virtualización y nos aprovechamos de un modelo de facturación que puede llegar al pago por minuto de uso. Los escenarios de aplicación pueden llegar a ser extraordinariamente variados.

La solución está descrita aquí:

  • Con una solución 100% nativa Microsoft:

image 

  • Con Dell vWorkspace:

Sobre la viabilidad práctica de este tipo de arquitecturas para esta solución, los principales factores a tener en cuenta son que están orientadas sobre todo para el consumo de escritorios y/o aplicaciones a través de Internet, y por supuesto las dependencias que tengan las aplicaciones que vayan a correr aquí con los servicios de back-end. Aquí tendríamos dos escenarios, con una gran variedad de posibles puntos medios:

  • Solución “autocontenida”: Es decir, ya que nos embarcamos nos subimos el back-end también a la red virtual de Azure. Frontales, aplicaciones, ficheros, bases de datos funcionan independientemente con pocas o ninguna dependencia de los servicios on-premise.
  • Solución conectada mediante una VPN. En este caso, las aplicaciones corriendo en los escritorios virtuales se conectan con el back-en a través de una VPN que conecta la red virtual de Azure con on-premise. Obviamente esto será viable solamente si los requisitos de ancho de banda y latencias son los adecuados, y si el numero de usuarios que hacen uso de ellos de forma simultánea no es elevado. Y lógicamente esto permite que el usuario acceda a la granja de escritorios y aplicaciones desde la propia intranet, a través del túnel, lo cual quizás no tenga demasiado sentido.

Por tanto, y en resumen:

  • Ventajas:
    • Legal
    • Fácil de desplegar
    • Capacidad de despliegue en diferentes localizaciones geográficas dependiendo de la ubicación de los usuarios
    • Geo-tolerancia a fallos
    • Pago por minuto de los recursos
    • Independencia de las redes propias o anchos de banda
  • Inconvenientes:
    • Peor escalabilidad que una arquitectura equivalente on premise
    • Poco viable para aplicaciones con fuertes dependencias del back-end
    • Menor flexibilidad o restricciones en los modelos de despliegue
    • Posibles limitaciones legales o en la soportabilidad  de algunas aplicaciones

Saludos

David Cervigón