VMworld 2018 – Achieving a GDPR-Ready Architecture Leveraging VMware vSAN (HCI3452BU)

Over the last few years I’ve gotten to know the folks at HyTrust pretty well. They are a great VMware partner and provide a critical piece to the vSAN and VM encryption puzzle for VMware customers. VMware doesn’t have an encryption Key Management Server solution so we rely on 3rd party vendors like HyTrust. They have a solution that provides highly available KMS servers which is essential to maintaining data availability. You can get more details here:

HyTrust KeyControl with VSAN and VMware vSphere VM Encryption

For this session, Dave Siles, VP, Business Development / Alliances, opened up discussing the details around GDPR and factors to consider when architecting solutions to meet the requirements. If you don’t know Dave, he’s as smart and technical as they come. He could spend hours discussing all the details but for this session he did a great job breaking it down to its simplest form. I then discussed VMware technology that aligns with GDPR requirements including Workspace One, NSX, vSphere, vSAN, and the vReailze Suite. I spent the majority of time discussing VM encryption and vSAN encryption for Data at Rest Encryption. Dave then shared some of the details about HyTrust products to meed specific needs and we then fielded questions from the audience.

If you want to check out the session, go to:

Achieving a GDPR-Ready Architecture Leveraging VMware vSAN (HCI3452BU)

VMworld 2018 – vSAN Technical Customer Panel on vSAN Experiences (HCI1615PU)

We had a great time at VMworld 2018 during the vSAN Technical Customer Panel with these 4 great vSAN customers:

HCI1615PU-Panalists

They introduced themselves, discussed how they are using vSAN in their environment, and the benefits achieved. After that, we had a stream of questions from the audience that provoked some interesting discussions. If you want to check it out you can view the recorded session here:

vSAN Technical Customer Panel on vSAN Experiences (HCI1615PU)

Also, there is a great TechTarget Converged Infrastructure summary of the session by Dave Raffo here:

vSAN hyper-converged users offer buying, implementing advice

This is the third year in the row I’ve been fortunate enough to host this session. This year was the best attended and had the best audience questions. FYI, my colleague, Lee Dilworth, will be hosing this session in Barcelona so we look forward to a good crowd with more good questions and discussion.

What Capacity Utilization Will I have after I Evacuate a vSAN Host?

To fully evacuate a vSAN host and satisfy FTT=1, FTM=RAID1 you must have at least 4 hosts in the cluster. When a host is put in maintenance mode and fully evacuated, that host data is spread across the surviving hosts. In other words, if you follow the vSAN best practice guidance to stay less than or equal to 70% utilized, then the capacity that represents the 70% utilization must now fit on 3 hosts, which means those 3 hosts become 93% utilized (70% utilized * 4 nodes / 3 nodes = 93.3% utilized). The more hosts you have in the cluster, the less utilized your cluster will be when putting a host in maintenance mode. For example: 70% utilized * 10 nodes / 9 nodes = 77.7% utilized after evacuation of a host.

The formula for this is:

