Platform as a Service (PaaS) Competency Center Blueprint
Left Curve   Right Curve
Multi-Tenancy (Non Virtualized)

Concept: Consolidated infrastructure is a key underlying technique of a private cloud which drives lower cost and more efficient server utilization. Consolidation, however, comes with the cost of complexity. When multiple Tenants are sharing the same underlying infrastructure it is important that a level of isolation is provided to keep Tenant data, transactions and users from intermingling. A natural first place to seek a Tenant partitioning strategy is to look at server virtualization. However server virtualization is only one option to consider.
Flexible Infrastructure
Implementation Plan:
Utilize WebLogic Server domains as isolation containers per Tenant for applications. Use database users and tablespaces as isolation containers for Tenant data.
Pre-requisites: None
Last Modified: 10/6/09

WebLogic server provides a natural partitioning mechanism with domains. Each domain is a logically managed set of application server nodes that may be part of zero or more clusters. One technique for partitioning the application servers is to allocate a single domain per cloud instance. WebLogic domains provide isolation for sets of applications and other configuration based information such as Data Sources, JNDI Tree, JMS Servers and Security Realms. Each domain is managed by a single Administration Server and the domain configuration is contained in a set of XML files.

There are several considerations to be taken into account when using WebLogic domains as your application partition:

  1. Possible Port conflicts
  2. More complex bookkeeping information during provisioning
  3. Moving partitions is not as simple as a virtualized solution

There are several benefits of using WebLogic domains for partitioning:

  1. Fewer software moving parts in the solution- all partitioning is done with WLS features out of the box.
  2. More cloud instances can be deployed on the same hardware compared to a virtualized solution. This is because each instance is the sum total of a set of Java Virtual Machines and do not require a full guest operating system running in the hypervisor.

Partitioning the database may be done in several ways. One brute force solution to data partitioning is to provide each Tenant with their own database. While this would provide complete isolation it is not an optimal use of resources. More commonly, a private cloud environment will be utilizing a shared highly available database instance such as Oracle RAC. RAC provides many key benefits to a private cloud implementation such as fault tolerance and automatic workload management. Due to the wide range of application types hosted on a private cloud infrastructure, RAC solves many of the tuning and availability issues faced with giving each cloud instance their own database server.

While RAC provides a single logical access point to a collection of physical database servers, it does not automatically provide multi-tenancy. To isolate Tenant data it is useful to use the following convention.

Each cloud instance is assigned to one RAC Service. The RAC Service provides a level of abstraction mapping to a JDBC Data Source that can be configured inside WebLogic Server. The RAC Service is defined with database schemas which will handle client connections from the application server. These schemas are marked as Preferred or Available indicating which instances should be used initially and then subsequently. Preferred schemas and available schemas are typically located on different hardware for disaster recovery purposes.

The use of RAC Services provides a clean separation between the JDBC connection settings in WebLogic Server and the actual database schemas handling requests. The cloud provider can establish different RAC Services to handle different database needs. For example, it is possible to designate RAC Services as follows:

  1. Databases not requiring HA or Load Balancing
  2. Databases needing HA and Load Balancing
  3. Databases just needing HA

A cloud instance is then provisioned the appropriate RAC Service based upon the service levels needed from the database.

Tenant isolation is managed by providing a tablespace for each cloud instance. This tablespace is created per cloud instance as part of the provisioning process and contains both the database users as well as the application data for the cloud. The physical storage of these tablespaces should be on highly available disk (e.g. RAID) and the actual storage of the files is best handled by Oracles Automatic Storage Manager (ASM). ASM provides a cluster filesystem and volume manager which is easily managed with Oracles Enterprise Manager.

Database resources can be governed inside the cloud using Oracles Database Resource Manager. For each schema provisioned, it is possible to associate a Resource Plan in Enterprise Manager which describes the percentage of system resources available to that cloud Tenant (or Resource Consumer Group). This is a fairly simple way of splitting up the pie of available database resources across multiple cloud instances and preventing one cloud instance from impacting the performance of other instances with runaway queries or updates.

Partition Example: Tenant A

As an example, consider Tenant A- requiring a cloud with full Load Balancing and High Availability. The cloud environment would provision Domain 1 which is a multi-node cluster spread across two physical machines. The nodes in the cluster would be configured to use RAC Service 1 which is mapped to two schemas on separate machines using redundant tablespace files.

Partition Example: Tenant B

Another example is Tenant B- who requires application load balancing and redundancy, and database fault tolerance without load balancing. Tenant B is provisioned Domain 3 which is a multi-node cluster spread across two physical servers. Each node in the cluster is configured with RAC Service 2 which has two schemas defined- a primary on Server 3 and a backup on Server 4. Storage for these schemas is handled by separate tablespace files.

Partition Example: Tenant C

As a final example, consider Tenant C- who has simple requirements (e.g. development needs) and is provisioned Domain 4, containing a single node. The node is configured with RAC Service 3 which has a single schema defined using a single tablespace. There is no fault tolerance or load balancing configured for this cloud instance.

Left Curve
Related Technologies
Right Curve
  WebLogic Server 11g
  Coherence 3.5.1
  Enterprise Manager 10g

Left Curve
Additional Resources
Right Curve

Oracle Cloud Computing Center