2013-10-15 16.55.482013-10-15 17.01.26

This session was a session presented by Dinesh Nambisan (Sr. Director of the Virtual SAN (VSAN) Engineering at VMware and Cormac Hogan, Senior Technical Marketing Architect at VMware.

VSAN is not a product that is currently shipping, but it is in a public BETA phase right now. If you want to sign up and give it a try or only want to see what information is available about VSAN you’re invited to do so at VSANBETA.COM

For VMware VSAN to work you need at least one unused SSD and 1 magnetic disk per host and a minimum of three hosts.

The magnetic drives are forming the VSAN capacity. The SSDs are only used for acceleration purposes, all writes will go to SSD. If you sized your SSD correctly, also all reads will come from SSD. There is a lot of information available at VSANBETA.COM where as mentioned earlier you can sign up and take a look at all the documentation including sizing guidelines.

The VSAN datastore is an object store, so not a vmfs, in this case all vmdk’s all are objects.

Speaking of objects there are four type of objects:

  • vm home
  • vmdk
  • delta
  • swap

These objects may be distributed across the hosts and disks in de VSAN cluster. VMs may have a replica copy for availability or stripe.

VSAN scale out storage is radically simple. Just put an extra host in the cluster. If the cluster is in automatic mode it automatically expands the VSAN storage. Even if you add an host without the pre-reqs (e.g. no disk available), it does not add storage to the VSAN, but can access the datastore and have VM placements. Best practice however is to keep the configuration of all hosts in the cluster identical.

The key components of the virtual san are policies. Which is more complex.

Policies are more or less the same as storage DRS policies as we know them now.

Some policy examples:

  • Number of disk stripes per object
  • Number of failures to tolerate
  • Object space reservation – thickness factor, all VMs are provisioned thin by default
  • Flash read cache reservation – allows a portion of the read cache reserved specifically for this VM
  • Force provisioning – allows to roll out VMs, even if they do not meet the policies you’ve set, comes in handy when resources temporary are not available. It will comply automatically when resources are available. When the VM is not compliant with any policy you’ve set it shows so in the vSphere web client, which is by the way the only way to manage VSAN, not through the c# vSphere Client.

Best practices for setting VSAN policies

The default policy will give you protection for host failures, so do not touch the settings unless there are specifically needs for it, use it with caution!

Deploying the VSAN is pretty straight forward.

Quorum disk concept is used to prevent a split brain scenario. In the web client you can have a visual layout of all the VMDKs across the VSAN. All VM io is directed to SSD, writes are later restaged to sas/sata disks

Maintenance mode options

You can use policies to manage the way vm’s can tolerate failures:

  • Disk failure
  • Ssd failure
  • Network failure
  • Server failure

After 60 mins of a host failure it is assuming the host is dead and reorganize automatically. This is configurable and you can override this if needed. 

Performance monitoring

Performance monitoring can be done using:

  • Esxtop
  • Performance manager ui
  • Rvc & observer (vcenter 5.5)

Demo (sorry for the quality, but it gives an idea of how things work)

#STO5027 Demo of deploying a Virtual SAN (VSAN) from Gerben Kloosterman on Vimeo.

 

Q&A

Q:Is VSAN capable of running in a Stretched cluster scenario?

A: Lots of people asked this, now we do not know what kind of form it will be, but R&D is looking at creating some sort of fault domains and a rule could be not to put two replica’s in one fault domain. We are definitely looking into this. 

Q: How big can the cluster be, how many hosts?

A: The maximum hosts participating in a cluster is now set at 8, now as in the beta, it is a soft limit, so there is no enforcement. The roadmap will be to follow the number of hosts. Besides that, all hosts that are in the cluster must participate, you cannot have a subset of hosts that are not participating in the same cluster.

Q: Is there a way you can migrate from an existing VSAN (lefthand for example)?

A: That is not really supported with special migration tooling but it should be possible to move gradually, host by host.

Q: Is there any support for vCloud Director?

A: vCloud director is supported

Q: How about when vCenter shuts down, what happens, is there a dependency?

A: vCenter is not critical for operating VSAN or dataloss.

 

2 Responses to #STO5027 VMware Virtual SAN Technical Best Practices

  1. […] and VMDK placement (viktorious.nl) VMware Virtual SAN Scalability Limits – VSAN (Virtual-blog) STO5027 VMware Virtual SAN Technical Best Practices (virtualarchitect.nl) VSAN and Storage Controllers (VMware vSphere Blog) Virtual SAN & Disk […]

  2. […] VSAN – Virtual SAN (Virtual-blog) VMware Virtual SAN Scalability Limits – VSAN (Virtual-blog) STO5027 VMware Virtual SAN Technical Best Practices (virtualarchitect.nl) How to quickly setup and test VMware VSAN (Virtual SAN) using Nested ESXi […]

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>