This chapter explains how you can scale up and scale out a SOA Domain, an Service Bus Domain, a WebLogic Domain, and a WebCenter Domain using Oracle Enterprise Manager Cloud Control (Cloud Control). In particular, this chapter covers the following:
Running the Scale Up / Scale Out Middleware Deployment Procedure
Middleware Provisioning and Scale Up / Scale Out Best Practices
Note:
To scaleup multiple products in one session, you can clone the servers from each products's cluster simultaneously.
A WebLogic Domain consists of a set of managed servers running independently or in a cluster, sharing the distributed resources. A WebLogic Server cluster consists of multiple WebLogic managed servers running simultaneously and working together to provide increased scalability and reliability. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or by adding machines to the cluster to host the new server instances. You can use the Domain Scale Up / Scale Out deployment procedure to automate the scaling up or scaling out of a domain. You can:
Scale up a domain by adding or cloning a managed server to a host that already exists in the domain or cluster.
Scale out a domain by adding or cloning a managed server to a host that is not present in the domain or cluster.
Before running the Scale Up / Scale Out Middleware deployment procedure, you must meet the prerequisites listed in this section.
Note:
For information about how to setup your infrastructure for Middleware Provisioning, see Prerequisites for Provisioning from the Middleware Provisioning Profiles.
Meet the following prerequisites before you start extending the WebLogic Domain:
The WebLogic Domain that is scaled up / scaled out must be an existing domain that has been discovered with Cloud Control.
If you are scaling out a domain, ensure that the destination machine contains sufficient space. If the size of the Middleware Home on the source machine is 3 GB, you need approximately 3 GB in the working directory on the source and destination machines. Additionally, the destination machine should also have 3 GB of space for the Middleware Home. The working directory is cleaned up after deployment procedure has been successfully completed.
The Middleware Home directory you specify on the destination machine must be a new directory or must be empty.
The Management Agent must be installed on the source (where the Administration Server is running) and the destination machines. The Administration Server for the domain must be up and running.
The Administration Server and Managed Server (being cloned) must be up and running before you run the deployment procedure.
The Managed Server and Node Manager ports must be free.
Ensure that the user has the necessary permission to the stage directory inside the work directory. The scale up may fail with an error in case sufficient permissions are not granted to the user. In such an event, assign the necessary 700 permission to the stage directory and retry.
For scaling out a domain, the user must have the following permissions:
Read permissions on:
Administration Server Host Middleware Directory
Administration Server Host Domain Directory
Write permissions on:
Administration Server Host Working Directory
Working Directory of all the destination Managed Server hosts
Middleware Directory of all the destination Managed Server hosts
Domain Directory of all the destination Managed Server hosts
For scaling up a domain, the user must have the following permissions:
Read permissions on:
Administration Server Host Working Directory
Domain Directory of all the destination Managed Server hosts
The domain being scaled up / out should not be in Edit mode. Ensure that there is a running WebLogic Console for this domain.
If you choose to associate a new manages server with an existing Node Manager or a machine, ensure that the Node Manager is up and running. If not, the deployment procedure will fail.
Ensure that you have discovered an existing OHS target in Enterprise Manager, if you want to front end the Oracle HTTP Server.
Ensure that the target machine which is being scaled up and Enterprise Manager host where the OMS is running are in the same timezone, before you begin the scaleup process.
Ensure that you do not delete the Aggregation Server when you are scaling down a domain. If the Aggregation Server is deleted, then a lot of dependent applications will stop running.
A WebLogic Domain consists of a set of managed servers running independently or in a cluster, sharing the distributed resources. A WebLogic Server cluster consists of multiple WebLogic managed servers running simultaneously and working together to provide increased scalability and reliability. The server instances that constitute a cluster can run on the same machine, or be located on different machines. You can increase a cluster's capacity by adding additional server instances to the cluster on existing machines, or by adding machines to the cluster to host the new server instances.
The Scale Up / Scale Out Middleware wizard allows you to increase a cluster's capacity by adding additional server instances to the cluster on an existing machine, or by adding machines to the cluster to host the new server instances.
Note:
Java Object Cache is always configured on a scaled out or scaled up middleware managed server whether it was available before scale up or not.
To scale up or scale out a domain, follow these steps:
Ensure that the prerequisites are met. See Prerequisites.
Specify the source domain. See WebLogic Domain Scaling Up: Scale up/Scale out Fusion Middleware Domain Page.
Specify when the scale up or scale out operation should be performed. Weblogic Domain Scaling Up / Scaling Out : Schedule Page.
Note:
For scaling out a WebCenter Domain, you must perform the following steps manually:
Oracle HTTP Server must be installed, discovered, monitored in Cloud Control. Additionally, you must ensure that for the scale out instance the configuration file should be manually configured.
If the Spaces Server is scaled out, then you must run the following commands to attach the WebService Policy:
attachWebServicePolicy(application='WC_Spaces2/webcenter', moduleName='webcenter', moduleType='web', serviceName='SpacesWebService', subjectName='SpacesWebServiceSoapHttpPort', policyURI='oracle/wss11_saml_token_with_message_protection_service_policy')
If the Discussion Server is scaled out, then you must run the following commands to attach the WebService Policy:
attachWebServicePolicy(application='WC_Collaboration2/owc_discussions', moduleName='owc_discussions', moduleType='web', serviceName='OWCDiscussionsServiceAuthenticated', subjectName='OWCDiscussionsServiceAuthenticated', policyURI='oracle/wss10_saml_token_service_policy')
You can automate the scaling up or scaling out of a domain or cluster using the Domain Scale Up / Out Deployment Procedure. You can add capacity to an existing WebLogic Domain and /or cluster by:
Adding attributes of a new managed server to an existing cluster.
Adding and copying attributes of a new managed server to an existing cluster.
Cloning a managed server. If the source server is clustered, when you clone an existing Managed Server, another Managed Server will be created in the same cluster.
A wizard guides you through the process.
Note:
If you are scaling a domain with products like SOA or OSB, then a JMS Servers section is displayed if the source domain has it configured.
On the Schedule page, specify a Deployment Instance name. If you want to run the procedure immediately, retain the default selection, that is, Immediately.
If you want to run the procedure later, select Later and provide time zone, start date, and start time details.
You can set the notification preferences according to deployment procedure status.
If you want to run only prerequisites, select Pause the procedure to allow me to analyze results after performing prerequisite checks. This pauses the procedure execution after all prerequisite checks are performed.
Click Next.
This section lists some of the best practices to be followed while using the Middleware Provisioning deployment procedure.
Configuration of the source domain should not be changed: While executing these deployment procedures, ensure that no administrative activities (such as configuration changes on the source domain and software patching) are actively performed on the source domain. If you change the configuration, the managed server may not respond to requests and the Administration Server will have an Unknown status.
Provisioning on the same machine: If you are using the Deployment Procedure to provision or scale up to the same machine as the source, the working directory on the source and target machines is populated by default. If these values are changed, you must ensure that the working directory on the source and the destination machines are different. For example, if the working directory is /tmp/source
for the source machine, it could be /tmp/dest
on the destination directory. You must also ensure that the listen port number and SSL port numbers (if enabled) for the Administration Server and Managed Server are different on the source and destination servers.
JDBC Configuration: While configuring the JDBC data sources, the database user and schema owner must enter appropriate passwords.
Custom Java Applications and their Deployment Plan: These deployment procedures support custom java applications in staged mode. Externally staged applications need to be manually deployed. For instructions on manual deployment, see the WebLogic Administration Guide.
Multi NIC Machines: If the destination machine is a multi NIC system, enter a listen address that is accessible to both the Administration Server and Managed Server.
Port Conflicts: While adding a new server on a host, you must enter ports that are unique to that server and are not used by any other existing managed server or process on that host.