Multitenant Persitence with SAP HANA Service. Differences Between NEO and Cloud Foundry

[christophroth]

Hello,

we are currently evaluating cloud foundry after 4 years on NEO and there came up some question about multienant-architecture with the SAP HANA Service.

I've also read some guides like https://blogs.sap.com/2018/09/17/developing-multitenant-applications-on-sap-cloud-platform-cloud-fou..., but there are still open questions.

Lets first have a look, how we would implement multitenancy with SAP HANA Service in NEO, and what advantages we have:

On NEO we are using Multitenant-Database-Containers, to seperate the data of different tenants and we are creating one DataSource-Binding for each tenant. (Using dynamic data source lookups)

This architecture brings the following advantage:
- Data between tenants are strongly seperated
- Every tenants has its own database backups automatically managed by the SAP HANA System, so we are able to restore a backup for one tenant, without affecting any other tenant. link
- Memory usage per each tenant can be individuallly configured, to prevent one tenant to use all ressource or to crash other tenants
- Tenant containers and DataSource-Bindings can be added at runtime automatically via console client
- If the ressources of the database system are not enough anymore cause the tenants need more ressources or there are new tenants subscribing to the application, we are able to upsize the database system

So now lets have a look at a possible architecture in the Cloud Foundry environment:

On CF i would create a single SAP Hana Service, and would create 1 SAP HANA Schema Service Instance for each tenant and bind this to the application.

Now i see the following differences/problems:

- There are no multitenant database containers available at CF, so to seperate data between tenants we have only to serious options: "1 Schema per tenant, 1 Database Service Instance per Tenant". The problem with 1 Database Service Instance per tenant, is that this is a very expensive option, cause the minimum size for a database system is 32 GB and the recommended size 64 GB (4 Blocks). And there will also be additional maintenance effort cause there are more database systems to update, monitore and maintain. So we are currently looking at schema seperation per each tenant.
- With schema seperation we have found no way to create and restore backups per schema/tenant
- With schema seperation we have found no way to limit the memory usage per tenant
- On CF we have found no way to upsize a database system when new tenants subscribe or when the memory of the current system is not enough anymore
- A service-binding between a tenant and an application needs an application restart, cause the service information are provided via environment variables and cannot added ad runtime like in NEO

So now my questions are:
- Is my understanding of the SAP HANA Service in CF correct?
- Is there a way to get MDC-SAP-HANA-Systems in CF?
- Is there a possibility to create and restory backups per each schema/tenant in a non MDC-System?
- Is it possible to upsize a SAP HANA-Service in CF?
- Whats the recommended way to seperate tenant data in CF and SAP HANA (all Tutorials with code samples i found was done with a tenant descriptor column in the tables, but thats not an serious option for us)

Best regards

Christoph

[former_member189718 · Accepted solution]

Hi Christoph,

thanks for your question.

In addition to the referred blog, I can also recommend my blog for this in which I also shortly discuss the topic of HDI: https://blogs.sap.com/2018/09/26/multitenancy-architecture-on-sap-cloud-platform-cloud-foundry-envir...

To answer your specific questions:

1) Yes, our understanding is correct. The Hana Service either provides the HDI separation or you can instantiate a separate Hana Service instance per tenant.

2) Currently, backup and restore is only possible per HANA instance. If you want to restore a single tenant, you can restore the complete instance into a new instance and then export the specific HDI container and import it on the to be restored instance.

3) Upsizing is currently only possible by creating a new instance and migrate to it. You can also scale by creating a new instance and only provision new tenants to the new instance and keep existing tenants on the existing instance.

4) The recommended way depends on your requirements. As mentioned in my referred blog, basically you have the option to use a column, the HDI containers or the distinct HANA instance per tenant. I recommend the HDI container approach as this is the best compromise for data separation, extensibility and costs.

I see your concerns about upscaling, backups and the restart of applications, but, without committing timelines, I am aware that these topics are being addressed.

Best regards,

Jan

[christophroth · Accepted solution]

Hi Jan,

thanks for your answers.
Do have any additional links or information about using HDI-Container for Tenant-Seperation in CF? Like deployment of a container for a new tenant, or exporting/importing the container with data in a backup scenario?
The only tutorials i found, was about deploying the HDI-Containers via MTA or Web-IDE. Both cases does not seem to fit very well, when you have to create and deploy a new container at runtime, when a new tenant subscribes. (You don't want to change your MTA-descriptor for every tenant that subscribes or unsubscribes the application).

And are there any advantages of binding an HDI-Container vs an HANA-Schema to the applications?

Best regards,
Christoph

[norbert_paukner_1 · Accepted solution]

Hi Jan,

I'm also investigating on this multi-tenant topic currently and I'm just curious: for the HANA Service in AWS it seems that there was some kind of switch around June 4, 2018 according to "Find the right guide" in https://help.sap.com/viewer/a36ee1aa073e4e8e840573fb30a72d95/Cloud/en-US/1e9a6cb47e1b44f990a917b4bf8....

For versions before this date the creation of multiple Tenant Databases for a HANA service was possible, for versions after that you can just have a HANA service with one Tenant Database (same for GCP) and would have to create multiple HANA service instances in case schema separation within one Tenant Database would not be enough.

And according to https://help.sap.com/viewer/a12d484310c847d2bb7ce1f0283cdb1e/Cloud/en-US/177a99c1741a478eacbbd472b2b... for Azure regions it seems still possible to create Tenant Databases.

Is there something planned to do this switch also for Azure?

Or do you know if there is something planned to add the possibility back again in AWS to create/add further Tenant Databases to one HANA service?

I guess in this new SAP HANA Cloud (Services) the multiple Tenant Databases feature will not be added?

Thanks,
Norbert

[former_member189718 · Accepted solution]

Hi Norbert,

I am not an expert on the HANA Service. I assume this change will also come to Azure at some point. I am not aware of any plans to bring back this feature to AWS.

But this shouldn't make a difference: you can use the instance manager to create different instances of the HDI plan or you can use the same to create multiple HANA service instances.

Best regards,

Jan

[dhdbob26 · Accepted solution]

Hey Jan,

I'm working on multitenant java (springboot) app with HANA Cloud DB. Wondering if you went with HDI containers route ? if so , do you have any reference for java backend ?

How do we specifiy HDI conatiner size during its creation ?

[gopalanand · Accepted solution]

Hi anil.kumar195

To answer your question,

Part 1: for reference, you can follow this blog: SAAS getting started
Here you need to you Service manager to create HDI containers for each subscriber and then establish a connection based on user's tenant. Though it's a nodejs based reference application I hope this will help you.

Part 2: We don't specify the size of hdi container. It's created as a technical schema, The sizing is decided on your HANA database instance level. For further details, you can read this: HDI

Best regards,

Gopal