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.
In this article:
- JAMS in AWS Architecture
- About the Architecture
- Failover and Recovery
- Auto Scaling Agents
- Security and Gateways
- Installing JAMS against Amazon RDS
- Additional Reading
JAMS in AWS Architecture
About this Architecture
This 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
- Two Private Subnets
- 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.
E.g. 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.
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. To learn more about NAT Gateways in AWS, read the 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. The main difference is in specifying the SQL instance where JAMS is installed.
Note that these instructions make no assumptions regarding VPCs (Virtual Private Clouds), Security Groups, nor the overall scope of the Amazon Environment. For information on Amazon Relational Database Services, check out Amazon's RDS Documentation.
Installing the JAMS Database against RDS
- Create the RDS instance. Note the SQL Server endpoint of the instance, as it will be used later.
- 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. Note the Database default Data and Log locations, as they must be defined in JAMS as they are specified here.
- Begin installing the JAMS Scheduler on the desired JAMS Server. When the installer does not detect a database, the Create a JAMS Database wizard will appear. Hit Next.
- Enter Contact Information for the Database, then hit Next.
- In the Select SQL Server section, enter the SQL Server Endpoint of the RDS instance. The Database may be named as desired.
- Set authentication to the RDS instance based on the following:
If RDS was not joined to a domain, use SQL Server Authentication and enter the credentials that were defined on creation of the RDS instance.
If RDS was joined to a domain, use Windows Domain Credentials.
- The Database File Locations step requires users to specify the Database File Locations for the JAMS Database. Enter the Database default log locations found in step 3 as the Primary File, Volatile File, History File, and Database Logs locations.
- The next section requires users to specify the JAMS Default Directories. Users may leave these directories as-is, or specify a custom location.
- In the Account Information step, enter the Username and Password to use on sample Jobs in JAMS.
NOTE: This information is optional.
- Click Finish to allow the JAMS Installer to deploy the database against the RDS instance.
- The JAMS Installer will create the Database, then resume any outstanding steps in the JAMS Software Installation.