Enabling multi-tenancy in HANA based cloud applications
Multi-tenancy is the key common attribute of both public and private clouds, and it applies to all three layers of a cloud: Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) and Software-as-a-Service (SaaS). Various scenarios demand many applications and development processes to have multiple tenants (data store and processing nodes). For example if you are developing an application where the same code and data has to undergo various phases of SDLC (development, testing…) then you can enable a multi-tenanted HANA environment. The following blog describes technical steps and solutions to achieve this goal. Please keep in mind that this document is a novel way to achieve multi-tenancy.
From the very earlier versions of many operating systems, we see the availability of logical volume managers (LVM). Irrespective of any OS, LVMs helps to manage hard disk farms by allowing disks to be added and replaced without downtime or service disruption, in combination with hot swapping. LVM allows file systems to be easily resized later as needed. You can perform consistent backups by taking snapshots of the logical volumes. LVMs help you to assign authenticated users to work on specific data or data area. SAP has collaborated with many hardware vendors (HP, EMC, Netapp Storage, etc…) who provide LVM managers to connect to the storage systems. Some of these storages are in a single disk whereas some are on storage area network (SAN). LVM based storage helps to achieve following application considerations; Scalability, High availability and Disaster tolerance. See the figure (1) below to understand a sample logical volume landscape.
In this architecture, you see two hardware storages being partitioned into 10 physical partitions and 3 logical volumes and assigned for different activities (development, unit testing and MIT of an application). You assign different users to these volumes and separate the issues of data isolation. Each volume is dedicated for a specific task for a set of users with isolation and non-isolation of data. Once this task is completed, perform a load of these data from LVMs into the required HANA in-memory processor instance and process the data. Refer figure (2) details. Apart from the regular data, SAP HANA persists two types of data to storage: transaction redo logs, and data changes in the form of save points. A transaction redo log is used to record a change. A save point overwrites the previous save point, but it is possible to freeze a save point for future use; this is called a database snapshot. Snapshots can be replicated into the LVMs in the form of full data backups, which can be used to restore a database to a specific point in time. This can be useful in the event of data corruption, for instance. In addition to data backups, smaller periodic log backups ensure the ability to recover from fatal storage faults with minimal loss of data.
You can achieve the following design characteristics for a multi-tenancy using this design principle
- Cost effectiveness
- Isolated patching and updates
- Isolated upgrades
- Tenant specific metadata.
Watch out this space later for more details.