WebLogic Feature Pack: Setup

Intended for use with WebLogic Feature Pack V2.3.

Migrating your WebLogic domains from your current environment to Cassatt Active Response using WebLogic Feature Pack increases flexibility and server utilization while reducing licensing and maintenance costs—all with minimal conversion cost and risk.

I'll walk you through the migration process, which I've divided into these phases:

• Install WebLogic Feature Pack on the control nodes – a simple script installation on top of Cassatt Active Response
• Create the WebLogic image and tiers – prepare the BEA WebLogic 8.1 or WebLogic 9.2 software to run in the Cassatt Active Response environment
• Configure your WebLogic domains – using the WebLogic Administration Console, create the correct number of managed servers and set parameters for the Cassatt Active Response environment
• Prepare your WebLogic Feature Pack Services – Issue a series of WebLogic Feature Pack commands that do the following:
  • Capture your WebLogic domains as "service images" – copy the domains into the service matrix
  • Configure WebLogic Feature Pack services for your WebLogic domains – specify service level agreements (SLAs) and deployment constraints; validate addresses, paths, and ports (or update if necessary)
  • Activate services – start monitoring and initiate WebLogic Feature Pack control over capacity levels
• Test – optional: ensure that the domain works properly in Cassatt Active Response
  
  Note that testing occurs between service configuration and activation—after you have started your J2EE application running in Cassatt Active Response, but before giving WebLogic Feature Pack control. Testing relies on access to the WebLogic Console.
• View WebLogic Feature Pack status – track the service status and WebLogic Feature Pack automated service-level compliance

Ready to experience the dramatic cost savings and customer satisfaction that service-level automation can deliver? Let's go.

WebLogic Feature Pack is designed to decouple your WebLogic domains from your WebLogic software image by storing and configuring WebLogic domains separately from the WebLogic software.

Because site considerations or policies may require it, WebLogic Feature Pack also supports the traditional method of installing or mounting WebLogic domains on the WebLogic Administration Server. To learn more about direct installation, read Alternative to the Service Matrix: Domains Installed on the Administration Server.

top

Install WebLogic Feature Pack on the control nodes

Install WebLogic Feature Pack by running the installation script as root:

1. On each control node, insert the WebLogic Feature Pack CD.
2. At a shell prompt, start the installation program by entering the following commands:

   mount /dev/cdrom /mnt/cdrom
   cd /mnt/cdrom
   ./ccwaminstall

Create and capture the WebLogic image and create tiers

Create a WebLogic image and deploy it in your Cassatt Active Response environment as described in WebLogic Feature Pack: Capturing an Image and Creating Tiers. That article explains that you need two tiers, one for the WebLogic Administration Server and one for the Managed Servers.

After activating your tiers, note the following information, which you will need later:

• The names of the two tiers
• The IPs or host names for nodes assigned to the tiers
• The maximum nodes value for the Managed Server tier.
• The absolute path to the WebLogic installation (WL_HOME) on the Administration and Managed Server tiers, for example: your_path/weblogic812/weblogic81
• The absolute path to the Java installation (JAVA_HOME) on the Administration and Managed Server tiers, for example: your_path/welogic814/jrockit81sp4_142_05
• The user name(s) and passwords to start the WebLogic Administration server and WebLogic Node Managers

top

Configure your WebLogic domain

WebLogic Feature Pack is designed to automate Managed Server startup for domains built on the Managed Server model, in which a single Administration Server manages a set of Managed Servers.

The key to making sure your WebLogic applications will run properly with Cassatt Active Response is knowing enough about them to be sure each one meets a couple of simple WebLogic Feature Pack requirements. I'll help you find each required setting later in this article.

WebLogic Feature Pack validates your domain twice during setup: when you configure a WebLogic Feature Pack service and when you activate the service. Validation helps you find problems before you give control to WebLogic Feature Pack. See all the items WebLogic Feature Pack validates.

For extra assurance, consider testing your domain inside Cassatt Active Response before activation, which places the domain under WebLogic Feature Pack control.

