what's new in websphere cloudburst 1.1?

8/14/2019 What's new in WebSphere CloudBurst 1.1?

1/31

Whats new inWebSphere CloudBurst

1.1?

Authors:

Brian Stelzer, IBM ([email protected])

Dustin Amrhein, IBM ([email protected])


2/31

AbstractThe IBM WebSphere CloudBurst Appliance is a revolutionary offering that allows you to

create, manage, and deploy WebSphere Application Server environments in a private

cloud. The first release of this product, version 1.0, introduced capabilities in each phase

of this application environment lifecycle. WebSphere CloudBurst version 1.1 expands on

the initial set of functionality offered by the appliance to introduce broader platformsupport, more customization options, new resource sharing capabilities, and enhanced

security controls. In this article, well take a look at the major updates in WebSphereCloudBurst 1.1 and what those updates mean to you.

WebSphere CloudBurst 1.1If you are a user or are otherwise familiar with WebSphere CloudBurst 1.0, you know that

it is an appliance offering that is focused on providing you with the capability to create,deploy, and manage application environments in a private cloud. The appliance is

preloaded with a new version of the WebSphere Application Server called WebSphere

Application Server Hypervisor Edition. You use this virtual image packaging of theWebSphere Application Server to create complete representations of your WebSphere

application environment. These representations are called WebSphere CloudBurst patterns

and they include your WebSphere Application Server topology as well as customconfiguration such as user applications. Once you have created your patterns, you can use

the appliance to deploy them into the private cloud you have defined, maintain the running

WebSphere Application Server environments created from deployment, and then retire

those environments when necessary.

The newest version of WebSphere CloudBurst, version 1.1, introduces several new

capabilities that enhance WebSphere Cloudbursts capabilities within thecreate/deploy/manage lifecycle. In particular, the new capabilities we will take a look at in

this article include:

1) Support for the PowerVM platform2) New DB2 Enterprise 9.7 virtual image3) Integration with VMware vCenter (or VMware Virtual Center)4) Enhanced customization and management capabilities for application

environments

5) New resource sharing techniques6) New security controls7) New LDAP integration capabilities

Lets drill down into each of these areas to understand the new features you will find in

WebSphere CloudBurst 1.1.


3/31

PowerVM Platform SupportA core part of WebSphere CloudBurst is the WebSphere Application Server Hypervisor

Edition. This is a virtual image that contains an operating system, WebSphere Application

Server binaries, WebSphere Application Server profiles, and IBM HTTP Server.

Figure 1. WebSphere Application Server Hypervisor Edition

wca-washv.jpg

All of the software in the image is pre-installed, pre-configured, and the virtual image isready to run in a virtualized environment.

Initially in WebSphere CloudBurst 1.0, the WebSphere Application Server Hypervisor

Edition virtual images were packaged solely for the VMware ESX hypervisor platform. In

addition to these VMware images that you can continue to use, WebSphere CloudBurst1.1 introduces a new version of the WebSphere Application Server Hypervisor Edition

that is packaged for the IBM PowerVM hypervisor platform. This new version, which is


4/31

uploaded into the WebSphere CloudBurst catalog alongside the other WebSphereApplication Server Hypervisor Edition versions, of the virtual image includes an AIX

operating system, in place of the SUSE Linux operating system packaged with the

VMware-ready images. Various versions of the image will be provided (as with theVMware images), including WebSphere Application Server version 6.1.0.27 with and

without feature packs and WebSphere Application Server version 7.0.0.7. The version ofthe AIX operating system is 6.1.3 and both the operating system and WebSphereApplication Server are the 64 bit varieties. The new virtual image allows you to build

patterns that can be deployed to the PowerVM hypervisor platform.

In order to allow you to deploy patterns to a PowerVM cloud, WebSphere CloudBurst 1.1introduces the ability to manage elements of an IBM pSeries environment. To do this,

WebSphere CloudBurst interfaces with a plugin to IBM Systems Director called

VMControl.

Figure 2. WebSphere CloudBurst and the IBM pSeries cloud

wca-pseriescloud.jpg

