The Four Levels of Multi-tenancy

The goal of multi-tenancy is to maximize the resource sharing across multiple users while hiding the fact that these users are on the same server and ensuring optimal performance, Srinath said. He then cited the four levels of multi-tenancy that exist today. Level 1 gives each user a separate machine, which is not exactly multi-tenancy, Srinath noted. Level 2 gives a configurable instance to each user on a separate machine. Level 3 runs a single instance, but it is shared across multiple users. Level 4 is a scaled up version of Level 3, running multiple instances or services that can be shared across thousands of users.

“People have been doing this at the first level and second level for some time, but we are here to talk about how to implement the fourth level and support a lot of users,” Srinath said.

WSO2 Approach to Multi-tenancy

WSO2’s approach to delivering a multi-tenant platform is to break multi-tenancy down into three parts: execution, security and data. The execution model addresses business processes, workflows and mashups. The security model addresses ownership and authorization of both data and executions in the framework. The data model (storage) addresses user data and system runtime data.

WSO2 has implemented multi-tenancy on its core platform through storage, the execution model, and the security model, Srinath explained. “Each provides multi-tenancy, and the products that run on top are/become multi-tenant.”

Achieving Isolation

In multi-tenancy, there are three requirements: sharing, isolation, and support for large numbers of users. Isolation requires particular attention, since there is always some level of tradeoff between isolation and performance, Srinath said. He then reviewed the four types of isolation required for multi-tenancy, which have been implemented in the WSO2 Stratos cloud middleware platform and WSO2 StratosLive platform-as-a-service (PaaS).

Tenant Isolation. To achieve tenant isolation, each tenant is given an isolated security domain, providing each one with its own space. Each domain may then be multi-tenant and have its own set of users and permissions that enable users to access resources.

Data Multi-tenancy. There are three options for data multi-tenancy: separate databases, separate schemas, and shared schemas. The shared schema model, which is used in the WSO2 Governance Registry, allows for the most sharing. For isolation, the tenant ID is added to check and enforce permissions.

Execution Isolation. Srinath noted that Apache Axis2 has yielded a pleasant surprise in that it already separates state and execution logic. Because all WSO2 execution runs on Axis2, he noted that, “All we have to do is maintain everybody’s state separately.”

Creating a different Axis2 context for each stored tenant’s state provides isolation, Srinath explained. When executing a tenant, the Axis2 engine runs with the context and logic and allows for multi-tenancy. Java Security is used to make sure one tenant cannot access or tamper with another tenants’ data structures, file system data, etc.

Performance Isolation. No multi-tenant product or service is complete without performance isolation. However, this is a very challenging issue, Srinath observed. While he is continuing search for approaches to address this issue, the solution at this time is to monitor and audit processes and kill CPU-hogging processes.

“The four levels of multi-tenancy help you to separate real multi-tenancy from halfway ones,” Srinath noted. However, he added, “The work on multi-tenancy is not complete, and we welcome all ideas and code. We do this open source.”

To learn more about WSO2’s approach to implementing multi-tenancy, view Srinath’s full presentation here.