I have published a series of posts, detailing a sample VMware SDDC Architecture. You can find the first part here, where I covered the requirements and began the series. I covered a lot of ground in the blogs, showing you the end result. I also shared the items I considered during the design.
With that, how do we actually architect an SDDC? What’s the SDDC Architecture Methodology? A good example is VMware vCAT, which I highly recommend you review.
A picture is worth a thousand word. I can’t find a better way to explain it than how the great Sidney Harris does it. This cartoon basically summarizes how we architect a large scale SDDC. It’s classic! Please visit this site for more examples of his creative work. [Acknowledgement: the picture in the link comes from this blog post by Don Boudreaux].
To me, architecting a Private Cloud is not a sequential process. It does not follow a ‘water fall’ methodology. I use the following diagram to depict it.
Why are there so many components? Because Enterprise IT is complex. I’m not here to paint it is simple. Chuck Hollis explains it very well here, so I won’t repeat it.
There are 8 components in the SDDC Architecture. They are all serving the Application. Yes, to me the Application drives the IaaS Architecture. An Infrastructure is always created for the Application. A cloud native applications will logically be best served with a different kind of infrastructure.
The above 8 components are inter-linked. Like a mash. I did not draw all the connecting lines, as that would make a complex diagram. Plus, I want to emphasize the Application. I have encountered many cases where Application Team are not being considered when architecting an IaaS.
Each component can impact other component. You can see in my sample architecture how they impact one another. This is why I recommend the architecture is jointly done.
Even the Bigger Picture is not sequential. Sometimes, you may even have to leave Design and go back to Requirements or Budgetting. So be prepared to be flexible.
Once you have passed the high level architecture, you are ready to architect the vSphere component. This serves as the building block, so make sure you get it right. The hypervisor layer is critical and far from being a commodity.
The above approach certainly depends on vSphere capability. vSphere continues to evolve. Also, the integration and dependency between NSX/VSAN to vSphere increases over time, as they form into a unified SDDC.
Let’s go over each component, starting from the Physical Data Center.
Define how many physical data centers are required. DR requirements normally dictate 2 physical data centers. You have 3 options here:
- Both on-prem
- Hybrid of on-prem and off-prem. The off-prem does not have to be pure cloud. It can be a managed vSphere environment, where you are not paying for VMware license. In fact, I see 3 sub-models here for VMware off-prem.
- Pure cloud. Multi-tenant, shared environment. You pay per VM per month.
- Managed vSphere (shared). You have dedicated vSphere cluster, but you don’t manage vSphere. You do not dictate the version of vCenter. You may or may not have your own LUN. You pay per cluster per month, and it gives you unlimited VM.
- Managed vSphere (dedicated). You have dedicated vCenter. You may or may not manage it. You can dictate your vCenter version, which can be useful as you know some features need the latest of vCenter.
- Both off-prem.
- You have choices here. You do not have to choose from the same provider. You can have 2 VMware vCAN partners.
- You can also choose the same vCAN partners, because you want to leverage their private network. I know of customers who do not want their data going over public network, even though it’s encrypted.
As you can see, even at that level you are already presented with choice and complexity. Your decision matters, as there are consequences downstream.
For each Physical DC, define how many vCenter Servers are required. Here are guidelines I used:
- Minimize the number of vCenter.
- I know 3 customers (all banks, as I serve mostly FSI) who have performed global vCenter consolidation. In general I see tendency for customers who create a separate vCenter where there is really no need to.
- It is okay to have a large farm managed by a single vCenter.
- In general, it is okay to have remote ESXi Hosts managed by a central vCenter.
- Desktop and Server should be separated by vCenter
- View comes with bundled vSphere so there is no license impact.
- Ease of management, especially if the desktop team and the server team are different. I view VDI as an application that has tight infrastructure requirement. There is dependency between Horizon Composer and Horizon Connection Server to vCenter. I’d prefer to give the whole vSphere to the Desktop Team to manage, as I treat them as a single stack.
- An exception here is a small environment, where the same IT team is running everything.
For each vCenter, define how many virtual data centers are required.
- Virtual Data Center serve as name boundary. The distributed switch do not go across vCenter Data Center. Think of that before you create a new data center object.
- Virtual Data Center does not have to be bound by physical data center. Think of the name boundary above.
- Virtual Data Center is a good way to separate IT (Provider) and Business (Consumer). In large environment, you do want to make the separation clearer. Physically, they can and will be in the same building or even rack. Virtually, you can make the distinction.
For each vCenter DC object, define how many Cluster are required.
- In large setup, there will be multiple clusters for each Tier.
- In general, I see tendency for customers to create cluster where there is no need to. A popular example is DMZ cluster.
- The Management VM should be placed in a separate cluster. It is a common practice, and we normally just call it the Management Cluster. How do you know what kind of VM should be placed here? For example, where do you place your MS AD and Print Server, if they are also managed by IT? To me, a good guideline is the network. Is the VM living in the Management Network, or in the Production network? If they live in the Production Network, then they should not be in the Management cluster. The Management cluster does not have VXLAN and its network is not virtualized. The reason it is not virtualized because NSX Manager lives here.
For each Cluster, define how many ESXi are required.
- Preferably 4 – 12. To me, 2 is too small a size, so I’d try to avoid that. I’d go with single socket ESXi if cost is an issue.
- Standardise the host spec across cluster. While each cluster can have its own host type, this adds complexity. I’d not use host type to distinguish the service tier. As you can see in this example, I’m using the same host. I’m using different attribute to separate the Gold cluster from Bronze cluster.