JobServer comes in two editions, Professional and Standard. Standard edition can only be deployed on one host computer and comes bundled with its own local database. Standard and Pro share the same basic architecture but Pro edition can be deployed on multiple computers and supports much greater scalability and offers higher reliability.
JobServer is composed of three tiers:
Below is a diagram that shows the architecture of JobServer Standard. All three tiers are installed and configured to run on one host computer. This helps make it easy to deploy and configure. All you need to do is install the package on the target host computer and you are ready to go.
JobServer Pro can be installed on one or more computers based on your scalability and environment needs. It allows for scalability in two dimensions. First, the three tiers of webserver, job scheduling/processing, and database, can each be deployed each on separate computers. This means you can have multiple web servers to serve up JobServer's GUI web applications and scale the JobServer web application to as many GUI users as you have. Then you can install a primary JobServer Scheduling/Processing Engine on a primary computer and have a secondary (failover) JobServer Scheduling/Processing Engine on a separate computer. The secondary server functions as a hot standby job scheduling and processing server. Then the database can also be placed on a remote computer with support Oracle, MYSQL, PostrgreSQL and HSQL. You can use high-end clustered Oracle database if like, as an example.
The second dimension of scalability, with JobServer Pro, is at the Job processing level. You can run jobs on multiple computers using the concept of Agents. A JobServer Agent is a remote extension of JobServer that can run jobs that are fed from the main JobServer Scheduling Engine. You can have many Agents, each on its own computer, all running jobs for one or more Partitions. This allows for clustering at the Partition level. Partitions are logical containers in JobServer that can span one or more Agent machines. Jobs are grouped together to run on Partitions. With this model you can increase job processing capacity by adding additional Agents for each Partition. With this, you can also support job processing clustering by leaving exccess Agent capacity in each Partition so if one Agent server where to go down, others would pick up the slack for the jobs associated to that given Partition. The diagram below illustrates the architecture of a distributed configuration of JobServer Pro using Agents.
Agents are essentially remote computers running JobServer's job processing engine. Each Agent can be used to run jobs from one or more JobServer Partitions. You have the option of laying the topology of Partitions to Agents in a variety of ways. This means you can have Agents dedicated to only one Partition, or if the Agent is running on a high-end computer with many cores/cpus/memory then you might consider letting it run jobs from multiple JobServer Partitions. This is all up to you at the GUI configuraton level. Using the JobServer Adminstration GUI tools, you can associate any Partition to any set of available Agents running on remote job processing computers.
You will also note an optional Mule/SOA tier is avialble to use. This is optional and requires you have Mule installed with your JobServer environment. This allows you to run and access SOA services through Mule, from your Tasklets and Weblets.
To install JobServer Pro on multiple machines. Install the JobServer software on a central file server then have the remote webservers, primary/secondary job scheduling host machines, and Agent machines mount the central file server that contains the jobserver home directory.
For high availability configurations, with multiple host machines, it is recommended you install the JobServer software on a highly available central filesystem such as a NetApp, SAN, or other high performance and reliable central file server. Then have each of the remote computers that are running JobServer Agents, Primary/Secondary scheduling engine or JobServer webserver to mount the central filesystem.