The Benefits of a JAMS Failover Scheduler
In many instances, it is beneficial to ensure a secondary Failover environment has been configured for the JAMS installation. The Failover ensures that there is a completely redundant instance of JAMS residing on a secondary server, often times offsite, relying on a heartbeat connection between the two.
By default, this heartbeat is set to a 60 second interval. In the event the Failover does not get a response from the Primary within 3 consecutive beats, the Failover will takeover as the Primary scheduler, ensuring that the schedule continues unharmed.
JAMS Failover Architecture
The JAMS Failover Architecture should consist of at least three servers:
- JAMS Primary Scheduler Server
- JAMS Failover Scheduler Server
- JAMS Agent Server(s), where Jobs are run
In the event of a failure, the Failover Scheduler will take over for the Primary Scheduler, ensuring the schedule of Jobs remains intact. If Jobs are executing locally on the Primary Scheduler Server, a failure would result in the failure of all Jobs executing on the Scheduler server. Running Jobs on JAMS Agent Server(s) insulates those Jobs from Primary Scheduler Server failure. To further insulate the executing JAMS Jobs from server failure, the JAMS Agent can be configured in a cluster.
Installing and Configuring the JAMS Failover
Note: An additional license will need to be purchased to install a Failover Server. Please contact your Account Manager for more details.
- Begin by stepping through the normal installation of the JAMS Primary Engine.
- The Local Agent Name defaults to the name of the Primary Scheduler. The name in the Secondary 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 which replaced Database Mirroring as of SQL Server 2012.
- At this point, please be sure to stop the JAMS Scheduler service on the Primary Engine machine.
- Next, begin by installing the JAMS Scheduler on the second node. When prompted for the database server, specify the same SQL Server, Instance and Database Name identically to the Primary JAMS Engine. After selecting Next, a dialog will appear stating “Database already exists”. You will select “Use Database.”
- As done on the Primary Server, stop the JAMS Scheduler service on the secondary server.
- Create/Edit a Failover.config file (sample is displayed below) in the \MVPSI\JAMS\Scheduler directory on the Primary and Secondary server. Default location:
- Next, start the JAMS Scheduler server on both the Primary and Failover machine.
- Lastly, if the Primary and Failover are sharing a database, it is necessary to add a user to the JAMS database to allow the Secondary engine to connect. This can be done by running the following SQL statements on the JAMS database:exec sp_grantlogin @loginame='YourDomain\YourMachineName$'
exec sp_grantlogin @loginame='YourDomain\YourMachineName$' exec sp_grantdbaccess @loginame='YourDomain\YourMachineName$', @name_in_db='JAMSMachine2' exec sp_addrolemember @rolename='JAMSApp', @membername='JAMSMachine2'
Note: You will replace the login name with the machine name.
<FailoverConfig> <Primary>Server1</Primary> <Secondary>Server2</Secondary> <Port>4773</Port> <Interval>60</Interval> </FailoverConfig>
Common Log Output Location
To have a common log output location on network share for both Primary and Secondary schedulers please refer to the following article's solution.
Note: After configuring the Common Log Output location, ensure that the default log location exists on both Primary and Secondary schedulers.
JAMS in a DR Site
Installing JAMS in a completely separate Disaster Recovery site allows jobs to run in the event that the Primary JAMS Server and Database are lost. Note the following about DR:
- The scheduler is installed on a completely separate server, and installed to 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.
During a DR 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," this is handled within SQL itself.
- 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 pick up the execution of Jobs utilizing the replicated information in its own DB.
- By granting access to MSMQ queues on each Scheduling Engine, jobs can be submitted transparently to the either the Primary or Secondary Engine.