Montando un escenario de Virtualización del Escritorio: Granjas de Remote Desktop Session Hosts

Posts anteriores:

Hola

Continuando con esta serie dedicada a las diferentes tecnologías de Virtualización del Escritorio, hoy vamos a tratar acerca de cómo montar una granja de Remote Desktop Session Hosts (es decir, Terminal Servers). Estas granjas nos van a permitir acceder a aplicaciones de dos maneras distintas:

  • RemoteApp: Lo que se nos presenta localmente es únicamente la aplicación que se está ejecutando remotamente en la sesión de usuario que arrancamos de manera transparente para nosotros en el servidor, y que aparecerá integrada con nuestra barra de tareas y escritorio del dispositivo de acceso.
  • Un escritorio completo donde correrán las aplicaciones, y que tendrá la apariencia que queramos darle:
    • La de un servidor con 2008 o 2008 R2
    • La de un Windows Vista (2008 con la “feature” Desktop Experience habilitada y los temas adecuados corriendo)
    • La de Un Windows 7 (2008 R2 con la “feature” Desktop Experience habilitada y los temas adecuados corriendo)

Como ya hemos dicho en post anteriores, las aplicaciones en el Remote Desktop Session Host pueden estar a su vez virtualizadas con App-V, lo que nos permitirá servir incluso diferentes versiones de la misma aplicación usando el mismo conjunto de servidores.

Antes de dar detalles acerca de la configuración, vamos a ver cómo es el proceso de conexión ya que es sensiblemente diferente al que se usar para conectar usuarios con máquinas virtuales. Recordemos que el actual Remote Desktop Connection Broker que utilizan los pools de VDI es una evolución del que se ha venido utilizando para distribuir las sesiones de usuario entre servidores de Terminal Server desde hace años, por lo que de hecho es este role el que nos ofrece una solución unificada de acceso a escritorios virtualizados, bien por sesiones, bien por VDI.

Proceso de conexión a una granja de Remote Desktop Session Hosts

  1. Se resuelve el nombre de la granja
  2. Existen dos métodos de balancear las conexiones entrantes entre los servidores que conforman la granja. Round Robin DNS y NLB (o balanceador hardware)
  3. Una vez el sistema de balaceo redirige al cliente a uno de los servidores, este contacta con el broker para consultar si algún servidor de la granja ya está atendiendo al usuario. Si la respuesta es positiva es redirigido al servidor correspondiente. Si no, puede ser atendido o redirigido en función de otros parámetros, como el peso que el administrador haya dado a cada host dentro de la granja
  4. El cliente realiza la conexión del usuario contra el servidor adecuado.

Configuración del método de balanceo

No voy a incidir en el proceso de instalación del Sistema operativo ni del role de Remote Desktop Sessión Host, ni tampoco sobre el proceso de instalación de las aplicaciones. Sobre este punto, el único matiz que hay que tener en cuenta a la hora de usar App-V en estos entornos es que, al ser Windows Server 2008 R2 única y exclusivamente de 64-bit, necesitamos el cliente de App-V 4.6, actualmente en fase Beta. El resto es tal y como se describía en Montando un escenario de Virtualización del Escritorio: El Cliente de App-V

Lo primero que hay que tener claro es qué método vamos a utilizar para balancear la carga de trabajo entrante a la granja. Como decía antes contamos con dos métodos software, además de los consabidos balanceadores hardware que quedan fuera del ámbito de este post:

  • Round Robin DNS: Se basa en la capacidad que tiene el DNS de respondernos cada vez una IP distinta, de las muchas que podemos tener asignadas a un mismo nombre de host (registros AAA). Lo cierto es que el método no tiene demasiada inteligencia y tiene otro problema. Las cachés de sistemas DNS intermedios y cache DNS del propio cliente que realiza la petición. Dicha cache tiene por objetivo aprenderse la IP asociada a un FQDN y mantenerla ahí durante todo su TTL, por lo que cuando se nos ha respondido la IP de un cierto host de la granja, la siguiente conexión va directa a la misma IP sin pasar por el DNS. Por el contrario, es muy fácil de implementar. Estas dos entradas del DNS asocial la granja RDSHFarm.dominio.com a las IPs de cada uno de los dos servidores de la granja.

