The following diagram shows an example of a three node cluster implementation of Co-browse:
- Each Co-browse server has the same role in the cluster and must be identically configured.
- Each Co-browse server hosts the following:
- CometD server with Co-browse
- Live Session API
- A Co-browse cluster is formed through a load balance/reverse proxy. See Cluster Configuration.
- A Cassandra cluster is formed through appropriate cassandra.yaml configuration.
- Co-browse servers are usually deployed in the back end server environment and given access through a load balancer/reverse proxy.
- Internal Co-browse server resources are secured at the network level by not being exposed via the Public Load Balancer. Co-browse Server resources are exposed to internal applications via the Internal Load Balancer.
- Agent Desktops connect to the Co-browser server to receive web page representations from the Client Browser.
- The Co-browse plugin for Genesys Workspace Desktop Edition (Agent Desktop) reports Co-browse statistics via attached data on primary interactions.
- The Client Browser initiates a Co-browse session and transmits web page content to the Agent Desktop through the Co-browse Server.
Architecture with Multiple Data Centers
The following diagram shows an example of a two data center implementation of Co-browse:
A Co-browse solution can be deployed across multiple Data Centers to provide higher availability. Each Data Center deployment acts independently except for the following points:
- The Cassandra cluster is configured in multi-data center mode (http://www.datastax.com/dev/blog/deploying-cassandra-across-multiple-data-centers) to enable data sharing across multiple data centers.
- If a local Co-browse cluster does not respond, a multiple DC Load Balancers could be configured to forward requests to a remote Co-browse Reverse Proxy. Multi DC balancing logic can also be injected directly into a Co-browse Reverse Proxy.