Analytics.ClusterName serves two main purposes:
- It is used as the identifier of the cluster that locks contacts in xDB;
- 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:
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 firstname.lastname@example.org. The contact email@example.com 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 firstname.lastname@example.org in the Collection database. This is impossible, since the contact is already locked by www1.yoursite.com. Here's what happens next:
- 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.
- www1.yoursite.com accepts the session and merges it with its own running session of the same contact.
- 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.
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:
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.
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.