CloudStack for Virtualization Engineers: Installation QuickStart Guide & Intro to Service Offerings
Now that we have the foundation, an intro to CloudStack
CloudStack is an IaaS solution that is similar to VMware vCloud Director at first glance. For a more detailed breakdown on their respective capabilities and where they fit in the market, please refer to the first article in this series. By using concepts found in public clouds, such as the volatility of instances in AWS, and marrying them with a sound IaaS design, we can design a robust, flexible, and affordable cloud in our own organization. If done correctly our own internal cloud could utilize an affordable public cloud provider (e.g. AWS) should the need arise as well.
CloudStack keeps things pretty simple as there are only three types of servers:
Management Server – Provides the web UI and API access as well as performs the management of the hosts, instances, storage, etc. [mandatory]
Host – A physical server running a hypervisor meant to host instances in the CloudStack environment (VMware vSphere, Citrix XenServer, or Linux KVM) [mandatory]
Usage Server – Provides usage based billing
Some lingo differences with VMware vCloud Director terminology in green, and CloudStack terminology in blue.
vCloud Director
CloudStack
Description
Cloud Cell
Management Server
The server(s) that performs the management, provides the UI, and exposes the API
Cluster
Cluster
Collection of hosts with access to the same primary storage & running the same hypervisor
vDC (Virtual Data Center)
Pod
A collection of clusters and their primary storage. In VMware = source comes from a single vCenter server In CloudStack = sources comes from cluster(s) of same hypervisor
---
Availability Zones
A collection of pods and secondary storage
vApp
Project
A collection of VMs/Instances needed to provide a multi-tier application or service
Datastore
Primary Storage
Used for storing virtual machine files (vmdk’s, vhd’s, etc.)
Repository
Secondary Storage
Used for storing templates, saved snapshots, and ISOs
Organization
Domain
A collection of authoritative accounts
In VMware vCloud Director, a lot of the design work is done at the Resource Pool level, as Organizational vDC’s map to resource pools. On the roadmap for CloudStack 3.0 (Acton) is a feature called Projects, which appears to be a full lifecycle management (including assignment of resources) of an
A few other key definitions:
User – An alias of an account; users use a CloudStack account (many-to-one mapping). Example = jlangone
Account – A group of user accounts. Example = CloudAdmin
Domain – A group of accounts. Example = Tenant_A
Note: There is no LDAP configuration mechanism from within the CloudStack UI. For example, if you have domain, Tenant_A, and you want Tenant_A to use their own LDAP for user authentication, you must tap into the CloudStack Administrator API. VMware vCloud Director makes this setting (local account, built-in LDAP, custom LDAP, etc.) easy to configure via a simple radio button in their UI.
Quickest Way to Get CloudStack Up & Running
In my testing, I’ve found the following recipe to work very well:
Create a new VM and install Centos 5.5 64bit in the VM
Configure a static IP address, DNS, hostname
Ensure the VM can resolve itself to the proper IP address (CloudStack will use the results of the hostname command)
Ensure DNS is working properly
Ensure DNS is working properly
Ensure DNS is working properly (you would do this 3 times with vCloud Director as well)
Download CloudStack from Cloud.com
tar –xvf <cloudstackfile>
From within the newly created directory, ./install.sh
M – Install Management Server
./install.sh
D – Install Database
Edit the /etc/my.cnf file at put the following under the datadir line:
On the CloudStack roadmap is, "Gorgeous Web UI," but I think the current UI is pretty attractive as is; I will say, from a pure UI-to-UI standpoint, I find the CloudStack interface easier to comprehend, but the vCloud Director interface prettier to look at.
The Management Console is where (typically) the Service Provider performs management tasks, as well as run their own cloud infrastructure.
In my opinion, any IaaS solution's management console should start with the service offering. Why? IaaS clouds are built to provide resources, primarily in the form of instances. By defining what type (e.g. OS flavor), size (e.g. 2vCPU/4GB RAM), and tier, an IaaS Cloud Architect can start to think about the underlying hardware components required, how the consumers of the cloud will consume (and what they will consume), and what some of the ancillary supporting platforms may be (e.g. a database instance = Microsoft 2008 + Microsoft SQL).
You are the executive chef of your cloud restaurant and are putting together a menu for opening night; the menu may have a few seasonal additions and subtractions as the restaurant matures, but the cloud menu is the first step for the consumers to understand how they are going to consume your IaaS cloud.
For most IaaS environments, service offerings are made up of two primary types:
Compute (volatile or non-volatile)
Storage (persistent)
The secondary service offering is:
Network (private, private with www access, public)
An additional type used for ancillary services also exists in most IaaS environments:
Ancillary services are commonplace in mature clouds but often a phase-two implementation for new or pilot IaaS environments. Nevertheless, these services are likely needed in a mature environment and should not be overlooked in the design (primarily as it relates to networking capabilities).
Out of the box, CloudStack ships with two examples of compute service offerings:
Small Instance. 1 vCPU. 512MB RAM. Cost = $0.05/hr
Medium Instance. 2vCPU. 1024MB RAM. Cost = $0.10/hr
These will likely not be used, but use them as examples. The best place to understand what your Service Offering menu should look like is a quick inventory of your existing environment.
1% CentOS, 38% RHEL and 60% Windows 2008? Well you know the first two instance types you need.
If possible, use a capacity planning tool to calculate the average number of CPUs required. For environments migrating from physical to a virtual IaaS platform, or even those graduating from a typical server virt solution, the average server may have 4 vCPUs but run at only 15% utilization.
Try to avoid taking bloat to your cloud's menu as that would not be efficient or economical to deliver or provide.
While a foreign concept to many, providing volatile instances and making persistent storage available may be the best formula (as stolen from AWS).
Either way, if persistent storage is going to be offered (and it should be), making a storage service offering available from your cloud menu is the most efficient way.
Conclusion
Now that (hopefully) the concepts of volatile instances and non-volatile storage are sinking in, and you have a functioning CloudStack Management Server, we can start to design our first environment. The next article will focus on:
