Clustering

Obsidian provides zero-configuration clustering. If you want to add a new scheduler to the cluster or replace an existing node, simply start it up pointing to your Obsidian database, and it will join the pool and begin executing jobs immediately. You may wish to consult Recovery & Failover for additional details on scheduler behaviour.

Obsidian's clustering works by coordinating effort of various nodes through a central relational database such as MySQL or Oracle. Each set of Obsidian tables corresponds to a separate cluster instance. For example, you may have separate QA and production databases. If you run multiple Obsidian schedulers pointing to the same database, they will run in the same cluster. This can also be accomplished by having Obsidian tables in the same database but using a separate table prefix.

No cluster configuration is ever required, allowing you to adapt quickly to new needs.

All scheduler nodes, any deployed Web Admin WARs and the database should be time synchronized from the same source and to the same timezone.

Load Sharing Algorithm

The clustering algorithm in Obsidian is designed to take full advantage of the available nodes in the cluster. The scheduler takes into account how many other nodes are running, and how many jobs need to be run at the current time in order to provide load balancing. That is one key difference in Obsidian since it values load-sharing over second-level precision, since most applications don't require it. Other schedulers, by contrast, do clustering by having all nodes immediately try to claim a job for execution, which can result in one node claiming multiple jobs while others remain idle.

You can add new cluster nodes at any time and they will automatically join the pool, and the load-sharing and scheduling algorithm will adapt right away.

Host Restrictions

Jobs can be restricted to run only on specified hosts. This allows you to use Obsidian in a multi-host environment, even when certain jobs can only run on one of the hosts in the cluster. More details can be found at Job Features, or you can view details on the corresponding configuration screen.

Host Preference

In addition to host restrictions, Obsidian 3.0 introduces the concept of host preference. For each job, you can select this option to enable prioritizing specific hosts for job execution. When a job configured with this setting is ready for execution, Obsidian will select the most preferred host to execute the job on, and if no preferred host is available, execution will fall back to any available host. This is configurable on the job configuration screen.