Technical Report 2013 HA Set up with GeoServer Ing. Alessio Fabiani Ing. Andrea Aime Ing. Simone Giannecchini. Date 22/05/2013 Version 01.07
Contents Record of Changes... 4 Introduction... 5 HA set up for GeoServer... 6 Internal Configuration Limitations... 6 Data Directory... 6 In Memory Configuration... 6 Coping with GeoServers Limitations... 7 Clustering... 7 Residual limitations... 8 GeoWebcache Optimal Deployment Guidelines... 9 GeoWebCache 1.3.x... 9 GeoWebCache 1.4.x... 11 GeoWebCache CACHE DIR... 12 Vertical Cluster Set-up with Apache Tomcat and GeoServer... 13 Apache Tomcat configuration for vertical clustering... 15 Windows Vertical Cluster Configuration... 17 Step 1: Basic Customization for instances environment variables... 17 Step 2: Customization for instances environment variables related to GeoServer... 17 Step 3: Customization for instances environment variables related to JVM options... 18 Manual start/stop of instances VS installation as services... 19 JK Load Balancer Setup with IIS... 19 Annex A : Cluster Basic Authentication with IIS... 31 Page 2 of 32
Illustration 1: Cluster Use Case... 13 Illustration 6: IIS Cluster Deploy Diagram... Errore. Il segnalibro non è definito. Page 3 of 32
Record of Changes Page 4 of 32
Introduction Objective of this document is to provide suggestions about how to best exploit the HW resources required with respect to the various software components of interests, namely, Apache Tomcat, GeoServer, and GeoWebCache in order to, on a side, implement an High Availability set up for each one of them to minimize the possibility of a service downtime and on the other side to achieve the maximum possible scalability in terms of number of concurrent requests that can be served for the unit of time with an acceptable response time. In the remaining part of this document we will assume that the reader possesses a decent knowledge of what the various software components do as well as the protocols they support. We will delve only into specifics related to the topic being discussed, that is properly dimensioning the deployment. In order to obtain reproducible numbers for the dimensioning of a host for GeoServer/GeoWebcache and Apache Tomcat capable to serve a certain number of concurrent requests, we have setup a test environment and launched different stress-test against it, in order to test its limits. Page 5 of 32
HA set up for GeoServer Clustering GeoServer is required to implement an Highly Available set up as well as in order to achieve superior scalability. Regardless of the reason why one intends to create a clustered deployment for GeoServer there are a few limitations that must be taken into account and where possible worked around, let us now briefly introduce and discuss them. Internal Configuration Limitations With the term GeoServer internal configuration we refer to the information that GeoServer manages and persists in order to perform its job. This information refers to, as an instance: Where the data is located How to connect to and serve the data How to manage incoming requests and so on. Long story short, all the information that GeoServer needs for its proper working are represented within the internal configuration therefore every time we configure a new dataset or we change the way we want WMS to behave we interact with the internal configuration. Data Directory Currently the default persistence method for the internal configuration consists in a set of XML files contained inside a well-known directory called data directory 1. This means that whenever we change the internal configuration and we persist the changes such changes are persisted in these XML files, moreover, whenever we need to load the internal configuration we need to read these files. Following this, it becomes obvious that if we want to cluster multiple instances of GeoServer we must somehow share the same data directory in order to make sure that all the instances are identical. This can be achieved by either having the multiple instances share the same location for the GEOSERVER_DATA_DIR variable or to act at a lower level and use file system replication to keep different locations in synch. In Memory Configuration Besides the fact that the internal configuration for GeoServer is stored by default in XML files, it is worth to point out that currently the persistence subsystem loads thoroughly in memory at start up ( or reload ) the entire internal configuration as it is defined inside the XML files in the data directory assuming, after that time, that the configuration resides actually in memory. The infrastructure within the GeoServer codebase that manages the in memory copy of the internal configuration is called catalog (which should not be confused with the OGC concept of catalog) and contains the GeoServer s internal object model where all the information of the internal configuration are 1 http://docs.geoserver.org/stable/en/user/datadirectory/data-dir-setting.html Page 6 of 32
represented by in memory java objects and relations; access to the catalog is guarded via specific locks from both the user interface as well as from the REST interface in order to ensure that proper access it it s guaranteed in every moment. The limitation posed by the fact that the internal catalog is kept pinned in memory by the GeoServer is relevant especially in a clustered environment since whenever a configuration change is made in one instance of GeoServer the other instances should not be aware of the change unless a full configuration reload is issued, moreover the internal configuration and catalog of GeoServer during a configuration reload is in an inconsistent state until when the loading has been performed and all the configuration objects have been created. Along the same line it is worth to point out that when working with a cluster of GeoServer instances whenever we make a configuration change in an instance of the cluster we must reload the configuration of the other instances and this process becomes slower as we the configuration grows that is as more data is deployed. Coping with GeoServers Limitations In the following we highlight a two steps approach to cope with GeoServr s limitations with respect to the ability to create a pool of clustered instances serving the same dataset. Clustering Shared data directory The various instances of GeoServer deployed in the cluster should share a single data directory, hosted on a shared file system and made available. Logging Configuration GeoServer s logging subsystem is quite flexible as we can decide whether or not we log onto the output stream (which usually means the internal logging mechanism for the enclosing Application Server as well as the location of the specific GeoServer s own log file where only the log coming from GeoServer is written. By default GeoServer s log location is relative to the data directory, however regardless of its location when multiple GeoServer share the same data directory it is crucial to instruct them to log to different locations, this can be achieved via the GEOSERVER_LOG_LOCATION configuration tweak as described here. Setting this environmental variable to different locations for each GeoServer instance (i.e. Java process) allows us to properly configure each of them to write to a different log file avoiding any problem. Page 7 of 32
Integrated GeoWebCache Configuration Standard GeoServer comes with an integrated GeoWebCache instance to achieve map acceleration for tile based requests without the need for installing an additional piece of software. This capability is very good for small set up but can be problematic in larger set up where clustering is crucial (we will discuss why this happens in the next sections. Residual limitations Once all of the above configuration changes are completed the cluster is ready for production. If nothing in the configuration ever changes, or changes only rarely, we ve got a good production environment. In this setup it s advisable to setup an offline GeoServer working off a copy of the cluster data directory (staging area), make changes until a new satisfactory configuration layout is reached, and then propagate the changes to the production cluster with the following steps: Copy the data directory from the staging area to the production one Issue the reload REST configuration command on each node in the cluster so that the new configuration gets loaded on disk This approach starts showing its limitations when any of the following situations apply: Frequent configuration changes that need to be applied right away to the entire cluster The configuration contains many layers (hundreds or more) which implies a long reload time. During the reload phase the server is not really able to respond properly to OGC requests as the configuration is in an inconsistent and incomplete state Page 8 of 32
GeoWebcache Optimal Deployment Guidelines GeoWebCache is a tile caching server exposing, among others, the OGC WMTS procotol, with ability to gather tiles from remote WMS servers. GeoWebCache has a special relationship with GeoServer, in that it is also a standard plugin with a tight integration with the GeoServer GUI and WMS operations, making it easier to use and speeding up the creation of new tiles. The usage of stand-alone versus the integrated solution has pros and cons: The workload of a tile cache is completely different from the one of OGC services, it involves an amount of concurrent requests which is orders of magnitude higher, with normally low CPU usage and high disk I/O, from this point of view, having a separate GeoWebCache is preferable to avoid the WMTS load to overwhelm the other OGC services The configuration of a separate GeoWebCache instance duplicates the work already done in GeoServer for the layer configuration, and requires manual intervention every time a new layer is configured in GeoServer. Moreover, a stand-alone GeoWebCache needs to ask GeoServer for the metatiles in some image format, that it will have to decode, slice in tiles, and save on disk, whilst an integrated version can directly tap into the in memory image generated by GeoServer and perform the slicing directly without having to go through an intermediate encoding/decoding operation. These considerations favor an integrated GeoWebCache approach. From the point of view of high availability, two or more GeoWebCache instances should be set up in order to share the same disk tile storage, which is required to be located on some network file system. It has to be noted performance wise clustering is not normally required, it is indeed well known that a single GeoWebCache can easily flood a Gigabit line, as a result there is no real need to distribute the load among various nodes, the gain obtained from clustering GeoWebCache is merely high availability. Different versions of GeoWebCache require different clustering strategies. Let s consider them separately. GeoWebCache 1.3.x GeoWebCache 1.3.x is the version integrated in the GeoServer 2.2.x series. Clustering wise GeoWebCache 1.3.x has two significant limitations: The meta-store system is using a H2 embedded database The disk quota system using a JE embedded database Both of them acquire an exclusive lock on the file system on startup and thus prevent other GWC instances from starting up in parallel against the same physical tile cache. Meta-store wise the GWC documentation shows up to setup a clustered H2 system, but we suggest against said solution for a few reasons: Page 9 of 32
This setup is poorly tested, we re un-aware of important production installations using it H2 managed database has been reported to get corrupted in face of abrupt shutdowns and network issues, resulting in the inability to recover the database and thus data loss Disk quota wise the system has been designed and tested on a single JE instance, while it s theoretically possible to setup a JE cluster the process is laborious and would require changes to the current code in order to allow the cluster to function. Giving up the metastore is possible, as it s not required for GWC to function, but it implies losing a couple of functionalities: The ability to expire tiles automatically based on their age The ability to use extra WMS parameters to setup multiple caches for a single layer, for example, allowing the cache to handle multiple values of the STYLE parameter for a given WMS layer Giving up the quota store is also possible, of course this comes with the inability to control how big the tile cache grows on disk. Moreover, it s not possible to have multiple GWC instances all writing to the same cache, as they would not be able to synchronize themselves properly, in particular: The same tile could be written in parallel by two GeoWebCache instances, depending on the file system default locking strategies this might result in failure of one of the instances to write (which will result in the corresponding tile request to fail), or file contents corruption, whilst on selected file systems this might actually work fine The same tile could be requested on two instances in such a way that one instance reads and serves back the tile while another one is still in the process of writing it, resulting in corrupted data being sent back to the client Given the above limitation a clustered GeoWebCache 2.3.x installation should: Disable the disk quota and metastore plugins Setup multiple stand-alone GWC instances and have the load balancer use a fallback strategy, so that only one of them can read and write on the disk at a given time A single GeoWebcache can still be kept inline in the master GeoServer in case large seeding workloads need to be scheduled without affecting the whole cluster operation. In order to speedup interactive tile seeding the GeoWebCache tile layers should be setup to ask GeoServer maps in TIFF format, over the local network it is the format that has proven to be the fastest to Page 10 of 32
encode/decode, up to 50% faster compared to PNG (it has a larger size, but that s not normally a concern over a LAN). GeoWebCache 1.4.x GeoWebCache 1.4.x received a number of improvements that makes it suitable for active/active clustering, in particular: The metastore has been removed and replaces for a mechanism embedded in the tile cache file system itself The disk quota subsystem can now use a centralized database, Oracle or PostgreSQL, to store information about disk space usage A locking mechanism has been devised allowing multiple processes to coordinate both file system writes and meta-tile requests, thus avoiding data corruption and minimizing duplication of work Given the above GeoWebCache 1.4.x can be easily deployed as a cluster of stand-alone instances in active/active mode, with all the instances operating at the same time. GeoWebCache 1.4.x is integrated also in the GeoServer 2.3.x series, making it also possible to directly use the integrated version and thus just have a single cluster of GeoServer instances. The concern about the WMTS workload taking over the servers and leaving little to the other OGC services still stands, but it can be mitigated by the following steps: Installing the control-flow plugin in GeoServer Use control-flow to limit the amount of GeoWebCache requests that the server will actually handle in parallel Increase the Tomcat thread pool to a high number (e.g. 5000) and reduce to zero the requests queue The last point deserves an explanation. Tomcat by default uses 200 threads tops to serve the requests, if more parallel requests come in they will be stored in a queue whose size is by any practical means infinite (see http://tomcat.apache.org/tomcat-6.0-doc/config/executor.html). This means that GeoServer, and in particular the control-flow subsystem, get to see only the 200 requests currently running, and cannot effectively prioritize the WMS/WFS requests. By setting the thread pool to a large size we allow the control-flow to see all of the incoming requests and apply the rules that will properly prioritize the different request types. The requests queue set to zero will make Tomcat refuse further connections, which is not going to be a problem if the thread pool size is large enough to allow for the maximum expected load anyways (a server under excessive load should start dropping incoming requests anyways to protect its own stability). Page 11 of 32
GeoWebCache CACHE DIR When possible use an external and shared GeoWebCache CACHE dir. This can be easily achieved by using setting the Environment variable on the Tomcat instances - GEOWEBCACHE_CACHE_DIR=<full_path_to_external_folder> This folder will contain custom configurations, logs and all the tiles of GeoWebCache. The size of this folder must be enough to contain the tiles pyramids. GeoWebCache will create 256x256 images for each output format (PNG/JPEG/GIF/ ), Coordinate Reference System/Grid and zoom level on all the cached layers. The size of the Cache can be in any case controlled by setting the DISK_QUOTA. About this last point, be very careful on which GeoWebCache version you install and deploy in a cluster configuration. When using GWC 1.3.x, on multiple instances, in order to avoid claches there are only two ways: 1. Completely disable the disk quota using the environment variable GWC_DISKQUOTA_DISABLED=true 2. Configure the load balancing in fall-back only mode When using GWC 1.4.x, you must enabled a DB centralized disk quota. Page 12 of 32
Vertical Cluster Set-up with Apache Tomcat and GeoServer A Tomcat worker is a Tomcat instance that is waiting to execute servlets on behalf of some web server. For example, we can have a web server such as Apache forwarding servlet requests to a Tomcat process (the worker) running behind it. The scenario described above is a very simple one; in fact one can configure multiple Tomcat workers to serve servlets on behalf of a certain web server. The reasons for such configuration can be: - We want different contexts to be served by different Tomcat workers to provide a development environment where all the developers share the same web server but own a Tomcat worker of their own. - We want different virtual hosts served by different Tomcat processes to provide a clear separation between sites belonging to different companies. - We want to provide load balancing, meaning run multiple Tomcat workers each on a machine of its own and distribute the requests between them. Illustration 1: Cluster Use Case Illustration 1 depicts a common use case composed by a cluster of two GeoServers 2.3.x using integrated GeoWebcache 1.4.x. Page 13 of 32
The GeoServer instances are hosted by Apache Tomcat which exposes different AJP ports to the JK connectors. The load balancer is implemented by Apache JK. By default Apache JK load balancing, implements a round-robin with fallback paradigm, but JK support also advanced configuration parameters which allow to define weights and distances of the workers 2. 2 http://tomcat.apache.org/connectors-doc/generic_howto/loadbalancers.html Page 14 of 32
Apache Tomcat configuration for vertical clustering The first step to perform in order to create a vertical cluster with Apache Tomcat to run multiple instances on the same box (physical or virtual) is actually have a single Tomcat HOME folder containing the standard Apache Tomcat binaries but then configuring additional Tomcat BASE folders containing the configurations for each instance 3. First of all we should download a recent version of the Apache Tomcat binaries 4 (in this document we are using 6.0.36) and extract them into a common folder, which will become the CATALINA_HOME default folder. Next step, we should start to create a new folder for each instance we want to have. This folder will contain the following sub-folders, copied from the original Tomcat folders that are part of the download: - bin/ : we should empty this directory after we copy it. It will contain scripts to set environmental variables - conf/ : - logs/ : empty; will contain the Tomcat logs for the specific instance - temp/ : empty; will contain the temp files for the specific instance - work/ : empty; will contain the compiled JSPs for the specific instance We need to repeat this step for each instance we want to have. In our sample package we created to directories called instance1 and instance2 which we ll allow us to run two instances of Tomcat on the same machine. Now, we need to tweak the ports used by each Tomcat instance. This means opening up the server.xml file inside the conf directory for each instance and making sure the various instances use different ports for each service. As an instance we did the following: 1. instance1 a. shutdown port 8005 b. HTTP connector port 8080 c. AJP connector port 8009 d. HTTPS port 8443 2. Instance2 a. shutdown port 8006 b. HTTP connector port 8081 c. AJP connector port 8010 3 We are assuming the reader is familiar with Tomcat and relative concepts and terminology 4 http://tomcat.apache.org/download-60.cgi Page 15 of 32
d. HTTPS port 8444 Now we can be sure that the different instances ports will not clash on Tomcat startup. The following steps are OS specific as they involve creating scripts and setting environmental variables to run Tomcat. As such we will differentiate instructions between different OS. Page 16 of 32
Windows Vertical Cluster Configuration For this setup you need to download the package at this link. The package contains a ready to use skeleton for Apache Tomcat 6.0.36 with three instances, a master and two slaves. It also contains the ISAPI redirect dll and configuration for both 32 and 64 bits Windows. In the following sections we will go over the steps needed to configure multiple Tomcat instances to run GeoServer in a perfect Active-Active clustered configuration. Step 1: Basic Customization for instances environment variables Create a setenv.bat file in the bin folder for each instance Make sure the JAVA_HOME and JRE_HOME contains the full path of the JDK you intend to use Make sure CATALINA_BASE contains the full path of the Apache Tomcat base folder Set the instance name to use the same name of the directory that contains the config for such an instance The setenv.bat so far looks like the following: rem basic Tomcat configuration set INSTANCE_NAME=instance1 set JAVA_HOME= C:/Program Files/Java/jdk1.6.0_37 set JRE_HOME=%JAVA_HOME%/jre set CATALINA_BASE=%CATALINA_HOME%\instances\%INSTANCE_NAME% Notice how we initialized the CATALINA_BASE environmental variable. This set up works since the various instances have been created in a path contained within the CATALINA_HOME directory where the parent Tomcat instances resides. It is also crucial to remark that the instance name must match the name of the enclosing directory for the instance s configuration. Step 2: Customization for instances environment variables related to GeoServer We are now going to provide some basic hints on how to customize environmental variable in order to run two instance of GeoServer in parallel on the same machine sharing the same data directory in order to create a perfect cluster in Active-Active mode. Notice that we are assuming that the data directory to use sits right next to the instances directories. All the instructions below refer again to the setenv.bat file and must be replicated on all instances. 1. Make sure the GEOSERVER_DATA_DIR is properly set for all instances in order to have them point to the same location 2. Make sure the GEOSERVER_LOG_LOCATION points to different locations for each instances in order to prevent them for writing on the same log file 3. If your GeoServer comes with integrated GeoWebCache: Page 17 of 32
a. Disable the metastore b. Disable the diskquota c. Make sure the GEOWEBCACHE_CACHE_DIR is the same on all instances Notice that in this set up we are running all instances in parallel with diskquota and metastore 5 disabled for GeoWebCache. We are assuming that the disk space is enough for all instances and we relying on GeoWebCache to coordinate between different instances trying to write the same tile at the same time (which is an unlikely event but not impossible). The setenv.bat so far looks like the following: rem basic Tomcat configuration set INSTANCE_NAME=instance2 set JAVA_HOME=C:/Program Files/Java/jdk1.6.0_37 set JRE_HOME=%JAVA_HOME%/jre set CATALINA_BASE=%CATALINA_HOME%\instances\%INSTANCE_NAME% rem Options for GeoServer and GeoWebCache set GEOSERVER_DATA_DIR=%CATALINA_HOME%\instances\data set GEOSERVER_LOG_LOCATION=%CATALINA_HOME%\logs\%INSTANCE_NAME%.log set GEOWEBCACHE_CACHE_DIR=%CATALINA_HOME%\instances\data\gwc set GWC_METASTORE_DISABLED=true set GWC_DISKQUOTA_DISABLED=true Step 3: Customization for instances environment variables related to JVM options The last step is to customize the JVM options for each Tomcat instance (like the heap memory and others). Again, all the instructions below refer again to the setenv.bat file and must be replicated on all instances. A possible configuration for JVM options would be as follows: rem Options for the JVM set JAVA_OPTS=%JAVA_OPTS% -Xms512m -Xmx1024m -XX:MaxPermSize=512m -XX:PermSize=128m set JAVA_OPTS=%JAVA_OPTS% -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:ParallelGCThreads=4 set JAVA_OPTS=%JAVA_OPTS% -DGEOSERVER_DATA_DIR=%GEOSERVER_DATA_DIR% set JAVA_OPTS=%JAVA_OPTS% -DGEOSERVER_LOG_LOCATION=%GEOSERVER_LOG_LOCATION% set JAVA_OPTS=%JAVA_OPTS% -DGEOWEBCACHE_CACHE_DIR=%GEOWEBCACHE_CACHE_DIR% set JAVA_OPTS=%JAVA_OPTS% -DGWC_METASTORE_DISABLED=%GWC_METASTORE_DISABLED% set JAVA_OPTS=%JAVA_OPTS% -DGWC_DISKQUOTA_DISABLED=%GWC_DISKQUOTA_DISABLED% set JAVA_OPTS=%JAVA_OPTS% -Duser.timezone=GMT -Djavax.servlet.request.encoding=UTF-8 set JAVA_OPTS=%JAVA_OPTS% -Djavax.servlet.response.encoding=UTF-8 -Dfile.encoding=UTF-8 It is worth to notice how we reuse the configuration options we set previously for GeoServer and GeoWebCache. 5 http://geowebcache.org/docs/current/concepts/stores.html Page 18 of 32
Manual start/stop of instances VS installation as services It is now possible to run the single instances manually via the start/stop commands or to install them as services on Windows to have automatic startup. To perform a manual start/stop of each instance we created a modified version of the startup.bat and shutdown.bat scripts which have been called startupx.bat and shutdown.bat and placed inside the bin directory of CATALINA_BASE. To start an instance called X (whose base directory must be named X as well as noted above) you need to : Open a command line Browse to the bin directory of the CATALINA_HOME Type startupsx.bat X Similarly to stop the same instance, you need to: Open a command line Browse to the bin directory of the CATALINA_HOME Type shutdownx.bat X If you prefer to install each instance as a separate service all you need to do is to, for each instance X: Open a command line as an Administrator Browse to the bin directory of the CATALINA_HOME Type servicex.bat X To uninstall the service for a specific instance you should instead: Open a command line as an Administrator Browse to the bin directory of the CATALINA_HOME Type servicex.remove.bat X JK Load Balancer Setup with IIS We are now going to configure Microsoft IIS webserver to act as a load balancer in front of the Tomcat instances we just configured. This is a common set up on windows systems, although it is possible to use Apache HTTPd on windows as well. Microsoft IIS implementation works with Virtual Directories and ISAPI Filters instead of Location and Modules like Apache HTTP. The concept is very similar, despite the configuration is slightly more complex. Let us now proceed with the configuration steps; however before proceeding let us mention that most of the information we are going to report here can be found at this links 6. Moreover we are assuming that IIS is properly installed together with the extension needed to create ISAPI filters on websites (we will use this feature extensively in the following). 6 http://tomcat.apache.org/connectors-doc/reference/iis.html, http://tomcat.apache.org/connectorsdoc/webserver_howto/iis.html and http://tomcat.apache.org/connectors-doc/generic_howto/workers.html Page 19 of 32
It is eventually worth remarking that the prepackaged Apache Tomcat we configured contains already the ISAPI filter and its own configuration for both 32 and 64 bits. They are located within the bin directory of the CATALINA_HOME folder. Step 1: Prepare isapi_redirect folder Download ISAPI redirector DLLs from here, matching the architecture of the machine on which we will install. This notice is to be taken into proper account as well: Note that in a 64 Bit environment - at least for IIS 7 - the used IIS Application Pool should have "Enable 32- bit Applications" set to "False". Otherwise the redirector will not be called and returns an http code 404. If you think, the 32bit version of isapi_redirect.dll would do the job instead, you will get an http code 500, because the library is not loadable into a 64 Bit IIS. Once the file has been downloaded, extract the content into a folder which will be used to link the IIS virtual directory. From now on we will assume the directory is C:\work\programs\apache-tomcat- 6.0.36\bin\win64. Create the following files inside the folder, modify them accordingly to your system setup - isapi_redirect.properties - worker.properties - uriworkermap.properties - logs directory (where we will place the log files for the JK connector) Configure Properties Files isapi_redirect.properties The ISAPI redirector read it's configuration from this properties file. The redirector will check for the properties file during initialization and will use it accordingly. The properties file must be placed in the same directory as the ISAPI redirector and named isapi_redirect.properties i.e. with the same name as the ISAPI redirector DLL but with a.properties extension. A sample isapi_redirect.properties can be found here below. Page 20 of 32
# Configuration file for the Jakarta ISAPI Redirector # The path to the ISAPI Redirector Extension, relative to the website # This must be in a virtual directory with execute privileges extension_uri=/jakarta/isapi_redirect.dll # Full path to the log file for the ISAPI Redirector log_file=c:\work\programs\apache-tomcat-6.0.36\bin\win64\logs\isapi_redirect.%y-%m-%d-%h.log # Log level (debug, info, warn, error or trace) log_level=error # Rotate the log file at 5 MB log_filesize=5m worker_file=c:\work\programs\apache-tomcat-6.0.36\bin\win64\worker.properties worker_mount_file=c:\work\programs\apache-tomcat-6.0.36\bin\win64\uriworkermap.properties uri_select=unparsed # A DWORD value representing the watchdog thread interval in seconds. The workers are maintained periodically by a background thread running periodically every watchdog_interval seconds. Worker maintenance checks for idle connections, corrects load status and is able to detect backend health status. watchdog_interval=5 It is worth to point out that additional information can be found at this link. It is however worth to point out that in this file we can configure the logging for the redictor (here we have configured log rotation with level set to error) as well as the configuration for the workers that is instrumental to load balance the Tomcat instances we created. uriworkermap.properties This file maps URL-Path patterns to workers. A sample uriworkermap.properties for mapping GeoServer URLs can be found here below. Additional information can be found at this link. # *********** Begin uriworkermap.properties *** # # Simple worker configuration file # # Mount the Servlet context to the ajp13 worker /geoserver*=wlb /geoserver/*=wlb # ************* End uriworkermap.properties **** worker.properties This file describes the host(s) and port(s) used by the workers (Tomcat instances). A sample workers.properties can be found here below. Additional information can be found here. It is worth to remark the following points: Page 21 of 32
we are defining a load balancer worker to load balance between two workers that map to two different instances of Tomcat running on the same machine but on different ports for the AJP connectors we are using round robin with the same load factor (same load on both Tomcat instances) we also a defined a Status Worker which is responsible for the worker management. It is especially useful when combined with load balancer workers and as such it should be protected from external access (not performed in this configuration) More on load balancing here. Page 22 of 32
# ************ Begin worker.properties ************** # Specifies the load balance factor when used with a load balancing worker. # Note: # ----> lbfactor must be > 0 # ----> Low lbfactor means less work done by the worker. #worker.ajp13w.lbfactor=1 # Specify the size of the open connection cache. #worker.ajp13.cachesize #------ DEFAULT LOAD BALANCER WORKER DEFINITION ---------------------- #--------------------------------------------------------------------- # The loadbalancer (type lb) worker perform weighted round-robin # load balancing with sticky sessions. # Note: # ----> If a worker dies, the load balancer will check its state # once in a while. Until then all work is redirected to peer # worker. worker.wlb.type=lb worker.wlb.balanced_workers=ajp13w1, ajp13w2 # the balancer will pick the worker with the lowest current load, based on # how many requests the worker is currently serving worker.wlb.method=b # You should configure your environment slash... ps=\ on NT and / on UNIX # and maybe something different elsewhere. ps=\ #------ ADVANCED MODE ------------------------------------------------ #--------------------------------------------------------------------- #------ DEFAULT worker list ------------------------------------------ #--------------------------------------------------------------------- # # The worker that your plugins should create and work with worker.list=wlb,jkstatus # Define a status Worker worker.jkstatus.type=status #------ DEFAULT ajp13 WORKER DEFINITION ------------------------------ #--------------------------------------------------------------------- # Defining a worker named ajp13 and of type ajp13 # Note that the name and the type do not have to match. worker.ajp13w1.type=ajp13 worker.ajp13w1.host=localhost worker.ajp13w1.port=8009 worker.ajp13w1.lbfactor=1 worker.ajp13w2.type=ajp13 worker.ajp13w2.host=localhost worker.ajp13w2.port=8010 worker.ajp13w2.lbfactor=1 # ************ End worker.properties ************** /jkmanager=jkstatus Page 23 of 32
Configuring IIS as the webserver Now we need to configure IIS. Start by creating a virtual directory and give it an alias of jakarta as shown here. Incidentally, you don t have to call the virtual directory jakarta - you can actually give it any name you like, just so long as the name you choose appears in the extension_uri line of your isapi_redirect.properties file. Next we need to configure the virtual directory to have execute permission. This was a simple tick-box option in IIS 6.0 but in IIS 7.0 we need to click on the Jakarta virtual directory and then double-click Handler Mappings. Page 24 of 32
Within the Handler Mappings feature click Edit Feature Permissions in the Actions Pane. Click Execute in the Edit Feature Permissions dialog box and click OK. In the Handler Mappings feature you can now see that calls to ISAPI-dll files are enabled. Page 25 of 32
The next step is to add an ISAPI filter on the web site. To do this click on the web site and then double-click the ISAPI Filters feature. Page 26 of 32
In the Actions pane click Add. In the Add ISAPI Filter dialog box enter a name and the path to the isapi_redirect.dll file and click OK. The Tomcat ISAPI filter should now appear in the ISAPI Filters list as shown here. Page 27 of 32
The final step we need to take is to configure the ISAPI and CGI Restrictions feature in IIS 7.0. This is analogous to adding or allowing a Web Service Extension in IIS 6.0. In IIS Manager navigate to the Server Home and then double-click on the ISAPI and CGI Restrictions feature. Page 28 of 32
In the ISAPI and CGI Restrictions feature click Add on the Actions pane. In the Add ISAPI or CGI Restriction dialog box enter a name and the path to the isapi_redirect.dll file, tick the Allow extension path to execute option and click OK. The Tomcat ISAPI extension should now appear in the list with a Restriction status of allowed as shown here. Page 29 of 32
On Application Pool - DefaultAppPool o Advanced Settings -> Make sure 32 bit application is disabled if the target architecture is 64 bits Restart both IIS web site and from Services the IIS Administration Service Check the logs both under - iis_redirect dll folder - inetpub/logs/logfiles Page 30 of 32
Annex A : Cluster Basic Authentication with IIS 1) Enable IIS Basic Authentication on redirect Virtual Folder and DISABLE the Anonymous one 2) Access the GeoServer ADMIN page through the MASTER Instance and go to the Authorization Menu Page 31 of 32
Look for the Filter Chains, and one by one (except for weblogout) make sure the basic interceptor is the first one for each chain Page 32 of 32