Modeling virtual systems with the IBM Rational Software Architect deployment architecture tools

This article discusses the use of the deployment architecture tools in IBM® Rational® Software Architect 7.5 in modeling virtual systems. It describes how to represent virtual deployments in a topology and how to work with existing virtual images.

Share:

Tim McMackin (tmcmack@us.ibm.com), Software Engineer, IBM

Photo of Tim McMackinTim McMackin is a technical writer for IBM's Enterprise Generation Language in Raleigh, NC. He has a background in writing for advertising technical products and has been with IBM since 2004.



22 June 2010

Also available in Chinese Portuguese Spanish

Introduction

You can use the deployment architecture tools in IBM Rational Software Architect Version 7.5 to describe a wide variety of computer systems in a type of model called a topology. Topologies can include individual computers, servers, software applications, hardware, components of computer networks, and many other elements of computer systems, all at various levels of abstraction. The author of this article assumes that readers have a basic familiarity with topologies. For an introduction to topologies and the deployment architecture tools, see the links in the Resources section.

The specific technologies and strategies of virtualization are also beyond the scope of this article, but, in short, a virtual system is a computer system that is insulated from its host by an intermediary. This intermediary interprets requests from the virtual system to the host, thereby adding a layer of virtualization between the virtual system and the host.

In the context of this article, an operating system running directly on hardware is a physical (or non-virtualized) system. To create a virtual system, you insert a layer of virtualization to separate the operating system from the hardware and to manage the communication between these components. A variety of technologies and strategies are available for this purpose, but, in general, creating a virtual system involves a hypervisor, which is software that presents the appearance of hardware to one or more virtual systems and intercepts a virtual system's attempts to communicate with the hardware.

Rather than letting the virtual system access the data storage, memory, and processing power of the physical system directly, the hypervisor manages these resources and provides mediated access to them. For example, the hypervisor might limit a virtual system's access to memory. The physical hardware might have a large amount of memory, but the hypervisor might designate only 1GB of that memory for a particular virtual system's use. Therefore, that virtual system appears to be running on a piece of hardware (that is, a virtual server) with only 1GB of memory. Similarly, the hypervisor might mediate access to data storage, processing capacity, or network connections.

In this way, the hypervisor makes virtual systems more flexible than physical systems. For example, assume that there are two similar physical systems, each running a different application, as Figure 1 shows.

Figure 1. Two simple physical (non-virtualized) systems
Diagram of 2systems with their own applications

Because each system has its own separate hardware, the amount of processing power that is available to each application is fixed. If application A comes under heavy use, it might run slowly, while application B might be idle. Thus, the processing capacity on hardware B might be underused. By running both applications on the same hardware through a hypervisor, you can direct resources to the system that needs them. With systems A and B virtualized on the same hardware, the hypervisor can provide more processing capacity and memory to the application that is being used more heavily Figure 2).

Figure 2. Two virtual systems
Diagram with 2 systems using hypervisor

The example in Figure 2 shows how several virtual systems can be hosted on a single physical system. Virtualization also works in the opposite direction; several physical systems can be combined to host a single virtual system. The most common example of this type of virtualization is clustering, in which a group of application servers work together to host an application. Rather than running a separate instance of the application on each physical system, the layer of virtualization presents a single hosting environment to the application, with the combined resources of the physical systems. The following example shows a cluster of two application servers that are hosting a single instance of an application.

Figure 3. A simple cluster of servers
A single application is running on a cluster

Virtualization permits cloud computing environments, which are dynamic hosting environments that provide seemingly infinite computing resources. Several types of cloud computing environments are in use today, but in general, a cloud provides a library of virtual systems and a hypervisor on which to run them. Users request instances of those virtual systems, use them, and de-allocate them when they are no longer needed. In this way, cloud systems use virtualization to provide a flexible environment that can be configured and expanded much more easily than a physical system.

A virtual system might provide a complete system, or it might focus on a virtualized resource, such as storage. For example, a virtual storage system might include several physical disks represented as a single storage medium. The applications that access the storage system interface with the virtual system, rather than storing data to the disks directly. In this way, you can combine several disks into a single virtual disk.

