I’m thrilled to have had a session accepted at this year’s VMworld. I’m also going to be a co-speaker on another session. As you might have guessed, both presentations are on Virtual SAN (VSAN), and I am co-presenting both sessions with my buddy Paudie O’Riordan.
In the first session, we will be talking about how to conduct a successful proof of concept (PoC) on VSAN, which will cover how to prepare, how to test, and what gotchas you need to be aware of when going through a PoC with VSAN.
In the other session, which covers day #2 operations, we will cover items like upgrades, troubleshooting, remediation, and monitoring of VSAN, and all those other things that you need to care about when you have VSAN in production.
If you have any thoughts on what you would like to see covered during the session, please leave a comment. We’re still putting together the content, and we are wide open to suggestions.
I’m delighted to announce the availability of a joint Rubrik and VMware Virtual SAN (VSAN) white paper. Both Rubrik and Virtual SAN epitomize many of the features and characteristics of Software Defined Storage, in particular simplifying storage and backup/restore for vSphere Administrators. Other features include abstracting the underlying storage into one large pool, and consuming/utilizing that underlying storage through policies, whether these are for virtual machine deployment or backup. If you are completely new to VSAN and/or Rubrik, this paper gives a good explanation of both technologies. The paper also explains how Rubrik and VSAN work seamlessly together to back up and restore virtual machines deployed on VSAN.
I should also mention that my co-author was none other than the one and only Chris Wahl, and as always, it was a pleasure to work with him on this paper.
I’d like to thank Chris, Julia and Sara of Rubrik for their attention to detail on this paper. I think it has turned out extremely well, and we hope you get a lot of good information from it.
This is a really cool development. There is now a docker volume driver for vSphere which we just made public last night, and is now available for tech preview. This will allow customers to address persistent storage requirements for Docker containers in vSphere environments. Basically, it allows you to create a VMDK, and use this VMDK as a persistent storage volume for containers. In the following posts, I will outline the steps involved in getting started with Docker Volume Driver for vSphere. In essence, there are 4 steps:
Install the docker volume plugin on ESXi host. I was running ESXi 6.0U2.
Deploy Photon OS VM (although you can also use Ubuntu)
Install the docker VMDK plugin on VM
Create docker volume and run container to consume it
Every week, the VMware Storage and Availability Tech Marketing team (John Nicholson and Pete Fletcha) run a podcast show called the Virtually Speaking Podcast. This week I am a guest on their show, alongside Rich Peterson of FlashSoft. We spoke about VAIO, the new vSphere APIs for I/O Filters. While I described some basic features on VAIO, Rich describing the Cache Acceleration VAIO implementation for FlashSoft 4.0, created by the FlashSoft team over at SanDisk. This is the first fully certified VAIO implementation and I wrote an article about it last month that you can read here if you wish.
You can listen to the podcast through the player below. I hope you enjoy it.
I spent the last 10 days in the VMware HQ in Palo Alto, and had lots of really interesting conversations and meet-ups, as you might imagine. One of those conversations revolved around the minimum VSAN configurations. Let’s start with the basics.
2-node: There are two physical hosts for data and a witness appliance hosted elsewhere. Data is placed on the physical hosts, and the witness appliance holds the witness components only, never any data.
3-node: There are three physical hosts, and the data and witness components are distributed across all hosts. This configuration can support a number of failures to tolerate = 1 with RAID-1 configurations.
4-nodes: There are four physical hosts, and the data and witness components are distributed across all hosts. This configuration can support a number of failures to tolerate (FTT) = 1 with RAID-1 and RAID-5 configurations. This configuration also allows VSAN to self-heal in the event of a failures, when RAID-1 is used.
Last week I had the opportunity to drop down to San Jose and catch up with our friends on the FlashSoft team at SanDisk. In case you were not aware, this team has been developing a cache acceleration I/O filter as part of the VAIO program (VAIO is short for vSphere APIs for I/O Filters). SanDisk were also one of the design partners chosen by VMware for VAIO. This program allows for our partners to plug directly into the VM I/O path, and add third-party data services, such as replication, encryption, quality of service and so on. An interesting observation made by the FlashSoft team is that implementing their acceleration data service via VAIO gives much greater performance than their previous product version which plugs into the Pluggable Storage Architecture (PSA) stack.
The guys were also kind enough to give me access to the components and some evaluation licenses, so I could test it out in my own labs. The documentation is pretty good so I won’t go into too much detail. However these are the steps to get going:
We had an interesting event happen on one of our lab servers this weekend. One of the hosts in our four node cluster hit an issue, which meant that the storage on that host was no longer available to the VSAN datastore. Since VSAN auto-heals, it attempted to re-protect as many VMs as possible. However, since we chose to ignore one of the health check warnings to do with limits, we ended up with a full VSAN datastore.