Clustered server environments
Configure a cluster of content delivery servers to improve scalability and performance
A clustered content delivery environment consists of a collection of servers grouped together to improve scalability and performance. Each cluster can contain two or more content delivery instances, each with its own session state server. You can also group clusters together in the same place or spread them across different geographical locations.
In a clustered content delivery environment, the same cluster of web servers serves all the visits for a single contact. This ensures that all interactions have fast access to the current state of the contact. If a single contact opens multiple concurrent sessions from different browsers or devices, the xDB ensures that each session sticks to the same cluster. A contact can only move to another cluster when they end all their current open sessions and start a new one or the session expires.
You can configure a clustered server environment for content delivery and to improve scalability and performance. For example, to improve performance and enable horizontal scaling of content delivery, you can create multiple content delivery clusters.
A content delivery cluster consists of the following components:
Two or more content delivery instances. Please refer to Configure a content delivery server for details on how to set up content delivery instances in a cluster.
Session state database – to ensure that a contact sticks to the same content delivery cluster, each cluster must have a shared session state server (Microsoft SQL Server or MongoDB).
Load balancer – that distributes traffic to the appropriate content delivery instances in the cluster (not shown in the diagram). The load balancer is the public endpoint of the cluster. The DNS name for the load balancer must use the same naming scheme that you use when you configure your clustered server environment.
Two content delivery clusters with two content delivery instances in each cluster:
 |
Sitecore uses session state for storing information about the current contact interaction, contact state, and any other related data.
Private session state collects data on the interactions and the devices used by the contact.
Shared session state data includes all data that is unique to a contact and that can be shared across simultaneous sessions, such as contact details and any triggered engagement automation states.
If a contact opens multiple, concurrent sessions from different browsers or devices, the xDB ensures that each contact stays connected to the same server cluster where their interaction originated. A contact can only move from one cluster to another once the active sessions have ended or expired.
Content delivery clusters share the same naming scheme, which is closely tied to the server geo-local DNS configuration settings:
All server clusters respond to a global hostname that is configured in DNS to resolve to the IP address of the closest cluster. For example, www.sitecore.net, which maps to
4.4.4.4in Asia and8.8.8.8in the United States.Each cluster must have a unique hostname that globally resolves to the cluster's IP address. For example, asia.sitecore.net maps to
4.4.4.4globally, and us.sitecore.net maps to8.8.8.8globally.