In this two-part blog post I’ll try to cover a new aspect of the vCloud Director for a change. We will have a brief look into the design journey of a private cloud and how all its pieces come together. It’s going to be very hard to cover every detail in this post, so I will try to focus on the main areas and group them into small sections for easier follow up. Let’s get started!

A Holistic Diagram

When it comes to an architecture design, you must have a diagram! In this one I’m mixing between logical and physical layouts. The former being around storage, and the latter will be focused on servers. The reason why I didn’t go with a complete physical design was to reduce the complexity of the diagram. I know that i should be vendor neutral here, but i thought that i need to be as much practical and realistic as possible (specifically in this design subject) for you to follow up easily. Choosing Cisco UCS was just a random selection. I happened to show IBM some love in my previous vSphere design posts, so i thought i would do the same for Cisco this time. Enough said?

Cluster Design

If you have already read my previous blog posts on designing vSphere on blades, this part won’t look very different to you. We will follow here nearly the same concept and divide our clusters into one Management cluster and two resource clusters. Let’s take a closer look:

• Management Pod: We will run here all our management and monitoring elements of our private cloud. The cluster consists of 4 blades spanned across two chassis for redundancy.
• Resource Pod: We have here two clusters forming our resources:
  • Gold Cluster: We are dedicating here one cluster for this hardware pool. In this cluster we have 12 blades spanned across three chassis with a maximum of 4 blades per each chassis. This will allow us to achieve the maximum high-availability, and also avoid having all our 5 primary HA nodes on a single chassis in case of any unlikely hardware failure.
  • Silver & Bronze Cluster: We are having here one cluster on this hardware pool, but we will slice it down into two resource pools. Each RP can be configured as per each customers’ requirement. We will name these two clusters “Silver” and “Bronze”.
    

The Management Pod

As mentioned earlier, in this cluster we will run all our management and monitoring elements of the cloud. Here are a list of the VMs:

• vCD Cells: It is highly recommended to use at least two cells in your cloud environment to avoid the single point of failures. It’s worth mentioning also that there is no licenses restrictions as to how many cells you have to run.
  
• Load Balancer: This is typically a physical box sitting outside your virtual/cloud environment (like F5 appliances) but it could be a virtual appliance as well. At the time of writing these lines, there is no special recommendations for the LBs to be used with vCD. In fact, a simple DNS round robin could do the trick to distribute the load across your cells.
  
• vSM: This is the vShield Manager virtual appliance. I would recommend here to run this VM in FT. From one hand, it will run perfectly well with 1vCPU and it won’t consume any cpu resources from your cluster, and from the other hand you will ensure that you have the required redundancy for this important cloud element.
  
• The Oracle DB: This is the backend database for our entire private cloud. It’s vital that you have a highly redundant setup for the Oracle database like a RAC setup for example. Your DB admins are typically the ones that will be concerned about this component and they should be the ones designing it. You have to know however what are the databases that will be hosted in this cluster, which can be summarized as follows:
  
  • vCenter Server DB: as per our existing setup, we have to vCenter Servers, consequently we will have two vC databases.
    
  • vCenter UpdateManager DB: same thing holds true here. We will need to vCenter UM databases.
    
  • vCloud Director DB: this is the most critical part of the cloud environment, not just because we store all out cloud related information there, but also for the fact that the DB plays a major role in the cluster heart beating of the Cells (more on this subject in a future blog post).
    
  • vCenter Chargeback: this is the DB that handles all our billing.
    
• vCenter Servers: As you see in the diagram above, we have two vCenter servers. The first one will be managing the management cluster itself, and the second one will be managing the resource clusters. I haven’t included in the diagram the vCenter Heartbeat product although it would be highly recommended here. You can still leverage the native VMware High-Availability to protect your vCenter VMs, and also enable the VM monitoring to reboot the VM in case of OS crashes. It all boils down to what level of protection and HA you want to ensure in your cloud.
  
• vCenter Chargeback Servers: Here we have the Chargeback servers. I will talk in details about this subject in a complete blog post very soon.
  
• NFS Share: You will need the NFS share to store the response files for the cells and also it would be a good practice to store your vCD bits along with the other required software for the cells. Eg. RPMs and dependencies.
  

To be continued.