OpenStack
Overview
OpenStack is a partially complete functional clone of Amazon's AWS. That is to say it lets you create an environment where multiple tenants (customers) can create and deploy networks and VMs using self-service menus. It's pretty good and is under active development -- which can be regarded as a good thing or a bad thing depending on how stable an environment you want.
From our SOHO perspective, where we're a single tenant shop with a desire to run Internet-facing mail and web servers etc., is it fit for purpose? The answer is yes (you're reading this on such a system) but we have to do the hard yards up front.
Background
OpenStack is targeted at the general purpose cloud environment ("public clouds", "private clouds" etc.) where your VM is a relatively anonymous leaf node. It'll be accessed via a randomly allocated IP address (not even directly whether it's behind a load balancer or even given its own public IP address) and its only job is to reply to your queries. The normal behaviour is to have a pre-constructed environment into which you can temporarily deploy more, say, web servers to cope with your impending "end of year sale" then switch them off again when the load drops.
On the other hand, we want to declare well-known (i.e. fixed) IP addresses for our VMs (or load balancers) as they are the authoritative points of contact for the rest of the world to see our environment. Furthermore, our VMs may want to interact with other hosts in our internal network over the physical LAN including VLANs. We need to be a bit more savvy when we're creating our environment.
We'll also need to dance around the stock (and quite right) anti-spoofing restrictions that OpenStack implements.
As with generic clouds, OpenStack deploys pre-prepared images -- this is you don't get to attach an ISO image as a CD and then boot from the BIOS. Your image must be ready to roll. We can work with that, though.
Implementation
OpenStack itself is broadly a bunch of Python scripts sat around a MySQL database poking the local KVM implementation. As such, you should be able to deploy on most OS' that support Python and KVM as OpenStack hosts.
An OpenStack deployment consists of several functional components:
Controller Node
Unsurprisingly, the heart of the cloud.
Networking Node
OpenStack networking is implemented on OpenvSwitch (OVS) which is what really brings the solution alive (as otherwise you could just do everything in KVM!). OVS is what allows a VM on one compute node to talk to a VM on another compute node as though they were on the same ethernet segment.
To make that sort of magic happen, all the compete nodes need a central networking node to communicate with which handles all the exotic OpenFlow and virtual-to-physical shenanigans.
Most often, the networking node and the controller node are the same host.
Compute Node
This is where your VMs actually run.
You can make your controller node be a compute node.
Storage Node
A VM is normally defined as having a single root disk. If your application needs more disks or if you want to keep the data separate from the implementation (e.g. your web page content from the web server) should you wish to rebuild the VM then you need something to serve out storage to the compute nodes.
There's two kinds of storage:
Block Storage
This is akin to actual disk drives.
Object Storage
This is for data referenced by URLs.
Document Actions