% Utilization after evacuation = (% Utilization before evacuation * # nodes) / (# nodes – 1)

VMworld Hands-on-Labs – 9,640 Labs Were delivered by vSAN

The Hands-on-Labs (HoL) at VMworld are always a big hit. A ton of work goes into putting them on and supporting them and everyone seems to love them. This was a big year for vSAN in the HoL. At VMworld Las Vegas, 11,444 labs were completed and the vSAN lab, HOL-1808-01-HCI – vSAN 6.6, was the #2 overall lab completed. Our NSX friends held the #1 spot.

The HoL’s were delivered from 5 different data centers. Each handled approximately 20% of the workloads. vSAN was the storage in 4 of the data centers. 2 of the 4 were VMware data centers running vSphere, NSX, and vSAN for software defined compute, network and storage. Another was IBM BlueMix (SoftLayer) built with VMware Cloud Foundation (vSphere, NSX, vSAN, and SDDC Manager). And the other was VMware Cloud on ASW also built with VMware Cloud Foundation (vSphere, NSX, vSAN, and SDDC Manager). The 5th data center was another VMware data center running traditional storage. This is a great Hybrid Cloud / Multi Cloud example leveraging 3 of our own datacenters and 2 of the largest public cloud data centers offering Infrastructure as a Service (Iaas).

 

VMware Cross Cloud Architecture

 

9,640 of the HoL’s were deployed across the 4 vSAN data centers. This represents 84% of the labs delivered at VMworld US were delivered by vSAN. To support the HoL’s, over 90,000 VM’s were provisioned in just 5 days. Actually, more than that since extra HoL’s are pre-provision that don’t all get used. This is a huge win for HCI and vSAN as it performed like a champ for this heavy workload.

These stats are too impressive not to share and they are a great testament to all the people that make it happen.

 

 

 

 

 

Nearly 10,000 vSAN Customers! Come hear from 4 of them at VMworld 2017!

I started at VMware on the vSAN team 4 years ago when we had 0 customers. It’s been a pretty wild and fun ride to get to 10,000 but we’ve only just begun. Customers are seeing the benefits of HCI and vSAN for all sorts of use cases including mission critical applications, management clusters, VDI, ROBO, DMZ, test/dev, DR Sites, and IaaS at IBM Bluemix (formerly SoftLayer) and soon at Amazon with VMware Cloud on AWS.

Unfortunately, we cannot fit all 10,000 customers in one breakout session at VMworld, but we can fit 4. I’m hosting a breakout session titled:

vSAN Technical Customer Panel [STO2615PU]

(Now that the session has happened, here is the video recording:)

I hosted a similar session last year with Stanley Black and Decker, Synergent Bank, M&T Bank, and Baystate Health and it was a lot of fun with some great audience participation. For more information check here.

This year we are fortunate to have Sanofi, Sekisui, Travelers, and Herbalife join the panel. The format is this:

  • Introduce the Panel
  • Panelists introduce their company, their VMware environment, and their use of vSAN
  • Q&A – I will have some questions for the panel but we expect the audience questions to generate some great discussion.

Let’s meet the Panelists:

Joachim Heppner
Director, Virtualization Engineering Services
Sanofi

In 2016 this large pharma needed to refresh their Remote Office Branch Office (ROBO) sites. After a successful proof of concept, 2+ Node vSAN on HPE ProLiant Servers was chosen. Since then, vSAN has been deployed for management clusters and VDI in USA and EMEA as well as in 2 of their 13 regional data centers. Next, Cloud Foundation is being considered to replace their legacy Blade servers & Storage arrays.

Michael DiBenedetto
Director, Global IT
Sekisui Diagnostics

In early 2014 this mid-size pharma needed to build a DR site and chose a 4 Node vSphere cluster with vSAN enabled. They used vSphere Replication and SRM to test and automate DR. They also moved their test and development environment to this cluster. This year they are replacing their production data center with HCI and vSAN.

Alexander Szwez
Senior Systems Engineer
Travelers

vSAN was chosen to support production and test/dev Hadoop workloads. Two other vSAN clusters are used for new application workload POC’s. In addition, 2 Cloud Foundation configurations, each with a management cluster and a VM workload cluster are being implemented to prove how the built-in automation simplifies operations.

Jaime Gurrola
Worldwide Manager of Linux & VMWare
Herbalife International of America

In early 2014 this nutrition company wanted to modernize their data center by automating IT to simplify application access and management and transform Windows delivery. Today they run vSphere and vSAN and are evaluating NSX in multiple call centers to support 4000 Horizon VDI across 5 ROBO sites and their primary data centers for mission critical applications. They’ve achieved great cost savings resulting in significantly reduced TCO while delivering exceptional performance to their users.

I’m looking forward to seeing many great friends and to meet new ones at VMworld. I hope you can come and participate and enjoy this session with these great guests.

vSAN Maintenance Mode Considerations

There are 3 options when putting a host in maintenance mode when that host is a member of a vSphere Cluster with vSAN enabled.  You follow the normal process to put a host in maintenance mode, but if vSAN is enabled, these options will pop up:

  1. Ensure accessibility
  2. Full data migration
  3. No data migration

There’s a 4th consideration that I’ll describe at the end.

I would expect most virtualization administrators to pick “Ensure accessibility” almost every time.

Ensure accessibility

Before we investigate, I want to reinforce that vSAN, by default, is designed to work and continue to provide VM’s access to data even if a host disappears.  The default vSAN policy is “Number of Failures To Tolerate” equal to 1 (#FTT=1), which means a HDD, SSD, or whole host (thus all the SSD and HDD on that host) can be unavailable, and data is available somewhere else on another host in the cluster.  If a host is in maintenance mode, then it is down, but vSAN by default has another copy of the data on another host.

VMware documents the options here:

Place a Member of Virtual SAN Cluster in Maintenance Mode

Ensure accessibility

This option will check to make sure that putting the particular host in maintenance mode will not take away the only data copy of any VM.  There are two scenarios I can think of that this would happen:

  • In Storage Policy Based Management, you created a Storage Policy based on vSAN with #FTT=0 and attached at least 1 VM to that policy and that VM has data on the host going into maintenance mode.
  • Somewhere in the cluster you have failed drives or hosts and vSAN self-healing rebuilds haven’t completed. You then put a host into maintenance mode and that host has the only good copy of data remaining.

As rare as these scenarios are, they are possible.  By choosing the “Ensure accessibility” option, vSAN will find the single copies of data on that host and regenerate them on other hosts. Now when the host goes into maintenance mode, all VM data is available.  This is not a full migration of all the data off that host, its just a migration of the necessary data to “ensure accessibility” by all the VM’s in the cluster.  When the host goes into maintenance mode, it may take a little bit of time to complete the migration but you’ll know that VM’s won’t be impacted.  During the maintenance of this host, some VM’s will likely be running in a degraded state with 1 less copy that the policy specifies.  Personally, I think this choice makes the most sense most of the time, it is the default selection, and I expect vSphere administrators to choose this option almost every time.

No data migration

This option puts the host in maintenance mode no matter what’s going on in the cluster.  I would expect virtualization administrators to almost never pick this option unless:

  • You know the cluster is completely healthy (no disk or host failures anywhere else)
  • The VM’s that would be impacted aren’t critical.
  • All the VM’s in the cluster are powered off.

For the reasons explained in the “Ensure accessibility” above, its possible that the host going into maintenance mode has the only good copy of the data.  If this is not a problem, then choose this option for the fastest way to put a host into maintenance mode.  Otherwise, choose “Ensure accessibility”.

Full data migration

I would expect virtualization administrators to choose this option less frequently than “Ensure Accessibility” but will choose it for a couple of reasons:

  • The host is being replaced by a new one.
  • The host will be down for a long time, longer than the normal maintenance window of applying a patch and rebooting.
  • You want to maintain the #FTT availability for all VM’s during the maintenance window

Keep in mind, if you choose this option you must have 4 or more hosts in your cluster, and you don’t mind waiting for the data migration to complete.  The time to complete the data migration is dependent on the amount of capacity consumed on the host going into maintenance mode.  Yes, this could take some time.  The laws of physics apply.  10GbE helps to move more data in the same amount of time. And it helps if the overall environment is not too busy.

When the migration is complete, the host is essentially evacuated out of the cluster and all it’s data is spread across the remaining hosts.  VM’s will not be running in a degraded state during the maintenance window and will be able to tolerate the failures per their #FTT policy.

4th consideration

I mentioned there is a 4th consideration.  For the VM’s that you want protected with at least two copies of data (#FTT=1) even during maintenance windows, you have two options.  One is to set the #FTT=2 for those VM’s so they have 3 copies on 3 different hosts.  If one of those hosts is in maintenance mode and you didn’t choose “Full Data Migration” then you still have 2 copies on other hosts, thus the VM’s could tolerate another failure of a disk or host.  You could choose to create a storage policy based on vSAN with #FTT=2 and attach your most critical VM’s to it.  For more information on running business critical applications on vSAN see:

Running Microsoft Business Critical Application on Virtual SAN 6.0

I hope this helps in your decision making while administering vSAN.  I recommend testing the scenarios prior to implementing a cluster in production so you get a feel for the various options.

Podcast Fun!

In my role I have to drive a lot around New England. To pass the time I listen to a number of podcasts. Some of my favorites include:

Job Related:

Fun stuff:

But by far my favorite and the most entertaining is:

Virtually Speaking

I guess it’s partly because it focuses on storage for VMware environments, but, it’s also because Pete Flecha and John Nicholson are the right amount of funny, geek, and attitude all rolled into one.

A few weeks ago I had the chance to sit with John Nicholson and Duncan Epping to record some sound bits regarding customer experiences with vSAN in the field. I get to meet and work with a lot of remarkable customers up and down the eastern USA and over the last 3 years I’ve seen them accomplish great things with vSAN. You name an application or use case and it’s pretty likely its being done with vSAN. I was able to share a few stories as was Josh Fidel (@jcefidel) who’s doing great things with vSAN at customers in the Michigan, Ohio, Indiana, and Kentucky areas. He’s no SLOB and don’t let him fool you, he’s as smart as he is interesting. Check out what I mean by listening to this episode:

Virtually Speaking Podcast Episode 36: vSAN Use Cases

https://blogs.vmware.com/virtualblocks/2017/02/21/vspeaking-podcast-episode-36-vsan-use-cases/