Select a service host

Choose a node to use as the service host using the guidance in the next table. A service host is analogous to an image host: you configure your domain just the way you want it on the service host, then capture the domain into the service matrix.

Start the Administration Server for your domain

You can begin with an existing WebLogic domain if it was configured for multiple servers, or follow these guidelines as you use the WebLogic configuration wizard to create a new domain on the service host.

Start your the Administration Server for your domain on the service host to access the WebLogic Administration Console. Need help?

Set WebLogic configuration parameters

In the WebLogic Administration Console, set these configuration parameters using the values from either your service tiers or your test tiers.

WebLogic Feature Pack validates these parameters during service configuration. Optionally, WebLogic Feature Pack can update some of these parameters for you during service configuration if you do not set them now. The parameters that WebLogic Feature Pack can update are noted with a checkmark.

• Administration Server – If necessary, select a new listen port in accordance with the guidance in WebLogic Feature Pack and listen ports: what you should know. ()
• Unix machines – Create the same number of Unix machines as maximum nodes in your Managed Server tier.
  
  Set the listen addresses to match the IP addresses/host names of the nodes in your Managed Server tier.

WebLogic does not support using localhost as the listen address when JMS and JTA are migratable. For more information about how JMS works with WebLogic Feature Pack, see JMS, WebLogic, and WebLogic Feature Pack.

If you use localhost as the listen address, edit the /etc/hosts file on each node in your Managed Server tier to specify that localhost = the node IP address. Edit the file to read as follows:

127.0.0.1 localhost.localdomain
IP Address of Managed Server localhost

Make sure all node managers use the same listen port; select the node manager listen port in accordance with the guidance in WebLogic Feature Pack and listen ports: what you should know. ()

• Managed Servers – Create the same number of Managed Servers as Unix machines: WebLogic Feature Pack uses a one-to-one mapping between Managed Servers and Unix machines, running only one instance of the same service on each Managed Server. Make sure the server names are unique across your WebLogic Feature Pack-managed domains to ensure that staging and logging locations generated by WebLogic are also unique.
  
  Use the same IP addresses/host names for the listen addresses as you used for the Unix machines. Assign each Managed Server to its designated Unix machine.
  
  Use the same listen port as you used for the Administration Server. ()
  
  For each Managed Server, set these configuration parameters after selecting Servers > server_name.

All Managed Servers must be set up identically for WebLogic Feature Pack automation to succeed with your domain.

Step, Selection, or Setting Note: for WebLogic 9.2, paths begin with Environment > Servers	Discussion	WebLogic 8.1	WebLogic 9.2	Updated by service capture script
Configuration > Deployment > Staging Mode = Stage	WebLogic Feature Pack administers staging directories slightly differently than WebLogic does: whenever a server is shut down entirely, WebLogic Feature Pack removes all stage directories. Removing the directories ensures a clean restart. Use the WebLogic default values for the staging directory, or use an instance-specific directory you specified for the WebLogic image during image capture. If you choose your own directory, make sure the directory is unique to this domain.
Configuration > Keystores & SSL > Advanced Options > Client Attributes> Hostname Verification	Set to None.
Configuration > Tuning > Advanced Options > Managed Server Independence > Managed Server Independence Enabled	Deselect the checkbox. Managed Server Independence is incompatible with WebLogic Feature Pack automated deployments.
Configuration > Remote Startup	If you need to set parameters on this page, make sure your settings match the locations in your image, and that you use the same locations later when you configure a service for the domain.			*
Configuration > Health Monitoring > Auto Restart	Set to Off.
(8.1) Control > JMS Migration Configuration (9.2) Migration	If your domain uses JMS, make sure you understand how JMS works with WebLogic Feature Pack and that you have JMS set up accordingly. If any JMS servers are configured in the domain, all JMS servers must be migratable. Move all managed servers to the right to make them migration targets.
(8.1) Control > JTA Migration Configuration (9.2) Migration	Move all managed servers to the right to make them migration targets.
Protocols > IIOP > Advanced	Change the user name and password to the WebLogic user name and password.
General > Advanced Tab	Startup mode must be running in each server.
(8.1) Control (9.2) Migration	Auto server migration must be off for each server.
Machines > Node Manager	Select a machine, the Node Manager tab, and then set Type to Plain .
Services	Set Enabled Detault Connection Factories.
Services	Set the Default Store Directory to /tmp.

