Recently we started moving away from our original setup plan that was to have an OpenNebula cloud running on CentOS boxes, to an OpenStack Cloud running on Ubuntu boxes.
I’ll try to give a quick overview of what is OpenStack and talk a little bit about some of its main components.
Before I get started, I really like this diagram that demonstrates what problem OpenStack is trying to solve.
This is a basic diagram demonstrating the basic usage/need of a cloud platform.
OpenStack works on all levels of the cloud set up, from the low level libraries that interact with the HyperVisors to the Web Dashboard that allows users to interact with the cloud.
In the end OpenStack aggregates different solutions to offer a simple way to build public and private cloud platforms.
Some OpenStack history
Back in 2010 NASA and RacKSpace started the OpenStack Cloud project with the goal of having an open standard for both hardware and software cloud solutions.
Currently there are more than 150 companies involved with the project, such as Intel, IBM, Cisco and HP to name a few.
As far as activity, OpenStack seems to be very active with two major releases per year.
Their release history:
- Austin 21 October 2010
- Bexar 3 February 2011
- Cactus 15 April 2011
- Diablo 22 September 2011
- Essex 5 April 2012
- Folsom 27 September 2012
- Grizzly 4 April 2013
OpenStack is divided into three different categories:
- Nova – OpenStack Compute
- Glance – OpenStack Image Service
- Swift – OpenStack Object Storage
- Cinder – OpenStack Block Storage
- Keystone – OpenStack Identity
- Horizon – OpenStack Dashboard
- Quantum – OpenStack Networking
Now lets took into more details on the components listed above:
Nova – Compute
Nova can be summarized as a cloud controller.
It centralizes the management of a cloud and communicates between all different components, a good diagram that illustrate its role:
The main components of Nova are:
- API server: handles requests from the user and relays them to the cloud controller.
- Cloud controller: handles the communication between the compute nodes, the networking controllers, the API server and the scheduler.
- Scheduler: selects a host to run a command.
- Compute worker: manages computing instances: launch/terminate instance, attach/detach volumes
- Network controller: manages networking resources: allocate fixed IP addresses, configure VLANs
List of features:
- Manage virtualized commodity server resources
- Manage Local Area Networks (LAN)
- API with rate limiting and authentication
- Distributed and asynchronous architecture
- Virtual Machine (VM) image management
- Live VM management
- Floating IP addresses
- Security Groups
- Role Based Access Control (RBAC)
- Projects & Quotas
- VNC Proxy through web browser
- Store and Manage files programmatically via API
- Least privileged access design
- Dashboard with fully integrated support for self-service provisioning
- VM Image Caching on compute nodes
Glance – Image Service
Glance takes care of managing virtual machine images.
Some of its functionality:
- List Available Images
- Retrieve Image Metadata
- Retrieve Raw Image Data
- Add a New Image
- Update an Image
- List Image Memberships
- List Shared Images
- Add a Member to an Image
- Remove a Member from an Image
- Replace a Membership List for an Image
Glance is only responsible for creating and managing virtual machine images, the deployment and maintenance of the VMs is taken care by Nova
Swift – Object Storage
The Swift component is a Container/Object storage system.
Different from SAN and NAS file systems, Swift cannot be mounted, since it is not a file system itself.
You can think of Swift as a distributed storage system for static data, such as images, videos, archive data, etc
All the files are exposed through an HTTP interface, typically with a REST API
A good analogy is to think of Containers as folders as in a regular OS such as Windows
Objects are chunks of data living inside containers.
So when you upload a picture to Swift it will be wrapped in an Object and placed inside a container.
The object can contain some metadata in the form of key value pairs.
No encryption or compression is performed on objects upon storage.
List of features:
- Leverages commodity hardware
- HDD/node failure agnostic
- Unlimited storage
- Multi-dimensional scalability (scale out architecture)
- Account/Container/Object structure
- Built-in replication
- Easily add capacity unlike RAID resize
- No central database
- RAID not required
- Built-in management utilities
- Drive auditing
- Expiring objects
- Direct object access
- Realtime visibility into client requests
- Supports S3 API
- Restrict containers per account
- Support for NetApp, Nexenta, SolidFire
- Snapshot and backup API for block volumes
- Standalone volume API available
- Integration with Compute
Keystone – Identity
To summarize what Keystone does in one sentence:
keep track of users and what they are permitted to do
Keystone handles the user management of the cloud system, allowing different permissions to be configured for different users.
One of the keywords they use when talking about Keystone is Tenants.
Their explanation of tenants is something that can be thought of as a project, group, or organization
A diagram demonstrating the basic flow of Keystone:
Horizon – Dashboard
Horizon is the web interface available for OpenStack, it’s very much like what OpenStone is for OpenNebula.
Quantum – Networking
Quantum is a new addition to OpenStack.
Up to the Essex release Quantum was built in the Nova component. However to provide more functionality in terms of network management Quantum was created with the focus on managing a network of an OpenStack solution
After all that being said, based on the image from the beginning of the blog post, we can have a better idea of where the OpenStack components fit in the overall cloud set up:
From somebody who is just getting started with cloud computing I would say that between OpenNebula and OpenStack the later is a better option. Even though OpenNebula is an older project OpenStack seems more mature.
A few things I noticed:
There is a lot more uptodate information about OpenStack, plus it is very easy to navigate through their website and find information about the different solutions they provide.
The community appears to be a lot more active with OpenStack than with OpenNebula.
Maybe it is just me, but after a few minute reading about OpenStack I was lead to their official repo on github where all the related projects are hosted.
I really like that since it is an easy way to stay in close touch with the project and follow the latest additions, plus it provides a channel of communication between the users and the developer and makes a lot easier for people to contribute back to the project.
I didn’t have the same feeling when it came to OpenNebula, the project didn’t feel as open as OpenStack, I felt there were a lot more hurdles to get started with OpenNebula.
Talking strictly technical it’s hard for me to say which one is better.
Reading about them both I could definitely see a lot of areas where they overlap, for example, they both use noVnc for the visualization of VMs and libvirt to communicate with the hypervisors.
They both have a web interface to manage the cloud and they both have options to configure VM templates.
A big difference is that OpenNebula is written in ruby while OpenStack is in python
And I’m sure they must differ in other architectural decisions as well, but for the most part they are very similar
For more information about OpenStack:
Keystone basic concepts
Very good blog about python & openstack