Introduction to IBM SmartCloud
IBM's SmartCloud family and Pure Application systems provide a flexible cloud platform for Infrastructure-as-a-Service (IAAS) and Platform-as-a-Service (PAAS). You can use this platform to deploy compute resources (like virtual machines), and compute workloads (for example applications), and then to manage those deployed resources through an intuitive GUI.
The deployed resources can be placed on hardware owned by your organisation (that is your private cloud); on hardware hosted by IBM (making them part of your public cloud presence); or they can be deployed in an architecture which combines private cloud and public cloud deployments (making it a hybrid cloud).
There are effectively three tiers to the products that are available.
- At the entry level you have a choice between Tivoli Smart Cloud provisioning (which is a software product to help deploying workloads), and IBM Workload Deployer (IWD) which is a hardware appliance. IWD allows you to create, deploy, and manage private cloud workloads using your existing hardware and hypervisors like VMware ESX and PowerVM.
- PureApplication Systems offer a complete “private cloud in a box”. A Pure Application system rack is a hardware and software solution which contains management software storage and hypervisors, giving you all you need to create, deploy, and manage a cloud workload. The workloads and hardware infrastructure are administered under a single interface for simplicity and consistency.
- Smart Cloud Application Services provide access to a virtual IWD appliance hosted by IBM and backed by a public cloud infrastructure run by IBM. So that you can model and deploy your public cloud resources in the same way that you can deploy your private cloud resources.
IBM Workload Deployer, Pure Application Systems and IBM Smart Cloud Application services all share the same “pattern” concept – described below – giving you access to a continuum of deployment options. You can deploy a pattern on your existing hypervisor technology; buy dedicated Pure Application Systems to run your own private cloud; or outsource the hosting of your deployed workloads to IBM. Thus your are able to distribute your compute resources and skills across private, hybrid, and public clouds in whichever way is quickest, most efficient, and cost effective.
Virtual System Patterns and MQ Hypervisor Editions
A number of IAAS technologies - both proprietary and open-source - are available to speed up your deployment and configuration of new computing resources. In the majority of these technologies the essential unit of deployment is a virtual machine - typically from a catalogue containing template images which define the software and configuration of the machine.
In common with other IAAS solutions, IBM's SmartCloud offers the ability to deploy single virtual machines as Virtual Appliances. A virtual appliance typically starts life as a standard operating system image or an IBM hypervisor edition image (which contains an operating system plus middleware). This base image can be deployed as a VM and extended with additional software. Once the extra software has been installed and configured, the machine is recaptured back into the catalogue, and is available as a new template for virtual machine deployment.
IBM SmartCloud extends this single-machine deployment concept with the idea of Virtual System Patterns, making it possible to model more complex topologies of machines and to deploy them together. A large WebSphere Application Server cluster is a good example of a virtual system pattern. It typically contains a number of machines running HTTP servers to act as a web tier; a number of machines running WebSphere Application Server to host the application(s); and a deployment manager to manage the application server instances. Individual machines in the virtual system pattern can be tailored with script packages which are executed on the virtual machine instances. Script packages can be run when the instance is deployed or removed or on an add-hoc basis through the lifetime of the virtual machine, so they can be used to configure a machine when it starts, or to clean up a machine before it is destroyed.
To make it simple to use WebSphere MQ in conjunction with virtual system patterns we developed the WebSphere MQ Hypervisor Edition (HVE) which combines MQ and an operating system in a single virtual machine image. Two variants of the MQ HVE are available – one for Red Hat Enterprise Linux and one for AIX. These can be deployed to VMware or PowerVM cloud groups respectively.
The MQ Hypervisor Edition has a number of configurable options,which can be set in the virtual system pattern and locked, or left open for the user to specify when the MQ HVE is deployed. For example the user can specify the amount of memory and virtual CPUs that the instance should have, the name of a queue manager to be created in the machine, and the port that the queue manager should listen on. When the machine is deployed, a queue manager is automatically configured and set to automatically start and stop with the VM. For a full list of properties see the MQ Hypervisor part description in the MQ Infocenter.
Once a virtual system pattern has been deployed, then the status of the machines inside it can be viewed from the IWD / Pure Application system console, and maintenance can be applied to the machines from the catalogue of available FixPacks.
For example, the screenshot on the left below shows a pattern containing three virtual system parts which have been customized so that they implement a multi-instance queue manager pair with a shared disk. The screenshot on the right shows the deployed instance of the virtual system pattern and the status of the virtual machines it contains. In future blog posts I will show some examples of virtual system patterns and script packages which implement messaging systems.
To summarise, you can use the MQ Hypervisor Edition with IBM SmartCloud to automate and standardize the traditional approach to provisioning messaging systems. The benefits of this approach include :
- Standardization of software images reduces risk and uncertainty
- Automated provisioning reduces errors and speeds time to value
- Repeatable configuration across sets of machines is quicker and less error-prone
- Applying software maintenance is simpler and quicker using IWD/IPAS GUI or CLI
- Comprehensive history/audit is maintained
- License tracking is integrated
Virtual Application Patterns and the Messaging Extension for Web Application pattern type
The previous section describes how virtual system patterns provide a quick and easy way to provision topologies of virtual machines and to configure them with middleware and other software. The main focus for modelling virtual system patterns is the virtual machine.
IWD and Pure Application systems also offer another class of patterns called Virtual Application (vApp) Patterns where the emphasis is on modelling applications and their dependencies rather than systems. When you deploy a virtual application pattern to IWD or a Pure Application System then one or more virtual machines are created to host the application and all the associated middleware is installed and configured.
A range of application types are supported by different types of vApp patterns – for example there is a vApp pattern type that can deploy a stand-alone Java application, and another pattern type (the Web Application pattern type) for deploying a Java Enterprise application into a web or servlet container. The web application pattern type is most interesting from an WebSphere MQ perspective, because it is the web application pattern type that we have extended for connecting applications to MQ. The IWD and Pure Application System infrastructure is extensible so you can add your own vApp patterntypes if you find that there isn't already a patterntype that meets your requirements.
Creating or editing a virtual application pattern is simple. For instance, to model a JEE virtual application you start up the vApp pattern editor and effectively drop a WAR file or an EAR file containing the application onto the canvas. Once you've done this the pattern editor opens the WAR or EAR file and introspects the application's deployment descriptor to works out the list of resources that the application is dependent on. The pattern editor then prompts you to satisfy the application's dependencies by dragging and dropping the resources that the application needs and wiring them to the application.
The example in the pattern on the right shows a web application which has a dependency on a JMS Queue and a JMS ConnectionFactory. These dependencies have been expressed in the model as a Queue node and an "Existing Messaging Service" node. The Existing Messaging Service node represents a client connection to an MQ queue manager (so hostname, port, and channel details details are specified as properties of the node – not shown here). When the application is deployed, a virtual machine containing WebSphere Application Server is created to host the application, the application is deployed into the application server, and JNDI objects are created to represent the Queue and ConnectionFactory. When the application is started it can get the JNDI objects out of the JNDI repository and connect to the MQ Queue Manager.
Queues, Topics, and Existing Messaging Service nodes are all available as standard in the Web Application pattern type which is included with IWD and Pure Application Systems and they allow you to connect to a "existing" MQ queue manager which has been defined outside the pattern. If you would like an MQ queue manager to be created for you when you deploy an application pattern then you need to use the IBM Messaging Extension for Web Application Pattern Type. The messaging extension is a separate software product that you need to download from Passport Advantage and upload to your Pure Application System or IWD machine.
The IBM Messaging Extension adds a sample application pattern and template to the Web Application patterntype, and a new node (the Messaging Service) to the palette of the Web Application vApp pattern editior. The sample application is shown below.
When you deploy a pattern containing a Messaging Service node then a new VM is created containing WebSphere MQ, a queue manager is created, and the queues represented on the canvas are created. JNDI objects are then created for the ConnectionFactory, Queue, and Topic resources and they are linked into the application.
Virtual application patterns allow you to deploy an application without needing to worry about configuring the container that the application runs in or the middleware it uses. To help hide those configuration details, you can access the common operations that need to be performed on the application's middleware and application server via the pattern instance's management panels. Once the pattern has been deployed basic monitoring functions are also installed into the virtual machine so that MQ activity can be displayed graphically in the management panels.
The diagram below shows the machine topology which is created when the above application is deployed, along with the machine status display and MQ monitoring graphs.
This blog entry describes the two types of WebSphere MQ products that are available for IBM Cloud environments. The following table compares products to highlight the different use cases for each product:
MQ Hypervisor Edition
IBM Messaging Extension for Web App Patterns
- System admins
- MQ administrators
- MQ developers
- JEE app developers
- JEE app testers
- JEE app deployers
MQ knowledge required
- Web Application Pattern 2.0
- OS pattern
- Rapid provisioning of standardised middleware in virtual environments.
- Repeatable automated configuration;
- Simplified maintenance;
- Audit trail and License tracking.
- Traditional MQ admin model.
- Quick and simple modelling and rapid deployment of applications;
- Cloud automatically provisions and configures middleware pre-requisites;
- MQ adds rapid provisioning of black-box messaging server for JEE environments
- Little/No MQ knowledge required
Take a look at the following links if you'd like to know more about the products I've described: