7 Tips and Resources for Cost-optimizing SAP HANA Infrastructure

Zora Caklovic

Posted by Zora Caklovic on November 6, 2014

More by this author

Are you planning to migrate to SAP HANA? Here are a few tips that will help you come up with the most cost-optimized HANA landscape configuration for your migration.
Tip #1: Size your application before you look at the SAP HANA server
Proper sizing of the SAP HANA server is very important. If you undersize the server – you will have performance issues, and if you oversize the server – you will pay for extra capacity that you do not need.
SAP has developed a comprehensive set of tools and resources to help customers with sizing their HANA workloads. SAP Quick Sizer tool is a quick and easy way for customers to determine the CPU, memory, and SAPS requirements for running their workloads on SAP HANA. Check the SAP HANA Sizing Overview document to quickly find what tools and resources to use to size the different HANA workloads, including:
  • Sizing New Applications, ” Initial Sizing” section – provides an overview of the steps and resources for sizing stand- alone HANA, SAP Business Suite on HANA, SAP HANA Enterprise Search, Industry Solutions powered by SAP HANA, SAP NetWeaver BW powered by SAP HANA, and other sizing guidelines for using HANA as a database.
  • Migrating to SAP HANA Applications, “Productive Sizing” section – contains the sizing guidelines to help you determine HANA system requirements when migrating your existing applications to HANA.
  • Sidecard Scenarios Sizing section – describes the sizing process for running SAP HANA Enterprise Search, CO-PA Accelerator, and other SAP Applications on SAP HANA in a sidecard scenario.
Tip #2: Determine the deployment model for SAP HANA that’s best for your Data Center infrastructure strategy
The ever-expanding SAP partner ecosystem offers a wide range of HANA appliance reference architecture models optimally designed and built to satisfy each deployment use case. Customers can choose from more than four hundred SAP HANA certified configuration systems offering unprecedented scalability and fine-grain memory sizes ranging from 128GB to 12TB. Besides the single server configurations, customers can easily create multi-node scale-out configurations by networking multiple nodes together to enable support for their largest SAP HANA requirements.

SAP knows that each customer’s set of requirements are unique, so you get to choose from a number of deployment options for SAP HANA to meet your every business need:

  1. The appliance delivery model provides an easy and fast way for deploying SAP HANA by leveraging preconfigured hardware set-up and preinstalled software packages fully supported by SAP.
  2. Tailored Data Center Integration (TDI) deployment model provides SAP HANA customers with increased flexibility and TCO savings by allowing them to leverage their existing hardware components (e.g. storage, networking) and operation processes. With TDI approach, HANA installation needs to be done by customer and customer aligns with each hardware partner on individual support model.
  3. Customers that have standardized on having their Data Center operations virtualized can leverage SAP HANA on VMware deployment model (currently in General Availability for single HANA VM and Controlled Availability for multiple HANA VMs).
  4. Finally, customers can choose the SAP HANA Enterprise Cloud service. This fully managed cloud service allows you to deploy, maintain, integrate, and extend in-memory applications from SAP in a private cloud environment—providing cloud elasticity and flexibility with subscription based pricing.
Additionally, SAP has recently expanded operating system options by providing support for SAP HANA on Red Hat Enterprise Linux in addition to its initial support for SUSE Linux Enterprise Server (SLES).This wide selection of configurations and deployment options empowers SAP HANA customers to achieve business performance and innovation while retaining their choice of IT architectures.
Tip #3: Explore carefully your options for scale-up, before deciding to go with a scale-out deployment model.
Understand the benefits of scale-up before you decide to scale-out:
  • With a scale-up, single node model, you have 1 server (minimal footprint), 1 operating system to update/patch/upgrade, and 1 box to operate/manage and provide power supply for.
  • With a scale-out, multiple node approach – you not only need more room and more power in your Data Center to deploy multiple server boxes, but also your operational/management costs for cluster systems will be much higher than for the single-node systems. Although scale-out provides more hardware flexibility and requires less hardware costs initially, it requires more upfront knowledge about data, application, and hardware than scale-up.
