VMware News and Announcements – May 13, 2022

Operationalizing VMware vSAN™

About a year ago, an astute college at VMware, Kevin Lees, reached out inquiring about writing a book on Operationalizing VMware vSAN. He had created a book on Operationalizing VMware NSX and thought writing one on vSAN would be a good idea. His extensive background in consulting and expertise in operationalizing infrastructure makes him a perfect fit for this series of books. I of course said it was a great idea and we talked about the topics to cover. I kept in touch with the project for a few months and scanned an early draft. Many others jumped in after than and helped create the book that was just recently released. Its a great read so check it out here:

Operationalizing VMware vSAN™

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.

vSAN and Data-At-Rest Encryption – Why SED’s are not Supported (i.e. Part 3)

I first wrote about vSAN and Encryption here: Virtual SAN and Data-At-Rest Encryption

And then again here: vSAN and Data-At-Rest Encryption – Rebooted (i.e. Part 2)

And then vSAN Encryption went live in vSAN 6.6 announced here: vSAN 6.6 – Native Data-at-Rest Encryption

Today I was asked if vSAN supports Self Encrypting Drives (SED). The answer is No. The vSAN product team looked at SEDs but there are too few choices, they are too expensive, and they increase the operational burden.

vSAN only supports vSAN Encryption, VM Encryption, or other 3rd party VM encryption solutions like HyTrust DataControl.

vSAN is Software Defined Storage so the product team decided to focus on software-based encryption to allow vSAN to support data at rest encryption (D@RE) on any storage device that exists today or will come in the future. When vSAN went live supporting Intel Optane, this new flash device was immediately capable of D@RE. The vSAN Encryption operational model is simple. Just click a check box to enable it on the vSAN datastore and point to a Key Management Server. One encryption key to manage for the entire vSAN datastore. The additional benefits of vSAN Encryption is that it supports vSAN Dedupe and Compression and vSAN 6.7 encryption has achieved FIPS 140-2 validation.

Another choice is to leverage VMware’s VM Encryption described here: What’s new in vSphere 6.5: Security
This is per VM encryption, so you point vCenter to a Key Management Server and then enable encryption per VM via policy. This flexibility allows some VM’s to be encrypted and some not to be. And, if the VM is migrated to another vSphere cluster or to VMware Cloud on AWS, the encryption and key management follows the VM. This requires the administrator to manage a key per VM, and because the encryption happens immediately as the write leaves the VM and goes through the VAIO filter, no storage system will be able to dedupe the VM’s data since each block is unique.

Finally, there are various 3rd party per VM encryption solutions on the market that vSAN would also support. For instance, HyTrust Datacontrol.

I hope this helps clear up what options there are for vSAN encryption and the various tradeoffs.

VMworld 2018 – My 2 Breakout Sessions

I’m looking forward to VMworld 2018 in a few weeks. It’s always a long week but a great time. I look forward to catching up with coworkers, partners, customers, and friends. And, I’ll also have to do a little work. This year I have 2 breakout speaking sessions.

vSAN Technical Customer Panel on vSAN Experiences [HCI1615PU]
Monday, Aug 27, 12:30 p.m. – 1:30 p.m.

The Panel will consist of 4 vSAN customers: General Motors, United States Senate Federal Credit Union, Rent-A-Center, and Brinks Oakland University. Brinks is a great vSAN customer but is doing an NSX session at the same time as the vSAN session so we are lucky to add Oakland University to the panel. I will moderate the session, ask the customers to describe their company, role, environment, and how they are using vSAN. General Motors will talk about their large VDI deployment. Unites States Federal Credit Union will discuss their use of vSAN in remote offices, VVols, and Storage Policy Based Management (SPBM). Rent-A-Center will discuss vSAN for management clusters, VDI, and the benefit of VxRail. Oakland University will discuss their vSAN stretched cluster, Data at Rest Encryption, and Dedupe/Compression. After each panelist does this, we’ll take questions from the audience.

Here’s a recording of last year’s session to give you an idea: https://youtu.be/x4ioatHqQOI 
On the panel we had Sanofi, Travelers, Sekisui Pharmaceutical, and Herbalife. The year before we had Stanley Black and Decker, Synergent Bank, M&T Bank, and Baystate Health. Both were great sessions and this year looks like it will be too.

Achieving a GDPR-Ready Architecture Leveraging VMware vSAN [HCI3452BU]
Wednesday, Aug 29, 12:30 p.m. – 1:30 p.m.

When it comes to security in vSAN, most think Data at Rest Encryption and to make this all work you need a key management server. It’s tough to beat HyTrust for this. They offer the software for free and support for a small fee. But that’s not all they do. Check out this session to find out more. Dave Siles and I will discuss GDPR-Ready Architecture and how vSAN encryption can help.

Troubleshooting vSAN Networking Issues with Health Checks – vSAN Health Check and vSphere Distributed Switch (VDS) Health Check

Recently, one of my colleagues was working with a customer that was intermittently getting an error on the vSAN health check in vSAN 6.6.x indicating that “A few hosts were failing ping test – large packet ping test: vsan: mtu check (ping with large packet size)”. As reported by the customer the same cluster would sometimes pass all tests in vSAN Health, and other times report the error above.

