In het geval van een ‘High Availability‘ omgeving voor ‘Remote Desktop Services’ is het mogelijk om de beschikbaarheid van de gehele service te vergroten door een aantal load-balanced services op te nemen. Denk hierbij aan het dubbel uitvoeren van RD-Gateways en RD-Web Acccess servers, failover clusters voor RD Session Hosts en RD Virtualization Hosts…Zaken om rekening mee te houden is de sessie die opgezet wordt door de client en die daarna tijdens de sessie naar dezelfde back-end servers blijven verwijzen. In de HA-configuratie noemen we dat ‘persistence‘  connections. Onderstaande tabel geeft aan naar welke RDS servers een persistence connectie noodzakelijk is:

• Virtualization Hosts
• Session Hosts
• Gateways
• Web Access Servers

Eigenlijk is alleen de Connection Broker niet persistence ingesteld aangezien de data opgeslagen wordt in een SQL database en de Connection Broker alleen maar als doorgeefluik fungeert.

Dit geeft dan ook de persistence mogelijkheid weer,

Connection Broker Persistence

Hiermee wordt via ‘Routing Token Redirection Mode‘ de verbinding (opnieuw) ingesteld m.b.v. een token. Een load-balanced ‘Connection Broker’ zoekt de (reeds bestaande) client-sessie gegevens uit de SQL database en het (bijbehorende) IP adres van de ‘Session Host’ wordt via de ‘Connection Broker’ teruggegeven aan de client. De client wordt nu rechtstreeks naar de juiste ‘Session Host’ geleid via het verkregen IP adres van de ‘Session Host’.

Op dezelfde manier wordt de verbinding opgezet bij het gebruik van een ‘Virtualization Host’ i.p.v. een ‘Session Host’.

Client Source IP Address Persistence

Deze methode wordt gebruikt in o.a. LAN omgevingen waar elke client’s IP adres uniek is. In een Internet client omgeving kan dit niet gegarandeerd worden. (gebruikers van hetzelfde externe bedrijf via NAT hebben hetzelfde externe adres) Zonder ‘Connection Broker’ wordt door de load-balancer vanuit een ‘client persistence tabel’ de client doorgestuurd naar één van de Session Hosts.

Op dezelfde manier wordt de verbinding opgezet bij het gebruik van een ‘Virtualization Host’ i.p.v. een ‘Session Host’.

RDP Cookie Persistence

Hierbij wordt een cookie gebruikt tijdens een Remote Desktop connectie (mstsc). Deze RDP Cookie (mstshash) wordt, afhankelijk van de configuraties, niet altijd verzonden en is dus niet betrouwbaar.

Populaire ‘Load Balancer’ die veel gebruikt worden zijn o.a. KEMP en F5 en zoals de naam al aangeeft worden deze gebruikt om de load te verdelen tussen de clients en de RD Gateways en/of RD Web Access Servers.

Load Balanced Gateways

De client zal via de load-balancer verwezen worden naar één van de RD Gateways die het verzoek doorzet, via de HA-methode ‘DNS round-robin naam‘, naar de (load balanced) ‘Connection Broker’ die het op zijn beurt doorzet naar de ‘Session Host’ of ‘Virtualization Host’.

Load Balanced Web Access Servers

De client wordt door de load-balancer doorgestuurd naar één van de (load balanced) Web Access Servers. Tijdens de gehele sessie blijft de client verbonden met dezelfde ‘Web Access Server’ en is gebaseerd op het IP adres van de client.