Call now: 252-767-6166  
Oracle Training Oracle Support Development Oracle Apps

 
 Home
 E-mail Us
 Oracle Articles
New Oracle Articles


 Oracle Training
 Oracle Tips

 Oracle Forum
 Class Catalog


 Remote DBA
 Oracle Tuning
 Emergency 911
 RAC Support
 Apps Support
 Analysis
 Design
 Implementation
 Oracle Support


 SQL Tuning
 Security

 Oracle UNIX
 Oracle Linux
 Monitoring
 Remote s
upport
 Remote plans
 Remote
services
 Application Server

 Applications
 Oracle Forms
 Oracle Portal
 App Upgrades
 SQL Server
 Oracle Concepts
 Software Support

 Remote S
upport  
 Development  

 Implementation


 Consulting Staff
 Consulting Prices
 Help Wanted!

 


 Oracle Posters
 Oracle Books

 Oracle Scripts
 Ion
 Excel-DB  

Don Burleson Blog 


 

 

 


 

 

 
 

multitenant Oracle Traffic Director tips

WebLogic multitenancy tips by Martin Heinzl

This is an excerpt from the book WebLogic Multitenancy: WebLogic as a Platform & Foundation for Cloud Services  by Martin Heinzl.

Oracle Traffic Director

 

The main part of the book focused on the new technology features around partitions in WebLogic. Partitions form the foundation for multitenancy and can be used as a base technology for cloud services.

 

In chapter 5, the new concepts are introduced. We are now revisiting the key concepts of the multitenancy strategy of Oracle – see the diagram below. Up to now the book discussed multitenancy at the WebLogic level, including all the new technologies and features. 

 

Within this advanced section of the book we will extend our scope and include the missing technologies.  First of all (this chapter) we will discuss the load-balancing capabilities offered by Oracle. In the subsequent chapter we will examine Oracle’s multitenancy extension into other products, especially into the distributed “Coherence Caches”.

 

 

Extending Multitenancy into the OTD loadbalancer © Oracle

Load-balancing Technologies for WebLogic

Oracle offers two different technologies for load-balancing web applications. This includes a plugin to the Apache Webserver and the Oracle product OTD (Oracle Traffic Director).

 

Unfortunately Oracle did not extend the Apache plugin in order to support multitenancy in a special way.  The Apache plugin can of course be used to load-balance traffic to partitions. In case partitions get moved to different servers or more instances of the partition need to be started, a manual change in the Apache plugin is required to update the load-balancer setup. The configuration of the Apache plugin for partitions is therefore identical to a load-balancing to a standard WebLogic domain.

 

This chapter focus on the “Oracle Traffic Director” (short OTD). Oracle has implemented a direct support for multitenancy into OTD.  Due to this support, the OTD configuration will get updated automatically if partitions get moved or additional instances gets started.

 

 

Introduction to Oracle Traffic Director

Oracle Traffic Director (OTD) implements a layer-7 software load balancer. Similar to the Apache Webserver, the OTD can be used for reliable HTTP, HTTPS and also (this is different to Apache) TCP communication. OTD acts as a reverse proxy and/or load-balancer to application server clusters sitting in the core network (backend). Oracle Traffic Director provides different load-balancing methods and rules. Like other web-server it also supports caching. OTD also supports a number of additional quality of service features. Instances of Oracle Traffic Director can be grouped together to form active-active or active-passive clusters.

 

With the 12.2.x. release Oracle has also added support for multitenancy. The interesting feature is an integration to the WebLogic domains hosting the partition cluster. This integration enables the infrastructure to get notified as soon as the partition cluster changes. A change may be that additional partition instances for this cluster had been started. In this case the OTD configuration gets updated automatically so that the load-balancing also includes the added partitions.

 

Oracle Traffic director adds the missing load-balancing and failover technology in front of a partition cluster.

 

Oracle Traffic Director – © Oracle Documentation

 

