VSAN – Page 32

VSAN Configuration Maximum Query Script

03.31.2014 by William Lam // 1 Comment

In addition to the vSphere Web Client, a great way to further explore VSAN in greater depth is by leveraging RVC and the new VSAN namespace on the command-line. If you have not played with the new the VSAN commands in RVC, Florian Grehl has written a fantastic series that is worth checking out here. While exploring the VSAN commands myself, one command that particularly stood out to me was the vsan.check_limits. The command provides a quick summary of the internal VSAN limits based on your current VSAN Cluster and configuration.

This actually got me thinking about the vSphere Configuration Maximums for VSAN and how manual of a process it is today to validate that you are currently running within the supported maximums not only for VSAN but for other areas as well. I thought it would be useful have a script that you could periodically validate the current VSAN configuration maximums against an existing VSAN Cluster. Creating this script was also a nice way for me to take what I have learned about the VSAN APIs over these last couple of weeks in my Exploring VSAN APIs series and build something that could be useful.

Disclaimer: These scripts are provided for informational and educational purposes only. It should be thoroughly tested before attempting to use in a production environment.

I created a vSphere SDK for Perl called vsanConfigMaximumCheck.pl which just accepts the name of a VSAN Cluster and will automatically check the current VSAN configuration maximums which I pulled out of the latest vSphere 5.5 Configuration Maximums document. It implements the majority of the configuration maximums that I thought made sense to display. This script works on any system with the vSphere SDK for Perl installed but does require one additional Perl Module called JSON. The script reports on the following VSAN configuration maximums:

VSAN Disk Groups per Host
Magnetic Disk per Disk Group
SSD Disks per Disk Group
Total Magnetic Disks in all Disk Groups per Host
Components per VSAN Host
Total VSAN nodes in VSAN Cluster
VMs per VSAN Cluster

Note: I also have plans on creating a VSAN vCheck report which is something I am still working on. Hopefully you will hear more about that very soon 🙂

Here is an example of running the script against VSAN Cluster called "VSAN-Cluster" by using the following command:

./vsanConfigMaximumCheck.pl --server vcenter55-1.primp-industries.com --username root --cluster VSAN-Cluster

Here is a screenshot of what the results would look like:

I personally think this information would be really useful to include in the vsan.check_limits RVC command but I also think it would be useful to have outside of RVC for any type of external reporting which can also leverage the vSphere API.

Exploring VSAN APIs Part 7 - VSAN Datastore Folder Management

03.26.2014 by William Lam // 1 Comment

In addition to storing your Virtual Machines, you may also want to use the VSAN Datastore to store your operating system ISOs in case you do not have an external repository and would like to keep everything local. If you use the vSphere Web Client to perform this operation, you will notice that you will need to first create a top-level directory before you can upload an ISO or a file to the VSAN Datastore.

The reason for this is that the VSAN Datastore does not support files in the top level directory, so you will have to first create a top-level directory and then upload the files under that directory. To create these top-level directories, a new DatastoreNameSpaceManager is introduced in the vSphere 5.5 API which manages the creation and deletion of these directories. Once these top-level directories exists, you can then use the regular fileManager API to manage your files and sub-directories within the VSAN Datastore. To demonstrate the creation of a top-level directory and sub-directory in a VSAN Datastore, I have created a sample vSphere SDK for Perl script called vsanDatstoreFolderMgmt.pl

Disclaimer: These scripts are provided for informational and educational purposes only. It should be thoroughly tested before attempting to use in a production environment.

In this example, I will create a top-level directory in the VSAN Datastore called ISO and then a sub-directory under that called Linux by running the following command:

./vsanDatstoreFolderMgmt.pl --server vcenter55-1.primp-industries.com --username root --vsan-datastore vsanDatastore --root-folder ISO --sub-folder Linux

The script will first call the DatastoreNameSpaceManager CreateDirectory() API method which will then create the top-level directory and then using the fileManager's MakeDirectory() API method to create the sub-directory. If we take a look at our VSAN Datastore using the vSphere Web Client, we can see that our new top-level directory has been created along with our sub-directory.

For deleting sub-directories and the top-level directories, there is the DeleteDatastoreFile_Task() and DeleteDirectory() API method respectively.

Quick Tip - Increasing capacity on a Nested VSAN Datastore

03.21.2014 by William Lam // 2 Comments

The other day I needed to increase the capacity on one of my Nested VSAN Datastores as one of our users required a larger VSAN datastore than it was initially configured for. I was expecting to be able to just increase the size of the underlying VMDKs like I would for a traditional Nested ESXi environment and rescan in ESXi to pick up the new capacity without any downtime. It turns out, this is was not exactly the case for a Nested VSAN environment.

Disclaimer: Nested Virtualization is not officially supported by VMware

When you first setup VSAN, regardless of how the disks were claimed, VSAN will consume the entire device (SSD or MD). The capacity that VSAN initially detects will then be used to create the necessary partition as part of the VSAN Disk Group creation. VSAN assumes that the capacity for the underlying devices would never change as in the "real" world, disks do not auto-magically get larger 🙂 and this is a valid assumption. In a Nested ESXi environment however, it can auto-magically get larger but VSAN was not built for this use case. What ends up happening is that the underlying devices can be "hot-extended" but the existing VSAN Disk Group can not detect this new capacity.

Having said that, there are two ways you can increase your VSAN datastore:

Option 1 - If you wish to preserve your VSAN Datastore, you can hot-add additional VMDK(s) to your existing VSAN Disk Group or if it is full, you can create a new disk group and add additional VMDK(s). This will modify your setup slightly if you wanted a particular set of disk groups but will allow you to preserve your data.

Option 2 - The latter option requires the deletion and re-creation of the VSAN Datastore which is not ideal if you already have data on it. You will need to increase the capacity of the underlying VMDKs and then re-create your VSAN Datastore, but this way you can keep the existing number of disks and disk groups you initially created your Nested ESXi environment with.

In my scenario, I could not destroy the VSAN Datastore as I had someone using it and so I opted for option #1. Here is what my configuration looked like before which was a single VSAN Disk Group with 1xSSD and 1xMD:

I then added an additional 10GB VMDK to each of my Nested ESXi hosts and issue a rescan so the ESXi host would pickup the new device:

In just a few seconds, I can see my new storage device. I can now head over to the VSAN management page which is located at the vSphere Cluster and once I refresh, I can see that VSAN has automatically added the new "MD" into the existing disk group and my storage has automatically expanded!