In continuation of my first post, I will describe the first level of Business Continuity solutions with SAP SYBASE ASE: server recovery solutions. Server recovery solutions deal with restoring activity on a new server. I will focus on server side operations (how database service can be restored) and not client side (how client applications are redirected). The subject of client application redirection is an important one and deserves dedicated blog posts. I will describe three solutions: database & log shipping, synchronous transfer of transaction data, and shared system. These Business Continuity solutions can be used for SAP ERP using SAP SYBASE ASE as the database server.
Database and Log Shipping
Description:
The aim of this solution is to synchronize both database servers via backups. Data is backed up on the primary database server on a regular basis (with a scheduler or a cron facility), transferred to standby host and restored on standby database server. Usually transactions log backups are used (this method is known as log shipping). We have 2 database servers up and running. Primary database server is “active” (supporting client connections). Standby database server is used only in case of primary database server failure.
Configuration:
- 2 physical hosts (a primary host and a standby host).
- 2 disks arrays.
- 2 database servers started.
- Client connections are connected against “active” database server.
Failover:
In case of outage of the primary host, following happens:
- Standby database server is restored with most up to date state thanks to the last backup of the primary database server.
- Standby database server is designated as the “active” database server.
- Client connections are to be redirected to the new “active” database server.
Failback:
To failback to the primary host, use the following procedure:
- Stop client activity on standby host.
- Backup standby database, transfer it to primary host and reload it.
- Primary database server is designated as the “active” database server.
- Resume client activity and redirect client connections to new “active” database server.
Considerations:
- Two database servers running. Each host runs a database server, but only one is “active” at a time.
- Performance. Transaction log shipping is most performance effective (versus entire database shipping).
- Configuration syncing. Primary and standby database server global configurations must be kept in sync; when database server parameters are changed in active database server, they must be changed on standby database server as well. When the database is altered on “active” database server it should be altered on standby database server as well.
- Minimally logged operations. Minimally logged operations (like SELECT INTO, REORG REBUILD, …) can break log shipping application on standby database server; user applications must be checked to not use minimally logged operations or database option (“enforce dump tran sequence” available since ASE 15.7 ESD 2) must be turned on to forbid minimally logged activity.
- Clients redirection. Client connections must be prevented from accessing the “inactive” database server.
Challenges:
- Data loss. In case of a failure of the “active” database server, transactions that are not backed up would be lost. Frequency of backups must be tuned to achieve SLA requirements.
- Undefined downtime in case of failover. Failover process is manual and may take time for various reasons (failure detection, failover decision, redirection of client connections).
Implementation:
For implementation purposes, please check "Log Shipping, SAP on Sybase Adaptive Server Enterprise (Sybase ASE)". It details log shipping implementation in a very comprehensive way. It comes with following 2 scripts:
Synchronous Data Transfer
Description
The aim of the solution is to synchronize data via synchronous storage replication over SAN. Database LUNs of primary disks array storage are mirrored over SAN to remote LUNs of standby disk array storage. In case of failure of the primary host, the database server is restarted on standby host with mirrored data.
Configuration:
- 2 physical hosts (a primary host and a standby host).
- 2 disks arrays attached to a SAN.
- 1 remote mirroring solution.
- 2 database servers configured, (but only 1 is “started” at a time)
- 1 “active” database server started on “active” host.
Failover:
In case of outage of primary host, following happens:
- Standby database server is started on standby host.
- A database recovery is carried out and database is restored to consistent state ready for operations.
- Client connections are to be redirected to the new “active” database server.
Failback:
To failback to primary host, first step is to enable storage replication from standby to primary and then:
- Stop client activity on standby host.
- Shutdown database server on standby host.
- Start database server on primary host; primary database server is designated as the “active” database server.
- Resume client activity and redirect client connections to new “active” database server.
Considerations:
- One database server. Database server runs on one host at a time (on primary host or on standby host, not both).
- Data Integrity. No data loss due to LUNs synchronous replication.
- Configuration syncing. Database server configuration file must be kept in sync as well on both hosts (if not replicated).
- Performance impact. Performance requirement should be taken into account when building this kind of solution because of “synchronous writes” over network; “synchronous writes” means that primary storage would acknowledge a write operation only after remote standby would acknowledge it.
Challenges:
- Performance on WAN. Performance degrades with an increase in networking equipment between the primary and standby hosts.
- SAN Mirroring availability and cost. SAN Mirroring solutions are offered by major storage vendors. Nevertheless, remote mirroring solutions are not applicable for all types of storages. Remote mirroring solutions are usually licensed solutions. Their cost must be taken into account.
- Undefined downtime in case of failover. Failover process is manual and may take time for various reasons (failure detection, failover decision, client connections redirections).
- Risk of I/O level corruption. Bad storage firmwares can issue “bad writes” on primary LUNs and lead and the corruption would be propagated to the standby LUNs.
Shared Disk Systems
Description:
Database LUNs of shared disk array can be presented either to primary host or standby host. By default, LUNs are presented to the primary database server. If the primary host fails, then LUNs are presented to the standby database server. The database server can see use the shared storage from the host it is running on.
Configuration:
- 2 physical hosts (a primary host and a standby host)
- 1 shared disks array attached to both hosts
- 1 database server started on “active” host
Failover:
In case of outage of primary host, following happens:
- Standby host takes the ownership of data of shared disk array.
- Database server is restarted on standby host.
- A database recovery is carried out and database is restored to consistent state ready for operations.
- Client connections are to be redirected to new “active” database server.
Failback:
To failback to primary host:
- Stop client activity on standby host.
- Shutdown database server on standby host.
- Start database server on primary host; primary database server is designated as the “active” database server.
- Redirect client connections to new “active” database server.
Considerations:
- One database server. Database server runs on one host at a time (on primary host or on standby host, not both), depending on where database LUNs are presented.
- Resources utilization and sizing. Standby host is usually used (not an idle spare) and must be sufficiently sized to host failed over database server in addition to resource requirements for its own load.
- Team work. Presenting LUNs to a host is a manual task done by system or storage administrator. Database administrator must work in close coordination with the system and storage administration teams.
Challenges:
- Undefined downtime in case of failover.
- Split-brain avoidance. System must be designed to absolutely avoid simultaneous starting of database servers on both hosts. Doubly presented/attached data can lead to severe corruption.
These three Business Continuity solutions are not automatic. Human actions are required for failover/failback operations. In my next post, I will describe O/S cluster based solutions with SAP SYBASE ASE.
References:
"SAP Sybase Adaptive Server Enterprise Getting Started with the Sybase Database and the SAP System"
"Log Shipping, SAP on Sybase Adaptive Server Enterprise (Sybase ASE)"
"SAP Note: 1650511 SYB: High Availability Offerings with Sybase ASE"
----
Stay in the conversation by following SAP Services on SCN
Follow along throughout the event on Twitter at @SAPServices
----
