CSWS Disaster Tolerance

[TMcB]

We are using CSWS 1.3 on an alpha based cluster.
CSWS is currently installed and running on only one node in the cluster.

The problem is that when we have to shut this server down, no-one can access the web services.

Can anyone give me any pointers on what I could do to provide some form of tolerance?

At the minute we use DNS aliases to point to the specific node running CSWS.

Any advice is greatly appreciated!

[Kris Clippeleyr · Accepted solution]

Hi,

Since CSWS is based on Apache, I think it lacks the necessary ingredients to make it fault tolerant.
Over here, we install SWS (either 1.3 or 2.0) on all custer members, configure it for each node, and start it on each node.
All WWW related stuff is stored on a disk accessible by all cluster members.
As for addressing the webservers we either use the node name, or the TCP/IP cluster alias.
Hope this helps,
Kris (aka Qkcl)

[Ian Miller.]

You may want to look at running the web server on multiple nodes and using the load broker/metric stuff to update a DNS server name . See
http://h71000.www7.hp.com/doc/732final/6526/6526pro_016.html#lbroker_chap

[Bojan Nemec]

You can also check the installation guide for CSWS. It has some considerations abbout running CSWS in cluster:

http://h71000.www7.hp.com/openvms/products/ips/apache/csws_iguide.html

Bojan

[Andy Bustamante]

Another option is to run the CSWS on multiple nodes and configure an additional TCP/IP address using failsafe IP in TCPIP 5.4 or a cluster alias in earlier versions. See http://h71000.www7.hp.com/openvms/journal/v2/articles/tcpip.html for an excellent overview TCPIP availability options.

[Robert Gezelter]

TMcB,

Assuming that there is no reason to only have one server at a time, I like to use DNS to spread the load over both boxes.

Note that this will provide a degree of fault tolerance, but it is not disaster tolerant. Disaster tolerant is normally used to refer to a configuration that will survive a severe calamity (e.g., the destruction of the WTC on 9/11).

Providing disaster tolerance means a wide-area cluster OR totally independent nodes that BOTH provide equivalent WWW capacities, and both are listed in the DNS. It is also a good idea to set the expiration values low so that if a site is destroyed, you can remove it from the DNS and have the old data quickly expire.

I hope that the above is helpful.

- Bob Gezelter, http://www.rlgsc.com

[TMcB]

thanks everyone for replying -
you have pointed me in the right direction for getting started.

Thanks again

[Robert Gezelter]

TMcB,

A small add-on.

I believe that you will find some information on strategies for Internet accessible assets and protecting www servers in my chapters in the Computer Security Handbook, 4th Edition (Bosworth & Kabay, Editors; Wiley, 2002; the chapter outline can be found via http://www.computersecurityhandbook.com).

Particularly, if you need to explain things to higher levels of the organization, the book may help.

- Bob Gezelter, http://www.rlgsc.com

[Jan van den Ende]

TMcB,

I fully endorse Robert on this.

We _HAVE_ CSWS running on all nodes of our homogenous multi-site cluster. Having multiple interconnects on each node helps redundancy, but complicates the adressing issue.
Our DNS has each node as a round-robin alias for its net devices, and (by default) the cluster name as round-robin over the nodes.
(in case of planned maintenance, we change that).
And each (browser- and other-) applic has an alias to the cluster alias (during work on such applic, we reduce that applics' list to exclude the node for the users).

(Upon unplanned loss of a node, the other nodes notice, and adapt DNS as well. Reminiscent of Metric-&-Broker, but including some of the extra flexibilities we like).

For us, this works great, and had for years!

Success.

Proost.

Have one on me.

Jan