Figure 4. A simple virtual storage system
A storage pool unit that contains three disks

Virtualization has many other uses and advantages that are not discussed in detail here, such as the ability to run several independent environments for testing or compatibility and the ability to move virtual systems from one physical host to another with relative ease. Many IBM documents are available on virtualization in particular circumstances. For more information, see the Resources section.


Basic virtualization with the topology editor

Part of the point of virtualization is that an application does not need to know whether it is running on a virtual system or on a physical system. The virtual system appears just like a physical system to the application, and the details of the physical system that hosts the virtual system are hidden from the application. In the same way, you can use separate topology diagrams to hide the details of the physical system from the application.

For example, assume that there is a simple physical system, as shown in Figure 5, which consists of hardware with an operating system.

Figure 5. A simple physical system
Illustration says: 'physical hardware,' 'physical OS'

This system could host a virtual image, which is an encapsulated environment in which you can run a virtual system. As Figure 6 shows, this virtual image might contain virtual hardware and a virtual operating system.

Figure 6. A simple virtual image
A simple physical system hosting a virtual image

Notice that the virtual server unit is identical to the physical server unit. (The virtual operating system unit is identical to the physical operating system unit, except that the physical operating system unit has the Hypervisor capability, which will be discussed later.) The virtual system can host applications in exactly the same way that the physical system can.

In a topology, you can make this virtualization seamless by creating a diagram that is dedicated to the virtual system. When you visualize the units in the virtual system to a new diagram (by right-clicking the units in the virtual system and then clicking Visualize > Add to New Topology Diagram), the new diagram shows only the units in the virtual system, even though these units are still linked to the physical system.

Now you can use the virtual system in other topologies by importing the diagram. When you import a diagram from another topology, you create a new instance of the units and other topology elements in that diagram. You can host applications on the virtual system in the imported diagram just as you can on any other system. As a result, the virtual system in the topology behaves just like a virtual system in the real world: it can host applications without exposing the underlying physical system or even being ostensibly virtual.

Figure 7. Hosting an application on a virtual system
An application from another diagram is hosted

In this way, if a design calls for a hosting stack, you can substitute a compatible virtual system. For example, the following topology contains a conceptual hosting stack, a specification for the system that must host an application.

Figure 8. A simple conceptual hosting stack
Flow diagram

As with all conceptual units, the units in this hosting stack can have a realization link to any other units that could perform all of the same tasks as the conceptual units. For example, the Java™ 2 Platform, Enterprise Edition (J2EE) application server unit could be realized to any application server that supports the same version of Java EE, regardless of the brand of that server. You could realize this hosting stack to a physical system:

Figure 9. Realizing the conceptual stack to a physical system
The units are linked to units in an imported diagram

However, you could also realize this conceptual hosting stack to a virtual system in the same way:

Figure 10. Realizing the conceptual stack to a virtual system
The units are linked to an imported virtual system

You don't have to encapsulate virtual systems into separate diagrams, but doing so is generally good modeling practice because it keeps your topologies independent and small.


Working with virtual systems

Rather than designing a virtual system from the ground up, you can convert an existing physical system into a virtual system. For example, you might create a virtual testing environment that mirrors your production environment. Alternatively, you might receive a design for a physical system and decide to implement that system virtually. Converting a physical system to a virtual system like this involves adding the physical system to a virtual image and then configuring the virtual image to use the network connection and storage space of the virtual image's host.

Converting a physical system to a virtual system

Follow these steps to convert a physical system to a virtual system:

  1. Create the topology for the original physical system that you want to convert to virtual. You can duplicate an existing system by copying and pasting its units, or you can create new units, or you can use the physical system directly.
Figure 11. A physical system to be made virtual
A WebSphere application server system
  1. If the system hardware does not have a network interface unit, add an L2 interface unit to the server. This unit represents the network connection, such as a wired or wireless Ethernet connection.
  2. If the operating system does not have an IP interface unit, add an IP interface unit to represent the operating system's use of the network connection. (No link is necessary between the IP interface and L2 interface units.)
