OpenNebula: Components

OpenStack has some main components: Interfaces & API, Groups and Users, Networking, Storage, Hosts and Clusters.

  • Interfaces & API. The two main interfaces for interaction with OpenNebula are the Command Line Interface (CLI) and the Graphical User Interface (GUI). The Graphical User Interface is also known as “Sunstone”. OpenNebula offers different APIs for Developers to extend the functionality or built on top of OpenNebula. These APIs are currently available as Amazon Web Services (AWS) APIs and OCCI Implementation.
  • Groups and Users. OpenNebula allows different groups and users. It is also possible to integrate with different services such as LDAP and Microsoft’s Active Directory. Multi-tenancy is possible by default, which eases billing and accounting. OpenNebula comes with the following standard users: administrators, regular users, public users and service users. Administrators are in charge of administrative tasks within OpenNebula, regular users can use the functionality of OpenNebula in the self-service Portal. Public users are restricted users that may only use a subset of the functionality and service users are users that can use the APIs or Interfaces in OpenNebula.
  • Networking. The Networking interface in OpenNebula is fully extensible, which allows almost any integration in existing data centers. There is also support for VLAN and Open vSwitch.
  • Storage. OpenNebula supports different storage systems such as the file system storage, distributed network storage or block storage.
  • Hosts. OpenNebula supports the following hypervisors: Xen, KVM and VMware on the host. A host has three main components: the host management, the cluster management and the host-monitoring component. The host management is implemented by the “onehost” and allows common operations on hosts such as initial setup or the machine lifecycle management. The cluster management allows placing a host in a specific cluster. This is implemented by the “onecluster” command. Host monitoring is done with the information driver (IM). Monitoring allows administrators to gather information about the health of a host.
  • Clusters. Clusters are a pool of hosts that share networking and data stores. A Cluster can be compared to a zone. Clusters are typically fulfilling different needs such as the production/testing differences.

OpenNebula allows the grouping of different Hosts into a virtual data center (VDC) within a cluster. Different Hosts can also be grouped into zones that allow better administration for similar hosts.
Header Image Copyright by European Southern Observatory

Self service IT Requirements: resource and process automation

A critical characteristic of self Service IT is the fact that users can utilize applications and instances. This characteristic leads to a higher demand for automation and integration of resources and processes. As described earlier, user interfaces should be easy to use and this can be achieved by taking away complexity from the end user. In any case, complexity for self Service IT Platforms should be at a very low level as this will lead to confusion of users.
Let us once again look at the process of creating a new website. The Marketing Department decides to create a campaign for a new product. This campaign needs a website promoting the product, which should be run on WordPress. The marketing department should have a link in their platform where they can create new instances. After clicking this link, they can create a new domain by buying one from the domain registrar. Most domain registrars allow automation of this task as well (Namecheap.com, 2012). Next, the user would configure what type of website it would be – in our case a marketing website. The user would select the template and in the last step configure elasticity by setting the maximum number of concurrent customers on the website. The process for the user takes some minutes and the instance gets launched immediately. Domain registration and assignment is done via API calls. This can significantly reduce the time-to-market. In the background, some tasks are handled:

  • A virtual Instance with mySQL is launched. This instance is the database Backend for the Website. Since it is about elasticity, the Database has to be in a separate instance as we might have more Web-Frontends. Provisioning the Database on the Webfrontend will remove any scaling possibility, since Data won’t be consistent over different servers once updates to the content are done. Furthermore, this approach allows easier scaling since the database itself can also be scaled out if there are serious performance issues.
  • A virtual Instance with WordPress is launched. This instance serves as the webfrontend for the new Website. No single data is stored on this instance as this instance will be cloned when the load increases. This instance is also connected to a Load Balancer. The instance will run a LAP-Stack (Linux, Apache, PHP) to execute WordPress.
  • The Content Delivery Network is configured. To improove the website’s performance, content of the Website such as Videos and Images are not delivered by the instances themselfs but rather via a powerful content delivery network. This might be outsourced to popular providers such as Akamai.
  • The Domain is registered with the domain registrar. Some Domain registrars provide the possibility to register domains via API Calls. When marketing launches a new instance, they also enter a Domain. As soon as they found a suiteable domain name, the task of registration is automated and once the domain is available (registration might take some hours) it is assigned to the new website instance(s).
  • WordPress Services and Plugins are installed and configured. The WordPress services are configured and plugins are installed. Plugins like social Media integration are added automatically to the Platform.

