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.

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.

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 or Affinity

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 [[Admin_Jobs#Job_Edit_Screen|configuration screen].