Clustering Connect Servers with Multiple Availability Zones
Challenge: When a Connect cluster/pool is split into two data centers it is prudent for backup meeting rooms to be created in an alternate datacenter; you do not want the backup and the primary meeting rooms hosted in the same datacenter.
Connect Edge servers fill the gap of extending resources out to remote offices in enterprise proxy mode or of splitting external client traffic from internal traffic in reverse proxy mode; there is not a federated option to allow an origin server cluster to be spread about geographically. Very little latency is tolerable between Connect origin servers. With that said, there is the possibility of splitting an origin cluster across two datacenters for additional redundancy if the latency between the two datacenters is consistently 3 milliseconds or less. Intra-cluster communication on ports 8507 and 8506 must be unhampered for a cluster to work properly.
Spreading a cluster across two local datacenters with less than 3ms of latency requires that all servers point to the same database. Basically I am describing a regular cluster except with half of the servers in one building and the other half in another building nearby. When you do this, it is prudent to make sure that the backup meeting rooms that are spawned in support of every primary active meeting room are always created on servers in the separate datacenter from the active primary meeting. You can do this in the Connect database in PPS_ENUM_DATA_HOSTS. Configure the hosts in one data center with one pool_id, and give the other servers in the second datacenter another pool_id. Then add this setting to the custom.ini on each origin server:
APP_SERVER_POOLING=true
This setting is necessary to configure failover to take advantage of multiple availability zones.
Hi Frank, great article. We’re about to embark on this very use case ourselves for a client. They have two geographically disparate data centers and are looking to cluster Connect across them. They have a consistent 10GB connection between DCs with 1ms latency, so an intra-cluster split origin seems the best way forward. Are you saying above that the Connect servers should point to a single database instance (mirrored in the other DC) or that they should point to a single physical database server? Many thanks.