And so we begin with… On Prem.
If you are new to HANA, the deployment options that lay before may seem bewildering. This is for a good reason. There are a lot of them. In the early days, things were simple. If you needed HANA you bought an appliance. Appliances still play an important role, but now there are other options available. In this series of blogs, I’ll attempt to describe most of the options currently available for rolling out your HANA project. I’m going to split this subject into three parts, that will cover On Prem, Cloud and hybrid options for HANA. In this blog I’ll tackle an On Prem as well as some HANA basics.
Before we go over the options for deploying HANA, I thought it would be good to write a little about the underlying platforms that are supported. SAP HANA can be run on Intel x86_64 and IBM Power platforms. First to market was the x8664 platform which has been supported since HANA went GA in 2010. Power came later to market (2015) and has yet to pick up a sizeable market share. It is expected that IBM will retain many of its customers that are loyal to the Power platform as they migrate from third party databases to HANA. For customers who don’t already use IBM Power, Intel seems to be the platform of choice.
There are plenty of blogs and articles out on the internet that could better describe the differences between the Intel and Power architectures then I ever could, so I won’t try. You’ll have your own preferences and unless there is an overwhelming reason to change away from your preferred platform, you probably won’t.
On Prem options
The traditional approach of deploying into a data centre may seem old hat to many people in the agile web/dev world of devops, but in the world of HANA it remains highly relevant. HANA installations tend to be either systems of record or analytic systems that ETL from systems of record. Therefore, we’re talking enterprise. Many enterprises prefer to install into their own datacentres that they have full control over. Other customers shy away from the cloud because of data compliance and sovereignty issues. Whatever the reason, On Prem is alive and kicking when it comes to HANA.
When deploying On Prem there are three main options to go for which are discussed next.
If your implementation is small and unlikely to grow much, you may be able to use an Entry Level HANA system. Unlike the appliance (next section) the Entry Level HANA systems are based on reference hardware. They need to be built by the customer or a partner and are, unlike appliances, not fully supported by SAP.
SAP describe these systems as “…valid for specific service packs. Intel Xeon E5 v2/v3/v4 based 2-socket single node systems with minimum 8 cores per CPU only. The hardware was tested by the hardware partner with SAP LinuxLab. The systems are supported for SAP HANA.”
Various configuration are available and you can view these here.
These Entry Level systems can be scaled up to 1.5TiB, however, due to the high cost of 64GiB DIMMs 768GiB should be seen as the economical maximum of these systems.
In reality I don’t see many of these systems used for production but we see them used for smaller development and sandbox systems.
These systems are based on Intel Xeon processors, there are no official IBM Power equivalents.
The original deployment method for SAP HANA was by appliance. What I want to do here is delve into what that means. A HANA Appliance is really a package of hardware, software and services. The hardware part usually consists of a server with a prescribed amount of memory, compute power, storage and network connectivity. The hardware may consist of more than one physical device (maybe a server and a disk tray) but should be considered as a single unit. The software is the Linux OS (SLES or RHEL), any drivers or utilities required for the appliance and the SAP HANA application. The service element is everything that is required to install the appliance into the data centre as a functioning database server.
Appliances are certified by SAP. These certified appliances are then fully supported by SAP. SAP will investigate and attempt to resolve any performance issues or system defects of any kind, working with the hardware partners behind the scenes.
Appliances are sized by the amount of memory they provide. The only metric required to get the right appliance is how much memory you need. Everything else (compute power, storage, etc) is provided in the appliance. In terms of sizing, you can scale up or scale out. Scale up appliance are available up to 20TiB. Scale out appliances max out at 4TiB per node, but you can deploy up to 94 of them as a single HANA instance providing up to 376TiB of memory.
It is fair to say that for On Prem, appliances are seen as the safe option. Everything you need in one box. But just because it is safe doesn’t mean it is particularly convenient. Which brings us onto our next section.
HANA appliances are provided with everything you need to run HANA. Large enterprises however, may not want everything an appliance provides. The biggest area that customers are having problems with is appliance storage. In an appliance, storage is included. For scale up systems, the appliance storage is usually internal or directly attached. For many enterprises this is not ideal, as they have already standardised (as much as possible) onto a common storage platform. For example, customer A has standardised on NetApp storage and Lenovo Servers. When they implement HANA they would like to keep this arrangement, but storage with a Lenovo appliance is internal. This is a problem. The appliance becomes an exception. Because the storage is local it has to be backed up and restored differently. If storage replication is required, that will have to be done differently. Moreover, local storage may also have less availability than an enterprise storage platform.
SAP’s response to this problem is the Tailored Data Centre (TDI) programme. This allows some aspects of the appliance to be removed and replaced by the customer. Both the storage and/or networking can be replaced.
One misconception about TDI is that it is a ‘bring your own server’ model. This is not the case. Appliances must be used. The vendors provide TDI part numbers that do not include the usual internal storage. It is also a misconception that customers can utilise existing storage for production HANA workloads. The TDI programme states that storage to be used for productive HANA system must be dedicated to HANA and must be certified for use with HANA. A list of the currently certified storage systems can be found here.
The removal and replacement of networking only applies to scale-out systems. It is a requirement of scale out SAP HANA system that the nodes will be connected via a dedicated 10GbE (minimum) backend network for inter-node communication. With the appliance model, dedicated switches would be provided. However, the customer’s enterprise may have already adopted a particular switch vendor and not want to differ from the standard. The customer may replace the appliance switches with their own, but again, these switches should be dedicated.
The way TDI is supported is somewhat different to an appliance. The appliance is fully supported by SAP. A TDI customer must support whatever it is they remove from the appliance. For example, if a customer replaces appliance storage with enterprise storage, any storage issue needs to be resolved by the customer, not SAP. TDI offers more flexibility than the appliance. It allows closer integration with a customer’s standards and may allow some or all of the benefits of their enterprise storage such as snapshots and replication. This flexibility comes at the cost of longer and more complex installation over that of an appliance and without the convenience of the appliance support model.
Entry Level Systems are rarely used in production due to their size. Appliance and TDI basically have the same sizing profile as they based on the same hardware, they can scale up to 20TiB and out to over 300TiB. Appliances offer a quick way to deploy HANA by supplying everything in a single footprint. TDI offers the chance to uncouple the storage and inter-node networking from appliances, making HANA a better fit in your data centre but at the cost of a less convenient support model.
Next time I’ll explain what cloud options are available for SAP HANA and then in the third installment in the series we’ll explore hybrid cloud, compare all the deployment options and summarise.