So, you decided to use GeoServer to deliver your business' critical spatial information across the enterprise and out on the web? This is a wise choice that many other like-minded GeoServer users will agree with.
Now, it's time for us to roll up our sleeves and get into the nitty-gritty of getting GeoServer up and running so that we can unlock the potential of our spatial information.
By the end of this chapter, we will have a better understanding of the following topics:
Choosing the right version of Java to run GeoServer
Installing and configuring Java for Linux and Windows
Installing and configuring Apache Tomcat for the Linux and Windows platforms
Configuring the Java VM's memory for GeoServer
Deploying GeoServer into the Apache Tomcat servlet container
Understanding the concepts of scalability and high availability and how to configure GeoServer for both
GeoServer is a software server written in Java, and as such it requires Java to be present in our environment. The process to install Java will differ according to our target server's architecture. However, in all cases, the first decision we must make is what version of Java to install and with which package. This is because Java is available in two main packages: Java Development Kit (JDK) and Java Runtime Environment (JRE). JDK, as the name suggests, is used to develop Java applications, while JRE is generally used to run Java applications (though JDK also contains JRE).
There are a number of different versions of Java available. However, the GeoServer project only supports the use of Java 6 (also known as Java™ 1.6) or newer. The most recent version is Java 7 (also known as Java 1.7), and GeoServer can be run against this version of Java. The choice of whether to use Java 6 or 7 will largely be down to either personal preference or specific system limitations such as other software that have dependency on a version. For example, Tomcat 8.0 now requires the use of Java 7 as a minimum. The GeoServer documentation states that Java 7 offers the best performance, and so this is the version we will use.
The upcoming GeoServer 2.6 release will require JRE7 (1.7) as a minimum. At the time of writing, GeoServer 2.6 is at Release Candidate 1.
Prior to Version 2, GeoServer required JDK to be installed in order to work; however, since Version 2, this is no longer a requirement, and GeoServer can run perfectly well using just JRE. The key to manage a successful production environment is to make sure there are no unnecessary software or components installed that might introduce vulnerabilities or increase the management overhead. For these reasons, JRE should be used to run GeoServer. The following sections will describe how to install Java to the Linux and Windows environments.
A well-designed production environment will be as lean as possible in terms of the resources consumed and the overall system footprint; one way to achieve this is to ensure that servers do not contain any more software than is absolutely necessary to deliver its intended function. So, in the case of a server being deployed to deliver mapping services, it should only contain the software necessary to deliver maps.
There are many different flavors of Linux available and all of them are capable of running GeoServer without any issues, after all, Java is cross-platform! The choice of Linux distribution is often either a personal one or a company policy-enforced one. There is a great deal of information available to install GeoServer on a Ubuntu distribution, but very little on installing on a CentOS distribution. CentOS is an enterprise-class distribution that closely follows the development of Red Hat Enterprise Linux, and it is a common installation in organizations. We will use CentOS 6.3, and in keeping with the philosophy of making sure that the server is lean, we will only use the minimal server installation.
By default, CentOS 6.3 comes preinstalled with OpenJDK 1.6 as a result of potential licensing conflicts with the distributing Oracle Java that's preinstalled. The GeoServer documentation states that OpenJDK will work with GeoServer, but there might be issues, particularly with respect to 2D rendering performances. While OpenJDK can be used to run GeoServer, it is worth noting that the project does not run tests of GeoServer against OpenJDK, which means that there is a potential risk of failure if it is used in production.
As mentioned previously, Oracle Java is not packaged for the CentOS platform, and thus we will need to install it ourselves using a generic package direct from Oracle. To download Java, visit the Oracle Technology Network website:
Perform the following steps:
Download the current version of JRE 7 for the Linux platform, choosing the
*.rpmfile from the download list. At the time of writing, this file is
The eagle-eyed amongst you might spot that this file is for a 64-bit flavor of Linux. GeoServer can be installed on both 32-bit and 64-bit architectures; however, installing to a 32-bit Linux architecture will require downloading the 32-bit version of the file, which at the time of writing is
Once we download the package to our server, we need to install it.
Change to the directory where the package is downloaded and execute the following command:
$ sudo rpm -Uvh jre-7u51-linux-x64.rpm
This will result in JRE being unpacked and installed to the
/usr/javadirectory. Within this directory, there is a symbolic link called
latest, which links to the actual JRE install folder. This symbolic link can be used in place of the lengthier JRE directory name. It is best practice to use the
latestlink so that the future upgrades of JRE does not cause Java-based software to stop working due to broken references.
Next, we need to tell CentOS that we want it to use Oracle JRE instead of the preinstalled OpenJDK. To do this, we make use of the
alternativescommand to specify the flavor of Java to use:
$ alternatives –install /usr/bin/java java /usr/java/latest/bin/java 20000
This tells CentOS that any time the
java command is used, it actually refers to the binary contained within the Oracle JRE directory and not the OpenJDK binary. The flavor of Java used by the system can be changed any time running the following command:
$ alternatives –-config java
There are 2 programs which provide 'java'. Selection Command ----------------------------------------------- 1 /usr/lib/jvm/jre-1.6.0-openjdk.x86_64/bin/java *+ 2 /usr/java/latest/bin/java Enter to keep the current selection[+], or type selection number:
Downloading the example code
You can download the example code files from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the files e-mailed directly to you.
In this case, Oracle JRE, which we just installed, is shown to be the active one. If Oracle JRE is not currently selected, then simply enter the number matching the
/usr/java/latest/bin/java entry in your list.
An important thing to note here is the command entry for Oracle JRE. Notice how it matches the path that we used for the
alternatives --install command. This is important as it means that we can now install future versions or updates of Oracle JRE without having to run the
alternatives command again. Where possible, you should use the
/usr/java/latest/bin/java path to reference Java, for example, the
JAVA_HOME environment variable.
We can now test whether our system is using Oracle JRE issuing the following command:
$ java –version
If all goes well, we should see the following response:
java version "1.7.0_51" Java(TM) SE Runtime Environment (build 1.7.0_51-b13) Java HotSpot(TM) 64-Bit Server VM (build 24.51-b03, mixed mode)
Your version numbers might differ, but the rest should be the same; most importantly, we do not want to see the word OpenJDK anywhere.
If you target Windows Server in your production environment, life is a little simpler than it is for the users of Linux. For the purposes of this book, we will use Windows Server 2008 R2 SP1 Standard Edition, however other versions of Windows Server that can have Java installed should also work fine.
At this point, we have a decision to make about which JRE installer to download, 32-bit or 64-bit. Making the right decision now is important as the choice of 32-bit versus 64-bit will have consequences later when configuring GeoServer. In the next section, we will discuss the installation of Apache Tomcat, which has a dependency on Java, in order to run GeoServer.
In the Windows environment, the Apache Tomcat installer will automatically install a 32-bit or 64-bit Windows Service based on the installed Java. So, a 64-bit installation of Java will mean that the Apache Tomcat service will also be installed as 64-bit.
The three factors influencing the choice of a 32-bit or 64-bit Java are:
The architecture on which you run Windows
Java VM memory configuration considerations
The use of native JAI and JAI Image I/O extensions
Hopefully, the first reason is self-explanatory. If you have a 32-bit version of Windows installed, you can only install a 32-bit version of Java. If you have a 64-bit Windows installation, then you can choose between the two versions. We install to Windows Server 2008 R2 SP1, which is only available in 64-bit; this means that the processor architecture or Windows is not a limitation. In this case, the decision now comes down to the memory configuration and use of native JAI and JAI Image I/O extensions.
The memory consideration is an important decision since a 32-bit process, irrespective of whether it runs on a 32-bit or 64-bit processor architecture, can only address a maximum of 2 GB memory. Therefore, if we want to maximize the available server memory, we will need to consider using the 64-bit version of Java. However, the JAI and JAI Image I/O extensions are only available on the Windows platform as 32-bit binaries. If we choose the 64-bit Java, then we will not be able to use the extensions, which can be an issue if we plan on using our server to provide predominantly raster datasets. The native JAI and JAI Image I/O extensions can provide a significant performance increase when performing raster operations, in other words, responding to WMS requests.
Getting the most out of a production environment is as much about maximizing resource utilization as anything else. If we have a server with lots of memory, we can use the 64-bit Java and allocate it a large chunk of memory, but then the only real advantage this provides is that it will allow us to do more concurrent raster operations. The maximum number of concurrent requests will still be limited by other factors, which might not be the most efficient use of server resources. An alternative approach is to scale-up by running multiple instances of GeoServer on the server. This is discussed in more detail later in this chapter. Scaling-up means that we can maximize the usage of server resources (memory) without compromising on our ability to utilize the native JAI and JAI Image I/O extensions.
From the Oracle download page, choose the 32-bit Java installer, which at the time of writing is
jre-7u51-windows-i586.exe, and save it to a local disk.
Open the folder where you saved the file, right-click on the file, and choose the Run as administrator menu item:
Accept all Windows UAC prompts that appear and wait for the Java installation wizard to open.
The installer will want to install Java to a default location, usually
C:\Program Files (x86)\Java\jre7, but if you want to install it to a different folder, make sure to tick the Change destination folder checkbox placed at the bottom of the dialog:
Specify the location you want to install to, and then click on the Next button; the installation starts.
If the installation is successful, you will be greeted with the following screen:
At the time of writing this book, the most recent version of Apache Tomcat is 8. At the moment, there is limited testing of GeoServer running inside Apache Tomcat 8, which means that we should avoid using it, at least for now. Instead, we will use the latest version of Apache Tomcat 7, which is currently 7.0.50. The download page for this version is http://tomcat.apache.org/download-70.cgi#7.0.50.
As with all the Linux variants, CentOS has a package management system that can be used to install software, including Apache Tomcat. However, quite often, the packaged software is several versions behind the current version. Unlike other software running on Linux, Tomcat does not actually require compiling, and so installing it directly from Apache is not much of a challenge. Perform the following steps to install Apache Tomcat on CentOS:
First, we need to download the Tomcat package to our system. Go to the download page (http://tomcat.apache.org/download-70.cgi#7.0.50) and find the download link for the
tar.gzpackage under the Core entry. With the location of the link, we can download the file with the following command:
$ wget http://www.mirrorservice.org/sites/ftp.apache.org/tomcat/tomcat-7/v7.0.50/bin/apache-tomcat-7.0.50.tar.gz
Once the download is complete, we need to think about where we want to place the installation on the system. The most common location seems to be
/opt, which seems as good a place as any. Extract the Tomcat files using the following command:
$ sudo tar –xvzf apache-tomcat-7.0.50.tar.gz –C /opt
The contents of the tarball will be extracted to
/opt/apache-tomcat-7.0.50/, which will now become our Tomcat home directory. These are the bare minimum steps required to get Tomcat installed, so you can now issue the following command and Tomcat will happily start:
$ sudo ./opt/apache-tomcat-7.0.50/bin/startup.sh
shutdown.shon the last command to shut Tomcat down if you just started it.
This is interesting, but actually not particularly useful in the context of a production environment. In a production environment, we need to be able to set memory parameters for JVM, have Tomcat run as a service on startup, and run the Tomcat service using a user with limited privileges.
Security is a key consideration for any production environment, and wherever possible, the applications and services should run using user accounts with just the right level of privileges for them to perform their functions. To adopt this best practice, we will now create a user account under which we can run the Tomcat service:
At your command line, enter the following:
$ sudo groupadd tomcat $ sudo useradd –s /bin/bash –g tomcat tomcat
The first command creates a new user group called
tomcat. The second command creates a new user called
tomcat, adds this user to the
tomcatgroup, and sets its shell to
Now that we have a
tomcatuser, we need to set the ownership of the Tomcat installation folder to this user:
$ sudo chown –Rf tomcat:tomcat /opt/apache-tomcat-7.0.50/
Now we are ready to create a service control script that will allow us to start, stop, and reload the Tomcat application. To do this, we need to create a service controller script and then register this script with an appropriate run level so that CentOS will start the service on boot:
$ cd /etc/init.d $ sudo vi tomcat-1
The preceding commands will enter the services directory on CentOS and create a blank script called
tomcat-1. The name of the script is not important. However, as we will see later when scaling Tomcat in production, we might want to instantiate multiple services, and so should come up with a suitable naming convention to keep track of them. In this case, we use the convention,
nwill be an incremented number. The
vicommand will start the vim text editor with an empty file; replace this with whatever your favorite Linux text editor is.
In the text editor, enter the following script:
#!/bin/bash # description: Tomcat 1 Start Stop Restart # processname: tomcat-1 # chkconfig: 234 20 80 JAVA_HOME=/usr/java/latest export JAVA_HOME PATH=$JAVA_HOME/bin:$PATH export PATH CATALINA_HOME=/opt/apache-tomcat-7.0.50 JAVA_OPTS="-server –Xmx1024m –Xms512m –XX:MaxPermSize=128m" export JAVA_OPTS case $1 in start) /bin/su tomcat $CATALINA_HOME/bin/startup.sh ;; stop) /bin/su tomcat $CATALINA_HOME/bin/shutdown.sh ;; restart) /bin/su tomcat $CATALINA_HOME/bin/shutdown.sh /bin/su tomcat $CATALINA_HOME/bin/startup.sh ;; esac exit 0
There is quite a lot going on in this script, so let's break it down a little. The first four lines beginning with a hash (
#) are settings for how the script is run. The last line in this group indicates the run levels that this service will operate under (
234) and the stop and start priorities (
80). This information tells the
chkconfig command how to run the service.
Next, the script will set environment variables to tell the system where to find Java (
JAVA_HOME), making the
java command accessible on the command line (
PATH) and setting the Tomcat directory (
CATALINA_HOME). Next, we set an environment variable called
JAVA_OPTS, which provides parameters to run JVM. This is where we can specify the memory configuration for our GeoServer instance. There is a discussion on how to determine the most appropriate memory settings for your server later in this book; for now, we will use settings that are good for an all-rounder instance of GeoServer.
The following table describes what each of these parameters are and why they are set:
The final section of the script is a case statement that will perform different actions according to the first parameter (
case $1) passed to the script. This can be one of start, stop, or restart. In each case, the Tomcat
shutdown.sh scripts are executed.
$ sudo chmod 755 tomcat-1
Once the script is executed, we can register it in CentOS as a service. The
chkconfig utility is used to register the script as a service:
$ sudo chkconfig --add tomcat-1 $ sudo chkconfig --level 234 tomcat-1 on
The first line adds our script, and the second line sets the runtime levels for it. We can check the configuration to make sure it is registered correctly:
$ sudo chkconfig --list tomcat-1 tomcat-1 0:off 1:off 2:on 3:on 4:on 5:off 6:off
If all goes well, levels
4 will be marked as
on, with all other levels marked
off. From this point onward, every time our server restarts, it will automatically run the
tomcat-1 service, thereby giving us Tomcat on each boot.
We should now check that the script works as expected, trying each of the following commands in turn:
$ sudo service tomcat-1 start Using CATALINA_BASE: /opt/apache-tomcat-7.0.50 Using CATALINA_HOME: /opt/apache-tomcat-7.0.50 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.50/temp Using JRE_HOME: /usr/java/latest Using CLASSPATH: /opt/apache-tomcat-7.0.50/bin/bootstrap.jar:/opt/apache-tomcat-7.0.50/bin/tomcat-juli.jar $ sudo service tomcat-1 restart Using CATALINA_BASE: /opt/apache-tomcat-7.0.50 Using CATALINA_HOME: /opt/apache-tomcat-7.0.50 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.50/temp Using JRE_HOME: /usr/java/latest Using CLASSPATH: /opt/apache-tomcat-7.0.50/bin/bootstrap.jar:/opt/apache-tomcat-7.0.50/bin/tomcat-juli.jar Using CATALINA_BASE: /opt/apache-tomcat-7.0.50 Using CATALINA_HOME: /opt/apache-tomcat-7.0.50 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.50/temp Using JRE_HOME: /usr/java/latest Using CLASSPATH: /opt/apache-tomcat-7.0.50/bin/bootstrap.jar:/opt/apache-tomcat-7.0.50/bin/tomcat-juli.jar $ sudo service tomcat-1 stop Using CATALINA_BASE: /opt/apache-tomcat-7.0.50 Using CATALINA_HOME: /opt/apache-tomcat-7.0.50 Using CATALINA_TMPDIR: /opt/apache-tomcat-7.0.50/temp Using JRE_HOME: /usr/java/latest Using CLASSPATH: /opt/apache-tomcat-7.0.50/bin/bootstrap.jar:/opt/apache-tomcat-7.0.50/bin/tomcat-juli.jar
If everything works as expected, we will see a similar output. Start the Tomcat service again if it is not already running, and then navigate to the server's IP address or the URL. We should get the Tomcat web page like the one shown in the following screenshot:
Congratulations! We now have CentOS 6.3 running Java and Apache Tomcat with the Tomcat service automatically, starting each time the server boots. Go ahead and restart the server to check that the Tomcat service starts automatically.
The default configuration of Apache Tomcat does not have any user configured for access to the web management portal. If you want to have the ability to manage your instance of Tomcat using the web management application, then you will need to configure access.
Tomcat maintains a simple user access database in the form of an XML configuration file in the
conf directory. To enable access to the manager web application, you must edit the user database or create one if it does not already exist. The file is called
tomcat-users.xml and has a very simple structure. Here is a very basic example of a
<?xml version="1.0" encoding="utf-8"> <tomcat-users> <role rolename="manager-gui" /> <user username="r2d2" password="5t4rW4r5" roles="manager-gui" /> </tomcat-users>
The structure of this file is very simple. First, you define the name of a role; in this case, the role name is specific to the web manager application as it expects one called
manager-gui. Next, you create a
<user> element and specify a username, password, and comma-separated list of roles that the user belongs to. Once you create the necessary entries for all the users, you want to grant access to the web manager application, and then you will need to restart the Tomcat service:
$ sudo service tomcat-1 restart
Once again, Windows users get the convenience of an installation wizard to take care of installing Tomcat. For the Windows installation package, choose the 32bit/64bit Windows Service Installer option. Download the installation file to a directory on your local hard drive.
To install Tomcat, perform the following steps:
For Tomcat 7.0.50, the downloaded installation file should be
Open the folder where you saved the file, right-click on the file, and choose the Run as administrator menu item:
Use the Next button to move through the installation wizard until you reach the Choose Components page. For a production system, we want to avoid any unnecessary installation, so make sure that the Documentation and Examples boxes are not ticked. Under the Tomcat branch in the components list, we want to make sure the Service Startup box is ticked. This will ensure that the Tomcat service starts when Windows starts, which is very useful in cases when the server has to be rebooted. Finally, we need to tick the box for Native, which will make use of the native APR for better performance and scalability.
Click on the Next button to move on to the configuration page. This page is where we will set the configuration for Tomcat and Windows Service. For the first installation, we can leave the default settings for ports as they are. Enter a username and password for the web administration pages:
Before moving on to the next step, an important change to the default configuration is the name of the Windows service. If we want to maximize server resources, then we will want to scale-up on the server by running more than one Tomcat service. In this case, we need to have a naming convention to distinguish between them, so we will use Tomcat7-1 and adopt a naming convention of
nis an incremented number to identify the instance.
Clicking on Next will move to the Java environment page that should have automatically selected the installation of Java we performed earlier. If it did not, you can manually browse to your JRE installation folder.
Clicking on Next will move to the page where we can specify the installation folder. A default will be provided, which will be the combination of a default installation folder, with the Windows Service name set in step 5 appended. You can either accept the default or specify your own. For simplicity, we will set the installation folder to
Once the installation is complete, the final wizard page will allow us the choice to start Tomcat. Uncheck the box marked Start Tomcat Service so that Tomcat does not start when we exit the installer.
The Windows version of Tomcat comes with an application called Monitor Tomcat, which starts automatically each time you log on to Windows. It is a System Tray application that allows quick access to monitor and manage the running Tomcat service.
Notice the icon in the top-left corner of System Tray; this is the Monitor Tomcat application and its icon tells us that Tomcat is not currently running (indicated by the red square in the middle).
If the Tomcat service runs, it displays a green triangle on its side, like a "play" symbol. If we right-click on the Monitor Tomcat application icon, we get a context menu as shown in the following screenshot:
The context menu provides us with the ability to access the Tomcat service configuration and allows us to stop and start the service without the need to go through the normal Windows service applet. Of course, Tomcat still runs as a normal Windows service, so there is nothing stopping us to manage it in the normal way; the Monitor Tomcat application is just a convenience tool.
Before we start the Tomcat service to check our installation is alright, we must configure the memory settings that Tomcat will use for Java VM. Right-click on the Monitor Tomcat application icon and select the Configure… menu item to open the Tomcat service configuration dialog. Once it is open, click on the Java tab at the top:
The Java tab allows us to set options that control the way Tomcat starts Java VM; the most important of these, from our perspective, is the memory configuration. Memory settings can be specified in one of the following two ways:
Parameters in the Java Options textbox
Entering values in Initial memory pool, Maximum memory pool, and Thread stack size
The choice is merely one of the preferences as both will achieve the same effect. My personal preference is to put everything into the Java Options textbox as it is good to remind oneself of the correct Java option parameter names, especially if you have a mixed Linux/Windows server environment.
The actual values to use for memory settings are subjects that we will cover later in this book, and we will very much depend on how you intend to use your GeoServer in production. For example, if you only intend serving vector data (through WFS), then GeoServer requires very little by way of memory allocation. For now, we will set the memory to some good defaults for an all-rounder GeoServer. Click on the Java Options textbox and scroll to the last parameter, press Enter to start a new line, and then enter the following parameters:
-Dserver -Xmx1024m -Xms512m -XX:MaxPermSize=128m
These parameters and what their values mean are described in the table given in the Running Apache Tomcat as a service section of this chapter.
With the Java options set, we are now ready to fire up the Tomcat service and check everything as is expected. Click on the General tab, then on the big Start button, and cross your fingers as the service starts up. If everything works, then the Start button will be disabled and the Stop button will be enabled. If the Start button is enabled again, and the Stop button remains disabled, then unfortunately something is wrong. Check that all the option parameters are correct and then try again. If you still don't get the service starting, check the Tomcat logs to try and figure out why.
If all goes well, we should be able to open a browser window, navigate to
http://localhost:8080/, and get the Tomcat 7 web page, as shown in the following screenshot:
We are getting there for a basic configuration of GeoServer, which we can use as a basis to architect our production environment for high-availability, failover, and scalability. Now we need to deploy GeoServer into Apache Tomcat, which is happily a straightforward process.
We will utilize Apache Tomcat's auto-deploy feature that allows us to copy the GeoServer WAR (Web Archive) file directly to
appBase of a running Tomcat instance. Tomcat will detect the presence of the WAR file, and then deploy it ready for use.
First, we need to download the WAR file from the GeoServer download page at http://geoserver.org/release/Stable. At the time of writing, the current stable version of GeoServer is 2.5.2:
Deployment of GeoServer on CentOS is a very straightforward process, thanks to the way Tomcat is architected. WAR files can automatically be deployed by copying them to a specific location in the Tomcat home directory.
Download the WAR file to a location on your system, for example, your home directory:
$ cd ~ $ wget http://sourceforge.net/projects/geoserver/files/GeoServer/2.5.2/geoserver-2.5.2-war.zip
The WAR file that we want to deploy to GeoServer is contained within the downloaded ZIP file, so we need to extract this from the Tomcat
$ sudo unzip geoserver-2.5.2-war.zip *.war –d $CATALINA_HOME/webapps/
This command will only extract the
geoserver.war file from the ZIP file and place it in the Tomcat
appBase directory. Tomcat will then autodeploy the WAR file, and you should see a
geoserver directory appear.
The following steps are required to deploy the GeoServer WAR file in Tomcat:
Download the WAR file to a location on your system, for example, the
Downloadsfolder within your home directory.
Double-click on the
geoserver-2.5.2-war.zipfile to open it in Windows Explorer (assuming you do not have another ZIP application installed).
Drag and drop the
geoserver.warfile from the ZIP folder to the
webappsfolder in your Tomcat service home directory. If you followed the steps to install Tomcat on Windows, then this directory will be
We should now have a basic configuration of GeoServer deployed inside an Apache Tomcat instance. Test that GeoServer was successfully deployed by opening a web browser and navigating to the GeoServer administration interface:
http://[your server address]:8080/geoserver
If everything worked as expected, then we should be presented with the GeoServer administration interface's front page:
One of the best things about GeoServer, apart from the quality of the software and community, is the fact that because it is free, you will not be hampered by cost considerations when increasing the capacity of your production environment. Unlike the Commercial-Off-The-Shelf (COTS) software that commonly utilizes a licensing model based on the number of physical or virtual cores, the software runs on.
Since there is no financial implication (in terms of software licensing) on running multiple instances of GeoServer, the only limitation will be the amount of infrastructure you can afford to implement. With the growth in cloud computing and Infrastructure as a Service (IaaS) providers such as Microsoft (Windows Azure) and Amazon (EC3), the costs of implementing large infrastructures is becoming more reasonable.
Performance can be gained by maximizing the usage of resources within your production environment and/or by increasing the capacity through additional nodes. Load balancing traffic across the environment to spread the load will also aid in ensuring that the environment performs well. Increasing the number of nodes within the environment will present an opportunity to set up for high availability. This is when one or more nodes in the environment are reserved to take over if the primary nodes fail. Usually, this can be handled by the load balancer by intelligently switching traffic to a reserved node when it detects that one or more primary nodes failed.
Scaling vertically, also known as scaling up, is when additional resources are added to a single (physical or virtual) node. In other words, this is when you create more than one instance of GeoServer to run on the same physical or virtual server. The following diagram depicts scaling vertically:
The available resources on the server are maximized by running multiple instances of GeoServer. Consistency of data is maintained across each of the instances by all of them sharing a common data directory, either located on the node itself or elsewhere on the network.
Traffic is managed across the GeoServer instances by a load balancer that can be a physical one in the network or even a software-based one.
Scaling horizontally, also known as scaling out, is when you add additional nodes (physical or virtual) to your environment. Each additional node can have an instance of GeoServer running on it. The following diagram depicts scaling horizontally:
In a scaled-out architecture, the data directory for GeoServer is shared across the additional nodes to ensure consistency of the configurations. With this approach, you can choose to place the shared data directory on one of the nodes and allow access to the additional nodes, or you can choose to have a separate server to hold shared data such as a Network Attached Storage (NAS) device.
If you configure multiple instances of GeoServer to provide resilience to your infrastructure, high availability, or failover, then best practice is not to place your shared data directory on one of the nodes running GeoServer. If this node fails, then all other nodes will lose their data connections. For proper resilience, the shared data server should also be replicated.
To really get the best performance from your production environment, it is worth considering scaling GeoServer both vertically and horizontally. Increase the capacity of your environment through additional nodes, and then maximize the resources on each node by running multiple instances of GeoServer. The following diagram depicts scaling vertically as well as horizontally:
In this architecture, traffic to each of the GeoServer instances running on each node is managed through a physical load balancer on the network. The load balancer can be configured to register one of the GeoServer nodes as the failover node, ensuring continuity of service should one or more of the primary nodes fail.
Once again, a shared data directory is used across the nodes to ensure consistency, but in this case, it will definitely make sense to keep the directory on a separate server instance.
You might have spotted a common thread running through each of the scenarios outlined. In all cases, multiple instances of GeoServer are implemented, and in the case of scaling up, these instances are running on the same node.
Setting up multiple GeoServer instances on a single node is actually quite straightforward and will involve you creating several instances of the Tomcat installation. In the following examples, we will configure an additional instance of GeoServer for CentOS and Windows Server 2008. However, you can apply the same principle to create as many instances as you want, but bear in mind the memory configuration of your server, making sure that you do not add more instances than your resources will allow. Also, bear in mind the number of processing cores available; too many instances will overburden the processor, and any gain in adding the instance will be lost through decreased performance. Typically, you should not consider adding more than four instances per server.
$ sudo cp –R /opt/apache-tomcat-7.0.50/ /opt/apache-tomcat-7.0.50-2
This command will copy our installation directory to the same location and append
2 to the end. The name and location of the directory does not matter; just ensure that it has a different name so that you can distinguish it from others. Next, we need to make the
tomcat user the owner of the new directory:
$ sudo chown –Rf tomcat:tomcat /opt/apache-tomcat-7.0.50-2/
Then we need to configure the Tomcat instance so that it can co-exist with other instances. This involves altering the
server.xml file stored in the
conf folder of the copied installation. Edit the file with your favorite text editor, and look for the line containing the following:
<Server port="8005" shutdown="SHUTDOWN">
Change the value of the port attribute to
8006 by incrementing it by 1. Further down the file, look for the line containing:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" />
Change the value of the
port attribute to
8081 by incrementing it by 1, save the file, and exit the text editor. We also need to change the value of
redirectPort, again incrementing it by 1 to make it
8444. What we just did has changed the ports on which the Tomcat service will listen for connections. Failing to do this will generate an error when we try to start the Tomcat service. If we want to add more Tomcat instances, we just need to follow the same process; increment each value by 1 again.
$ sudo mkdir /mnt/share $ sudo cp –R /opt/apache-tomcat-7.0.50/webapps/geoserver/data/ /mnt/share/geoserver-data $ sudo chown –Rf tomcat:tomcat /mnt/share/geoserver-data/
You might be wondering why we just copied the data directory out to a different location. This is an important step for two reasons:
It is necessary to ensure that both instances of GeoServer deliver the same data and services
It makes upgrading GeoServer much simpler
The last point is an important one. Even if we only run a single instance of GeoServer, it is a good practice to place the data directory outside of the GeoServer installation. When we decide to upgrade, we can do so by simply deploying a new WAR file without having to back up and restore the original data directory.
Now we can make a new service for our newly configured instance:
$ sudo cp /etc/init.d/tomcat-1 /etc/init.d/tomcat-2
Next, we need to make some changes to the service script to tell each GeoServer instance where the data directory is located, and we will also control the name and location of the default logfile for GeoServer. Edit the
tomcat-2 script files in your favorite text editor, and add the following lines near the start:
GEOSERVER_DATA_DIR=/mnt/share/geoserver-data export GEOSERVER_DATA_DIR
This line sets an environment variable for our external data directory. Next, add the following lines:
GEOSERVER_LOG_LOCATION=$GEOSERVER_DATA_DIR/logs/geoserver-1.log export GEOSERVER_LOG_LOCATION
This sets another environment variable, but this time it tells GeoServer what to call the logfile that will be generated. This is another important aspect of running multiple instances of GeoServer, and it is essential to avoid clashes on the logging.
Do the same for both the service scripts, but change the name of the logfile to suit each instance. Now we just need to register the second service script so that it can be controlled:
$ sudo chkconfig --add tomcat-2 $ sudo chkconfig --level 234 tomcat-2 on $ sudo service tomcat-1 restart $ sudo service tomcat-2 start
GeoServer instance 1:
http://[your server address]:8080/geoserver
GeoServer instance 2:
http://[your server address]:8081/geoserver
Once again, life is a little simpler in the world of Windows. All we need to do is configure some environment variables to set the location of the shared data directory and the name and location of the logfile, and then create a new service instance. First, copy the current GeoServer data directory (
C:\Tomcat7-1\webapps\geoserver\data) to a location outside of the container, for example,
D:\Data\geoserver-data. Then, click on the Windows Start button, right-click on Computer, and choose the Properties menu option:
In the System Properties dialog that opens, click on the link at the left-hand side labelled Advanced system settings, and in the dialog box that opens, click on the Advanced tab. Click on the button labelled Environment Variables… to open a new properties dialog:
Click on the New button in the System variables group, and then enter the details shown in the preceding screenshot. Click on Ok to dismiss all of the dialogs. We now have an environment variable to tell GeoServer where to find its data directory.
Next, we need to create a new instance of the Tomcat service. To do this, we just need to rerun the installation file that we downloaded originally. Work through all of the pages until you reach the Configuration Options page:
On this page, we need to change the settings for the ports by incrementing the default values by 1, for example, HTTP/1.1 Connector Port will be
8081 instead of
8080. We also need to change the default value of Windows Service Name, in this case, we continue with our naming convention of incrementing each instance by 1. Click on Next to check whether the Java installation directory is correct, and then click on Next again to specify where we want to install the files. Change the installation location so that it points to
Now we need to use the Tomcat Monitor application to control the new service. Copy the same values for the Java options, but also include an additional parameter to tell GeoServer where to create its logfile this time:
We created a second instance of Tomcat, so we just need to deploy the
geoserver.war file to it by copying it into the
C:\Tomcat7-2\webapps folder and letting Tomcat perform autodeploy when it starts up.
Remember to include
–DGEOSERVER_LOG_LOCATION in the original Tomcat instance Java options, and specify the name of a logfile so that it can be distinguished. Then, restart both the new services. If everything works as expected, you can open a browser and navigate to:
GeoServer instance 1:
GeoServer instance 2:
We now have a basic configuration of GeoServer that we can take forward into a production environment. This basic configuration will be the basis for exercises in the remainder of this book, and over the course of the book, we will build a well-configured and high-performing instance(s) of GeoServer.
In this chapter, we also had an introduction to the concepts of scalability and configuring GeoServer so that it can be highly available and/or high performing. These basic concepts will give you a good understanding of the concepts and enable you to start to consider and design the implementation of a GeoServer cluster within an enterprise environment. With the barrier of software licensing costs removed through the use of GeoServer, the only limitation on the power of your production environment will be how much you can afford to spend on infrastructure.
Creating a high-performing installation of GeoServer is as much about data optimization as it is about Java VM configuration and clever architecture. In the next chapter, we will look at how we can optimize raster data for high-performance rendering.