*Only the address and port are updated, and only when they fit the following pattern: http[s]://server.ListenAddress:Server.ListenPort/xxxxx)

• JMS (WebLogic 8.1 only) – Set JMS JNDI name replicated to true in both the JMS queue and JMS topic configurations for all JMS servers that target Managed Servers. ()

• Clustering (WebLogic 8.1 and 9.2) – If your domain uses a cluster, make sure all Managed Servers belong to the cluster. Use a unique multicast address and port combination for each domain (WebLogic Feature Pack does not validate multicast addresses or ports). A cluster is required if JTA or JMS servers are migratable.
• Paths and addresses (WebLogic 8.1 and 9.2) –
• Be sure the domain is self-contained; that is, all domain files are within the parent directory.
  
• Make sure that application components target either a cluster, all Managed Servers, or just the Administration Server.
• If your WebLogic domain uses a start script with a name other than startWebLogic.sh, rename it to startWebLogic.sh. Do the same for stopWebLogic.sh.
• Check the application paths in the config.xml to be sure they are correct. If a path points to a location that exists, but is incorrect, you may get undesired results.
• Administration Server (WebLogic 9.2 only) – Set the IIOP user name and password.

Prepare your WebLogic Feature Pack services

The next illustration shows a high level overview of the three-step process to convert your WebLogic domains into WebLogic Feature Pack services. This section covers each step in detail.

Before you continue, make note of these points about how WebLogic Feature Pack works:

• Service capture makes an exact copy of your domain as it's configured on the service host. This creates a new service image.
• Service configure makes an exact copy of your domain from the service image; however, service configure can optionally update the new copy as described in Set WebLogic configuration parameters and again in the section that follows this one. These updates to the WebLogic Feature Pack service configuration do not affect the domain in the original service image.
• Service configure mounts the domain via NFS on the WebLogic Administration Server. If you are using a domain that you have mounted or installed directly on the WebLogic Administration Server, service configure does not mount the domain; consequently, the domain you mounted or installed may not match the domain stored in the WebLogic Feature Pack service configuration or the domain in the service image.

Capture your WebLogic domains as "service images"

A service image for WebLogic Feature Pack is a copy of the WebLogic domain, including the application (.war, .ear, .jar) file or files. Capturing a service image is very simple—run the ccservicecapture command from the control node:

/opt/cassatt/bin/ccservicecapture

The command requires:

• The name you want to give the service image.
• A version number for the service image.
• The IP address of the service host.
• The service host's root password.
• The full path to the WebLogic domain on the service host.
• The file system to hold the service image. You can capture the service image into the storage location of your choice. If you are unsure, select the Cassatt Active Response base file system, where the image will be stored in the service_images directory.

After you provide this information, Cassatt Active Response copies the domain into the service matrix.

top

Configure a WebLogic Feature Pack service for your WebLogic domain

A WebLogic Feature Pack service comprises a copy of the service image, modified for your Cassatt Active Response environment, plus the rules and all the information about your WebLogic domain that WebLogic Feature Pack needs to automatically start and stop Managed Servers.

You configure a service by running the ccserviceconfigure command from the control node:

/opt/cassatt/bin/ccserviceconfigure

The ccserviceconfigure command presents a series of questions about the service. Some of the questions bring together the information you collected in previous steps:

• The service image name and version (the captured WebLogic domain)
• The tiers in which to run the service image (your active WebLogic Administration Server tier and WebLogic Managed Server tier or your test tiers)
  
