Architecture for virtualization

---

This section introduces the key concepts and techniques that are important for preparing and creating a virtualized application server environment. It provides possible scenarios for resource sharing at the application server level, using the previously discussed WebSphere Application Server, Version 5 features and techniques. Sample scripts to deploy applications and administer requirements to expand and contract application capacity were developed and tested in conjunction with the writing of this chapter; see the section Sample script for listings of some of these sample scripts.

First, a review of the terminology used in this section:

Server machine. This term refers to the smallest possible control point used for allocating and managing resources. It consists of memory, CPU(s), associated I/O, and a single operating system image. Typically, a server machine is in fact a single physical machine; however, there are mature technologies that allow a single (typically much larger) physical machine to be logically (and, in some cases, dynamically) split into multiple independently manageable server machines. The rest of this architecture section uses the term server machine to refer interchangeably to a single physical or a single logical server machine. From the application software's perspective there is no difference, nor should there be. More detailed discussions on this subject can be found in the section LPARs in a virtualized server environment.

WAS (WebSphere Application Server) install. A WAS install refers to a single installation of WebSphere Application Server. Multiple WAS installs could include multiple WebSphere Application Server versions and/or multiple installations of one version.

WAS (WebSphere Application Server) instance. Each WAS install can create one or multiple configuration WAS instances. This chapter focuses mainly on the one WAS instance per WAS install configuration.

application server. An application server is a WebSphere managed JVM process running the J2EE server that contains user applications.

node. A node is a logical grouping of WebSphere managed server JVM processes that share common configuration and operational control on a single server machine or LPAR. A single server machine or LPAR can have multiple nodes, each with multiple application servers. There is only one node per WAS instance. Each node is controlled by a JVM running a special application (called a node agent) that acts on behalf of the node for administrative purposes.

Application isolation

A major architecture consideration for running an application in a shared environment is the trade-offs between application isolation and resource sharing. To get the maximum use of server resources, it may be necessary to deploy multiple applications on a single physical server machine. This is especially true when there are many low volume applications or the physical server machines have large processing capabilities.

This section shows the best practice configurations for sharing resources at the smallest possible resource element -- a single server machine or logical partition (LPAR). To establish the basic concepts for sharing and isolation, these configurations focus on application deployment without provisions for failover or workload management. Failover and workload management are fundamental requirements for application server resource sharing environments and are addressed in the next section, which assumes the basic application isolation/sharing principles are understood. These configurations can be used as building blocks for constructing resource-sharing environments. They can also be used to construct viable multiserver deployments for applications with high volume requirements and those that are business critical and require failover support to meet availability requirements.

This section presents four configurations to illustrate varying degrees of sharing and isolation. It concludes with a discussion of the trade-offs of applying hosting cost considerations to the various configurations.

Configuration 1: Hardware level isolation

In this configuration, one WAS install is installed on a server machine. One application server (JVM) was created in this WAS install instance. Figure 2-6 shows one enterprise application deployed to the application server.

Figure 2-6: Configuration 1 -- hardware level isolation

There is no resource sharing. This configuration offers the highest possible application isolation -- hardware level isolation.

This configuration is ideal for high-priority and high-traffic applications. High-priority applications require the least risk of interference. This type of isolation is possible for high-traffic and low-priority applications because the load usually requires several physical servers.

Configuration 2: Application server sharing

Figure 2-7 shows a configuration where one WAS install is installed on a server machine. One application server (JVM) was created in this WAS install instance. However, more than one enterprise applications are deployed to the application server (JVM).

Figure 2-7: Configuration 2 -- application server sharing

This configuration offers the highest possible resource sharing in a single server machine. However, application isolation is at its lowest and hence risk of interference is at its highest. In this configuration, all applications share a single application server (JVM). Misbehavior by any one of the applications, such as a memory leak or an overloaded request, can affect the performance of all applications.

This configuration should be used only for low-priority, low-traffic, mature and stable applications, and if the decision maker believes that the cost of memory required for separate Java virtual machines (JVM) is not justified

Configuration 3: Application server level isolation

Figure 2-8 is a configuration where one WAS install is installed on a server machine. However, the WAS install instance contains more than one application server (JVM). Each application server (JVM) has one enterprise application deployed.

Figure 2-8: Configuration 3 -- application server isolation

This configuration offers application sharing at the JVM level. Because each application is running on an isolated application server (JVM), misbehavior by any one of the applications, such as a memory leak or an overloaded request, does not affect the performance of the other applications.

This is the most cost effective configuration to share resources. It can be used for high priority and low-traffic applications. It can even be used for high priority and high-traffic application if surplus CPU resources are available

Configuration 4: WebSphere software level isolation

Figure 2-9 shows a configuration where multiple WAS installs are installed on a server machine. Each WAS install instance contains one application server (JVM) and each application server (JVM) has one enterprise application deployed.

Figure 2-9: Configuration 4 -- WebSphere software level isolation

