In the first part of this post I described a sample architecture (shown in the figure below). Now I will describe one possible solution to implement it, using the IBM PureApplication System.
Exploring the infrastructure aspects
Concerning infrastructure, I focused on network aspects only. There are other interesting considerations regarding, for example, the management of resource allocation. You may want to have a look at this article to find out more.
IBM PureApplication System works with networks by IP groups, where each IP group is a collection of IP addresses that are available for use by the deployed systems.
An IP group can be assigned to a cloud group, and a cloud group is a collection of compute nodes. Of course, an IP group can be assigned to a specific VLAN ID, and this allows the creation of separated logical networks.
Looking back to the sample scenario, each zone will belong to a specific cloud group, which in turn contains an IP group that maps to a specific network (VLAN ID).
Mapping the architecture to patterns
To implement the sample architecture, I used a combination of different deployment models:
Zone B:
- a virtual application pattern including “TradingOnLine internet” and the Internet database
- a virtual application pattern including the Internet user registry
Zone A:
- a virtual application pattern including “TradingOnLine intranet”
- a virtual application pattern including the intranet user registry
- a virtual system pattern including the intranet database
- a virtual system pattern including the batch engines
Whenever possible, the adoption of a virtual application pattern should be the first choice. However, I did not use this approach with the batch engine component. That is because I assumed that this component is a monolithic custom application, clearly not compatible with the virtual application pattern.
In contrast, even though the best choice to build up the intranet database would dictate the use of the IBM database patterns, here I adopted a different approach by embracing the virtual system pattern, just to make the scenario more interesting (showing the interaction between patterns of different nature) to lay out.
Customizing virtual images
All systems of the sample architecture must have specific third-party software installed. This technical constraint can be addressed in different ways depending on the deployment model.
Creating a new custom base image for virtual applications
PureApplication Systems are shipped with the preinstalled virtual image “IBM OS Image for Red Hat Linux Systems.” This image is a prerequisite for deploying virtual application patterns (as well as shared services). To build the sample architecture, it is necessary to extend the custom base image. This can be accomplished following this macro procedure:
- From the virtual image catalog select the custom base image.
- Choose “clone and extend,” and the PureApplication System will deploy the image.
- Install the third-party software onto the deployed system.
- Capture the deployed system, in order to have the TradingOnLine batch engine virtual image listed in the catalog.
In order to make the new custom base image ready to be used by the virtual application patterns, you just need to change the default virtual image of the PureApplication System. So, the custom virtual image will be used by the PureApplication System to deploy any newer virtual application patterns.
Building a script to customize the DB2 virtual system
The best way to install the third-party software on DB2 systems is through a custom script. In a PureApplication System, a script is basically an archive (.zip) file containing artifacts that you want to be executed during the deployment phase of a virtual machine. The script can be as simple as a single file or as complex as containing an entire new product. Therefore, by editing a virtual system pattern, it is possible to attach custom scripts on every virtual image you put onto the workspace.
I believe the script offers great flexibility here. An alternative method requires the customization of the predefined image of DB2 through this procedure:
- From the virtual image catalog select the DB2 database server image.
- Choose the feature “clone and extend,” and PureApplication System will deploy the virtual image.
- Install the third-party software onto the deployed system.
- Capture the deployed system, in order to have the new DB2 database server image listed in the catalog.
Building the TradingOnLine batch engine virtual system
The TradingOnLine batch engine may be installed into a virtual image and used as a building block of virtual system patterns.
I thought the IBM Construction and Composition Tool (ICCT) could be an option for building the virtual image. This tool can be used to create virtual workloads targeting several private cloud deployment platforms (including those not from IBM). It comes with support for both x86 and IBM Power hardware architectures. Building the virtual image using this tool would require:
- Importing the IBM OS Image for Red Hat Linux Systems from PureApplication System to ICCT
- Creating new software bundles for the specific third-party software in ICCT
- Creating new software bundles for the TradingOnLine batch engine application in ICCT
- Adding the new software bundles to the new custom base image
- Importing the new custom base image from ICCT to the PureApplication System
Of course, an alternative exists to build the virtual image of the batch engine. It implies the usage of the cloning and the capturing features of the PureApplication System. In this later case, the procedure is as follows:
- From the virtual image catalog, select the new custom base image built for virtual applications (it already contains the third-party software).
- Choose the feature “clone and extend,” and the PureApplication System will deploy the virtual image.
- Install the batch engine application into the deployed system.
- Capture the deployed system, in order to have TradingOnLine batch engine virtual image listed in the catalog.
Designing the patterns
The figure below shows how I designed the sample architecture. The diagram shows a composition of patterns of different types. Connections between patterns also indicate the cardinality between patterns.
One note about the communication between patterns: the TradingOnLine intranet application uses a “generic target” object to communicate with the batch engine. The generic target is a specialized component that allows other components (like an enterprise application) to open outbound TCP/IP connections toward an external service. To address the same need, the TradingOnLine internet uses an “existing web service endpoint” object to establish a web service communication.
With reference to scalability, virtual application patterns make this simple. Both enterprise applications contain the scalability policy, while the predefined shared services provide load-balancing features. Indeed, the load-balancing proxy service acts as a front end of all deployed web applications.
I hope this exercise helps you to take advantage of the IBM PureApplication System’s flexibility to implement real-life scenarios.
Editor’s Note:
Learn more about PureSystems at these events:
- February 5, 2013: Webcast: “Smarter Computing: What’s Next. Ready Now.”
- February 12, 2013: Webcast: “Speed Analytics and Simplify Cloud”
