vRO and OpenStack thoughts on the Orchestrator

Some of you are maybe playing with OpenStack. Some of you with the native OpenStack of in a Distribution of your choice others with the VMware Integrated OpenStack (VIO) Beta. The VIO Beta is actual available as Beta. Information’s about VIO and other OpenStack Staff in context of VMware can be found here http://blogs.vmware.com/openstack/

Some general information about OpenStack and the different Modules are documented in the OpenStack Documentation. I want to include some Information from here: http://docs.openstack.org/juno/install-guide/install/yum/content/ch_overview.html

About the different modules:

Overview

The OpenStack project is an open source cloud computing platform that supports all types of cloud environments. The project aims for simple implementation, massive scalability, and a rich set of features. Cloud computing experts from around the world contribute to the project.

OpenStack provides an Infrastructure-as-a-Service (IaaS) solution through a variety of complemental services. Each service offers an application programming interface (API) that facilitates this integration. The following table provides a list of OpenStack services:

Table 1.1. OpenStack services

Service Project name Description
Dashboard Horizon Provides a web-based self-service portal to interact with underlying OpenStack services, such as launching an instance, assigning IP addresses and configuring access controls.
Compute Nova Manages the lifecycle of compute instances in an OpenStack environment. Responsibilities include spawning, scheduling and decommissioning of virtual machines on demand.
Networking Neutron Enables Network-Connectivity-as-a-Service for other OpenStack services, such as OpenStack Compute. Provides an API for users to define networks and the attachments into them. Has a pluggable architecture that supports many popular networking vendors and technologies.

Storage

Object Storage Swift Stores and retrieves arbitrary unstructured data objects via a RESTful, HTTP based API. It is highly fault tolerant with its data replication and scale out architecture. Its implementation is not like a file server with mountable directories.
Block Storage Cinder Provides persistent block storage to running instances. Its pluggable driver architecture facilitates the creation and management of block storage devices.

Shared services

Identity service Keystone Provides an authentication and authorization service for other OpenStack services. Provides a catalog of endpoints for all OpenStack services.
Image Service Glance Stores and retrieves virtual machine disk images. OpenStack Compute makes use of this during instance provisioning.
Telemetry Ceilometer Monitors and meters the OpenStack cloud for billing, benchmarking, scalability, and statistical purposes.

Higher-level services

Orchestration Heat Orchestrates multiple composite cloud applications by using either the native HOT template format or the AWS CloudFormation template format, through both an OpenStack-native REST API and a CloudFormation-compatible Query API.
Database Service Trove Provides scalable and reliable Cloud Database-as-a-Service functionality for both relational and non-relational database engines.

This guide describes how to deploy these services in a functional test environment and, by example, teaches you how to build a production environment. Realistically, you would use automation tools such as Ansible, Chef, and Puppet to deploy and manage a production environment.

 Conceptual architecture“

As graphical view this is a good oversight about the different modules and how they work together. The drawing this from the OpenStack documentation. The original can be found here: http://docs.openstack.org/juno/install-guide/install/yum/content/ch_overview.html

Independent which “Version” of OpenStack you use, the APIs and components are always the same. From automation perspective the Project Heat is interesting.

Quote (https://wiki.openstack.org/wiki/Heat):

OpenStack Orchestration

The mission of the OpenStack Orchestration program is to create a human- and machine-accessible service for managing the entire lifecycle of infrastructure and applications within OpenStack clouds.

Heat

Heat is the main project in the OpenStack Orchestration program. It implements an orchestration engine to launch multiple composite cloud applications based on templates in the form of text files that can be treated like code. A native Heat template format is evolving, but Heat also endeavours to provide compatibility with the AWS CloudFormation template format, so that many existing CloudFormation templates can be launched on OpenStack. Heat provides both an OpenStack-native ReST API and a CloudFormation-compatible Query API.

Why ‘Heat’? It makes the clouds rise!

How it works

  • A Heat template describes the infrastructure for a cloud application in a text file that is readable and writable by humans, and can be checked into version control, diffed, &c.
  • Infrastructure resources that can be described include: servers, floating ips, volumes, security groups, users, etc.
  • Heat also provides an autoscaling service that integrates with Ceilometer, so you can include a scaling group as a resource in a template.
  • Templates can also specify the relationships between resources (e.g. this volume is connected to this server). This enables Heat to call out to the OpenStack APIs to create all of your infrastructure in the correct order to completely launch your application.
  • Heat manages the whole lifecycle of the application – when you need to change your infrastructure, simply modify the template and use it to update your existing stack. Heat knows how to make the necessary changes. It will delete all of the resources when you are finished with the application, too.
  • Heat primarily manages infrastructure, but the templates integrate well with software configuration management tools such as Puppet and Chef. The Heat team is working on providing even better integration between infrastructure and software.

What does this mean for a VMware Administrator which want to orchestrate and automate his VMware and OpenStack environment?  At the Moment Heat is primary focused on the OpenStack environment. When you want integrate your Automation solutions you have to use other Automation Tools. I would speak from Infrastructure Orchestrator and Application Orchestration.

In this case Heat is the Infrastructure Orchestrator which offers the possibility to create new virtual machines. For the communication from Heat to VMware and API must be used to provide the Information from Heat to vRO. That is a possible way to Automate and Orchestrate the OpenStack Environment. When we take VMware into the Account, the drawing becomes somewhat more complex.

vCO is used to provision virtual Machines on the VMware Site. Heat is used to provision virtual Machines on the OpenStack Site.

I want to keep my Orchestration and Automation part as simple as possible so why we don’t only use vCO for provisioning new VMs?

From OpenStack site, you lose somewhat flexibility because can cannot use Tosca as description Language any more but from Orchestration Site it is simpler.

In my next Blog Post I will show you the way how vCO can talk with OpenStack.

Have fun and Orchestrate the World 😉