As with Cloud Computing, resource and process automation sees different complexity based on the delivery model (SaaS, PaaS, IaaS). In case of IaaS, the self Service Platform would only provide virtual instances. The instances can be delivered with different configurations such as Web Servers. Key consumers of IaaS self Service Platforms are departments that require virtual Servers e.g. for Compute purposes. The complexity of automation is rather low since the only thing that are delivered to the consumers are virtual instances. The platform could provide some sort of scaling features but it is not explicitly available in IaaS environments. The next platform Level, Platform as a Service (PaaS) is aimed at development departments within the enterprise. A department could order or develop a new Software for internal or external use. The platform should provide deployment automation and automated scaling, which lowers deployment effort. Software as a Service has the highest level of automation complexity. Typically, when Software is deployed (either via the IaaS or PaaS model) a lot of configuration is necessary. As with our former example (WordPress installation for the Marketing department) a lot of steps are involved. The WordPress example is seen as SaaS by the marketing department but as IaaS by the IT department. Table 1: automation Complexity by delivery type outlines the complexity as seen by resource and process automation.

Platform Automation Complexity
SaaS Very High
PaaS High
IaaS Low

No self service for IT?

No self service for IT?


Image Copyright by L.C. Nøttaasen
 

OpenNebula: Overview

This post is part of the Open Source Cloud Computing series. For an Overview, please click on the Tag.
OpenNebula is an open source Software for Infrastructure as a Service Solutions, which started as a research project in 2005. The first public release was available in 2008. Ubuntu, Debian and OpenSuse currently support OpenNebula. The project is funded by European Institutions. OpenNebula provides Amazon Web Services (AWS) EC2 and Elastic Block Storage (EBS) APIs, as well as OGF OCCI (Open Cloud Computing Interface) APIs. OpenNebula also provides a self-service Portal to their users. OpenNebula has several third-party tools for Software Stack automation and it is easy to integrate a marketplace for applications in OpenNebula platforms. Administrators have their own portal, which is called “Sunstone”, and OpenNebula provides a Unix-inspired command line interface (CLI). OpenNebula Marketplace allows virtual appliances to be managed and run in OpenNebula environments.
Billing is basically easy as there is a fine-grained accounting and monitoring system available. Account Controls and quota management allows administrators to set limits on compute, storage and network utilization. To enable this, OpenNebula supports multi-tenancy built into the system. OpenNebula can be extended by popular directory services such as LDAP or Active Directory.
OpenNebula distinguishes between clusters and virtual data centers. Clusters are a pool of hosts that share data stores. Clusters also support virtual networks dedicated to load balancing, high availability and high performance computing. Virtual data centers are isolated virtual infrastructures where an administrator can manage the compute, storage and network capacity. OpenNebula is built for high availability with a persistent database as a backend.
A key challenge for OpenNebula is to allow the management of large enterprise data centers. To fulfill these needs, a complete life cycle for virtual resource management is possible and can be extended with a hooking system. The virtual infrastructure can be controlled, monitored and accounted to the correct tenants.
Header Image Copyright by Bob Familiar

Self service IT Requirements: simplicity and user roles

Simple to use

