Setting up Clustering

As of Version 7.4, Secret Server supports clustering the web servers. This feature requires Enterprise Plus Edition.

Setting up Clustering
  1. Have Secret Server upgraded\installed and running on the primary server.
  2. Enable Clustering by going to Administration, Server nodes.
  3. Copy the entire web application folder from the primary node to the secondary node. Follow the steps in the Installation Guide for setting up the application pool and virtual directory in IIS
  4. Ensure the server has the same date time as the primary server.
  5. Once the secondary server is running navigate to Secret Server on that node to go through the DB Connection reset page for connecting to the database. Instructions for how to do this are in Step 2 of this KB article.
  6. Activate licenses for the new node (this can be done on either server once the database connection is established on the secondary node).
  7. Configure your load balancer for the two sites and to have sticky sessions to prevent a user from bouncing between server on each request.
Upgrading in a Clustering environment

Note: Before ANY UPGRADES see the KnowledgeBase article Upgrading Secret Server - Single Instance & Web Clustering for important steps to ensure your data is backed up.
  1. Perform a backup of the primary server.
  2. Stop all but the primary web server
  3. Perform the upgrade as with a single instance
  4. Once upgraded and working, copy the web application folder (without the database.config) to all secondary servers
  5. Start Secondary Server and confirm they still work
Making a server in your cluster the primary:
  1. On the server you will make the primary node, navigate to Secret Server locally.
  2. Log in as an administrator, and click Server Nodes from the Administration menu.
  3. Click the Make Current Node Primary button.
  4. Refresh the Clustering Log on that page to ensure the change is in effect.
Clustering Error Conditions:
  • Encryption configs don't match - see this KB article
  • Server Dates don't match - if the dates on the web servers do not match the audit records could be bad. The fix is to set the servers to the same time.
  • Version does not match - If a secondary node is not properly updated from the primary node after an upgrade, that node will not run because the application version does not match the database. The fix is to copy the application folder (minus the database.config) to replace the files on the secondary server

Article ID: 159, Created On: 4/26/2011, Modified: 2/10/2014

Feedback (1)

Jonathan Jespersen

What are the limitations that require sticky sessions? Is there any direction remove this requirement and allow other load balancing schemes?

5/7/2013 at 1:37 PM