Supportworks Replication
| Status: | Published |
|---|---|
| Version: | 1.4 |
| Authors: | HTL QA |
| Applies to: | Supportworks ESP 7.x |
Supportworks Replication
Introduction
There are various techniques that could be used for performing dynamic backups for Supportworks Version 7.
A variety of factors may be taken into account when deciding on the actual method to be used, but this document provides a "first pass" outline of (a) the IT backup environment in which Supportworks may be run, (b) what would be required to replicate from a "Master" Supportworks application server to a "Slave" Supportworks application server, and (c) how a switch-over from Master to Slave might occur.
Note that a Slave server requires an additional Supportworks server licence. For pricing information on additional server licences, please contact your Hornbill account manager.
Scope
The information within this document covers the dynamic backup of Supportworks Version 7 server using resources supplied with Windows and the system's Core Services, but also refers to certain third-party products and a generic monitoring system. The parts of this document that cover database backup specifically are valid only for the databases that relate to the supplied SwSQL server.
If the Supportworks server is utilising any database system other than SwSQL as the main database (for example, Microsoft SQL Server), provision to replicate that database server should be made independently of the guidelines given in this document, as such replication would normally be the responsibility of your organisation's database administrators.
Note: Any kind of data replication, such as that described in this document, is only of use for recovery from hardware failures or operating-system failures. If failures are caused by configuration or data issues, these would merely be replicated in the Slave server. It should also be borne in mind that switch-overs from Master to Slave server, as described in this document, will still cause a certain amount of disruption among users, since it is unavoidable for network connections to be lost.
The "Standard Running State"
This is the scenario that would exist during normal running, before any switch-over has occurred.
In this section, a general outline is first given of how the Master and Slave servers relate to each other during normal running. This is followed by an indication of what has to be replicated on the Slave, and then by detailed accounts of how such replications may be accomplished.
Outline of Server Locations and Communication
There is a Master Supportworks application server physically located on the main IT site, plus a Slave Supportworks application server that is physically located on a secondary Disaster/Recovery (DR) site. Each would consist of a full, identically configured Supportworks installation.
The Master and Slave servers will be able to communicate with each other via TCP port number 5002, and they will also be able to utilise Windows File Copy from the Master to the Slave.
Outline of Elements to be Replicated
There are up to three distinct elements that may need to be replicated from a Master server to a Slave server (if you ignore the data in any third-party database system such as Microsoft SQL Server), and they are as follows:
- The data in the SwSQL server database - whether or not a third-party database is used
- Some files stored in a Microsoft logical volume on the Supportworks application server
- Windows registry keys recording any HTTP server aliases you may have modified or added
Techniques for replicating each of these elements are described in the following four sections.
Replicating SwSQL Server Database Data
The SwSQL database system can be configured to dynamically replicate the data in its databases via the TCP networking protocol on communications port 5002. Although the configuration procedure itself requires server down time, the ongoing replication processes that result from this can proceed without any services having to be shut down. A possible set of configuration instructions is given here:
- On both servers, run the Supportworks Server Configuration utility (by selecting Start > Programs > Supportworks Server > Supportworks Server Configuration).
- On the Server tab of the Master server's instance of the Server Configuration utility, use the Installed Services section to stop all services (starting at the top of the list).
- On the Master server, run the Interactive SQL program (by selecting Start > Programs > Hornbill Core Services > Interactive SQL).
- Enter the following SQL statement to create a "replication" user account:
- GRANT ALL ON *.* TO user-ID@"%" IDENTIFIED BY 'password';
- On the Master server, open, using a text editor, the file called Swsql.ini, which is located in the SwSQL server’s Bin folder (C:\Program Files\Hornbill\Core Services\SwSqlServer\Bin\ by default) and add the following two lines of text at the end:
- log-bin=replication.log
- server-id=1
- On the Slave server, open, using a text editor, the file called Swsql.ini, which is located in the SwSQL server Bin folder (C:\Program Files\Hornbill\Core Services\SwSqlServer\Bin\ by default) and enter the following lines of text at the end:
- master-host=host-IP-address
- master-user=user-ID
- master-password=password
- master-port=5002
- server-id=2
- where the user credentials are those of the replication account created above.
- Stop the SwSqlServer service on the Master and Slave servers.
- Copy the contents of the Data folder from the Master server to the Slave server. By default, its path is C:\Program Files\Hornbill\Core Services\SwSqlServer\Data.
- Start the SwSqlServer service on the Master and Slave servers.
- Run the Interactive SQL program on the Slave server (by selecting Start > Programs > Hornbill Core Services > Interactive SQL).
- Enter the following SQL statement:
- flush slave;
- On the Master server, run the Supportworks Server Configuration utility (by selecting Start > Programs > Supportworks Server > Supportworks Server Configuration).
- Start all of the installed services, starting from the bottom of the Installed Services list, working your way upwards.
The Slave server's embedded SwSQL databases should now keep "in sync" with the Master server's SwSQL databases, without any services having to be stopped in the process. In order to confirm that data is in sync, you may use the following SQL statements in the Interactive SQL program:
- SHOW SLAVE STATUS; (on the Slave server)
- SHOW MASTER STATUS; (on the Master server)
Replicating File Data
For the copying of file data (such as configuration files and MIME attachments held outside of the databases) from the Master application server to the Slave application server, you could include a command line similar to the following in a regularly scheduled script run on the Master server:
- xcopy C:\Program Files\Hornbill\*.* \\slave-server\Hornbill-folder /d /e /v /c /i /q /h /r /k /y
where slave-server would be the name of the Slave server, and Hornbill-folder would be the network share name representing the Hornbill installation folder on that machine.
This example command would copy all files in your Master Hornbill installation that have changed and would copy all new files that have appeared.
Note that such a complete file copy would include the database files, which means that you would then have to start the script with a series of net stop commands to shut down all the Supportworks services (as they all access the database), and to end the script with corresponding net start commands to restart them.
You could avoid service shutdowns by excluding the database files in \Core Services\SwSqlServer\data from the xcopy and instead replicating that data by means of the configuration method described in Replicating SwSQL Server Database Data above. Thus, rather than specifying a complete copy of the Hornbill installation folder using a single command line, you would have separate xcopy command lines for all other folders.
Alternatively, if you wish to retain the simplicity of a single xcopy command line, you could exclude the database files by denying rights to access (and hence copy from) the \Core Services\SwSqlServer\data folder on the Master server for all accounts but one domain account, and then scheduling the file-copy script to run in the context of any of those restricted accounts. The domain account could then still be used for unrestricted access as and when required.
Replicating Registry Keys
For custom registry data relating to HTTP aliases, the only way you can replicate this is by manually editing either or both of the following registry keys on the Slave server whenever you have modified the corresponding ones on the Master server:
- HKEY_LOCAL_MACHINE\Software\Hornbill\Core Services\Applications\_Global\HttpAliases
- HKEY_LOCAL_MACHINE\Software\Hornbill\Core Services\Applications\Supportworks Server\HttpAliases
Switch-Over from Master to Slave Application Server
To maintain readiness for a switch-over, one Windows service - named SwServerService - would need to be monitored on the Master application server. Then, if this service entered a non-running state, the Supportworks services on the Slave application server would need to be started (from the standby stopped state) in order to bring that server from its “warm” state to its “hot” state - and this would constitute the switch-over.
It is therefore envisaged that any monitoring system used must be able to monitor Windows services on one server and invoke, upon any alteration in the state of such a service, batch files and/or script files (such as Windows Power Shell scripts) to run the Supportworks services on the other server.
At the simplest level, the required Supportworks services could be invoked from the Recovery properties of the monitored service itself, as in the following screenshot:
Any batch or script file (such as SwitchOver.cmd above) that would need to be invoked on the Slave application server for a switch-over to occur would have to include the command lines listed here:
net start SwServerService net start SwCalendarService net start SwSchedulerService net start SwMessengerService net start SwMailService net start SwMailSchedule net start SwLogService net start SwIndexServer net start SwFileService
Supportworks Services States
The "before" and "after" switch-over states of the Supportworks services on either of the servers are shown in the two tables below.
Standard Running States (Before Switch-Over)
| SUPPORTWORKS SERVICE | ||
| SwSqlServer | ||
| SwHttpServer | ||
| SwServerService | ||
| SwCalendarService | ||
| SwSchedulerService | ||
| SwMessengerService | ||
| SwMailService | ||
| SwMailSchedule | ||
| SwLogService | ||
| SwIndexServer | ||
| SwFileService |
DR Running States (After Switch-Over)
| SUPPORTWORKS SERVICE | ||
| SwSqlServer | ||
| SwHttpServer | ||
| SwServerService | ||
| SwCalendarService | ||
| SwSchedulerService | ||
| SwMessengerService | ||
| SwMailService | ||
| SwMailSchedule | ||
| SwLogService | ||
| SwIndexServer | ||
| SwFileService |
Other Considerations
There is one table (named swsystag) within the database that would not require replicating.
Excluding a table from replication is possible, but there are various methods by which this can be done, so a decision as to which method to use would need to be made.
This document is, by no means, a definitive solution, as backup strategies and/or disaster recovery options are covered in more depth during any requirements/analysis phases of Supportworks implementations - in order to best suit the individual environment(s) into which Supportworks is deployed.
For an easier and more comprehensive solution to DR, it may be worth considering the use of a server virtualisation product that has a migration option (such as VMware with vMotion). This should allow the standby server to retain its network identity and connections, resulting in switch-overs that are undetectable by users. See the FAQ entitled "Virtual Server Migration" for the basic requirements.