MapGuide RFC 3 - Session Affinity

This page contains an change request (RFC) for MapGuide Open Source.  
More MapGuide RFCs can be found on the MapGuide RFCs page.

Status

This section should include the following:

• Submission Date: November 1, 2006
• Last Modified Date: November 1, 2006
• Author: Chris Claydon
• RFC Status: draft
• Implementation Status: pending
• Voting History:
• Assigned PSC guide(s):

Overview

When multiple MapGuide instances are accessed via a load balancer, problems arise when a request that requires a session that was created on one MapGuide site server is processed by a different server. The proposed short-term solution to this problem is to ensure that any requests that make use of a session and its related resources are always processed by the same server that created (and therefore has access to) that session.

Motivation

Configuring a load balancer to distribute requests between multiple MapGuide instances should be simple. The need to ensure that a session-related request is always directed to the server that originally created that session makes configuration of a load balancer undesirably complicated.

In a deployment that uses multiple, synchronized MapGuide Servers, a load balancer is typically used to distribute incoming client requests to a number of MapGuide Web Tier deployments. Each instance of the web tier makes use of a single MapGuide Site Server in order to process its requests.

Many operations require the use of sessions in MapGuide. Once a session has been created, the server may create temporary resources in a session repository. A session repository is very similar to the main (Library://) repository, except that the resources it contains only persist for the lifetime of the session. Requests that require the use of such session-based resources can only succeed if those resources are present on the server. Thus, if the load balancer hits one web tier deployment, and hence one particular server, when it creates a session, subsequent requests for that same session which get directed to an alternate web tier instance (and hence a different server) will fail. This is because the alternate server knows nothing about the requested session, and does not have a copy of the session repository.

All requests related to that particular session will fail unless the load balancer happens to direct the request to the server that created it. The proposal is to modify MapGuide to handle this problem so that the load balancer can direct incoming requests to any of its available web tier deployments. This allows the load balancer configuration to be trivial.

Funding/Resources

Autodesk to supply the resources to make the required changes.

Proposed Changes

The proposed changes represent a short-term solution to this problem. In the long term, steps should be taken to ensure that any of the available servers in a site are capable of handling sessions created on any of the other servers.

The changes can be summarized as follows:

1) Modify the web tier so that it can be configured to access more than one site server - this allows each web tier instance to make use of all of the site servers.

2) Modify the web tier so that requests that require a session are always directed to the site server that created the session.

3) Modify the server code so that any support servers that require access to session resources are able to retrieve them from the appropriate site server.

Technical

To support item 1, the web tier needs to perform some rudimentary load-balancing to distribute requests among the available servers. A simple round-robin algorithm would suffice. Support for failover if errors occur or servers are taken offline is beyond the scope of this proposal.

To support items 2 and 3, some means is required to map between a session ID and the corresponding server.

Implications

Client requests, particularly from the MapGuide viewers, often depend upon a session, so most of the traffic from a given client will always be directed back to the same server.

Test Plan

Testing will require multiple site servers, support servers, and web tiers to be deployed under a load balancer. Testing should then be carried out by making requests from multiple clients accessing different sessions.