Contact
NTT DATA Business Solutions
Bret Applegate | February 20, 2018

Solving the Mystery Behind SAP HANA Data Center Integration

HANA

As the calendar pages continue to flip toward 2027, for SAP customers there is a growing sense of urgency to start planning the move of their ERP systems to the HANA platform. As S/4HANA continues to mature, both in terms of the product and methodologies to help you get there, the chances that you will start to plan and move to S/4HANA in the next few months is becoming more and more likely.

My guess is that this project is at least on the radar for most who are reading this. Most of the attention and fanfare with respect to navigating the challenges of this move are centered on the application layer and the potential disruption to the user base, key users, and functional testers associated with both pre-kickoff preparations and post-kickoff project activities.

But, for on premise customers, significant attention should also be paid to determining the right data center integration approach for the installation of the new HANA architecture that will be required to run this new platform.

The key considerations to examine when trying to integrate HANA into your current data center can be broken down into the following categories:

  1. Hardware Architecture Approach – Appliance or Tailored Data Center Integration (TDI)
  2. Storage Considerations
  3. Networking Requirements
  4. Virtualization or Bare Metal

Hardware Architecture Approach

From an overall architecture perspective, there is one key decision to make: Do you want to go with a pre-configured HANA appliance or build out a Tailored Data Center Integration (TDI) approach based on certified commodity hardware and leveraging existing data center components where possible?

There are some key advantages to both approaches. The appliance approach was the original method for deploying HANA when it was first released. It comes preconfigured from your hardware vendor and contains all the necessary compute, back end storage, and networking switch components required to run a HANA installation of a given size.

Appliances typically come in a variety of “t-shirt” sizes, so you can pick the one that will fit the sizing needs of your particular environment, taking into account both current sizing requirements and room for growth. With an appliance, the hardware vendor will even install the HANA software for you, so once the appliance is put in place it is ready to go.

The advantages to this approach are fairly clear. You are essentially buying HANA in a box, and it is as close to “plug and play” as you can get. There are some disadvantages, however. There is no inherent redundancy to a single appliance approach. For example, on production systems you have to consider a failover or spare appliance to be used in the event of a critical hardware failure on the primary appliance. The sizing is also inflexible. You have to decide on day one how much to buy. If you over or underestimate the requirement you will either be spending money on capacity that may not get used for years down the road, or even worse, run out of capacity early on and potentially have to buy a new, larger appliance.

Storage and Networking Considerations

In its simplest form, the TDI approach allows you to purchase HANA certified compute capacity only and leverage your existing networking and back end storage infrastructure to support the remaining architecture requirements. The simplest form assumes that you have the necessary network and storage infrastructure in place to meet the HANA performance requirements. For the network layer, this means 10 Gbit bandwidth between your HANA database server and the S/4HANA application server. For storage, it means running HANA certified enterprise storage.

You can review the SAP Certified and Supported SAP HANA Hardware Directory here. The information on this page contains everything you will need to determine which compute and storage platforms are certified for HANA. However, also keep in mind that you don’t have to rely on your own navigation of this to determine hardware support. Your hardware vendor should also be well versed in the HANA requirements, and will be able to help you down this path.

The advantage to the TDI approach comes in the form of reduced cost and capacity flexibility. Assuming your existing storage is supported, you only have to be concerned with buying servers with the right memory configuration to support your initial need. As your system capacity requirements grow, you will be able to scale SAN storage as you normally would, and compute capacity can be added either by buying a larger server or simply adding additional memory to an existing server. This is called “scale up.” The scale up approach to growing your environment should be discussed with your hardware vendor up front so that you have a plan for how to achieve the proper balance of spare compute capacity and a plan for scaling up when required.

Virtualize or Bare Metal

When choosing the TDI approach, which has become the most common approach to deploying HANA, there is one additional question that needs to be answered. The question to be answered is whether or not to deploy HANA in a virtualized architecture approach.

Virtualizing SAP HANA brings a lot of flexibility, scalability, and hardware redundancy benefits that cannot be easily achieved via a bare metal architecture approach. The hypervisors currently supported for production use cases of HANA include VMWare, Hitachi LPAR, Huawei FusionSphere, and IBM PowerVM. If you are currently running one of these virtual platforms in your data center, it will be important to explore the potential benefits to leveraging that architecture and expertise for your HANA environment.

SAP provides some tools that can be very beneficial to TDI customers wanting to validate their HANA architecture and installation. One of the most useful is called the SAP HANA Hardware Configuration Check Tool (HWCCT). The HWCCT runs tests against your HANA systems to help validate that your hardware architecture and deployment meets the minimum requirements defined by SAP for productive HANA use.

Among the checks performed by the HWCCT are the following key validations:

  • Validation of physical hardware
  • Validation of operating system configuration
  • Validation of i/o throughput and latency between HANA server and back end storage

You can find all the information that you need to download, configure, and run the tool in SAP Notes 1943937 and 2235581.

There are a lot of factors to consider when planning your hardware architecture approach to SAP HANA, going beyond even what is presented in this article. Factors such as Disaster Recovery, backup and restore approach, and high availability also need to be considered.

The hardware investment can be significant, so it is important that much care and thought is put into the approach so that you can choose the best and most cost effective way to roll out HANA in your data center.

Do you feel overwhelmed by the information provided in this article? Another great way to ensure that your HANA landscape runs on the most cost effective, scalable,  reliable, and robust hardware platform possible is to partner with a Managed Cloud provider who is deeply experienced in running, migrating, and administering SAP and HANA workloads. Download our free expert paper – What to look for in a Managed Cloud provider – to learn more!