Over the last couple of days I’ve been getting to grips with Photon Controller v0.8. For those of you who do not follow developments in our Cloud Native Apps BU, Photon Controller leverages ESXi hosts to provide compute and management for containers at large scale. It will also allow you to stand up container frameworks such as Kubernetes, Docker Swarm and Mesos very quickly. I’m not going to take you through the step-by-step instructions on how to do this as my colleague and good pal William Lam has already done this. Instead, I’m going to try to highlight some newbie issues that I have run into. Expect a few more of these over the coming weeks.
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.
Manish, Rich, Serge and Tom gave us another update on the 4.0 version of the FlashSoft product. I had seen this before, as the guys tech previewed it at VMworld 2015 last year. However with the release of FlashSoft 4.0, the guys now have the first certified VAIO I/O Filter on the market. SanDisk are our first certified partner for VAIO. Rich Petersen has a good write-up on the capabilities here on the SanDisk blog.
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:
This lab contains a bunch of new VSAN 6.2 features including erasure coding (RAID-5/6), checksum, sparse swap and dedupe/compression. You can also see the new health check views, performance metric views and capacity views.
Also included is a workflow that will guide you through configuring VSAN stretched cluster and remote-office/branch-office (ROBO) implementations, and how these features work with HA to restart VMs in the event of a failure.
The whole lab is modularised, so you can simply look at the features that interest you.
You can get access via the hands-on-lab portal – http://labs.hol.vmware.com/HOL/catalogs/catalog/123
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.
Before I get into this post, I do want to highlight that you probably will not do this in any production type environment. The reason why I implemented this, and how this post came about, is because I was helping out with our new edition of the VSAN 6.2. Hands-On-Lab (which should be available imminently by the way). Part of the lab involved demonstrating checksum functionality. Since VSAN has a distributed architecture, there was a requirement to run commands on different hosts. Rather than having lab participants input the password each and every time to run a command on the remote hosts, which becomes tedious very quickly, we decided to try to implement a public/private key pair, creating a trust between the ESXi 6.0U2 hosts and avoid having to input the password to run commands remotely. This proves a little problematic on ESXi hosts as not every file on ESXi is persisted on reboot. The following are the steps we implemented to allow us to do this in the lab.
Last week I wrote a post on Horizon View 7 on VSAN. That was all about showing the policies that were associated with the different desktops that can be deployed. I did mention that while one could use vmFork/Instant Clones for desktops, they did not include any sort of persistence. I did add a caveat to say that you could provide persistent storage to these desktops using App Volumes. In this post, I wanted to give some details on App Volumes, and the different moving components one will need if they want to deploy View desktops with App Volumes. However, I am only going to show the considerations around deploying AppStacks which is an application that is presented to the desktop via a read-only VMDK. I do not get into the specifics around writable volumes in this post, but this is also available via AppStacks. Hopefully this will be a good enough primer to get you started with App Volumes. I will say at the beginning that there is nothing unique about using VSAN in this case, other than the fact that policies can be used for the VMDKs. As you will see shortly, both the management cluster and production cluster both run VSAN, and I could use App Volumes and AppStacks with no issues.