|
When IBM Workload Deployer V3.0 was introduced last year, one of the "hidden" values that it delivered was a new base image used for virtual application patterns. I say "hidden" because this image, while delivered primarily for use in virtual application patterns could also be leveraged for virtual system patterns. By now you may be scratching your head and wondering just what I'm talking about. Let me explain...
|
|
To begin with, it is helpful to understand a little bit about how virtual applications are deployed and how that differs from virtual system patterns. As you may already know, virtual system patterns are built from IBM Hypervisor Edition images to launch the virtual machines for your deployment. The IBM Hypervisor Edition images include the Operating System and middleware components together in the image. Therefore, building a virtual system pattern basically starts with a fairly complete image and activates the parts in that image necessary to fulfill the particular role this virtual machine will pay in a virtual system pattern. Virtual application patterns take a somewhat different approach. The starting point for a virtual application pattern is the base image which only includes the base Operating System. Workload Deployer launches a virtual machine with just this base image and then the appliance manages installation, configuration, and integration of software and applications to complete the role this virtual machine must fulfill for this virtual application pattern. At a high level you could consider virtual system patterns a template approach and virtual application patterns more of a build it as you need it approach.
|
|
So just what is the "hidden" value of these base images provided for virtual application patterns and how can that be used for virtual system patterns? The hidden value is that the base images used for virtual application patterns are delivered with IBM Workload Deployer in the image catalog and can be used for building virtual system patterns. If you already have an appliance you can take a look ... you will see the base images there under Catalog > Virtual Images right along side more familiar images like the IBM Hypervisor Edition images for WebSphere Application Server. For x86 systems this image is appropriately named "IBM Workload Deployer Image for x86 Systems". These images each include a base part called "Core OS" that can be included in a virtual system pattern.
|
So now you may be saying to yourself - well that's all great news but what is new about this? The new thing is that in IBM Workload Deployer V3.1 a significant new feature was added - the ability to deploy virtual application images to PowerVM environments using AIX. To enable that feature a base image was created for AIX, the "IBM OS Image for AIX Systems." As with the x86 image, this new image is now also available for your use in the image catalog. You can now employ that default AIX image for your own needs in virtual systems patterns - creating a very nice extension mechanism for PowerVM and AIX users.
|
|
This new base image contains the IBM AIX 6100-05 operating system and the Core OS part that you can include in virtual system patterns. As with the x86 base image delivered earlier, there are no restrictions on how you use or customize this image. To make it suitable for your purposes you can employ the IBM Workload Deployer extend and capture capability to install additional software content into the image. You can also enhance this image using the IBM Image Construction and Composition Tool (ICCT) that is now included with IBM Workload Deployer v3.1. When you include this part in a virtual system pattern you can also associate any configuration scripts that you may need, just as you would with any other part. Just as with the x86 part - this provides substantial value and a significant convenience for AIX users.
|
|
I hope this clues you in on the "hidden" benefits of a substantial new feature included in IBM Workload Deployer V3.1. We have often been asked to provide base OS images to build upon as starting from scratch is sometimes difficult when you need to create your own custom image. Now, with IBM Workload Deployer v3.1, you have your choice of two default images in addition to the many IBM Hypervisor Edition images delivered as well as a robust set of new features in IBM Workload Deployer V3.1!
|
|
-- Joe Bohn
|
|
|
No doubt that you have heard the buzz about cloud computing. If you have been tuned into this blog or other similar blogs you have no doubt also heard the talk of saving money, saving time, and increased agility using patterns of expertise. There are substantial benefits to be gained and increased efficiency when using cloud computing and especially when using patterns of expertise in the cloud. Perhaps all of this talk has piqued your interest but then you get back to you day job, look at the applications your company uses, and have no idea where to begin.
|
|
Well, there is help available in a great series of articles to help you analyze, evaluate and move forward with onboarding your applications into a private cloud solution. This particular series of articles was written specifically for onboarding your applications into IBM PureApplication System. However, if you have been following things then you also know that the core pattern technology included in PureApplication System and other IBM offerings such as IBM SmartCloud Application Workload Services got their start right here with Workload Deployer. That means that these articles are directly applicable for IBM Workload Deployer if you choose this solution where you build your own private cloud. One caveat to keep in mind - the function that is discussed in some of the articles around AMC (Advanced Middleware Configuration) that is included in PureApplication System is not included in Workload Deployer. However this same function is provided in Rational Automation Framework and when combined with IBM Workload Deployer you have the same capabilities.
|
|
So now is the time to take the next step! Check out the onboarding articles and see just how easy it can be to move your current applications into the cloud. If you don't already have IBM Workload Deployer you can also take advantage of these free trial offers to get first-hand experience with just how easy it is to work with patterns. In no time at all you will be able to reap the benefits of cloud computing and patterns of expertise for your business.
|
|
-- Joe Bohn @jabber63
|
|
IBM Workload Deployer (IWD) is a hardware appliance that lets you dispense repeatable patterns of middleware onto a private cloud. IWD has two main deployment models, virtual applications and virtual systems. In a virtual system, IBM-supplied image parts from the IWD catalog can be customised at deploy-time via script packages. If you'd like to migrate your application to run as a virtual system on IWD, development of these script packages will likely be your key deliverable. The most common pairing of middleware that I encounter in support of solution development is an application server (JEE) and a database. In IWD, this requirement is fulfilled out of the box by WebSphere Application Server and DB2. Against that backdrop, a script package is a bundle of files that you create to perform a particular function with an image part. An example might be a script package for the DB2 image part that performs your initial data load, or a script package for the WebSphere Application Server image part that creates a cluster, installs your JEE application and then configures JDBC. Essentially, a script package contains an main executable (often a shell script) that will be executed (usually as root, but you can always su) by IWD at a specified time (system creation, system deletion or manually triggered). In addition to the main executable, other scripts and files can be included and these are placed in a location of your choosing at virtual system creation. You can create a script package either with the GUI, or by manually packaging your files up into a .zip file (with a JSON descriptor) that can then be imported into the IWD catalog. Script packages can have defined input variables (known as environment variables) and these environment variables can either be hard-coded at pattern creation time, filled in at pattern deployment time or dynamically filled using special IWD variables for values that cannot be known until deploy time. Here's a simple virtual system pattern comprising WAS, DB2 and some of the sample script packages:  One of the things I found initially difficult to get my head around is that if I'm going to create a DB2 Data Source connecting to my DB2 Enterprise instance in WAS, I need to know the hostname/IP of the DB2 box. As IWD is in charge of deciding where to place my desired middleware images, this neatly illustrates an example of a value that cannot be known until deploy time. Taking a look at the properties of the "Create DB2 Data Source..." script package gives us a clue as to how this is done:  As you can see, the script package makes use of the special properties variable syntax to discover the hostname and domain of the running DB2 instance that has been dynamically created by IWD. As described in the InfoCenter, image parts have a number of variables including: - hostname
- domain
- ipaddr
- netmask
- gateway
- pri_dns
- sec_dns
- language
- country
- encoding
To use these property variables, you also need to know the part name that you are targeting. Part names for images in a virtual system can be discovered either on the pattern overview page, or in the pattern editor by clicking the table icon as shown below:  To help you get started, here's a table of my most used parts: | Part | Name | | Deployment manager | DMGRPart | | Custom nodes | CustomNodePart | | Standalone server | StandalonePart | | IBM HTTP server | IHSPart | | On demand routers | ODRPart | | DB2 Enterprise | DB2_ESE | | DB2 Enterprise HADR Primary | DB2_ESE_Primary | | DB2 Enterprise HADR Standby | DB2_ESE_Secondary | | DB2 Express | DB2_EXP | | DB2 Express HADR Primary | DB2_EXP_Primary | | DB2 Express HADR Secondary | DB2_EXP_Standby | | WebSphere MQ - Basic | BasicPart | | WebSphere MQ - Advanced | AdvancedPart |
So, to get the hostname of a deployed WAS standalone server image part, you would use ${StandalonePart.hostname}, and to get the language of a deployed DB2 Enterprise image part, you would use ${DB2_EXP.language}. The variables are very useful and must be passed into your script packages as input variables as shown above. Note that if you have more than one of a given part on your canvas, you can address the individual instances by adding an underscore at the end of the part name. eg. DB2_EXP_ for instance one. DB2_EXP_1 for 2 etc. In addition to those variables, each image part has a number of useful script package environment variables for you to use. These variables are placed into a file ( /etc/virtualimage.properties) which is automatically made available to the main executable of your script package. These script package environment variables come in two main categories. those that control virtual image lifecycle (reset the image, install a service, start a service etc) and those that relate to the middleware (Deployment Manager hostname, cell name etc). If the main executable in your script package is a shell script, you can use these provided variables via the ${variablename} syntax. The variables that are available vary from image to image, so here's some of the ones I use most often: You'll notice in the WAS variables that in addition to things you would expect like CELL_NAME, PROFILE_NAME, DMGR_HOST and WAS_PROFILE_ROOT you are also told the PROFILE_TYPE, which you may find useful for developing a multi-purpose script that can handle both standalone and clustered WAS configurations.
One other point worth noting is that for the current DB2 9.7.3.1 image, the DB2 installation directory is /opt/ibm/db2/V9.7. To start developing your own script packages, I recommend creating a stubbed version of the virtualimage.properties that contains any input variables that you expect to be passed into your script package at deploy time and also any script package environment variables that you need to use. If you create the stub so that the paths and configuration details match your environment, this should enable you to develop script packages against your existing middleware installations and without access to IWD. Also, bear in mind that the maximum size for a script package when zipped is 512mb. If you need to load more data than that you could consider using a number of script packages to transfer the data into the virtual machine or by extending an existing image to include your files using the extend and capture function.
|
|
Everybody likes having choices. This is true whether you are talking about lunch or deploying to a private cloud. When IBM Workload Deployer v3.0 was first introduced it included a pattern type for our Database-as-a-Service offering. The DBaaS PatternType v1 provided substantial value in an easy to use form factor to get a database up and running quickly and then provided the necessary tools to manage that environment. Pretty impressive for a first release! But the story doesn't end there. IBM Workload Deployer v3.1 brings an updated version of this pattern type that builds upon this foundation and adds even more capabilities and more choices.
|
|
Some of you may not be familiar with the Workload Deployer Database-as-a-Service offering so let me give you a brief introduction. Database-as-a-Service patterns allow you to define and deploy database applications into your private cloud environment with speed and consistency. These offerings also provide integrated management and monitoring capabilities. The Database-as-a-Service capability can be used in conjunction with a web application pattern (Patterns -> Virtual Applications, IBM Web Application Pattern) by including a database component in a pattern connected the web application components to use it. In this case the web application and database are deployed and managed as a unified solution with a common life-cycle as shown in the pattern below.
|
Database patterns can also be created and deployed as standalone entities (Patterns -> Database Patterns) that have their own life-cycle, independent of the virtual web application(s) that use the database. What's more, you can leverage these stand-alone databases from applications both inside and outside your private cloud.
|
|
Whether you use a stand-alone database pattern or one that is part of a web application pattern, the attributes and capabilities of the database are consistent.
|
|
So what is new in this release? For starters, the DBaaS PatternType has been renamed and the capabilities expanded. For Workload Deployer v3.1 the pattern is delivered as the IBM Database Patterns v1.1 and includes several elements to provide predefined configurations: the IBM Transaction Database Pattern and the IBM Data Mart Pattern.
|
|
Before we take a closer look at the new features I just want to alert you to one thing. Before you can leverage any of these new features you first need to accept the licenses and configure the plugins for the database pattern types. So look at the link and follow the directions if you would like to along and you aren't seeing the same options in your IBM Workload Deployer V3.1 system.
|
|
Using the screen shot above as a reference, let's take a look at what you can specify when creating a database pattern. You start with a name for the pattern and an optional pattern description. You also specify the maximum user data space size and an optional schema file. These are pretty basic and were all available with in the previous release. Another really nice feature that has also been available since the first release is the ability to specify a compatibility mode for DB2 and Oracle (a nice feature if you are looking to move content from existing databases).
|
|
Some of the new enhancements appear in the middle of the view; the purpose and source. The purpose specifies if this database is to be used for production or non-production (test and development). Your selection will optimize license management for deployed instances of this pattern.
|
The source field lets you specify a database configuration to be used to provision this database. You can choose from two different provisioning approaches; applying a workload standard or cloning from a database image. When choosing apply a workload standard you select between two predefined, optimized database configurations. These configurations will run a set of scripts to tune the operating system and instance configuration for the database. The departmental transactional standard is optimized for online transaction processing applications while the data mart standard is optimized for data mining purposes and is therefore more suitable for reporting applications. If those aren't exactly what you want but you have an existing database you can use the clone from a database image approach by selecting an existing database image backup as a model for the new database pattern. When using the clone method metadata from the backup is retrieved and a DB2 restore command is used to set the same configuration for the new database instance. Reference the cloning from a database image topic in the IBM Database Patterns information center for more details.
|
|
Once the pattern has been created you can deploy the pattern to a target cloud group or an environment profile (another new feature for database deployments in IBM Workload Deployer V3.1).
|
|
I hope you can see the value that has been added with the source configuration choices and the ability to clone an existing configuration. They are certainly substantial new features of the Database-as-a-Service solution in Workload Deployer V3.1. However, there are a number of other significant enhancements that I would just like to mention as well. In other posts we've discussed the new ability to deploy virtual applications to run on AIX with a PowerVM hypervisor. As you might expect this same ability is also available to deploy database patterns to run on AIX systems leveraging PowerVM. Management capabilities have also been significantly enhanced with the ability to configure automated database backups using the IBM Tivoli Storage Manager. These features and many other aspect of the Database-as-a-Service model are detailed in the IBM Database Patterns information center and the IBM Workload Deployer information center. My goal here has not been to replicate our product documentation - it is rather my goal to provide a few highlights and provide pointers to help you get started. I hope it has been useful.
|
|
You can be sure that we will continue enhancing and improving our Database-as-a-Service offering in IBM Workload Deployer. Please provide your feedback so that we can make it even better.
|
|
-- Joe Bohn
|
|
|
When many people think of cloud computing they immediately think of virtualization and virtual machines in particular. This is completely natural and not at all surprising. After all, one of the core underlying technologies necessary for cloud computing is virtualization. However, it is important not to confuse one element of cloud computing with the entire thing - and this can sometimes happen. Many people have begun to leverage virtual machines in their on premise environment and sometimes begin to call this their private cloud. While virtualization is a substantial step forward and help gets you started down the necessary path of standardization and automation that is essential in a cloud - it is not in and of itself "a cloud".
|
The National Institute of Standards and Technology has published its definition of cloud computing. This is a very complete and yet concise definition that includes not only the essential characteristics of a cloud solution but also the service models (IaaS, PaaS, SaaS) and deployment models (public, private, hybrid, community). It is a great way to get a perspective on cloud and can be useful when considering the solutions of various vendors.
|
Let me summarize the essential elements of cloud from this definition here:
- on-demand, self-service
- broad network access
- resource pooling
- rapid elasticity
- measured service
|
So, this is interesting. Not only is this much more than just virtualization - but virtualization isn't even mentioned in the list explicitly. Not to worry - virtualization is of course important and is included under the resource pooling topic. I would assert that virtualization is also necessary to facilitate the type of on-demand, self-service, elastically scaling resources that are leveraged in a cloud. What is crystal clear from this definition is that there is a lot more to a cloud solution than just virtual images and some hypervisor infrastructure upon which to run them. Somebody must provide the necessary on-demand/self-service capabilities, the network access to these services, the management of the resource pools, enabling true elasticity for running systems, measuring services and so forth. IBM Workload Deployer provides just such capabilities for the on-premise cloud allowing you to efficiently deploy patterns built for virtual systems and virtual applications with deep knowledge of the middleware that is being provisioned to optimize these solutions. Furthermore, Workload Deployer provides the complete lifecycle management from pattern creation, to deployment and provisioning, applying maintenance, resource and license management in the on-premise cloud, elastic scalability, and eventually returning resources to the on-premise cloud to be reused. Workload Deployer is a complete solution for not only server virtualization but of course for cloud computing.
|
|
However, virtualization doesn't have to stop with just virtual machines. It is a general principle that can be applied to more than just servers. At its core, virtualization is really about providing a level of abstraction between some real resources and the consumers of those resources. This is a natural fit when we think of server virtualization and virtual machines. However, there are also substantial benefits to be gained by adopting a similar abstraction between the middleware and the applications themselves - sometimes referred to as application virtualization.
|
|
|
By application virtualization I mean providing the capabilities to abstract the application from the underlying infrastructure such that it can be elastic, participate in health management policies, and provide agility across the pool of application infrastructure resources. This type of application virtualization is built into our Virtual Application pattern (hence the name) in Workload Deployer and surfaced in solutions via policies (such as scaling and routing), and high availability functions built into the Web Application pattern type. For Virtual Applications these features are fully integrated and optimized functions as are all elements of Virtual Applications. However, similar features have also been available for WebSphere Application Deployments in Virtual System patterns with a special extension.
|
|
|
WebSphere Virtual Enterprise provides application virtualization for traditional WebSphere ND solutions and this same feature is delivered for Virtual System pattern deployments of WebSphere Application Server by use of the Intelligent Management Pack. Leveraging the capabilities of Workload Deployer with Virtual Systems lets you gain the benefits of server virtualization and to reduce hardware, provide rapid and consistent deployment of entire systems, dynamically adjust resource consumption, and much more. Leveraging the capabilities of the Intelligent Management Pack provides the ability to manage service level agreements with elastic scaling and health management, lower operational costs, and provide for improved application management. These two solutions together provide a powerful combination to improve the management and resiliency of your enterprise applications.
|
|
If you would like to learn more about application virtualization using the Intelligent Management Pack in conjunction with Virtual System Patterns in IWD then please join Keith Smith and myself tomorrow for a webcast on this very topic. Keith is the lead architect on our WebSphere Virtual Enterprise and Intelligent Management Pack products and brings a wealth of experience in this space. So don't miss this opportunity - register here.
|
|
-- Joe Bohn
|
|
In my last post I gave you my impressions of Impact 2012 .... including my assessment that IBM PureApplication System was the star of the show. I also pointed out how PureAS leverages the capabilities of IBM Workload Deployer and provided references to several areas where you can get more information on IBM PureApplication System and some hands-on experience with patterns.
|
The purpose of this post is to point you to another post - an insightful comparison of IBM PureApplication System and IBM Workload Deployer offered by Dustin Amrhein in the A view from the clouds: Cloud computing for developers blog. This is a quick read from Dustin - giving his report from Impact as well as a nice overview of the similarities and differences between IBM PureApplication System and IBM Workload Deployer to assist you if you are considering either offering. ... read Dustin's post ...
|
|
|
|
|
Customers are always impressed when they learn about the simplicity, resiliency, and rapid time to value they can received from virtual applications. However, they are usually a little mystified at how virtual applications really work. After all - they have become quite accustomed to doing things the "traditional way" where they control every aspect of their applications manually. Virtual Applications represent an entirely new way of thinking. Sure, the benefits are enormous but can you really trust them? How is it doing all of this anyway?
|
|
What seems like "magic" is really a sophisticated and coordinated set of activities driven and coordinated by IBM Workload Deployer while leveraging the expertise built into the pattern type. Yes, you can trust it because experts have worked to build the system and created to it react and respond much faster than you can. When moving away from manual processes to automated processes it is always nice to get a sense of what is really happening. I think it is just human nature. We can't really place our trust in something until we have first hand experience or understand what it is really doing ... I guess it is the critic inside each one of us. Even after you've experienced the value it is still reassuring to see and understand the "how".
|
|
It is the "how does it do that?" type of question that I attempted to answer for virtual applications in a blog post I wrote on the Expert Integrated Systems blog recently. It attempts to pull the curtain aside and describe what is actually happening to support a virtual application pattern. As with my previous post - this was written for IBM PureApplication Systems but the concepts are 100% applicable to IBM Workload Deployer. I think you will find it interesting ... Continue reading ...
|
|
-- Joe Bohn @jabber63
|
|
|
Applications - just like humans, animals, plants, and many other things - have a life cycle. They are conceived, given birth, grow, do foolish things in youth, hopefully improve over time, have problems that need to be fixed, don't always age well .... and eventually they will die and release their assets to the next generation. Sounds kind of familiar, doesn't it?
|
|
One of the many benefits of virtual application patterns in IBM Workload Deployer and related IBM offerings is support for the complete life cycle of the application.
You can manage the complete life cycle of virtual applications from a single interface that is fully integrated and well thought out - not just a series of links from one product UI to a
different product UI. This eliminates the complexity of having to work with different interfaces, paradigms, metaphors, controls, labels, names, authorization, and so on - that is often the norm in many customer environments today. I think the benefits of this integration are obvious - eliminating confusion, configuration, miscommunication, interpretation, and mapping errors. Providing a truly complete solution also facilitates a common knowledge base and encourages cooperation and collaboration among teams. You can share patterns, providing consistent governance for a solution, guarantee consistency in deployments, and build upon the expertise provided by others. Having an integrated solution for design, development, deployment, configuration changes, monitoring, and problem determination ensures that time is not wasted and valuable information is not lost.
|
|
Of course, this complete life cycle management isn't the only benefit of virtual application patterns - but it is significant. I wrote a blog post about this topic from the perspective of IBM PureApplication Systems on the Expert Integrated Systems blog. The concepts around this topic for virtual applications are 100% applicable to IBM Workload Deployer. Continue reading ...
|
|
-- Joe Bohn @jabber63
|
|
 IBM Impact 2012 was just last week with a theme of "Change the Game" ... and I'm still reveling in all of the excitement and energy that goes into conferences such as this. I was fortunate to get a last minute spot to attend the conference and help out at the Solution Center where I had the chance to speak to a lot of customers and other IBMers interested in cloud computing. Among the many things that stood out - there is certainly a lot of interest in cloud computing and patterns of expertise - it also seems that folks are ready to get some first hand experience with these patterns. There's plenty of opportunity for that! |
