WebLogic Feature Pack: Managing Images and Services
Intended for use with WebLogic Feature Pack V2.3.
The WebLogic Feature Pack is designed to hum along, deploying and undeploying services based on service level agreements you chose during setup. Because priorities, resources, software versions, and business needs change, you will almost certainly need to manage your services over time.
Overseeing your WebLogic Feature Pack services
The Cassatt Active Response Controller is your primary tool for checking on service deployments. Click Services in the left navigation pane to see the services in your environment.
Most of the items on the Services page are straightforward, but a few merit some explanation:
- Status column – icons for each service indicate whether the service is running within all of its service level agreements. Status icons are animated when a WebLogic Feature Pack action is in progress. Mouse over the status icons to see their definitions.
- Online (Expected) column – indicates the actual number of nodes providing the service contrasted with the number required based on the service level agreements. Don't be alarmed when the actual and expected do not match: they will differ whenever WebLogic Feature Pack is deploying or undeploying services. These differences indicate WebLogic Feature Pack activity.
- Service Actions dropdown menu – lets you disable and enable services. When you disable a service, WebLogic Feature Pack automation ignores any service-level breaches.
Disabling is useful when you know your application isn't working properly, but the failure is not detectable via the node service monitors you specified for the service. Disabling gives you manual control: when a service is disabled, WebLogic Feature Pack ignores failures. You can restart the application (or an application component like a JVM) using the WebLogic Administration Console, and WebLogic Feature Pack does not attempt to replace it. When you reenable, you give control back to WebLogic Feature Pack .
Disabling is also used when you are upgrading services and need to replace application files, then restart the Administration Server so it will use the new files. For upgrades, disable both the service for the domain and its Administration Console service.
- Service Type filter – All of the WebLogic Feature Pack services you configured are of type "wl81" or "wl92." In addition, the WebLogic Administration Console for each domain is managed as a WebLogic Feature Pack service: when you configure a WebLogic Feature Pack service for a domain, WebLogic Feature Pack automatically creates an Administration Console service for the domain with a type of "wl81admin" or "wl92admin." By default, the services list is filtered to show only wl81/92 services. Use the dropdown list and Filter button to see Administration Console services.
top
Service details
Click a service name to see details for the service. The service tabs show:
- Node list – Look here for details about each node that is available to run the service, including its current node monitored values. The node list tab contains a scrolling list of WebLogic Feature Pack activity for the service called SLA Events.
- Properties – The settings you chose during service configuration are all displayed on this tab. The properties tab is also where you can edit service properties, which I explain in the next section.
- Alerts – WebLogic Feature Pack alerts provide details about service deployments and undeployments, including service breaches and surplus capacity analyses.
You can also see WebLogic Feature Pack alerts from the Cassatt Active Response Controller alerts page—after logging in, select the alerts log from the left navigation pane, select Application Activity from the Events dropdown, and click Filter.
Changing service properties
If you configured your WebLogic services yourself, you probably have a good understanding of what they are and how they work. If not, you may want to review WebLogic Feature Pack: Setup, particularly the section on service configuration, which describes each service property, how it is used, and whether you can edit it once you've configured it. Only a few properties are editable once the service is activated.
This section covers only how to change editable WebLogic Feature Pack service properties.
- If you need to change WebLogic Feature Pack service properties that are not editable, you must configure a new service for the captured service image. See Adding services.
- If you need to make changes to the WebLogic domain or you need to update an application or service inside a WebLogic domain, see Updating a WebLogic domain.
top
Changes using the Service Properties page
The next screen shows editable properties for an example service.
The passkey name is not editable here, but the username and password it references can be changed using a command-line interface, which I'll describe in the next section.
top
Changes using a command-line interface
You can use the ccgovernor command to make the same service property changes you can make in the GUI. To see the usage statement, issue the command from the control node with no options:
/opt/cassatt/bin/ccgovernor
One property—the passkey information—is edited using the standard Cassatt Active Response ccpasswd command rather than the WebLogic Feature Pack -specific ccgovernor command. You need to change the username and password within WebLogic separately. To change the WebLogic user's username or password, follow these steps.
- Disable the WebLogic Feature Pack service for the domain and the WebLogic Feature Pack
service for its Administration Console in the Cassatt Active Response
Controller.
- Using your standard site procedures, disallow access to the application.
- Use the BEA WebLogic Administration Console to make the changes for the domain and for each managed server as described in the WebLogic documentation. Make sure to update the boot.properties file for the domain.
- (WebLogic 9.2 only) Update the IIOP user name and password.
- Test all of the changes within WebLogic.
- Log into the control node as root and use the ccpasswd command to change the information in the passkey. To see the usage statement, issue the command from the control node with no options:
/opt/cassatt/bin/ccpasswd
- Reenable the services.
top
Scheduling service changes
If you can reliably anticipate daily, monthly, or quarterly capacity demands for the J2EE services that run in your data center, you can use scripts to change capacity requirements, SLA thresholds, and other editable parameters automatically on a set schedule.
Although limited to the ccgovernor command with its various options, scripting scheduled changes for WebLogic Feature Pack is similar to scripting scheduled changes for native Cassatt Active Response.
Simple WebLogic Feature Pack Scripting example
Let's suppose you have an employee time tracking portal that must be available 24/7, but heaviest use is 8:00 am to 5:00 pm on weekdays. You want to maximize efficiency for employees using the portal during regular business hours, but you also want to reclaim capacity for important services that run during nights and weekends.
To accomplish this goal, you might create two files: one to run weekday mornings to increase capacity and efficiency for the employee portal, and one to run weekday evenings to decrease capacity and efficiency.
Morning script example
This example script sets the high threshold for pending requests to 20, which causes WebLogic Feature Pack to start a new service when demand reaches that level—keeping wait times for employees relatively low.
/opt/cassatt/bin/ccgovernor -u admin -p changeme -g PendingRequests
20 EmployeePortal.1.0
Evening script example
This example script sets the high threshold for pending requests to 50, which results in a longer—but still acceptable—wait during a time when you want most resources focused on other services.
/opt/cassatt/bin/ccgovernor -u admin -p changeme -g PendingRequests 50 EmployeePortal.1.0 |
Do not adjust the Managed Server tier's operational target nodes as a means to manipulate resources allocated by WebLogic Feature Pack. WebLogic Feature Pack is designed to adjust the tier operational target automatically based on load thresholds.
If you lower the tier operational target manually, Cassatt Active Response removes a node selected at random, and might remove a node that's running services. Moreover, if the node is required to meet SLAs, WebLogic Feature Pack raises the target and allocates another node, counteracting your removal.
If you raise the target manually, and the node is not needed, WebLogic Feature Pack removes a node, again counteracting your increase.
top
Adding new services
You might need to add services in two kinds of circumstances:
Can your WebLogic Administration Server handle the load?
Before you deploy a new WebLogic service it's a good idea to make sure your WebLogic Administration Server has enough spare capacity to run the new service. Unfortunately, the resources required to manage a domain are highly variable, so I can't provide an exact calculation. Here are some things to explore:
So, your WebLogic Administration Server is at
max—now what? Add another Administration
Server. Because the managed server model in WebLogic
8.1 and 9.2 don't address dynamically scaling
the Administration Servers, this is a manual process:
- In the Cassatt Active Response Controller, create a new tier for the new Administrative Server that is just like the original, and using the same image. Need help? Follow these instructions.
- Allocate and activate the tier.
- Specify the new tier when you configure the service. Watch for this prompt:
Enter the name of the WebLogic admin tier []:
No need to create a second Managed Servers tier; WebLogic Feature Pack supports using different Administration Servers to manage domains in a single Managed Server tier. |
top
Updating a WebLogic domain
When you want to update a domain, you can make changes directly on the WebLogic Administration Server using the WebLogic Administration Console in the usual way. You can make whatever changes are necessary—such as replacing EARs and WARs or switching to a different jdbc connection URL—with one important caveat: any changes must adhere to the same configuration requirements described in Configure your WebLogic domain.
If you alter your WebLogic domain in ways that conflict with the guidance in Configure your WebLogic domain, WebLogic Feature Pack automation will not work properly. Problems may include—but are not limited to: node managers fail to start, applications or services fail to start, Managed Server nodes become "stuck."
Before you alter a WebLogic domain, be sure you understand the implications related to how WebLogic Feature Pack stores and retrieves domain information: your active domain will be out of sync with your captured service image, as shown in the next illustration.
As a best practice, whenever you update your domain on the WebLogic Administration Server using the WebLogic Administration Console, capture a new service image using the node in the WebLogic Administration Server tier as your service host. See Capture your WebLogic domains as "service images." Your newly created service image is then always available with the latest domain changes.
Follow these steps:
- Disable the WebLogic Feature Pack service for the domain.
- Make the necessary changes, including restarting if needed.
- Capture the domain (recommended).
- Enable the WebLogic Feature Pack service for the domain.
top
Updating a WebLogic image used with WebLogic Feature Pack
WebLogic Feature Pack automated control over the tier operational target conflicts with Cassatt Active Response rolling update, which raises the operational target. When Cassatt Active Response raises the operational target, WebLogic Feature Pack lowers it, causing both the image update and WebLogic Feature Pack services to fail.
Follow these steps in conjunction with the standard Cassatt Active Response image management procedures whenever you are updating the image for a WebLogic tier that uses WebLogic Feature Pack.
- Create the new image version as usual.
- Disable all WebLogic Feature Pack services for the tier you are updating
(if you are updating the Administration Server tier,
disable the Administration Console services, which have
a type of either "wl81admin" or
"wl92admin").
- Update the image of the tier using the Cassatt Active Response Controller. You can use rolling update or, to update all nodes at once, deactivate the tier, update, and reactivate.
- Enable the WebLogic Feature Pack services using the Controller Services list.
Be aware that Cassatt Active Response selects image instances at random when allocating nodes. Consequently, the image instances that hosted services prior to the image update might not have nodes allocated following the image update.
When you enable services, WebLogic Feature Pack attempts to start the services on the original nodes. If the nodes are unavailable, WebLogic Feature Pack starts the services on the new nodes. The time needed to restart services therefore varies.
top
Backing up and restoring WebLogic Feature Pack
If you are following the procedures for backing up Cassatt Active Response, you are backing up WebLogic Feature Pack by default.
If you need to backup or
restore just WebLogic Feature Pack service configurations, access files under: /cassatt/dde.
If you need to backup or restore just applications managed
by WebLogic Feature Pack, access these files: /cassatt/services, /cassatt/service_images.
These paths assume your
WebLogic Feature Pack service configurations, services, and service images
are stored on the default Cassatt Active Response base file system. If
they have been stored on another file system,
adjust these paths accordingly.
Removing WebLogic Feature Pack services and
service images
Before removing a service or service
image, follow your standard site policies for
discontinuing usage of an application. To remove the
service and accompanying service
images, use the ccserviceremove and ccserviceimageremove commands.
First, run ccserviceremove:
/opt/cassatt/bin/ccserviceremove
Make sure you know the name and version of the service
you want to remove, and decide whether you want Cassatt Active Response
to remove all files associated with the service.
Keeping the files saves your having to recapture
the service image when you intend to redeploy the same
WebLogic domain with a new service configuration (that
is, when you are updating only the service that runs the
domain, and not the WebLogic domain itself—which
you'll remember I talked about in Adding
new services).
The ccserviceremove utility
sets the minimum services to 0, which stops any remaining
instances of the service as long as all SLAs are below
their thresholds. After waiting for the services to stop, ccserviceremove deletes
the service from working memory, stops the Administration
Server for the WebLogic domain, unmounts the domain file
system and removes its fstab entry,
removes the domain directory mount point, and (optionally)
removes files associated with the service. The ccserviceremove utility
does not remove the domain directory from the Administration
Server.
If there are no other services referencing
the associated service images, you can also remove the
service
image when prompted by the ccserviceremove command:
Do you want to delete
all files associated with the service? [n] y
Do you want to delete the image associated with the service?
[n] y
Alternatively, you can remove a service image by using
the ccserviceimageremove command:
/opt/cassatt/bin/ccserviceimageremove
The command fails if any service references
the service image.
top
Uninstalling WebLogic Feature Pack
Before uninstalling WebLogic Feature Pack, remove all services as described in the last section (removing all files), and deactivate and delete any tiers used for hosting WebLogic Feature Pack services.
Uninstall WebLogic Feature Pack by running the uninstallation script as follows:
- On the control node(s), stop the Cassatt Active Response service using the appropriate command(s):
If using a single control node:
/opt/cassatt/bin/cccoreservice stop
If using dual control nodes:
Use the cccoreservice status command to determine which control node is the active one:
/opt/cassatt/bin/cccoreservice status
On the standby control node, run this command:
/opt/cassatt/bin/cccoreservice stop
On the active control node, run this command:
/opt/cassatt/bin/cccoreservice stop
- Uninstall WebLogic Feature Pack on each control node by entering the following command:
/opt/cassatt/bin/ccwamuninstall
- Restart the Cassatt Active Response service using the following command
on all control nodes:
/opt/cassatt/bin/cccoreservice
start
Troubleshooting
See WebLogic Feature Pack: Troubleshooting.
top
Was this article useful? Tell us what you think.
Email infocentral@cassatt.com.
|
