HANA Multitenant Database Containers, or HANA MDC, is something fairly new in the SAP world. It first became supported in SPS 09 (Revision 90), less than two years ago, in late 2014. Since it’s a new technology, there are relatively few customers using it. At oXya, we do have customers to which we helped implement MDC. In this blog I will describe the technology, what challenges it solves, what issues it actually creates, and which type of organizations can benefit from it.
Background: HANA before MDC
SAP HANA is an innovative in-memory database system. We’re taking large database systems, and we’re putting them all in-memory, which is pretty expensive from the hardware perspective – they need expensive hardware, with strong compute power and lots of memory.
Before HANA MDC, you had to have a separate SAP HANA instance – possibly on the same hardware, but still a separate SAP HANA instance – for each different database (meaning for each landscape). The meaning was that every time you wanted to install a new HANA system, you either had to buy a new physical appliance; or you had to install a new HANA instance for each different database, on the existing hardware.
The challenge is that HANA appliances are installed by the vendor, and delivered to the customer as an already-configured system. The vendor also certifies that the appliance was correctly configured. Now, if you want to install another HANA instance on that appliance, you either have to engage the appliance vendor again, for them to install another HANA instance in a certified manner; or the customer has to go through the painstaking steps of making sure that the new HANA instance is installed correctly.
In order to perform the installation, you needed a HANA expert to install the new instance, and that’s often done by the vendor that sells you the appliance. In other words, each new installation of HANA was complex, took a lot of time, and often may have also resulted in the need to purchase a new appliance.
All of the above is a rather inefficient way to install new HANA instances, and it obviously generated a lot of extra work.
Another challenge, as you probably guessed, was that the above method was very wasteful, with regards to hardware usage. Not only did SAP face the challenge of making the HANA install process quicker and easier, but also the challenge of reducing hardware costs, that was slowing down HANA sales. The hardware needed for this in-memory computing system is very expensive; SAP’s goal was to reduce hardware costs and footprint of the HANA landscape.
Let’s use an example, to explain all of the above. Imagine a customer (and we have an actual customer like that), who has SAP ERP and SAP BW (Business Suite applications), and they’re both running on HANA. Each of these applications has Sandbox, Development, Quality Assurance, and Production systems, all running on HANA. Before MDC, if the customer wanted to run their ERP on HANA, they needed to buy multiple appliances, one for each system:
- An appliance for Sandbox
- Separate appliance for Development
- Third appliance for Quality Assurance
- Fourth and separate appliance for Production.
So far we’re talking about four HANA appliances, and that’s only for their ERP application. If the customer wanted to duplicate their data and also run their BW on HANA, then they would need to buy additional appliances for the BW systems (Sandbox, Development, Quality Assurance, Production).
And of course, it’s not just about the hardware costs, but also a matter of license costs. Do additional instances also mean you needed additional licenses, therefore additional license costs?
Well, the answer in general is “Yes”, or sort of. As a general rule, HANA is licensed by the amount of memory that the application needs. There is a difference between using separate appliances, and using one larger appliance with MDC; that can affect not only hardware costs, but also (to a lesser degree) the licensing costs. I’ll explain that later on, when referring to MDC sizing.
So what is SAP HANA MDC?
SAP released a newer feature, Multitenant Database Containers (MDC), which is supported as of HANA SP9 revision 95 and higher. In a nutshell, MDC allows us to take multiple SAP systems, say 2 sandboxes, 1 ERP, 1 BW, 2 development systems and 2 quality assurance systems, and put them all on the same HANA appliance.
The beauty of it: once the hardware provider had provided the appliance and did the initial set-up for the HANA system, we can very quickly and easily create the new database containers for each of our different systems, and allows these different products to cohabitate in the same appliance.
The MDC feature provides huge economy savings in terms of hardware, because instead of buying a separate appliance for each system (or perhaps not an appliance for each system, but an appliance for each landscape – possibly have your ERP’s Dev and QA on one appliance, and the same for BW), you can now take all of these, put them all on a single appliance, and better utilize that hardware.
Of course, as a general rule, we're not going to mix production and non-production systems. So, we still need to separate the Production system. However, for all of our non-production systems, MDC introduced significant flexibility.
MDC does come with some challenges, and we hope that SAP will eliminate these challenges in the future. These are current challenges, so you are aware:
First, when you perform replication at present, you take your HANA system and you replicate the databases to another site. There is no ability to replicate just a single database tenant – you have to replicate everything. The replication treats all database tenants as a single database system, as opposed to completely independent database systems. Hence, in the case of a failover to a secondary site, you'd have to perform the failover for all HANA database tenants on that appliance, and not for just one database.
Second, there’s a challenge in terms of version maintenance. In a traditional SAP landscape, we apply patches gradually:
- We apply the patches to our Sandbox, and test
- Then, we apply the patches to the Development, and we test
- Then, we apply the patches to the QA system, and test again
- And only then, after multiple patching is done on non-production systems, plus testing, we patch the Production system.
The benefit of the above method is we can test patching in many different systems, before going to Production. The challenge with MDC is that when you apply patches to this multitenant environment – you’re applying patches to all the systems simultaneously, because it’s impossible to perform individual patching for each database tenant. Essentially, once you patch your HANA appliance through the MDC, you have patched all the environments that are on the appliance – all at the same time!
“But wait”, you may say, “is this really a challenge? Is patching everything a challenge? Don't you want to patch everything? Doesn’t it save you work and time?”
The answer is – take another look at the patching process I outlined above. Our goal is to prevent impact to the Production system. In an SAP environment, we perform multiple tests on patches in non-production systems, before implementing in Production. The way to ensure that patching is successful, and doesn't cause any negative impact, is by performing multiple iterations: first Sandbox, then Development, then QA. By the time you get to Production, you've already performed patching 3 times.
However, in the case of MDC, once you performed patching on your non-production MDC system, you’ve done that simultaneously to all the systems within the same appliance. You’re not getting those multiple iterations, which is a huge disadvantage.
Also, there’s another caveat to patching. Let’s say you have ERP and BW on the same appliance, and patching is only required for one product, but not for the other. In the case of MDC, we don’t have a choice – we have to patch them both, at the same time.
This patching challenge is not an insurmountable issue, but it is something to get used to. This is also another reason why the Production system must be separate from non-production – you certainly don’t want to do patching on Production without testing it first!
But all in all, and despite of the above challenges – MDC is a great technology. We're able to spin up new containers in minutes, with a simple command on the HANA system. This, as opposed to having to engage a HANA expert to install the new instance, or perhaps even purchase new hardware every time you need a new a system. MDC adds significant flexibility, and I believe SAP is working to enable the replication of individual containers, and it will be available in the near future.
Difference between HANA system and the Containers
One important thing to understand is the difference between the HANA system and the containers, as each container has its own SID (system ID), in addition to the SID for the HANA appliance itself. For a customer that is going to use MDC, it’s important to realize that they have to name their HANA appliance uniquely for the entire appliance, and then name each container based on its purpose. In other words, you have an SID for the HANA instance on the appliance, and then you have a separate SID for each container.
Let’s explain that using an example. Let’s say that the SID of the HANA appliance would be HA1. Then, we’ll give various names to the containers, usually according to some kind of a key. For example, we will use "Q" for quality assurance, “D” for Development, “E” or “B” for ERP and BW, and an "H" to indicate that it's a HANA system.
With the above method, your development ERP container could be “DEH”, and your development BW container could be “DBH”. The QA containers will be “QEH” and “QBH”.
Earlier, I mentioned sizing and said that customers may also save some money on license purchases. In order to explain that, let’s start with the traditional sizing for HANA, meaning separate appliances for each system.
HANA is a database, and each database system (Development, QA, Production, etc.) needs its own memory to contain its database. There are no savings in terms of reducing the volume of each database, because they stay the same, whether in separate HANA appliances or when using MDC, on one larger appliance.
However, when performing sizing, one doesn’t size just perfectly – you always leave room for growth, meaning a buffer. When you size for separate HANA systems (say one Dev and one QA), you will oversize for both systems, to make sure that you have sufficient space. However, when you do that, you often significantly oversize, and you actually “waste” hardware. In fact, I Can guarantee that if you look around the world, at various HANA systems, there's lots of memory and CPU that are not being used. Customers are paying for this over capacity, not only in hardware costs, but also in HANA licensing costs.
Consolidating systems omits the above, and provides great savings. When consolidating HANA databases, we don’t need to oversize for each database separately. We can better utilize the resources on the server, and oversize to a smaller extent, for all databases combined.
Basically, what you're saying is that if before we needed 2 appliances, let's say each 1 with half a terabyte of memory, then when we combine them all on the same appliance, we need actually 1 appliance with 1 terabyte, that's 2 halves and you may be able to save a little out of the 1 terabyte, put a little less because you don’t buffer twice or you don't oversize twice.
Take one of oXya’s customers, for example. This customer has 5 different HANA systems, with each database in need of 200GB (already includes space for future growth), meaning we need a total of 1TB. If you went ahead and bought separate appliances for each database, as was the case before MDC, then you would buy five appliances with 256GB each (5 x 256GB). This means you’re wasting more than 250GB, above and beyond your needs. These systems will be gravely underutilized.
However, when you consolidate those systems, then you only need to buy a 1TB appliance (which again, already includes space for future growth). Then, as some databases grow, those databases that need the additional resources are able to utilize them. Furthermore, not only do you better utilize the hardware and licenses, but you may even be able to add additional systems onto the same hardware, once it's running.
Having said all of the above, it’s important to understand that Sizing is a bit of an art (and not really a Science, as some people claim). When you perform sizing, you make assumptions regarding what is going to be once it’s running, and it doesn’t always happen this way. That’s one reason why there’s a tendency to oversize. When we're sharing several databases onto a single system using MDC, we're able to better utilize resources.
Come see us at SAP SAPPHIRE this week – stop by the Hitachi booth, look for the oXya team, and discuss your SAP challenges with us.
Sevag Mekhsian is a Service Delivery Manager at oXya, a Hitachi Group company. Sevag is an SAP expert with more than eight years of experience, the last four of which leading a team of ten SAP professionals, at oXya’s service center in New Jersey.
oXya, a Hitachi Group company, is a technical SAP consulting company, established in 1998. oXya provides ongoing managed services (outsourcing) for enterprises around the world. In addition, oXya helps customers that run SAP with various projects, including upgrades and migrations, including to SAP HANA. oXya currently employs more than 650 SAP experts, who service more than 330 enterprise customers with more than 300,000 SAP users around the world.