The goal of multitenancy is to maximize resource sharing by allowing multiple users (tenants) to log in and use a single severserver/cluster at the same time, in a tenant-isolated manner. That is, each user is given the experience of using his/her own server, rather than a shared environment. Multitenancy ensures optimal performance of the system's resources such as memory and hardware and also secures each tenant's personal data.
...
- Tenant isolation: Each tenant has its own domain, which the other tenants cannot access.
- Data isolation: Each tenant can manage its data securely in an isolated manner.
- Execution isolation: Each tenant can carry out business processes and workflows independent of the other tenants. No action of a tenant is triggered or inhibited by another tenant.Performance Isolation: No tenant has an impact on the performance of another tenant.
A tenant is an isolated domain. The users within this domain can manage their own data and perform their own transactions without being affected by actions carried out in other domains.
...
WSO2 Carbon provides a number of Admin services which have special privileges to manage the server. These admin services are deployed in the super tenant. Other tenants can make use of these admin services to manage their deployment. The admin services operate in a tenant aware fashion. Thus, privileges and restrictions that apply to any client using an admin service are taken into account.
Resource sharing
WSO2 Carbon supports the following methods for sharing resources among tenants:
- Private Jet mode: This method allows the load of a tenant ID to be deployed in a single tenant mode. A single tenant is allocated an entire service cluster. The purpose of this approach is to allow special privileges (such as priority processing and improved performance) to a tenant.
- Separation at hardware level: This method allows different tenants to share a common set of resources, but each tenant has to run its own operating system. This approach helps to achieve a high level of isolation, but it also incurs a high overhead cost.
- Separation at JVM level: This method allows tenants to share the same operating system. This is done by enabling each tenant to run a separate JVM instance in the operating system.
- Native multitenancy: This method involves allowing all the tenants to share a single JVM instance. This method minimises the overhead cost.
...
Tenant loading policy
Lazy loading is a design pattern used specifically in cloud deployments to prolong the initialization of an object or artifact until it is requested by a tenant or an internal process.
Tenants
Lazy loading of tenants is a feature that is built into all WSO2 products. This feature ensures that all the tenants are not loaded at the time the server starts in an environment with multiple tenants. Instead, they are loaded only when a request is made to a particular tenant. If a tenant is not utilized for a certain period of time (30 minutes by default), it will be unloaded from the memory.
You can change the default time period allowed for tenant inactiveness by adding -Dtenant.idle.time=<time_in_minutes> java property to the startup scrip of the product (./wso2server.sh file for Linux andwso2server.bat for Windows) as shown below.
| Code Block |
|---|
JAVA_OPTS \
-Dtenant.idle.time=30 \ |
Artifacts
Lazy loading of artifacts is a feature that is used by some WSO2 products, which can be enabled in the <PRODUCT_HOME>/repository/conf/carbon.xml file. The deployer that handles lazy loading of artifacts is called the GhostDeployer. A flag to enable or disable the Ghost Deployer is shown below. This is set to false by default because the Ghost Deployer works only with the HTTP/S transports. Therefore, if other transports are used, the Ghost Deployer does not have to be enabled.
| Code Block |
|---|
<GhostDeployment>
<Enabled>false</Enabled>
<PartialUpdate>false</PartialUpdate>
</GhostDeployment> |
When a stand-alone WSO2 product instance is started with lazy loading enabled, its services, applications and other artifacts are not deployed immediately. They are first loaded in the Ghost form and the actual artifact is deployed only when a request for the artifact is made. In addition, if an artifact has not been utilized for a certain period of time, it will be unloaded from the memory.
When lazy loading of artifacts is enabled for PaaS deployments, lazy loading applies both for tenants as well as a tenant artifacts. As a result, lazy loading is applicable on both levels for a tenant in a cloud environment. Therefore, the associated performance improvements and resource utilization efficiencies are optimal. In WSO2 products based on Carbon 4.4.0 or later versions, you have the option of setting the required tenant loading policy by enabling either Lazy Loading or Eager Loading of tenants. Additionally, you can separately control the loading policy for web applications and axis2 services deployed in your tenants using the GhostDeployment setting.
See Configuring the Tenant Loading Policy for more information.
Restrictions
The following restrictions are imposed to ensure that each individual tenant has the required level of isolation and maintains fine-grained security control over its own services without affecting the other tenants.
...