I’ve been at VMware for 1.5 years and have had a blast talking to customers, partners, and VMware employees about all things software defined storage. This primarily involves Virtual SAN & EVO:RAIL which take advantage of VASA, Storage Policy Based Management, and VVOLS. Because we are talking about storage it also includes discussing the benefits of vSphere Replication, Site Recovery Manager, and vSphere Data Protection. Basically, anything to do with storing, protecting, and managing Virtual Machine data. Its exciting to be part of the whole software defined data center strategy.
We are growing our Software Defined Storage team and are looking for qualified rockstars. If you are one, and the topics above are familiar to you, and you are interested in joining the VMware Software Defined Storage Team, then check out the openings below. Feel free to apply directly or reach out to me with any questions at: pkeilty at vmware dot com
Unfortunately I won’t be attending VMware PEX this year. Its a great event to meet up with our great VMware partners and learn the latest VMware tech. There will be tons of Software Defined goodness, specifically, here is a great link to all the storage stuff:
Specifically, make sure Power Management BIOS Settings are disabled in the server BIOS (see page 17)
Once ESXi is installed on the host
Make sure the IO Controller is loading the correct version of the device driver. You can look this up on the Virtual SAN HCL
I work with a lot of customers who are evaluating or implementing Virtual SAN and following these simple, obvious, but important best practices have led to better performance and a better overall experience with Virtual SAN.
One of the big topics at VMworld 2014 was VVols. VMware announced it will be part of the next release of vSphere and almost every storage vendor on the planet is excited about the benefits that VVols bring. I was working the VVol booth at VMworld and had the pleasure of being interviewed by VMworld TV to discuss the comparison between VSAN and VVols. This was fun but unscripted and off the cuff so here it is:
VMworld TV Interview: Peter Keilty of VMware Discussed Virtual Volumes
What I’m trying to say is:
VSAN is the first supported storage solution takes advantage of VVols.
VVols, in vSphere.NEXT, will work in conjunction with VASA to allow all block and file based storage arrays to fully realize the benefits of Storage Policy Based Management (SPBM).
Each storage vendor can write a VASA/VVol provider that registers with vCenter to integrate with the vSphere API’s and promote their storage capabilities to vCenter. I expect just about every storage array vendor to do this. I have seen VVol demonstrations by EMC, NetApp, Dell, HP, and IBM.
VVols eliminates the requirements of creating LUNs or Volumes on the arrays, instead, arrays present a pool or multiple pools of capacity in the form of storage containers that the hosts in the cluster see as datastores
Through SPBM, administrators can create different service levels in the form of policy that can be satisfied by the underlying storage provider container.
When VM’s get provisioned, they get assigned to a policy, and their objects (namespace, swap, vmdk’s, snap/clones) get placed as native objects into the container in the form of VVols.
You can even assign objects from the same VM to different policy to give them different service levels, all potentially satisfied by the same storage provider or perhaps different provider containers. In other words, a vmdk for an OS image might want dedupe enabled but a vmdk for a database might not want dedupe but might want cache acceleration. Different policy can be set and each object can be assigned to the policy that will deliver the desired service level. The objects could be placed into the same storage array pool but taking advantage of different storage array features. And these can be changed on the fly as needed.
Like all the storage vendors out there, I’m very excited about the benefits of VVols. For a full description and deep dive check out this awesome VMworld session by Rawlinson Rivera (http://www.punchingclouds.com/) and Suzy Visvanathan:
I’m really looking forward to attending VMworld 2014 in a few weeks. Its a great time to catch up with friends and meet new ones. For me the week kicks off on Thursday at the VMware SE Tech Summit. Then vOdgeball on Sunday afternoon with a team of former EMC vSpecialists. This is a great event to help out a great cause, the Wounded Warrior Project. We’ll also be honoring our two vSpecialist friends, Jim Ruddy and Stephen Hunt, that were recently involved in a tragic accident. Then the main event starts Sunday night. It should be fun and exhausting.
I think one of the hidden gem features of VMware Virtual SAN (VSAN) is it’s software defined self healing ability. On the surface this concept is simple. The entire pool of disks in VSAN are used as hot spares. In the event of a failure, data from the failed disks or hosts are found on other disks in the cluster and replicas (mirrors) are rebuilt onto other disks in the cluster to get back to having redundant copies for protection. For VSAN, the protection level is defined through VMware’s Storage Policy Based Management (SPBM) which is built into vSphere and managed through vCenter. OK, lets get into the details.
Lets start with the smallest VSAN configuration possible that provides redundancy, a 3 host vSphere cluster with VSAN enabled and 1 SSD and 1 HDD per host. And, lets start with a single VM with the default # Failures To Tolerate (#FTT) equal to 1. A VM has at least 3 objects (namespace, swap, vmdk). Each object has 3 components (data 1, data 2, witness) to satisfy #FTT=1. Lets just focus on the vmdk object and say that the VM sits on host 1 with copies of its vmdk data on host 1 and 2 and the witness on host 3.
OK, lets start causing some trouble. With the default # Failures To Tolerate equal 1, VM data on VSAN should be available if a single SSD, a single HDD, or an entire host fails.