Introduction
It is possible to configure support for Load Balancing (LB). In large deployments where several issuance's need to be performed concurrently, LB can be useful for balancing the traffic across several different instances, or secondaries, in order to optimize the throughput and capacity of the system.
LB in vSEC:CMS should only be used in very large deployments where high volume of concurrent issuance will be carried out.
The diagram below shows the LB configuration. There will always be one primary server and several secondaries. The LB will then balance requests across these secondaries. Any operation that require read operations only on the database (DB) will go directly to the DB from the secondary. Any operation that requires write operations on the DB will be forwarded to the primary.
For the DB it is required that the primary is configured to use MS SQL for the DB.
LB is only available from version 5.0.1 and above.
Configure LB Support
1. On the primary server install, or update to, the latest version of vSEC:CMS that supports LB.
2. Run through the migration process to MS SQL as described in the article Configure MS SQL as vSEC:CMS Database.
3. On the primary server stop the service vSEC:CMS Service.
4. On the primary server create a registry String value named lb.sqldb.sett in:
[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service]
for 64-bit systems and for 32-bit systems here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]
And put a dummy value into this entry.
5. Start the vSEC:CMS Service. Once the service has started you will see base64 encoded data populated into this registry value. This will be used later when configuring the secondaries. Additionally, start the user self service, RSDM and operator console services.
6. On a secondary server perform a full server installation of the latest version of vSEC:CMS.
At minimum, Microsoft ODBC Driver 17 for SQL Server should be available/installed on the secondary server(s).
It is possible to check what ODBC drivers (if any) are installed on your server. Open the ODBC Data Source Administrator console and from the Drivers tab you can see the drivers installed. Additionally, it is recommended to use the ODBC console to test and ensure that you can connect to the MS SQL database which the primary is configured to use.
If the secondary is failing to connect to the MS SQL check the event viewer for details on possible reasons why the connection failed.
7. On the secondary server stop the service vSEC:CMS Service. Make sure to configure the vSEC:CMS Service to run under the dedicated Windows account that the same service on the primary is running under. Additionally, make sure the same dedicated Windows account has full permissions on the dat folder in the root of the vSEC:CMS installation folder.
Make sure that the secondaries are able to communicate fully with the MS SQL server that the primary is using.
8. On the secondary server create a registry String value named lb.sqldb.cfg in:
[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service]
for 64-bit systems and for 32-bit systems here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]
And put the base64 encoded data created in step 5 above for this value.
9. On the secondary server create a registry String value named soap.adm.lb.url in:
[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service]
for 64-bit systems and for 32-bit systems here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]
And put the URL of the primary server that the operator console SOAP service is available on.
10. On the secondary server create a registry String value named soap.rsdm.lb.url in:
[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service]
for 64-bit systems and for 32-bit systems here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]
And put the URL of the primary server that the RSDM SOAP service is available on.
11. On the secondary server create a registry String value named soap.uss.lb.url in:
[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service]
for 64-bit systems and for 32-bit systems here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]
And put the URL of the primary server that the USS SOAP service is available on.
12. On the secondary server create a registry String value named soap.lb.config.file in:
[HKEY_LOCAL_MACHINE\SOFTWARE\Versatile Security\vSEC_CMS_T\Service]
for 64-bit systems and for 32-bit systems here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Versatile Security\vSEC_CMS_T\Service]
And put the value LB_config.xml.
13. If the MS SQL connection on the primary is configured to use Windows AD account then it will be necessary to configure the vSEC:CMS Service to run under this account on the secondary.
14. Start the vSEC:CMS Service on the secondary and log on with an operator token to the admin console.
15. On the secondary server, from Options – Connections configure the User Self-Service, RSDM Service and Operator Console Service for these connections. These will be the connections that the LB will communicate with.
16. Repeat steps 6 thru 15 on any additional secondary server that you wish to be used for LB.
17. On the LB configure it to balance the traffic to the USS, RSDM and Operator console service configured for your secondaries.
18. On the clients configure these to point to the LB for USS, RSDM and Operator console service.
This completes the setup.
Once the secondaries have been configured they should not be used to perform administration/day-to-day operations. All administration/day-to-day operations should be performed directly on the primary. For example, a helpdesk operator should have their operator console configured to point to the operator console service on the primary.