Figure 2 depicts the way in which the WebSphere CloudBurst Appliance interacts with a

VMControl instance in order to manage the PowerVM cloud environment. Based onrequests from the appliance, VMControl communicates with the Hardware Management

Console (HMC) to create LPARs on IBM Power systems. These LPARs host the virtual

systems that are created as a result of deploying patterns with WebSphere CloudBurst.VMControl also communicates with a Network Installation Manager (NIM) instance in

order to deploy the WebSphere Application Server Hypervisor Edition virtual images to

the target LPARs. Note that when deploying to a PowerVM cloud you still benefit from

the intelligent virtual machine placement algorithm provided by WebSphere CloudBurst.


5/31

Regardless of the type of cloud, WebSphere CloudBurst retains responsibility and controlover virtual machine placement.

You are not constrained to leveraging one cloud type per WebSphere CloudBurstAppliance. Support for the PowerVM hypervisor platform added in WebSphere

CloudBurst 1.1 means that you can manage both VMware and PowerVM clouds from asingle appliance.

Figure 3. Managing heterogeneous cloud environments

wca-heterocloud.jpg

In order to utilize a PowerVM cloud environment, you need to define a new cloud group.In the definition of this new cloud group, you specify the location of an IBM VMControl

installation that interfaces with the pSeries environment that includes the PowerVM

platform.

IBM WebSphere CloudBurst Appliance 1.1

Catalog

Virtualimages for

VMware

Virtualimages forPowerVM

Cloud Groups

Patterns

VMwareCloudGroup

PowerVMCloudGroup

The Cloud

VMwarehypervisors

PowerVMhypervisors


6/31

Figure 4. Defining a PowerVM cloud group

wca-pcg1.jpg

In Figure 4, you can see that we provide information about our new cloud group including

its name, hypervisor type, and then the location and login information for the VMControl

instance. In addition to what is shown above, you also supply login information for theoperating system that is hosting the VMControl instance. All that is required for this is a

username and password.

Once the PowerVM cloud has been defined, you can build WebSphere CloudBurst

patterns based on the new version of the WebSphere Application Server Hypervisor

Edition packaged for that environment. The user experience with respect to buildingpatterns based off this new image is virtually unchanged when compared to building

patterns for VMware platforms. The only difference when building a pattern for the

PowerVM environment is that you select the virtual image built for the PowerVMplatform.


7/31

Figure 5. Building a pattern for the PowerVM environment

wca-pvmpattern.jpg

Once the appropriate image is selected, you customize the topology and include script

packages using the same Pattern Editor interface.

In addition to the pattern building process, the pattern deployment process for a PowerVM

pattern is much the same as well. Other than targeting a cloud group that containsPowerVM hypervisors, the only difference is the option to specify the number of

processors to be assigned to each part in the pattern as highlighted in the image below.


8/31

Figure 6. Deploying a pattern to PowerVM

wca-pvmdeploy.jpg

Once a user initiates the deployment process, the appliance intelligently selects the right

hypervisors to host the different virtual machines in the virtual system, and it dynamicallycreates LPARs in which the virtual machines will run. Once all the virtual machines and

WebSphere Application Server components within them are started in the LPARs, the

WebSphere CloudBurst Virtual Systems page is updated to reflect the current status.


9/31

Figure 7. Virtual system on PowerVM

wca-pvs.jpg

Notice that like virtual systems running on a VMware platform, WebSphere configuration

information, node location information, and links directly into the environment aresupplied.

DB2 Enterprise 9.7 virtual imageThe image built for the PowerVM platform is not the only new virtual image delivered

with WebSphere CloudBurst 1.1. The new version of the appliance brings with it a DB2Enterprise 9.7 virtual image, initially available as a trial offering. The DB2 image resides

in the WebSphere CloudBurst catalog alongside the rest of the WebSphere Application

Server Hypervisor Edition images.


10/31

Figure 8. DB2 Enterprise 9.7 virtual image

wca-db2img.jpg

As with all other images, you can use this new DB2 virtual image when building patterns.To do this, navigate to the Patterns page and click on the green cross at the top of the left

