Glenn Sizemore recently joined the vSAN team coming from one of the big blue storage vendors. His first hand knowledge of traditional storage and now also of vSAN gives him an interesting perspective. Check out Glenn’s most recent post as he discusses vSAN from the eyes of a Storage Administrator.

vSAN-magnify

Today I would like to discuss vSAN from a slightly different perspective, that of the dedicated storage administrator.  In my experience working with storage admins, I sometimes will come across a group who in my opinion are overly dismissive of HCI solutions.  The subtle subtext being that HCI solutions are not capable of handling “real work.”  Having transitioned from a significant storage vendor to the Storage and Availability team here at VMware, I was pleasantly delighted to confirm that those preconceived notions are rooted in pride and tradition not technical distinction.  I don’t begrudge anyone who may share this out of date perspective, but I would like to confront several of the talking points often used within the industry when discussing HCI solutions and more specifically address how several of these criticisms have been mistakenly levied against vSAN.

HCI is fine for dev/test data, but it’s not reliable enough for production data.

Nope, this one is just FUD. Aimed at making the consumer overly cautious because as we all know losing data in this business is a resume generating event.   The facts are that vSAN had a different starting point when it comes to availability as it utilizes RAIN in place of the more traditional RAID.  While not genuinely unique the shared-nothing architecture of vSAN does enable an enticing set of powerful capabilities.  These capabilities are a direct result of the architectural choice that went into vSAN.

Fundamentally there are only two ways to make a piece of data highly available.  Either provide multiple redundant paths to a shared media source or store multiple copies of the data.   vSAN being a shared nothing architecture necessitates storing multiple copies of the data; however, it isn’t nearly as pedestrian as one may think.  You see, vSAN is an object store, not a distributed file system.  This means that availability and durability are implemented at a per-object (component) level and can be adjusted as the realities of a deployment change.

Speaking of durability; it’s worth calling out that vSAN implements all the bit-rot detection and self-healing sub-systems one would find in a dedicated storage OS.  At the end of the day as long as the failures to tolerate (FTT) policy settings are set higher than the number of nodes lost the data is still available.  The real maturation process that vSAN has undergone over the past three years and six releases has been a refinement in the underlying systems which oversee this process. This helps ensure administrators don’t put themselves in an exposed position unknowingly.

HCI is fine so long as you don’t need to scale.

This will sometimes be more directly stated as; vSAN is fine but doesn’t scale. This particular claim is a pet peeve of mine because it’s rarely an actual concern.   When we are honest, the question we ask is not will it scale, but instead if it scales sufficiently to solve the problem at hand.  To answer that question let’s take a brief look at the current scale points of a vSAN cluster.  The vSAN 6.6 release currently supports up to 5 disk groups per host.  Each disk group will contain a cache and up to 7 capacity drives.  Since only the capacity drives contribute to usable capacity that gives us a maximum of 35 capacity drives per vSAN node. Finally, we can combine up to 64 hosts into a single cluster.

Assuming 1.9TB flash drives that would give us roughly ~4PB of raw capacity in my theoretical cluster.    Usable capacity is dependent on the policies applied to the component objects being stored.  Therefore, I’d like to set that aside for a moment and instead continue to explore the scalability of vSAN.   The final point of which is that as of the date of this post, up to 2000 vSphere hosts can potentially be placed into a single management domain for a combined total of ~125PB of raw capacity.  That is a LOT of flash storage, and to be honest, there are other restrictions which kick in and limit a deployment before the 125PB maximum in my example. If additional capacity were needed, we can easily use a larger drives.  Suffice it to say I believe we can safely move past the capacity argument, while not limitless vSAN 6.6 is already able to support more hardware then all but a handful of deployments can afford/justify.

What about performance?

It depends and it’s not productive to try and address performance any further than that in this post as its just too involved.  Again though, there are sufficient proof points that vSAN is more than capable when it comes to performance, and can exceed the actual required performance of all but the most demanding customer workloads.

Object count?!

Again, this is a simple misunderstanding. As of vSAN 6.0, every node added to a cluster can support 9000 component objects.  A single component can be up to 255GB.  Therefore, a full 64-node All-Flash vSAN cluster would support 576,000 component objects.  Mind you this is merely the current upper limit.   Assuming all components were consumed in support of VMDK objects, there is ~140PB of addressable space in a VSAN cluster to spread across 6000 VMs.

So to circle back around to the beginning of the conversation just how much “scale” does one need out of a single vSphere cluster?  I wouldn’t be comfortable with having that many eggs in a single fault domain, regardless of the storage technology in use.