Figure 12. Adding the network connection information to the physical system
Diagram shows a new network connection unit
  1. Add a virtual image unit to the topology. You can use a generic virtual image, such as the (Virtual Image) template from the Virtualization drawer of the Palette, or you can use a specific VMWare or Xen virtual image unit if you want to work with a specific virtualization technology.
  2. Drag the physical server unit into the virtual image unit to make the server a member of the virtual image.
Figure 13. Moving the physical hardware to the virtual image
The physical hardware is now on the image
  1. Add a virtual disk definition unit and a virtual Ethernet connection unit to the virtual image. If the image is a generic virtual image, use a generic virtual disk definition unit from the (Virtual Disk Def) template and a generic virtual Ethernet connection from the (Virtual Ethernet NIC Def) template. Otherwise, use the equivalent Xen or VMWare-specific templates.

These units represent the configuration information that is specific to a virtual system. In this case, they represent the configuration of the virtual disk and network connection. When you model a virtual system in a topology, you can add this information to plan how the virtualization environment will provision and manage the virtual system.

Figure 14. Adding the virtual resources to the virtual image
New virtual resource units
  1. On the virtual Ethernet connection's capability, set the type of connection to the host system's network connection to use, such as bridged, host-only, or NAT.
Figure 15. Setting the connection type
Editing the attributes for the capability
  1. Host the virtual image on an appropriate hypervisor:
    • For a generic image, add the virtualization.Hypervisor capability to an operating system unit.
    • For a VMWare image, use a VMWare ESX unit.
    • For a Xen image, add the virtualization.XenHypervisor capability to an operating system unit.
  2. Host the hypervisor on an appropriate hardware unit, such as an x86 server unit from the (x86 Server) template in the Hardware drawer of the Palette.
Figure 16. Hosting the virtual image
A conceptual virtual image hosted by a hypervisor
  1. Create a dependency link from the virtual Ethernet connection unit in the virtual image to the L2 connection in the physical server. This link represents the network access that the server provides to the virtual system. As with adding the virtual disk and network connection units, this dependency link augments the model with extra information to describe the configuration of the virtual image.
Figure 17. Specifying the network connection with a dependency link
A dependency link for the network connection

The complete virtualized system behaves just like a physical system. As explained previously, you can import the virtualized system into another topology and use it just like you would use a physical system. For ease of reuse, visualize the virtualized system on a separate diagram so you can import this system into other topologies without exposing the details of the physical host.

Figure 18. Hosting an application on the newly virtualized server
A component is hosted on an imported virtual system

Planning deployment for an existing virtual image

If you already have a virtual image, you can plan the deployment of that image in a topology. The topology editor recognizes Xen XMDOMAIN files and VMWare VMX and VMSD files. These files provide information about a virtual host, and the topology editor can create units that represent the host based on this information. However, these files do not contain enough information to model the operating system and other software hosted on the virtual image. You can use the topology editor to add information about the system in the virtual image and to plan how the virtual image will be deployed. (The topology editor cannot make changes to the virtual image files, though.)

Follow these steps to deploy an existing virtual image in a topology:

  1. Drag and drop a virtual image, such as a VMWare VMX file, onto a topology (Figure 19). The topology editor creates a matching bound virtual image unit (Figure 20) that contains disk definition units and network connection units, according to the data in the virtual image file.
Figure 19. Dragging a virtual image to the topology editor
Dragging the virtual image from the Project Explorer view
Figure 20. The units that represent the virtual image
New units representing the image, disk drives, and network connection

Tip

Rather than copying the virtual image files into a project your workspace, it can be easier to create a folder in your workspace that is linked to the folder on a disk where you keep your virtual images. To create a linked folder:

  1. Right-click a project in the Project Explorer view and then click New > Folder.
  2. In the New Folder window, expand the Advanced section, select the Link to a folder in the file system check box, and select the folder on disk.
  3. Now you can use the files in that folder as though they were in your workspace.
  1. Host the virtual image on an appropriate hypervisor unit:
    • For VMWare images, use a VMWare ESX unit, or an operating system unit with the virtualization.VMwareHypervisor capability, which represents VMWare software installed on an operating system.
    • For Xen, use an operating system unit and add the virtualization.XenHypervisor capability to represent the Xen hosting software.
