After all the sound and fury, when will VVOL start to rock? VMware virtual machines need storage and VVOLs (Virtual Volumes) are a way of automating this process, avoiding delay as VMware admins talk to storage admins to get storage provisioned. Virtually all storage array vendors support VVOLs yet the facility has not been taken up by users’ data centres in any large scale. This poses …
"Perhaps the VVOLs scheme is too complex? Possibly it is too limited in its focus.
To recap, a virtual machine (VM) can be thought of as VMDK files stored in a VMFS datastore which is a logical unit (LUN) in a storage array."
Presumably you are talking in an incomprehensible way about another layer of shit smeared on top of all the other incomprehensible layers of shit.
@ dikrek appears to be 'In Tune' with your blither so I guess 'That's FaceBook'.
First time I met a DataBase, back in Mumble Something and Four it was broken.... looks like 'we' have not made much progress since then.
VVOLs certainly are very exciting and has the potential to really shake up the storage world for vSphere and storage admins/designs; however in my opinion it will be a slow burn. Not everything will warrant to be VVOL deployed either, there's still room and need for traditional VMFS, especially for low-end VMs.
Also, VVOLs really just expose the storage platform capabilities to the vSphere Admin... so if the backend is a "legacy" storage system based on controller "SP' mappings, Aggregates, tiers, RAID sets, disk types, or segregated landing areas, then that is the capability exposed withi VMware to the vSphere Admin... potentially not something makes a lot of sense and could be quite dangerous.
If anyones interested I recorded and published a deep-dive presentation and live demonstration of Nimble Storage's VVOL integration beta, available on YouTube here: https://www.youtube.com/watch?v=iBS_MZlpYtk
"Why aren't VVOLs everywhere"?
Because the very few arrays that support VVOLs are stupidly expensive and deliver an ass-tier value/$. When VVOLs start showing up in storage systems people actually want to buy, you'll see increased usage. Imagine that.
Of course, by the time the crusty old dinosaurs remove their over-inflated heads from their asses and figure that one out, hyperconvergence will be an unstoppable juggernaut and VVOLs will be nothing more than a quaint means of making legacy storage less horrible for those unfortunate enough to be stuck having to cling to the past. (And don't get me started on "it only works with the stupid expensive licensing tier" bit.)
Companies don't make money resizing LUNs. They make money doing stuff with their workloads. VVOLs was a nice step, but too little, too late, too expensive.
Yes, yes, I realize that there is a whole category of large enterprises that give negative fucks about the price of anything. What should be noted, however, is that they are shoving their piles of burning cash at Amazon, not at keeping on premises stuff going. If you're going to pay too much for IT, why not get someone to take care of most of it for you while you're at it?
That leaves VVOLs and legacy storage vendors where, exactly? All clamoring for the same, shrinking piece of pie? That increasingly mythical large enterprise that just doesn't care how much anything costs, they'll splash the cash because you take them out for hookers and beer?
Have fun with that, legacy storage vendors. Write me a post card from the other side of the grave.
Dinesh from HDS
Benefits from VVol framework are undeniable e.g. snapshot, storage reclamation, VMDK replication. Customers are putting test/dev workloads on VVol datastore and with VVol 2.0 release, I foresee accelerated adoption.
Regarding scale, Hitachi VSP G1000 allows 64 K active VVols with 1M snapshots. For more on VVol, please read this white paper
hds.co/ck
The traditional storage architectures are, er, painful to work with, to say the least. VVOL hoped to bring a level of automation but you can only do so much to hide the complexity of traditional storage. Hence the low uptake is not that surprising.
If however you include relatively newer software defined storage architectures in the discussion, you might see how VVOL is actually becoming helpful (in automation, offloading), and might come across more customer examples. Atlantis was the first SDS vendor, and AFAIK the only HCI vendor so far to support VVOL. And it doesn't bring the problem of massive LUN proliferation with VVOL support (like other traditional storage vendors).
It actually brings some real benefits, like all cloning/snapshot operations done in vCenter are offloaded to Atlantis on the backend. It not only brings VM level snapshot granularity at storage level, it also makes those operations deduplication-aware (so making clones is just metadata manipulation). In some ways, these are similar to VAAI offloads but with more automation possibility.
And of course, it goes without saying, if your storage array doesn't support VVOL, Atlantis can bring that support by virtualizing any underlying storage (Disk, Hybrid, Flash, JBODs, whatever). More here:
https://portal.atlantiscomputing.com/documents/other/Event-Materials/AtlantisConnect2015/Atlantis-Connect-VVOL-presentation.aspx
At least I am seeing more customers getting on vSphere 6.0 U1, and then kicking off automation projects around VVOLs.
/*Atlantis employee obviously*/
Who is the vsphere admin, the network(ethernet) admin, the network(fibe channel) admin, the storage admin etc.. VVOLs sound pretty cool, look pretty cool but right now none of the capabilities are needed by my org(approaching 700 VMs in a SaaS environment e-commerce company).
I decided to look at what vmware says vvols aim to help address( http://blogs.vmware.com/vsphere/2015/08/vvols-a-game-changer-for-business-critical-databases.html ):
Database Performance to meet strict SLAs
-----------------------------------------------------------------------
Our existing systems already easily meet and exceed those SLAs, so there is no issue to address here for us.
Daily Operations e.g. Backup & Recovery to complete in set window
------------------------------------------------------------------------------------------------------
backup and recovery for the most part are managed outside of vmware, so really nothing to address here either. We do NOT use things like VM-based replication or whatever, we designed the systems so that data and OS are separate and configuration is handled, for the most part, with a configuration management platform(chef in our case).
Cut down time to Clone / Refresh of Databases from Production
------------------------------------------------------------------------------------------------------
I've had a system in place leveraging snapshots and software iSCSI directly to guest VMs for this exact purpose for at least 7 years now(across multiple companies, the process has evolved over time). Sample architecture for current system:
http://elreg.nateamsden.com/MySQL%20Snapshot%20diagram%20for%20Staging.png
(to me about 97% of the steps involved in that process do NOT involve storage)..
I have to use software iSCSI because of a "bug" introduced in vSphere 4.0
http://www.techopsguys.com/2009/08/18/its-not-a-bug-its-a-feature/
So again no problem to address here.
Meet different IO characteristics and capabilities based on criticality
---------------------------------------------------------------------------------------------------------
No issues here either, things are pretty simple for our setup. I/O contention is not a problem, pretty much ever, and when it can become one with the insight and access I have I can address it in a matter of minutes. This has happened for one workload in the past 2 years that I can think of.
So again no problem to address here for us anyway.
Never ending debate with DBAs
-----------------------------------------------------------------------------------------------------------------
The last DBA I worked with who ran a "performance" test against our original 3PAR SAN at my current org 5 years ago said it worked awesome, I looked at the 3PAR stats and it showed him hardly hitting the disk at all. There was no debate, he was happy, I was happy.
File Systems v/s Raw Devices (VMFS v/s RDM)
---------------------------------------------------------------------------------------------------------------------
All of my even remotely critical databaes are RDM, for SAN snapshots, always have been. I realize this doesn't scale to the end of the earth but has more than enough scalability for all of the companies I have worked at for the past 10 years.
So they are solving problems that I do not have, so I don't need VVOLs.
The one part I was looking forward to with VVOLs is better per-VM I/O monitoring. That was a pain point I had for a long time. But I have deployed a solution that provides that about 18 months ago, it's called LogicMonitor(SaaS offering) which ties into vCenter and grabs 10,000+ data points a minute from it for all of our VMs and ESXi hosts. I adapted my existing 3PAR monitoring to use their platform which adds another 12,000+ data points a minute from our 3PAR arrays (also I have dashboards for our load balancers, firewalls, our more critical applications, ethernet switches, FC switches everything it is by far the best infrastructure level graphing and dashboarding I have ever seen in my career and I have been writing custom monitoring stuff for at least 18 years now). I created simple dashboards so I can see "top 10" volumes, disks, latency, VMs, reads, writes, whatever.
Two easy reasons for the lack of adoption, from customers as well as storage vendors.
1) The VASA2 spec wasn't ever going to be widely adopted. It was a 1.0 product, lacked a number of core features, and required upgrading to a x.0 version of ESXi/vCenter to put it in place.
2) Once storage vendors started to get their heads around the resources (not just volume count) that it was going to demand, and how important the VASA provider was going to be from an availability standpoint (figure out how many VMs you can power on when the VASA provider is unavailable...) there were some major re-assessments of how to implement the tech and how to make it scalable and well performing.
All of these issues are being fixed, on both sides. The operational simplicity of the Vvols model can't be discounted, and once the back-end is ready for prime time, it'll be adopted much more quickly. Give it time.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
