High Availability Installation with a JAMS Failover Setup

The Benefits of a JAMS Failover Setup

In many instances, it is beneficial to ensure a secondary failover environment has been configured for the JAMS installation. The failover setup ensures there is a completely redundant instance of JAMS residing on a secondary server, often offsite, relying on a heartbeat connection between the two.

By default, this heartbeat is set to a sixty-second interval. If the secondary JAMS Scheduler server does not get a response from the primary JAMS Scheduler server within 3 consecutive beats, the secondary will take over as the primary JAMS Scheduler to ensure the schedule continues as expected.

JAMS Failover Architecture

The JAMS failover architecture should consist of at least three servers:

Primary JAMS Scheduler server
Secondary JAMS Scheduler server
JAMS Agent server(s), where Jobs are run

If a failure occurs, the secondary JAMS Scheduler will take over for the primary JAMS Scheduler to ensure the schedule continues as expected. If Jobs are executing locally on the primary JAMS Scheduler server, a failure will cause all Jobs executing on the JAMS Scheduler server to fail. Running Jobs on JAMS Agent server(s) protects those Jobs from a primary JAMS Scheduler server failure.

Installing and Configuring the JAMS Failover Setup

NOTE: An additional license needs to be purchased to install a secondary JAMS Scheduler server. Please contact your Account Manager for more details.

Install the JAMS Scheduler on the primary server.
The local Agent Name defaults to the name of the primary JAMS Scheduler. The name in the secondary JAMS Scheduler must be updated to localhost.
For redundancy of the JAMS Database, you can configure AlwaysOn Availability after completing the instructions listed above. AlwaysOn Availability is a Microsoft product that replaced Database Mirroring as of SQL Server 2012.
Stop the JAMS Scheduler service on the primary JAMS Scheduler server.
If the primary and secondary JAMS Schedulers are to share a database, add a user to the JAMS database to allow the secondary JAMS Scheduler to connect. This can be done by running the following SQL statements on the JAMS database:
```
exec sp_grantlogin @loginame='YourDomain\YourMachineName$'
exec sp_grantdbaccess @loginame='YourDomain\YourMachineName$', @name_in_db='JAMSMachine2' 
exec sp_addrolemember @rolename='JAMSApp', @membername='JAMSMachine2'
```
NOTE: Replace the login name with the machine name.
Install the JAMS Scheduler on the secondary server.
1. When prompted for the database server, specify the same SQL Server, Instance, and Database Name of the primary JAMS Scheduler server.
2. After selecting Next, a dialog is displayed stating the “Database already exists”. Select Use Database.
Use File Explorer to check whether the following folders are present on the Secondary Scheduler server and manually create them if not:
```
C:\ProgramData\JAMS\Logs
C:\ProgramData\JAMS\Temp
```
Stop the JAMS Scheduler service on the secondary server.
Create or edit a Failover.config file in the Program Files\MVPSI\JAMS\Scheduler directory on the primary and secondary servers. (A sample Failover.config file is displayed below. )
Start the JAMS Scheduler on both the primary and secondary servers.
Grant permissions to the MSMQ Service from the secondary JAMS Scheduler as described in the link below.
How to Grant Permissions to the MSMQ Service from a Secondary JAMS Scheduler

Sample Failover.config

<FailoverConfig>
<Primary>Server1</Primary>
<Secondary>Server2</Secondary>
<Port>4773</Port>
<Interval>60</Interval>
</FailoverConfig>

The primary and secondary server names are the hostnames of the respective machines.
The port is the port used by the primary and secondary scheduler to communicate the heartbeat connection.
The interval value is the length of time that must elapse before a heartbeat is missed. If 3 heartbeats are missed, then the failover process will start.
The interval value can be modified to suit the users needs. It is recommended to not have this value lower than 15 seconds to ensure that the schedulers are not constantly trying to take control of the database during intermittent network issues.

Common Log Output Location

To have a common log output location on a network share for both the primary and secondary JAMS Schedulers, refer to the link below.

Setting a common log output location for JAMS in a Failover Environment

NOTE: After configuring the Common Log Output location, ensure the default log location exists on both primary and secondary JAMS Schedulers.

JAMS in a Disaster Recovery Site

Installing JAMS in a completely separate Disaster Recovery site allows Jobs to run if the primary JAMS server and database are lost. Note the following about DR:

The JAMS Scheduler is installed on a completely separate server with its own database - the JAMS Services on the DR scheduler are left stopped.
The DR database is mirrored using SQL log shipping or mirroring services (also known as High Availability as of SQL 2012), and replication of the SQL DB takes place from Production to DR.

See the "Disaster Recovery Configuration" section in the JAMS Installation Guide for additional information.

During a Disaster Recovery Scenario, the following must take place:

The services on the production Scheduler must be brought down.
The direction of the Mirroring or Log Shipping must be switched to "DR to Production" from "Production to DR," which is handled within SQL.
The Failover table in the DR database must be truncated to allow the DR Scheduler to gain control over its own database.
The Scheduler will look to see if there is a JAMS GUID in the Failover table and will not take control of the DB if another GUID is present.
The services can be started on the DR Scheduler, and the DR Scheduler will execute Jobs using the replicated information in its own DB.

Upgrading JAMS in a Highly Available Configuration