High availability and scalability

The IMS Server adopts a two-tier server architecture, with a front tier of

application servers and a back-end database. As such, deploying the IMS and its database is possible in a number of configurations, ranging from low to high end.

The IMS Server and its database, and any underlying support infrastructure can be configured to achieve the availability and scalability requirements of the tangible environment. In this section, we describe three deployment models covering different deployment sizes and availability requirements.

Pilot deployments

Pilot deployments with no high availability requirements typically involve a single server machine hosting both the IMS and its database. This single-box

configuration is not horizontally scalable and does not provide high-availability.

The only way to support more users is to upgrade its processor capability.

Small scale deployments

Smaller environments with up to 10,000 users typically deploy a two-box

clustered configuration, where each box hosts the IMS Server and the database.

In this configuration, a clustering solution such as Microsoft Cluster Server is required to maintain an active-passive pair of IMS and DB. Usually, this

configuration requires that the two database hosts share a common external disk array, and that the cluster-aware versions of the database must be deployed.

This configuration provides high-availability, because an automatic failover is initiated when the active node fails.

This configuration is typically limited to an active-passive pair and is thus not horizontally scalable. To support heavier loads, the hardware must be upgraded.

Large scale deployment model

Medium- to large-scale architectures with, for example, up to 500,000 users will adopt the standard two-tier architecture, with multiple IMS Servers in the front-tier and a clustered IMS database in the back end.

The IMS Servers must be fronted by a session-aware load-balancer. The IMS tier is thus horizontally scalable. An estimation is that each server, assuming a

two-processor dual-core 3.6 GHz Windows machine, can support up to 40 K concurrent AccessAgent sessions. As such, a deployment expecting 100 K concurrent AccessAgent sessions requires three such servers at the IMS tier to share the load.

The database tier can only be scaled vertically by default. As such, an important point is that the database host be sized correctly in accordance to the number of IMS Servers it is expected to service. A typical guideline, based on load test experiments, is to double the processor and memory capacity of the database host for every five additional IMS Servers.

Scaling up a combined IMS and database server

A single server machine hosting both the IMS and database server is sufficient for small-scale deployments. This configuration can be scaled-up in any of the following ways:

򐂰 Enhance the processor hardware (faster processor or multi processor).

򐂰 Add more RAM.

򐂰 Upgrade the disk sub-system (more disks, faster disks) and optimize the database file layout on these disks.

A single server configuration can be made highly-available by adding a second server and setting up an active-passive cluster over the two servers. Such a configuration typically involves:

򐂰 Use of Microsoft Cluster Service (or equivalent)

򐂰 Use of an external disk array shared by both server machines

򐂰 Use of a cluster-aware edition of the database server

򐂰 Configuring the cluster service to recognize IMS and the database as resources to be managed under the cluster

In such configuration, the cluster service monitors the following components:

򐂰 Host machines

򐂰 Health of the IMS Server

򐂰 Database services

If any of these components fail, the cluster service also triggers failover from one machine to another.

Scaling out the IMS Server

For most deployments, a two-tier architecture is suggested, with a tier of IMS Servers fronting a shared database server.

In this configuration, a hardware or software-based load balancing solution should be used to distribute the incoming traffic from various AccessAgent installations into multiple IMS Servers. The load balancing solution should support session affinity, where each client’s request is consistently routed to the same IMS Server (until the server goes down, and the requests are then re-routed to another server).

Scaling up or scaling out the database server

The database server can be scaled up if performance measurements indicate that its processor, RAM, or disk is a bottleneck. In these cases, the methods for scaling up the database server include:

򐂰 Enhance the processor hardware (faster processor or multi processor).

򐂰 Add more RAM.

򐂰 Upgrade the disk sub-system (more disks, faster disks) and optimize the database file layout on these disks.

Solutions for scaling out the database server across multiple machines are typically vendor-dependent and might require a customized IMS installation process.

Components for high availability

The following three components require high availability (HA), as shown in Figure 2-8 on page 71:

򐂰 IMS Server

򐂰 Database Server

򐂰 Directory Server

Figure 2-8 High availability architecture

Setting up the IMS Server for high availability

Two-tier deployments can make use of load balancing solutions to achieve high availability (HA). The load balancer automatically re-balances incoming traffic when a member of the server farm goes up or down. Some load balancers also support continuous monitoring of application or service status based on custom scripts (for example, pinging a certain URL), so that traffic can be re-routed if a certain application or service on a server machine fails to respond.

In the case of Microsoft NLB, each machine in the server farm can monitor the heartbeat of each other, and re-converge when a member of the farm goes up or down. However, NLB monitors only the server operating system’s health. If the server operating system is up but IMS service is down, some IMS Server requests continues to be routed to that server. This issue can be addressed through some custom scripts to monitor the IMS Server.

Setting up the database server for high availability

The solutions for database server high availability (HA) are vendor-specific:

򐂰 Microsoft SQL Server Cluster (on top of Microsoft Cluster Service)

򐂰 IBM DB2 HADR

򐂰 Microsoft SQL Server Database Mirroring

򐂰 Oracle RAC

Most solutions involve an active-passive pair of database servers, except Oracle RAC, where servers are active-active.

IMS can interoperate with these highly-available database solutions, if IMS database schemas can be installed in the database to configure the IMS to recognize the database cluster/pair as one logical database.