|
IBM Workload Deployer was specifically featured in the Solutions Center and referenced in many sessions. However, this paled in comparison to the visibility that IWD received as being one of the key components in IBM PureApplication System which was clearly the star of the show (it also helped that we had several real systems on hand to draw the crowds and drool over the raw power present in these systems). Of course IBM PureApplication System wasn't the only shinny new object. There was also a large emphasis on Mobile and BigData .... but it seemed to me that the biggest buzz was around IBM PureApplication System and in particular the "patterns of expertise" capabilities which come directly from our very own IBM Workload Deployer.
|
I hope you had a chance to attend the conference (perhaps I may have even spoken with you at the solutions center). However, even if you couldn't make it to the conference - there is still a wealth of information available to you. Many of the sessions were recorded so you can still watch the general sessions, detailed interviews from the social playground, highlights of the unconference, and main tent sessions. I'm sure that you will also hear a lot of news in the coming weeks as the impact of what was announced and demonstrated makes it's way through the social channels. If you had a conference pass you can also download many of the presentation materials. Also, don't forget to consider attending one of the IBM Impact2012 comes to you events to be held in various locations in the coming months.
|
Several announcements that came out during the conference are of particular interest to our community.. First, the IBM Virtual Pattern Kit for Developers was announced. This includes an image that you can download and then leverage to gain experience building patterns. I will warn you that the download is not for a slow bandwidth connection - one of the three images is 16GB (mine is still downloading). However, once you finally get the image you can launch a VM running a version of the IWD technology and leverage your own ESX install to work with a private cloud for development purposes.
|
Another announcement and opportunity to gain experience working with patterns (that doesn't involve any downloads) is a 90-day free trial of these same pattern capabilities in our public cloud offering - IBM SmartCloud Application Services. This is a great offer and a really quick way to get some hands on experience with both the value of pattern based deployments and our public cloud offering.
|
I would encourage you to take advantage of these offers. Both are great ways to get some first-hand experience with patterns if you don't happen to have your very own IBM Workload Deployer. As they say "seeing is believing" and it really drills it home the first time you deploy a system and have it up and running within minutes. Another way to get some experience on an actual IBM Workload Deployer appliance is to contact your IBM client representative for a Proof of Technology (POT) or Proof of Concept (POC) ... and don't forget to get a free business value assessment so you can convince your boss how much money you can save the company!
|
IBM Workload Deployer technology is now available in three places and you can expect to see it in even more places very soon. This is just too powerful of a technology to limit it to just one product! Whether you are considering IBM PureApplication System, IBM Workload Deployer, or IBM SmartCloud Application Services the value that pattern based deployments bring is consistent and portable.
|
If you need a little more convincing before investing the time to get some first hand experience then take a look at our youtube videos for IBM Workload Deployer and IBM PureApplication System.
|
|
Your feedback is always welcome!
|
|
-- Joe Bohn @jabber63
|
|
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.
|
|
In addition to the familiar Caching Service and ELB Proxy Service (formerly Proxy Service) there are now additional entries for an External Caching Service and an External Application Monitoring Service. For simplicity let's just start from the top and go down the list, discussing the function of each service, what is new/improved for v3.1 with regard to virtual applications, and when applicable how this service can be used by virtual systems.
|
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.
|
|
Several new features were introduced in v3.1 for the Caching Service. First, the Caching Service can now be launched with parameters to define the behavior for automatic scaling to meet the ever changing demands of your applications. Once set, Workload Deployer will manage this service to ensure sufficient capacity based upon your requirements, adding or removing containers. Second, and this is significant for Virtual System patterns, the caching service has been enhanced to add new operations to support listing, creating, and deleting various types of object grids. You can then use the WebSphere eXtreme Scale ObjectGrid APIs to persist and manage content in the grid from your application code from Virtual System deployments. This saves you the trouble of creating and configuring your own caching service for these purposes outside of the cloud and permits sharing of the service you have already configured - a nice savings.
|
Caching Service (External)
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.
|
Monitoring Application (External)
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.
|
|
One other item that I should point out (and to which I've already alluded) is that you can now deploy multiple instances of each of the shared services - one per cloud group. Shared services can also now be deployed using environment profiles. This was not previously the case in v3.0 where each service was a singleton for the appliance. Allowing multiple instances of shared services gives you the flexibility to configure the sharing of your services as necessary for your particular environment.
|
|
I hope this post has provided a useful overview of the value of shared services and the new capabilities introduced in v3.1. I also hope that you can see how these services make it easier to implement your solutions for both virtual applications and virtual systems within a private cloud environment and shed a little light on how we are continuing to improve IBM Workload Deployer. As always, these improvements are driven by the feedback we receive from you so please let us know what you think!
|
|
-- Joe Bohn
|
|
25
X
