The recently released OpenGeo Suite 4.0 adds new support for clustered operation of GeoServer with the JDBCconfig and Clustering modules.
We’ve mentioned how to run GeoServer in a clustered configuration (part 1, part 2) before, but these new modules make that same configuration work even better. You’ll still be sharing a data directory and putting the nodes behind a load balancer, but now some of the config has been moved to an RDBMS and there’s no need for restrictions on updates or workarounds to get all the nodes in sync.
JDBCconfig moves the persistence of the catalog and much of the other configuration of GeoServer out of the file system and into a relational database where sharing between nodes is more reliable. Postgres and H2 are currently supported, and can be configured directly or via JNDI. The database does not need special extensions and can be initialized and loaded with the existing contents of the GeoServer data directory automatically. JDBCconfig handles much of the most frequently changed configuration information, but does not completely eliminate the data directory as there are many specialized files, particularly those used by extensions, plugins, and templates.
Besides having common storage for configuration, GeoServer’s subsystems need to be informed when changes occur so that they can purge cached copies of configuration information. The clustering module detects changes and informs other nodes in the cluster so that they can perform the necessary clean-up themselves. If the module is in the simpler ‘reload’ mode, this simply means that the other nodes reload their entire catalogs. In ‘event’ mode, clustering replicates the specific events that were fired on the first node on all the remote nodes, triggering cache purges for only the specific configuration objects that were changed.
The clustering module also provides HTTP session sharing for the administration interface of GeoServer so that a shift between nodes by a load balancer will not cause the user to logout. For performance reasons, session sharing is best used as a backup to sticky sessions in the load balancer. It will allow a user to stay logged in even if the node they were using fails. Session sharing can also be disabled if you prefer to just use the synchronization capability of Clustering.
Both configuration synchronization and session sharing use the Hazelcast library, which allows nodes to join, fail out of, and rejoin the cluster on the fly. The full range of Hazelcast’s configuration options are exposed to allow cluster behaviour to be customized.
OpenGeo Suite customers get custom clustering and deployment advice included in their maintenance agreements. Have you been looking at deploying GeoServer in a clustered environment? Tell us about it!