Figure 21. Hosting the virtual image
Hosting the image on a VMWare ESX unit
  1. Within the virtual image unit, add units as appropriate to the use of the virtual image. For example, you might add a server hardware unit and an operating system unit to represent the hosting capabilities of the virtual system.
Figure 22. Representing the software that is on the virtual system
Adding an operating system unit to the image
  1. Host the hypervisor unit on an appropriate hosting stack.

Examples of virtual topologies

The following section shows a few examples of virtual systems modeled in the topology editor. Many other examples of topologies are available in the product help: click Help > Help Contents and then expand Samples > Technology Samples > Topologies. Many of the topologies shown in this article are available in the Resources section.

VMWare ESX

A VMWare ESX system (Figure 23) is a type of hypervisor that runs directly on hardware, in place of an operating system. A single instance of VMWare ESX can host one or more virtual images, each of which contains a virtual system. The virtual image also contains virtual disk definition and virtual network connection units that represent the virtual resources that the hypervisor provides to the virtual system.

Figure 23. Example of a VMWare ESX system
A simple VMWare ESX system with two hosted images

Xen

Xen is an open-source virtualization technology. Topologies that use Xen for virtualization look much like those that use VMWare, except that the Xen hypervisor is represented by the virtualization.XenHypervisor capability on the physical operating system unit, rather than by a separate unit.

Figure 24. Example of a Xen system
A Xen virtual system with two hosted images

Clustering

A simple example of clustering was given in the introduction. A similar example is available in the sample Topologies for specialized domains (see the Resources section). Clustering involves combining a group of physical systems into a single hosting environment for one or more applications or virtual systems. Figure 25 shows a cluster of IBM® WebSphere® Application Servers hosting an application.

Figure 25. Example of a cluster of servers
A cluster of servers hosting a Java EE application

System z

Beginning with IBM Rational Software Architect 7.5.4, the deployment architecture tools include units and other topology elements that represent IBM® System z® components. System z permits virtualization in two main areas: at the hardware level with logical partitions (LPARs) and at the operating system level with IBM® z/VM®. A piece of System z hardware might have several different processors, and you can allocate these processors to LPARs on the system. You can use LPARs to divide a single piece of System z hardware into separate virtual pieces of hardware. Each of these LPARs can run an operating system, such as z/VM, IBM® z/VSE™, or IBM® z/Linux.

Figure 26. Example of a LPARs on a System z system
Three LPARs on a single System z system

To provide further layers of virtualization, an instance of z/VM can host one or more other operating systems, called z/VM guests. These guests provide another layer of virtualization. The topology in Figure 27 shows a simple System z system that hosts several different virtual systems.

Figure 27. Example of a complete System z system with z/VM guests
Four z/VM guests on the system

In this example, the system has four physical processors: two central processors (CPs) and two z Application Assist Processors (zAAPs). These processors are shared among three LPARs, each of which runs a separate virtual operating system. One of these virtual operating systems is further divided into two guest virtual systems, one that hosts z/Linux and one that hosts z/VSE. In this way, virtualization on System z allows you to divide a large computer into several virtual systems and distribute the system resources as needed.


Summary

The examples in this article show some of the ways to model simple virtual systems with the deployment architecture tools. They also show how to separate virtual systems into diagrams, which illustrates the independence of the virtual systems from their physical hosts. In this way, the deployment architecture tools can help you plan deployment for complex applications or complex environments. Several of these example topologies are available in a project in the Download section.


Download

DescriptionNameSize
Virtual topology examplesVirtualTopologyExamples.zip77KB

Resources

Learn

Get products and technologies

Discuss

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=496705
ArticleTitle=Modeling virtual systems with the IBM Rational Software Architect deployment architecture tools
publish-date=06222010