The IBM WebSphere CloudBurst Appliance gives you the capability to create IBM WebSphere Application Server virtual systems in a private cloud. These virtual systems are the running instantiation of WebSphere middleware environments represented by WebSphere CloudBurst patterns. Patterns are a logical representation of a WebSphere middleware environment, complete with WebSphere Application Server components, configuration settings, and other customizations. These patterns can represent anything from a single server WebSphere Application Server environment, to a more complex, clustered environment (Figure 1).
Figure 1. WebSphere Application Server Hypervisor Edition
The WebSphere CloudBurst Appliance ships with a set of patterns that have been built and tuned by IBM. These patterns represent the deep knowledge and best practices that have evolved from over ten years of experience with WebSphere Application Server deployments. These shipped patterns provide out-of-the-box value because they are ready to be deployed to a private cloud.
However, because these patterns will not meet the needs of every possible WebSphere Application Server deployment, you need the ability to define your own custom WebSphere middleware topologies with your own configuration and deployment settings. Using the customization capabilities provided in the WebSphere CloudBurst Appliance, you can produce highly customized WebSphere middleware environments and then save those customized configurations as patterns so they can then be reused as necessary.
Customized WebSphere CloudBurst patterns
To satisfy a wider range of topologies, WebSphere CloudBurst provides several ways in which patterns can be customized:
- Using image extension, you can customize the images from which patterns can be defined. This approach (to be discussed in Part 4 of this article series) enables fixed changes to be applied to all topologies; for example, the installation of virus detection software.
- WebSphere Application Server topologies can be varied by changing the number and types of nodes.
- Built-in WebSphere Application Server environment configuration scripts can be identified and included into the pattern. These advanced configuration options provide well-defined and standard approaches to common configurations.
- User applications, in the form of scripts, can be associated with the nodes in the topology, enabling general post installation configuration. Pattern authors can exercise varying degrees of control over deployment by choosing to lock deployment time parameters, ensuring fixed values for every deployment.
Starting the customization process
The facilities for customizing WebSphere CloudBurst patterns are quite consumable and intuitive. This article will stick to the WebSphere CloudBurst console, which provides a Web 2.0 style interface for interacting with patterns on the appliance. Remember, though, that customized patterns can be created using the WebSphere CloudBurst command line interface as well.
To create a customized pattern, you can choose an existing pattern to clone, or you can create an entirely new pattern. To clone an existing pattern, select the pattern you want to start with and click the Clone button in the upper right toolbar. To create a new pattern, select the green cross in the left panel of the Patterns page. Both options are illustrated in Figure 2.
Figure 2. Creating new patterns
Regardless of which method you use, the dialog in Figure 3 will display so you can enter information about the pattern.
Figure 3. New pattern dialog prompt
The information includes a name for the pattern, a description, and a virtual image on which the pattern will be based. You can select any virtual image that you have access to for the basis of a pattern. The selection of the virtual image is important as it establishes, among other things, the version of WebSphere Application Server that is present in the pattern.
After this initial information has been supplied, you can begin to edit the pattern by clicking on the pencil icon in the upper right toolbar. This displays the Pattern Editor page where you can customize the WebSphere Application Server topology and configuration settings in the new pattern.
From the Pattern Editor, you can begin to edit the WebSphere Application Server components that make up your topology. For the purpose of this article, an example pattern called My custom cluster will be constructed. Initially, this pattern contains a deployment manager, two custom nodes, and an IBM HTTP Server. On the Pattern Editor page, this pattern is represented as shown in Figure 4.
Figure 4. Cluster environment in Pattern Editor
For some types of components, the number of components in the pattern can be adjusted using up/down arrows on the upper left corner of the virtual part diagram. For example, in My custom cluster, the custom node and IBM HTTP Server components each have such arrows displayed. Click on the arrows to increase and decrease the number of either within the pattern. Components that typically appear only once in a pattern do not have quantity spinners.
Also notice the Virtual Image Parts listing in the left panel. This is a list of the available WebSphere Application Server components that can be included in this pattern. The list is determined by the image you selected when creating the pattern. You can add extra components to the pattern by dragging and dropping the components from the left panel onto the pattern canvas. In Figure 5, the Job Manager component has been added as a part in the My custom cluster pattern.
Figure 5. Adding parts to patterns
The Pattern Editor uses a grid to place the different components onto the pattern canvas in an arrangement that is indicative of the relationships between the components. In particular, it places manager nodes, such as deployment managers and job managers, in the first column. It places managed nodes, such as custom nodes, in the center column, and it places load balancing nodes, such as IBM HTTP servers, in the third column. If there are virtual parts that do not fall into one of these categories they are placed in the center column. This placement into columns helps you better visualize these sometimes complex relationships. In addition, the Pattern Editor will give you warnings if you attempt to build invalid WebSphere Application Server topologies.
Figure 6. Invalid topology warning
In Figure 6, the pattern author has a topology that contains custom nodes but no deployment manager part. The Pattern Editor recognizes this faulty WebSphere Application Server topology and warns the user.
Warnings are informative; they do not prevent a pattern from being deployed. Warnings are meant to inform you that the pattern does not follow best practices for a WebSphere Application Server configuration. Common pattern configuration errors include:
- Pattern contains more than one deployment manager or job manager.
- Pattern includes a deployment manager but no custom nodes.
- Pattern includes custom nodes but no deployment manager.
- Pattern has a job manager but no deployment managers or administrative agents.
- Pattern includes administrative agents but no job manager.
- Custom nodes are not federated to a deployment manager because there are multiple deployment managers.
- A standalone node is federated to a deployment manager; if a standalone node and a deployment manager are in the same pattern, the standalone node will be federated by the deployment manager making it behave like a custom node.
Configuring advanced options for the pattern
Beyond creating a customized WebSphere Application Server topology, you can also use the Pattern Editor to configure common WebSphere Application Server environment settings into the pattern. To access these settings, select the Advanced Options button in the Pattern Editor. The Pattern Editor evaluates the topology to classify it, and, based on its classification as a standalone pattern, a development cluster, a cluster or a large cluster, you are presented with different configuration options.
Figure 7. Advanced options for patterns
The set of advanced options include the ability to configure messaging, enable session persistence, and activate global security in the WebSphere Application Server environment:
- Messaging: Creates a WebSphere Application Server cluster that contains members which are part of a Service Integration Bus. A message engine is also established for the bus, and a DataSource for that message engine is established.
- Session persistence: Creates a WebSphere Application Server cluster whose members are configured for HTTP session persistence. Users can choose either database persistence or memory-to-memory persistence.
- Global security: Enabled by default, this option enables global security in the WebSphere Application Server environment. Optionally, secure messaging can be enabled.
For more on these options, refer to the WebSphere Application Server Information Center for the appropriate product version.
When you have made your configuration choices, click OK. The visual representation of the pattern is updated so you can see the application configuration choices you have made. In particular, new boxes will appear within the deployment manager and custom nodes. These boxes represent the configuration choices. Additional parameters, such as the number and sizes of the application clusters that will be created, can be specified by clicking on the properties icon within these boxes.
Recall that the set of valid advanced configuration options depends on the topology of the pattern. Subsequent changes to the topology might invalidate the assumptions that were made when the advanced configuration dialog was presented. As you edit the topology, it is continuously evaluated to see if any configuration choices have become invalid. If any are invalid, the advanced configurations are automatically removed from the pattern, making it then necessary to click the Advanced options button and make new choices.
Be aware that once these settings are selected for a pattern, they become part of the stored pattern. This means that each and every deployment of the pattern will result in a WebSphere Application Server environment with this configuration.
In the same panel where you see the words "Virtual Image Parts," the Script Packages drop-down menu is also available. Script packages are .zip files that contain executable scripts, such as wsadmin scripts or shell scripts, and supporting artifacts. These script packages can be included in the pattern and are invoked by WebSphere CloudBurst after the virtual machines comprising the pattern topology are deployed and started. Script packages can be used to do just about anything since they only need to supply something that is executable along with any supporting artifacts.
You can add scripts to the individual nodes in a pattern by selecting them and dropping them on the target node. A box representing the script is shown inside the node. (Part 3 in this series will describe how to utilize script packages as a means of customizing middleware environments dispensed by the WebSphere CloudBurst Appliance.)
Configuring settings for pattern parts
In addition to the Advanced Option settings, WebSphere CloudBurst also lets you configure properties on each of the parts and scripts in the pattern. These settings include WebSphere Application Server properties, virtual machine properties, and script parameters.
Figure 8. Pattern part properties
To set properties, click on the properties icon in the upper right corner of each pattern part or script figure. By setting these values, you set default values for each property. In addition, you can lock the value of a property, fixing its value for all deployments. A property value is locked when you click on the lock icon to the right of the property value.
In Figure 9, for example, the password for the root user on the deployment manager part was locked as part of the pattern. This means that the root user password for all deployment manager virtual machines deployed from this pattern will utilize the same password.
Figure 9. Locking pattern properties
Pattern parts, such as custom nodes and IBM HTTP servers, represent multiple nodes with a single figure in the pattern. When setting properties on these pattern parts, the parameter values are applied to all instances of the part that are deployed. However, there are some properties that should be unique per deployment such as the custom node property Node name. In such a case, the configured property value is treated as a prefix to which a unique integer is appended.
For each part in a pattern, property values that were not locked in the pattern are supplied at deployment time. Locking properties for parts in a pattern can be very useful, but you should balance this capability against enabling maximum pattern reuse. For example, you should usually avoid locking things like WebSphere Application Server cell and node names as part of the pattern because these will likely be unique for each and every deployment. WebSphere CloudBurst lets you specify settings that are particular to specific deployments during deployment.
In Figure 10, the My custom cluster pattern is being deployed. During the deployment you would provide configuration information for each of the parts that make up the pattern. This is the same information that was seen when customizing the pattern parts in the Pattern Editor. Notice that locked properties do not appear in the deployment time dialog.
Figure 10. Deploying the My custom cluster pattern
Figure 11 shows the deployment information panel for the deployment manager part in the My custom cluster pattern. You don’t see or provide a value for the root user password because that value had been locked as part of the pattern.
Figure 11. Locked properties during deployment
When all of the required deployment information is supplied and a name is given for the deployment, WebSphere CloudBurst begins the deployment process. The result of the deployment is a customized WebSphere Application Server virtual system running in your private cloud.
You can benefit from the out-of-the-box capabilities derived from the patterns that are shipped with the WebSphere CloudBurst Appliance. These hardened, best-practice WebSphere Application Server configurations are ready to be deployed to a private cloud. When these patterns don’t suit your needs, you have the option of customizing the patterns as you require.
Customizations can include topology changes, configuration settings, installing user applications, and more. Further, you are afforded a great deal of flexibility in what information is stored in the pattern versus the information that can be specified for each pattern deployment. All of this adds up to the creation of customized WebSphere Application Server patterns that promote reuse among a group of users, while still enabling each user to insert deployment-specific customizations into the environment.
Watch for the next article in this series, which will look at the use of script packages in WebSphere CloudBurst.
Learn
- More in this series
- Part 1: Creating highly customized private clouds
- Part 3: Using script packages for customizing above and beyond patterns
- Cloud computing for the enterprise
(series)
- Part 1: Capturing the cloud
- Part 2: WebSphere sMash and DB2 Express-C on the Amazon EC2 public cloud
- Part 3: Using WebSphere CloudBurst to create private clouds
-
WebSphere
CloudBurst Appliance product information
-
Cloud Computing Journal
-
Is
there value in cloud computing?
-
IBM developerWorks
WebSphere
Discuss
- Space:
WebSphere Cloud Computing for Developers
- Space:
Cloud Computing
Central
- YouTube:
WebSphere CloudBurst Appliance videos
- Forum:
WebSphere CloudBurst Appliance Forum
- Blog:
A view from the clouds: Cloud computing for the WebSphere developer
-
Follow us on
Twitter
Dustin Amrhein joined IBM as a member of the development team for WebSphere Application Server. While in that position, Dustin worked primarily on Web services infrastructure and Web services programming models. In addition, Dustin worked on the development of a RESTful services framework for Java runtimes. In his current role, Dustin is a technical evangelist for emerging technologies in IBM’s WebSphere portfolio.
Michael Kalantar joined IBM research in 1997. His research interests include distributed systems, application provisioning and automation. The pattern editor in IBM WebSphere CloudBurst represents the application of his work on model driven systems management to the problem. Michael received his B. Sc. from the University of Alberta in 1989 and his M.Sc. and Ph.D. from Cornell Univeristy in 1992 and 1995, respectively. He spend two years teaching computer science in China before joining IBM.
Comments (Undergoing maintenance)
Table of contents
Next steps from IBM
My developerWorks community
Tags
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).
My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).
Popular article tags |
My article tagsSkip to tags list
Popular article tags |
My article tags
