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:
- Vendor Failover cluster solution integration
- Two database servers cluster
- Active/Passive, Active/Active configuration
- Shorter failover duration for large database configuration
- Transparent reconnection
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:
- HP UX – Service Guard 11.19
- IBM AIX – PowerHA System Mirror 6.2
- Sun Solaris - Sun Cluster 3.2, VCS 5.0
- RHEL 5.0 / VCS 5.0 ; RHEL 6.0 / VCS 5.1 SP1
- SuSE Enterprise 11 / VCS 5.1
- Windows 2008 R2 – Microsoft Cluster Server
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:
- Finance database devices are exported from node1
- Finance database devices are imported on node2
- HA layer of ASE2 database server is aware of cluster change and will integrate failed over devices
- ASE2 database server will proceed to the recovery of the databases
- Finance application connections can reconnect against ASE2 and resume on ASE database server
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:
- Database devices are exported from node1
- Database devices are imported on node2
- HA layer of ASE2 database server is aware of cluster change and will integrate failed over devices
- ASE2 database server will proceed to the recovery of the databases
- Finance application can reconnect against ASE2 and resume on the companion database server
- ASE2 companion database server serves both Finance and HR application
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:
- The Finance databases are unmounted on the ASE2 database server
- Their associated devices are released from ASE2 database server
- The Logical volumes on O/S cluster layer are exported from node2
- The Logical volumes on O/S cluster layer are imported on node1
- The vendor cluster layer will restart ASE1 database server with the newly database devices
- Databases will be recovered by ASE1 on node1
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:
- Setting up underlying cluster solution
- Cheking underlying cluster solution and failover/failback capabilities
- Installing ASE software on both nodes or on a shared disk (both options have their pros and cons)
- Installing ASE_HA license option. License can be installed in served or unserved mode.
- Create database server with cluster resources (disk, IP) but in standalone mode
- Run installhasvss SYBASE ASE script on UNIX platform (or insthasv on Windows) to install High Availability specific stored procedures and objects
- Fill interfaces file on UNIX platform or sql.ini on Windows (check next section)
- Configure High Availability specific parameters on primary database server (HA option relies on CIS layer; CIS must be properly configured).
- Run “sp_companion” stored procedure with “configure” argument on the primary database server
- If this is a symmetric scenario, then un “sp_companion” stored procedure with “configure” argument on the secondary database server
- Cheking failover/failback capabilities with the database servers
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:
- Always mention logical hostname or floating IP address (as with failover cluster).
- Always mention both companion servers; for clients that are using a directory services file ($SYBASE/INI/SQL.INI or $SYBASE/interfaces file) an extra entry with HAFAILOVER keyword must be added.
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:
- a database recovery is performed by secondary server; incomplete transactions are rollbacked
- all client connections are dropped by default
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:
- The companion database server’s process is there ready to accept databases. Physical resources of the companion database were already granted by the operating system layer. Resource shortage like lack of memory will not impend the database server.
- During the database failover, only the recovery of user databases is performed. Temporary databases recovery, memory allocation phases do not occur. This may reduces failover duration for large database server configuration.
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
1 Comment