panel. Give your new pattern a unique name, and then select the new DB2 Enterprise 9.7

virtual image as shown in Figure 9.

Figure 9. Creating a DB2 pattern

wca-db2patternpanel.jpg

After selecting the virtual image, click the OK button, and then navigate to the PatternEditor by clicking the pencil icon in the upper right hand corner of the screen. Once in the

pattern editor, drag the lone part in the DB2 virtual image and drop it on the pattern

canvas.


11/31

Figure 10. Editing a DB2 pattern

wca-db2pedit.jpg

You can optionally include script packages just as you can with other WebSphere

CloudBurst patterns. For instance, you may want to include a script package that createsand populates databases for your application environment.

Once you are done editing the DB2 pattern, you can deploy it by clicking the Deploybutton on the pattern detail page.


12/31

Figure 11. Deploying a DB2 pattern

wca-db2deploy.jpg

Besides the information that is typical to every deployment like virtual machine memoryallocation, CPU allocation, and password information, there is some information particular

to the DB2 environment. First of all, you supply a password for the DB2 instance that will

be created for you. The password you supply, coupled with the pre-configured db2inst1user, form the credentials you will need to manage the DB2 instance. You can also

provide a custom value for the DB2 Service port and for both the FCM start of portrange and FCM end of port range. Once you supply this configuration information clickthe OK button on the part configuration panel and again on the main panel to begin

pattern deployment.

When the pattern deployment process finishes, a process that takes only about threeminutes after the first deployment, you can view information about the DB2 virtual

system.


13/31

Figure 12. DB2 virtual system

wca-db2vs.jpg

Once the virtual system is in the started state, you can login to the DB2 instance, via the

link from the WebSphere CloudBurst console if you wish, and manage the database as youwould any other DB2 installation. In addition, your applications can now use this DB2

environment.

VMware vCenter integrationAs mentioned above, starting with WebSphere CloudBurst 1.0 and continuing with 1.1,

you can define a cloud that consists of VMware ESX hypervisors. Starting in WebSphere

CloudBurst 1.1, the process of defining this environment is made even simpler by way ofintegration with VMware vCenter. When defining a cloud group in WebSphere

CloudBurst you can now specify information about the location of a VMware vCenter

instance as shown in Figure 13.


14/31

Figure 13. Adding a VMware vCenter cloud group

wca-virtualcenter.jpg

After you indicate the cloud group is managed by VMware vCenter, you provide the

information about the location of your VMware vCenter instance as well as necessary

login credentials. Once you define the information above and click the Create button, youwill be prompted to accept the SSL certificate from VMware vCenter. After accepting the

certificate, each of the ESX hosts managed by the specified VMware vCenter will show

up in the detail panel for the cloud group.


15/31

Figure 14. VMware Virtual Center cloud group details

cb-vmvchvs.jpg

In addition, hypervisor resources were automatically created for each of the hosts shown

in the Hypervisors section above. This means that you do not have to individually addeach of the hosts. Rather, you simply assign IP Groups to the hypervisors and they are

ready to be started. Further, if you do not want to use all of the hosts, you can remove any

of them by simply clicking the remove link. This removes the hypervisor from the cloudgroup and deletes the hypervisor resource that was created.

In addition to making it easier to add several VMware ESX hosts, the integration with

VMware vCenter also changes the point of contact between WebSphere CloudBurst andthe hypervisor environment. When you create a cloud group that consists of VMware ESX

hosts that were manually defined, WebSphere CloudBurst communicates directly with

each hypervisor host to initiate deployments and specify the placement of virtual

machines. However, when a cloud group is created that is managed by VMware vCenter,WebSphere CloudBurst communicates with the VMware vCenter instance directly to

carry out these actions. Regardless of whether or not WebSphere CloudBurst iscommunicating directly with VMware ESX hosts or with a VMware vCenter instance, it

always makes the determination of where (which hypervisor) to place the individual

virtual machines in a virtual system. This is done by an intelligent placement algorithm inthe appliance that considers all the compute resources available in a cloud group, and


