Appboard/2.4/admin/clustering and failover: Difference between revisions

imported>Jason.nicholls
imported>Jason.nicholls
Line 18: Line 18:
Whether running a load-balanced, failover, or cold-standby configuration the following components are required:
Whether running a load-balanced, failover, or cold-standby configuration the following components are required:


* AppBoard installation per node, this includes a separate license for each node.
* AppBoard installation per node, this requires a separate license for each node.
* External (shared) configuration database. This database is not provided by Edge and is recommended to reside on a different host to the AppBoard servers. In high availability environments the database itself should also highly available. See the [[appboard/2.4/system_requirements|System Requirements]] for supported external configuration databases.
* External (shared) configuration database. This database is not provided by Edge and is recommended to reside on a different host to the AppBoard servers. In high availability environments the database itself should also highly available. See the [[appboard/2.4/system_requirements|System Requirements]] for supported external configuration databases.
* Load Balancer. This component is not provided by Edge but is required in cluster configurations.
* Load Balancer. This component is not provided by Edge but is required in cluster configurations.

Revision as of 12:45, 21 July 2014

Overview

AppBoard is implemented using a highly scalable web application architecture. As a Java application running inside an Apache Tomcat server, AppBoard is able to make use of multi-core and multi-processor systems with large amounts of RAM on 64-bit operating systems. In addition to scaling vertically on a single system, AppBoard supports horizontal scaling to handle even greater loads and/or to provide for high availability environments through the use of a shared configuration database. AppBoard can be used in the following configurations:

  1. Load Balanced: Two or more nodes are fully operational at all times. The load balancer directs traffic to nodes based on standard load balancing techniques such as round-robin, fewest sessions, smallest load, etc... If a server is detected as down it is removed from the active pool.
  2. Failover: A two-node configuration with both nodes running but all traffic is routed to the primary node unless it is detected to be down. At this point the load balancer re-directs traffic to the secondary node.
  3. Cold Standby: A two-node configuration where the secondary node is offline in normal operation. If the primary node is detected to be down the secondary node is brought online and traffic re-directed.

In cases where high-availability is required then regardless of the load a cluster configuration is recommended. In cases where load is a concern refer to the Performance Tuning & Sizing documentation for more information.

Architecture & Licensing

Two Node Cluster Architecture

Whether running a load-balanced, failover, or cold-standby configuration the following components are required:

  • AppBoard installation per node, this requires a separate license for each node.
  • External (shared) configuration database. This database is not provided by Edge and is recommended to reside on a different host to the AppBoard servers. In high availability environments the database itself should also highly available. See the System Requirements for supported external configuration databases.
  • Load Balancer. This component is not provided by Edge but is required in cluster configurations.

Cluster Configuration

Shared Configuration Database

Load Balancer

The Load Balancer can distribute sessions to one or more AppBoard nodes using any standard load balancing algorithm (e.g. Round-Robin, smallest load, fewest sessions, etc.). The only requirement is that the session affinity is maintained such that a single user is always routed to the same AppBoard node during the full duration of the session.

The two session cookies used by AppBoard are JSESSIONID and enPortal_sessionid. When configuring the Load Balancer for session affinity, it is recommended to use enPortal_sessionid to avoid any conflicts with other applications that may also have a JSESSIONID cookie.

The following URL can be used by the load balancer as a means of testing AppBoard availability:

http://server:port/enportal/check.jsp

This script returns a HTTP status code 200 (success) if all components of AppBoard are running properly, otherwise it returns a 500 (internal error) if there is an issue. And in the case the AppBoard server isn't running, then of course there will be no response.