ibm-information-center/dist/eclipse/plugins/i5OS.ic.rzaie_5.4.0.1/rzaiehighavailability.htm

147 lines
9.7 KiB
HTML

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html
PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html lang="en-us" xml:lang="en-us">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<meta name="security" content="public" />
<meta name="Robots" content="index,follow" />
<meta http-equiv="PICS-Label" content='(PICS-1.1 "http://www.icra.org/ratingsv02.html" l gen true r (cz 1 lz 1 nz 1 oz 1 vz 1) "http://www.rsac.org/ratingsv01.html" l gen true r (n 0 s 0 v 0 l 0) "http://www.classify.org/safesurf/" l gen true r (SS~~000 1))' />
<meta name="DC.Type" content="topic" />
<meta name="DC.Title" content="Highly available Web server cluster on HTTP Server" />
<meta name="abstract" content="This topic provides information on highly available Web server clusters." />
<meta name="description" content="This topic provides information on highly available Web server clusters." />
<meta name="DC.Relation" scheme="URI" content="rzaieconcepts.htm" />
<meta name="copyright" content="(C) Copyright IBM Corporation 2002,2006" />
<meta name="DC.Rights.Owner" content="(C) Copyright IBM Corporation 2002,2006" />
<meta name="DC.Format" content="XHTML" />
<meta name="DC.Identifier" content="rzaiehighavailability" />
<meta name="DC.Language" content="en-us" />
<!-- All rights reserved. Licensed Materials Property of IBM -->
<!-- US Government Users Restricted Rights -->
<!-- Use, duplication or disclosure restricted by -->
<!-- GSA ADP Schedule Contract with IBM Corp. -->
<link rel="stylesheet" type="text/css" href="./ibmdita.css" />
<link rel="stylesheet" type="text/css" href="./ic.css" />
<title>Highly available Web server cluster on HTTP Server</title>
</head>
<body id="rzaiehighavailability"><a name="rzaiehighavailability"><!-- --></a>
<!-- Java sync-link --><script language="Javascript" src="../rzahg/synch.js" type="text/javascript"></script>
<h1 class="topictitle1">Highly available Web server cluster on HTTP Server</h1>
<div><p>This topic provides information on highly available Web server
clusters.</p>
<div class="important"><span class="importanttitle">Important:</span> Information
for this topic supports the latest PTF levels for HTTP Server for i5/OS .
It is recommended that you install the latest PTFs to upgrade to the latest
level of the HTTP Server for i5/OS. Some of the topics documented here are
not available prior to this update. See <a href="http://www-03.ibm.com/servers/eserver/iseries/software/http/services/service.html" target="_blank">http://www.ibm.com/servers/eserver/iseries/software/http/services/service.htm</a> <img src="www.gif" alt="Link outside Information Center" /> for more information. </div>
<p>If Web serving is a critical aspect of your business, you may want high
availability and scalability of your Web server environment. High availability
and scalability of the Web server environment can be achieved through the
use of iSeries™ clustering.
</p>
<p>The Web server cluster solution can provide: </p>
<ul><li><strong>Planned downtime</strong>: If a Web server requires planned maintenance,
it is possible to transfer the work to another node without visible service
interruptions to the client. </li>
<li><strong>No unplanned downtime</strong>: If a machine fails, the work is transferred
to another node with no human involvement and without visible service interruptions
to the client. </li>
<li><strong>Scalability</strong>: When employing multiple nodes, it is possible to distribute
the Web site workload over the cluster nodes. </li>
</ul>
<p>Clusters are a collection of complete systems that work together to provide
a single, unified computing capability. For more information on clusters,
see <a href="../rzaig/rzaigicclust.htm">Clusters</a> in
the iSeries Information Center. </p>
<p>A liveness monitor checks the state of the Web server and interacts with
the Web server and the clustering resource services in the event that a Web
server fails (failover), or a manual switchover takes place (ensures no interruption
of Web server services). The clustered hash table (part of the state replication
mechanism) can be used to replicate highly available CGI program state data
across the cluster nodes so that the state data is available to all nodes
in the event that a Web server fails (failover) or is switched-over manually
(switchover). To take advantage of this capability, an existing CGI program
must be enabled in a highly available Web Server environment. CGI programs
write to the CGI APIs to indicate what data is replicated. </p>
<p>There are three Web server cluster models that are supported: </p>
<ul><li>Primary/backup with takeover IP model </li>
<li>Primary/backup with a network dispatcher model </li>
<li>Peer model </li>
</ul>
</div>
<div>
<div class="familylinks">
<div class="parentlink"><strong>Parent topic:</strong> <a href="rzaieconcepts.htm" title="This topic provides concepts of functions on HTTP Server and IBM Web Administration for i5/OS interface.">Concepts of functions of HTTP Server</a></div>
</div>
</div><div class="nested1" id="takeover"><a name="takeover"><!-- --></a><h2 class="topictitle2">Primary/backup with takeover IP model </h2>
<div><p>In this model, the Web server runs on the primary and all backup nodes.
The backup node or nodes are in a idle state, ready to become the primary
Web server should the primary Web server fail (failover), or a switchover
takes place. All client requests are always served by the primary node. </p>
<p>The following diagram illustrates a Primary/backup with takeover IP model.
</p>
<br /><img src="rzal8505.gif" alt="Picture of primary/backup with IP-takeover model." /><br /><p>When the primary node fails (failover), or is brought down by the administrator,
the failover/switchover process begins. The following steps are performed
during failover/switchover: </p>
<ol><li>One of the backup servers becomes the primary (the first backup in the
switchover order). </li>
<li>The client requests are redirected to the new primary node.</li>
<li>If the new primary receives a user request that belongs to a long-running-session
(a CGI program that has been updated to be a highly available CGI program),
the server will restore the request's state. The new primary retrieves that
highly available CGI program's state information from the clustered hash table.
The clustered hash table is part of the state replication mechanism. </li>
<li>After the failed node recovers, the highly available Web server instance
can be restarted and it will become the backup system. If the system administrator
wants the failed node to become primary again, a manual switchover must be
performed (this can be accomplished with the IBM Simple Cluster Management
interface available through iSeries Navigator or a business partner tool). </li>
</ol>
</div>
</div>
<div class="nested1" id="dispatcher"><a name="dispatcher"><!-- --></a><h2 class="topictitle2">Primary/backup with a network dispatcher model </h2>
<div><p>In this model, just like the primary/backup with takeover IP model, the
Web server runs on the primary and all backup nodes. The backup nodes are
in an idle state and all client requests are served by the primary node. A
network dispatcher (for example the IBM WebSphere<sup>®</sup> Edge Server) sends client
requests to the Web server. </p>
<p>The following diagram illustrates a Primary/backup with a network dispatcher
model. </p>
<br /><img src="rzal8508.gif" alt="Picture of primary/backup with a network dispatcher model." /><br /><p>When the primary node fails (failover), or a switchover takes place, the
failover/switchover process begins. The following steps are performed during
failover/switchover: </p>
<ol><li>One of the backup servers becomes the primary (the first backup in the
switchover order). </li>
<li>The client requests are sent to the new primary node by the network dispatcher.
</li>
<li>If the new primary receives a user request that belongs to a long-running-session,
the server needs to restore the request's state. The new primary searches
for the state either locally or in the clustered hash table. The clustered
hash table is part of the state replication mechanism. </li>
<li>After the failed node recovers, the system administrator can restart the
Web server instance and it will become a backup Web server. If the system
administrator wants the failed node to become primary again, a manual switchover
must be performed. </li>
</ol>
<div class="note"><span class="notetitle">Note:</span> A node can join a recovery domain as primary only if the cluster resource
group is in inactive mode. </div>
</div>
</div>
<div class="nested1" id="peer"><a name="peer"><!-- --></a><h2 class="topictitle2">Peer model </h2>
<div><p>In this model, there is no declared primary node. All nodes are in an active
state and serve client requests. A network dispatcher (for example the IBM
WebSphere Edge Server) evenly distributes requests to different cluster nodes.
This guarantees distribution of resources in case of heavy load. Linear scalability
is not guaranteed beyond a small number of nodes. After some number of nodes
are added, scalability can disappear, and the cluster performance can deteriorate.
</p>
<p>The following diagram illustrates the peer model.</p>
<br /><img src="rzal8506.gif" alt="Picture of peer model." /><br /><p>For more information on Clusters, see <a href="../rzaig/rzaigtroubleshoot.htm">Clustering troubleshooting</a>. For instructions
on how to set up a highly available Web server, see <a href="rzaieconfigha.htm">Set up and administration of a highly available Web server cluster on HTTP Server (powered by Apache)</a> or <a href="rzaiesetha_cl.htm">Set up a highly available Web server using clustering CL commands
for HTTP Server</a>. </p>
</div>
</div>
</body>
</html>