Once deployed, Microsoft's Remote Desktop Services (RDS) becomes a critical part of a customer's infrastructure, particularly the apps and resources that are shared with users.
If the RDS deployment is configured with only a single Remote Desktop (RD) Broker and this broker goes down for any reason (i.e. VM or network failure), users can't access those apps and resources, and your business is negatively impacted.
To prevent this from happening, many itopia CAS customers chose to deploy a High Availability (HA) RD (Remote Desktop) Connection Broker configuration.
High-Availability RD Connection Broker Configuration
In order to support high-availability (HA) configurations, the RDS deployment must have two RD Connection Brokers. The RD Connection Broker role then uses a Microsoft SQL server to coordinate session information amongst Broker servers.
Fully-Resilient RD Connection Broker Configuration
For a fully-resilient implementation, the SQL Server instance should also be configured for fault-tolerance, using either SQL Always On Availability Groups (SQL AGs) or SQL Always On Failover Cluster Instances (SQL FCIs).
Sizing the SQL Cluster
The performance requirements for the RD Connection Broker database are relatively insignificant. In most cases, a small SQL server (2 CPU, 4GB RAM) is sufficient to provide adequate performance for a mid-size RDS deployment. For environments that will have a substantial number of concurrent RD sessions-- perhaps 1000 sessions or greater-- it may be advantageous to increase the size of the cluster VMs to 8GB RAM. Cluster VMs can be resized after the initial deployment, as needed.
The RD Connection Broker database does not require a significant amount of storage. Google Cloud currently sets a lower limit of 10GB on each data disk, and the Windows Storage Spaces Direct (S2D) feature used to provide shared storage to the SQL cluster requires a minimum of 4 disks; this capacity is more than sufficient for the RD Connection Broker database.