
Chapter 5: New Features in Adaptive Server Version 12.5.0.x
Active-passive configuration
for Sun Cluster 3.0
Adaptive
Server for Sun Cluster 3.0 offers either an active-passive or an
active-active setup.
An active-active setup includes two Adaptive Servers installed
on two nodes of the cluster that are configured as companion servers.
When the primary companion fails, the secondary companion takes
over its workload. The active-active setup for Sun Cluster 3.0 is
described in Chapter 11 of Using Sybase Failover in a
High Availability System.
If Adaptive Server, or the node on which it is running, fails,
the server and all its devices fails over to a secondary node. At
the time of failover, all existing client connections are lost.
Clients must reestablish their connections and resubmit their uncommitted
transactions as soon as Adaptive Server is running on the secondary
node. The failover of client connections (that is, reestablishing
their connections after failover) can be done automatically by using
the self-referencing hafailover entry in the
interfaces file and setting the CS_HAFAILOVER connection
property.
If your site includes more than two nodes in an active-passive
setup, the server running on the primary node can fail over to any
of the secondary nodes, as long as it can successfully host Adaptive
Server and all its associated resources. The node list determines
the order in which Adaptive Server fails over to the other nodes
in the cluster.
Table 5-1 discusses
the differences between an active-active setup and an active-passive
setup.
Table 5-1: Differences between active-active and active-passive
Active-active
|
Active-passive
|
Setup: Two Adaptive
Servers are configured as companion servers, each with an independent
resource group. These companions run on the primary and secondary
nodes, respectively, as individual servers until failover.
|
Setup: One Adaptive
Server, running either on the primary node or on the secondary node.
Only one Adaptive Server resource group exists, which is hosted by
the primary node before failover and the secondary node after failover.
|
Failover: When
failover occurs, the secondary companion takes over the devices,
client connections, and so on from the primary companion. The secondary companion
services the failed-over clients, as well as any new clients, until
the primary companion fails back and resumes its activities.
|
Failover: When failover
occurs, the Adaptive Server along with its associated resources
and resource group is relocated to, and restarted on, the secondary
node.
|
Failback: Failback
is a planned event during which the primary companion takes back
its devices and client connections from the secondary companion
to resume its services.
|
Failback: Failback
is a planned failover or relocation of the Adaptive Server resource
group to the another node. Failback is not required, but can be
used for administration.
|
Client Connection failover: During
failover, clients connect to the secondary companion to resubmit
their transactions. During failback clients connect to the primary
companion to resubmit their transactions. Clients with the failover
property reestablish their connections automatically
|
Client Connection failover:
During failover and failback, clients connect to the same Adaptive
Server to resubmit uncommitted transactions. Clients with the failover property
reestablish their connections automatically.
|
Copyright © 2005. Sybase Inc. All rights reserved.
|
|
View this book as PDF 