Friday, September 12, 2014

Looking at High Availablility with Eclipse Orion

I've had the opportunity to do some work on Eclipse Orion lately, and I'm really enjoying it.  There are opportunities to learn about technology on both the server (Java and/or Nodejs) and the client side (HTML, CSS, and JS).  It's a lot to learn :-)

One of the things I've been looking at is High Availability in Orion 7.0.  If we use horizontal scaling, we can upgrade one server while leaving another server to continue to provide service (we're working with some kind of proxy in front of the servers, like NGINX, to direct traffic).

Anthony has been working on consolidating Orion metastore/metadata, on distributing upgrades on user access or background processes, and on a policy to cover how we add/upgrade new metadata properties so that older servers could still function against the new metadata.

I've been focused on allowing multiple servers to access the same user content and search indices at the same time.

By default, there's only one small change in Orion 7.0.  The search indices which used to reside in osgi.instance.area/.plugins/org.eclipse.orion.server.core.search will now reside in osgi.instance.area/.plugins/org.eclipse.orion.server.core.search/<version> (where the current version is v16).

You can use properties (See web-ide.conf) to activate the new configuration, where the user content and the search indices are in a common location but each server still has its own local osgi.instance.area.

For example, if I had 2 servers that had their local OSGi instance areas at /opt/orion/workspace (not shared between servers) and a common NFS mount at /home/data, I could set up the orion configuration on each server to serve up the same content using:

  • orion.file.content.location=/home/data/orion/content
  • orion.search.index.location=/home/data/orion/search
  • orion.file.content.locking=true
The search indices and user content should not point to the same directory.  The file content locking uses file system (per process) locks to protect read-writes of user metadata and instructs only one process to run the search indexing jobs at a time.

We've done some preliminary testing, but we always welcome more testing and feedback.  If you get a chance to use this, please let me know :-)