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

 

 

 

 

 

vSAN ReadyNode Sizer

If you plan on implementing HCI to support your workloads and are looking to size an environment, the vSAN ReadyNode Sizer tool is the place to go.

vsansizer.vmware.com

There are 3 ways to use this.

  • Don’t log in – use the tool in “Evaluation” mode
  • Login using your My VMware account
  • Login using your Partner Central account

In “Evaluation” mode you’ll be able to create some basic configurations for general purpose workloads but will have no ability to customize or download the sizing results.

If you log in using your My VMware account or Partner Central account, you’ll have a lot more functionality. First, you’ll be asked if you want to configure an All Flash cluster or Hybrid cluster.

vSAN Sizer 1

Previously, the only place to size a Hybrid cluster was using the old vSAN Sizing tool. The ability to configure Hybrid clusters was just added to the new tool so now there is one place to size either option.

Next you’ll be asked if you want to size for a “Single Workload Cluster” or “Multi-Workload Cluster”

vSAN Sizer 2

The Single Workload Cluster provides options to configure for VDI, Relational Databases, or General Purpose workloads.

vSAN Sizer 3

The Multi-Workload Cluster choice is I helpful if you plan to have different types of VM’s and want to input the various workload specifics. There are a ton of customization options including block size, IO Pattern, vCPU/Core, etc. And of course, either option allows you to choose what vSAN protection level and method for each workload. You can even size for stretched clusters.

Our great product team at VMware has put a ton of work into this tool including some complex math to come up with a simple and easy way to configure clusters for vSAN. Check out the tool and see for yourself. But, also, feel free to contact your favorite partner or VMware Systems Engineer to also help. The vSAN SE team has done hundreds and thousands of these configurations and can help make sure you’ll be good to go.

 

 

Public Speaking Advice

Over my career, I’ve had the opportunity to publicly speak at VMUGs, vForums, Partner events, and other technology focused events. Recently I was asked to provide some Public Speaking Advice and I quickly jotted down some notes in an email and sent them. This is by no means complete, but perhaps someone else will benefit from this:

Be prepared for the worst-case scenarios

  • No network – Assume you will have no network connectivity. Perhaps you will have network connectivity and will be able to link to your live demo system, however, you should be prepared to deliver your message assuming the connectivity is too slow or broken.
  • Broken Laptop – Assume your laptop won’t boot up or can’t connect to the overhead projector. Have your presentation on a USB stick or cloud storage so you can access your presentation from someone else’s device or from your secondary device.
  • Test and verify – Do a dry run of your presentation ahead of time if possible, if not, arrive early and make sure your setup will work.

If it’s a Web based presentation

  • Have a plan if people cannot connect, maybe use an alternate method (e.g. WebEx, Skype, GoToMeeting, etc.) or be prepared to just talk through your material without visuals.
  • Don’t move your mouse all over the place, it’s annoying to the viewers.
  • Make sure you engage the audience. Ask them questions. Don’t just talk and hope they are hearing you.
  • Leverage the web presentation tools to enhance your presentation – whiteboard, highlighter, marker, etc.

If it’s an in person presentation

  • Dress for success – In other words, dress how you want to be perceived. If its your first meeting with a customer you should probably dress up. Likewise, if you are on stage at a big event, then you’ll probably want to wear a dress shirt, sport coat, polished shoes. But if it’s a technical deep dive at a customer or a technical breakout session at a conference, then you might want to dress more casual, perhaps in your company golf shirt.
  • Empty your pockets – this will prevent you from fidgeting with your cell phone, wallet, coins, etc.
  • Eliminate other Distractions – Take off your badge, lanyard, or anything that’s distracting so that the focus is on you and what you are saying. Also, don’t pick up pens or markers and click them or open and close the cap repeatedly
  • Setup the Room – Sometimes it is not possible to rearrange the room, but, if it is, then make it so you can move around the room and engage the audience. A U-shape works well for this.
  • Posture – Stand tall, arms at your side in a relaxed confident manner to start the presentation and as much as possible throughout.
  • Hand Gestures & Movement – Use as many hand gestures as possible. It shows your passion and emphasizes the content. Also move around the room as much as possible. It forces people to pay more attention. If someone is on their phone or falling asleep, move closer to them.
  • Maintain Eye Contact – This is a hard skill to master, but, extremely effective when you do. It is the #1 way to help eliminate saying “um” and “ah” which is the #1 complaint against a public speaker. To practice, cut out faces and paste them on the wall. Say a sentence to one face, then randomly make eye contact with another face and say the next sentence or complete thought. Continue to move around and randomly change who you are looking at throughout the presentation.

Slides

  • Don’t introduce yourself. Have your opening slide with your name & title on it but don’t repeat that in an opening statement. Start your conversation with an interesting opening statement that makes the audience want to hear more.
  • Keep them as simple as possible. The focus should be on you, the presenter, not the slides. Technical presentations tend to have a lot of details to convey so it may be hard to avoid showing some complex slides, but use them as a trigger for your talk track; never read them.
  • Present what you know (i.e. deleting slides is OK). We in the tech industry often get handed slide decks from corporate marketing which are great, but, often there are certain slides that just don’t make sense or you cannot figure out how to talk to it. Its best to just hide or delete the slide than try to fumble around trying to talk to it, or turn your back to the audience and read it. Build a story that you can tell by only glancing at the slides once in a while.
  • Incorporate a product demo into your presentation if possible. People like to see things in action. Best to do this earlier than leaving it until the end.

Public Speaking Training

 

 

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 IP Networking Versus Fibre Channel

Today I was asked by a customer: “By taking all of our storage traffic off of our Fibre Channel network and putting it onto our IP network, won’t that cause major network congestion?”

Quick answer is no if you implement some form of traffic “Isolation”. There are many ways to achieve isolation of vSAN traffic. All of them are identical to how you would isolate NAS or iSCSI storage traffic.

vSAN traffic can be isolated using dedicate physical switches. But most customers implementations leverage existing core switches that support all other IP traffic. In this case, for vSAN, the strong recommendation is to create a dedicated VLAN for the vSAN traffic.

On the host side, you can dedicate physical NIC’s for vSAN traffic. Some customers do this but others find that shared physical 10GbE NICs (2 for redundancy) on hosts provides enough bandwidth. When doing this, it is recommend to implement vSphere Distributed Switches and then configure vSphere NIOC to allocate bandwidth shares for different vSphere traffic. Typically vSAN should be allocated 50% of the shares.

There is an updated networking design guide for more details on all of this here:

VMware® Virtual SAN™ Design and Sizing Guide 

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.