• The absolute path to the WebLogic domain location on the Administration Server and Managed Server tiers.
• Using a pre-existing domain: see Alternative to the Service Matrix: Domains Installed on the Administration Server.
  
• The paths to the WL_HOME, and JAVA_HOME in the WebLogic image
  
  The ccserviceconfigure command checks that these directories exist in your image, but it does not ensure that your startWeblogic.sh script uses these paths.
  
  Also, if your startWeblogic.sh script uses paths in addition to these BEA standards, you'll need to manually edit the script to correct the paths for the Cassatt Active Response directory structure.
• The Unix user name(s) to run the WebLogic Administration server and Node Managers
• The Weblogic listen port and Managed Server listen port

The interview also requires new information, which you should determine before beginning. Most of these become read-only when you complete the interview, but a few can be edited from the WebLogic Feature Pack services web site for your Cassatt Active Response environment, which I'll introduce in the next section. I've marked items you can edit later if you choose.

• Name – A name for the service configuration.
• Version – A version number for the service configuration.
• File system – The file system to hold the service. You can capture the service into the storage location of your choice. If you are unsure, select the Cassatt Active Response base file system, where the service will be stored in the services directory.
• Update – Should WebLogic Feature Pack update your WebLogic configuration as required to run under WebLogic Feature Pack? If either the listen addresses in your tiers or the listen ports you specified for the WebLogic Feature Pack service don't match the values in your WebLogic domain configuration, the service configuration will fail unless you allow WebLogic Feature Pack to update the WebLogic domain configuration. In WebLogic 9.2, WebLogic Feature Pack will also update the default user name and password for IIOP.
  
  Note that, although the service configuration question in ccserviceconfigure asks about listen addresses and listen ports in general, WebLogic Feature Pack updates only the Administration Server listen address, the Managed Server listen address, the Node Manager listen address, the WebLogic listen port for the Administration Server and Managed Servers, the Node Manager listen ports for Unix machines, and the server start arguments if WebLogic Feature Pack finds the following pattern: http[s]://server.ListenAddress:Server.ListenPort/xxxxx.
  
  Update also sets the following parameters whenever you say "yes" to updating the listen addresses and listen ports:
  • Disables auto restart on all servers
  • Disables Managed Server Independence on all servers
  • Sets Staging Mode to "stage" on all servers and applications
  • (WebLogic 8.1 only) Sets JNDI name replicated to true on JMS servers that target managed servers
  • (WebLogic 9.2 only) Sets the default IIOP user name and password for each Managed Server.
  For more information, see WebLogic domain validation.
• Capacity requirements (editable) – Like the capacity requirements for tiers, capacity requirements for services are set in minimum number of servers. You initially set a minimum and maximum. WebLogic Feature Pack automatically starts the minimum servers at service activation. Then WebLogic Feature Pack uses the SLAs you've set to adjust the capacity within the minimum and maximum bounds as service levels dictate.
  
  Note that WebLogic Feature Pack capacity requirements are constrained by your Managed Server tier capacity; that is, WebLogic Feature Pack maximum servers cannot exceed the maximum nodes in the Managed Server tier.
• The service shutdown mode – The way you want WebLogic Feature Pack to shut down a Managed Server. Your selection depends on how quickly (and whether) your application shuts down gracefully. Choices are normal, force, and kill. Note that WebLogic Feature Pack escalates the shutdown mode after 300 seconds. If you specify normal shutdown mode, for example, WebLogic Feature Pack sends a request to WebLogic to run the normal shutdown process. After 300 seconds, if the service on the Managed Server is still running, WebLogic Feature Pack issues a forced shutdown request; after 300 more seconds, if the service is still running, WebLogic Feature Pack issues a kill request.
  
  WebLogic Feature Pack operations are most efficient when you select a shutdown mode that closely matches your Managed Server's actual behavior.