The customer enabled the vSphere distributed switch (VDS) health check and ran it on the vSphere distributed switch that was supporting the cluster. The VDS health check immediately reported …

  • Mismatched VLAN trunks between a vSphere distributed switch and physical switch.
  • Mismatched MTU settings between physical network adapters, distributed switches, and physical switch ports.

The VDS health check also reported which uplinks across the hosts had these specific misconfiguration issues, so customer had something concrete to take to his networking team to resolve the problem.

I thought this was a good example of using these two tools together to identify a networking problem and providing evidence to help facilitate the resolution.

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)

vSphere 6.7 and vSAN 6.7 in the News

Yesterday was a big day for vSphere and vSAN with the launch of the 6.7 release. There are many great blogs written so rather than repeat the content, here’s a list with links.

VMware Written Content

VMware Web Site: What’s New: vSAN 6.7
VMware Virtual Blocks: Extending Hybrid Cloud Leadership with vSAN 6.7
VMware Virtual Blocks: What’s New with VMware vSAN 6.7
VMware Virtual Blocks: vSpeaking Podcast Episode 75: What’s New in vSAN 6.7
Yellow-Bricks.com: vSphere 6.7 announced!
CormacHogan.com: What’s in the vSphere and vSAN 6.7 release?
Tohuw.Net: The Art in the Architecture – vSAN & Shared Nothing

Industry Analyst Content

 

Migrating Workloads onto vSAN

You’ve built your vSphere cluster with vSAN enabled, now what? Of course, you can start provisioning VM’s in the cluster and their vmdk’s onto the vSAN datastore. But, what if you want to move existing VM’s onto your new cluster? Well, there are several methods to consider, each with their own benefits and detractors. This topic has been explored a few times and here are some useful links:
Migrating VMs to vSAN
Migrating to vSAN

I had the opportunity to record an overview of this topic using our Lightboard technology at VMware headquarters in Palo Alto. You can check it out here:

Migrating Workloads onto vSAN

The video lightboard explores the following methods:

Backup

Simply, you can backup your VMs sitting in one cluster, shut them down, then restore them onto the new cluster.

Cross Cluster vMotion (AKA XvMotion), Cross vCenter vMotion, Long Distance vMotion (LDM)

You can migrate live VM’s from one cluster to another cluster (Cross cluster vMotion) and those clusters could be managed by different vCenters (Cross vCenter vMotion). This can be great for a few VM’s but if it’s a lot of VM’s and a lot of data then it can take a while. There’s no downtime for the VM’s, but, you could be waiting a long time for the migration to complete. For more details, see one of my previous posts:

XvMotion, Cross-vCenter vMotion, VVols, LVM active/active, LVM active/passive, SRM & Stretched Storage, VAIO Filters

Storage vMotion

This is only possible if your source and destination hosts are connected to the same source storage system LUN/Volume. If so, you can have both clusters mount the same LUN/Volume and move the VM from the source cluster to the destination cluster and also move the data from the source datastore (LUN/Volume on SAN/NAS) to the destination datastore (vSAN). If you are moving off a traditional fibre channel SAN then you’ll need to put fibre channel HBA’s in the hosts supporting the new vSAN datastore.

VMware vSphere Replication

VMware’s vSphere Replication replicates any VM on one cluster to any other cluster. This host based replication feature is storage agnostic so it doesn’t matter what the underlying storage is on either cluster. A vSphere snapshot of the VM is taken and that snapshot is used as the source of the replication. Once you know the data is in sync between the source cluster and destination cluster you can shut down the VM’s in the source cluster and power them up in the destination cluster. So, there is downtime. If something doesn’t go right, you could revert back to the source cluster. Here’s a good whitepaper on vSphere Replication.

VMware vSphere Replication + Site Recovery Manager

VMware’s vSphere Replication replicates any VM on one cluster to any other cluster. VMware Site Recovery Manager allows you to test and validate the failover from the source to the destination. It allows you to script the order in which VM’s are powered on as well as Re-IP them if necessary and can automate running pre and post scripts if necessary. Once you validate the failover will happen as you want it to, you can do it for real knowing it’s been pretested. If something goes wrong it has a “revert” feature to reverse the cut-over and go back to the source cluster until you can fix the problem. Here are a few good whitepapers on Site Recovery Manager.

3rd Party Replication

DellEMC RP4VMs replicates data prior to cut over. Once you know the data is in sync between the source cluster and destination cluster you can shut down the VM’s in the source cluster and power them up in the destination cluster. So, there is downtime. If something doesn’t go right, you could revert back to the source cluster. There are other 3rd party options on the market including solutions from Zerto and Veeam.

What About VMware Cloud on AWS?

Since vSAN is the underlying storage on VMware Cloud on AWS, all the options above will work for migrating workloads from on Premises to VMware Cloud on AWS.

Summary

Personally, I like the ability to test the failover migration “cut over” using Site Recover Manager so I’d opt for the vSphere Replication + Site Recovery Manager option if possible.  if it’s only a few VM’s and a small amount of data then XvMotion would be the way to go.

Migrating Workloads onto vSAN.png