As I have given various people already individually the formulas needed to calculate how much bandwidth is required I figured I would share this as well. If you are doing a stretched VSAN design you will want to read this excellent paper by Jase McCarty. This paper describes the bandwidth requirements between the “data sites” and from the data sites to the “witness site”. It provides the formula needed, and it will show you that the “general guidelines” provided during launch were relatively conservative. In many cases especially the the connection to the witness location can be low bandwidth. Just have a read when you are designing a stretched VSAN and do the math.
Over the last couple of weeks I have been presenting at various events on the topic of Virtual SAN. One of the sections in my deck is a bit about the future of Virtual SAN and where it is heading towards. Someone tweeted one of the diagrams in my slides recently which got picked up by Christian Mohn who provided his thoughts on the diagram and what it may mean for the future. I figured I would share my story behind this slide, which is actually a new version of a slide that was originally presented by Christos and also discussed in one of his blog posts. First, lets start with the diagram:
If you look at VSAN today and ask people what VSAN is today then most will answer: a “virtual machine” storage system. But VSAN to me is much more than that. VSAN is a generic object storage platform, which today is used to primarily store virtual machines. But these objects can be anything if you ask me, and on top of that can be presented as anything.
So what is it VMware is working towards, what is our vision? VSAN was designed to serve as a generic object storage platform from the start, and is being extended to serve as a platform to different types of data by providing an abstraction layer. In the diagram you see “REST” and “FILE” and things like Mesos and Docker, it isn’t difficult to imagine what types of workloads we envision to run on top of VSAN and what types of access you have to resources managed by VSAN. This could be through a native Rest API that is part of the platform which can be used by developers directly to store their objects on or through the use of a specific driver for direct “block” access for instance.
Combine that with the prototype of the distributed filesystem which was demonstrated at VMworld and I think it is fair to say that the possibilities are endless. VSAN isn’t just a storage system for virtual machines, it is a generic object based storage platform which leverages local resources and will be able to share those in a clustered fashion in any shape or form in the future. Christian definitely had a point, in which shape or form all of this will be delivered has to be seen though, this is not something I can (or want) to speculate on. Whether that is through Photon Platform, or something else is in my opinion besides the point. Even today VSAN has no dependencies on vCenter Server and can be fully configured, managed and monitoring using the APIs and/or the different command-line interface options we offer. Agility and choice have always been the key design principles for the platform.
Where things will go exactly and when this will happen is still to be seen. But if you ask me, exciting times are ahead for sure, and I can’t wait to see how everything plays out.
This week I flew to Staines (that is where VMware’s European HQ is these days) to record a video for the Online Technology Forum. For those who don’t know what it is, it is similar to a vForum but in this case you don’t even need to get out of your comfortable chair… you can attend it from home / the office. My session was all about Software Defines Storage, where we are today and where we will be tomorrow. In my session I will discuss things like VSAN, VVols and VAIO. Primarily around what was announced at VMworld, but also with a hint of what is coming for all three of these in the future.
Of course it isn’t just my session. During the Online Technology Forum, which is held on Wednesday the 25th of November, there are many great sessions held by folks like Joe Baguley (keynote), Paul Nothard (vSphere), Mike Laverick (EVO:RAIL), Lee Dilworth (VVol/VSAN) and folks like Robbie Jerrom who is going to tell you all about Cloud Native Apps and those container thingies. And that is not it, Automation / Orchestration / EUC / Networking etc… All part of the agenda.
On top of that, during the sessions you have the ability to ask your questions to a panel of experts who will answer them live online. After my session there also is a live Q&A panel where you can ask your questions directly to one of the experts one the panel (I am one of them, and I believe Joe Baguley is the moderator.)
This event was a huge success 6 months ago, and I don’t expect anything less this time around. Make sure to sign up today and tune in next week.
I have a whole bunch of VMUGs on the agenda in the upcoming month that I wanted to inform you about. For those who have never been to a VMUG, they are “user group” meetings where usually you see community people presenting and vendors presenting. The setting is a bit more informal which allows you to have discussions with fellow users during breaks, ask questions during session and meet up with people from VMware and other vendors who attend. In the upcoming weeks I will be delivering sessions at my favourite VMUGs in the world, if you are in the neighbourhood make sure to attend. These are free events, so you just need to free up some time from work to attend. If you do attend, don’t hesitate to stop by to say hi!
- Thursday November 12th – Italy VMUG – Milan / Italy
- Awesome event in a great city with people like Lee Dilworth, Chad Sakac and Vaughn Stewart. I can ensure you that this is going to be a great event. A lot of the sessions will be in English by the way, judging by the people who are presenting. Also, what I love about Italy is the passionate community they have, one of those events where I spend talking to users/partners/customers and bloggers most of my time.
- Thursday November 26th – Scottland VMUG / Edinburgh
- Although this is a “smaller” event it doesn’t mean the agenda isn’t top notch. With Joe Baguley delivering the keynote and people like Paul Nothard, Robbie Jerome and Andy Jenkins from VMware presenting this is going to be a great day.
- Tuesday December 1st – Nordics VMUG (Denmark) (Usercon)
- Keynote by Paul Strong and a line-up of great speakers like William Lam, Paudie O’Riordan, Cormac Hogan, Ole Agesen, Christian Mohn and Joerg Lew. Strongest line-up I have seen in a very very long time at an event with a very interesting closing speaker which is the first Danish astronaut Andreas Mogensen. I expect this event will fill up, so register today! Most sessions will be in English, so whether you are from Sweden, Finland, Norway or Germany… you can’t miss out on this one!
So if you live close to any of these VMUGs, I expect to see you there. I will be delivering a session on VSAN at each of these events and are more than happy to talk about anything else before or after my session. I will also bring some cool Captain VSAN stickers for those who want to pimp their laptops / office etc. Hope to see you all there.
It seems that a lot of people haven’t picked up on this… With Virtual SAN in the past, or better said with vSphere, booting from SATADOM was not supported. This had to do with the default location of the scratch partition, the number of expected writes to the SATADOM device and simply the fact that we did not know how fast the device would wear out.
For those who don’t know, SATADOM devices are basically flash chips on a SATA module which usually directly goes on the motherboard. Great solution as it is as fast as SSD, as small as SD/USB which means you don’t lose a disk slot.
After many tests over the last year it was concluded that SATADOM can be fully supported for vSphere and Virtual SAN but that there are some requirements for the device itself:
- When you boot a Virtual SAN host from a SATADOM device, you must use:
- single-level cell (SLC) device
- The size of the boot device must be at least 16 GB.
Again, key reason for this is that all the trace logs and vSphere logs (etc) end up on this device and we don’t want it to wear out and cause all sorts of unexpected behaviour. As our documentation says: It is important that the SATADOM device meets the specifications outlined in this guide!
Anyway, now you know… more options when it comes to booting ESXi supported, which especially is handy when you want to use your disk slots for Virtual SAN!