Classic virtual system patterns overview
Use a classic virtual system pattern to rapidly set up and manage your cloud middleware topology. A classic virtual system pattern describes a middleware topology and employs the tools to automatically build that topology in the cloud.
PureApplication® Software has integrated hardware and software which combines virtualized workloads and scalable infrastructure. Included are middleware support for data and run time along with the deployment and management capabilities that streamline and speed these activities, making them more efficient.
Classic 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 classic virtual system patterns are parts that are delivered with virtual images. These parts, together with configuration parameters and other artifacts such as script packages and add-ons, are used to create complex patterns that are deployed as a single unit.
Classic virtual system patterns are the captured essence of years of infrastructure-management experience and best practices. Classic virtual system patterns encapsulate repeatable topology definitions that are based on various middleware images and runtime configurations; they give you control over the middleware landscape that is deployed.
IBM-supplied, best practice, classic virtual system patterns come preloaded on the system; the culmination of years of experience working with our customers to understand optimal configurations. Classic virtual system patterns can be as simple as a single server product instance or as complex as a multiproduct, multinode deployment.
A virtual system is defined through a classic virtual system pattern, consisting of one or more virtual images to be installed, configured, and integrated to implement a topology. After a classic virtual system pattern is deployed into the cloud environment, it is referred to as a virtual system instance.
When a classic 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 that 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 customization, parameters, add-ons, and automation scripts to create a pattern that can be consistently deployed to the cloud. Support for high availability and fault tolerance functions are also contained within the topology.
Classic virtual system pattern components
A classic 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 classic virtual system pattern for a WebSphere® configuration might contain multiple parts that are delivered with hypervisor edition images, with each part representing a virtual machine that includes a Linux operating system with WebSphere Application Server or other middleware software preinstalled and enabled for activation. The pattern might include a deployment manager, several custom nodes, a DB2® database, and an IBM® HTTP server.
Using a classic 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 and add-ons 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.
You can customize classic virtual system patterns, or new patterns can be created using the Pattern Editor user interface. Customize your patterns using simple drag-and-drop operations, selecting from a catalog of parts (derived from virtual images), script packages, and add-ons.
Parts contained in hypervisor edition images
A hypervisor edition image is a delivery of middleware product that is packaged according to the Open Virtualization Format (OVF) in an Open Virtualization Archive (OVA) file. When you obtain these images, you can import them into a catalog of virtual image parts within PureApplication Software.
A hypervisor edition image typically includes middleware product such as WebSphere Application Server that is preinstalled and pre-configured, along with an operating system (Linux, AIX®, or Windows), specifically designed for virtual environments. For example, a WebSphere Application Server virtual image might be composed of an operating system, WebSphere Application Server and IBM HTTP Server binary files, and WebSphere Application Server profiles, along with additional code and tuning built into the image to optimize WebSphere Application Server for a virtual environment.
Preinstalled means that all of the elements, operating system, middleware, middleware dependencies and feature packs, and necessary maintenance upgrades are preinstalled into the image. You do not need to install the middleware or operating system, nor develop a script to perform these tasks. The hypervisor edition image handles all these tasks automatically.
Because IBM pre-installs both the middleware and the underlying operating system, the image is specifically tuned for best practices and optimal performance in a virtual environment. Deploying images also completes quickly because the installation and optimization have been done ahead of time. All you need to do during deployment is to refine the configuration and run some activation logic. Maintenance is also simplified because the fully installed image is a complete solution.
The elements of the middleware are contained 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 pre-configured in the image 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 useful, the activation capabilities support having this one image transform into different configurations when it is initially started. By using this capability, the same template image can be copied and quickly re-configured for rapid provisioning of different environments. The activation code included in the image reads input parameters, maps these parameters to different pre-configured profiles, and performs reconfiguration.
During activation, reconfiguration scripts inside the image specify new network settings, such as IP address, host name, and passwords), re-configure WebSphere Application Server parameters, such as cell name, and node name, and start the WebSphere Application Server profile corresponding to the server type. The activation enables an image to quickly adjust to new network settings, passwords, and WebSphere Application Server personalities, from deployment managers to custom nodes and job managers.
Script packages
In a classic virtual system pattern, script packages provide detailed custom middleware configuration, including installing applications, configuring application dependencies, or otherwise tuning the middleware layer.
Script packages are compressed files that include some executable files (shell script, wsadmin script, Java program, etc.) and optional artifacts that support the execution of the scripts. There is no singular, mandatory format for a script package. You can reuse many of the same scripts that you have been using in your traditional deployments.
You can perform a wide variety of configuration and customization tasks with a script package. You can provide parameter values in script packages so that additional configuration at deployment time can be supplied. With this flexibility you can use a common script package for different purposes on multiple parts. Script packages are added to the PureApplication Software script package catalog and can then be associated with parts contained in classic virtual system patterns.
Add-ons
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 operating system configuration of a virtual machine.
Add-ons simplify the task of making lower-level operating system configuration changes. You need only to drag the add-on from the Pattern Editor list of available add-ons and drop it onto the appropriate part, and then configure any additional parameters as needed.
You use add-ons like a customized script package, creating or cloning them in the catalog as necessary, and then dragging them onto parts in the Pattern Editor. The primary difference is that add-ons are run at deployment time before any custom script packages, and they target the virtual machine configuration.
Unlike custom scripts, however, you cannot specify the order of execution for add-ons added to 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.
Managing classic virtual system patterns
- Use predefined classic virtual system patterns as they are.
- Copy (or clone) predefined classic virtual system patterns and customize them.
- Create new classic virtual system patterns.
- Edit any classic virtual system pattern that is not read-only.
You can use parts from multiple virtual images in a single classic virtual system pattern. For example, you might build a classic virtual system pattern that includes WebSphere Application Server, IBM WebSphere Process Server, and DB2 components. Deploying the example classic virtual system pattern installs and initializes the product components.
You can edit the configuration parameters of the parts, script packages, and add-ons that you have included in your classic virtual system patterns.
- Use the console.
- Use the command-line interface or REST API to work with patterns outside of the console.
You can configure advanced options for the classic virtual system patterns. See the related tasks for more information.