in this post we'd like to introduce some work that we have performed in order to provide robust support support for clustered GeoServer deployments with an emphasis on publishing new layers in real-time.
As you might know there are various approaches with GeoServer that can be used to implement a clustered deployment, based on different mixes of data directory sharing plus configuration reload. However, these techniques have intrinsic limitations therefore we decided to create a specific GeoServer Clustering Extension in order to overcome them. It is worth to point out that what we are going to describe is designed to work with GeoServer 2.1 stable series.
In the picture below our approach is shown. We propose a robust Master/Slave approach which leverages on a Message Oriented Middleware (MOM) where:
- The Masters (yes, we can have more than one, read on...) receive changes to the internal configuration, persiste them on their own data directory but also forward them to the Slaves via the MOM
- The Slaves do not accept changes to their configuration from eithe REST or the User Interface, but are configured to inject configuration changes disseminated by the Master(s) via the MOM
- The MOM is used to make the Master and the Slave exhange messages in a durable fashion
- Each Slave has its own data directory which it is responsible for keeping it aligned with the Master's one. In case a Slave goes down when it goes up again he might receive a bunch of messages to align its configuration to the Master's one.
- A Node can be both Master and Slave at the same time, this means that we don't have a single poinf of failure, the Master itself
Improved Clustering in Action
In the following we provide a few additional technical details on our solution, describing a deployment which we use for our tests (as such, it is designed to show every possible combination as opposed to be a best practice for deploy). We will refer to the following picture.
This deployment is composed by:
- A pure Master GeoServer(s), this instance can only send events to the topic.It cannot act as a slave
- A set of Geoserver which can work as both Master and Slave. These instances can send and receive messages to/from the topic. They can work as Masters (sending message to other subscribers) as well as Slaves (these instances are also subscribers of the topic).
- A set of pure Slaves GeoServer instances whic can only receive messages from the topic.
- A set of MOM brokers so that each GeoServerinstance is configured with a set of available brokers (failover). Each broker use the shared DB as persistence. Doing so if a broker fails for some reason, messages can still be written and read from the shared database.
Manually create the GeoTiff store using the User Interface:
Publish the layer
Click save and check results on the clients
Now check the result using the LayerPreview:
As expected using the pure Master to publish the GeoTiff file, the resulting layer will be published automatically on the salve instances with no intervention. There is one thing to notice, we are not moving data around but only their configuration (styles included) since we are assuming that all instances sees the same resources with the same absolute paths, which is common in distributed and cluestered set ups where resources are shared among multiple servers, like for example network storage.
Conclusions
If you are responsible for administering a a series of GeoServer instances and/or you are publishing lots of data in real-time then this extension is a perfect fit for your organization.
In case you are interested in test-driving this extension in your own set-up, you might want to know that we are going to provide this extension free of charge to clients who will subscribe to our GeoServer Professional Services for the 2012 as well as to our partners. Contact us if you are interested!
Regards,
the GeoSolutions Team.