• Service dependencies – Any other services that must be running for this service to function properly. WebLogic Feature Pack does not deploy a service that depends on another service when that service is not active. WebLogic Feature Pack will not stop all instances of a service that has other services depending on it.
• Passkey – A reference to a user name and password pair in a secure store. For a service, the passkey should reference the WebLogic administrative user name and password in the boot.properties file for the domain. Note that ccserviceconfigure allows you to replace the boot.properties file in a later step.
  
  If you have not defined a passkey, you can define one during the configuration interview by providing a passkey name and the user name and password it should reference.
  
  Once you have specified a passkey you can edit the user name and password it references by using the ccpasswd command (see WebLogic Feature Pack: Managing Images and Services). However, you must also update the domain. A change introduced by ccpassword does not update the domain.
  
  For WebLogic 9.2, the passkey user and password values need to match the default IIOP user name and password values for each server.
  
• Expected start delay (editable) – the length of time in seconds required for your WebLogic Managed Server to start. WebLogic Feature Pack allows 240 seconds beyond your start delay for the Managed Server to report in through monitoring.
  
  Here's how it works:
  • If the Managed Server reports in at any time during the start delay or during the 240-second wait, WebLogic Feature Pack starts managing the service immediately, bypassing any remaining wait time.
  • If the Managed Server hasn't reported in after your start delay plus 240 seconds, WebLogic Feature Pack concludes that the startup was unsuccessful and restarts the Managed Server on the same node.
  • If the Managed Server fails to start on the second try (after waiting for the start delay plus 240 seconds), WebLogic Feature Pack marks the Managed Server for the node as failed and starts a Managed Server on another node in the tier.

You should perform some tests to determine the start delay required for your domain—a start delay that is set too long holds up WebLogic Feature Pack's response to a failure, while a start delay set too short results in apparent SLA breaches and undue node replacements. In general, a start delay that is too long is better than one that is too short.

• Load delay (editable) – The length of time in seconds for the service level to adjust after starting a new service instance before determining whether to start another service instance or to stop a service instance.
  
  The load delay period allows for load balancing before new starts/stops.
• Monitoring – The key to WebLogic Feature Pack automatic deployments. The values you choose to monitor, and how you manipulate them, govern how frequently WebLogic Feature Pack checks your service status and how WebLogic Feature Pack determines when to start and stop Managed Servers.
  
• Monitored values – Which parameters WebLogic Feature Pack monitors for the service and the nodes in the service tiers.
• Service level agreements (SLAs) – The policies you set that dictate when WebLogic Feature Pack deploys an additional instance of a service or undeploys under-utilized instances of the service.

Remember that SLAs are bounded by the capacity requirements for minimum and maximum services. That is, when a domain is at its minimum number of services, WebLogic Feature Pack cannot undeploy services, even if an SLA calls for an undeployment.

Likewise, when a domain is at its maximum number of services, WebLogic Feature Pack does not deploy additional services, even if an SLA is breached.

When devising SLAs, consider how they may be be affected by capacity requirements—and vice versa.

• Deployment constraints – Policies that ensure that WebLogic Feature Pack selects nodes that meet the minimum requirements to run the service.
• Replace the boot.properties file – If the passkey you specified has a different user name and password than the domain's boot.properties file, you'll want to replace the file during service configuration.

When the service configuration script completes, WebLogic Feature Pack checks your WebLogic configuration to make sure it meets all of the requirements to run under WebLogic Feature Pack management. If you set parameters as described in Set WebLogic configuration parameters, your domain should pass validation with no errors.

When validation is complete, WebLogic Feature Pack starts the Administration Server and the Node Manager on each Managed Server that is online, and which is not already running the node manager for the domain's WebLogic version and service pack.

Be aware that WebLogic Feature Pack allows 10 minutes for the Administration Server to start; if the Administration Server does not start within 10 minutes, WebLogic Feature Pack provides an alert so you can investigate. Be sure to wait for the Administration Server to start before proceeding.

If you activate the service while the Administration Server is starting, WebLogic Feature Pack attempts to deploy your minimum service level, but cannot because the Administration Server is unavailable.

If you know your Administration Server takes longer than 10 minutes to start, set minimum nodes to 0 when configuring the service.

