1 Oracle WebLogic Server Multitenant
This chapter introduces WebLogic Server MT and describes its use in multitenant environments.
This chapter includes the following sections:
Note:
Many new WebLogic Server MT features such as resource groups, resource group templates, and deployment plan overrides are also available in the 12.2.1, non-MT version of WebLogic Server. This chapter notes when a given feature is available in the non-MT version and refers to the WebLogic Server documentation and online help where appropriate.
About WebLogic Server MT
Multitenancy in WebLogic Server provides a sharable infrastructure for use by multiple organizations. These organizations are a conceptual grouping of your own choosing, which you can think of as tenants. By allowing one domain to support multiple tenants, WebLogic Server MT improves density and achieves a more efficient use of resources while eliminating the hurdles typically present when trying to share multiple applications: runtime cross-application effect, security differences, data commingling, and administrative challenges.
WebLogic Server MT provides resource isolation within a domain partition, an administrative and runtime slice of a WebLogic Server domain that is dedicated to running application instances and related resources for a tenant. Domain partitions achieve greater density by allowing application instances and related resources to share the domain, WebLogic Server itself, the Java Virtual Machine (JVM), and the operating system while isolating tenant-specific application data, configuration, and runtime traffic, as shown in Figure 1-1.
Figure 1-1 WebLogic Server Domain Partitions
Description of "Figure 1-1 WebLogic Server Domain Partitions "
Each domain partition has its own runtime copy of the applications and resources. Changes in how WebLogic Server handles classloading provide both application isolation and efficiency. Deploying to multitenant environments requires no changes to your applications. For example, you could run multiple instances of a payroll application in different domain partitions without modifying the application.
WebLogic Server MT enables an end to end multitenant infrastructure, including multitenancy from the load balancer to the middle tier and cache tier, and to the database tier. WebLogic Server MT extends the Oracle WebLogic Server Enterprise Edition and Oracle WebLogic Suite products, and includes the following components:
-
Oracle WebLogic Server MT, which enables the consolidation of applications into fewer domains (by allowing partitions within domains) while maintaining secure isolation
-
WebLogic MT extensions to Java SE Advanced, which enables memory, CPU and I/O isolation, monitoring, and management for applications within a JVM
-
Oracle WebLogic Coherence Enterprise Edition to Grid Edition option, which enables the consolidation of caches into fewer Oracle Coherence clusters while maintaining secure isolation
-
Oracle Traffic Director, which provides WebLogic Server MT-aware and fully integrated tenant-aware local load balancing
For detailed licensing information, see "Oracle WebLogic Server Multitenant" in the Oracle Fusion Middleware Licensing Information User Manual.
WebLogic Server MT Supports Only Java EE Applications
In this release of WebLogic Server MT, only Java Platform, Enterprise Edition (Java EE) applications are supported. Products that depend on Oracle Java Required Files (JRF) are not supported.
JRF consists of those components not included in the WebLogic Server installation that provide common functionality for Oracle business applications and application frameworks. JRF consists of a number of independently developed libraries and applications that are deployed into a common location. The following components are considered part of JRF: Oracle Application Development Framework, Oracle Fusion Middleware Audit Framework, Dynamic Monitoring Service, Fabric Common, HTTP Client, Infrastructure Security, Java Object Cache, JMX Framework, JPS, logging, MDS, OJSP.Next, Oracle Web Services, Oracle Web Services Manager, Oracle TopLink, UCP, XDK.
This means that WebLogic Server MT does not support the following products:
-
Oracle Web Services Manager
-
Oracle SOA Suite
-
Oracle Application Development Framework (Oracle ADF)
-
Oracle WebCenter
-
Oracle Service Bus
-
Oracle Enterprise Scheduler
-
Oracle WebLogic Service Component Architecture (SCA)
Key Concepts in WebLogic Server MT
In addition to domain partitions, WebLogic Server MT includes these new concepts.
Tenants
Distinct user organizations, such as different external companies (for example, CompanyA and CompanyB), or different departments within a single company (for example, HR and Finance), that use applications and resources within a WebLogic Server domain.
A tenant is a logical grouping of your own choosing; it is not a configurable object. That is, you manage domain partitions, not tenants.
A tenant's identity is the association of a given user with a given tenant. For example, you might choose to associate the tenant Finance with a specific domain partition called Finance-partition.
The system identifies which tenant a given user belongs to from the user's identity as prescribed by the user identity store. Further, the user's identity helps the system enforce what that user will be authorized to do as he or she moves throughout the system, including but not limited to, which tenant the user belongs to.
Resource Groups
A named collection of (typically) related deployable resources, such as Java EE applications and the data sources, JMS artifacts, and other resources that the applications use.
A traditional WebLogic Server domain may contain many types of deployable resources: Java EE applications, JMS servers and queues, data sources, and such. In this traditional model, if an application suite contains multiple Java EE applications and various resources that support those applications, the administrator defines these resources and deploys these applications individually rather than as a coherent unit.
WebLogic Server MT introduces resource groups, simply as a convenient way to group together Java EE applications and the resources they use into a distinct administrative unit within the domain. The resources and applications are fully qualified in that the administrator provides all the information needed to start or connect to those resources, including credentials for connecting to a data source and targeting information for Java EE applications. A resource group will either contain these deployable resources directly or refer to a resource group template that defines the resources. Resource groups can be defined at the domain level, or be specific to a domain partition.
All the resources in or referenced by a resource group are targeted together (to the same target). Resource groups can be started and stopped.
Resource Group Templates
A named, domain-level collection of deployable resources intended to be used as a pattern by (usually) multiple resource groups. Each resource group that refers to a given template will have its own runtime copies of the resources defined in the template. A resource group template is a convenient way to define and replicate resources for multiple tenants. Resource group templates make it very easy to deploy the same collection of applications and resources to multiple domain partitions.
Resource group templates can define:
-
Application deployments
-
Library deployments
-
Java Database Connectivity (JDBC) system resources
-
JMS system resources
-
Oracle Coherence system resources
-
File stores
-
JMS servers
-
Messaging bridges
-
Path services
-
Persistent stores
-
Store-and-Forward (SAF) agents
-
Foreign JNDI providers
-
Mail sessions
-
WebLogic Diagnostic Framework (WLDF) modules
Resource group templates are defined at the domain level, and then referenced by one or more resource groups.
Resource group templates are particularly useful in a SaaS environment where WebLogic Server MT activates the same applications and resources multiple times, once per domain partition. Some of the information about such resources is the same across all domain partitions, while some of it, such as the attributes of a JMS queue or of a database connection, varies from one partition to the next. For example, the URL, user name, and password used to connect to a data source would be different among different partitions. WebLogic Server MT will activate the application suite represented by the template differently for each partition. You can specify override configuration MBeans and resource deployment plans to override some attribute values in a partition. For more information, see Configuring Resource Overrides.
Virtual Targets
The locations where a partition or resource group runs and instructions how to route traffic to them, including addresses, protocol settings, and targeting. Request routing is determined by the host name and optional URI.
May include:
-
Host name and port
-
Optional URI
-
Network access point/channel
-
Protocol specific configuration
-
Target clusters and Managed Servers
Virtual targets isolate a domain partition and the global (domain-level) runtime from the physical attributes of the target WebLogic Server instances so that your application does not have to know these details.
Scopes
When you deploy an application or library, you have four deployment scope options:
-
Global. This is the equivalent of the domain level in a nonpartitioned environment.
-
Resource group template. This is always at the domain level. Whether the application or library that you deploy to a resource group template is available at the domain level or a partition depends on the scope of the resource group that references the resource group template.
-
Resource group in a partition. This is the only scope that is limited to a partition.
-
Resource group at the domain level.
You cannot share an application or library between domain partitions: the application or library is available only within the partition. When you deploy the application or library, you specify the resource group in the partition. In Fusion Middleware Control, applications and libraries that are deployed to a resource group in a partition display the name of the domain partition and the resource group within that partition where they are deployed.
The key differences between an application or class running at the domain level and an application or class running in the context of a partition are:
-
Applications or classes running at the domain level are available across the domain and are not available in partitions.
-
Applications or classes running in the context of a partition are available only within that partition.
Note:
The recommended best practice is that you deploy all applications and resources to domain partitions.
Resource Isolation
Resource isolation is critically important within a partitioned environment. When you create a resource group in a domain partition, WebLogic Server MT creates runtime copies of all the resources needed by the application, including JMS servers, JMS stores and JMS modules (including connection factories, queues, topics, and such), Java Connector Architecture (JCA) adapters, and other associated resources.
When you deploy an application or library within a partition, any configuration changes that you make are specific to that partition. WebLogic Server MT ensures that applications in one partition refer to the resources that apply to that partition only and not to resources associated with other partitions.
Resource isolation in WebLogic Server MT encompasses:
-
Security: A unique security realm and identity domain for each domain partition.
-
Administration:
-
Partition-specific administration
-
Independent deployment, configuration, and software updates
-
Partition-specific monitoring and troubleshooting
-
-
Runtime:
-
Dedicated Java Naming and Directory Interface (JNDI): Isolation between partitions at the JNDI level, which is partition-aware. Applications can bind named objects and retrieve them on a per-partition basis. Each resource is tagged (internally) with a partition-specific name, and is placed in a JNDI tree that is exclusive to the partition. Intra- and inter-application communication for a partition within a cluster is automatically isolated for the partition.
-
Isolated data: JMS, file system, and data sources.
-
Resource isolation and fairness: Resource consumption management (RCM) of resources provided by the JVM or the OS. This allows system administrators to specify resource consumption management policies (including constraints, recourse actions and notifications) on resources such as CPU, heap, file, and network.
-
Partition Work Managers: The fair distribution of thread usage and prioritization of work requests among partitions that share the same WebLogic Server instance.
-
WebLogic Server MT Users and Roles
Two main users of WebLogic Server MT are WebLogic Server system administrators and partition administrators.
WebLogic Server system administrators create and delete partitions for tenants. System administrators can set or change the security characteristics of a partition (such as the security realm or SSL configuration), or reference a shared (domain-level) resource group or resource group template.
The significant difference between WebLogic Server system administrators and partition administrators is that partition administrators log in directly to a partition-specific security realm, as described in Administrative Roles for Configuration and Management.
Partition administrators manage partitions at the partition level, such as changing partition configuration, deploying applications, creating JMS resources, data sources, JDBC connections, and such, for each resource group in the partition. The partition administrator can also manage the security realm data associated with the partition, such as managing users and groups, credential maps, roles, and policies. To enable security management capabilities for the partition administrator, the system administrator must specify a management identity domain to which the partition administrator belongs. The management identity domain must be the same as the primary identity domain for the partition as shown in Step 5 in Configuring Security Realms and Primary Identity Domains: Main Steps and Examples.
Both system and partition administrators:
-
Create, modify, and delete resource groups in partitions.
-
Deploy and undeploy applications to resource groups in partitions.
-
Start and stop partitions: all of the resource groups and all of the applications deployed to those resource groups are started or shut down.
-
Manage users and groups, credential maps, roles, and policies in the partitions.
Analogous to their WebLogic counterparts, partition-constrained roles exist for Deployers, Operators, and Monitors.
Understanding SaaS Multitenancy
In a SaaS environment, if an application cannot internally provide a per-tenant view or the necessary per-tenant isolation, then you might instead deploy separate instances of the application and its related server-side resources for each tenant. At the very least, this is inefficient: each tenant might get its own stack that includes hardware capacity or Java virtual machines, WebLogic Server domains, Administration Servers, Managed Servers, clusters, and other related resources, such as web servers, data grids, networking, and storage.
The WebLogic Server MT SaaS model provides a way to get the most efficient use from server resources while still providing resource isolation. Each tenant gets an application instance plus resource instances on the targeted servers and clusters. The same application or applications run concurrently and independently on multiple domain partitions. No code changes to the applications are needed: WebLogic Server manages the domain partition identification and isolation.
In the SaaS model, you typically define one or more applications and the resources they depend on in a resource group template. You then reference this template from every domain partition in which you want to use the same applications. You make any domain partition-specific changes by editing the values of the associated resource group.
From a high-level view, the SaaS model procedural flow is:
-
The WebLogic Server system administrator creates the JMS resources, data sources, and other resources for a resource group template.
-
The WebLogic Server system administrator deploys the needed applications to the resource group template.
-
When ready to deploy for a tenant, the system administrator does the following:
-
Creates a virtual target, if necessary.
-
Creates a domain partition configuration, including the resource group, pluggable database information, the virtual target, and the security realm, and then targets the partition to a cluster or set of Managed Servers.
-
Overrides some attributes in certain resource groups and all application deployment values.
-
Starts the partition, which starts all of the applications deployed to the resource group for that partition.
-
-
After a partition is started, a partition administrator can view the runtime state of the partition applications and resources, view partition log entries, manage the security realm data in the partition, and stop and restart the partition applications.
At deployment, the applications and resources in the resource group template are replicated and deployed for each domain partition in a resource group, with the following results:
-
WebLogic Server infrastructure is shared among domain partitions.
-
Separate application instances have their own JNDI tree and resources.
-
Runtime traffic is isolated. You access the application using the virtual target.
-
Partition Work Managers provide fairness of thread usage and prioritization of work requests among partitions.
-
Data is segregated with pluggable databases. The data source implementation creates a separate physical connection pool for each domain partition to its assigned pluggable database.
Testing Applications in a Saas Environment
One of the many benefits of using domain partitions in a SaaS environment is to test new versions of applications in a controlled production environment.
For example, assume that a business-critical application is deployed to Partition A. If you make significant changes to this application, then you would probably want to test it in your production environment before it is generally available to users. WebLogic Server MT provides an easy way to do this. You could create Partition B and deploy the updated application, without affecting the stable version of the application running in Partition A.
You can target the updated version of the application running in Partition B to real production clusters and data sources, test and tune performance metrics, and so forth, all in a controlled environment.
Understanding PaaS Multitenancy
The WebLogic Server MT PaaS model is synonymous with consolidation. Consolidation means that you can deploy different applications from many tenants into the same WebLogic Server infrastructure. WebLogic Server MT shares the infrastructure and underlying resources including the domain, clusters, Managed Servers, hardware, and network.
In the SaaS use case, the WebLogic Server system administrator typically manages all the domain partitions and their resource instances. However, in the PaaS use case, partition administrators are more likely to administer their respective domain partitions and the resources within them, including configuring resources, managing security realm data in the partition, and deploying applications.
Consolidation:
-
Makes it easy to deploy applications from many tenants into the same WebLogic Server infrastructure.
-
Results in one domain to manage and one JVM consuming resources.
-
Isolates management. WebLogic Server system administrators manage the infrastructure. Partition administrators manage partition security realm data, partition deployments and related resources.
-
Isolates the runtime, including partition-specific components: security realm (per tenant), virtual target (addresses), pluggable database, JNDI (internal traffic), JMS, Partition Work Managers. Each tenant gets its own set of application instances and dedicated resources.
In the PaaS use case, each tenant would typically run different applications, and these applications may or may not overlap with the applications run by other tenants. When implementing a WebLogic Server MT PaaS solution, you would typically create self-contained resource groups that do not refer to resource group templates but instead represent applications and their related resources that are to be available only within that domain partition. However, even though a PaaS solution is less likely to use resource group templates, this does not mean you cannot use resource group templates in a PaaS solution if they fit your use case.
From a high-level view, the PaaS model procedural flow is:
-
The WebLogic Server system administrator creates a virtual target, if necessary.
-
The WebLogic Server system administrator creates a domain partition with a specified Partition Work Manager or quality of service (QoS) definition to manage the workload.
The Partition Work Manager defines the relative priority and underlying memory and CPU availability for the partition.
-
The WebLogic Server system administrator selects a security realm for the domain partition, and sets the list of available targets.
Resources and applications in the domain partition are available only to users within the domain partition's security realm. Other tenants cannot see or access the resources or applications.
-
The WebLogic Server system administrator assigns the partition to a partition administrator.
Resources, applications, and partition security realm data are managed by the partition administrator. (The underlying Managed Servers and clusters are not managed by a partition administrator.)
-
The partition administrator creates one or more resource groups for that domain partition and selects the resource group from the list of available targets.
-
The partition administrator creates different JMS resources, data sources, PDB info, application deployments, and such for each resource group in the domain partition.
-
The partition administrator starts the partition, which starts all of the applications deployed to the resource groups in the partition.
-
Repeat steps 1-4 for each additional tenant.
Lifecycle Management
Enterprise deployments of Oracle Fusion Middleware can be complex. WebLogic Server MT simplifies consolidating many domains into one using partitions for isolation and introduces new levels of coordination between component configurations.
WebLogic Server MT lifecycle management connects partitions across different components to form one cohesive unit that serves a tenant's needs. To do this, the lifecycle manager (LCM) provides configuration integration across components.
When a partition is created, updated, or deleted—either through Representational State Transfer (REST), WebLogic Scripting Tool (WLST), Fusion Middleware Control, or the Oracle WebLogic Server Administration Console—the lifecycle manager detects these out of band actions and synchronizes its configuration with the Administration Server's configuration. The lifecycle manager then informs registered plug-ins, such as the Oracle Traffic Director plug-in, of these changes to keep the entire environment synchronized.
When a domain partition is created or updated in WebLogic Server MT, the changes are orchestrated across multiple tiers:
-
The Oracle Traffic Director configuration is updated and synchronized with the new partition.
-
Applications are associated with Oracle Coherence caches or services.
-
Data sources are associated with existing databases or pluggable databases (PDBs), or new pluggable databases are created.
Figure 1-2 depicts the traffic segregation and flow from the web tier to the database tier.
