Private Cloud Isn’t Dead Yet

I’ve been hearing about the eminent demise of on-premise workloads and “Private Clouds” ever since the Public Cloud became a thing. Most recently I’ve seen quite a few articles about how their days are numbered.

I disagree.

In my role as a Product Architect for Microsoft Hyper-V and Cloud Platform my team and I deal with traditional Virtualization but we also dabble quite a bit in Public Clouds, mostly Microsoft Azure. We try and make sure we utilize every service that we can to provide a streamlined product offering for our customers. So, I live in these worlds and often advise customers and architect environments that take advantage of both worlds. I’ll be speaking primarily from the Microsoft side of things.

First off private clouds still provide significant value and lower your overall IT spend. Your benefits include being able to fully manage your entire stack from the networking on up. You’re in control of the compliance and how everything operates. There are still quite a few reasons to use traditional virtualization for things like legacy workloads and most of all control. You also have full access to all the capacity you purchased up front, and when you aren’t using that capacity it’s available to you right away. It certainly is not hyperscale, but it is guaranteed capacity within your data center.

Public clouds are advancing at a rapid pace, in some cases new features are added hourly. They are starting to become MUCH friendlier to compliance requirements like PCI, FedRAMP and many others. And as a result, it is becoming more appealing to put your workload in Azure or AWS.

Hyper-V Best Practices

When deploying Windows Server as a hypervisor host for virtual machine workloads there are a variety of best practices that should be put in place. Running Hyper-V on Windows has special considerations when it comes to workload. For example, Virtual Machine Queues and Hyper-V Specific hotfixes. This is blog entry serves as an overview of important checks you should ensure are in place.

General Host Considerations

Starting with your base operating system you should strongly consider Windows Server Core. Server Core has a much lower attack surface as well as lower resource utilization and reduced patching requirements. This is important when running a VM workload as it frees up additional resources for your virtual machines. And the reduced patching allows for greater availability of tenant workloads.

Additionally, consider running minimal roles and features on your host operating system. IIS for example should never be installed on a host as it uses valuable resources and also increases your attack surface. If your host will be clustered, obviously, Failover Cluster Manager and Multipath I/O will need to be installed to access shared storage. Any Anti-Virus installed on the host should be configured to ignore Hyper-V specific files like VHDs, aVHDs, VHDx and VSV.

Drivers and Firmware

Ensure that all of the latest drivers and firmware for your hardware are installed on the host operating system. This is critical because inbox drivers included with Windows are not intended for long term use. Many of the features that Hyper-V takes advantage of on the networking layer require the latest and greatest network card drivers. We have seen outdated drivers and firmware cause reduced performance and instability Hyper-V hosts. Hyper-V adds a layer of complexity which is often times more sensitive to driver and firmware versions.

If you’re clustering Hyper-V, put in place a process to be sure that every single one of your nodes is running the same driver revisions and software updates.

Your browser is out-of-date!

Update your browser to view this website correctly. Update my browser now

×