In this post, I will describe SRS Business Continuity solution based on Warm Standby feature.
Introduction.
SRS-based versus other Cluster-based Business Continuity solutions.
Before talking about SRS Business Continuity solutions and Warm/Standby, let’s compare them to other Business Continuity solutions. In my first posts, I described cluster-based Business Continuity solutions like O/S cluster, ASE CE, ASE with HA Option). These Business Continuity solutions differ in many ways from SRS Business Continuity solutions, although they achieve the same result (server availability). Unlike cluster-based solutions, SRS Business Continuity solutions (like Warm Standby) have following:
- Distributed structure
- No clusterware is used
- Data is duplicated. There are two (or more) occurrences of data with SRS Business Continuity Solution, whereas with cluster-based solutions there is only once occurrence of data.
- Improved availability and security
- Source and replicate data are both up and ready. They are online and quickly availaible.
- Availability of data is improved. Production activity is run on the source data and reporting or database maintenance activities can be offloaded on target(s). O/S Cluster-based solution do not offer this feature.
- The risk of data corruption is mitigated thanks to logical replication. In case of a data corruption, the corruption would occur only on one local storage. Failover clusters or disk-mirroring solution will usually propagate data corruptions.
With Warm Standby system, the database service loosely coupled from the Business Continuity solution. If SRS or some replication item fails, the database is still up an running.
Warm Standby in short.
A typical Warm Standby system consists in a pair of databases synchronized by SRS. The scope of the replication is the database (not the server). All the actions within the source database (a.k.a. active database) are replicated to the target database (a.k.a. standby database). DML and DDL operations are logically replicated. Data is modified on the active database and standby database may support readonly clients or database maintenance.
A unique feature of Warm Standby is that the replication flow can be inverted: the roles of the active and the standby database can be exchanged. Old standby database becomes active database and old active becomes standby database.
Availability.
SRS is supported on major 64 bit platforms like HPUX Itanium, AIX, Solaris and Linux and Windows and virtualized enviroments like VMware VSphere ESXi. The current version is SRS 15.7.1 SP110.
Warm Standby is the oldest Business Continuity solution offered by SRS. Warm Standby feature is available for ASE since 1996 with SRS release 11.0. It can be implemented for following databases:
- SAP SYBASE ASE - SAP SYBASE ASE : All ASE versions supported.
- ORACLE - ORACLE: ORACLE 10,11,12 supported.
Check “Product Compatibility” for complete support information [1].
Use cases.
Warm Standby may be used in various use cases. Below, you will find three basic use cases.
Server availability.
This picture depicts a typical Warm Standby setup used for server availability purposes.
- Warm and Standby systems are hosted in the same location (New York data center).
- Both databases are SAP ASE
- In normal operations:
- Warm system is used by production applications.
- Standby system is used for reporting purposes.
- In case of a planned downtime (for maintenance purposes) or a unplanned downtime of host #1: production applications can be switched to host #2
Site availability.
This picture depicts a Warm Standby setup used for site availability purposes.
- Warm and Standby systems are hosted in different locations (New York data center and New Jersey City data center).
- Both databases are SAP ASE
- In normal operations:
- Warm system is used by production applications.
- Standby system is used to run database administration tasks like data reorganization or consistency checks. This offloads the active database from heavy or blocking maintenance activities.
- In case of a planned downtime (for maintenance purposes) or a unplanned downtime of New York data center: production applications can be switched to host #2 of the New Jersey data center.
Site availability with non SAP database.
This picture depicts a Warm Standby setup with non SAP database used for site availability purposes.
- Warm and Standby systems are hosted in different locations (New York data center and New Jersey City data center).
- Source and target databases are ORACLE databases.
- Replication middleware, SRS and Replication Agent are hosted on a different host than the databases. Latest version of Replication Agent for ORACLE can be setup on a different machine than the source database. It is able to remotely extract transactions from ORACLE redo and archive logs.
- In normal operations:
- Warm system is used by production applications.
- Standby system is not used.
- In case of a planned downtime (for maintenance purposes) or a unplanned downtime of New York data center:” production applications can be switched to host #3 of the New Jersey data center.
The standby system is only used here for Disaster Recovery purposes. But it be used for offloading reports as well like in the previous use case.
Setting up a Warm Standby.
Warm Standby Requirements and Restrictions.
Be familiar with the requirements and restrictions of Replication Server Warm Standby applications.
- One Replication Server manages both the active and standby databases. Both the active and standby databases must be from the same vendor.
- Replication Server does not switch client applications to the standby database.
- Run the data server for the active and standby databases on different machines. Putting the active and standby databases on the same data server or hardware resources undermines the benefits of the warm standby feature.
- Replication Server does not support Warm Standby replication between different platforms.
- SAP recommends that tables in the active and standby databases should have a primary key defined.
Physical and Logical connections.
Basically, a Warm Standby is a database bi-directional replication mechanism. To enable bi-directional replication, the Warm Standby relies on two kind of database connections:
- physical connections
A physical database connection is a connection that links SRS to a (source or target) database. As a Warm Standby system is composed by a pair of databases, there are always two physical database connections.
A physical connection involves a particular database of a particular dataserver. A physical connection is defined as: PHYSICAL_DATASERVER_NAME.PHYSICAL_DATABASE_NAME, where PHYSICAL_DATASERVER_NAME is an actual dataserver name defined in the $SYBASE/interfaces file of SRS and PHYSICAL_DATABASE_NAME is the actual name of the database. For instance: MY_DATASERVER.my_database. - logical connection
A Warm Standby requires a particular database connection named “logical” connection. A logical connection must be considered as an abstract replication object. It is used to define and manage the direction of the replication flow between the source and the target database. From syntax perspective, a logical connection looks like a physical connection as it is defined as a composed name: LOGICAL_DATASERVER_NAME.LOGICAL_DATABASE_NAME. The difference is that both logical names do not need to match an actual dataserver or database name.
Having a logical connection help us in many ways: it is used to invert the replication flow, publish logical data and subscribe to logical data.
Installation steps.
Installing a Warm Standby is a straighforward process.
What is remarkable is that setting up the replication system is done without any downtime. Replication is enabled and standby database is synchronized with active database without disruption thanks to “dump marker” feature of SRS. When using “dump marker” technique, a backup is performed on the active database while client applications are modifying data. This backup will be used to initialize the standby database. SRS will notice the backup completion thanks to special markers (“dump markers”). It will then enable replication process transparently.
Some words about “dump markers”. “Dump markers” are replication system information, they are added in replication flow to tag and separate the intial database content (hold in database backup) from the actual new transactions to replicate. Basically “dump markers” are conveyed by the replication flow just like DML or DDL operations. SRS is aware of these markers and will only start the replication once it sees them. Initialization with “dump marker” is available for both SAP ASE and ORACLE. On ORACLE, online backup is performed with RMAN utility and SCN number is used by “dump marker” to tag the backup completion. On SAP ASE online backup is performed with DUMP DATABASE or DUMP TRANSACTION.
To setup a Warm Standby system, you can run following procedure (prior installation of SRS is assumed):
1. Create a logical connection on the replication server
create logical connection to <logical dataserver>.<logical database>
2. Create a connection from the replication server to the active database on the replication server
create connection to <warm_server>.<warm_database>
set error class to rs_sqlserver_error_class
set function string class to rs_sqlserver_function_class
set username to <maintenance_user>
set password to <maintenance_user_password>
with log transfer on
as active for <logical dataserver>.<logical database>
3. Create a login on the replication server
create user <rep-agent_user> set password <rep-agent_password>
grant connect source to <rep-agent_user>
4. Configure the source Replication Agent
use < warm_database >
exec sp_config_rep_agent "<database>", "enable", "<repserver>", "<rep-agent_user>", "<rep-agent_password>"
exec sp_config_rep_agent "<database>", "send warm standby xacts", true
5. Mark the source database for replication (here DML + DDL operations replicated)
exec sp_reptostandby "<database>","all"
6. Create a connection from the replication server to the standby server
create connection to <standby_server>.<standby_database>
set error class to rs_sqlserver_error_class
set function string class to rs_sqlserver_function_class
set username to <maintenance_user>
set password to <maintenance_user_password>
with log transfer on as standby
for <logical dataserver>.<logical database>
use dump marker
7. Backup the database on the active server
8. Transfer and restore the database dump into the standby server
9. Start the connection from the replication server to the standby database
resume connection to <standby_server>.<standby_database>
rs_init utility can be used as well to setup a Warm Standby system.
Failover.
Failover is the process of exchanging the role of the active and standby database. In Warm Standby terminology, a failover is refered as a switch. A failover can be planned or an unplanned event. In case of of a planned switch (for maintenance purposes for example), all the ongoing transactions are guaranteed to be replicated by SRS. There is no transaction loss. Whereas, in case of an unplanned failover (because of an outage of primary database or host), due to the asynchronous replication mechanism used by SRS, some trailing transactions may be lost.
During a failover, two events occur: the database is controlled by another host and then the clients follow the database. First look how to switch a database from one dataserver to another.
Data failover : replication switch.
Switching a database is a quick process. It is mainly driven by SRS itself. Following procedure is to failover database “my_database“ from “my_physical_dataserver_1“ to “my_physical_dataserver_2”
1. Shutdown the Replication Agent of the active database on “my_physical_dataserver_1“
exec sp_stop_rep_agent my_database
2. Issue a switch command at Replication Server
switch active for my_logical_dataserver.my_database to my_physical_dataserver_2.my_database
3. Monitor the switch at Replication Server
admin logical_status, my_logical_dataserver.my_database
When switch is over, run next step.
4. Restart the Replication Agent of the new active database, here “my_physical_dataserver_2“
exec sp_start_rep_agent my_database
5. Resume the connection to the new standby database
resume connection to my_physical_dataserver_1.my_database
Switching information is logged in the errolog of the replication server. It always must be checked during a failover.
Clients failover.
With cluster-based solutions, database and client failover is done in a single operation thanks to logical host or virtual IP address. With SRS and Warm Standby, redirecting clients in case of failover require additional steps. To failover clients following solutions are usually used:
- Update Network Directory Services
DNS or LDAP directory services can be updated to redirect the client applications to the new active dataserver.
- Update SYBASE Directory Services
On client side, client applications directory services files ($SYBASE/interfaces or SQL.INI) a double entry (with both addresses/ports of database server) must be defined. For thin clients like JDBC, the connection string must mention both database servers.But on server side, only the listener of the “active” dataserver is started. In case of a failover, the listener of the old “active” is shutdown and the listener of the new “active” is started.
- Use a gateway like OpenSwitch
It is possible to use an intermediary gateway to redirect client connections. OpenSwitch is a special Open Server program aimed to redirect connections. It has a specific module named “Coordination Module” for SRS which is able to manage both database switch and client failover.
Conclusions.
Some general remarks to complete this post:
- This post introduces basic Warm Standby configurations, with a pair of databases only. Warm Standby can be used in more sophisticated replication architectures. Logical database connections of Warm Standby can be the source or the target of replication system.
- Warm Standby is a replication technique, its scope is the database level. If you have a dataserver with multiple databases, multiple Warm Standby pairs can be setup. Multiple Warm Standby database pairs work fine except in the case of cross-database referential constraints.
- Warm Standby uses one and only one SRS. A careful reader of this post would have noticed that in the use cases I implemented the SRS on the nominal primary host. This is arbitrary. The location of SRS must be chosen depending of customer context and requirements.
- From SRS perspective, active and standby systems can be different in power, in storage. Nevertheless for Disaster/Recovery purposes having similar hosts is advised.
- Like failover clusters, it is recommended to perform switches in a regular basis (once a month for instance). Knowledge and practical experience of replication switch is important for database administrators.
- Warm /Standby is not supported for Business Suite on ASE applications. HA/DR for ASE on Business Suite is the supported SRS Business continuity solution.
- As final remark to show how Warm Standby improves availability and risk mitigation. In addition to offloading reporting activities, database maintenance, Warm Standby can be very useful for avoiding downtime when upgrading a database. The standby database can be upgraded to version+1 whereas active database stays in current version. Once the standby database is fully upgraded and checked, a quick switch can be performed to use the new database version. Minimal downtime occurs. Replication flow is inverted for replicating to old database version. Old version database is still synced and switching back to old version is still possible.
Next post will detail Multi Standby Availability (MSA) Business Continuity solution. Stay tuned.
References:
[1] “Replication Server 15.7.1 SP100 > Release Bulletin Replication Server 15.7.1 SP100 for UNIX and Linux > Product Compatibility”
http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc01232.1571100/doc/html/ang1270721750...
[2] “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...
[3] “Adaptive Server® Enterprise Helps Ensure Critical SAP Applications are Always Available to Organizations”
http://www.sap.com/corporate-en/news.epx?PressID=21357
[4] “SAP Sybase Replication Server” documentation
http://help.sap.com/replication-server
[5] “ASE-to-ASE Replication Quick Start Guide Replication Server® 15.7.1 SP100” – Chapter Warm Standby Applications
http://infocenter.sybase.com/help/topic/com.sybase.infocenter.dc01251.1571100/doc/pdf/rs_qs.pdf
[6] SAP Note 1650511 SYB: High Availability Offerings with SAP ASE
Stay in the conversation by following SAP Services on
Check our Database Services Content Library
Follow along throughout the event on Twitter at @SAPServices
5 Comments
