Fault-Tolerant AWS Architecture in JAMS V7.X

Fault-Tolerant AWS Architecture

JAMS and AWS, used together, create a fault-tolerant, secure cloud automation environment. Continue reading for an overview of the AWS Architecture for JAMS, and instructions on how to install JAMS against Amazon RDS.

JAMS in AWS Architecture

Note: The below example is for illustration purposes and not intended to be the suggested JAMS Configuration. There are many ways to configure JAMS in AWS. The below is just one possibility.

About the Architecture

The architecture diagram assumes that JAMS would be built around a Virtual Private Cloud (VPC), with a CIDR block of 10.0.0.0/16 in the US East region.

In the JAMS for AWS architecture, there must be a minimum of:

Two Public Subnets
- us-east-1a(10.0.1.0/24)
- us-east-1b(10.0.2.0/24)
Two Private Subnets
- us-east-1a(10.0.3.0/24)
- us-east-1b(10.0.4.0/24)
A separate Subnet for RDS, spanning multiple AZ's (Availability Zones), with automated replication.

Failover and Recovery

In the AWS architecture, JAMS is deployed on two Public Subnets to ensure failover capabilities for the primary server.

How It Works

The failover scheduler is a duplicate instance of JAMS that checks the health of the primary scheduler on a configured heartbeat interval. If the primary scheduler misses three heartbeats with the failover server, the failover will take over as the primary scheduler, ensuring that the schedule continues unharmed.

For Example

If the us-east-1a AZ goes down, the failover scheduler in us-east-1b would automatically take over scheduling duties after three failed heartbeats.

Failover capabilities could also be met with an Auto Scaling Group relying on a health check via HTTP (port 80), looking for "healthy.html".

NOTE: Users are responsible for determining which file the ASG looks for if there is a web server running on the instance. If no server is running on the instance, users may also do health checks via a specific port.

Recovering from AWS Region Failures

To provide recovery options for region-wide AWS failure, users could define their environment as a CloudFormation Template, updating this template with Database Snapshots to keep a near 1:1 reflection of the primary environment. Even if an entire AWS region went down, AWS could automatically bring everything back up again with that latest database snapshot in as little as 15 minutes. In the rare event of a region outage, the CloudFormation Template would reduce recovery times by hours.

Note: To learn more about using the CloudFormation Template, visit Amazon AWS.

Auto Scaling Agents

By using an Internal Load Balancer in conjunction with Auto Scaling Groups (ASGs) for each Agent Pool, users will ensure that JAMS scales up and down as needed based on the Agent load. With an Internal Load Balancer, AWS handles the routing of traffic, simplifying the configuration and removing the need for JAMS to know which instance is healthy or was added to the pool of resources.

Note: Users should employ multiple Internal Load Balancers as necessary to match their Agent Pools.

Security and Gateways

Each Subnet has a Security Group to allow access to specific ports necessary for a given instance. The external network ACL is used to limit traffic to specific ports. This way, users can let data in on a given port, without making it accessible to the broader internet.

The NAT Gateway limits access to the Private Subnets and acts as a bastion - whether to check on data, update, patch, etc.

NOTE: To learn more about NAT Gateways in AWS, review Amazon's AWS NAT Gateway Documentation.

The Internet Gateway gives the Public Subnets access to the internet. Through ACL's, users can ensure this access is limited to ports 773 and 80, if desired. Note that the Internet Gateway is the only way the outside world can access the given server (with the JAMS Web or FAT client).

Users may implement additional security measures, such as Web Application Firewalls, as desired.

Installing JAMS against Amazon RDS

Installing JAMS against Amazon RDS is similar to on-premises JAMS deployments, except that the RDS SQL Instance will be specified on the Installer's SQL Step.

NOTE: The instructions make no assumptions regarding VPCs (Virtual Private Clouds), Security Groups, nor the overall scope of the Amazon Environment. For information regarding Amazon Relational Database Services, check out Amazon's RDS Documentation.

Installing the JAMS Database against RDS

Create the RDS instance. Take note of the SQL Server endpoint of the instance, as this information will be used later within step 3 of the instructions.
Within SQL Server Management Studio, connect to the newly created RDS instance, then open the server's Properties.
In the SSMS Properties dialog, select Database Settings. Take note of the Database default Data and Log locations, as they must be defined in JAMS as they are specified within step 7 of the instructions.
Begin installing the JAMS Scheduler on the desired JAMS Server.
On the SQL step in the JAMS Installer, enter the SQL Server Endpoint of the RDS instance. The Database may be named as desired.
Use SQL Server Authentication, then enter the Master RDS User credentials defined on creation of the RDS instance.
NOTE: To utilize Windows Authentication instead of SQL Server Authentication, a database must first be created via the Installer with the RDS Master User. Once the JAMS Database is created, the JAMS Machine Account or Account running the JAMS Services, can be permissioned. The Connection String in JAMS can then be modified for JAMS Window Authentication.
The Locations step requires users to specify the File Locations for the JAMS Database. Enter the Database default log locations found in step 3 as the Primary File and Database Logs locations.
Finish the JAMS Installation normally.