Modeling Virtualization

A first attempt to enable virtualization modeling has been initiated in the MEGA 2007 release. The objective was to enable the identification of virtual servers and the application “generating” such servers. So, an association has been added that links applications to servers (instance of the metaclass Server). This link can be drawn in a technical infrastructure diagram and so belong to the technical infrastructure metamodel introduced prior to the 2009 SP2 release.

The link was sufficient to express facts such as: “the VMWare application creates this virtual server”. Servers linked to an application can be identified as virtual servers since they are generated by a virtual machine application. Since the virtual server is a server regarding the type, it can be used as any other servers to host applications.

This principle has not been reintroduced in the metamodel proposed from the 2009 SP2 release for several reasons:

- The simple link between applications and servers is not enough to model all virtualization configurations. Depending on the context, virtualization can be handled by an application, an operating system, a dedicated server and even a cluster of servers. In these cases, numerous associations should be necessary and even an intermediate object to group the potential virtual server generators.

- The new infrastructure metamodel is not defined at the same level. Servers are not described as instances of a dedicated metaclass but as artifacts inheriting from a reference Server artifact. This new design principle induces that a link between artifacts is available for any artifact even if virtualization has no meaning for some of them.

So, the question now is how to model virtualization based on the Artifact metamodel? Two facts are relevant in such modeling:

To model the first topic, one way consists of starting from an existing artifact. The MEGA Architecture add-on contains some artifacts that can be used as starting points. Among them there is the Server artifact. From the 2009 SP3 release, the add-on contains also a Virtual Server artifact that inherits from the Server artifact. Every new virtual server is then a new artifact inheriting from the Virtual Server artifact. The variation mechanism can be used to created a family of virtual servers and so refine their definitions.

This first step allows the identification of the virtual server. Once created, they can be retrieved using a query on variable objects (or more precisely on artifacts). Such a query, named “Variants of an Object”, is supplied from the MEGA 2009 SP3 release. The query looks like:

Select [Variable Object] Where [Variant Side Variation].[Varied Object] Deeply = &"Variant"

Processing the query will ask the user for a variable object. Then the Virtual Server artifact is selected and the query lists all the virtual servers in the repository. If a more specialized virtual server is selected, the query lists the corresponding subset of virtual servers.

The same identification principle can be applied to any artifact. Indeed, the virtualization technique is available for servers but also for more complex architectures. For example, a virtual network can be created or a complete virtual architecture including a network and a set of servers. For these two examples, a Virtual Network artifact is designed as a starting point for all virtual servers while a Virtual Architecture instance of the Resource Architecture concept matches the starting point of all virtual architecture items. Then, variants of the virtual architecture are described with their own components.

Another way to identify virtual servers is simply by the addition of a customer property on the Server artifact. For example, the property type can be named Virtual and the available values for this property can be yes or no.

The advantage of this simple proposal is that the type can be reused for different artifacts (server, network …) or resource architecture. The research of virtual servers is deduced from the previous query but adding the property value condition. Such a query looks like:

Select [Artifact] Where ([Variant Side Variation].[Varied Object] Deeply Like "Server") And
([owned property].(([Property Value]="yes") And
([Property Type].ShortName Like "Virtual")))

There are at least two drawbacks with this proposal:

- The query to search for virtual item is more complicated and the ERQL request written above does not manage all the possible cases. Indeed, since the property values can be inherited from varied ancestors, the value is not always connected directly to the artifact. In consequence the query must be updated to take this inheritance into account. This is not the purpose of this article to expose how to go through inherited properties but the fact is some code must be used instead of the ERQL syntax to perform a complete search (vb script, javascript or java code, refer to the MEGA API).

- The second point is that the proposal does not allow the definition of taxonomy of virtual servers has the variation does and then to simply ask for servers, virtual servers, hardware virtual servers... Instead, each sub-family should be implemented thanks to additional properties making the search tool again more complex.

For the reasons exposed here, the use of a dedicated artifact is recommended compared with a solution based on properties.

Whatever the way the virtual servers are created, they result to some artifacts that can be used in any solution architecture or embedding artifacts describing what are the environments letting the virtual servers available. The common example is some virtual servers hosted by a physical server. An approach can be described by the following steps:

4. Establish the links between the virtual servers to explain how they interact - if they do so - in the context of the physical server. Such links can be communication channels with communication protocols.

5. Detail the applications that the physical server hosts. Among these applications there is probably some virtualization tools (e.g. VMWare). At this point, if the virtualizing tool is considered as a platform technology it is more appropriate to model it based on an artifact as are operating systems. One can create the corresponding application later and insert it in the platform technology as an Application Host.

In the example above, two servers are available for the end user: VS 1 and VS 2. They are both virtual servers hosting business application (e.g. Invoice). The infrastructure supporting the end-user servers is composed of a physical server Server XYZ that generates the virtual server and hosts an instance of the VMWare application. The implementation of such design in the MEGA 2009 SP3 Release is based on the Artifact Assembly Diagrams. These diagrams are very simple from a graphical representation perspective and look like the following:

The principle exposed here can be replicated to any virtual structure. A complex virtual architecture composed of a network, n servers and some hosted applications is described the same way: the physical server contains all the virtual items including the network, the virtual servers and the applications that are all artifacts or applications.