Administration

Digg This!

Business managers are demanding better, faster, and cheaper access to IT resources and environments. At the same time, IT budgets and resources are being cut, there is a proliferation of servers running at low utilization.

These competing objectives play nicely into consolidation and virtualization of computing resources. A strong case can be made for deploying a virtualized and shared environment designed for hosting multiple BEA WebLogic applications with a high level of isolation between each application.

The Current Problem

Today IT organizations face the challenge of consistently and strategically aligning IT investments with evolving technology and changing business objectives. At the same time, IT must optimize assets, reduce complexity, be cost effective, comply with standards, and improve the stability and flexibility of the environment. Within HP the J2EE application server platform, specifically BEA WebLogic Server, was identified as an area where applying concepts and solutions from utility computing could bring significant benefits to IT groups and the business units served.

In HP's case, there wasn't a federated approach for managing J2EE environments across business units, creating challenges in assuring a cost effective platform. For example, HP internal business units invested in additional hardware, software, and support resources to host their application runtime environments on a per application basis. This led to three significant problems:

1. Redundant infrastructure and support resources across the organization, leading to excess spending and often low resource utilization of each infrastructure
2. Increased time-to-market for solutions because of the time and budget required to obtain hardware, software, and resources
3. Lack of standardization, repeatable processes, and solutions across application teams.

These multidimensional problems impact application teams by reducing their agility and increasing their expense when delivering solutions. Meeting these challenges allows IT to manage the environment better, faster, cheaper, simpler, and smarter.

Our Solution

In early 2003 a team was built to focus on this problem and began a strategic program to develop a Shared Application Server Utility (SASU) infrastructure. This team was chartered to create an adaptable, flexible, and fully monitored environment for hosting J2EE applications on shared virtualized hardware. The goal was to providie a J2EE application hosting service that business partners can use on-demand and eventually be charged back based on actual environment usage. SASU provides the infrastructure and the application provider provides the application and team resources for deployment and support. The infrastructure now runs in production with several applications and has a funnel with many new pending requests.

To deliver the infrastructure, SASU integrates a set of complex emerging technologies to deliver a comprehensive solution. Its servers are deployed in a data center that provides Web server farms, load balancing appliances, external access capabilities, Storage Array Network, and shared database farms. Figure 1 shows the overall SASU infrastructure deployed on a physical machine. The infrastructure can be described in terms of layers.

J2EE Environment Layer
BEA WebLogic Server 8.1 SP2 provides the J2EE platform, including advanced capabilities such as isolated application environment support, administration services, clustering across physical machines, and session state management.

SASU has deployed dedicated domains per application, including dedicated managed servers (often deployed to multiple machines) and a dedicated admin server. This will provide JVM isolation and the ability to deploy, and start and stop applications independently.

Monitoring and Reporting Layer
SASU has deployed monitoring and reporting components based on the HP OpenView product suite. This provides application alerts, historical usage reporting per application, service-level objective violations, and the ability to deploy application specific monitoring requirements through ARM or the inclusion of upcoming components to provide URL availability and transactional level information. The information is captured into a central reporting database that allows for the creation of reports, or for additional automation around responding to specific events occurring in the system.

Management and Control Layer
This is a critical component for providing isolation of shared CPU resources between applications. The key technology is an HP-UX software product - Work Load Manager (WLM).

WLM provides a configuration file where CPU Min/Max resources can be allocated and guaranteed for a specific application process through the definition of a WLM workgroup with an associated service-level objective (SLO). The granularity for the allocation of CPU can be up to 1% of 1 CPU for a workgroup. WLM periodically monitors applications performance characteristics versus the configured service-level objectives of the configured applications. When additional CPU is required to meet increasing load, WLM automatically allocates the additional CPU to keep the application within the min/max range up to its max value, at which time the CPU allocation is capped.

A key benefit of this technology is that system utilization can be pushed to higher levels as applications can get access to the reserve CPUs when required but share the excess capacity with others when not utilized. In addition, errant applications will be capped at their configured max configuration, which will stop an application from overtaking all of the CPU reserve and impacting other applications.

Physical Disk Layer
SASU deploys application disk space into a Storage Area Network with dedicated logical volumes per application that are sized according to an application's needs up front. This allows a specific application's disk space to be completely isolated from others on the system. All application-specific files and logs will reside in this space.

Processes and Automation
SASU provides a consistent and repeatable development and promotion to production methodology, including standard shared functional test, integration test, and production infrastructure and maintenance. This enables application development teams to focus on their application functionality without dealing with infrastructure configuration and maintenance, enabling simplified and accelerated application deployment, and testing and repeatable environment creation steps. An essential component for delivering environments quickly and in a repeatable manner is the automation of the WebLogic domain creation.

Automating WebLogic Domain Creation and Configuration

Life Before Automation
Imagine you're hosting multiple applications in a shared WebLogic environment. Two to three new applications must be deployed each week, each requiring its own dedicated domain with users, passwords, port numbers, JVM arguments, classpath configuration, and a host of other unique server properties. Creating these by hand, using the Domain Configuration Wizard, administration console, and other tools, can easily become a full-time job.

Automation Done Thus Far
Wanting to get out of the "hands-on administrator" business, we embraced "wlshell" to assist our automation effort. We began by creating a flat configuration file. The file contains wlshell environment variables for all the static and dynamic configuration variables which make up the common MBean properties needing configuration in a new domain. This configuration file is used as input to a domain configuration wizard script template, which creates a basic entry-level domain. After the basic domain is created, we start the admin server and run generic wlshell scripts that set all the properties defined in the domain environment file. This automation has exponentially shortened the amount of time and effort necessary to create an application domain.

What Lies Ahead
Investigation is now under way automating other areas, including uploading and tracking application versions, as well as deployment. Going forward, we must be careful not to "over-automate" in order to ensure that the interface and functionality remain flexible. The key is in striking the right balance between the GUI approach, and automation.

Another key automation candidate is the "promotion" of applications between environments (for example, taking an application from test to production). BEA is working on features such as deployment plans in future releases, which should ease configuration issues when promoting applications. Any automation work must account for and take full advantage of such features.

Automation not only increases the speed and efficiency of operations, but also provides a highly "repeatable" process that is much less error prone than manual processes.

Things to Consider

Embracing a shift from traditional infrastructure to utility computing requires changes across three dimensions: people, processes, and technology. It is critical to define a solution that takes all three dimentions into account. A strong technical solution and architecture will not be successful without a buy-in from application teams and sponsors for the changes in process to be part of a shared environment. With a solid plan and organization structure both application teams and IT sponsors should benefit from reduced costs and faster time-to-market offered from a shared infrastructure.