Scaling VSAN: Adding a New VSAN Host

In my previous post, VMware VSAN Meets EZLAB, I highlighted the implementation of VSAN into my vCloud lab. At the time of writing, 1 of 4 my vSphere hosts was down for maintenance and was not added to the VSAN cluster. Now that it’s back online, I thought I would share the experience of adding a new VSAN host…and another 2.25TB of capacity.

Here’s a “before” shot — 3 hosts configured with 6.13TB total capacity…

Step 1: Add the host to the existing VSAN cluster: I’m pretty sure I don’t have to review how this is done. Once added, configure all settings to match the other hosts in the cluster…in my setup I’m using a dedicated pNIC and vmkernel port (vmk1) for all storage traffic.

Adding new host to the vSphere cluster

The local storage of the new host, a Dell R610 box, is configured identically to the other
three — 1 x 256GB SSD + 3 x 750GB SATA drives. And since it is
identical, that also means I had to deal with the fact that the PERC 6/i
controller does not support JBOD. So, I stepped through the work-around to identify the SSD as such…

before…the SSD show up as “Non-SSD”


“esxcli storage…” command executed on host



the SSD is now recognized as an SSD drive


Step 2: Enable VSAN Service on the vmk port…

Configure vmk for VSAN traffic

Step 3: Disk Management…

Since my VSAN cluster is configured to “Manual” mode, adding the new host’s disks to the cluster takes an additional step.…

VMware VSAN meets EZLAB

Let me just get this out of the way – I’m a HUGE fan of VSAN (aka VMware Virtual SAN). I was first in line to drink the kool-aid when VSAN was nothing but a “what if…?”. Fast forward to the present — VSAN beta (refresh) is backing my entire lab. I’m tweaking, testing, breaking (learning), and sharing my thoughts on VSAN’s capabilities, performance, and benefits ahead of the official launch. This is all in good order because even the beta has exceeded my expectations in what VMware would ship as a 1.0 product.

I can write page after page about the ins-and-outs of VSAN, but fortunately several very respected individuals have already done so. For starters, Duncan Epping at yellow-bricks.com not only is a massive contributor to the cause, but has also put together a nice list of VSAN resources from around the web that is a must-see. But lets face it, if you’re tracking VSAN you’ve probably already been there, done that 🙂  So for this post, I’m going to focus instead on my VSAN home lab build and experiences thus far. I’ve shared several preliminary stats on twitter (here, here, and here) ahead of any tweaking and will be sure to post additional results as I play with things a bit more.…

vCloud Networking: Using vShield Edge for Firewall & Routing (without NAT)

The Challenge: You are providing cloud services for a tenant using vCloud Director (obviously!) and want to provide a dedicated [routed] subnet and firewall services that are managed by the tenant admins.  Apps deployed in this cloud will be utilizing shared infrastructure services – LDAP, patching, scanning, etc – outside the cloud, so you’re trying to avoid NAT due to possible complications introduced by masking/translating source IPs.  Sound familiar?  Read on…
The release of vCloud Director (vCD) v1.5 along with vShield Edge (VSE) v5.0 provided a significant number of in-cloud networking enhancements that put a smirk on the faces of socially awkward cloud geeks everywhere.  Okay, I’ll admit it – the networking capabilities VMware has baked into vCloud Director have been one of the most intriguing components of the solution.  The combination of vCD 1.5 and VSE 5.0, riding on top of vSphere’s native networking capabilities, provide the framework for enhanced (and industry-leading) networking options for your cloud.  Check out the vCD 1.5 Technical Whitepaper for more info on these and other enhancements.
Here are the cliff notes for those who don’t care to read the marketing stuff:
  • improved network isolation at several levels within the cloud,
  • enhanced firewall capabilities,
  • baked-in VPN tunnels and the ability to securely stretch tenant networks across clouds,
  • enhanced NAT’ing flexibility,
  • the addition of static routes and layer-3 routing
Speaking of static routes and layer-3 routing (yep, that’s the best transition I can come up with), I have found many of my customers questioning what is actually possible with the use of these features.