Cómo configurar la alta disponibilidad para el agente de conexión RDS en Windows Server

Configurar un agente de conexión a Escritorio remoto (RDCB) con tolerancia a fallos puede parecer complicado, pero es bastante necesario si se toma en serio la disponibilidad. Especialmente si no quiere que un solo fallo del servidor deje fuera de servicio toda su granja de RDS. Esta guía explica cómo lograr una alta disponibilidad del agente de conexión a Escritorio remoto, rebotar la base de datos backend a SQL Server Always On y, en general, eliminar ese punto único de fallo. Porque, claro, Windows tiene que complicarlo más de lo necesario, así que prepárese para algunas configuraciones de SQL y la magia del DNS. La idea principal: instalar el RDCB en un par de servidores, conectarlos a una base de datos SQL compartida y mantener ambos en funcionamiento pase lo que pase. Se requiere un poco de paciencia y algo de trabajo con la línea de comandos, pero al final, vale la pena no perder usuarios cuando un servidor falla.

Cómo solucionar el punto único de falla de RDCB con configuración de alta disponibilidad

Preparación de la infraestructura para el agente de conexión a Escritorio remoto

• Asegúrese de que cada servidor con el rol RDCB tenga una IP estática y esté conectado a su dominio de AD. Por ejemplo:
  • srv-rds1.woshub.com— 192.168.13.20
  • srv-rds2.woshub.com— 192.168.13.21
• Se recomienda crear un grupo de seguridad de AD dedicado llamado MUN_RD_Connection_Brokers. Puede hacerlo mediante PowerShell:

  New-ADGroup "MUN_RD_Connection_Brokers" -path 'OU=Groups, OU=Berlin, DC=woshub, DC=com' -GroupScope Global -PassThru -Verbose

• Agregue sus servidores RDCB a ese grupo:

  Add-AdGroupMember -Identity "MUN_RD_Connection_Brokers" -Members srv-rds1$, srv-rds2$

Cree registros DNS A para el nombre de su granja con balanceo de carga, por ejemplo, MUNRDCB.woshub.com, que apunten a ambos servidores. Esto garantiza el funcionamiento del DNS round-robin. Puede hacerlo mediante PowerShell:

Add-DnsServerResourceRecordA -Name MUNRDCB -IPv4Address 192.168.13.20 -ZoneName woshub.com Add-DnsServerResourceRecordA -Name MUNRDCB -IPv4Address 192.168.13.21 -ZoneName woshub.com

No olvides asignar direcciones IP estáticas y configurar esos registros DNS; de lo contrario, el equilibrio de carga se vuelve inestable rápidamente.

En cuanto a SQL, instale SQL Server Native Client en todos los servidores que alojan el rol RDCB, ya que es necesario para la conectividad. Consígalo del sitio web de Microsoft o copie el MSI si no le convence (consulte la ruta: D:\1033_ENU_LP\x64\Setup\sqlncli.msi).

Abra SQL Server Management Studio y conéctese a su SQL Server. Deberá crear una base de datos dedicada para RDCB, llamada algo como RDCB_DB. A continuación, asigne los permisos correspondientes:

• Vaya a Seguridad > Inicios de sesión en SSMS. Agregue el grupo de dominio MUN_RD_Connection_Brokers.
• Otorgue a este grupo los roles de dbcreator y sysadmin (acceso temporal para la configuración inicial, pero en realidad, restrinja esto más adelante como un jefe).

Asegúrese de abrir el puerto TCP 1433 (puerto SQL predeterminado) en el Firewall de Windows Defender en esos servidores, por si acaso.

Instalación de roles RDS en Windows Server

• Inicie el Administrador del servidor, vaya a Administrar > Agregar roles y características. Seleccione Instalación de Servicios de Escritorio Remoto.
• Seleccione la implementación estándar con la implementación de escritorio basada en sesiones. A continuación, seleccione un servidor para alojar la función RDCB. No instale el segundo todavía.
• Instale otras funciones necesarias, como Acceso web a Escritorio remoto, en el mismo servidor y Host de sesión de Escritorio remoto en *ambos* servidores involucrados.
• Al finalizar, agregue los hosts RDCB al grupo de servidores de administración de RDS localmente en cada servidor. Esto suele estar en Servicios de Escritorio Remoto > Servidores.
• Nota importante: Durante la instalación del rol RDCB del primer servidor, se crea una rdcbDbbase de datos local (como C:\Windows\rdcbDb\rdcms.mdf).Esto es prácticamente inútil en alta disponibilidad, ya que otros servidores no pueden acceder a ella. Por lo tanto, es recomendable migrar esta base de datos a SQL más adelante.

