Failover and redundancy considerations

7.5 Failover and redundancy considerations

The text referring to support for ‘web server clusters’ means that you can add additional servers for failover/backup purposes for the web layer, but the important thing to understand is that there is an architectural limitation of the COM+ components that are at the core of MyID that means that there must be a fixed mapping between web servers and the application server that they are paired with.

For example, in this diagram on a linear 3-server model, the COM+ proxies that run on the web server are:

created from the original COM+ components on the application server,
then exported to the web server and installed there,
then used by the MyID website to drive the primary components on the application server.

The proxies that run on the web server must be derived from the instance of the components on the individual application server that they are paired with.

This means that you can add additional web servers (for example, a cluster or farm) that share the same proxies and are therefore paired with a specific application server. For example:

This is OK because each web server (with the COM+ proxies that run it) is still paired with a specific application server. However, this model creates redundancy/failover in the web layer only, meaning that there is still a single point of failure at the application server level.

Therefore, customers seeking a fully redundant system are advised to duplicate the application/web channel, as well as using a SQL Cluster for hosting the MyID database:

In this model each web server is individually paired with each application server (represented by the different colored circle for the COM+ components).

There cannot be any failover from a web server in one channel to the application server in another without manual reconfiguration. For example:

This is because the proxies on the web server in the top channel are not paired with the application server on the second channel. That is, the communications from top channel web server to the second channel application server will not work.

It is for this reason that each web to application channel must be treated as a single unit in failover decisions.

That is, if any part of the top channel fails, the load balancer/failover router can switch all MyID traffic to the second channel:

This requires that the load balancer/failover router be capable of monitoring the health of each channel as a whole and not just the web server that sits at the front of it.

This depends on the capabilities of the load balancer/failover router in use. For example, potentially it could base its failover decisions on a combination ping/heartbeat to both the web and application server in each channel.