Analytics.ClusterName in a multi-site scaled environment

Question

We have a multi-site scaled environment, with dedicated roles for CM, PRC, REP and CD, based on the XP1 Azure templates. Behind the load balancer, we have 2 CD instances.

According to the documentation, we need to set Analytics.ClusterName (Sitecore.Analytics.Tracking.config) to the domain name of the website, but in this case, we have a multi-site setup, i.e. multiple domain names.

If you are creating a cluster of content delivery servers, use your domain name when naming the content delivery cluster.

For example: value="cluster1.domain.com"

Repeat this for each node in the cluster. For a single content delivery server, use the domain name of the server instead.

So, which value should I add to the Analytics.ClusterName setting? The host name of the load balancer? Or, just any one of the domain names?

Answer 1

Background

The setting Analytics.ClusterName serves two main purposes:

1. It is used as the identifier of the cluster that locks contacts in xDB;
2. It is used by clusters to transfer sessions and jobs to other clusters.

The first use case is, more or less, self-explanatory.

I'll elaborate on session transfers. Let's say you have two clusters:

• www1.yoursite.com
• www2.yoursite.com

When a user comes from their laptop to yoursite.com, the request is served by www1.yoursite.com, transparently to the user. The user signs in, which identifies them to the system as the contact [email protected]. The contact [email protected] is now locked to www1.yoursite.com in the Collection database.

At the same time, this same user visits yoursite.com from their smartphone, and this visit is served by www2.yoursite.com. After several page loads, the user signs in, and xDB tries to get an exclusive lock on [email protected] in the Collection database. This is impossible, since the contact is already locked by www1.yoursite.com. Here's what happens next:

1. The cluster www2.yoursite.com serializes the current user's session and invokes a web service on www1.yoursite.com to push the user's session.
2. www1.yoursite.com accepts the session and merges it with its own running session of the same contact.
3. www2.yoursite.com uses an HTTP redirect to send the user's browser to www1.yoursite.com. Both user sessions will now be handled by the same cluster.

The above is possible because the cluster names represent real domain names, and the clusters are available by those domain names.

Recommendations

When you have multiple content delivery clusters:

• Set up a separate domain name for each cluster;
• On every CD instance of every cluster, set the Analytics.ClusterName setting accordingly;
• Make sure that the clusters are available by that domain name, both from the internet, and to each other. Session transfers are server-side web requests, so each cluster should see all other CD clusters;
• These domain names don't need to be specific to any domain names in your multisite solution. They are only needed for inter-cluster communication and forwarding users between clusters.

When you have one content delivery cluster:

Set Analytics.ClusterName to the main domain name of any site running on it. In this scenario, there should be no inter-cluster communication, so this setting will only serve one purpose: be the owner of contact locks in the Collection database.

Notes

If your CM server has xDB tracking enabled, it should be considered a separate CD cluster, since the CM server role only supports InProc shared session. In this case, set its cluster name to a separate domain name, e.g. cm.yoursite.com and make this domain name visible internally and externally.