Instances of Oracle Traffic Director are in almost all cases hosted in a different domain than the partitions. Usually the Oracle Traffic Director instances are located in a DMZ environment or at least on dedicated server and forward traffic to application server cluster in secure networks. Albeit it is possible to co-locate OTD into the same WebLogic domain as the multitenancy application partitions, I consider this setup as unusual. This section will assume that OTD and application partitions are deployed into different, separated domains.

 

The integration implemented by Oracle is called “OTD Runtime”. Partitions on the WebLogic multitenancy domains can be associated with an OTD Runtime for load-balancing.

 

Configure Multitenancy Setups in OTD

Please refer to the Oracle documentation for the installation and the configuration of an OTD domain. It is required to install WebLogic and OTD into the same directory as we will manage OTD through WebLogic. This means that on each machine where you want to run OTD, you need to install WebLogic and OTD.

 

It is required to create an OTD runtime in the OTD domain first. On each WebLogic domain, it is required to activate the Lifecycle Manager. Then you can create links between these two domains.

 

Create an OTD runtime in the OTD domain

The first step is to create a new OTD domain. As in our case we manage OTD through the WebLogic administration, the OTD domain can be created using the standard WebLogic configuration wizard, or a WLST script.

 

After setting up the OTD domain, the OTD node-manager and the OTD machines we can start to create OTD runtime configurations.

 

The following screenshots demonstrate the creation of an OTD runtime using the Enterprise Manger Fusion Middleware Console.

 

Start to configure OTD

 

As the OTD is managed by WebLogic, the drop-down menus also contain all the resource and security wizards used to setup a standard WebLogic domain. For each load-balancing service we need to configure an a new OTD configuration in the OTD domain.

 

 

Create a configuration

 

Start the creation of the OTD configuration by clicking on “Create” in the OTD configurations wizard. The wizard will guide you through the different steps, which are required to create a new configuration.

 

 

Configure the OTD Configuration

 

First choose an unique name. Later on we link up the WebLogic domain to this configuration. It is recommended to use a meaningful name.

 

The OTD – other than Apache – does not only offer HTTP load-balancing. It also offers load-balancing for other protocols like t3 or even SSL tunneling. In our example we want to load-balance HTTP requests to our partitions, therefore we choose HTTP.

 

 

 

Select the OTD listener port

 

In the second step, you need to configure the listener port of the OTD load-balancer. If you do not want OTD to listen on all network adapter, then it is possible to choose a network adapter and server name which OTD should listen on.

 

The next step allows the administrator to configure all the remote WebLogic servers to which OTD should load-balance requests to.

 

 

Load-balancing setup

 

In the section we will "link" OTD to a WLS12.2.x domain. WebLogic starting with version 12.2.1 is able to pass its configurations of the partition cluster to OTD. Therefore it is not required to configure these servers for a multitenancy setup.

 

 

Deployment of your configuration

 

As a last configuration step we need to deploy (or target) our configuration to one or more OTD servers. In this example we deploy the configuration to a single OTD server called “OTDMachine”.

 

After a chance to review our settings, the configuration is completed

 

 

Configuration has been created

 

Similar to changes in standard WebLogic server, we need to activate our changes.

 

 

Activate the configuration settings

 

A deployed and activated configuration must be started so that requests can be processed and forwarded to the backend server. Similar to WebLogic managed server or partitions, the OTD offers lifecycle operations for its configurations. 

 

You need to perform a “start” operation in order to start the configuration.

 

 

Start the configuration

 

OTD also offers monitoring capabilities. Each configuration has changed after its activation into a link. By clicking on the link, OTD will bring up the monitoring page for this configuration.

 

 

Selecting link to see the monitoring page

 

 

Monitoring page for this OTD configuration

 

Activate the Lifecycle Manager in the WebLogic domain

By default, the “LifecycleManager” is disabled in WebLogic.  Note that this section changes the configuration of the WebLogic multitenancy domain and no longer the OTD domain!

 

You can enable the LifecycleManager using the WebLogic Console or the WebLogic EM Console.

 

 

Choose OTD Runtimes

 