Creación del clúster RDCB con alta disponibilidad

• Antes de agregar el segundo host RDCB, migre la base de datos local a su servidor SQL compartido. En el Administrador del servidor, vaya a Servicios de Escritorio remoto > Descripción general. Abra el asistente para configurar alta disponibilidad mediante el icono de su primer servidor RDCB.
• Seleccione Servidor de Base de Datos Dedicado. Ingrese el nombre DNS de la granja, como MUNRDCB.woshub.com. Luego, proporcione la cadena de conexión, que se ve así:

  DRIVER=SQL Server Native Client 11.0;SERVER=srv-rds2.woshub.com;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB

• Después de la configuración, verifique en SQL Management Studio que la base de datos RDCB_DB exista y que el inicio de sesión de SQL tenga los derechos adecuados (normalmente db_ownery public).
• Agregue ambos servidores RDCB a la granja mediante el asistente (verá las opciones » Agregar servidor de agente de conexión a Escritorio remoto» ).El objetivo: que ambos tengan la misma configuración de alta disponibilidad, con uno como secundario en caso de que el primero falle. Listo. Una vez habilitada la alta disponibilidad, no hay vuelta atrás, así que revise bien todos los ajustes.

Configuración de conmutación por error de SQL Server: el corazón de la alta disponibilidad

• Ahora, en serio, configure su SQL Server en un Clúster de Conmutación por Error o, más moderno, en un Grupo de Disponibilidad AlwaysOn. Instale el rol de Clúster de Conmutación por Error, cree el clúster y habilite los Grupos de Disponibilidad AlwaysOn en el Administrador de Configuración de SQL Server.
• Ejecute el asistente para crear un nuevo grupo de disponibilidad, incluir la base de datos RDCB_DB y configurarla para conmutación por error automática. Asegúrese de que su receptor tenga un nombre DNS (p.ej., SQL-RDSDB-liste ) para que su RDCB pueda conectarse a una IP virtual en caso de conmutación por error.
• Actualice su cadena de conexión con PowerShell para apuntar la granja RDCB a este receptor:

  Set-RDDatabaseConnectionString -ConnectionBroker srv-rds1.woshub.com -DatabaseConnectionString "DRIVER=SQL Server Native Client 11.0;SERVER=SQL-RDSDB-liste;Trusted_Connection=Yes;APP=Remote Desktop Services Connection Broker;DATABASE=RDCB_DB"

Nota: Esta configuración no es sencilla, y la resolución de problemas de conmutación por error de SQL requiere paciencia. Asegúrese de que los escuchas y el clúster funcionen correctamente antes de continuar.

Una vez configurado, pruebe la configuración apagando un servidor RDCB o forzando una conmutación por error de SQL para comprobar si la granja sigue funcionando correctamente. Esa es la magia de la alta disponibilidad.

Ahora, después de todo esto, puede continuar con la implementación del resto de su entorno RDS: servidores de licencias, RDSH, publicación de RemoteApps y todo lo demás. La clave es asegurarse de que su RDCB siga atendiendo conexiones, incluso si un nodo falla.

Resumen

• Utilice direcciones IP estáticas y DNS round-robin para la distribución de la carga.
• Cree una base de datos SQL dedicada con los permisos adecuados para RDCB.
• Instale los roles de RDS y luego migre la base de datos RDCB a SQL.
• Configure la alta disponibilidad en SQL con Always On o agrupación en clústeres.
• Agregue servidores a la granja RDS con alta disponibilidad habilitada.

Resumen

Conseguir alta disponibilidad de RDCB no es sencillo, pero vale la pena si el tiempo de actividad es importante. Una vez configurado y probado todo, restaurar el servicio tras un fallo es mucho más fácil, sin necesidad de ajustes manuales. Estos pasos hacen que toda la granja sea resiliente, algo crucial cuando los usuarios dependen de escritorios remotos a diario. Ojalá esto ayude a reducir los problemas de inactividad; funcionó bastante bien en un par de configuraciones.