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:
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:
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:
We had a great time at VMworld 2018 during the vSAN Technical Customer Panel with these 4 great vSAN customers:
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:
Also, there is a great TechTarget Converged Infrastructure summary of the session by Dave Raffo here:
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.
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.
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.
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.
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)