initial commit

content/blog/open-source-virtual-san-thought-experiment/index.md

@@ -0,0 +1,37 @@
+---
+date: 2013-09-05
+title: Open Source Virtual SAN thought experiment
+category: Opinions
+---
+
+Okay, I know I am little slow on the uptake here, but I was on holiday
+at the time. The announcement of [Virtual
+SAN](https://www.vmware.com/products/virtual-san/) at VMWorld the last
+week got me thinking a bit.
+
+Very briefly, Virtual SAN takes locally attached storage on you
+hypervisors. It then turns it into a distributed object storage system
+which you can use to store your VMDKs.
+[Plenty](https://www.yellow-bricks.com/2013/09/05/how-do-you-know-where-an-object-is-located-with-virtual-san/)
+[of](https://www.computerweekly.com/news/2240166057/VMware-Virtual-SAN-vision-to-disrupt-storage-paradigm)
+[other](https://chucksblog.emc.com/chucks_blog/2013/08/considering-vsan.html)
+[people](https://architecting.it/2013/08/29/reflections-on-vmworld-2013/)
+have gone into a lot more detail. Unlike other systems that did a
+similar job previously this is not a Virtual Appliance, but runs on the
+hypervisors themselves.
+
+The technology to do this sort of thing using purely Open Source exists.
+All this has added is a distributed storage layer on each hypervisor.
+There are plenty of these exist for Linux, with my preference probably
+being for GlusterFS. Something like this is what I would have in mind:
+
+{% img center <https://i.imgur.com/NHYdf78.png> %}
+
+Ceph is probably the closest to Virtual SAN, as it is fundamentally
+object-based. Yes there would be CPU and RAM overhead, but that also
+exists for Virtual SAN too. Something like DRBD/GFS2 is not really
+suitable here, because it will not scale-out as much. You would not have
+to have local storage in all your hypervisor nodes (as with Virtual SAN)
+too.
+
+I honestly do not see any real problems with this.