In today’s IT world, competitors compete. SAP HANA has competitors in the market that present a product they market as being similar to ours. When your competitor feels the heat from your product, they will often make public comparisons, presented in such a way as to make their product compare favorably. This is not news, this is just business. Sometimes the comparisons can be gross misrepresentations of the truth about the abilities of their products versus ours. This is also not news, but it happens.
But just because someone makes an argument, this does not make it true. And it certainly does not make it right to deliberately, and perhaps even maliciously, try to mislead potential customers. Is it ethical? No. Does it happen? Yes. That’s why customers need to believe what they see, not what they hear. SAP HANA is a product whose strengths and value can be seen. We do not have to use smoke and mirrors (or a whitepaper presented with the ingestible value of cotton candy) to make our case.
SAP HANA has come a long way in the last two years and, thanks to close working partnerships with hardware and software vendors, as well as leveraging SAP's own application features across a range of products, we have great solutions for customers.
There is no single ‘best’ solution, as each customer’s set of requirements are unique. It is for this reason that SAP provides flexibility and choice, with solutions that enable customers to utilize SAP HANA in enterprise-class environments with reliability and certainty that operations will continue in the event of a failure.
As we see increasing momentum in the adoption of mission-critical applications like Suite on HANA, we find more and more often that customers are seeking information on topics of scalability and high availability, among others. Several case studies on these very topics will be out soon to show how SAP HANA is in fact being used in productive environments. I will link back to them here when they are released.
For the full technical details, see the excellent documents just posted by my colleague Chaim Bendelac, now updated for SAP HANA SP6:
Additionally, here is my take on some facts about some of the ways in which SAP HANA is designed and delivered to meet requirements for mission-critical applications.
SAP HANA supports both scale-up and scale-out approaches. If customers have not maximized the use of a single server, databases can grow within that server to whatever their hardware solution permits.
Additionally, hardware partners have varying cluster configurations to accommodate virtually any customer requirement, up to 56 nodes and 56TB of main memory, which could easily hold hundreds of terabytes of data in a single database. Native parallelism in SAP HANA allows near-linear scalability across nodes, as has been proven in massive-scale testing such as the 100-node petabyte test.
Customers and partners have reported the manageability of the scale-out process as simple and straightforward, when done in a planned manner, with minimal to no interruption.
Backup & Recovery:
Natively, SAP HANA provides robust capabilities for backup and restore, as has been tested many times in customer environments. Additionally, new features have been added over time to allow, for example, backing up production to restore on a smaller cluster or server configuration for quality assurance and testing purposes.
Additionally, in keeping with the general overall strategy, SAP is working closely with partners to not only extend our backup and recovery mechanisms and capabilities, but also to support customers by enabling their existing backup and recovery technologies to be extended to SAP HANA. Symantec NetBackup is the first product to be certified for use with SAP HANA, and several others are in the process of gaining certification.
HA features are critical to customers, and have been at the core of the design of SAP HANA since its inception. Working closely with partners, customers can benefit from combined solutions to reduce and minimize hardware, software and network failures. In addition to this, SAP HANA has native capabilities for recovering from all sorts of failures, ranging from minor faults to major outages, including:
- Automatic restart of services, wherein SAP HANA core services are continually monitored and restarted if necessary.
- Fault recovery from host outages, which will keep a clustered database running in the event of a complete server failure.
- Near Zero Downtime Upgrades - this allows customers to create a secondary "shadow" instance, which can be decoupled from the primary instance, patched in place of production, quiesced with production data, and then take over as production.
Including the latest changes in SP6, SAP HANA has a broad range of optional configurations for Disaster Recovery environments, both hardware and software-managed. Using the capabilities existing today, customers can partake of solutions that allow for RTO and RPO values, as well as investments, to meet their requirements. Possible solutions today include:
- Synchronous storage replication solutions offered by five hardware vendors – HP, IBM, Hitachi, Cisco and Fujitsu. These are the same enterprise-grade solutions that customers are benefitting from in non-SAP HANA configurations, and these solutions are also now certified for customer use with SAP HANA.
- Synchronous System Replication configurations, (aka: software replication) managed by the SAP HANA kernel. This ensures that every single change made in production will be made also in your Disaster Recovery environment immediately, and that the SAP HANA database manages the process end-to-end. The result of this is a zero-RPO configuration. If a change has been committed in production, you can guarantee it exists also in DR. (note, data from disk is always sent asynchronously, just as data is written to disk asynchronously on the local system. Still, this is a synchronous option as data is updated in memory in DR and logged synchronously)
- Fully Asynchronous replication, managed by SAP HANA. This allows for huge distances between production and DR, by sending all changes asynchronously to the disaster recovery environment, and is suitable for many customer requirements that allow for higher RPO SLAs in order to reduce costs and/or increase distance between data centers. Being managed by the SAP HANA kernel, this also will allow for some degree of asymmetrical, and even multi-vendor, hardware configurations in DR in order to meet additional customer requirements.
- Backup/log shipping. As the least expensive method to maintain a DR environment, customers can ship backups and logs on a regular basis to rebuild production in case of a failure at an alternate site. Depending on customer requirements, this is often an inexpensive and viable option.
When I want technical information, I find it's best to go to the source. SAP provides lots of sources for information on HANA. You can go to conferences, you can go to forums and blogs on SCN, you can even go to the SAP HANA Academy, or the implementation cookbooks on saphana.com. What I don't recommend, when you want to learn how something in HANA works, is to go to a competing vendor. Other vendors will often say that "they don't do things like we do, and our way is best!" But we would prefer to tell our story openly and leave it to customers to decide whether our solutions meet their requirements or not.
For further reading, please see the following documents (SP6 documentation will be out very soon!):
SAP HANA: Operations, High Availability, and Data Center Readiness (video from SAP TechEd 2012 – SP5)
Scalability – SAP HANA (SP5)