Since users of the self Service Platform are now end-users and not members of the IT department, the platform should provide a clear and understandable interface. The platform should also offer the possibility to integrate within existing platforms such as the internal portal to lower confusion of end users and improve the level of integration of different applications. A simple platform helps the end users to learn about the capabilities and possibilities of the self Service Platform. Furthermore, it lowers the support calls to the IT department. Self Service Platforms transfer a lot of responsibility from trained IT staff to end users in departments within the enterprise. This requires a lot of attention to design such portals, since users must only see what they need to see. If marketing regularly needs to launch new websites, this possibility should be presented to the end user in a simple and understandable way. Typically, end users don’t care about how powerful their instances are, unless it is a technical department. The marketing department might only be interested in how many customers can use this platform. If we set up a website powered by WordPress, the type could be indicated like that: “each instance allows 1 million views per hour”. This would give a much better understanding to the end users how many instances they might need and how they can estimate costs that will occur by each instance they decide to launch. The platform should allow elasticity on that as well. If instances are not needed any more, they can be shut down automatically. The end user shouldn’t care about that.

simple to use IT self services at Intel

simple to use IT self services at Intel (C) The Intel Free Press

Quota Configuration and User Roles

With self Service Platforms, end users get more responsibility as with the traditional way how people deal with IT. More responsibility might also lead to greater risk of misuse. People could launch instances and simply forget that other departments might also need instances. This could lead to a over-utilization of the datacenter. Usually, resources within a company’s datacenter are not infinite and unused instances can be used better for other load. Therefore, the platform should allow some sort of quota configuration. A quota configuration within a self Service IT Platform offers the possibility to set how many instances a specific user or department can use. The IT department could set that the marketing department can utilize a maximum of 100 concurrent instances of a specific type (e.g. 4 cores with 8gb of RAM per instance). This could start with a coarse-grained configuration (e.g. 100 instances maximum for the marketing department, 100 instances for the R&D during business hours and 500 after 8pm) and gets fine-grained in the departments. This would mean that each department gets more responsibility on how to use the available IT resources, but it also requires someone that is responsible for IT within a department. Typically, this would be a manager or assistant to a manager. The IT responsible can now set different quotas within their own quotas (let’s assume it is the marketing department with a maximum of 100 instances). Different websites, applications and projects would have different quota sets, which are combined with the department quota. However, this requires different user roles with different rights.

Eucalyptus: Walrus and Storage Controller

This post is part of the Open Source Cloud Computing series. For an Overview, please click on the Tag.

Walrus

Walrus is also called “WS3” and is the storage service provided by Eucalyptus. The Storage Service provides simple storage functionality, which is exposed by ReSTful and Soap APIs. Walrus takes care of storing the virtual machine images, storing the snapshots and serving Files. As with all other public facing Services in Eucalyptus, these Services are based on the Amazon Web Services API.
Containers in Walrus Storage are called „Buckets“ and they have to be unique across accounts, just like it is with Amazon Web Services (AWS). Some naming restrictions are:

  • Containers can contain lowercase letters, numbers, periods (.), underscores (_), and dashes (-)
  • Container Names must start with a number or letter
  • The Length of a Name must be between 3 and 255 characters long
  • It is not allowed to use an IP-Address as Name (e.g., 265.255.5.4)

The maximum File Size in a Walrus Container is 5 Terabytes and Files can either be public or private. If the Container should be deleted, a container must be empty, which means that all files have to be deleted prior to deleting the container. Files are identified via unique Keys represented by Uniform Resource Identifiers (URIs).
Common Actions performed on the Walrus storage are the creation of containers, store data in containers, download data and grant or deny permissions. These Actions can be performed via the ReSTful or SOAP Interfaces. The Walrus Storage distinguishes two major read options: consistent read or eventually consistent read. The later one is faster but might server inconsistent data whereas the first one might have higher latency but data is always consistent.

Storage Controller

The Storage Controller is comparable to the Elastic Block Storage (EBS) for Amazon Web Services. Elastic Block Storage is a fast storage for virtual Image Files. The Storage Controller takes care of the creation of persistent EBS devices. Block Storage Devices are typically provided over over the ATAoverEthernet or iSCSI protocol to the instances.
The header image is provided by  jar (away for a while) under the creative commons licence.