The OPTIMIS Toolkit

The contextualization research is performed in the context of the OPTIMIS Toolkit [74], a set of software components aimed to simplify and optimize the construction, deploy- ment, and operation of services (at the SaaS and PaaS level) as well as the operation of virtualised hardware needed to deliver these services (IaaS level). Although OPTI- MIS targets scenarios and capabilities somewhat different to the ones provided by current PaaS and IaaS providers, the OPTIMIS contextualization requirements are general and the solution should be applicable in a wide range of Cloud providers. The research on contextualization is presented in light of OPTIMIS Toolkit and project to facilitate the readers understanding but it should be clarified that it is purely the work of the thesis author.

The two beneficiaries of the OPTIMIS Toolkit are Infrastructure Providers (IP) who operate the infrastructure resources (IaaS level) required to provision services and Service Providers (SP) who deliver these services to end users by combining the PaaS and SaaS roles. An OPTIMIS service is functionally accessible by end users over a network. A service is also virtualised such that it is provisioned by means of VMs and elastic in the sense that the number of VMs it uses can vary over time. In overview, the service lifecycle has three steps:

1. Construction where the SP constructs the service (by implementation, orchestration of existing services, and/or use of licence-protected legacy software) and packages it as a set of VM images described in a service manifest.

2. Deployment where the SP initiates the provisioning of the service in an IP.

3. Operation where the IP manages the VMs and related infrastructure resources whereas the SP monitors and controls the application level aspects of the service.

The OPTIMIS Toolkit is a set of stand-alone components that can be adopted and con- figured to support a range of Cloud deployment models. The targeted scenarios include: private Clouds where SP and IP are combined, Cloud bursting, where private Clouds utilize external IPs; Cloud federation, i.e., collaboration between IPs; Multi-Cloud de- ployment, where an SP interact with more than one IP; and brokering, a variant of the latter where a third-party broker mediates between SPs and IPs.

The simplest scenario is a Private Cloud, where the SP and IP are within the same or- ganization and cooperate to provision resources for services using an internal infrastruc- ture. In Cloud bursting scenarios, the IP of a private Cloud manages peaks in demand for

a service by deploying additional VMs in another IP. Another possible deployment model is a Federated Cloud, where an IP provides resources for an SP on behalf and across a col- lective of IPs working in collaboration, while being the single point of interaction for the SP. In contrast, in a Multi-Cloud deployment scenario, an SP directly negotiates with and deploys part of a service across multiple IPs but no collaboration occurs between these. An additional scenario is Cloud Brokerage, where a third-party broker acts as an interme- diary between SPs and IPs, potentially also providing added value through its knowledge base.

In addition to support for multiple deployment scenarios, one notable feature, com- mon for all toolkit components, is self-management capabilities (for services, VMs, data, SLA protection etc.). These self-management decisions are made not only with performance- related criteria but also include non-functional aspects. All resource management actions are taken by balancing performance against TREC, namely trust (in the IPs and SPs based on previous experiences), risk (of resource and service failure, SLA violations, etc.), eco- logical aspects such as energy-efficiency and compliance to green legislations, as well as the cost of provisioning services and VMs. To manage the complexity of this multi- objective service provisioning challenge, the OPTIMIS Toolkit has a modular and layered architecture with a Basic Toolkit that provides monitoring and assessment engines for the TREC factors and security capabilities. On top of that, a set of SP Tools handles e.g., deployment of services, data transfers, and software licenses, whereas IP Tools provides basic functionality for infrastructure management, e.g., admission control, management of VMs and data, fault tolerance, and autonomic elasticity control. A in-depth description of the OPTIMIS Toolkit and the motivations for it is beyond the scope of this research and can be found in [74]. Figure 6.1 shows the tools that make up the OPTIMIS toolkit.

Figure 6.1. Componets of the OPTIMIS Toolkit architecture.

Deployment Optimizer (SDO) in the SP and the Cloud Optimizer (CO) in the IP. The role of the SDO is to coordinate the service deployment process. Based on the service description in a manifest, including VM images and deployment constraints, the SDO identifies suitable IPs, assesses the Trust, Risk, Eco-efficiency and Cost (TREC) factors related to the service, filters out unsuitable deployment targets, and negotiates terms of use with suitable ones. After selecting the best IP(s), the SDO contextualizes the VM images prior to deployment. Finally, the contextualized VM images are uploaded to the selected IP and the service is started.

The CO has a similar coordination role in the IP as it handles all VM launching re- quests. New VMs can be started upon deployment of a new service, restarted as part of fault recovery, or booted due to elasticity, i.e., service scale up caused by increasing workload. For each VM launch request, the CO initially decides whether the VM should run in the local infrastructure of the IP or outsource to an external provider (bursting or federation). In the latter case, the SDO functionality for selection of partnering IPs and deployment negotiation is reused. Notably, as VM images boot, they can, thanks to the preparatory steps performed by the SDO, contextualize themselves without synchronizing with any component external to the service, in the SP or elsewhere.

The OPTIMIS service lifecycle management and support for many Cloud deployment models, highlight the need to address the three main contextualization challenges previ- ously discussed. The first, contextualization support as part of a PaaS tool used during service deployment (as opposed to SaaS solutions for service development). The second, contextualization that supports service deployment across multiple IaaS providers and finally support in contextualization for functional aspects such as secure cross-domain networking and use of license protected software. The following is a list of OPTIMIS specific contextualization requirements:

• The VMs of a service need to be able to communicate with each other seamlessly. The different Cloud deployment models supported complicate this, as VMs may be spread across multiple IPs, i.e., several network domains.

• A service must be able to make use of license protected software packaged inside VMs. There is hence a need for a mechanism to propagate software license creden- tials.

• Services are elastic, it must be possible to launch multiple running VM instances from a single VM image.

same time. The exact number of VMs used by a service varies dynamically during operation and is not know in advance.

• Similarly, due to the different Cloud deployment models supported, it is not known a priori in which network, or even which IP, the VMs of a service are hosted.

• The incorporation of license tokens in VMs and need for cross-domain service net- working raise several security concerns. To summarize these, contextualization mechanisms must be designed in a manner that does not expose assets such as ser- vices, the networks connecting them, and software licenses to exploitation.

• Security information (keys etc.) needed for the establishment of a VPN overlay should not be stored in the VM image nor found on uninstantiated VMs.

There are several problems to solve regarding contextualization of OPTIMIS system level components, such as those associated with license management and Cloud security. The following subsections outline these issues in more detail: