The introduction of IBM® PureSystems™ family of products takes cloud computing to new heights. IBM PureSystems — in the form of IBM PureApplication™ System and IBM PureFlex™ System — is an expert, integrated cloud system that encompasses applications, services, hardware, and even the expertise — delivered in the form of best practices patterns — to integrate, deploy, and maintain an enterprise-level cloud environment.
The IBM PureApplication System architecture supports three models of workloads, three different types of workloads used to deliver cloud solutions:
- The use of virtual application patterns through workload platform services. A virtual application represents a collection of application components, behavioral policies, and their relationships. Using this application-centric definition of the workload the IBM PureApplication System will automatically construct the necessary infrastructure and middleware resources to provision and continually manage this virtual application.
- The use of virtual system patterns through virtualized middleware services. Virtual system patterns are a logical representation of a recurring topology for a given set of deployment requirements. For example: A WebSphere® Application Server Cluster pattern containing IBM Deployment Manager, one or more custom nodes, IBM Http Server, and configuration scripts for installing applications to the topology. Using this approach the detailed middleware configuration is explicitly defined and IBM PureApplication System will provision the exact system defined in this virtual system pattern.
- The use of virtual appliances through virtualized infrastructure services. A virtual appliance represents a single server workload instance consisting of a preconfigured operating system environment including necessary middleware and application elements preinstalled in an Open Virtualization Format image.
The developerWorks community will provide resources to explain these elements; in this article, we'll discuss one of these key components and how it affects IT professionals — the virtual system pattern.
The big picture
Basically, IBM PureApplication System has integrated hardware and software which combines virtualized workloads and scalable infrastructure. Included are middleware support for data and runtime along with the deployment and management capabilities that streamline and speed these activities, making them more efficient.
Virtual system patterns are focused on the middleware layers of the system by defining repeatable, deployable topologies that can be shared. The fundamental building blocks of virtual system patterns are parts that are delivered with virtual images. These parts, together with configuration parameters, scripts, and add-ons, are used to create complex patterns that are deployed as a single unit.
Reducing deployment time, increasing consistency, and fostering agility are benefits you would likely expect when exploring cloud-based approaches for your middleware application environments. IBM PureApplication System solution, built upon the foundation of IBM Workload Deployer and other technologies, tackles these issues making the deployment of cloud middleware environments fast, repeatable, and efficient.
The pattern-based approach is the foundation of IBM PureApplication System and is consistent for both virtual application patterns and virtual system patterns. Using the cloud appliance, you build and deploy patterns that represent your completely configured application environments. When you are ready to use a particular application environment, you simply pick a pattern and deploy it. IBM PureApplication System automates the deployment, configuration, and integration of the various virtual machines that make up your environment and delivers the completed product in a matter of minutes.
The elements and functions of a virtual system pattern
As we touched on earlier, virtual system patterns (also known as topology patterns) represent repeatable topology definitions based on various middleware virtual images and runtime configurations. Virtual system patterns provide flexibility and control over the middleware topology to be deployed.
Anatomy of a virtual system pattern
Figure 1 shows an overview of how you can create a virtual system pattern from components in the catalog:
Figure 1. A generalized view of creating a virtual system pattern from catalog components
Virtual systems consisting of one or more virtual image parts are a foundational deployment model of IBM PureApplication System. A virtual system is defined in IBM PureApplication System through a virtual system pattern, a provisionable unit of one or more virtual images to be installed, configured, and integrated in order to implement a topology.
Virtual system patterns can be as simple as a single server product instance or as complex as a multi-product, multi-node deployment.
IBM-supplied, best practice, virtual system patterns come pre-loaded on the appliance; the culmination of years of experience working with our customers to understand optimal configurations. Once a virtual system pattern is provisioned from IBM PureApplication System, it is referred to as a virtual system instance.
Virtual system patterns can be customized or new patterns can be created using the Pattern Editor in the IBM PureApplication System user interface. Customization in the Pattern Editor is achieved using a simple drag-and-drop interface from a pallet of parts (derived from virtual images), script packages, and add-ons.
A virtual system pattern typically consists of one or more middleware elements working together to provide the necessary platform for a complete application. An example of a virtual system pattern for a WebSphere® configuration might contain multiple parts, each representing a virtual machine that includes a Linux® operating system with WebSphere Application Server or other middleware software pre-installed and enabled for activation. The pattern might include a deployment manager, several custom nodes, a DB2® database, and an IBM HTTP Server.
Using a virtual system pattern gives you more control over the middleware topology, but it also requires that you configure the middleware for your particular application needs. Script packages can be added to the pattern to automate further customization of the virtual systems topology; for example, a script package to create WebSphere resources and to install an application.
When a virtual system pattern is deployed, the appliance creates the topology, builds the relationships between the components (for example, federating the custom nodes to the deployment manager), and configures the middleware based on the script packages you provide. System administrators can login to the system to perform additional customization if necessary — but the best practice is to provide the complete configuration of the system in the pattern using image customizations, parameters, add-ons, and automation scripts to create a pattern that can be consistently deployed to the cloud.
The ability to integrate standard aspects of high availability and fault tolerance are contained within the topology.
With a virtual system pattern, you define exactly the type of middleware configuration that you need for your application environment and IBM PureApplication System provisions exactly that configuration when the pattern is deployed to your private cloud.
We've already touched on the building blocks of a virtual system pattern, but let's go into a little more detail on these items.
Parts contained in hypervisor edition images
The most fundamental of building blocks for virtual system patterns are parts that are delivered with hypervisor edition images. So the logical questions are
- What is a hypervisor edition image?
- What is a part?
What is a hypervisor edition image?
In a nutshell, a hypervisor edition image is a delivery of some middleware product that is packaged according to the Open Virtualization Format (OVF) in an Open Virtualization Archive (OVA) file. These images are imported into a virtual image catalogue within IBM PureApplication System Application Services.
A hypervisor edition image consists of some middleware product such as WebSphere Application Server that is pre-installed and pre-configured, along with an operating system (typically Linux), and specifically designed for virtual environments. As an example, for the WebSphere Application Server we typically show the composition of the virtual image as an operating system, WebSphere Application Server and IBM HTTP Server binaries, and WebSphere Application Server profiles, along with the "special sauce."
Figure 2. Overview of a hypervisor edition image
Okay, so what is this special sauce? It's a combination of code and tuning built into the image to optimize WebSphere Application Server for a virtual environment.
The main elements of the hypervisor edition image include:
- Preinstalled and preconfigured image
- Image-specific tuning
- Fast deploy-time activation capabilities
By pre-installed, we mean that all of the elements, operating system, middleware, middleware dependencies and feature packs, and necessary maintenance for all elements are preinstalled into the image. You don't need to install the middleware or operating system or develop a script to do this — it is all handled automatically by using the hypervisor edition image.
Since IBM is pre-installing both middleware and the underlying operating system, the image is specifically tuned for best practices and optimal performance in a virtual environment. And it is lightening fast when deploying images because the installation and optimization has been done ahead of time. All that is necessary to do during deployment is to refine the configuration and run some activation logic. Maintenance is also simplified because it is available as fully installed images for the complete solution.
What is a part?
The elements of the middleware are delivered in the hypervisor image as parts. For example, the WebSphere Application Server hypervisor edition image includes parts for the deployment manager, custom node, standalone node, job manager, and so on. Having these common profiles preconfigured in the image again saves significant deployment time when compared with traditional deployment processes where profile creation is done later by scripting.
Detailed middleware configuration and provisioning for specific purposes is handled by an activation agent. While the preinstallation, configuration, and tuning is nice, you can consider activation the real "secret ingredient" in hypervisor edition image.
For WebSphere, the activation capabilities support having this one image transform into different WebSphere Application Server configurations when it is initially started. This enables one template image to be copied and quickly reconfigured for very rapid provisioning of different WebSphere Application Server environments. This is accomplished through an activation code included within the image that reads input parameters, maps these parameters to different preconfigured profiles, and performs reconfiguration.
Specifically, during activation, reconfiguration scripts inside the image inject the new network settings (IP address, hostname, passwords, and so on); reconfigure WebSphere Application Server parameters for cell name, node name, and so on; and start the WebSphere Application Server profile corresponding to the server type. Replacement or injection of the configuration metadata for both the OS and WebSphere Application Server profiles provides a significant time savings. The activation enables an image to quickly assume and adjust for new network settings, passwords, and WebSphere Application Server personalities, from deployment managers to custom nodes and job managers.
Parts are the primary building block of any virtual system pattern. However, there are other fundamental elements of a virtual system pattern that are necessary to support detailed customization - namely script packages and add-ons.
In IBM PureApplication System virtual system patterns, a script package is your vehicle to provide custom middleware configuration. This may mean installing applications, configuring application dependencies, or otherwise tuning the middleware layer.
Script packages are essentially ZIP files that include some executables (shell script, wsadmin script, Java™ program, etc.) and optionally, artifacts that support the execution of the script. As you can see there is not a singular, mandatory format for a script. You will find that you can reuse many of the same scripts that you have been using in your traditional deployments.
As was the intention, you can achieve just about anything you want with a script package. This allows you to be as flexible and creative as you need to be. Scripts can be parameterized so that deploy-time configuration can be supplied. This allows a common script to be applied for many purposes on many parts. Scripts are imported into the IBM PureApplication System script catalog and can then be associated with parts contained in virtual system patterns.
Add-ons are specialized scripts to customize the virtual machine configuration. Add-ons let you modify the virtual machine configuration during deployment without the need to modify and save a new image configuration. You can use add-ons to augment the hardware and OS configuration of a virtual machine.
Add-ons greatly simplify the task of doing lower-level OS configuration changes. For example, with the Add disk add-on, you only need to drag and drop the add-on from the Pattern Editor palette to the appropriate part and then configure the parameters.
You use add-ons like custom scripts: You create and clone them in the appliance catalog as necessary and then drag them onto parts in the Virtual System Pattern Editor. The primary difference is that add-ons are run before any custom scripts and they target the virtual machine configuration.
However, while add-ons are like scripts, but there are significant differences. First, add-ons are not listed with the custom scripts. They have their own category in the catalog. Add-ons execute before any custom scripts for a part at the time of deployment. Unlike custom scripts, you cannot specify the order of add-on execution on a part. Add-ons are run only during system creation; you cannot initiate them on demand. They use hypervisor-level APIs to configure new hardware in virtual machines during deployment.
Virtual system pattern editing views and parts
Let's talk a bit about the virtual system patterns built from these elements. IBM PureApplication System ships with a number of pre-defined virtual system patterns that represent best practices derived from years of experience working with customers. These patterns represent common configurations from simple to advanced WebSphere environments, various DB2® configurations for Enterprise and Express, WebSphere Portal, WebSphere Message Broker, WebSphere MQ, and many other common topologies.
The pre-defined patterns may fit your needs exactly and you can deploy them without any changes. However, it is more likely that you will want to clone and extend these patterns or create your own custom patterns from scratch. We will now cover the mechanics of editing and building virtual system patterns.
Figure 3. Virtual System Patterns view
The Patterns window
When you select a virtual system pattern to edit in Pattern window, you can see detailed information about the virtual system pattern. A view of the topology for the pattern is deployed in the right panel of the Pattern window.
The topology for a virtual system pattern is described graphically for editing purposes; virtual image parts, add-ons, and script packages can be dropped onto an editing canvas to create or change relationships between the parts that define the topology. All of this is done in the pattern editor.
The Pattern Editor window
Clicking the edit icon on the upper right panel of the Patterns window opens the Pattern Editor window for the selected virtual system pattern. The Pattern Editor window provides lists to select virtual image parts, add-ons, and script packages.
Figure 4. A virtual system pattern in the Pattern Editor
Virtual image parts
Selecting the Parts list on the Pattern Editor provides a listing of the parts that can be dropped onto the virtual system pattern canvas. The virtual system pattern canvas is on the right panel of the Pattern window. Some common virtual image parts include:
- Administrative agents
- Custom nodes
- Deployment managers
- HTTP servers
- Job managers
- Standalone servers
- On-demand routers
- DB2 servers
- and much more ...
The parts are determined by the virtual images you are using. Some virtual image parts represent multiple instances; there is a badge on the editing canvas that indicates the number of instances of each part.
You can configure the part properties either when you deploy the virtual system pattern or directly from the part in the pattern editor deployment. To configure the part before deploying it, click the Edit Properties icon for the part on the editing canvas. Selecting to lock a property will prevent changes in that property during deployment.
The Scripts list on the Pattern Editor provides a listing of the script packages that can be dropped onto the virtual image parts. This list can contain script packages associated with the virtual image and any that you have defined for use with IBM PureApplication System.
Common add-ons can be added to parts on the editing canvas, such as:
- Default add disk: Adds a virtual disk to the virtual machine and, optionally, formats and mounts the disk.
- Default add NIC: Adds a virtual network interface controller (NIC) to the virtual machine, configures IP address information for it, and activates it.
- Default add user: Defines an additional user on the virtual machine.
- Default add raw disk: Add a virtual disk to the virtual machine but does not format or mount the disk.
Customized versions of add-on types can also be created and made available to meet your particular needs and added to the catalog. An add-on can be created from scratch or cloned and modified from the default set.
Interaction between virtual image parts
Virtual image parts can be defined to interact with other virtual image parts. When the interacting virtual image parts are included in the same virtual system pattern, cross-configuration results. For example, when a custom node and a deployment manager are placed in the same virtual system pattern, they are automatically cross-configured. This results in the custom node being federated to the deployment manager. Similarly, administrative agents (or deployment managers) are registered with a job manager.
Virtual image parts can be cross-configured if the virtual system pattern editor can determine a unique relationship. If it is unable to do so, no cross-configuration occurs. For example, if a custom node is added to a virtual system pattern with two deployment managers, no federation takes place. However, if one of the deployment managers is later removed, cross-configuration occurs because a unique relationship now exists.
You can use the version indicator on the parts to ensure that they are referencing the same version of the virtual image in the catalog. If the version of a part is incorrect, you can change it when the part is on the editing canvas. Hovering over the part name opens a window with additional information about the virtual image.
Developing a virtual system pattern
You can build a virtual system pattern by creating one outright or by cloning an existing one.
Cloning a then-customizable virtual system pattern
First you select the pre-existing pattern that most closely fits your needs. (Here are some patterns from IBM Workload Deployer.)
Then it's as simple as pressing a button to clone and rename the pattern. Then you can customize the clone in the Pattern Editor window by adding, removing, editing parts; add or remove script packages or add-ons; configure properties for parts; configure parameters for script packages; set parts start-up order; etc.
For more on this step, see "Cloning an existing virtual system pattern."
Creating a virtual system pattern
Surprise! This method is just as easy as the cloning method; in this case, the first step is to add a new pattern. Then you go through the same steps as you would when cloning a virtual system pattern.
For more on this step, see "Creating a virtual system pattern."
Whenever possible you should attempt to reuse the predefined virtual system patterns or use them as a starting point. This can save you substantial time and if you don't require any customization it will save you from having to maintain custom versions of these patterns.
Using a virtual system pattern
You might be asking yourself "what conditions suit the use of an IBM PureApplication System virtual system pattern over a virtual application pattern?" In this case, let's further define the question so that it makes more sense.
In essence, virtual system patterns are similar to virtual application patterns in that they both represent models of a virtualized application for deployment to the cloud. When we refer to patterns in the context of cloud, we are referring to the encapsulation of installation, configuration, and integration activities that make deploying and managing environments in a cloud much easier. Regardless of what kind of pattern you end up using, you benefit from treating a potentially complex middleware infrastructure environment or middleware application as a single atomic unit throughout its life cycle of creation, deployment, and management.
Let's start by considering the cloud tradeoff continuum in order to understand the differences between the application and the systems pattern deployments. (Again, we've used IWD since it is the immediate ancestor technology and we've got lots of data and experience using it.)
Figure 5. The cloud tradeoff continuum
- The X-axis represents the degree to which you have customization control over the resulting environment. The degree of control gets lower as you move from left to right.
- The left Y-axis represents total cost of ownership (TCO) which decreases as you move up the axis.
- The right Y-axis represents time to value which similarly decreases as you go up the axis.
Naturally, enterprises want to move up the Y-axis, but they are sometimes hesitant to relinquish much control (move to the right on the X-axis) in order to do so.
With what this figure shows as a reference point, start to think about the two patterns-based approaches a bit more.
Scenario: Using a virtual system pattern
Consider a fairly simple web service application that you want to deploy to the cloud. If you were to use a virtual system pattern to achieve this, you would probably start by using parts from the WebSphere Application Server Hypervisor Edition image to layout the topology. You may include a deployment manager, two custom nodes, and a web server.
After establishing the topology, you would add custom script packages to install the web service application and then configure any resources the application depended on. Users that wanted to deploy the virtual system pattern would access it, provide configuration details such as the WebSphere Server cell name, node names, virtual resource allocation, and custom script parameters, and then deploy.
Once deployed, users could access the environment and middleware infrastructure as they always have. That means they could run administrative scripts, access the administrative console provided by the deployed middleware software, and any other thing they would normally want to do.
Same scenario: Using a virtual application pattern
Using a virtual application pattern to support the same web service application would result in a markedly different experience from both a deployment and management standpoint.
In using the virtual application pattern approach, a user would start by selecting a suitable virtual application pattern type based on the type of application. This may be a pattern type shipped by IBM, such as the Pattern for Web Applications, or it may be one created by the user through the extensibility mechanisms built into the appliance.
After selecting the appropriate pattern, a user would supply the web service application, define functional and non-functional requirements for the application via policies, and then deploy.
The virtual application pattern and IBM PureApplication System provide the knowledge necessary to install, configure, and integrate the middleware infrastructure and the application itself. Once deployed, a user manages the resultant application environment through a radically simplified lens provided by IBM PureApplication System. It provides monitoring and ongoing management of the environment in a context appropriate for the application.
This means that there are typically no administrative consoles and users can only alter well-defined facets of the environment. It is a substantial shift in the mindset of deploying and managing middleware applications.
So how do I decide?
The main point is, when you deploy software using a virtual system pattern, for the most part you manage the environment the same way you have always managed it for that particular type of software; normally via administration consoles. With virtual system patterns, you don't focus on changing the way you operate or manage the software; instead, you primarily focus on improving the delivery of said software.
With virtual application patterns, you fundamentally change everything about those environments. You are working with a highly optimized and automated solution. The burden of managing high availability and dynamically react to changing conditions is built into the pattern type solution so you only need to specify your business level requirements. The management and operations of that environment are completely integrated in the IBM PureApplication System user interface. Everything is integrated and highly specialized for the specific application type.
You should base your decision on your requirements and management needs for the particular application that is being considered.
For each application, you need to decide whether you favor the middleware-infrastructure-centric approach of virtual system patterns or if you prefer the application-centric approach of virtual application patterns. You may be driven by the need to support very specific configurations that don't fit easily into an already available virtual application pattern type. In that case you may choose to create your own virtual application pattern type or use a virtual system pattern to create the exact topology that your application requires — perhaps replicating a physical environment that you previously implemented. In other cases you may find that your application fits well into one of the virtual application pattern types that are already provided.
Whenever possible you should seek to leverage the optimization and convenience of a virtual application pattern as this will always provide the lowest total cost of ownership and shortest time to value. However, there will certainly be scenarios where you require very detailed configurations and therefore decide in favor of the detailed control that is available with virtual system patterns.
The most important thing is to understand all of the options and make an informed decision. Look at your use case, understand what's available to help you accomplish that use case, and finally, decide on what you want your user's experience to be.
Finally, it is also important to note that IBM PureApplication System supports both of these models concurrently. You can have a mix of virtual applications, virtual system, and even virtual appliances all deployed to the same pool of cloud resources. The robust capabilities built into IBM PureApplication System enable this variety of deployments, allowing you to choose the deployment model for each application to deliver the best fit with this highest return on investment.
We introduced you to virtual system patterns and their place in the IBM PureApplication System ecosystem (as well as how they compare and contrast with virtual application patterns); we also described virtual system pattern components and functions, and provided a basic look at how to create and use a virtual system pattern.
For more experience in pattern-centric cloud deployment, take a look at the companion communities, forums, articles, and videos in the Resources section.
- Learn more about IBM PureSystems.
- Find IBM PureSystems resources on developerWorks
For more on how to perform tasks in the IBM Cloud, visit these resources:
- Up and download files from a Windows instance.
- Install IIS web server on Windows 2008 R2.
- Create an IBM Cloud instance with the Linux command line.
- Create an IBM Cloud instance with the Windows command line.
- Extend your corporate network with the IBM Cloud.
- High availability apps in the IBM Cloud.
- Parameterize cloud images for custom instances on the fly.
- Windows-targeted approaches to IBM Cloud provisioning.
- Deploy products using rapid deployment service.
- Integrate your authentication policy using a proxy.
- Configure the Linux Logical Volume Manager.
- Deploy a complex topology using a deployment utility tool.
- Provision and configure an instance that spans a public and private VLAN.
- Secure IBM Cloud access for Android devices.
- Recover data in IBM SmartCloud Enterprise.
- Secure virtual machine instances in the cloud.
- In the developerWorks cloud developer resources, discover and share knowledge and experience of application and services developers building their projects for cloud deployment.
- Find out how to access IBM SmartCloud Enterprise; developing on SmartCloud is a great way to practice developing for IBM PureSystems.
Get products and technologies
- See the product images available for IBM SmartCloud Enterprise.
- Join a cloud computing group on developerWorks.
- Read all the great cloud blogs on developerWorks.
- Join the developerWorks community, a professional network and unified set of community tools for connecting, sharing, and collaborating.
Dig deeper into Cloud computing on developerWorks
Exclusive tools to build your next great app. Learn more.
Crazy about Cloud? Sign up for our monthly newsletter and the latest cloud news.
Deploy public cloud instances in as few as 5 minutes. Try the SoftLayer public cloud instance for one month.