Cloud technical consultant
IBM Innovation Centre Hursley
The purpose of the WebSphere CloudBurst Appliance (WCA) is to allow application configurations -- which are customizable to the virtual infrastructure environments required for particular projects -- to be deployed and maintained, so as to be ready to run distributed applications on the project's available cloud. The environments typically contain all the elements of WebSphere Application Server Hypervisor Edition: Operating System, HTTP Server, WAS ND application server nodes and intelligent management components for dynamic clusters.
Because the necessary components, aside from the project application code itself, are all contained within a predefined OVF package, the question arises: How do we keep the application configurations up to date with the current recommended fix level?
In this note, I illustrate in detail some typical practical steps to maintain virtual systems under WebSphere CloudBurst Appliance 2.0. I shall show some convenient steps to take the appliance from an earlier to a current fixpack level and apply the upgrade.
I shall assume that there is a single networked Linux workstation PC available on the same network as the WCA to be maintained. This is all that is needed to administer and make the upgrades available.
In this situation, the outline steps are:
Step 1) Download the WebSphere Application Server Hypervisor Edition (WAS HV) recommended fixpack to your local Linux PC.
Step 2) Keeping each OVA file downloaded on the local Linux PC, use these to add a new virtual image into the WCA's catalog through secure copy (scp) to access the file from the appliance.
Step 3) At the appliance, select each out of date virtual system and upgrade to the fixpack level provided by the new virtual image.
Step 1 - Obtaining the WAS HV fixpack
The latest fixpacks may be obtained through the Software Access Catalog available to IBM Business Partners who have obtained the IBM Value Package or Software Access Option. Details are at https://www.ibm.com/partnerworld/wps/servlet/ContentHandler/isv/sac.
A current snapshot of available WAS HV fixpacks for a variety of deployable Operating Systems is shown in Figure 1. A convenient search term to locate the packages which may be used with WCA 2.0 is 'WebSphere Application Server Hypervisor Edition OVA'.
At the time of writing, an applicable download is shown in Figure 2. In this example we are using the 32-bit WAS HV option for SLES 5.4 to upgrade our virtual image catalog on the WCA. The OVF package is available in the form of a single archive of the directory structure based on OVF. This single archive is know as an OVA file.
The download shown in Figure 2 provides the file named WAS_HV_V22.214.171.124_SLES_X86.ova. Its size is 7.9 GB (or to be exact 8,490,311,680 bytes).
For this exercise, I chose to use a Linux PC, known on the network as linux-local. I prepared a directory, as a subdirectory of the root filesytem, to hold each OVA file at the path /WCA-Updates as shown at Figure 3 (before downloading) and at Figure 4 with some of the available fixpack 17 packages. firefox is a suitable browser for accessing the WCA administrative user interface, as is also Internet Explorer on Windows.
OVF is a standardized representation of virtual machine metadata. Its purpose is to allow virtual machine hypervisor vendors to be able to describe and create virtual machines across different platforms in an agreed, open format. See http://www.dmtf.org/standards/ovf for a definition of OVF and OVA.
Step 2 - Adding the OVA files to WCA's catalog
Figure 5 shows a WCA at release level 126.96.36.199-26833 at a network address we shall refer to as my-wca-address. I have logged into the appliance as the Administrator. At this appliance, I selected Catalog -> Virtual Images, in the pulldown as shown in Figure 5.
Figure 6 illustrates that the existing level of WAS HV in the catalog is 188.8.131.52. So the upgrade to 184.108.40.206 is likely to be opportune.
In order to make the OVA file available for adding to the WCA's catalog, WCA 2.0 following the OVF specification provides for three main options:
i) To allow the OVA file to be accessed over the network from an HTTP Server using unsecured http
ii) To allow the OVA file to be accessed over the network from an HTTP Server secured using SSL via https
iii) To allow the OVA file to be accessed using secure file copy (the scp protocol).
Notice that other options, especially to locate the ova file at an NFS mount point are not supported by the specification at the time of writing and are not accepted as valid URLs. In my scenario, option (iii) using scp to serve OVA files from my local Linux workstation is perfectly convenient. I decided that this was my preferred means of accomplishing the download to the WCA.
Preconditions of the scp transfer are:
i) the hostname is resolvable using DNS supplied by the local network.
ii) the username and password of a scp authorized account (such as root by default) is known.
iii) the WCA appliance is at 2.0 or greater.
To commence the update, using my /WCA-Updates/WAS_HV_V220.127.116.11_SLES_X86.ova saved download package, I selected the green + sign, alongside the title Virtual Images in the top left of the user interface. I provided the scp path linux-local:/WCA-Updates/WAS_HV_V18.104.22.168_SLES_X86.ova as the location for adding a new virtual image as shown in Figure 7. The user name and password must be for an account which has the right to run scp. Having completed these fields, I simply pressed OK so as to initiate the process of importing the OVA as a new virtual image.
N.B. - Remember to check that linux-local (substitute your workstation hostname) is DNS resolvable and that you have the correct administrative credentials for SCP. An error with either of these conditions results in a red warning triangle and the message 'Invalid URL provided for OVA'.
In my scenario, the process began to create a new virtual image 1309103352782. The image download continues as shown in Figure 8.
Using my WCA over the network to linux-local the download took approximately 2 hours to complete. During this period, the task flow is as shown in Figure 9. Upon completion of the import, the result is shown in Figure 10.
In order to make the new image available, it is necessary first to accept the licences provided with the image. I accepted all licences by clicking each of the entries (for Novell, for Vmware, for WAS HV and for WAS HV intelligent management in this scenario) in Figure 11 then clicking the acceptance button. Once all constituent licences had been accepted, as in Figure 12, I finally clicked the OK button.
The effect of all the preceding steps is to create a new visual image in the catalog, whose description is WebSphere Application Server 22.214.171.124 and whose details are for Novell SuSE Linux Enterprise Server 11. This is as shown in Figure 13.
The new image is now available in the catalog, with accepted licences,for use in new patterns or apply to existing ones.
Step 3 – Effecting the virtual system upgrade
Where there is a virtual system running the out of date WAS HV level it may be updated from the WCA console. Let us take the simple example of a Single Server pattern deployment available under the Virtual Servers tab, as shown in Figure 14.
To update to the current WAS HV fixpack I clicked the wrench symbol on the top right of the WebSphereSingleServerDeployment virtual server page, next to the red cross. The result of this action is to provide a set of options which include 'Move to service level'. The pulldown for this option includes the newly created WebSphere Application Server 126.96.36.199 option, as shown in Figure 15.
When the virtual server gets upgraded to the later service level, a VMware snapshot of the earlier version gets taken. Under 'Product administrator user name and password', I supplied the root user and password, before clicking the OK button to apply the change.
Figure 16 and Figure 17 show the progress of selecting the update option to apply the move to the later fixpack level.
A Linux workstation on the same network as WebSphere CloudBurst Appliance 2.0 is all that is needed to configure new virtual images which represent updated fix levels for providing new patterns or upgrading existing virtual servers. The requirement is that the workstation is capable of running Secure Copy Protocol (scp). On this assumption no additional tooling for the Linux PC is needed.
This note has documented all the steps needed to get this function to work correctly.