16/31

attempts to optimize performance and avoid single point of failure scenarios for yourapplication environment.

Currently, WebSphere CloudBurst 1.1 does not support some advanced features offeredby VMware vCenter such as VMotion, Storage VMotion, and Distributed Resource

Scheduling (DRS). If you create a cloud group that is managed by a VMware vCenterinstance, you must make sure that these advanced features are not used on any of thehypervisors in your cloud group.

Enhanced customization and management capabilitiesfor application environmentsWebSphere CloudBurst is focused on providing the set of capabilities necessary tomanage the full lifecycle of WebSphere application environments in your private cloud.

The ability to create and deploy customized environments, from the operating system

layer all the way up to the middleware layer, and then to update those environments once

they are running in your private cloud is key to supporting the lifecycle. WebSphereCloudBurst 1.1 introduces enhancements that allow for greater customization of your

application environments, and it delivers updates to the command line interface that allow

you to easily maintain and update these environments in an automated fashion.

Virtual image extend and capture disk resizing

The ability to create a custom image in WebSphere CloudBurst is done through the extend

and capture process. This capability is not new to WebSphere CloudBurst 1.1 as it waspresent in version 1.0. However, the ability to resize the four different virtual disks during

the image extension process is new to WebSphere CloudBurst 1.1.

To start the image extension process, navigate to Catalog>Virtual Images and click onthe existing virtual image that you wish to extend. In the upper right hand toolbar, click

the export icon. Figure 15 shows the popup that will appear. In the General information

section enter a unique name and in the Version field enter a version number that makessense to you.


17/31

Figure 15: Extend/Capture General information

figure3b.jpg

Next, click on Deployment configuration illustrated in Figure 16. In this view you will

enter the cloud group to deploy the virtual image to and the password used for the rootand virtuser users. This information is necessary because WebSphere CloudBurst will

create a standard pattern from the image you selected to extend and deploy that pattern

into the cloud group you specify. This provides a running virtual machine in whichcustomizations, such as installing custom software, can be made.

Figure 16: Extend/Capture Deployment configuration


18/31

figure4b.jpg

Up to this point we did not go through anything new other than the reformatting of

existing options. The truly new part of extend and capture is in the ability to resize thevirtual disks and specify the number of network interfaces. The Hardware configuration

section illustrated in Figure 17 gives you the ability to resize the virtual disks that makeup the virtual image. Once you have extended your virtual image you will be unable tomodify the sizes of the virtual disks.

Figure 17: Extend/Capture Hardware configuration

figure5b.jpg

The Hardware configuration section shown above is the information that is displayed forimages packaged for the VMware platform. PowerVM virtual images are different in that

they do not contain a separate virtual disk for each component (OS, WebSphere

Application Server binaries, WebSphere Application Server profiles and IHS) of thevirtual image. The PowerVM virtual image is made up of one virtual disk called

image1.mksysb. The default size of this virtual disk is 26GB to which WebSphere

CloudBurst appends 15 additional GBs of storage to accommodate the mksysb filesystem,resulting in a default total disk size of 41GB. Figure 18 shows the Hardware configuration

for Power.


19/31

Figure 18: Extend/Capture Hardware configuration Power

figure6b.jpg

Once you have configured your virtual disk sizes press the OK button. This will create a

virtual system with the name you defined in the General information section. The time it

takes for the creation of the virtual system will be in the order similar to a WebSphere

single server pattern deployment. Once the virtual system has been created you canmake your modifications and then capture your changes back into the catalog. To capture

your changes you navigate to Catalog>Virtual Images and click on your extended virtual

image. Next, click the capture icon located in upper right corner of the panel. The captureprocess will take more time than the extend operation, so be patient.

User initiated script packagesPrior to WebSphere CloudBurst V1.1, script packages attached to a pattern were

automatically invoked by WebSphere CloudBurst near the end of pattern deployment afterthe creation of the virtual system. In many cases this was sufficient, but you may also wan

tto attach scripts that are invoked during deletion of the virtual systems or at any time you

decide. There may be times when you want to execute a script package at virtual system

