vCenter and vCloud Management Design - Management Separation

While at a customer site this past week, I was confronted with a situation. But before I get to that, lets talk about vCenter and vCloud Design. First thing is first, you should be vaguely familiar with vCloud Architecture Toolkit (vCAT). One important topic it discusses is the placement and use of vCenter when it comes to vCloud Director. It's a recommended practice to have 2 vCenter servers in a vCloud environment. Use 1 vCenter server for hosting Datacenters/Clusters/VMs that are relevant to vSphere and vCloud Infrastructure Components. Use another vCenter server for hosting vCloud Resources. Why's this? Separation of management domains. It's important to know that vSphere and vCloud are different animals. Just because you are a vSphere admin, it doesn't make you a vCloud admin. By separating the two environments, you are letting vSphere admins access VMs that are outside the Cloud, and manage VMs that are considered vCloud Infrastructure. vCenter becomes abstracted. ESXi abstracts the hardware layer, and vCenter is the central management point. vCloud Director abstracts the resources that belong to vCenter and present those to vCloud as Provider Virtual Datacenters. Saves vSphere Admins from themselves. Have you've ever watched what happens when you add a vCenter server to vCloud Director? vCloud Director takes charge. It does it's own thing by creating folders, resource pools, port groups, appliances, etc. Everything that is created by vCloud has a set of characters that proceed it to become unique identifiers. If a vSphere admin has access to a Distributed Virtual Switch, and notices some random portgroup ending with HFE2342-FEF2123NJE-234, he is probably tempted to delete it. If a user goes crazy and starts deleting objects directly from vCenter without vCloud's knowledge, its havoc. Relieve Stress on vCenter. As Duncan pointed out below in the comments, if a tenant of the cloud is issuing a bunch of requests, it could possible render the vCenter server unusable. By separating out the workload among 2 vCenter functions, you will not impact a vCenter server responsible for management functions. So lets take a look at 2 vCenter vCloud environment where there is already a management cluster for other applications. This management cluster already has a vCenter Server, SQL Server, vCOPS, AD/DNS, etc. and probably manages other cluster in the datacenter. If the resources are available, you will want to create a cluster called a vCloud Management Cluster. This Management cluster will house the second vCenter Server, SQL, vShield Manager, vCD Cells. There is a second SQL server because the vCloud vCenter, vCloud vCenter Update Manager, and vCloud Director applications will all need access to a database. It's best to have a second because using a single SQL server in a different cluster can cause latency int he applications or unexpected downtime. As depicted in the diagram, the Management vCenter Server owns the Management Cluster and the vCloud Management Cluster. The vCloud vCenter Server own the vCloud Resource clusters. This is how it would look in vCenter: Here's another instance where we see a 2 vCenter vCloud environment. Instead of having a dedicated vCloud Management Cluster, it's integrated into a different management cluster. This management cluster will need to have ample space to satisfy HA requirements. As we can see in the logical diagram, all the VMs before have been listed (I didn't show AD/DNS, but that should be in there as well) except there is an orange and red box around the second SQL Server. This depiction means that a 2nd server may or may not be necessary depending on your requirements. Here is a resemblance in vCenter: So back to my dilemma this past week. I'm standing up a vCloud POC environment for a customer and they only purchased 1 vCenter license. What's the best approach? Well of course the single vCenter and SQL server are going to manage all clusters. But how do we get around some things we mentioned before about separation of management domains, and saving a vSphere admin from himself? Here is the simple logical design, but skip on down to the vCenter example. So you might be looking at this diagram and saying, "yeah, so what?". There was thought into what you see below. Since we only have a single vCenter to manage all the clusters, we need to create a separation of management domains. This is done by creating a second logical datacenter and putting the vCD resource clusters in that datacenter. Using role based access control (RBAC) we can allow certain AD users/groups to only access the datacenter that is relevant to them. Therefore, an AD group such as "Cloud Admins" can access the vCloud-Resources Datacenter object when logging into vCenter. At the same time, creating this second logical datacenter is saving a vSphere admin from themselves. If this were all pooled into a single logical datacenter, a vSphere admin would be looking at a mess of multiple virtual distributed switches and folders. There would be a vDS assigned to the management cluster, and a vDS or two assigned to vCloud Resources, and perhaps a recovery vSwitch somewhere. All of these would be visible from a single view (BAD!). Since a virtual distributed switch is tied to logical datacenter, we get a clean separation. When a vSphere admin looks at the Networking tab under the vCloud-Resources datacenter, they will only see things relevant to vCloud and vice-versa. This logical datacenter separation allows you to safely use 1 vCenter server in your vCloud environment.