If, like many of us, you have been running SAP for years, it was a bit of a shock when SAP introduced HANA. For decades users had the choice of what hardware their SAP applications and their associated databases would run on. Users could choose (with restrictions) the OS, the hardware vendor, the attached storage, back-end switches and so on. Many enterprises developed standard building blocks for deploying new SAP systems that could easily be rolled out. Then SAP introduced HANA.
Unlike the vast majority of previous SAP applications, HANA could only be run on SAP HANA certified appliances. HANA had been in the works for years and was a big change in SAP’s stance on being database agnostic. If HANA were to succeed it needed to be introduced in a controlled way that would safeguard HANA’s performance. As an in-memory database, the hardware and software requirements for HANA are different to a traditional RDBMS. Therefore SAP chose to deploy HANA in pre-built appliances, mitigating the risk of HANA being deployed on unsuitable hardware / software.
All SAP HANA appliances are mandated to user certain Intel Xeon processors and either SuSE Linux or Red Hat Linux (although early appliances were only certified for SuSE). The hardware vendor has control of the storage layer but must meet or exceed certain KPIs mandated in the appliance specification. Unlike traditional RDBMSs, SAP HANA appliances are sized by memory. That’s it. Not SAPS, not disk IO, just memory. The appliance will always supply enough CPU, disk and network performance to support the given memory size.
The idea is that if you want to run your application on HANA you run a sizing exercise that churns out a number. This number is the physical memory size of the HANA system you need. This number is handed to your hardware partner. The hardware partner should then take into consideration a number of factors, like the application to run on HANA (OLAP or OLTP), scale up or scale out and HA/DR requirements. You would then be presented with the cost for an appropriate HANA appliance/s.* *
HANA appliances are frequently referred to as ‘black boxes’. They arrive, are installed by a third party and (should) just work. It is a model that worked well for a number of years. Yet there was a big problem. Every instance of HANA needed to run on an appliance, and I mean EVERY instance. For production and pre-production, running a full production appliance is a good thing. You will always get the expected performance. But you also need an appliance for every other environment. Non-production environments don’t need to give you full appliance level performance, it is cripplingly expensive to deploy appliances for every HANA instance. SAP allow MCOS for non-production workloads, but this still means having an appliance with enough memory for all the HANA instances you need as memory in HANA solutions cannot be over committed.
The cost of running an appliance for all workloads has lead some customer to reduce the number of environments down to just production, QA and development This is not ideal. Projects I’ve worked on before have had environments for production, pre-production and then separate development and QA systems for BAU and project tracks (and sometime other instances such as sandbox and training too). This would be very expensive if all HANA DB instances were to be appliances, and may have deterred some users from adopting HANA.
These changes can be summarised as:
- Appliances are no longer necessary for non-production.
- Non production systems can use any Intel Xeon E7 or E7 v2 processor.
- Non production systems can use any Intel Xeon E5 v2 processor, but are restricted to a maximum two sockets and 1.5TiB of memory.
- E7 and E7 v2 systems do not need to honour appliance memory ratios. The maximum amount of the memory supported is the maximum that is installable in the server.
- Standard appliance storage ratios do not need to be honoured, storage can be as low as 2x memory rather than 5x.
Although it is not an official term, we soon started to call these non production systems ‘white boxes’ as this seemed a reasonable antonym to ‘black boxes’.
White boxes can range from being slightly cheaper than a comparable appliance to being vastly cheaper and as you’d imagine the performance of white boxes can vary too.
To understand how deviating from the appliance model is likely to affect performance, you must understand the performance impact of each component that is replaced for a cheaper alternative. This topic will be covered in black box white box part two.