deletion, such as when cleaning up resource handles. There may be times when you wantto execute a script package manually, such as re-installing an application.

WebSphere CloudBurst V1.1 introduced the Executes field on the Cloud>Script

Packages>YOUR_SCRIPT_PACKAGE panel. This field has three options:

at virtual system creation (default)

at virtual system deletion

when I initiate it

at virtual system creation is the default and produces the same script package invocationbehavior that was present in WebSphere CloudBurst 1.0. at virtual system deletion is


20/31

just the opposite in that it will happen when the virtual system is deleted. when I initiate

it tells WebSphere CloudBurst that the script package should be invoked when you

specify. Figure 19 illustrates the new field showing the three available options.

Figure 19: Executes field

figure1b.jpg

Execution of scripts packages at creation and deletion time is self explanatory, but lets

take a little closer look at user initiated (when I initiate it) script packages . When you

create a script package and choose when I initiate it, a button will be added to the detailspage of the virtual machine on which the script was included as seen in Figure 20.

Figure 20: Virtual system user initiated script package

figure2b.jpg


21/31

In order to execute the user initiated script package you click the green play button with

the text Execute now. This will cause WebSphere CloudBurst to transfer the script

package from the catalog over to the virtual machine, unzip and then execute the contentsof the script package. If it is not apparent, this feature allows you repeatedly update your

script package, execute the script package on the virtual machine and verify all withouthaving to re-deploy the virtual system.

Command line interface updates

The WebSphere CloudBurst V1.1 command-line interface (CLI) brings with it many

enhancements and improvements over the V1.0 implementation. This section will cover

just a few of these enhancements.

Imagine for a second, that the CLI version you downloaded to your local system is at a

different level than the WebSphere CloudBurst appliance you are trying to interface with.

WebSphere CloudBurst V1.1 introduces a feature that will automatically update the CLIto the correct version. This feature removes the burden of comparing versions,

downloading and installing a matching version of the CLI. The CLI contains a smallamount of bootstrap code that contacts the target appliance, compares versions and if the

versions do not match it downloads the appropriate libraries and uses those to

communicate with appliance. In this way you are ensured that you are always using the

right version of the CLI libraries when connecting to a particular appliance. Figure 21graphically depicts this process.

Figure 21: Command-line interface automatic update

figure7b.jpg

In addition to this bootstrapping enhancement, there are new features available in the

cloudburst module of the WebSphere CloudBurst CLI.

To start, WebSphere CloudBurst V1.1 CLI comes with support for creating andmanipulating emergency fixes and configuring the appliance. Two resources were

introduced to create and import fixes and maintenance into the catalog:

cloudburst.fix cloudburst.fixes


22/31

Four methods were introduced to find and apply fixes and maintenance to the virtualsystems:

virtualsystem.findUpgrades()

virtualsystem.applyUpgrade()

virtualsystem.findFixes()

virtualsystem.applyFixes()

Figure 22 shows an example of an emergency fix being created using the CLI. The firsttwo lines create an emergency fix with the name Fix-Article and uploads the .pak file.

The last two lines define which virtual image this fix can be applied to (Applicable to

field for those familiar with the UI)

Figure 22: Example - emergency fix creation

figure14b.jpg

After you have created your emergency fix you can install this fix onto a target virtual

system. Figure 23 shows an example of an emergency fix being applied to a virtual

system. The first line gets a handle to the virtual system to which you want to apply thefix. The second line gets a list of all available fixes for this virtual system. Finally, the

last line applies the fix to the virtual system.

Figure 23: Example service applied to virtual system

figure15b.jpg

The other improvement in the WebSphere CloudBurst V1.1 CLI is its ability to manage

the appliance settings. The following resources were introduced to allow you to manageyour appliances settings:

cloudburst.security

cloudburst.ethernet

cloudburst.dns

cloudburst.dateandtime

cloudburst.mail

cloudburst.ilmt


23/31

cloudburst.firmware

cloudburst.power

We will not provide examples of all the new CLI capabilities in this article, but you canfind more information about using the WebSphere CloudBurst CLI in the product

