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
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)
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.
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: