The OpSource Cloud is made up of these components:
- Cloud Servers, or the virtual machines (VMs) or instances running in the OpSource cloud.
- Cloud Networks, or the private, cloud-based networks used for communication in the OpSource cloud. These private networks can be accessed via a Cisco VPN connection that OpSource offers for free (and in a very intuitive manner).
Making assumptions from this graphic, one can assume that OpSource uses Dell servers running a VMware hypervisor, Cisco networking gear and both EMC and HP back-end storage for Cloud Files and the storage of the actual VMs.
OpSource also offers a 100% availability guarantee (which I'm not sure is even possible). After signing up for the OpSource cloud (a very straightforward process), the first step is to deploy a network.
A network in the OpSource cloud is essentially a cloud-based LAN dedicated to a customer's environment. This cloud-based LAN is not accessible from the naked Internet; it requires the customer to establish a VPN connection into the cloud-based LAN. This network is the default network for VMs and allows the configuration of components such as firewalls, load balancing parameters, NAT rules and multicast networks.
For customers looking to host solutions with a publicly accessible address, a simple change to map a public IP address to an OpSource VM will allow anyone to hit the resource without requiring the VPN connection first.
Once at least one network has been defined, it's now time to provision a VM or two. The list of available images is as follows:
- Red Hat 5 Standard
- 64-bit 1 vCPU
- 64-bit 2 vCPU
- 64-bit 4 vCPU
- Windows 2008 Server Standard
- 32bit 1 vCPU
At this time, there are no partner images available, although with OpSource allowing you to import your own VM, an argument could be made that the VMware Appliance Marketplace is a potential source of available images as well.
For this example, I deployed a Windows Server 2008 Standard Edition 32-bit with 1 vCPU, 2 GB of RAM and a 32 GB OS drive. The VM takes 10-15 minutes to fully build and customize. Once it is ready for use, it shows up in the "Servers" section of the user interface (UI).
On first login to the VM, my first impression is that the "Preparing Desktop" phase of my Windows VM goes very quick. In other providers, I've seen this last approximately 60 seconds, but I was on my desktop in less than 10 seconds.
I also deployed a few other VM, including a 2 vCPU instance. A few basic tests were run; overall, the performance within the OpSource cloud is good but could also be characterized as "unpredictable." For example, a 2 vCPU server had low CPU utilization but high CPU % ready times and overall felt sluggish, while another VM ran effortlessly.
The OpSource Cloud experience: What's good
The OpSource cloud is fairly intuitive to use, OpSource users can import their own images, and overall the performance is acceptable. Establishing a VPN connection (via the Cisco-based solution) is very simple and worked flawlessly every time it was tested.
The OpSource Cloud experience: What's bad
The UI could use a "Tasks" area that shows pending, queued, active and completed tasks. When a user creates a VM, for example, they are clueless as to the level of progress. After 10-15 minutes, the VM shows up under "Servers," but I wasn't sure that it took properly the first time so I unnecessarily created a second. After that, I checked the logs to make sure my "create" task was working properly.
The user (if they had access) could certainly check the log to verify that the "create" task was executed, but right now there is no way to check and see how much longer it will take to complete. Finally, I occasionally received several "there has been a problem communicating with the OpSource cloud" messages when performing random tasks from within the UI.
How OpSource can improve its cloud experience
Other than what's noted in "the bad" section above, a few other changes would be nice.
First off, having the ability to hide the "VMware Tools" icon so that the underlying platform is less obvious to the end user. Along the same lines, the option to make it less obvious as to which version of the VMware hypervisor the OpSource cloud is using. Savvy customers will note the dated version of VMware tools.
It would also be beneficial to have a dashboard, similar to Vizioncore's vFoglight, to monitor all of a customer's VM in the OpSource cloud. This could certainly be a cost-based option, but if I was to move a large portion of my environment to the OpSource cloud, I would want a dashboard to monitor the health of my environment without having to tap into application programming interfaces (APIs) or other measures.
The argument could be made that an admin would monitor his OpSource virtual machines just like any other server in the environment; however, if this environment was on-premise in my own data center, I'd have vCenter or System Center to monitor my environment at a bird's eye level.
Finally, it would be great if, during a "delete" action on a VM, it was obvious that the underlying storage was zeroed out. Just because the VM's disk(s) have been deleted, it doesn't mean that the data is completely removed from the (assumedly) EMC or HP storage array(s). While the OpSource cloud meets a handful of industry compliance guidelines, it would still be nice to see and know that the underlying disks on the storage array(s) were overwritten with zeroes.
ABOUT THE AUTHOR: Jason Langone is a Federal Data Center Architect for INX. He has spoken at VMworld, Green Computing Summit and Virtualization Congress. Langone won the VMware Vanguard Award in 2007 and has architected some of the largest virtualization and cloud computing implementations to date. His solutions have been primarily implemented at Fortune Global 500 and public sector organizations and have received various accolades. Langone's focus remains on designing virtualization and cloud computing solutions in large-scale environments.
This was first published in August 2010