Space Efficiency then!  HCI solutions can’t compete with dedicated storage operating systems when it comes to space efficiency technologies.

You may have noticed how we’ve moved past questions and into accusations. That’s because that’s how these conversations, unfortunately, tend to go.  Never the less it’s worth addressing.

vSAN 6.2 introduced Erasure-Coding as a failure toleration mechanism.   This was a game changer as it enabled vSAN customers to realize the media efficiency of a RAID deployment with the flexibility and composable nature of HCI. It is a very compelling meet in the middle approach which allows customers to optimize their capacity pool as they deem optimal.  Customers who value raw performance can utilize traditional full copy based RAID-1 striping.

Heck, they can even sacrifice additional capacity to further strip a component across a RAID-0 under the RAID-1 granting additional queues and media to a given workload.

When capacity utilization is a priority, the customer can opt to implement a RAID-5/RAID-6 EC deployment allowing up to 50% raw media utilization with minimal capacity lost to parity.  The ability to configure how the data will be protected on a per object basis while the standard for an object storage system is unheard of in storage arrays.  Traditionally, storage arrays would build the parity mechanism into the media pool themselves and support multiple different availability targets would require separate media pools.

Oh yeah, and vSAN 6.2 also added support for Deduplication and Compression on a per-disk group level.  After spending way too much time arguing over who’s compression and dedupe works the best…  I would just like to summarize this by saying your results will vary but not that much from vendor to vendor.   Not all workloads are compatible, which is why the erasure coding RAID implementations are far more significant in my opinion.  However, if your workloads recieves a benefit from dedup and or compression, then you will see those benefits reflected in vSAN for a surprisingly minimal performance impact.

This post carried on a little longer then I had intended if you made it this far I would like to thank you for your time. If you disagree with any of the points made, please reach out and let me know.  I’m open to changing my mind.  I have come by my current opinion only after building and selling CI and HCI solutions for customers of all sizes for the past several years. While doing so, I watched vSAN from the outside as the engineering teams iterated through the problem space.  Now on the inside with a full view of the sausage factory, I’ve concluded that while vSAN is a new way of solving the VM storage problem. There are some very compelling capabilities in addition to the undeniable advantages around administration ease of use.  If you’re on the fence and unsure how vSAN satisfies a particular concern addressed by your current solution, please drop me a line. I’d love to continue this conversation.

After this post went live we invited Glenn on the Virtually Speaking Podcast to add some color to these points. Enjoy!

Episode69

 

Advertisements

Episode62.png

It wasn’t that long ago that SQL Server was considered too resource-intensive to successfully virtualize. A new generation of hardware and advances in vSphere have made it much more common however it’s still easy to make mistakes that can result in poorly performing SQL Server VMs. This week we discuss SQL Server with Argenis Fernandez from Pure Storage. See more


hosting_outage

Recently a customer shared a story with me about a routine patch upgrade that resulted in several production VMs becoming inaccessible. The only way to bring them back online was to get the host out of maintenance mode. Read more


Episode 61

https://media.zencast.fm/virtually-speaking-podcast/episodes/61

The benefits of NVME over SSD are pretty compelling. Not only do NVMe drives offer more bandwidth, but the updated interface and protocols improve latency and better handle heavy workloads . Now, as NVMe approaches price parity with SATA SSDs organizations are making the switch, but what about the storage fabric? Are we just shifting the bottleneck to the network?

This week we bring in Dr J Metz to discuss storage networking technologies, protocols and standards. J shares his thoughts on what’s near end of road and what is gaining momentum.

Dr J Metz is a Data Center Technologist in the Office of the CTO at Cisco, focusing on Storage

Topics discussed:

  • Ethernet, Fibre Channel, PCI Express, Omni-Path (a new Intel high-performance communications architecture), and InfiniBand.
  • NVMe’s impact on datacenter design
  • Technology transitions (the game of whack-a-mole)
  • Is Tape going away?

Links mentioned in this episode:

The Virtually Speaking Podcast

The Virtually Speaking Podcast is a weekly technical podcast dedicated to discussing VMware topics related to storage and availability. Each week Pete Flecha and John Nicholson bring in various subject matter experts from VMware and within the industry to discuss their respective areas of expertise. If you’re new to the Virtually Speaking Podcast check out all episodes on vSpeakingPodcast.com.


Episode 60.png

https://media.zencast.fm/embed/virtually-speaking-podcast/60.mp3

This week we continue the Partner Perspective series with three great VMware Partners. This week we continue the Partner Perspective series with three great VMware Partners.

