Building a Private Cloud With System Center 2012 (Part 1)

If you would like to read the other parts in this article series please go to:

Introduction

A couple of years ago I wrote a series of articles on using Hyper-V to build a private cloud. That article series walks the reader through the construction of a private cloud that allows authorized users to use a self-service portal to deploy virtual machines from templates that were created by the administrator.

Even though I am happy with the way that the series turned out, technology has improved a lot in the last couple of years. I guess that you could say that private cloud technology has grown up and is finally starting to mature. That being the case, I wanted to take another crack at the series, but this time I wanted to base the private cloud on the advancements that are available through System Center 2012 and Windows Server 2012.

My original series on private cloud management was all about providing self-service virtual machine creation capabilities. That was the big end game of the article series. Although I will show you how to implement similar capabilities within this article series, enabling VM creation is really a secondary goal. My main goal in writing this article series is to teach you the skills that you are going to need if you want to build a private cloud that is truly ready for a production environment. Like the previous series, I plan to start at the beginning and walk you through the various tasks in a step by step manner, but I will be focusing much of my attention on things like storage management and Windows image maintenance.

Hardware Resource Planning

Although private clouds make heavy use of server virtualization, it is ultimately physical hardware that handles the virtualized workloads. As such, I think that it makes a lot of sense to start out by coming up with a plan for hardware usage. In doing so, there are two concepts that I want to introduce you to – host groups and storage classification.

Host Groups

There isn’t anything complicated about the concept of host groups, but having a basic understanding of host groups is critical to successfully building a System Center based private cloud.

As you are no doubt aware, virtual machines run on host servers. Host groups are nothing more than a collection of host servers that have been grouped together to achieve a common purpose.

One of the advantages to building a host group is that you can manage the servers within a host group collectively. For example, one of the first steps in building a private cloud is to set up a host reserve. A host reserve simply reserves resources for the hypervisor and the host operating system so that virtual machines running on the host do not completely deplete the host server’s resources. Building a host group allows you to set up the host reserve at the host group level rather than requiring an administrator to configure each host’s reserve individually.

Perhaps the most important thing to understand about host groups is that they can be hierarchical. In other words, it is possible to create parent and child host groups. Now here is the important part. Child level host groups inherit certain settings from parent groups.

I will talk more about this inheritance as the series goes on, but for right now you need to know that if you make a modification to the host reserve then you have the option of cascading the host reserve settings. If you choose to allow the cascade to happen then members of the child host group will inherit the parent group’s host reserve settings. When this happens, all of the reserve settings for the child group are completely overwritten by the parent group’s reserve settings.

Storage Classification

The second concept that I need to talk about before we jump right into things is that of storage classification. There is an old saying that basically states that you should always use the right tool for the job. Perhaps nowhere is this more true than when it comes to storage.

When you build a private cloud, you are likely to need a number of different kinds of storage. For example, if the private cloud will eventually host mission critical applications that are extremely I/O intensive then you will need some high speed storage that can meet the demands of those applications.

While it would be nice to be able to use high performance storage exclusively, doing so isn’t usually realistic. High performance storage (especially solid state storage) comes with a high price tag. Furthermore, solid state drives offer very low capacities when compared to SATA or SAS drives. As such, solid state storage definitely has its place in a private cloud, but building your entire private cloud around the use of solid state storage is probably going to be cost prohibitive.

Even if you were to take solid state storage out of the picture, there are varying capabilities and service levels for traditional storage. For example, you might want to use Fibre Channel connectivity to storage that will be used for your more important VMs, while iSCSI storage might be adequate for less important VMs. Likewise, you should probably consider protecting your most important VMs with RAID 10, but RAID 5 will probably suffice for everything else.

My point is that there are many different use cases for physical storage, and properly managing that storage is essential to building a private cloud that strikes an appropriate balance between storage costs and storage capabilities.

This is where the concept of storage classification comes into play. As the name implies, storage classification is essentially the acknowledgement that no one single type of storage is going to adequately address all of the private cloud’s needs. That being the case, various types of physical storage are purchased and provisioned for use by the private cloud. Each individual storage type is classified with regard to its cost, capability, and intended use.

You can create any storage classification scheme that you want. There is no right or wrong way to classify storage so long as your classification system allows you to differentiate between storage types. For demonstration purposes, I will be building a private cloud that uses three different storage classifications. You are free to use your own classifications, but here is the classification model that I will be using throughout this article series:

Gold Storage – Solid state storage

Silver storage – Fibre Channel connected SAS drives arranged in a RAID 5 architecture

Bronze – Mirrored iSCSI storage

Again, these are the storage tiers that I will be using to build a private cloud, but you are free to define your own storage categories.

Conclusion

In this article, I have discussed some host group architectural considerations and I have also talked about categorizing the storage that will be used by the private cloud. For right now, you should consider the types of hardware that will be used in your own private cloud environment and how you will categorize your storage and your host servers. If you still aren’t quite sure of how best to group and categorize your hardware resources then you can always build a lab environment and follow along with the hands on portion of this article series, which I will begin in Part 2.

If you would like to read the other parts in this article series please go to:

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top