The architectural model should have a formalised representation of the previous description on how the elements in the model will be dealt with. Thus, a first step towards a valid data model is to have a clear view of the entities in the system and how they are related to each other. The main two elements in the system are, therefore, the resources that need to be deployed or configured at each level and the relationships, links among them.
The basic abstractions included in these data models are the network, the compute and the storage resources (children of the resource class).These elements are, in turn, related to each other by the relationships illustrated in Figure 3.2.
Figure 3.2: A Simple Data Model.
There are various data models and related APIs trying to make their way in the standardisation process of different organisations. Open Cloud Computing Interface (OCCI) is one such standard to-be that is implemented by OpenNebula [6, 7]. OpenStack’s network API is another example,
but in this case the product of an open source development process. OpenStack’s network API and OpenNebula’s OCCI both use a simplistic network scenario, using a single network or VLAN networking without routing or bridging (two networks cannot be directly linked/bridged together; a compute resource is needed for them to be bridged). More recent proposals (including future design proposals for OpenStack) start to analyse more sophisticated data models to go beyond some of the limitations present in currently available specifications and APIs [8, 9].
However, all employ network types that are used to represent a network element in the context of a (logical) data centre. This is well enough if the focus of the model is end-user oriented (as in providing a descriptive language such as Virtual private eXecution infrastructure Description Language (VXDL)[8] to allow users to describe their need for specific constraints, rather than expressing the way their need will be instantiated on an actual network of resources). An operator- oriented model might require to deal with the peculiarities of the data centre to network operator or network operator to network operator borders beyond Border Gateway Protocol (BGP) and the like. There is not a means to deal with both, users and operators (data centre and network) peculiarities at same time.
In the following section we will show how more sophisticated mechanisms are needed in order to achieve a fully functional federation of heterogeneous infrastructures (not just data centres). This federation should be capable of preserving infrastructure operational independence (e.g. techno- logical heterogeneity and hidden management mechanisms), while coping with highly abstract user requests to meet a series of application performance, quality of service, cost, etc. goals.
3.2.1 A Possible Embodiment of the Data Model
The first ingredient for understanding how the data model is going to be treated and refined in SAIL is having a high level view of the resources involved in the application. The reader is advised this is just an introductory data model that will be further refined in later sections. A detailed specification of the data model is beyond the purpose of this architectural document. The two major components of this model are the Resources (mainly network, compute and storage resources) and the Relationships among them, also referred to as links in some available data models for describing virtual infrastructures (e.g. OVF’s, OCCI’s) and topologies (e.g. NDL’s), or both such as VXDL’s. Figure 3.3 shows these two major elements and how the rest of the elements in the description are organized around them. For instance, VXDL’s and OCCI’s data models are totally compatible in the sense that network, compute and storage (the main entities in OCCI’s) can be considered as children of the VXDL’s resource. OCCI’s links are directly translatable into VXDL links and, therefore, both model seem to be highly compatible. More detailed research on the appropriateness of any of the available languages is beyond the scope of this document.
The point here is that all the available models can be viewed as a graph of connected resources whose attributes and completeness is going to be refined in the delegation chain described above. The model is the portrayer of user’s goals.
3.2.2 Unique Universal Naming in a Distributed Cloud
Being able to delegate a request and let other providers materialize it implies two major things: there is a trust chain across providers; and this trust is maintained even though providers intendedly hide the complexities of their operation (see below) to the users of the services they expose. While the former is highly static and typically done on the basis of written and formal negotiation with different providers, the latter is highly dynamic and needs to be resolved at runtime.
Resolving this naming of entities across federated clouds was easily solved in previous approaches by having a central naming entity (e.g. [10]). A site identifier was followed by the user account and the specific name the user wanted to expose for that given requests. That was the root name for
Figure 3.3: Example of Elements Considered in a Virtual Infrastructure + Virtual Topology De-
scription Data Model. Taken from http://vxdlforum.org
a request. After that, the name of a given resource could be obtained by appending new branches of the tree as needed (e.g. vms/vm1/cpus/cpu1/ etc.). However, the delegation model herein proposed conveys the federation of resources across non-coordinated domains and service providers and no single entry point for end user requests. Moreover, the presence of virtual infrastructure service providers and the fact that a given virtual infrastructure provider can be, in turn, relying on another virtual infrastructure provider makes naming a bit trickier.
The three most straightforward approaches to distributed naming are, arguably, encapsulation or mapping (see Figure 3.4 for details):
• Encapsulation implies appending length-fixed identifiers and directing the request to the
appropriate entity (which is supposed to be capable of understanding and handling it).
• Mapping involves letting service user specify their own names while mapping them locally
to unique internal names. This can be done by every player involved in the trust/delegation chain.
• Universally Unique Identifier (UUID) for naming mechanisms. This does not guarantee col-
lisions will not take place, but given the nature of UUIDs their probability of occurrence is kept reasonably low.
Figure 3.4: Two Possible Approaches for Distributed and Uncoordinated Naming.