OpenSwitch
is an application that is placed between client connections
(such as ISQL, or any application developed using Sybase´s
Open Client TM, ODBC, or jConnect TM for JDBC libraries) and
two or more Sybase Adaptive Servers. It provides the facility
to transparently transfer incoming connections to any Sybase
server product, such as Adaptive Server ® Enterprise, or
another Sybase Open Server TM application (including another
instance of OpenSwitch).
OpenSwitch works either manually, in response to an administrative
request, or automatically when it detects failure in the
remote Sybase Server product. Additionally, OpenSwitch
also provides features for routing and load balancing across
servers, as well as communicating with any third party
high availability (HA) solution on the market.
Transparent
client connection transfer
OpenSwitch
operates by loosely coupling each application connection
to an outgoing connection to a remote Adaptive Server,
allowing OpenSwitch to transparently replace the outgoing
connection with a connection to any other server without
disturbing the client connection.
OpenSwitch attempts to track and restore as much state
information as possible on each client connection, such
as current database context and transaction state, insuring
that no connection will be disturbed while information
is being actively transferred between the client and remote
Adaptive Server.
Failure Detection and Recovery
For the duration of an incoming
client connection, OpenSwitch monitors several important
aspects of the communications with the remote Adaptive
Server, including:
- |
The
Transaction State: Whether or not the connection
is in the middle of an open transaction |
- |
The Communications State: Whether or not the connection
is actively communicating with the Adaptive Server |
- |
The
Connection State: Whether or not the connection is
currently established with the Adaptive Server |
If,
at any time, the connection to the remote Adaptive
Server is unexpectedly disconnected (such as if the
Adaptive Server was shut down or the connection was
killed) OpenSwitch would automatically transfer the
connection to the next available server.
External
Coordination
The default behavior
of the OpenSwitch is to automatically attempt to migrate
individual failed connections as they happen. That is,
if a single connection fails, it is immediately migrated
to the next available server (according to the mode of
the pool in which the connection resides).
Frequently, however, it is desirable to coordinate the
switching process around certain operational or business
requirements. For example, rather than immediately migrating
the connection to the next server, it may be best to first
try to re-connect to the failed server to ensure it has,
indeed, failed; or it may be desirable to switch all connections
to the server if a single connection fails unexpectedly.
More importantly, the switching process may need to be
coordinated with an external high availability solution
(such as Sybase Replication Server ® , or a hardware
vendor specific HA solution). In this case, a fail-over
should not occur until the HA service has completed whatever
steps are necessary to bring the back-up server online
(such as waiting until replication queues are in sync between
servers).
For these situations, OpenSwitch provides a simple API
(application programming interface) for developing an external
Coordination Module (or CM). When connected to an OpenSwitch,
a coordination module will receive event notifications
based upon connection state changes (e.g. a user attempts
to log in, or a connection is lost to a server) and is
expected to respond back to the OpenSwitch informing it
of any actions it needs.
Customizable High Availability
Coordination
OpenSwitch
provides an open, customizable mechanism for coordination
of fail-over events with any available third party high
availability solution, including Sybase Replication Server,
HP Service Guard, Sun Solstice, and Microsoft Wolfpack.
By providing such integration, OpenSwitch can ensure all
transactions which have been played against the primary
server have been migrated to the warm-standby. In turn,
the warm-standby is fully operational prior to switching
connections. During administrative switch requests, OpenSwitch
also ensures all transactions have been committed prior
to migrating connections to the warm-standby and drives
the HA solution to initiate the fail-over sequence.
