Preamble: NFS works great for ESX datastores. Its a whole lot easier to manage than iSCSI and although iSCSI is generally considered to perform better, we find that the flexibility of using NFS more than makes up for the lost performance.
If you have sufficient budget, there are great solutions from Dell, HP etc. where you can get fault-tolerant ESX installations already setup in a rack, which not only provide data-store fault tolerance, but also VM failover and so on. But there’s a lot of people or companies out there who have several servers running the free ESX5i hypervisor and who would still like to have some fault-tolerance. This article is for those people.
What’s not so great about shared storage (like NFS or iSCSI) is that you generally have a lot of extra boxes around and complicated network configuration. If you want fault tolerance, you’ll need two ESX servers, two NFS servers and two switches (and a bunch of cables to connect them all). Furthermore, you’ll add a lot of complexity to configure those (often proprietary) NFS boxes. I recently configured a couple of Lefthand boxes for a customer and it not trivial to set up.
So I figured there must be an easier way – after all, ESX is an amazing platform for reducing the number of boxes in the rack, so why would I want to start adding boxes again if I don’t have to.
The first important point is that ESX provides the VMXNET3 10Gb virtual ethernet adapter, so that even if your ESX server does not have 10Gb network cards, the VMs running on the server can communicate with each other at 10Gb and, more importantly for our purposes, ESX itself can communicate with its VMs at 10Gb speeds. So if we run an NFS server as a VM on the ESX server, and use it as an NFS datastore for the ESX server, then the server will see it as a 10Gbps NFS server.
OK, but what about the fault-tolerance? For that, we need to replicate the NFS server’s disk to another server. So, if we don’t have a real 10Gb network, that’ll have to be across 1Gb. Does that slow things down? Apparently not much – we’re using DRBD asynchronously which causes a minimal performance hit.
So what we do is to clone the NFS server VM to a second ESX server and set up DRBD replication between the two VMs. We’re using Ubuntu 11.10 server (you’ll need a reasonably recent Linux distribution to get the 10Gbps support with the VMXNET3 virtual network adapter).
Because you only get the 10Gbps datastore access to the NFS server when the NFS VM is hosted on the local ESX server, this is not really shared storage (or at least its shared only at 1Gbps to other ESX servers). However, for our fault-tolerance purposes that doesn’t matter much. In fact, from a scalability point of view, it makes sense to provide each ESX server with a locally-running NFS datastore, accessed at 10Gbps and replicated to another ESX server. This scheme also has the advantage that each ESX server is autonomous – ESX servers with remote datastores always make me a bit nervous – any problems on the network and the VMs are likely to freak out. This way, the ESX server is completely self-contained – it only needs another ESX server for fault-tolerance. Even if the network fails, the local NFS datastore will be unaffected (except that fault-tolerance is temporarily suspended) and when the network is available again, the DRBD secondary will simply catch up again automatically, providing fault-tolerance again.
ESX Server 2 can do the same thing with another pair of NFS servers (a local one for fast access and a remote one on ESX Server 1 for fault tolerance). This idea can be scaled indefinitely – each ESX server having its own local NFS VM running its datastore and replicating to another ESX server. The major advantage of this approach is that its more scalable than a single fault-tolerant pair of shared NFS servers and you get 10Gbps access for free. Conversely, the price you pay for this is that you have a separate NFS server for each ESX server which makes administration more complex than for a single shared datastore (but hey, you can’t have everything, at least not for free).
You could additionally configure the nfs servers to fail over a shared ip address to the secondary – we haven’t bothered to do this since if the primary nfs server fails, its likely that the whole ESX server has failed. If that’s the case, we need to promote the DRBD secondary to primary manually, start the NFS server and register the VMs.
And how does it perform? Pretty well actually. The benchmarks below are made on an ESX5 host with a single i7 930 CPU, 24GB RAM, an Adaptec 5405z controller and 4x SATAII disks in RAID5.
Disk performance of a VM running directly on the ESX host (i.e. on the local datastore).
hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 12396 MB in 2.00 seconds = 6201.81 MB/sec
Timing buffered disk reads: 398 MB in 3.00 seconds = 132.59 MB/sec
dd if=/dev/zero of=ddfile bs=8k count=20000
20000+0 records in
20000+0 records out
163840000 bytes (164 MB) copied, 0.274105 s, 598 MB/s
And now the disk performance of a VM running on our fault-tolerant nfs datastore:
hdparm -tT /dev/sda
/dev/sda:
Timing cached reads: 12242 MB in 2.00 seconds = 6124.43 MB/sec
Timing buffered disk reads: 258 MB in 3.00 seconds = 85.89 MB/sec
dd if=/dev/zero of=ddfile bs=8k count=20000
20000+0 records in
20000+0 records out
163840000 bytes (164 MB) copied, 0.707547 s, 232 MB/s
As you can see from the above, the VM running on the fault-tolerant NFS datastore is not as fast as the VM running on the local datastore, but it’s sufficiently fast for the subset of your VMs which require more fault-tolerance than that provided by daily backups.
Speaking of backup, we’re using ghettoVCB to backup 150 VMs (>1TB) every night via NFS to a Netgear ReadyNAS Ultra 6 device. We then rsync them to a remote data-center for offsite, versioned storage.