information center linked in the Resources section below.

Resource sharing techniquesWhen you use WebSphere CloudBurst to build customized application environments, you

invest a lot of time and intellectual resource into getting those customizations just right.

You start by creating custom virtual images that contain operating system customizations

like the installation of additional software or other configuration changes, and then basedon these custom images you create customized WebSphere CloudBurst patterns. These

patterns contain not only the different types of nodes that make up your WebSphere

Application Environment but customizations in the form of script packages. Thesecustomizations represent applications, tuning, and other middleware level customizations

that are needed in your particular environment.

Once you have invested the time to build up these customized elements on a particular

WebSphere CloudBurst Appliance, you may want to share them with another appliance.

In WebSphere CloudBurst 1.0 you could do this by backing up the entire state of theappliance that held your customized images and patterns (the source appliance) to an

external store. Once the backup location was established you could import the appliances

state into the WebSphere CloudBurst Appliance that you also wished to have these custom

images and patterns (the target appliance).

This approach is less than desirable when you simply want to share images and patterns

among appliances. In WebSphere CloudBurst 1.1 new capabilities make it easier for youto share both customized patterns and images among a set of appliances.

Sharing WebSphere CloudBurst patterns

Consider the case that you have built a customized WebSphere CloudBurst pattern on one

appliance and you want to utilize that same pattern, with the same customizations, on adifferent appliance. There are essentially three elements that need to be accounted for

when sharing the pattern:

Pattern (topology)

Script packages

Virtual image

All three pieces need to be transferred from one appliance to another in order for this

process to work. We will talk about each in order.


24/31

In order to get the pattern off of the appliance you have two options. You can either usethe CLI commands directly or you can use the interactive script that is provided in the

samples directory.

Figure 24 demonstrates using the CLI commands directly. First, you need to get a handle

to the pattern you want to export. Once you have a handle to the desired pattern, call the.toPython() method on the pattern object to export it. The .toPython() commandwill create a Jython script and place it in the location you specified as a parameter to the

command. As you can see this is pretty simple.

Figure 24: CLI commands to export pattern

figure8b.jpg

WebSphere CloudBurst V1.1 also ships with an interactive script that will accomplish the

same thing as the direct CLI commands in Figure 24. This script is located in the

samples directory and is named patternToPython.py. Figure 25 demonstrates the usageof this interactive script.

Figure 25: patternToPython.py example

figure9b.jpg


25/31

Both the CLI commands and the patternToPython.jy script included in the samples

directory are used to create a Jython script containing CLI instructions to rebuild the

pattern on your target appliance. This script will eventually be executed against the targetenvironment, but first we must ensure that any associated virtual images and script

packages that make up the pattern exist on the target system.

There is no automated way to export a script package from one appliance to another. You

will need to manually recreate the script package on the target appliance if it does not

already exist on the target appliance. Take note of the script package settings as you will

need these when you recreate on the target appliance.

This may be a good time to point out a best practice when creating script packages.

WebSphere CloudBurst gives you the capability to package the definition of the scriptpackage inside of the archive. This can be done by including a file called cbscript.json

with the script packages configuration settings. If you use this approach to define your

script packages you can bypass writing down your script packages configuration settingsand reentering them onto the target appliance. Instead, you just need to upload the archive

onto the target appliance and all of the configuration settings are automatically brought

over. For more information on this approach see part 3 of the Customizing with

WebSphere CloudBurst article series.

To ensure that you have the correct archive contents of the script package click the

Download link which is highlighted in Figure 26.

Figure 26: Script package archive download link

figure10b.jpg

Lastly, you need to ensure that the virtual image that makes up the pattern exists on the

target appliance. If it does not exist then you will need to export from the sourceappliance and import into the target appliance.

Exporting virtual images from the catalog

To export a virtual image, navigate to Catalog>Virtual Images and click on the virtual

image that you want to export. Located in the upper right corner is an export icon, click it.


26/31

This will result in a window being displayed requesting information on where to place theexported virtual image (.ova). Figure 27 is a screen capture of the window that is

