Clustering: Difference between revisions
Created page with "Obsidian provides zero-configuration clustering. If you want to add a new scheduler to the cluster, or replace an existign node, simply start it up pointing to your Obsidian d..." |
No edit summary |
||
| Line 1: | Line 1: | ||
Obsidian provides zero-configuration clustering. If you want to add a new scheduler to the cluster, or replace an | 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. 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 [[Advanced_Configuration#Table Prefixes|table prefix]]. | Obsidian's clustering works by coordinating effort of various nodes through a central relational database such as MySQL. 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 [[Advanced_Configuration#Table Prefixes|table prefix]]. | ||
Revision as of 03:26, 8 November 2013
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. 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.
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.
