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.