displayed. The host that you define in the Remote host field must support SCP. Remotepath should be some location that can support a large file transfer. The size of the virtualimage is dependent on your scenario. To give you an idea of the size requirements, the

preloaded virtual images require roughly 4-6GB of storage. The export process can takesome time, which is dependent on the size of the virtual image and the speed of yournetwork.

Figure 27: Virtual image export dialog

figure11b.jpg

Importing a pattern into the target appliance requires a few steps which we will describe

here. Before you import the pattern, you need to import the virtual image and recreate the

script packages that make up the pattern.

To create a script package in the WebSphere CloudBurst web console, navigate to

Catalog>Script Packages and click on the green plus icon to create a new script package.Use the archive and information you noted (paying special attention to the name) in a

previous step.

There are two options available when importing a virtual image. You can use theadministrative console by navigating to Catalog>Virtual Images or you can use the CLI.

If you use the administrative console the virtual image that you exported in a previous step

will need to be hosted on a HTTP server. If you use the CLI then you can either push the


27/31

virtual image up from a HTTP server or your local file system. Figure 28 shows anexample of the CLI virtual image upload command pushing a virtual image up from your

local file system. The virtual image import operation can take quite some time depending

on the size of the virtual image and speed of your network.

Figure 28: CLI virtual image upload command

figure12b.jpg

At this point you have configured your target appliance with all the pattern dependencies

(virtual image and script packages). The only thing left to do is to import the pattern.You import the pattern by executing the Jython script created in previous steps. Figure 29

shows how to run the script. As you can see it is no different than executing any other

script.

Figure 29: CLI pattern import command

figure13b.jpg

The pattern and all associated artifacts have been imported into the target appliance. Youcan now successfully deploy the pattern.

New Security ControlsWebSphere CloudBurst provides several security features that deliver a secure

environment in which to create, deploy, and manage WebSphere application environments

in a private cloud. A core part of delivering this secure environment is the ability to define

users and user groups with associated set of permissions and resource access rights. InWebSphere CloudBurst 1.1, updates have been delivered to both user permissions and

resource access rights that help to further enhance security controls in the appliance.

User group permissionsIn WebSphere CloudBurst 1.0, the permissions mentioned above were assigned toindividual users of the appliance. User groups were mainly a way to organize users and

assign access to shared resources at the group level instead of having to specify access for

each user in the group. Permissions could not be assigned to user groups.


28/31

With updates to WebSphere CloudBurst 1.1 permissions can now be assigned at the grouplevel. When you define a user group, you will also decide on a set of permissions for the

group.

Figure 30. User group permissions

wca-usergroups.jpg

As you can see, a user group can have the same permissions as an individual user. Thereare some things you should know when creating user groups and assigning users now that

permissions are associates with user groups. First, when you add a user to a user group,

any permissions the user had prior to being added to the user group are lost. Usersautomatically inherit the permissions of the group to which they are added. As such, once

a user is added to a group (besides the default Everyone group created by the appliance),

that users permissions can no longer be edited at the user level. Any permission changemust be done at the user group level. With that said, it is important to point out then that

any permissions granted to a user group apply to all of the users in that particular user

group.

It is possible for WebSphere CloudBurst users to belong to multiple WebSphere

CloudBurst user groups. In that case the effective permissions of the user become the sum

of the permissions of the groups to which the user belongs. For instance, say the user

Dustin belongs to both the Systems Test Group and the Admin Group. The Systems


29/31

Test Group has the permission to deploy patterns to the cloud while the Admin Group hasboth the cloud and appliance administration permissions. As a result, Dustin would have

permission to deploy patterns, administer the cloud, and administer the appliance.

If at any point a user is removed from a user group, the user retains the permissions of the

groups to which they still belong. From the above example, if Dustin were removed fromthe Admin Group he would still have the permission to deploy patterns however he couldno longer administer the appliance or the cloud.

Access control for cloud groups

Suppose you configured multiple different cloud groups that represented different

subclouds within your organization. You may have defined a cloud group that contained

