Secondary Connection Brokers
A secondary Connection Broker is added to a Site to provide redundancy and distribute runtime workloads. Connection Brokers within a Site can operate simultaneously in an active/active configuration. This allows multiple Connection Brokers to actively process runtime workloads and monitor the environment.
If a Connection Broker becomes unavailable, the remaining active Connection Brokers can continue to handle the workload. The Connection Broker architecture reduces downtime and prevents the Primary Connection Broker from becoming a bottleneck.
When you install one or more Secondary Connection Brokers, runtime information is replicated between the Connection Brokers and the agents they manage. In addition, active Connection Brokers can handle authentication.
The Primary Connection Broker performs the same runtime tasks as Secondary Connection Brokers, but has additional responsibilities. It manages system-wide processes and settings that a single Connection Broker must manage.
Connection Brokers within a Site can have one of the following roles:
Primary Connection Broker — manages system-wide settings and processes and also participates in runtime monitoring and workload processing.
Secondary Connection Broker — actively processes runtime workloads, monitors resources, and provides redundancy for the Primary Connection Broker.
Connection Broker in standby — maintains replicated configuration but does not actively process runtime workloads.
Connection Broker in a Tenant Broker environment — provides Connection Broker functionality for a tenant environment and performs a defined subset of Connection Broker operations.
Connection Broker roles and responsibilities
The following table describes Connection Broker responsibilities by role.
Handles administration sessions
Yes, Primary Site only
No
No
Yes
Manages system settings
Yes
No
No
Yes
Replicates RAS settings changes
Yes
Yes
Yes
Yes
Keeps RAS settings change audit
Yes
Optional
Optional
Yes
Monitors Connection Broker performance counters
Yes
Yes
No
Yes
Monitors RDSH performance counters
Yes
Yes
No
No
Monitors VDI Host performance counters
Yes
Yes
No
No
Monitors SGW performance counters
Yes
Yes
No
Yes
Monitors ES performance counters
Yes
Yes
No
No
Monitors runtime sessions
Yes
Yes
No
No
Monitors runtime applications/processes
Yes
Yes
No
No
Monitors VDI sessions and reconnections
Yes
Yes
No
No
Sends licensing information and heartbeat
Yes
No. Provides information to the Primary Connection Broker only
No
No
Processes and sends CEP information
Yes
No
No
No
Sends information to the Reporting Server
Yes
No
No
No
Manages Schedulers
Yes
No
No
No
Provides information to the Reporting Engine
Yes
No
No
No
Device Manager shadowing
Yes
No
No
No
Sends system alert email notifications
Yes
Yes
No
Yes
TOTP registration
Yes
Yes
No
No
Email OTP registration
Yes
Yes
No
No
Manages template versioning and distribution
Yes. During setup, the Primary Site Connection Broker is used
Yes. During setup, the Primary Site Connection Broker is used
No
No
Clones hosts from templates
Yes
No
No
No
Manages auto scaling
Yes
No
No
No
Manages Web authentication
Yes
Yes
No
No
Manages Credentials authentication
Yes
Yes
No
No
Manages Smart card authentication
Yes
Yes
No
No
Validates Policies
Yes
Yes
No
No
Provides configuration to HALB devices
Yes. The first Connection Broker to reach the device provides the settings
Yes. The first Connection Broker to reach the device provides the settings
No
Yes. The first Connection Broker to reach the device provides the settings
Distributes configuration changes to RDSH, VDI, PC, ES, and Gateway agents
Yes
Yes
No
Yes. HALB and Gateway agents only
Primary Connection Broker
The Primary Connection Broker handles system-wide operations that must be managed by a single Connection Broker.
These operations include managing system settings, schedulers, auto scaling, licensing information, CEP information, reporting, and other Site-level functions.
The Primary Connection Broker also participates in runtime monitoring and workload processing. However, because it has additional responsibilities, the system does not distribute agent connections equally between the Primary Connection Broker and Secondary Connection Brokers.
Secondary Connection Brokers
Secondary Connection Brokers are active Connection Brokers. They are not passive backup servers.
A Secondary Connection Broker can actively:
Monitor Connection Broker, RDSH, VDI, SGW, and ES performance counters.
Monitor runtime sessions and applications/processes.
Monitor VDI sessions and reconnections.
Replicate RAS settings changes.
Participate in Web, Credentials, and Smart Card authentication.
Perform TOTP and Email OTP registration.
Validate policies.
Provide configuration to HALB devices.
Distribute configuration changes to supported agents.
Send system alert email notifications.
Secondary Connection Brokers do not manage system settings or the Site-wide processes reserved for the Primary Connection Broker.
A Secondary Connection Broker also does not directly perform the Primary Connection Broker's licensing, CEP, reporting, scheduling, auto scaling, or Device Manager shadowing functions.
Connection Broker in standby
A standby Connection Broker does not actively process runtime workloads.
A standby Connection Broker replicates RAS settings changes but does not perform active runtime monitoring, handle administration sessions, manage system settings, or process runtime sessions and applications.
Standby Connection Brokers are useful when you need an additional Connection Broker for availability without having that Connection Broker participate in the active runtime workload.
Connection Broker in a Tenant Broker environment
A Connection Broker in a Tenant Broker environment performs a different set of functions from a Primary or Secondary Connection Broker in the primary Site.
A Tenant Broker Connection Broker can:
Handle administration sessions.
Manage system settings.
Replicate RAS settings changes.
Maintain the RAS settings change audit.
Monitor Connection Broker performance counters.
Monitor SGW performance counters.
Send system alert email notifications.
Provide configuration to HALB devices.
Distribute configuration changes to HALB and Gateway agents.
It does not perform the primary Site's reporting, scheduling, auto-scaling, licensing, or runtime session monitoring functions.
Agent connection distribution
Because the Primary Connection Broker performs additional system-wide functions, agent connections are not distributed equally between Connection Brokers.
The system uses the following preferred distribution:
1
100%
—
2
40%
60%
3
20%
40% each
4
10%
30% each
5 or more
0%
100 / number of Secondary Connection Brokers
This distribution is intentional. It reduces the workload placed on the Primary Connection Broker so that it has sufficient resources to perform its additional system-wide responsibilities.
For five or more Connection Brokers, the Primary Connection Broker does not receive a preferred share of agent connections. Agent connections are distributed between the Secondary Connection Brokers.
The percentages represent the preferred distribution of agent connections. They do not mean that all Connection Brokers perform the same functions or that every type of runtime workload is distributed equally.
Preferred Connection Broker
If an agent is explicitly configured to be managed by a specific Connection Broker, that Connection Broker is preferred over the general connection distribution.
This allows an administrator to control the preferred Connection Broker for a particular agent when required.
For example, if an RDSH agent is configured to use CB2 as its preferred Connection Broker, CB2 is preferred even if the general Site distribution would otherwise assign the agent to another Connection Broker.
Planning for secondary Connection Brokers
RAS Connection Brokers running in the same Site communicate with each other and participate in workload processing. Connection Brokers and agents can exchange a significant amount of data, so provide reliable, high-speed network connectivity.
When planning a Site with multiple Connection Brokers, consider the following:
Provide reliable, high-speed connectivity between Connection Brokers.
Ensure that the network infrastructure can support the communication and configuration replication generated by multiple Connection Brokers.
Where appropriate, use a dedicated subnetwork for Connection Broker communication.
Make sure Connection Brokers can communicate with agents and other RAS components over the required network paths.
Connection Brokers use TCP port 20030 to communicate with each other.
When determining the number of active Secondary Connection Brokers, consider the additional workload performed by the Primary Connection Broker.
Use the preferred agent connection distribution described above to reduce the load on the Primary Connection Broker.
Use standby Connection Brokers when you need additional availability without adding another active runtime processor.
The active Connection Broker architecture supports multiple Connection Brokers in the same Site. However, adding Connection Brokers also increases configuration replication and inter-Connection-Broker communication. Therefore, select the number of Connection Brokers based on the size and requirements of the Site.
You can use the N+1 redundancy approach when planning Connection Broker availability. For environments using auto-promotion, follow the requirements described in Configuring RAS Connection Brokers.
A three-Connection-Broker configuration is particularly useful for environments that use Providers and require high availability for VDI.
Standby Connection Brokers do not participate in active runtime workload processing and therefore have different resource and performance considerations from active Secondary Connection Brokers.
Adding a secondary RAS Connection Broker to a Site
To add a secondary Connection Broker:
In the RAS console, navigate to Farm > <Site> > Connection Brokers.
Click the Tasks drop-down list and choose Add to launch the Add RAS Connection Broker wizard.
The Server field specifies the FQDN or IP address of the server that hosts the RAS Connection Broker. To automatically resolve the IP address to an FQDN, enable the global Name Resolution option. For details, see Host Name Resolution.
The IP field specifies the server IP address. Click the Resolve button to obtain the IP address automatically using the FQDN specified in the Server field.
The Alternative IPs field specifies one or more alternative IP addresses, separated by a semicolon. These addresses will be used if RAS Secure Gateways fail to connect to the RAS Connection Broker using its FQDN or the address specified in the IP field. This can happen, for example, if Secure Gateways are connecting from a different network, which is not joined to Active Directory.
Select the Install a Secure Gateway with a Connection Broker option if you also want to install a RAS Secure Gateway on the specified server. If you select this option, you may also select the Enable HTML5 Gateway option (for more info, see Configure User Portal).
Select the Add Firewall Rules option to automatically configure the firewall on the server. See Port Reference for details.
Click Next.
On the next page, click Install to install the RAS Connection Broker on the server. The Installing RAS Redundancy Service dialog opens.
Select the server on which the RAS Connection Broker is to be installed and click Install.
Click Done.
Click OK to add the server to the Farm.halb
Last updated