This is the second post filed under Autosys Tutorials. If you are new to AutoSys you may want to start with Introduction to AutoSys.
In this tutorials we will cover AutoSys System Components. AutoSys follows a Unique, Event-Driven Architecture in order to fascilitate job management for your organizations mission critical applications at an enterprise-wide level. Its event-driven, tiered architecture comprises of the following components.
The main system components of AutoSys are:
- Event Server (database)
- Application Server
Event Server (Relational AutoSys Database)
The event server is the AutoSys database. It stores all system state information such as all jobs, monitors, calendar, report definitions etc. It also stores the systems active state such as event status, machine statuses, job statuses and machine queues. Having the current state information allow AutoSys to support high availability, disaster recovery and fail-over capabilities in case of a disaster such as a server crash, network or infrastructure failure.
Dual Event Servers
You can configure Unicenter AutoSys JM to run using two databases, or Dual Event Servers. This feature provides complete redundancy so that, if you lose one Event Server due to hardware, software, or network problems, operations can continue on the second Event Server without loss of information or functionality. This feature is independent of any replication or redundancy offered by the database. For various reasons, database users often run multiple instances of servers that are unaware of the other servers on the network. When implementing Unicenter AutoSys JM, the database can run for Unicenter AutoSys JM only, or it can be shared with other applications.
The Application Server acts as a communication interface between the Event Server Database and the Agent and client utilities. It may run either as a UNIX process or a Windows service and manages communication between the Event Server, Agent, and client utilities.
The Scheduler is the core component of AutoSys. Sometimes called the event_demon, the Scheduler is the program, running either as a UNIX process or as a Windows service that actually runs Unicenter AutoSys JM. The Scheduler is event-driven. After you start it, the Scheduler periodically queries the database for events to process. As events are retrieved, the Scheduler acts on them as appropriate. Events have various origins: some are manually sent by a user; others are sent by an Agent to indicate the progress of a job. An event often requires an Agent process to perform an action. These actions may include starting or stopping jobs, determining availability of resources, monitoring existing jobs, or initiating corrective procedures.
High Availability Option: Shadow Scheduler
AutoSys lets you set up a second Scheduler, called the Shadow Scheduler. Each Scheduler should run on a separate computer. Both the Primary Scheduler and the Shadow Scheduler periodically update the Event Server to indicate that they are in active mode. The Shadow Scheduler remains in an idle mode, receiving periodic messages called pings from the Primary Scheduler. Basically, these messages indicate that the Primary Scheduler is operating correctly. However, if the Primary Scheduler fails for some reason, the Shadow Scheduler takes over the responsibility of interpreting and processing events.
The Agent consists of a persistent or parent Agent process (or service in case of Windows) that runs the software on the remote computer. A Child Agent that is started by the parent for every job that is run on that computer. The child Agent starts and monitors the job process and exits when the job is completed. On Windows, the parent Agent is a Windows service (autosysd.exe), and the child Agent is an executable (auto_remote.exe). On UNIX, the parent Agent is a binary (auto_remote), and the child Agent is a split image of it. The child Agent sends running and completion information about the job to the Application Server. If the Agent cannot transfer the information, it waits and retries until it can successfully communicate with the Application Server.
A Client is any executable that interfaces with the Application Server. This includes AutoSys Command Line Interface (CLI) applications such as JIL and autorep. Client software allows us to control the Application Server from a remote computer.