Partager via

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

  • Article

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 https://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 https://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 https://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

Comments

  • Anonymous
    January 01, 2003
    The comment has been removed

  • Anonymous
    January 01, 2003
    Hola Si el usuario se desconecta su sesion se queda Idle. El broker le reconectará con ese servidor la siguiente vez que se conecte En estos entornos es una buena idea controlas por políticas cual es tiempo que permitimos tener vivas sesiones sin actividad y sesiones deconectadas. Es frecuente ver como el numero de sesions sube y sube (y la memoria y el uso de CPU) y ciando vamos a las sesiones nos encontramos con usuarios conectados que hace 10 dias que se fueron de vacaciones Saludos

  • Anonymous
    January 01, 2003
    Hola En cada hosts solamente es necesario agregar la funcionalidad de NLB, ni siquiera la consola. Ésta se puede utilizar desde un equipo totalmente ajeno a la granja o desde cualquiera de los hosts del cluster. Pero con crear el cluster y agregar los hosts desde un solo punto basta. Saludos

  • Anonymous
    January 01, 2003
    Hola Abre el programador de tareas, y navega a Microsoft/Windows/RemoteApp and Desktop Connections Ahi veras la tarea que hace la magia una vez al dia o cuando el usuario inicia sesión. Desafortunadamente no se puede controlar via GPOs Saludos

  • Anonymous
    December 03, 2009
    Fácil sencillo y para toda la familia. Como siempre un gran trabajo David, nos facilitas mucho las cosas. Gracias por el esfuerzo y sigue así ;-) Un saludo.

  • Anonymous
    December 08, 2009
    Hola David, gran post!! Una cosa, la consola de NLB se debe instalar en todos los host de terminal que van a formar la granja?? Hay que repetir los pasos que nombras (crear cluster y añadir host) en cada servidor de terminal services?? Gracias de antemano. Te paso mi mail: fran@zerkana.com

  • Anonymous
    December 14, 2009
    Hola de nuevo David, siguiendo tu magnifico post tenemos la granja funcionando. Quería realizarte una consulta: Con este tipo de solución (granja terminal con nlb) se garantiza que si un usuario tiene una sesión abierta contra uno de los host y este se "cae" cuando vuelva a lanzar la conexión y lo reciba el próximo host disponible va a seguir con su antigua sesión?? Ej: Si esta escribiendo en un archivo de word y se le cierra la sesión, cuando conecte al próximo servidor aparecera este archivo tal y como lo tenía en el caido. Lo pregunto porque he estado realizando las pruebas y aparece una sesión nueva, tengo la afinidad en "none" en nlb y el broker y host configurados perfectamente. Gracias de antemano.

  • Anonymous
    December 14, 2009
    Ok, muchas gracias por tu rápida respuesta y aclaración, es lo que pensaba. Igual he realizado mal la consulta; a ver ahora: Y si el usuario desconecta la sesion?? Vuelve a ser redirigido al mismo servidor donde se encontraban sus procesos?? Gracias

  • Anonymous
    January 22, 2010
    Hola David!! una consulta: Tengo win7 configurado para acceder desde el inicio a las aplicaciones publicadas en un rdweb, hay alguna manera de configurar la frecuencia de actualizacion de las aplicaciones agregadas a la web en el menu incio de win7?? Se que desde panel de control, en las propiedades de la conexion al rdweb se puede forzar con "actualizar lista de programas remoteapp". Cada cuanto tiempo suelen actualizarse?? Gracias de antemano Un saludo

  • Anonymous
    November 03, 2010
    Buenas David, gran documento. Tengo una consulta por si tu me podrias ayudar. Tenemos montado una granja de 3 servidores de escritorio remoto en windows 2008. Con uno de ellos siendo el agente de sesiones. Y utilizando el propio DNS del dominio para el balanceo. Cada uno de estos servidores tiene una IP privada en la red, y a traves del router realizamos un NAT a una IP publica distinta. Y el problema es el siguiente, dentro de la red local, todo funciona OK, el balanceo, el agente de sesiones, etc. Pero cuando se intenta acceder desde el exterior a traves de un NAT configurado en nuestro router, cuando el agente realiza la redireccion de un servidor a otro, el cliente no se puede conectar. ¿Sabes que podemos hacer para solucionar estos problema? Porque si realizamos el mismo montaje, pero utilizando el TS Gateway, el balanceo funciona perfectamente entrando a traves de la página web. Un saludo, y gracias.

  • Anonymous
    May 28, 2015
    Buenos Días,

    David me gustaría saber si me podrías hechar una mano con una implementan deseamos en la compañía clisterizar una aplicación que se llama GoalSystem que es aplicación Stand-Alone no ya estuve investigando sobre esta esta aplicación y no hay información sobre el balanceo de cargas o algo relacionado con la disponibilidad no se si desde la la parte de OS puede generar alguna tarea .job, algo me pueda ayudar a la realizar este balanceo de cargas para solucionar el tema de disponibilidad

    Correo: jhonnathan.alvarez@mectronics.co