SDDC management changes drastically with virtualization. In this chapter, we will learn why it is one of the areas that are greatly impacted by virtualization. We will cover the following topics:
- Why the very thing you manage has changed and how it directly impacts management
- The restaurant analogy
- Contention versus utilization
- Monitoring versus troubleshooting
- The primary counters for monitoring
- Planning for the dashboards
Before we cover management, it is important to understand what it is exactly that needs to be managed. This is because it changes drastically. We will use the physical aspect of SDDCs to drive the point. It is easy to use the physical element as that's where our experience comes from, and it's also easy to mentally picture it.
Ponder the following question: how many people does it take to manage one rack's worth of hardware?
Your answer is likely "Not many." After all, it is just one standard rack. The entire thing barely occupies a small server room.
If your entire data center can fit inside one standard rack of equipment, that makes it a small operation. It is indeed a small operation for physical systems. However, in SDDC, you can achieve 1000-2000 VM per rack from a performance point of view. We're using a standard 30:1 consolidation ratio, which is possible with Intel Xeon E5-2699 v3. With 18 cores per socket, you have 36 physical cores in a dual-socket ESXi host. Add 50 percent of Intel Hyper-Threading benefit, and you can easily support 25 VMs with two to four vCPUs each, as there are enough physical cores to schedule the VMs.
I published a calculation in this blog post, which has resonated well with readers: http://virtual-red-dot.info/1000-vm-per-rack-is-the-new-minimum/.
The calculation takes into account your Infrastructure VM. Infrastructure functions that used to be provided by hardware (for example, storage replication, firewall, load balancer) are now delivered as VMs. You may run a hundred such VMs, depending on the type of services that your SDDC needs to provide.
This is not just my opinion. Ivan Pepelnjak, a networking authority, in fact shared back in October 2014 that 2000 VMs can easily fit onto 40 servers. He elaborates the calculation in this blog article: http://blog.ipspace.net/2014/10/all-you-need-are-two-top-of-rack.html. He further updates it in his November 2015 blog post at http://blog.ipspace.net/2015/11/1000-vm-per-rack-is-perfectly-realistic.html.
Greg Ferro, cofounder at Packet Pushers Interactive, also wrote a good article on why it is possible to have high VM density. He shared an example where you exceed 1000 at http://etherealmind.com/response-number-of-vms-per-rack-its-more-than-1000-dell-ms-for-example/. It all depends on the applications.
The key to having this kind of density is a converged infrastructure. In the Example Lab, we have chosen a 2RU 4-node form factor. You can find many models from Super Micro and Dell that use this form factor. From their websites, you can tell that they have a lot of other form factors to choose from.
I hope that you are convinced that 1000 VMs per rack, complete with storage, network, and security, is achievable. Assuming enough power supply per rack, you will practically shrink your data center.
How does that impact your Infrastructure as a Service (IaaS) operation? Here's how:
- You will no longer need many teams (Architect, Implement, Operate)
- You will no longer need silos (Network, Server, Storage, Security)
- You will no longer need layers (Admin, Manager, Director, Head)
It's an important question, so it's worth pondering: How should the IT department be structured if it only has 25 percent of the team left?
By team, I mean all types of members, be it your own permanent staff, monthly contractors, or per-project outsourced vendors.
You still need the doers and the experts. The layer you can cut is the middle management.
Indeed, we are entering a period of tectonic shift in Data Center Management.
The changes to SDDC management can be largely grouped into two areas:
- Architecturally: The infrastructure moves from a bespoke system to standardized hardware. The application team no longer needs to dictate the specifications of the hardware. For example, they do not need to specify a server brand, model, and CPU frequency. They need only specify how many virtual CPUs they need. Sometimes, especially in a large environment, they need only choose small, medium, or large vCPUs, and all of these will have been preconfigured.
- Operationally: Virtualization changes the IT infrastructure team from system builders to service providers. The application team no longer owns the physical infrastructure, and it is now a shared infrastructure.
Let's summarize the points. The following table compares the operations of HDDCs and SDDCs:
|
HDDC |
SDDC |
|---|---|
|
There's a clear silo between the compute, storage, and network teams. In organizations where the IT team is big, the DR, Windows, and Linux teams could also be separate teams. There is also a separation between the engineering, integration (projects), and operations (business as usual) teams. The team, in turn, needs layers of management. This results in rigidity in IT. |
With virtualization, IT is taking the game to the next level. It's a lot more powerful than the previous architecture. When you take the game to the next level, the enemy is also stronger. In this case, the expertise required is deeper and the experience requirement is more extensive. |
|
A relatively higher headcount is required in IT, with lower skill sets. |
Earlier, you may have needed 10 people to manage 1,000 physical servers. With virtualization, you might only need three people to manage 2,000 VMs on 80 ESXi hosts. However, these three people have deeper expertise and longer experience than the 10 people combined. |
|
DevOps is a concept that applies to the developer or application team. It does not apply to the Infrastructure team. |
The IaaS team needs to have its own DevOps too. As the infrastructure becomes software, there is a need for a continuous flow of Architect | Engineer | Implement | Operate | Upgrade. |