If you plan to test your domain inside Cassatt Active Response, skip the activation section and perform the optional steps in Test the configuration.

Activate the service

Activating the service validates the configuration again and gives WebLogic Feature Pack control over deployments and undeployments. WebLogic Feature Pack starts the Administration Server and the Node Manager if they are not already running.

Run the ccserviceactivate command from the control node:

/opt/cassatt/bin/ccserviceactivate

WebLogic Feature Pack starts the minimum number of Managed Servers for the service; if the minimum is 0, you must raise the minimum before WebLogic Feature Pack starts any service instances.

After your service is activated, WebLogic Feature Pack manages starting and stopping Managed Servers for you; do not manually start or stop Managed Servers using the WebLogic Administration Console. WebLogic Feature Pack also manages resource allocation to tiers; do not raise or lower the Managed Server tier's operational target.

Any manual changes you make could cause service disruptions as they are overridden by WebLogic Feature Pack. Make all deployment changes through the WebLogic Feature Pack service level agreements and deployment constraints. See WebLogic Feature Pack: Managing Images and Services..

top

Test the configuration: optional

As you follow these steps, use the information from either your service tiers or from your test tiers, as applicable.

Start a Managed Server

1. In the WebLogic Administration Console, select a Managed Server that is associated with a node that's online in the Managed Server tier and is running the the Node Manager.
2. Select Control > Start/Stop > Start this server...
3. Watch the server log for errors.
4. If errors arise, use the error text provided in the WebLogic Administration Console to diagnose the problem.
   
   Common errors include failure to connect to external services such as databases, JMS queues, and single sign-on. If you encounter external connection errors, check your etc/resolv.conf file on the control node to be sure it is set up to resolve host names from external servers in your network. Make sure ports in firewalls are open.
   
5. When you have succeeded without errors, continue to the next step.

top

Validate the deployment

1. Validate the WebLogic domain: in the WebLogic Administration Console, select Deployments > Web Application Modules > Application_Name > Testing.
2. Make sure that all end points, such as databases and JMS messaging, are working properly.
3. In the Cassatt Active Response controller, disable and power off the Administration Server node. Verify that your domain continues to operate properly on the Managed Server.
4. In the Cassatt Active Response controller, power on and enable the Administration Server node. The Administration Server restarts automatically.
5. In the WebLogic Administration Console, start the second Managed Server and verify that your application operates properly on both servers. If you are using a load balancer, ensure that traffic is flowing to each server.
6. Repeat step 5 for each additional Managed Server.
7. In the Cassatt Active Response controller, disable and power off the first Managed Server node. Verify that your domain continues to operate properly on the remaining Managed Servers.
8. Repeat step 7 as necessary with your remaining Managed Servers.
   

Stop the services

1. In the WebLogic Administration Console, select a Managed Server.
2. Select Control > Start/Stop > Stop this server...
3. Pay attention to how long it takes the Managed Server to stop, which will help you determine which service shutdown mode to specify when you configure a service to run the WebLogic domain; that is, whether WebLogic Feature Pack should shut down the server gracefully or force shutdown.
4. Stop the remaining Managed Servers.
5. Stop the Administration Server.

Reconfigure for production

Use the next table to determine your next step.

top

View WebLogic Feature Pack status

To see service status and watch WebLogic Feature Pack activity, click Services in the left navigation pane of the Cassatt Active Response Controller.

The WebLogic Feature Pack web site lists each service, its status, and the number of nodes online and expected to be online. These provide your window into WebLogic Feature Pack activity.

Next steps

This completes the procedure to set up WebLogic Feature Pack with your WebLogic applications.

For a more complete description of the WebLogic Feature Pack user interface and procedures for ongoing operations using WebLogic Feature Pack, continue with WebLogic Feature Pack: Managing Images and Services. Or go back to the WebLogic Feature Pack home page for links to the full set of WebLogic Feature Pack documentation.

Was this article useful? Tell us what you think.
Email infocentral@cassatt.com.