Before you start
IBM® Rational® Software Architect is a powerful tool for software development, but the capabilities are not limited to that specific area. With its complete UML support and overall modelling abilities, it can be used in quite flexible ways:
- Free-form diagramming: The plethora of diagram options provides a complete foundation for free-form diagrams, as they are often used in non-software development scenarios. An IT architecture overview can easily be made by using a Deployment or Component model or even by mixing concepts from different models.
- Method artifacts: When following a specific methodology (Rational Unified Process or OpenUP, for example) there is often the need to create models and diagrams. Rational Software Architect can be used to good effect in producing them, either by itself or by using specific plug-ins that streamline the process and provide helpful templates.
- Modeling deployment topologies: This is a specific ability that recent versions make available and one that is different from the UML deployment model.
This tutorial focuses on the last point: deployment topologies. This feature can be used in many different ways. As an example, you could put aside all of the niceties regarding constraints, requirements, and capabilities and simply use it as another form of diagramming. This is true for most parts of Rational Software Architect, in that there is a superficial use that can be immediately productive and a more involved one that takes more time to learn but that has an even higher potential for productivity.
The deployment topologies are not UML (although they will use UML links if they are present and are integrated with existing UML diagrams), and they can represent a wide variety of computer systems in different levels of abstraction. It's quite intuitive, because it doesn't require the level of conceptual understanding that UML does. It uses well-known terms for well-known relationships among software, hardware, and other IT components. By default, Rational Software Architect comes with templates that cover many different software packages, hardware models, operating systems, and many other different units in different domains. But equally important, Rational Software Architect makes it possible to customize the existing units to your own needs.
This tutorial guides you through the process of developing a custom-made virtualization framework to use with modeling for the IBM® Power Systems™ platform with PowerVM technologies. Rational Software Architect has a rich deployment topology editor that contains explicit support for several virtualization technologies and, equally important, makes it easy to customize existing elements. Using PowerVM modeling as an example, you learn how to quickly modify generic units to adapt them to new scenarios.
About this tutorial
This tutorial is broadly divided in three major steps:
- A quick introduction to physical deployment modeling, using discrete servers
- A hands-on overview of some of the existing virtualization technologies explicitly supported by Rational Software Architect
- The gradual development of PowerVM virtualization support by using the Rational Software Architect customization tools
Although the customization process is straight-forward, this tutorial assumes no prior experience with Rational Software Architect. Therefore, some emphasis is given to showing how deployment topologies are created and populated. By the time the customization process begins, the core concepts of topologies have already been demonstrated and it is a natural progression.
In this tutorial, you will learn about Rational Software Architect deployment topologies, how to model a physical infrastructure, and how to model different virtualization technologies. By the end of this tutorial, you will have successfully implemented support for PowerVM modeling and will have learned the fundamentals of customization that can be used in many other scenarios.
This tutorial is not based on any specific operating system. However, the examples use Linux, so any file system operation should be converted to the equivalent if some other operating system is used.
This tutorial requires no prior knowledge of modeling deployment topologies. Some familiarity with Rational Software Architect is helpful but it is not assumed.
The sole requirement of this tutorial is Rational Software Architect Version 8.0 (or later) with the Deployment Modeling capabilities enabled.
Creating a topology
- Start Rational Software Architect.
- Create a new project by selecting File > New > Project.
- From the General category, select Project and then click Next.
- In the Project Name text field, enter
- Click Finish to create the new project.
Figure 1. Creating a project
Now that you have created the project, you will add a topology to it.
- Right-click on the project name in the Project Explorer and select New>Topology.
Figure 2. Adding a new topology to the project
- When the topology creation window opens (see Figure 3), select the Blank Topology in the Basic Topologies category.
- Name it
test_topology, and click Finish
Figure 3. The New Topology wizard
Rational Software Architect has different perspectives, and each one changes the way that information and tools are presented in order to make the working environment more aligned with the goal of the model being worked on.
- After creating a new topology, you will be given the choice to change to the Deployment perspective. Accept the offer by clicking OK.
You have now created a new topology (see Figure 4). You will see a Welcome note. It is a good idea to explore the topics suggested. For the purposes of this tutorial, though, close the Welcome note.
Figure 4. A blank topology
You are now ready to explore the topology editor.
Physical deployment topologies
Before addressing virtualized environments, you will start by modeling a simpler scenario: representing the deployment of an application into an operating system that is, in turn, installed on a specific server. Several important concepts that you need to understand later in this tutorial are built in this section.
You will use the following units to successfully model this scenario, all of them present in the palette that is, by default, on the right side of the screen, next to the diagram editor.
- LDAP Server: Found in the Middleware templates
- Power Server: Found in the Hardware templates
- x86 Server: Also found in the Hardware templates
- AIX 5L: Found in the Operating Systems templates
- Linux: Also found in the Operating Systems templates
Hosting an LDAP server in IBM AIX systems
- Drag LDAP Server into the diagram, and notice the warning icon in the bottom-left corner. (See Figure 5.)
Clicking it will display information about the error that was detected. When no errors are found, the icon turns into a blue icon with an i in it (lowercase letter i). If you click, it will display information, including optional actions that could be useful but aren't strictly required. This is very useful, though, and should be used constantly, because it provides real-time information concerning the consistency of the model, as well as being a huge time-saver, because the proposed actions are not only context-sensitive but take the surrounding environment into consideration.
Figure 5. Adding the LDAP server to the topology
- Click the warning icon. As Figure 6 indicates, the LDAP server needs to be hosted in an operating system.
Figure 6. Warning message about the LDAP server
- IBM® AIX 5L™ for POWER™ is a UNIX operating system, so add it to the diagram: drag the AIX 5L template into the diagram.
You now have a representation of an AIX deployment. If you look at the warning icon, you will notice that this unit also contains warnings. But focus on the LDAP Server for now and leave the AIX warnings for latter.
- Click the LDAP Server warning again, and this time, click the specific entry that it contains: "Unit ('LDAP Server') must be hosted (OperatingSystem)." One of the actions suggested is to host it on the no hostname unit, which is the AIX instance that you added but haven't properly named yet.
- Select that option by selecting that action in the lower pane and double-clicking it. This will host the LDAP Server unit in the AIX instance.
Figure 7. Using proposed actions
Notice that the warning has disappeared from the LDAP Server, which means that all mandatory requirements are now met. There is a hosting link between the LDAP Server and the AIX instance, as shown in Figure 8.
Figure 8. LDAP server hosted on an AIX instance
Different relationships have different links. Hosting is represented by an arrow with two parallel lines. Later in this tutorial, you will see how dependencies and membership relationships have different visual queues.
It's time for you to take a look at the AIX unit, which, as mentioned earlier, contained warnings.
- Click on the warning icon of that unit. A list of errors will appear (see Figure 9) that includes the need to set the hostname, the root password, and to host the operating system is a physical server.
Figure 9. AIX instance warnings
You will tackle the issues concerning the hostname and the root password first.
- Following the previously explained method of selecting each error and
choosing a proposed action, name the AIX host
gemini(by using the Set hostname action proposed for the "hostname" is undefined error), and set the root password to
123to address the userPassword is undefined error under the root user.
- Click the warning icon again will present a final error regarding the lack of host (Figure 10).
Figure 10. AIX hosting requirement warning
Adding physical servers
The AIX instance must be hosted on a server. To find out more about this requirement take a look, as noted above, in the Requirements tab in the Properties unit, which is at the bottom of the screen, by default.
Figure 11. Viewing the AIX unit requirements
The requirement specifies that AIX can be hosted in any unit with the server.Server capability, which includes x86 servers. This can seem strange, but upon further inspection you will note that there is one constraint for this requirement. Click on the Constraints tab in the Properties view.
Figure 12. AIX hosting constraint
The constraint specifies that the server hosting it must implement the PowerPC architecture. To test this drop two server units into the diagram: a Power Server and a x86 Server.
Figure 13. Adding servers
In Rational Software Architect there are several ways to perform the action so you will use a different method to host this unit. Place the pointer over the AIX unit. This will display a yellow arrow. Click on it and drag it to an empty space. A pop-up will appear asking the type of relationship we want to indicate. Choose Hosting link.
Figure 14. Using link discovery
Rational Software Architect will present a list of option that are compatible with the requirements. Since as you have seen before there is a mandatory requirement regarding the CPU architecture that can host an AIX instance only the Power Server unit appears on the list. Select it and click OK.
Figure 15. Hosting link matching
The AIX instance is now hosted and all warnings have disappeared from it, as shown in Figure 16. The Power Server doesn't have any requirements, so it never did display a warning.
Figure 16. AIX instance hosted on Power server
Hosting Linux in the x86 server
Follow the same procedure to add a Linux unit and another LDAP Server unit, host the Linux unit in the x86 server and the new LDAP Server in the Linux unit.
Figure 17. AIX and Linux final stacks
In terms of visual style you are seeing the units hosted outside of their host, with a hosting link indicating the relationship. Depending on the purpose it can be useful to have a more compact view. This is easily achievable via the Show Unit on Host toolbar options or by simply dragging the unit into the host. This also works to create a new hosting relationship should one not exist. Dragging the units outside has the reverse effect.
You can mix and match different visual arrangements inside the same diagram. This can be useful to give a different focus to particular components. Figure 18 shows the two different stacks arranged in different ways.
Figure 18. Different ways to view hosting relationships
Now that you have successfully experimented with physical deployments, it is time to see what changes when introducing virtualization options. The next sections give an overview of some of the possibilities.
Modeling virtualized topologies: x86 with VMware
The present version of Rational Software Architect doesn't specifically address PowerVM. It does, however, have a Virtualization palette category with dedicated units for VMware and Xen, plus z/VM. Given that you will later be using its simple but powerful unit customization facilities to model PowerVM deployments, it makes sense to first explore how virtualization is modeled in other hardware platforms that have explicit support in Rational Software Architect.
- Create a new topology by following the same steps as before, and name it virt_topology.
- Add an LDAP Server and a Linux operating system unit, and create a hosting link between them.
Note about these instructions:
For the rest of this tutorial some details that were already previously covered will be omitted.
Figure 19. Redoing the LDAP deployment
Adding the virtualization layer
- Rather than creating a server, as you did before, drag a VMwareESX unit from the Virtualization palette into the diagram.
Because VMware ESX is not implemented in firmware, it needs to be deployed in an x86 server, as indicated in the list of warnings for the unit. You can view the VMwareESX unit as representing the software that needs to be installed in order to provide a x86 server with an hypervisor that allows the virtualization of resources.
- Add a x86 server unit to the diagram and host the VMwareESX unit in it
Figure 20. VMware ESX hosted in an x86 server
At first glance, you could assume that this VMware ESX unit would directly host the several operating systems, but this unit doesn't have that capability. You can try it, though. If you try to create a hosting link between Linux and VMware ESX, a pop-up window will appear to allow you to create a new capability on the target. This is not what you want, but it is a useful feature to be aware of, especially for unit customization. The hypervisor doesn't directly host an operating system; it hosts a virtual image that represents the virtualized resources that can be used by a virtual server.
- Add a VMware Virtual Image to the diagram, and host it in the VMware ESX unit. For this tutorial the VMware ESX unit was given lupus as an hostname. The result should be similar to Figure 21.
Figure 21. Adding a virtual image
To better understand the concept behind virtual images, take a look at the list of Capabilities of the unit. Capabilities and requirements, with associated constraints, define most of what you need to know about any unit. Notice that it needs to be hosted on a server, as seen previously, and that it must have a member that is a server. At first, this can seen odd, because there isn't a warning sign in the unit. If you take a closer look at the Constraints tab, the lack of warning is clarified: the number of servers that must be a member of the unit is either one or zero.
It is important to note that this VMware Virtual Image unit doesn't specify operating systems as possible members, but servers, which will, in turn, host the operating system.
- Add a x86 server to the diagram and make it a member of the ESX unit by dragging and dropping this server into the VMware Virtual Image unit. Membership is always shown by displaying the member in the host. Figure 22 shows the topology up to this point.
Figure 22. Using a Virtual Image as a container
Modeling virtual resources
Before hosting the Linux unit in this virtual server, you will probably have noticed by now that clicking a unit also displays a small tool tip with icons, which are a sort of "quick add" entries that show what is most commonly hosted or grouped in that unit. Doing this in an x86 server shows a list of Microsoft Windows and Linux operating systems. In an IBM Power Server, it will show only AIX, and in AIX, it will display icons for users, groups, file systems, and so forth. In the VMware Virtual Image unit it will display these definitions:
- VMware Virtual SCSI Disk Definition: This represents the configuration of a virtual disk, as done by ESX, that is made available to the virtual image.
- VMware Virtual IDE Disk Definition: As above, but for an IDE disk.
- VMware Virtual Ethernet NIC Definition: represents a NIC that is made available to the virtual image
- VMware Virtual Server Snapshot: A snapshot configuration
As noted previously, these definitions represent the virtual resources that are made available to the virtual image, and thus, ultimately, to the hosted operating system. These units aren't required by the virtual image, and their use depends on the specific deployment being made and the level of detail that the topology will reflect.
Add a VMware SCSI Disk Definition and a VMware Virtual Ethernet NIC Definition to the diagram. The warnings and the Requirements indicate that they must be hosted in a VMware Virtual Server Definition, which is a capability that the existing VMware Virtual Image unit implement.
Figure 23. Adding virtual resources to an image
As you can see in Figure 23, there is an information icon in both the virtual image and the virtual NIC (hosting units always show warnings and information inherited from the units they host), which says that there is an optional requirement that isn't satisfied: the VMware Virtual NIC depends on a Layer 2 interface. Or, putting it another way: the Virtual Ethernet NIC must be backed by a physical one. This is a level of detail that falls outside of the scope of this tutorial. Please see the developerWorks article titled "Modeling virtual systems with the IBM Rational Software Architect deployment architecture tools," which is referenced in the Resources section.
You now have, in one end, an LDAP server hosted in a Linux instance, and on the other a x86 server that hosts VMware ESX, which in turn hosts a Virtual Image. This Virtual Image hosts two virtual resources (a disk and an Ethernet NIC) and has as a member a x86 server that represents the virtual ability to host operating systems.
Tying it together
You can now finally tie the two ends together and host the Linux instance in the x86 Server that is contained in the VMware Virtual Image. Set the hostname of the Linux instance if you haven't done so yet. All warnings disappear from the model and you should have something very similar to Figure 24.
Figure 24. Hosting Linux on the virtualized infrastructure
This sums up the main concepts behind modeling VMware virtualization deployments in Rational Software Architect, which are largely the same when using Xen instead of VMware.
The next section will show you one different approach in virtualization modeling.
Modeling virtualized topologies: System z and z/VM
You will now take a look at how virtualization is modeled in System z. The virtualization capabilities of System z were pioneering when they were introduced, and Rational Software Architect has explicit support for them. When talking about System z virtualization, it is important to note that there are several different ways to implement it, including these:
- LPAR: System z allows the creation of several LPARs, which are then managed, in terms of resources, by PR/SM.
- VM Guest: IBM® z/VM® is an operating system that has the ability to run other operating systems as guests (the typical z/VM environment uses CMS as an operating system), including another copy of z/VM.
In this section, you will deploy to a z/VM guest, because that's the most common choice when considering Linux on System z.
Creating the base topology
- Create a new topology named
systemz_topology, and recreate the LDAP server deployment in Linux:
- Add an LDAP server and a Linux operating system, and then create a hosting link between them.
- Set the root password and hostname for the Linux unit.
- Drop a System z Server from the Hardware palette category into the diagram. Clicking the warning indicator will show you that a System z server needs at least one LPAR.
- Add an LPAR, also found in the Hardware palette, to the diagram, and host it on the System Z server by creating a hosting link.
- Now add an IFL (Integrated Facility for Linux), which is a dedicated CPU for Linux, to the LPAR. You can easily perform this action by clicking in the LPAR unit.
- When a toolbar appears, select the icon that depicts a CPU with a penguin. The LPAR contains a warning (Figure 25), because an LPAR with an IFL must directly host either Linux or z/VM.
Figure 25. An LPAR with an IFL has specific requirements
- Click the warning icon and select the existing warning.
- Double-click the Host "ZVM" on LPAR "LPAR" action proposed.
Figure 25 shows the final result of the actions taken up to this point.
Figure 26. Hosting a z/VM instance
The IFL that was previously added to the LPAR shows an information icon, because an IFL can optionally be hosted in System z server.
- Click the information icon of the IFL, select the Unit (IFL) may be optionally hosted () entry, and double-click the Host "IFL" on "System z Server" action proposed. This relation represents the fact that the IFL is physically present in the System z server but attributed to the LPAR.
Notice the difference between the arrows that represent the relationship between the host and the contained unit. In the System z Server, the IFL is hosted; whereas, in the LPAR, the IFL is a member.
If you try to host the Linux instance in the created z/VM unit, it will not work. Just like in the VMware scenario, you need an intermediate layer that indicates that the operating system is running in a virtual image, not directly from the z/VM instance.
- Drag the z/VM guest unit from the Virtualization palette and into the diagram (or use the z/VM unit toolbar, as previously shown) and host it in the z/VM unit.
Dealing with hosting errors
You are now ready to host the Linux instance. Link the Linux unit to the z/VM Guest to create a hosting relationship.
Figure 27. Linux on z/VM hosting error
You will notice that, as in Figure 29, the hosting link has a warning. Clicking on it will reveal that the Linux unit you have been using can't be deployed to z/VM.
Figure 28. Hosting error details
There are several different ways to solve this, and some of them are provided by the warning dialog. The most direct approach is to use an appropriate template. Instead of Linux, which is x86 specific, use z/Linux, that can be found on the System z stack in the Operating Systems palette drawer.
One alternative that you will use in this tutorial, to show how units can be customized, involves removing constraints. Because Linux runs on pretty much everything (especially true if you consider the available CPU architectures in Rational Software Architect), you will just remove the constraint associated with the hosting requirement of the Linux unit. Select the Linux unit and go to the Requirements tab of the Properties unit. Select the Server requirement and, in the content area to the right, select the Constraints tab (Figure 29).
There is one constraint listed, cpuArchitecture = intel. Select and remove it by clicking on the red cross above it.
Figure 29. Removing a constraint
This immediately removes the warning and the model is error-free, as shown in Figure 30.
Figure 30. The final model without any warnings
This Linux unit you created is generic in terms of hardware hosting requirements. Another option would be to merely change the constraint to make it require a System z architecture, in which case we would have created a unit very similar to the standard z/Linux one. In the next sections we will see how this kind of customised units can be added to the palette.
Notice that with System z you didn't use any Virtual Disk or NIC definitions. In Rational Software Architect System z virtualization doesn't use them, but in turn there is fine-grained support for different CPUs (CP, IFL, ZiP, and so forth) and how they are hosted and used.
In the next sections you will start developing you own virtualization approach.
Adding PowerVM hosting capabilities
Now that you have seen how virtualization in modeled in System z and x86 you will finally start working on the primary objective of this tutorial: being able to model virtualization scenarios that include PowerVM.
There is one way that already works: since the Power Server doesn't enforce any constraint regarding the number of operating systems that it directly hosts you could just add a number of AIX units to a single Power Server. If you use the customized Linux unit that you changed to allow deployment in System z you can also use it in the same way. This possibility could be seen as inherent support for the built-in PowerVM hypervisor in Power servers, but if you try to do the same with a x86 server, which doesn't have an integrated hypervisor, the same lack of constraint exists.
Figure 31. Directly hosting multiple operating systems
This way of doing things can actually be useful if your goal is to produce a quick diagram (as in Figure 31), more than an actual model that ensures consistency and checks for capabilities and requirements. For that you will need to implement some sort of support for PowerVM, modeled after what already exists for x86 and System z. In this tutorial you will use concepts from both:
- You will initially not use Virtual NIC and Disk definitions, so here you will follow the System z model.
- You will use a Virtual Image, which is closer aligned with the VMware example.
Creating the initial topology
Create a new topology named powervm_topology and add the base stack: an LDAP server, an AIX instance and a Power server just like you did in the section about modeling physical deployments. You will only host the LDAP server in the AIX instance this time since you will need to do some changes first before deploying the AIX unit. Figure 32 shows the topology up to this point.
Figure 32. Initial topology
Customizing existing units
Take a look at the Virtualization palette category. Notice that there are "container" units for VMware, Xen, and z/VM, and they are fully realized (they have both a conceptual unit and a concrete unit that realizes the conceptual one). There is also a generic-looking section that is mostly just conceptual and doesn't mention any specific technology. This is what you will use. These templates (Figure 33) use the base, technology-independent units and capabilities. This makes them ideal building blocks for the goal of creating PowerVM-specific units.
Figure 33. The Virtualization templates palette
- Drag and drop a conceptualVirtual Image into the diagram. Notice that what would be warnings in a concrete unit are presented as information in a conceptual one.
- Now look at the Requirements of this conceptual unit. This unit can have a server as a member (and only one, as can be seen by the constraint), and can optionally host any number of units, of any kind. More relevant though is the hosting requirement: it needs a (generic) hypervisor.
Figure 34. Virtual Image requirements
In terms of the Capabilities, you can see that this unit implements a Virtual Image and a Virtual Server Definition. The names of the capabilities are sometimes linked with information that hasn't yet been provided, which is why the first capability appears as no imageId. Looking at the Type: information shows the capabilities that are referenced, as Figure 35 shows.
Figure 35. Virtual Image capabilities
Your next step will be to create a concrete unit that can be used to model PowerVM LPARs.
- Deselect the Conceptual check mark from the Virtual Image
Properties in the General tab, and add a Stereotype named
PowerVM LPAR. This stereotype will allow you to quickly see that this concrete unit is a specific kind of Virtual Image.
Figure 36. Adding stereotypes
- Now, make the following changes:
- Delete the AnyMember requirement. Not removing it would not make much of a difference but it will make our unit more in line with the other specialized virtual images.
- Change the Image id to PowerVM LPAR. The Image id field is also in the Capabilities tab.
- Select the field named no imageId and change the appropriate field in the content area to the right.
- To make this unit reusable, you will now add it to the palette:
- Right-click the unit and select Add to Palette.
- Give it a name (
PowerVM LPAR) and an icon
(Figure 37) shows that the System z LPAR icon was selected), and you will find a new entry in the Local Extensions palette category.
Figure 37. Adding a custom unit to the palette
Your next step is to host the new PowerVM LPAR unit in the Power Server, but if you try to you will not be allowed. This is because the LPAR unit needs to be hosted in a server with an hypervisor and by default the Power Server unit in Rational Software Architect doesn't have one. In other words, the PowerVM LPAR has a hosting requirement of type virtualization.Hypervisor, and the Power Server unit does not provide this capability.
To fix this create you will need to create another custom unit: a Power Server with a hypervisor capabilities. You could alternatively create a PowerVM unit to be deployed in a Power Server unit, like the VMware ESX scenario, but the option of adding hypervisor functionality directly in the server reflects the fact that in Power Systems the hypervisor is not an independent software product.
- Select the Power Server unit, go to the Capabilities tab, click the Add Capability... icon. In the pop-up window that appeared choose Virtualization.Hypervisor (Figure 38).
Figure 38. Adding hypervisor capability
- You should also add a PowerVM Server stereotype. The designation isn't strictly correct, but it is short enough to be useful for the purpose of this tutorial. Add this server to the palette by following the same steps as above. Figure 39 shows the workspace after these modifications.
You can now host the PowerVM LPAR in the PowerVM Server.
Figure 39. Hosting the LPAR in the PowerVM server
Finishing the topology
Your next step is to drop a Power Server into the diagram and make it a member of the PowerVM LPAR. This server will be the one hosting your AIX instance. This concept is the same as the one previously explained and allows for a much easier way to model transformation scenarios, because existing physical servers can be wrapped inside an LPAR.
- Create a hosting link between the AIX unit and this Power Server.
The topology, shown in Figure 40, is now complete and without any warnings
Figure 40. Final topology with all hosting links in place
The concepts used are similar to the x86 and System z examples, namely in the use of three separate layers:
- A physical server that will host the different images (the PowerVM Server)
- A virtual image that represents the partitioning ability of the host (the PowerVM LPAR)
- A virtual server that is a member of the virtual image and provides hosting capabilities (the Power Server inside the LPAR)
The work done in this section is sufficient to model the core aspects of virtualization with PowerVM. The next section will add the ability to model more detail, namely virtual resources, such as disks and Ethernet cards.
Virtual resources and PowerVM
The work that you have done so far already provides a functional way to model PowerVM deployments. In this section, you will go a step further and implement some of the behavior present in the VMware scenario, namely virtual disks and NICs that represent the virtual devices configured in the HMC to be used by the operating system in the LPAR.
There are two important points that you need to take into consideration:
- Using generic units as a starting point for new units is extremely flexible, quick, and easy to manage, but there is only so much that can be done. In particular, you can use only existing capabilities. (Rational Software Architect offers ways to create new units and domains, but that it beyond the scope of this tutorial.) You could use this approach, for example, to add a Virtualization.PowerVMHypervisor capability that would be more tailored to your needs. For more information, see the developerWorks article Extending the topology editor with custom technology domains referenced in the Resources
- One of the best points of Rational Software Architect is the support for model-driven development. This means that in many cases there is built-in support for turning diagrams into real configurations that can be deployed, much in the same way that it creates Java header files from UML diagrams. Our customizations are merely aimed at providing a coherent model and do not support advanced functionality, such as automatic creation of HMC configuration files that would configure a server according to our model.
You will use the same general approach as in the previous section: take a generic conceptual unit and customize it to your needs. You will need to use these two definitions:
- The conceptual Virtual Disk definition
- The conceptual Virtual Ethernet NIC definition
- Using the same topology as the previous section, add a conceptual Virtual Disk Definition to the diagram, and deselect the Conceptual check mark, as before. The result is a generic virtual disk that can be hosted in a virtual image.
- Now, add a stereotype named PowerVM Virtual Disk Def to the unit.
As it is right now, this PowerVM virtual disk would happily allow a hosting relationship with, for example, a VMware virtual image. You want to limit to the unit to a specific kind of virtual image so that this newly created PowerVM Virtual Disk Definition will be hosted only by your custom-made PowerVM LPAR.
As mentioned previously, Rational Software Architect offers ways to add entire new capabilities and domains. For the purposes of this tutorial, though, a simpler approach is sufficient, and one possibility is using stereotypes.
- Select the Virtual Disk Definition that you just customized, and go to the Requirements tab.
- Select the HostingReq requirement, and go to the Constraints tab.
- To add the constraint, click the green plus sign in the constraints editor, and select Stereotype from the pop-up window.
- In the dialog window that appears, type
PowerVM LPARin both the Caption and Includes fields.
- Click Close when you are finished.
Figure 41 shows the constraint added.
Figure 41. Adding hosting constraints to the virtual disk
- Now, try to host you virtual disk in the PowerVM LPAR.
You'll find that the hosting link displays an error (see Figure 42). The warning tells you that the constraint failed because the PowerVM LPAR Virtual Server definition doesn't have the appropriate stereotype.
Figure 42. Virtual disk hosting error
The reason that this happened is because the constraint that you specified was not made in relation to the stereotype of the hosting unit but, instead, to the stereotype of a specific capability present in the hosting unit, namely virtualization.VirtualServerDef.
- Using the action proposed by the error resolution dialog, add the stereotype to the Virtual Server Definition capability in the PowerVM LPAR unit. (See Figure 43.)
Figure 43. Adding a stereotype to satisfy hosting requirements
- Repeat the process with a conceptual Virtual Ethernet NIC Definition.
The result, shown in Figure 44, will be quite similar to the VMware topology.
Figure 44. Final topology with virtual devices
With the addition of virtual devices, the PowerVM virtualization possibilities that you have built during the course of this tutorial are already complete. The next section adds a final touch that could be useful.
Requiring an HMC
As a final exercise, you will make the PowerVM Server require a Hardware Management Console (HMC). Although there are situations where a HMC isn't strictly needed, such as with a standalone server or server with an IVM, in practice and for our purposes here, consider an HMC a requirement.
- Using the same topology as before, you will start by creating an HMC. The Hardware Management Console is an x86 server with a customized version of Linux. By now, you already know how to model this by using an x86 Server unit and a Linux unit.
- Add an HMC stereotype to the x86 Server.
- To make things a bit more interesting, change the appearance of the unit to make it stand out. You can do that by using the Appearance properties tab and selecting a different appearance from the list.
Figure 45 shows the HMC in tones of green.
Figure 45. Adding an HMC
You can add this stack composed of the server and the OS to the palette if you wish. The palette can contain templates composed of several units and relationships.
You need to make the PowerVM Server depend on at least one HMC. This means that you need to create a mandatory dependency requirement on the PowerVM Server unit.
- In the Requirements tab of the PowerVM Server unit, click the Add Requirement icon positioned above the requirements editor.
Needs HMCas the value of the Caption, set the Link type to dependency, and set the Type to server.X86Server.
Figure 46 shows the requirement added.
Figure 46. Adding the requirement to the PowerVM unit
- This requirement is set on server.X86Server, which is not specific enough. Therefore, add a constraint to the Needs HMC requirement to the HMC stereotype.
Figure 47. Adding a constraint
If you try to create a dependency link between the Power VM Server and the HMC, a pop-up window will appear showing the matching between requirements and capabilities. As can you can see in Figure 48, there is no 100% match between the requirement that you specified and the capabilities of the HMC unit. The reason is the same as in the previous sections: the dependency is enforced based on the stereotypes of the capability, not the unit itself.
Figure 48. Matching requirements and capabilities
You need to add the HMC stereotype to the server.X86Server capability of the HMC.
- Go to the HMC unit Capabilities tab, select the x86 Server capability, and add an HMC stereotype.
Figure 49. Adding the stereotype to the server capability
- This time, use the PowerVM Server warning icon to create the dependency link. Click the warning icon of that unit.
- When the warnings pop-up window appears, as seen in Figure 50, double-click the proposed action to create a dependency link to the x86 Server unit.
Figure 50. Creating the dependency link
Your model is now error-free.
Figure 51 shows the topology in its final state. You took it through several stages, each one building on the previous. Now you can use it for modeling not only LPARs but also virtual devices and HMC requirements.
Figure 51. The final topology
This concludes this tutorial. You now have custom units in your local palette that can be used to good effect in modeling PowerVM deployments. Above all, you should feel more comfortable in customizing Rational Software Architect standard units to adapt them to a wider range of scenarios.
There is plenty more that could be done in terms of PowerVM deployment, for example:
- Require more than one HMC for availability purposes
- Create completely new domains and capabilities
- Implement something to model Virtual I/O servers
- Learn how to model something akin to the System z CPU allocation model
In this tutorial, we barely touched the surface of what you can do with the deployment modeling features. Exploring some of the link types, for example, reveals numerous possibilities regarding collocation rules and capacity planning.
Rational Software Architect deployment topologies are both simple to use and to customize, yet very clear and intuitive to use, too. The Help system contains examples and tutorials that help you understand all of the potential uses. Explore the Resources section here to start learning more.
|RSA project file for this tutorial||rsa_powervm.zip||22KB|
- Read these related articles:
- Modeling virtual systems with the IBM Rational Software Architect deployment architecture tools (developerWorks, June 2010), which discusses the use of the deployment architecture tools in IBM Rational Software Architect 7.5 in modeling virtual systems.
- Extending the topology editor with custom technology domains developerWorks, July 2010), which demonstrates how to create custom units and capabilities that you can use to model the components of any area of information technology by using the Topology Domain Generation Toolkit.
- Check the Rational Software Architect Standard Edition overview, Information Center, and developerWorks page to explore the full range of capabilities.
- Get more details about IBM PowerVM, the virtualization platform for UNIX, Linux, and IBM® i clients
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Stay current with developerWorks technical events and webcasts focused on a variety of IBM products and IT industry topics.
- Improve your skills. Check the Rational training and certification catalog, which includes many types of courses on a wide range of topics. You can take some of them anywhere, any time, and many of the "Getting Started" ones are free.
Get products and technologies
- Evaluate Rational Software Architect by downloading a fully functional trial with an evaluation period of 30 days.
- Evaluate IBM software in the way that suits you best: Download it for a trial, try it online, use it in a cloud environment, or spend a few hours in the SOA Sandbox learning how to implement service-oriented architecture efficiently.
- Join the discussion in the Rational Development Tools forum.
- Share your knowledge and help others who use Rational software by writing a developerWorks article. You'll get worldwide exposure, RSS syndication, a byline and a bio, and the benefit of professional editing and production on the developerWorks Rational website.
- Follow Rational software on Facebook and Twitter (@ibmrational), and add your comments and requests.
- Ask and answer questions and increase your expertise when you get involved in the Rational forums, cafés, and wikis.
- Connect with others who share your interests by joining the developerWorks community and responding to the developer-driven blogs.