In the WebLogic domain – not OTD domain (!) – you need to choose the “OTD Runtimes” configuration section.

 

By default the LifecycleManager is disabled.

 

 

Click to enable the Lifecycle Manager

 

After clicking the above button, the Lifecycle Manager gets enabled and you need to restart the domain as this is a non-dynamic change.

 

The same activity can also be automated using the following WLST script:

# connect to the WLS domain which hosts the partitions

connect('weblogic','welcome1','t3://localhost:12001')

 

# change to the lifecycle manager MBean

cd ('LifecycleManagerConfig/'+domainName)

 

ls()

 

This script will provide the following output, which shows the Lifecycle Manager setup.

> ls()

dr--   ConfiguredEndPoints

dr--   EndPoints

dr--   Target

 

-rw-   DataSourceName                               null

-rw-   DeploymentType                               none

-r--   DynamicallyCreated                           false

-r--   Enabled                                      false

-r--   Id                                           0

-rw-   Name                                         usecase_10

-rw-   Notes                                        null

-rw-   OutOfBandEnabled                             false

-rw-   PersistenceType                              XML

-rw-   Tags                                         null

-rw-   Target                                       null

-r--   Type                                         LifecycleManagerConfig

 

-r-x   addTag                                       Boolean : String(tag)

-r-x   freezeCurrentValue                           Void : String(attributeName)

-r-x   getInheritedProperties                       String[] : String[](propertyNames)

-r-x   isInherited                                  Boolean : String(propertyName)

-r-x   isSet                                        Boolean : String(propertyName)

-r-x   removeTag                                    Boolean : String(tag)

-r-x   restoreDefaultValue                          Void : String(attributeName)

-r-x   unSet                                        Void : String(propertyName)

 

This lifecycle manager must be enabled. The following WLST script can be used to do that (unless you want to use the WebConsole or EMConsole):

 

# connect to the WLS domain which hosts the partitions

connect('weblogic','welcome1','t3://localhost:12001')

 

# switch to the edit mode        

edit()

 

# change to the lifecycle manager MBean

cd ('LifecycleManagerConfig/'+domainName)

 

# activate the lifecycle manager and set it to "local admin". The corresponding parameter is "admin"

cmo.setOutOfBandEnabled(true) 

cmo.setDeploymentType('admin')

 

# save and activate changes

save()

activate()

 

After this script has been run, you need to restart the domain.

 

 

Create the link between both domains

After the Lifecycle Manager has been enabled, the administrator has to configure OTD runtime configurations in the multitenancy (!) domain. These runtime configurations contain a link and login details to the OTD domain and the OTD runtime defined in the OTD domain.

 

As a second step, the administrator can now define partitions in the multitenancy domain. The partitions can be configured with the information that load-balancing will be done using a specific OTD runtime.  This link enabled the WebLogic multitenancy domain to feedback setup information for this OTD runtime from the multitenancy domain to the OTD domain.

 

Create an OTD runtime link

 

The OTD link is a configuration on domain level and does not (yet) have anything to do with partitions.

 

 

Select OTD runtimes in the multitenancy domain

 

In this configuration wizard you can configure the different OTD runtime links. Click on “Register Runtime” in order to create a new OTD runtime link.

 

 

Register a runtime to create a new link

 

You need to provide login details to the OTD domain that hosts the load-balancing runtime. It is also required to provide the runtime name – “wls_multitenancy” -  which we used earlier to create the runtime in the OTD domain.

 

 

Provide remote runtime details

After all changes have been activated, we have successfully created our OTD runtime link to a remote OTD domain runtime configuration.

 

 

Runtime link registered

 

After the runtime link has been created, the administrator can configure partitions with reference to the OTD runtime link.

 

 

Create a new partition using the EM console

 

It is also possible to use an automated WLST script to create the partition. The first step offers a possibility to enable OTD load-balancing and to select the OTD runtime link which should be used to update the remote OTD.

 

Configure the remote OTD runtime link

 

With this setup on partition level, the OTD load-balancing setup has been completed. The multitenancy domain will automatically update the OTD domain whenever partition instances are started or stopped.

 

 

