In my last posts ("Business Continuity with SAP ASE – Server Availability Solutions (1/2 and 2/2)"), I described failover cluster solutions of various vendors. I will continue our journey in High Availability solutions with SAP ASE with HA option. SAP ASE with High Availability option is enhancement of O/S vendor solutions. SAP ASE with High Availability option clusters a pair of database servers together.
Main features of SAP ASE with High Availability option are:
SAP ASE with High Availability option interacts with vendor failover cluster solution. It uses cluster APIs of vendor solutions to be cluster aware. For instance, it is able to query cluster to get resource group state or to trigger a failback on cluster layer.
Availability.
ASE with High Availability option is generally available since ASE version 12.0 (circa 2000). It is available with ASE 15.7 on following platforms and cluster vendor solutions:
SAP ASE with High Availability option applies only to SAP ASE Enterprise Edition. SAP ASE Cluster Edition is a different product with additional features and capabilities. For the moment, SAP Business Suite is only certified with SAP ASE Enterprise Edition with HA option.
Terms.
ASE with High Availability option uses the same terms than failover clusters (node, resource groups, …). It has following additional specific terms.
Primary database server, secondary database server and companion server:
Primary database server is the first database server registered in the database cluster. The secondary database server is the second database server of the database cluster. Both database servers are known as companion servers.
Asymmetric configuration:
In asymmetric configuration, the databases of the primary database server can be managed by both primary and secondary database servers. If the secondary database server has its own databases, they cannot failover against the primary host.
Symmetric configuration:
In symmetric configuration, both companion database servers can manage all the user databases. Primary companion databases can fail over secondary companion server and vice-versa.
Active-Passive scenario:
In an active-passive scenario, client applications are connected to one database server. The other companion database server is a standby database server. It is only used in case of failover.
Active-Active scenario:
In an active-active scenario, client applications run against both companion database servers. Client applications are partitionned between companion database servers. For instance a Finance application may run on the primary database server and an Human Resource application runs on the secondary database server.
Use cases.
In following use cases, we have 2 companion database servers (ASE1 and ASE2). The prefered host for ASE1 is physical node node1 and the prefered host for ASE2 is physical node node2. This is only for the sake of clarity. ASE1 and ASE2 database servers are of course able to run on both physical nodes thanks to cluster layer.
Active-passive scenario:
Normal operation.
In this active-passive scenario, in “normal” operation, Finance application clients run on ASE1 database server. ASE2 database server is up and running ready to receive/host database devices and client connections (in case of a failure). Data is only presented to ASE1, ASE2 is not able to access data.
Failover situation.
In case of failure of node1 or physical resources of database resources group of node1, following occurs:
Active-active scenario:
Normal operation.
In this active-active scenario in “normal” operation, Finance application runs on ASE1 database server and HR application runs on ASE2. Both database server companions are able to receive and re-host applications. Finance data is only presented to ASE1 (ASE2 is not able to access Finance data). HR Data is only presented to ASE2 (ASE1 is not able to access HR data).
Failover.
In case of failure of node1 or physical resources of node1, following happens:
Failback.
Failback is a planned failover or relocation of the Adaptive Server and its resources to the primary node. Primary node must be fixed and checked. Usually failback is performed outside production activity timeframe. DBA triggers a failback by running the “sp_companion” stored procedure with “prepare_failback” argument.
For instance, when running “sp_companion/prepare_failback” command on ASE2 (in case of ASE1 finance databases failed over ASE2), following occurs:
DBA must acknowledge the failback on ASE1 by running “sp_companion” stored procedure with “resume” argument to complete failback procedure.
Database server setup.
Setting up ASE with High Availability option requires that you have a minimal knowledge of underlying failover cluster solution. Working closely with cluster engineer is advised. In short, main steps of the installation are:
Client connections.
Setup.
Client connections must be configured to properly connect against both companion servers and to properly failover. There are two things to keep in mind for database server connection address:
For instance, below you have the SQL.INI server entries for previous Active/Active setup:
[ASE1]
query=TCP,logical_hostname_1,4901
hafailover=ASE2
[ASE2]
query=TCP, logical_hostname_2,4901
hafailover=ASE1
Each HAFAILOVER entry refers to the other companion database server.
For JDBC clients, companion servers can be mentioned in the connection string directly like this: DriverManager.getConnection( "jdbc:sybase:Tds:logical_hostname_1:4901,logical_hostname_2:4901"). An alternative option is to mention both companion database servers with via a JNDI directory server.
Client connection setting can be quicly checked with isql client with –Q switch like this:
isql -S ASE1 -Q
Failover behaviour and transparent reconnection.
In case of a failover (of primary companion on secondary companion for instance) following happens:
In order to keep the connections against database server, a client application must enable High Availability support. HAFAILOVER flag must be set on client application for this. For CT Library applications, this is done on context or connection level with ct_config( CS_HAFAILOVER) or ct_con_props( CS_HAFAILOVER) APIs. For JDBC connection, REQUEST_HA_SESSION connection property must be set to “true”. Basically, enabling HAFAILOVER flag causes the client layer to reconnect automatically against companion database server.
Database context is consistent on database side thanks to database recovery. Nevertheless, application context (temporary tables, open cursors …) is possibly lost and must be restored. When a failover occurs, an exception is raised by the by SYBASE client layer (in JDBC/jCONNECT SQL exception JZ0F2 is thrown ‘Sybase high-availability failover has occurred. The current transaction is aborted, but the connection is still usable. Retry your transaction.’ ).
Application should catch and handle this exception. In particular, aborted transactions should be re-submitted.
Conclusion.
SAP ASE with High Availability option is an enhancement compared to failover cluster vendor solutions.
Having a companion database server already up and running increases the level of resilience of the system because:
Moreover, SAP ASE with High Availability option is more transparent for applications. If properly configured, client connections are automatically reconnected. Application layer will receive a feedback informing that a failover occurred, HA-aware client layer will automatically reconnect against the companion database server.
In my next post, I will describe another server availability solution: ASE Cluster Edition.
References:
[1] “SAP Sybase Adaptive Server Enterprise Getting Started with the Sybase Database and the SAP System”
http://www.sdn.sap.com/irj/scn/go/portal/prtroot/docs/library/uuid/0040e969-b4a1-2f10-998d-e0eeec6fb...
[2] “Using Sybase Failover in a High Availability System” - Adaptive Server® Enterprise 15.7 Document ID: DC00356-01-1570-02
http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc00356.1570/pdf/ha.pdf
[3] "jConnect for JDBC 7.0 Programmers Reference > Programming Information > Working with databases > Implementing high availability failover support" - Chapter 2: Programming Information /Implementing failover in jConnect
----
Stay in the conversation by following SAP Services on SCN
Follow along throughout the event on Twitter at @SAPServices