IBM Workload Deployer

In the previous post I spoke about how a Virtual Application feature introduced in Workload Deployer v3.1 actually had benefits for Virtual System patterns as well.  In that case I was talking about the ability to deploy Virtual Applications running on AIX to PowerVM hypervisors and how this had hidden benefits for Virtual Systems as well.  This is a great example of how an enhancement to Virtual Applications can sometimes benefit Virtual Systems. However, this is not the only instance where the two pattern types intersect.

Several other new or enhanced features that are primarily for Virtual Applications are also being extended to benefit and improve Virtual Systems ... and vice-versa.  One such area of improvement involves Shared Service in v3.1.   These services were introduced in v3.0 specifically for the benefit of Virtual Applications.  However, several enhancements have extended these capabilities to Virtual Systems and likewise, some functionality that was previously only available to Virtual Systems has been extended to Virtual Applications in the form of Shared Services. 

As you may already know, Shared Services were first introduced in v3.0 and are just what the name implies; services that are deployed by a cloud administrator and used by multiple virtual application deployments. Let's start by taking a look at the shared services available under Cloud -> Shared Services in v3.1. You will notice that there are now more shared services listed than there were in v3.0.

 

Caching Service

The Caching Service was introduced in v3.0. Its primary purpose is to cache HTTP session data using a highly scalable and fast in-memory cache. This is the same core technology that is included in our WebSphere eXtreme Scale and DataPower XC10 Caching appliance.  To make use of this service all you need to do is deploy an instance of the Caching Service with the configuration parameters of your choice into a cloud group where you want to leverage that service.  As you create virtual application patterns you simply select the Enable session caching check-box when you add a scaling policy.  When this pattern is deployed it will be automatically configured to leverage the Caching Service for session persistence.  It's as simple as that.

The External Caching Service is one of the new additions for v3.1.  Let's say that you already have configured a caching solution for your enterprise using the DataPower XC10 appliance or a collective of appliances.  It would be nice if you could leverage this same solution instead of launching yet another caching solution within your private cloud.  Leveraging your existing solution would consolidate your caching needs and preserve the cloud resources for other purposes.  With this new external caching service you can do just that.  It provides you the ability to leverage an external caching solution for both your Virtual Application session persistence needs as well as your Virtual System and even non-cloud caching needs.  Just point an instance of this external caching service at your DataPower XC10 caching solution and all of the HTTP session persistence needed by your virtual applications in the same cloud group will make use of the external caching service.   You can also point multiple instances of the external caching service in multiple cloud groups to share the same XC10 appliance or collective. 

With the External Monitoring Application service you can deploy an External Application Monitoring service reference within a cloud group to point at a Tivoli Enterprise Monitoring Server installation outside of the cloud.  The TEMS server must be at version 6.2.2 Fix Pack 5 or later.  Once created, the Unix or Linux OS monitoring agents and the Workload monitoring agent that is provided for virtual application workloads will be automatically connected to the defined instance of the Tivoli server using the supplied primary and fail-over Tivoli Enterprise Management server, protocol, and port.  This is especially useful if you want to consolidate all of your monitoring to a common console.  As with the External Caching Solution, this enhancement also extends the integration capabilities of Virtual Application Patterns beyond the scope of your private cloud and allows you to consolidate and leverage investments you have already made.  

ELB Proxy Service

The Proxy Service was first introduced in v3.0 and renamed to the ELB Proxy Service in v3.1 for clarity.  As the name implies, its primary purpose is to provide routing and load balancing to multiple deployed web applications.  As with the caching service, you deploy this service based upon your requirements for load and availability within a cloud group.  When defining virtual application patterns to leverage this service you simply add a routing policy and define your virtual host name.  When the virtual application pattern instance is deployed to the cloud group the necessary configuration will performed to add the virtual host name and configure your application environment to use the ELB Proxy Service.  New in v3.1 is the capability to  scale the ELB Proxy Service itself to meet the changing demands of your application mix.