In summary, always scale-up first and go to scale-out only if you really have to. Most customers find that SAP HANA’s high compression rate combined with its high scalability (up to 2TB – OLAP and up to 12 TB – OLTP) will easily meet their business requirements. SAP HANA scalability constantly grows, spurred on by advances in multicore technologies, providing new ways to meet the most demanding scalability requirements of our largest customers.
Tip #4: Fully understand extra options available for reducing the cost of your non-production systems
Carefully review SAP HANA TCO savings for non-production use cases to determine the most cost-efficient approach for your non-productive landscape. The cost of DEV/QA hardware can represent a significant portion of the total cost of your SAP HANA system landscape. In a typical SAP landscape, for each PROD system there can be anywhere between 2 to 9 corresponding DEV/QA boxes.
SAP always had less stringent hardware requirements for SAP HANA non-production systems. For example, the sizing guidelines for non-production systems allowed customers to use a 2x times higher core-to-memory ratio than the one used for production systems.
This summer, SAP made additional steps to further relax hardware requirements resulting in potentially significant new cost savings for customers. For more details, see this blog: Cost-Optimized SAP HANA Infrastructure for Non-Production Usage.
Tip #5: Chose the right option among various High Availability/Disaster Recovery (HA/DR) models including the choice of cost-optimized vs performance-optimized System Replication
When it comes to SAP HANA total cost of ownership (TCO), one of the main cost-drivers is related to lowering the management and operations costs by designing an efficient landscape. In order to minimize IT costs, customers can use the servers on the secondary system for non-productive SAP HANA systems.
SAP HANA System Replication solution used in the HA/DR landscape design can be configured for either the cost-optimized or the performance-optimized mode of operation. One of the roles of the SAP HANA System Replication (SR) capability is to prepare the secondary hardware for shortening take-overs and performance ramps after a system failover. In a cost-optimized mode of operation the hardware on secondary site is used for DEV/QA purposes, so the system recovery time will take longer (since data cannot be pre-loaded into the main memory of the secondary node in preparation for take-over). By enabling customers to use their secondary hardware resources for non-production, SAP HANA helps drive down TCO by allowing customers to consolidate their environment.
Tip #6: Request a quote from at least two SAP HANA technology partners once you have finalized your landscape design
Once you know the sizing (CPU, memory, SAPS), HA/DR configuration, and deployment model for your applications, make sure to request a quote from at least two certified SAP HANA appliance and storage partners – even if you already have a preferred hardware partner. SAP HANA vendors are ready to price their offerings competitively – getting multiple quotes can help you with negotiating the best price for your deployment infrastructure.
Tip #7: Before you go live, validate and take advantage of services offered with your software and hardware licenses
Always make sure to run some additional testing before you go live. Customers often find that their requirements have changed during the project lifetime (scope creep), so make sure to re-validate your initial SAP HANA system sizings. First run the stress and performance tests to optimize the KPIs for your production workloads before you go into production. You will also want to take advantage of SAP HANA go-live-checks and any other service offered in your SAP support license (see HANA GTM Resources & Sales Community / Content / SAP HANA Services ) or by your hardware partner.
Conclusion Tip: With SAP HANA, you get many choices to help you Simplify Your IT and Lower TCO
SAP HANA provides customers with a variety of configuration and deployment choices to meet every businesses need and budget. The tips above will help you maximize your IT and achieve increased economics out of your SAP HANA infrastructure and resources.
High flexibility and openness is at the core of SAP HANA strategy for helping customers lower their TCO and maximize performance and efficiency. According to the recent Forrester Study: “Cost Savings with SAP HANA”, organizations opting to implement SAP HANA could expect to see their software costs fall by more than 70 percent, their hardware costs by 15 percent, and their administration and development costs by 20 percent!
So I’ll just wrap it up by saying this: Join the rapidly growing SAP HANA customer base and follow the tips above when deploying HANA into your data centers to rapidly transform your business and maximize your ROI.
Stay tuned for more exciting updates, and thanks for visiting!
VN:F [1.9.22_1171]
Average User Rating
Rating: 5.0/5 (11 votes cast)
7 Tips and Resources for Cost-optimizing SAP HANA Infrastructure, 5.0 out of 5 based on 11 ratings