 | Level: Introductory Mahi R. Inampudi (inampudi@us.ibm.com), Lead IT Architect, IBM
Murali Narasimhadevara (muralin@us.ibm.com), Senior IT Architect and Webmaster, IBM
Paulo Palacios (ppalacio@us.ibm.com), IT Architect, IBM
31 Jan 2006 This article, the second in a series, continues to follow the IBM intranet portal team as they upgrade the IBM internal enterprise applications infrastructure. Migrating WebSphere® applications into a WebSphere Extended Deployment environment has several major steps involving server layout, infrastructure building, and capacity and performance testing. This article explains key aspects of moving IBM's internal hosted applications to a WebSphere Application Server and WebSphere Extended Deployment infrastructure.
Introduction
In this series about upgrading the IBM internal enterprise applications infrastructure, Part 1 explains the problems to be solved, the proposed solutions, and how the team uses the features of WebSphere Extended Deployment to achieve their goals.
This article serves as a migration guide to adopting WebSphere Extended Deployment in your own environment. It covers:
In Part 3 you'll learn about design patterns that can help an application achieve autonomic resiliency to protect, optimize, and reconfigure itself, and heal from outages. We'll discuss a short-circuit pattern to circumvent a deadlock situation, a service availability pattern, and show how to apply a service availability pattern to a sample application.
Network topology
Our IBM corporate intranet uses a cluster of WebSphere caching proxy servers in front of the WebSphere Extended Deployment cluster, and a generic Web server cluster. For the generic Web server, an IBM HTTP Server (IHS) cluster was used for serving static content. To view a diagram of the topology our team uses, see Part 1 of this series.
An alternate method is to use a Web server in front of the WebSphere Application Server Extended Deployment nodes. There are many different network topologies possible with WebSphere Extended Deployment. Several topologies are discussed in detail in the article "IBM WebSphere Developer Technical Journal: Exploring new network topologies made possible by WebSphere Extended Deployment and the On Demand Router" (see Resources).
Capacity requirements
Capacity planning for WebSphere Extended Deployment is no different from infrastructure capacity planning for WebSphere Application Server. The only additional component, compared to a
non-WebSphere Extended Deployment environment, is the On Demand Router (ODR). You can view ODRs as a very advanced version of what used to be called WebSphere plug-ins inside Web servers. ODRs perform dynamic application placement, dynamic workload management, and come with many more autonomic computing features built in. Figure 1 shows the throughput managed by ODR compared to IHS WebSphere plug-in performance.
Figure 1. ODR versus WebSphere Application Server plug-in performance
The IBM corporate intranet environment currently needs more ODR capacity than is available. The goal is to migrate as many non-Extended Deployment WebSphere applications as possible to the WebSphere Extended Deployment environment to use features such as dynamic application placement, which will reduce costs by increasing white space on our infrastructure.
Installing WebSphere Extended Deployment
After your network topology is defined and capacity planning is complete, the next step involves actually installing WebSphere Extended Deployment. There are three different categories of nodes, with one or more for each category based on capacity and high availability requirements. They are: Deployment Manager nodes, ODR Nodes, and WebSphere Application Server nodes.
The high-level steps required for creating a WebSphere Extended Deployment environment are:
- Install WebSphere Application Server, the Java™ Development Kit (JDK), and the Deployment Manager on the Dmgr node.
It is important to install the correct version of the JDK so that WebSphere Extended Deployment is not impacted by some of the bugs in the JDK. See the WebSphere Extended Deployment installation requirements, or WebSphere Extended Deployment, to get the latest version of the JDK that goes with WebSphere Extended Deployment installation.
- Perform a WebSphere Application Server base installation on WebSphere Application Server nodes and on ODR nodes.
- Run
addNode on each of the WebSphere Application Server nodes and ODRs to create an WebSphere Extended Deployment cell.
- Install WebSphere Extended Deployment on Dmgr.
- Install WebSphere Extended Deployment on WebSphere Application Server nodes and ODR nodes.
- Start Dmgr, and start node agents on WebSphere Application Server nodes and ODR nodes.
Creating the ODR
To create a new ODR:
- Open Administrative Console > Expand Servers, and select On Demand Router.
- Click New. You should see a window similar to Figure 2.
Figure 2. Creating ODR
- Select the node Node that is meant for ODR.
- Use Server name: ODR011.
- Select template: Default On Demand router template.
- Click Next.
- Review the information to make sure you are creating ODR on the correct server.
- Click Finish.
- Save the configuration, as shown in Figure 3. Always make sure to check the box to Synchronize changes with Nodes.
Figure 3. Confirm ODR configuration
- Expand Servers in the Administrative Console.
- Click the On Demand Router link in the left navigation area.
- Select the ODR you just created, and click Start.
Dynamic cluster for applications
To create a dynamic cluster:
- Expand Servers and click Dynamic Cluster.
- Click New on the Dynamic Clusters panel. Use the following settings, as shown in Figure 4.
- Dynamic Cluster name: DynamicABCCluster
- Map to Node Group: WASNodes
- Prefer local: Checked (Default)
- Internal replication domain: UNchecked (default)
- SelectTemplate: Default application server template
- Minimum number of member instance to start when activated: 1 (default)
- Maximum number of instances: -1 (Default)
- Click Next, then Finish
Figure 4. Create dynamic cluster
- Save the configuration, and make sure to select Synchronize changes with Nodes.
Static content cluster
Most common topologies involve placing the ODR behind the HTTP server plug-in. WebSphere Extended Deployment allows for a different option of placing the ODR in front of the HTTP servers and not using a plug-in at all. This option gives the ODR the responsibility for routing requests to the HTTP servers, and performing load balancing. The value is that it offloads the responsibility of serving static content from the application servers to the HTTP servers. WebSphere Extended Deployment supports this configuration through generic clusters.
A generic cluster is a set of similar resources that are not managed by the cell's Deployment Manager for which the ODR routes and load balances HTTP traffic. Load balancing is done in a round robin fashion depending on static weights. To create a static cluster configuration:
- Create the generic cluster.
Select Servers > Generic Server Clusters in the Administrative Console. Select New to create a new cluster, as shown in Figure 5.
Figure 5. Creating static cluster, Step 1
- Assign ports.
Ports are the server resources contained within the cluster. On the Generic Clusters Configuration panel, select Ports under Additional Properties. Select New to create a new Port, as shown in Figure 6.
Figure 6. Creating static cluster, Step 2
- Create the routing rules.
Routing rules are used to determine how to map requests for specific URIs to generic clusters. Defining this mapping is a two step process:
- Create a URI Group, which contains a logically related set of URIs. Select On Demand Routers > Your ODR name in the Administrative Console, as shown in Figure 7. Select URI Groups under Related Items on the ODR Configuration panel. Select New to create a New URI Group.
Figure 7. Creating static cluster, Step 3
- Create a routing rule. Select On Demand Routers > Your ODR name in the Administrative Console. Select Routing rule under General Properties on the ODR Configuration panel, as shown in Figure 8. Select New to create a New Routing Rule.
Figure 8. Creating static cluster, Step 4
Defining service policies
WebSphere Extended Deployment service policies involve a few relatively simple administrative tasks, but they have a significant impact on the overall behavior of multiple applications on a WebSphere Extended Deployment shared, virtualized environment. Policies dictate the way WebSphere Extended Deployment manages resources among the different deployed applications to satisfy the configured service goals. WebSphere Extended Deployment manages through flow control and automatic starting or stopping of applications' instances.
We need to define a process to derive the primary parameters that make up a WebSphere Extended Deployment service policy. The process should focus around the business importance and operational aspects of applications. The decisions that match an application with a certain policy and response time goal should best reflect the actual business priorities and goals. (Discussion of this process is outside the scope of this article.)
To define a WebSphere Extended Deployment service policy:
- Select Operational Policies > Service Policies from the Administrative Console. Select New to create a new Service Policy. The policy Name is arbitrary. The Goal Type has three options: Average Response Time, Percentile Response Time, or Discretionary. In this example, we'll choose Average Response Time, as shown in Figure 9.
Figure 9. Creating service policies, Step 1
Select Next.
- Indicate the maximum response time that this service policy will enforce, and select an Importance value, as shown in Figure 10.
Figure 10. Creating service policies, Step 2
- Select Next.
- A service policy needs to be linked to a set of application URIs, so we need to create a Transaction Class. As shown in Figure 11, select New.
Figure 11. Creating service policies, Step 3
- Select a name for your Transaction Class and optionally provide a description, as shown in Figure 12.
Figure 12. Creating service policies, Step 4
- Select Next.
- As shown in Figure 13, select the target application from the installed Enterprise Application list, and the corresponding .war module. Select all the Available URIs that should meet this service policy. Select Add to add these URIs to this Transaction Class.
Figure 13. Creating service policies, Step 5
- Select Next.
- Select Finish to confirm the Transaction Class creation, as shown in Figure 14.
Figure 14. Creating service policies, Step 6
- As shown in Figure 15, select Next.
Figure 15. Creating service policies, Step 7
- Confirm the new service policy creation by pressing Finish, as shown in Figure 16.
Figure 16. Creating service policies, Step 8
- To apply the changes to the master configuration, click Save, as shown in Figure 17.
Figure 17. Creating service policies, Step 9
- To update the master repository, select Save, as shown in Figure 18.
Figure 18. Creating service policies, Step 10
 |