Topics discussed

  • Cohesity’s Rawlinson Rivera shares their solution for the recovery of a datacenter’s management stack.
  • Veeam’s Anthony Spiteri and Michael Cade update us on Veeam Powered Network, and their data protecton for VMware Cloud on AWS.
  • Duncan and John talk with Fujitsu Chief Evangalist Data Center Business, Udo Würtz

Links mentioned in this episode

The Virtually Speaking Podcast

The Virtually Speaking Podcast is a weekly technical podcast dedicated to discussing VMware topics related to storage and availability. Each week Pete Flecha and John Nicholson bring in various subject matter experts from VMware and within the industry to discuss their respective areas of expertise. If you’re new to the Virtually Speaking Podcast check out all episodes on vSpeakingPodcast.com


The short version of this post is…. we moved

Our new rss feed is https://media.zencast.fm/virtually-speaking-podcast/rss

What does this mean to you?

  • If you subscribed on iTunes, SoundCloud, GooglePlay, or stitcher it’s business as usual. We redirected to the new rss feed.
  • If you subscribe to a different service please use the new rss feed.  https://media.zencast.fm/virtually-speaking-podcast/rss
  • Take a peek at the new site. We’ve aggregated all show notes pages and episodes.  While you’re there be sure to subscribe.

So long SoundCloud

For those of you that hadn’t heard, SoundCloud was about to close the doors before securing the largest ever funding round securing their future.  During this period of uncertainty we decided to look at alternatives. The criteria we had was pretty simple

  • An embedded player
  • Ability to migrate our existing content catalog
  • A seamless change for our existing subscriber base

There were a few companies that met our needs, but one stood out among the rest for various reasons. Ultimately we decided to move from SoundCloud to Zencast.fm.

Hello ZenCast

vspz

One of the new features we have with ZenCast is a dedicated page for each episode and the respective show notes and relative links. We also have a guests page that provides links to the episodes each guest has appeared on.  This should be a really helpful when trying to find a specific guest.

vsp-g

The real advantage I see with this new site is the aggregation of all episodes.  We have been posting individual show notes blog posts on Virtual Blocks but using SoundCloud as the aggregate for actual episodes.  Now with the new site we’ve aggregated the episodes and all the show notes pages.

Summary

SoundCloud has been a great option for us for the past year.  Sure it had it’s limitations but worked.   That said, change is always tricky.  Hopefully this will be a welcome change and at very least non-disruptive to your podcast listening experience.  Let us know what you think.  Alright, thats the update, we hope to hear from you but until then… bye for now.


Lets do this..

24Jul17

OK My buddy Russ Cantwell has yet again entertained and inspired me.  This time to put together a compilation of Virtually Speaking Podcast listeners who love to rock out to our intro.

Backstory:

About a year ago, shortly after joining the ranks of the VMware technical marketing team I decided to start a podcast to help me learn more about all the different products and solutions out there but also to contribute to this vCommunity that has been such an amazing source of information, not to mention networking etc.  So my buddy John Nicholson (@lost_signal) and I decided… Lets do this, and started recording.

Side Rant: If you’re new to the world of virtualization you’ll be pleased to know there is an enormous community of IT professionals who are passionate about learning and share their knowledge through blogs, podcasts, VMUGs, and sessions at various industry events.  If your’e already part of this community, you know exactly what I’m talking about, and on that note, thank you for your contributions.

Now, just over a year in, and 75K downloads we have been overwhelmed with all the positive (and appreciative of the constructive) feedback we have received.  Now I have to be honest, sure we get lots of positive comments about the content, guests, format and even audio quality, but by far the thing we hear most is how much people love the intro. Recently a vCommunity member and all around awesome guy, Russ Cantwell ()  posted the following hilarious video of his weekly drive when listening to the Virtually Speaking Podcast.

If you don’t know Russ, be sure to follow him on Twitter.  He is a brilliant guy who is beyond passionate about all technology. Also be sure to check out his SEV Ops videos. (Short Educational Videos) on YouTube.

Lets All Do this

Here’s where you come in. Just like Russ, we want to see your creative submission of you rocking out to the intro music. You can tweet the video to @vPedroArrow and @lost_Signal or email it to podcast @ vmware . com.  John and I will assemble the submissions and make a compilation video.  We will be accepting submissions up until 8-20-17 so get moving. All submissions that make the video will receive a nice Virtually Speaking Podcast care package.  Russ, you definitely made the cut 🙂

Please be safe, John and I won’t be paying your medical bills if you hurt yourself. (we also don’t advocate handling any recording equipment while driving).

 



Advertisements