This configuration offers application isolation at the JVM and WebSphere software level. This is a configuration to consider when running different versions of WebSphere Application Server on the same machine is necessary during an application's migration from one version to another.

Sharing versus isolation -- the trade-offs

The basic trade-offs between application isolation and resource sharing benefits are shown in Figure 2-10. The highest level of application isolation, hardware level isolation, usually imposes the highest hardware cost. The lowest level of application isolation, application server sharing, usually gives the lowest hardware costs because multiple applications share the resources of one JVM process.

Figure 2-10: Application isolation vs. hardware cost

WebSphere Application Server, Version 5 provides tools that can significantly reduce system administration costs. More discussions about cost-effective system administration of WebSphere Application Server in a shared environment can be found in the section System administration.

Figure 2-11 shows that for high-traffic applications that require several physical servers to satisfy the load, the hardware level isolation can be used to achieve utmost application isolation and resource use. Note that this does not mean the servers are necessarily dedicated to that application. As application resource use increases or decreases, server capacity can easily be shifted to other applications using provisioning techniques and scripts that are described later.

Figure 2-11: Trade-offs between application isolation and hosting cost

Also shown in Figure 2-11 is the fact that, although the application-server sharing configuration (configuration 2, Figure 2-7) offers the highest possible resource sharing, it does not necessarily do so at the lowest possible hosting cost. The potentially undesirable interference among applications may cause application availability problems and bring additional support requirements and thus increase the overall hosting cost.

Given these considerations, the application server level isolation is the most cost-effective configuration for a shared environment when any single application does not consume a server's entire complement of CPU and memory resources. There is no significant difference in application isolation gain between application server (configuration 3) and WebSphere software level isolation (configuration 4). WebSphere software level isolation (configuration 4) consumes additional memory and creates additional system management work (overhead) and therefore should only be used when running different versions of WebSphere Application Server on the same machine is necessary due to such activities as migrating applications or WebSphere versions.

To summarize, effective cost saving can be achieved by balancing application isolation, resource use, system administrative costs, and application workload priority. Identifying and classifying applications into the correct workload priority is an important factor for determining application deployment options and architecture selection.

WebSphere Application Server, Version 5's clustering features provide high availability and workload management capabilities in application server shared environments.

In a shared or virtualized environment, horizontal clustering should be used to eliminate any single machine as a point of failure. At a minimum, all applications should be deployed in a two-server horizontal clustering environment where application server processes are physically separated onto two different machines. Vertical clustering, or multiple application server processes on the same physical machine, can be used to improve process availability, or better use of resources on a single node. However, horizontal-clustering rules should not be overlooked for each separate application server process in the vertical cluster to assure availability and failover needs are met.

For a discussion of advanced clustering techniques, see part 4 of the IBM Redbook IBM WebSphere V5.0 Performance, Scalability and High Availability and Chapter 3 of this redbook.

Configuration 5: High availability and isolation

Figure 2-12 shows a two-machine horizontal cluster configuration where one WAS install is installed to each of the two server machines. Only one application server (JVM) was created in each WebSphere Application Server instance, and there is only one application installed to the application server (see configuration 1, Figure 2-6). This configuration represents the highest possible application isolation, failover, and availability. This sample configuration is targeted for high-priority and high-volume applications.

Figure 2-12: Configuration 5 -- horizontal clustering of two servers

Note 

Because failover and high availability of Web servers are outside the scope of this chapter, Figure 2-12 shows only one Web server. In a production environment, appropriate considerations in architecture should be taken to prevent any server from becoming a single point of failure.

Configuration 6: High availability for low-volume applications

Figure 2-13 shows a configuration where two applications are installed into a shared environment of three servers. Both horizontal and vertical clustering techniques are used.

Figure 2-13: Configuration 6 -- horizontal and vertical clustering

This configuration also demonstrates one way the HTTP workload management's two-level failover support can be used. Application 2 in the sample configuration represents a low-priority and low-traffic application. Because application 2 is deployed to a shared environment, it should be installed to at least a two-server horizontal clustering to ensure adequate failover and availability. However, due to its low-traffic, there is not really a need for additional capacity. The second application server member is therefore configured as a backup server. Since the HTTP plug-in does not route requests to any server in the backup server group when there are servers available in the primary server group, this configuration can save runtime resources and at the same time satisfy the failover and availability requirements.

Configuration 7: Multiple WebSphere version coexistence

Figure 2-14 shows a configuration where two different WebSphere Application Server versions are installed to a single server machine. Although it is possible to run multiple versions of WebSphere Application Server in a shared environment, it's recommended to run multiple versions in a shared environment only when it is absolutely necessary to do so, such as during the upgrade and migration to a new version of WebSphere.

Figure 2-14: Configuration 7 -- coexistence of two WebSphere versions

Configuration 8: Clustering and application server sharing