Defining health policies
Our health policy is defined with an "Out of memory health check," to detect servers that are running out of memory, so we can be proactive in responding to failures.
- Select Operation Service Policies > Health Policies > New, and complete the fields in Figure 19 as follows.
- Reaction Mode: Monitor will only notify, Supervise will notify with the possibility for administrators to approve action, and Automatic means WebSphere Extended Deployment will restart the affected server automatically.
- Cell-wide Policy: Checked
- Health Condition: Excessive Memory Condition
Figure 19. Creating excessive memory usage condition, Step 1
- Select Next.
- For the fields shown in Figure 20 use:
- Total Memory Used: 85%
- Time Over Memory Threshold: 5 minutes
Figure 20. Creating excessive memory usage condition, Step 2
- Select Next.
- Go to Runtime Operations > Task Management > Notifications, and use the following input:
- SMTP hostname: us.ibm.com
- SMTP port: 25
- Enable notifications: True
- E-mail addresses: add the people who should be notified
WebSphere Extended Deployment provides a few other health policy definitions, such as excessive work load monitoring, age-based conditions, and excessive response time conditions.
Testing, operating, and administering
A combination of Rational® Performance Tester and WebSphere Extended Deployment's Administrative Console charts helped application developers understand
the performance details at the transaction level, and tune the application components to match the performance expectations. This was the first WebSphere Extended Deployment production deployment for such a high-volume Web infrastructure, and we had a share of WebSphere Extended Deployment's product PMR list. But, the IBM Software Group support made "Going Live" an easy deployment in the end.
Traditional process-level monitoring at the operating system level, such as Trevi monitoring, will need a slight change with WebSphere Extended Deployment. For example, with WebSphere Application Server, when an application server cluster is started it is expected that all Java processes for that application are found. With WebSphere Extended Deployment, application clusters are dynamic clusters. During WebSphere Extended Deployment configuration, administrators specify the minimum number of instances of the application that must be running in the dynamic cluster. WebSphere Extended Deployment then chooses the most available WebSphere Application Server nodes to run those minimum number of instances of the application in the cell. With WebSphere Extended Deployment, it makes more sense to monitor a group of servers for a given process definition. If the total count is less than the minimum number of instances for a given application, you would have an error situation and send alert messages, such as e-mails or paging the administrators to take actions.
WebSphere Extended Deployment Administrative Console charts, such as the one in Figure 21, can help developers get a better understanding of their applications during
run time under a production load. WebSphere Extended Deployment provides details about CPU usage, memory usage on WebSphere Application Server nodes, throughput, and concurrency of transactions. This information could be very helpful in production problem determination. For example, a transaction named LDAPSearch could
tell developers how well the Lightweight Directory Access Protocol (LDAP) cluster is responding at that moment, which not only shows the application code performance aspect, but
also how one component in the infrastructure, such as LDAP, could affect the entire application infrastructure.
Figure 21. Response Time chart
Conclusion
Moving your applications to a WebSphere Extended Deployment infrastructure takes planning, and great attention to migration details. This article serves as a migration aid to help you move from a WebSphere clustered environment to a WebSphere Extended Deployment-based environment for hosting many applications. We covered the particulars of installing WebSphere Extended Deployment and creating the environment with three categories of nodes. We also discussed how to set up service and health policies and how to use Administrative Console charts for problem determination.
After proclaiming how WebSphere Extended Deployment takes care of everything for you, we warn you not to expect it to drive your car or cook a meal for you. There are lots of things we still need to do. In the next installment of this series, we'll discuss some of the application resiliency design patterns to self-protect IT portfolios from being affected by undesirable outages
on heavily used infrastructure services or Web services in an enterprise architecture. Stay tuned!
Resources Learn
Discuss
About the authors | 
| | Mahi R. Inampudi is the lead IT architect for IBM's On Demand Workplace expertise location system (BluePages). Other responsibilities include the architecture and solution design for several of IBM's internal offerings and collaborating with the CIO office and IBM Research helping design applications using the latest SOA methods. Recent interests include leveraging newer technologies, such as WebSphere Extended Deployment, the Rational product suite, and IBM's intraGrid architecture. |
| 
| | Murali Narasimhadevara is a Senior IT architect with the IBM CIO office. Murali is also the Senior Webmaster for the IBM intranet, and has been helping develop it for the past eight years. He has extensive experience in building and managing high volume Web sites, application and Web server administration with a focus in WebSphere, performance/capacity planning, and enterprise application design. His areas of interest are in autonomic and utility computing for managing Web infrastructures. |
| 
| | Paulo Palacios is an IBM Certified IT Architect. He has over 19 years of experience in IT, providing services in consulting and IT architect roles to clients across multiple industries in the United States and Latin America . Mr. Palacios specializes in application performance evaluation, performance testing, capacity planning, and architecture design of high performance, highly scalable on demand infrastructure. |
Rate this page
| |