Automatic OTD update from the multitenancy domain

 

After the setup of both domains has been completed and the link between both domains has been established, the administrator can start the partition clusters. After the partitions have been started, you can see the automatic update in the OTD domain.

 

 

OTD domain was updated

 

As you can see in the screenshot above, the OTD runtime now shows two virtual servers.

 

The tab called “Origin Servers” provides a list of destination servers. In our case these are the virtual targets for our two partitions in the multitenancy domain.  If the administrator would shutdown a partition or start additional partitions, this list will be updated. 

 

 

 

List of original servers

 

The above information, including the cluster name, is provided by the multitenancy domain. The configured link is used in order to contact the OTD domain and to update the information in the OTD runtime associated with this link.

 

The OTD portal also provides information about the setup of the routing. Select the “virtual server” link to see these details.

 

 

Select the virtual server link

 

The routing information displays the routing rule and the destination cluster, including all the destination servers.

 

 

Routing information

 

 

Shortcuts of the OTD

Oracle has implemented a nice integration between OTD and partition based multitenancy domains.

 

For many real-world infrastructure setup the OTD provides a very valuable setup.  But the OTD integration also has a number of potential disadvantages.

 

One of the first disadvantage is the dependency on Oracle Linux, because the OTD is only certified for this operation system.

 

A second disadvantage is the way Oracle has implemented this integration.  The multitenancy domain establishes a remote connection to the OTD domain.  Usually the OTD domain would reside in the DMZ network and the multitenancy domain in the core network.  Any link from the core network to the DMZ is suspicious and not wanted for any company.

 

If the OTD is running in the DMZ, this also means that the administrators need to install, patch and maintain a full WebLogic and OTD installation. Usually companies try to avoid application server installations in the DMZ and tend to use reverse proxies to tunnel incoming communication to core network.

 

Summary

The Oracle Traffic Director fills an important gab in the Oracle multitenancy strategy. There are other http load-balancer which could forward traffic to WebLogic instances, like Apache with the WebLogic proxy or the Oracle http server which is based on Apache.

 

Oracle Traffic Directors provides a number of business advantages for customers. The most important one is the link between the multitenancy domain and the OTD domain. The OTD setup can be automatically updated as soon as the partition cluster changes. Another unique advantage is that OTD domains can be managed by the familiar WebLogic administration server and the corresponding administrative consoles.

 

The multitenancy integration of Oracle Traffic Director also has a number of disadvantages with regards to firewall setup and installation.

 

Especially in combination with dynamic clusters, the use of the multitenancy integration simplifies the administration of the load-balancing setup for partition clusters.

 

This is an excerpt from the book WebLogic Multitenancy: WebLogic as a Platform & Foundation for Cloud Services  by Martin Heinzl

   
Oracle Training from Don Burleson 

The best on site "Oracle training classes" are just a phone call away! You can get personalized Oracle training by Donald Burleson, right at your shop!

Oracle training
 
 


 


 

Burleson is the American Team

Note: This Oracle documentation was created as a support and Oracle training reference for use by our DBA performance tuning consulting professionals.  Feel free to ask questions on our Oracle forum.

Verify experience! Anyone considering using the services of an Oracle support expert should independently investigate their credentials and experience, and not rely on advertisements and self-proclaimed expertise. All legitimate Oracle experts publish their Oracle qualifications.

Errata?  Oracle technology is changing and we strive to update our BC Oracle support information.  If you find an error or have a suggestion for improving our content, we would appreciate your feedback.  Just  e-mail:  

and include the URL for the page.


                    









Burleson Consulting

The Oracle of Database Support

Oracle Performance Tuning

Remote DBA Services


 

Copyright © 1996 -  2020

All rights reserved by Burleson

Oracle ® is the registered trademark of Oracle Corporation.

 

 

��  
 
 
Oracle Training at Sea
 
 
 
 
oracle dba poster
 

 
Follow us on Twitter 
 
Oracle performance tuning software 
 
Oracle Linux poster