Figure 2-15 shows a configuration where multiple applications are installed to an application server. As discussed earlier, while this configuration offers the highest possible resource use, it also results in the lowest application isolation. This configuration should be used only for low-priority, low-traffic, mature, stable applications.

Figure 2-15: Configuration 8 -- multiple applications in an application server (JVM)

System administration

System administration is a major challenge in a shared server environment. Simply sharing servers without the proper approach to administration can increase complexity, thereby erasing any cost savings derived from increased use. This section explains techniques for server and application provisioning and monitoring that can be used to decrease the complexity of system administration.

Server and application provisioning in a shared environment

A shared environment requires tools that facilitate adding and removing applications, and the capability to easily shift capacity between applications. WebSphere Application Server, Version 5 provides this tooling capability with the wsadmin tool. Scripting can be used for production environments and unattended operations to simplify and ensure the consistency of the administrative tasks. Automation of these administrative tasks leads to cost effective system and operation management processes that are reliable and efficient.

Working with several IBM customers, the High-Volume Web Sites (HVWS) organization has developed and used scripts run by wsadmin to manage virtualized server environments.e Examples of these functions include:

• Add capacity to an application without adding hardware to a running shared environment. The scripts to carry out this function include: adding a new application server to a cluster, starting up the server, and regenerating the plug-in. (see Appendix A for sample script listing)

• Expand capacity by adding a new server machine. This function includes adding a new node to a cell environment, followed by adding the needed application server.

• Remove excess capacity. This function includes draining the current users from the target node and removing the node from the cell environment.

• Shift capacity from one application to another. This function includes add and delete application server members from a cluster and add and remove nodes from a cell.

Automating these functions with scripts assures that the actions take place in a timely, effective, and accurate/repeatable manner.

Sample architecture

Based on the configurations discussed above, this section shows an example of the application deployment architecture for a virtualized environment. It ends with a discussion that shows capacity can be reallocated, on demand, using the sample scripts described above.

Figure 2-16 shows how applications can be categorized based on their workload traffic and priority characteristics, ranging from applications with low priority and low load (applications G and H) all the way up to an applications with high priority and/or high load (applications A, B, and C).

Figure 2-16: Application categorization

Using the architectural configurations discussed earlier and the application workload attributes shown in Figure 2-16, Figure 2-17 shows a sample architecture where applications are deployed to a virtualized environment based on their workload traffic and priority classifications. This figure shows a before-virtualization view and an after-virtualization view.

Figure 2-17: A sample of a resource sharing virtualization environment

In Figure 2-17, each gray box represents a machine or LPAR that has one WebSphere Application Server installation. Each colored box with a single letter represents an application server with one application deployed. For example, the green rectangular box with letter A represents an application server with application A installed. Each application is deployed on its own application server to achieve isolation at the application server level. The before view on the left side shows varying amounts of gray space (or underused resources and capacity). The right side represents the after view where the entire collection of applications is redeployed into fewer server machines and there is a noticeable increase in resource use across the active server machines that are actively in the pool.

Application A is a high priority and high traffic application. Therefore, it is deployed using the horizontal clustering technique to accomplish the highest level of application isolation, failover, and availability (configuration 1 and 5, Figure 2-6 and Figure 2-12). Of course, vertical clustering can be added to improve process availability or resource use if there are excessive resources available on these machines.

Although application B is not a high-traffic application, its priority is high enough to justify its deployment on its own hardware to assure the highest possible isolation.

The remaining applications are medium or low priority applications that are deployed with the application server level isolation configuration and across the landscape with an eye towards optimizing overall server machine use.

As more is learned about each application and its workload attributes based on actual experience, adjustments to the deployments can be made to refine the optimizations. These activities can be undertaken without having to engage the developers because the virtualization process has decoupled the application's view of the physical infrastructure allowing the complement of resources to be adjusted.

Applications B and C are seasonal high-priority or high-traffic applications. Their resource use needs to be adjusted from time to time (Figure 2-17). Increasing or decreasing capacity is effectively achieved by running the scripts as discussed.

In this virtualized environment sample, applications B and C are seasonal high-priority and seasonal high-traffic application respectively. The quantity and type of resources allocated to each now need to be adjusted because it is the end of the high-priority period for application B and the beginning of the high traffic season for application C. Figure 2-18 shows that resources are adjusted by relinquishing two server machines previously dedicated to application B and extended application B's horizontal cluster to share a server machine with three other single application JVMs. The resources for application C were expanded to a 4 dedicated-server-machine-cluster from its previous low traffic configuration in which a cluster of two members spread across two separate shared (multiple single JVM apps) server machines. As part of the expansion for application C, a new server machine was provisioned into the pool.

Figure 2-18: Increasing and decreasing capacity in a shared environment

Again, the tasks of expanding capacity, contracting capacity, and provisioning (or decommissioning) server machines are achieved effectively by running the scripts discussed above in the section Server and application provisioning in a shared environment.

---