Summary
This article explains how to configure a standby instance of adTempus on a separate computer for use in disaster recovery scenarios.
Assumptions and Definitions
This article assumes you already have adTempus installed and configured on the Primary server. This article explains how to install and configure adTempus on the Secondary server and to shift job execution to the Secondary server in the event of a failure of the Primary server.
This article does not use Windows clustering for failover. See article K00000453 for cluster setup instructions.
Background
adTempus stores most of its data in a database, including all job definitions and history, and information on the current state of each job. Therefore a second instance of adTempus installed on a different computer can take over execution of jobs for an instance on a failed computer, provided that it has access to the database or a copy of it).
Note that adTempus can only execute programs (and scripts, etc.) that are installed on the same computer as adTempus. Therefore all software to be executed by adTempus must also be installed on both computers.
Database Strategy
In shifting execution from the Primary to the Secondary server, the key piece is the adTempus database. Two main strategies are available:
- Both the Primary and Secondary adTempus instances can be configured to use the same database, hosted on a third server.
- The Secondary adTempus instance can be updated with a backup from the Primary instance when it is needed.
Shared Database
The shared database option is only available if you are using a standalone SQL Server instance to host the adTempus database, not if you are using the default SQL Server Express database server provided with adTempus. In this configuration, the adTempus database must be hosted on a SQL Server that is accessible to both the Primary and Secondary adTempus instance. For this to be a viable approach, your SQL Server must be included in your disaster recovery planning as well, and must be redundant (through clustering or some other approach).
With this configuration, the Secondary instance of adTempus can be started immediately if the Primary server fails, because it will have immediate access to the latest version of the adTempus database.
Copied Database
If you are using SQL Server Express, or do not want to rely on a shared database, the Secondary instance will need to be updated with the latest adTempus data before it is activated. This can be done by restoring the adTempus database for the Secondary from a recent backup of the Primary instance's database. To use this approach you must ensure that a recent backup of the Primary instance database is always available.
If you are using the SQL Server Express instance provided with adTempus, adTempus creates a database backup automatically each day. See the adTempus help document for more information.
If you are using a standalone SQL Server instance, you must configure the database backup yourself.
Once the backup has been created each day (or more frequently if you require), you must ensure that the backup file is copied to the Secondary server, or to a location that will be accessible to the Secondary server in the event of a disaster failover.
adTempus Installation and Configuration
On the Secondary server, install the same version of adTempus as is running on the Primary server.
When the database configuration wizard runs during installation, proceed based on the database strategy you are using (see above):
- If you are using the Shared Database strategy, configure the Secondary instance to point at the same database as the Primary instance. Important: You should stop adTempus on the Primary server while you are installing and testing adTempus on the Secondary server, to prevent duplicate execution of jobs and possible corruption of data from having two instances updating the database at the same time.
- If you are using the Copied Database strategry, allow adTempus to install SQL Server Express and create an empty database for you. After installation is complete, load the data from a backup file as discussed in the Failover section below.
After installation completes, change the properties of the adTempus service so the startup type is "Manual" instead of "Automatic," to ensure that adTempus does not run jobs when it should not be doing so.
Registry Configuration for adTempus 4 and Later
Run the Registry Editor on the Primary server and go to key "HKEY_LOCAL_MACHINE\Software\Arcana Development\adTempus\Instances\InstanceName". Copy the "MachineID" value and add it to the same Registry key on the Secondary server.
This step is necessary to allow the Secondary server to connect to the database owned by the Primary server, and to allow a Master to connect to Agents.
Licensing
You do not need to purchase an additional license for your Secondary server but you will need to contact us to get a license issued for the Secondary server.
Additional Software Installation
Any programs, batch files, etc., that your adTempus jobs execute or depend on must also be installed on the Secondary server.
Failover
The steps required to start up your Secondary instance depend on which database strategy you are using.
Shared Database
If you are using the Shared Database strategy, no additional effort is required other than to start the adTempus service on the Secondary server. Important: Always make sure that adTempus is stopped on the Primary server before you start adTempus on the Secondary server, whether for disaster recovery failover or for testing. Otherwise data corruption may occur from having two instances updating the database at the same time.
Copied Database
If you are using the Copied Database strategy, you must use a database restore to load a recent copy of the adTempus data before you start the adTempus service. To do this, run the adtdbutil tool (found in the adTempus program directory) and use the Restore command to restore from a recent backup of the Primary database. Note: The restore will completely replace all data currently in the adTempus database on the Secondary server.
Failback
The steps required to return operations to your Primary instance depend on which database strategy you are using.
Shared Database
To return operations to the Primary server, you need only stop the adTempus service on the Secondary server and start it back up on the Primary server. Because the instances are sharing the same database, the Primary instance will have the history of any jobs that were executed on the Secondary server. You may also want to copy over captured file data as described in the Captured Files section below.
Copied Database
Operations may be returned to the Primary server simply by restarting the adTempus service on the Primary server. However, since the Secondary instance has updated a different copy of the adTempus database, the Primary instance will not have the history of any jobs that were executed on the Secondary server.
At this time it is not possible to selectively transfer that history from the Secondary to the Primary server. Therefore the job history will remain incomplete on the Primary server.
Captured Files
The contents of Captured Files are stored on disk, not within the adTempus database. If you try to view a Captured File that was captured when adTempus was running on a different server, you will get an error indicating that the captured file cannot be found.
If you want files captured on the Secondary instance to be available on the Primary instance after failback, you must copy the files from the Secondary server to the Primary server. Captured files are stored under the "c:\program files\arcana development\adTempus\instances\InstanceName\data\CapturedFiles" directory. Simply copy over any files from the Secondary to the Primary server that do not already exist on the Primary server.
Additional Suggestions
If you need to review or modify adTempus configuration on the Secondary server without allowing jobs to run, you can temporarily disable job execution as described in article K00000346.