image

  • Network Load Balancing: Es un algoritmo que se encarga de repartir las conexiones TCP y/o UDP entre todos los nodos que participen del cluster. Durante el proceso que se conoce como “convergencia” de los hosts, estos se “ponen de acuerdo” de manera que al aplicar el mismo criterio a un paquete entrante, son capaces de discernir si lo tienen que aceptar o no en función de parámetros como IPs y puertos de origen y destino, entre otros. El concepto de afinidad se utiliza para servicios en los que múltiples conexiones provenientes de un mismo cliente (single) o subred (network) deben ir a parar siempre al mismo servidor, para poder mantener por ejemplo una sesión o una transacción. El caso más típico de esto es navegar por una aplicación web sencilla.

En el caso de los Remote Desktop Services, utilizar estas afinidades constituyen un sistema de brokering extremadamente simple, que no se aprovecha de capacidades de reparto de la carga pero que puede cumplir las veces. Sin embargo, cuando estamos usando el Remote Desktop Connection Broker, debemos usar la afinidad a “none”, de modo que cada conexión pueda ser tratada y redirigida.

En este artículo de TechNet se explica como usar NLB para balancear las conexiones entrantes a una granja de terminales con una única NIC por host, usando un modelo de unicast:

Aunque lo anterior es suficiente, aquí vamos a utilizar dos NICs por servidor, donde dedicaremos una para gestión y uso propio del host, y otra exclusivamente para aceptar las conexiones RDP remotas de los clientes. En esta segunda NIC de cada hosts simplemente enlazaremos TCPIP, donde pondremos la IP dedicada que le corresponda a cada uno. Necesitaremos una IP adicional para el cluster, que tendremos que registrar en el DNS.

CONSIDERACIONES:

  • Si los servidores están virtualizados, hay que acordarse de marcar la casilla “Enable MAC Spoofing” en las propiedades de esta tarjeta. NLB sobreescribe o agrega direcciones MAC a las tarjetas de red, y en el caso de las tarjetas virtuales debemos permitir explícitamente que esto suceda.
  • Si se juega a cambiar de un modelo a otro de balanceo y se utiliza el mismo nombre de granja, hay que recordar limpiar las caches DNS del broker y clientes involucrados con ipconfig /flushdns, además de, lógicamente, agregar/borrar/cambiar las entradas en el DNS.

Veamos el proceso para crear el cluster:

  • Agregamos el primer host del cluster en la consola de NLB, seleccionamos la NIC que vamos a dedicar a NLB y respetamos su IP dedicada

image image

  • Ponemos la IP del cluster y el nombre de la granja, que tendremos que registrar en el DNS. En este caso elegimos unicast (la MAC asociada a la IP del cluster sobreescribe la MAC de la NIC)

 image image

  • Elegimos las reglas de balanceo. En este caso es única, para el puerto TCP 3398, con afinidad a “none”

image

  • Agregamos el segundo host, elegimos la misma NIC, también respetamos la IP dedicada y respetamos la regla que hemos creado en el punto anterior

 image image image

Tras haber seguido alguno de estos dos métodos, un telnet al puerto 3389 contra el nombre de la granja debe funcionar.

Configuración de los Remote Desktop Session Hosts (ver http://technet.microsoft.com/en-us/library/cc771383.aspx)

Todos los hosts de la granja deben ser informados de cual es el nombre de la granja a la que pertenecen y que bróker es quien s encarga de gestionar la granja. Esto se especifica en la consola de la configuración del Remote Desktop Session Host de cada uno de ellos (Herramientas Administrativas)

image image

Como se puede observar, es en este único sitio donde decimos que el host es miembro de una granja, el nombre de la misma y cual es su broker. En este caso estamos usando redirecciones basadas en direcciones IP (ver http://technet.microsoft.com/en-us/library/cc732852.aspx), y al estar usando dos NICs utilizaremos para las reconexiones la IP dedicada de la NIC enlazada a NLB.

Lógicamente, todos los Remote Desktop Session Hosts deben estar configurados de forma idéntica, tener instalado (o virtualizado con App-V)el mismo software y estar publicando las mismas aplicaciones si es así como las queremos consumir. Esto último podemos garantizarlo trabajando sobre uno de ellos y exportando la configuración a los demás:

 imageimage

Configuración del Connection Broker (ver http://technet.microsoft.com/en-us/library/cc753630.aspx)

En el connection broker tendremos simplemente que agregar los Remote Desktop Session Hosts de la granja al grupo local “Session Broker Computers”:

imageSi además queremos que un Remote Desktop Web sea capaz de publicar las aplicaciones servidas por los servidores de la granja a través de este broker, solo tenemos que agregarla como una fuente de RemoteApps en la consola de configuración:

image

Una vez llegados a este punto, deberíamos tener una granja de servidores de sesiones de usuario funcionando a pleno rendimiento.

Saludos

David Cervigón