hypervisors used for testing purposes, another cloud group that contained hypervisors usedfor development, and yet another cloud group that contained hypervisors used in your

production environment. In this case it is likely that you want to control access to each of

these different subclouds in your WebSphere CloudBurst environment. For instance, you

may want to limit appliance users from your development team to only be able to deploytheir patterns into the development cloud group.

In WebSphere CloudBurst 1.0 access control to different subclouds could only be

controlled by governance policies external to the appliance. There was no way to specify

exactly which users had access to specific cloud groups. However in WebSphere

CloudBurst 1.1, the fine-grained access control previously available for virtual systems,patterns, virtual images, script packages, and emergency fixes has been extended to cloud

groups. This means that for each cloud group you can decide exactly which users or user

groups have access to deploy patterns into that environment. For example, in Figure 31,the user Dustin has access to deploy patterns to the Development Cloud cloud group.


30/31

Figure 31. Assigning access to cloud groups

wca-cloudgpaccess.jpg

If you are migrating from a previous version of WebSphere CloudBurst to version 1.1 this

new feature will impact cloud groups that existed before the migration in two ways. First,after migration the owner of the preexisting cloud groups will be automatically set to the

cbadmin user. Any cloud groups created after the migration will be owned by the user

that creates the resource. Second, the user group Everyone is assigned read access to all of

the preexisting cloud groups. This means that all users still have access to deploy patternsto the cloud groups that were defined in your WebSphere CloudBurst 1.0 setup. This is

done to preserve the access control behavior for cloud groups in WebSphere CloudBurst1.0.

New LDAP integration capabilitiesIn many cases you may have an existing LDAP server that contains, among other things, a

record of users, their passwords, and groups they belong to within your enterprise. Withversion 1.0 of WebSphere CloudBurst you can integrate with an LDAP server to

authenticate users of the appliance. In this situation, you define users in WebSphere

CloudBurst with the exact same username that appears in your LDAP server. You would

associate permissions with the user in WebSphere CloudBurst, but do not need to providea password for the user as is normally done. Instead, when the user logs into the appliance,

the password they supply is authenticated against the information stored in the LDAP

server. This allows you to avoid the situation where a given users password is out of syncacross various systems in the enterprise.

With WebSphere CloudBurst 1.1, LDAP integration is extended to the user group level.Now when you specify an LDAP server you also configure it to integrate with information


31/31

about user groups across your enterprise. Once this information is supplied, you can beginadding both users and user groups to the WebSphere CloudBurst Appliance. When new

users are added to the appliance, they are automatically added to any groups on the

appliance to which they belong. When new user groups are added, any users of theappliance that are members of the group are automatically added to the new group on the

appliance. When LDAP integration is configured, any time a new user or user group isadded to the appliance, WebSphere CloudBurst verifies that it is a valid user or user groupin your LDAP server. If the user or user group is not defined on the LDAP server it cannot

be added to the appliance.

You should also be aware that when you enable LDAP authentication on the appliance,group membership can no longer be edited via WebSphere CloudBurst. This means you

cannot add or remove users for a user group on the groups detail page in WebSphere

CloudBurst, nor can you add or remove groups for a user from the users details page.Any updates to group membership must be done on your LDAP server.

ConclusionUpdates to the WebSphere CloudBurst Appliance delivered in version 1.1 further advanceits capabilities to manage the full lifecycle of WebSphere application environments in a

private cloud. To start, you can now harness the PowerVM platform to host their

virtualized WebSphere Application Server environments. Increased customization andmaintenance controls help you to deliver even more highly customized application

environments all the while providing a more automated approach to maintaining those

environments over time. In addition, WebSphere CloudBurst 1.1 delivers new featuresthat allow the different elements of these customized application environments to be easily

shared among a set of appliances. Finally, enhanced security controls make it easier to

manage user permissions and control access to subclouds, and new group-level LDAPintegration makes it easier to integrate user and group management between WebSphereCloudBurst and existing enterprise control systems. You can see some of these new

features in action by viewing the demonstrations on our WebSphereClouds YouTube

channel linked below.

what's new in websphere cloudburst 1.1?

Documents