Always On? Sybase? You must be kidding…
Well, [SAP] Sybase has always been well known (and coveted) for its replication technology. Sybase Replication Server is a well established, rock-solidly stable product allowing homo- or heterogeneous replication solutions or different types and topologies across most platforms. But as opposed to other DBMS vendors (say Microsoft?) the solution was always kept separate from ASE server.
It looks like SAP has decided to change this at last. ASE 16 SP02 has finally bundled replication server into the core installation package – that is if you purchase the HADR ASE option…
What’s in the package? Let’s have a closer look. The last ISUG issue has a brief description of the solution, but since I have not found an open reference to this document and since the only other option is to read official product documentation I decided to summarize it here for those who do not have access to it.
ASE 16 SP02 came out with quite a few enhancements – Always On falls under the “Availability Enhancement” hood. As the option name suggests Always On has both HA & DR capabilities to choose from. It promises:
- Zero data loss (HA)
- Transparent Client fail-over
- Planned/Unplanned fail-over support
- Soft DB quiesce for planned fail-over without interrupting applications
- Zero downtime upgrades for minor & major DB releases
- Automated fault detection and handling
- Ability to leverage replicate DB in enforced read-only mode with zero user administration
Replication server has most of these capabilities in the past and indeed it is the infrastructure for the Always On option. Yet, having them all bundled together is indeed a huge step forward. I love in particular the transparent fail-over and automated fault detection – forced read only sounds nice too.
As said – the option comes in two configurations: HA & DR.
HA configuration encompasses two database servers tied in synchronous data replication mode (apparently relying on RS 157 SP300 capabilities of synchronous replication) – a pair of ASEs with a pair of dedicated RS applying transaction directly to the companion side with only one node being active at a time:
DR configuration replication mode is a-synchronous (although ISUG specifies otherwise – a typo?..). This is a familiar topology we have been used with Sybase Replication Server for years – a pair of ASEs each with a dedicated RS connected through a direct route to speed up message delivery to the companion side:
I am very curious how simple the management of HADR option is and how scalable is the topology behind it. I’ve been busy testing replication server for the last couple of months (replicating from an old ASE 15.x release to a new ASE 16 SP01PL2 in either direction). Although the setup part is pretty easy, one of the hurdles I have been stumbling on was the volume of data transferred between various RS components. In particular the pressure on the inbound queue. In the HA configuration above the RS responsible for applying transaction to the companion ASE seems to be sitting close to the companion ASE rather than the primary ASE.
As of today when replication agent follows transactions from the primary log to the inbound queue it translates each update/delete command into a command listing all of the primary table columns. For wide tables this impacts the volume of data moved across network pretty badly (we’ve lodged CR to deal with this – CR791846). As minimal column support kicks in only for the outbound queue I am very curious to see what the out-of-the-box HA implementation is able to achieve (unless it is based on stream replication rather than transaction replication). In the testing I have been performing any latency introduced to the chain RA – inQ was threatening to blow the primary ASE transaction log – the nightmare for any DBA messing up with replication server. And I have not been testing synchronous replication even! I also wonder if HADR option includes various ASO enhancements introduced into RS for the past couple of years.
In short, HADR is our there – love it or leave it.
I hope we will go with the former but only time will tell…
Have fun,
ATM.
ps. I wonder what are the pricing differences between HADR option vs. RS CORE (+ASO).
True, full HADR, eh SAP?
Does that mean you finally, finally handle a virtual IP/name and automatic failover? Otherwise it ain't gonna be "real" HADR. Right?
ASE 12.0 handled this with HA option - but you didn't need ip/name failover for HA as we transparently failed the connections without it. ASE/CE extended it further with 15.0. ASE Always-On with 16sp02 eliminates the HW requirements of CE and OS requirements of ASE/HA.
The reason most folks (and sounds like yourself) had issues was you tried to use ASE/HA in the same extremely limited/OS cluser only fashion that other DBMS's supported.
Nice guess. Indeed most of what I actually saw implemented in 12.x were cold failover clusters. I wouldn't call them HA because we looked at hours of downtime on failover (redo/undo pass).
There were a couple of environments using RS to achieve HA but these achieved it by interfacing with OS level cluster software, not Sybase interfaces.
And TBH I never saw anything beyond a pilot that got connection failvoer working - the app needed to be built from the ground up to "get" that form of DR... Not very practical for the kind of system I find myself DBA for, unless your devs are willing to extensively rework your app. Put the extra licensing costs on top of that and I was never able to sell it to exec.
With (other vendor) AlwaysOn AGs the virtual name/IP makes it so that legacy apps can gain many HADR benefits with minimal modification... As long as you understand that their connect will drop on failover, which most of our apps can live with quite happily.
Hmmmm....if you don't care about app dropping connection, then nothing needed to be changed with any of them (ASE/HA, ASE/CE or HADR). All you need is the second node in the interfaces and a HAFAILOVER line...
12.x was definitely slower due to recovery speed although HA was a tad faster due PFTS (page flush time stamps).....12.5.x did some reworking of recovery speed and 15.7 did a lot of recovery speed work. But as HADR is a full up and running redundant system, recovery speed isn't the issue. ....and if you failover the ip, you can always start a dynamic listener on it.
HADR gives you only the option to have one active node and fail over using the cockpit gui. If it has been possible to configure two-way MSA topology using the new gui one might use DNS/load balancer to switch from one node to the other. I don't think, however, that HADR will ever allow this topology. It's 5 minutes installation/configuration using command line. I'm afraid HADR setup will be pretty rigid: it will do what it does the way it does, no customization.
Btw. I can't find SCC binaries for SRS above 3.3 anywhere on the marketplace/sap one. Has it been removed? 3.3 version fails to connect to mail server 🙁 . Any thoughts?
It's not that we don't care about a dropped connection. But a dropped/rolled back transaction in our environment is as bad as a dropped connection. We can tolerate them to a certain extent and auto-reconnect helps reduce the perception of both planned and unplanned outages.
Many of our legacy apps don't use SQL.INI, though. Instead they use various JDBC/ODBC/OLEDB/whatever drivers. Some of which don't support the failover partner options (although some do). We are also in the position where we have problems using the current 15.x or 16.x drivers because of the debilitating stability and integrity issues.
For the remainder of our applications, including our core software, the long recovery times in older ASE HA models makes it an unacceptable option for our core products. 3+ hours for failover definitely takes the HA out of our HADR!
Hot standby is definitely a cornerstone of true HADR - you can't have HA without it! Not for larger, busier databases. The new iteration of ASE HADR might be useful in our core software if we can get licensing approved and development done and... Yeah it'll take corporate level sponsorship to get there if we can't treat the current app as legacy.
So I guess my perspective is very much a practical one, rather than a theoretical one. In practice the lack of vIP/vName leaves many of me with legacy systems that can't benefit from HADR. It's been our experience across our MS DB environment and I guess I'm foreseeing the same in the ASE space.
Great post Andrew
Thanks.
Do you know if an OS Cluster software is needed as it was in the original ASE Ha option?
(i guees it is needed)
Thank you
Regards
Jose
Hi Jose,
No OS Cluster software needed
Unfortunately, that ISUG post was based on WP that was done prior to product release. The actual GA version only supports (currently) HADR ....and not the DR/local topology. Q4 will add the multi-node (with distance) as well as external replication support and possibly a DITY approach for the DR only (as that is something that we may not officially support until we get some clarity about the real requirements for this....)
In response to the latency - yes, it includes and pretunes all the ASO options. We and customers have tested bcp and large (multimillion row) deletes/updates.
Jeff,
Thank you.
So , could this solution be an alternative (or better solution ) to ASE Cluster Edition as you commented that CE would be only available in Linux?
Also , in terms of implementation , costs, , ect "ASE Always On" efforts look more simpler compared to CE ..?
Regards
Jose
As said by others - no HW dependencies for this one (almost).
I've posted another article on how this thing looks - you may find it here if you are interested:
HADR: A Glimpse at ASE HADR Instance & beyond...
HADR uses both ASO and stream replication - which is still kept in secrecy by SAP product documentation team (had to add this one 😛 ). Hopefully one day we will be able to DIY...
Andrew,
thanks a lot
Regards
Jose
Hi, somebody can help me?. I have a couple of questions. Using ASE 16sp02 Always-on option can I use the standby server to generate reports or queries in read-only mode? The customer must pay extra value?