Information Technology Reference
In-Depth Information
What does a guest OS see during this period? It sees a nonresponsive SCSI disk on the vSCSI
adapter (similar to the failover behavior of a Fibre Channel or iSCSI device, though the inter-
val is generally shorter). The disk time-out is how long the guest OS will wait while the disk is
nonresponsive before throwing an I/O error. This error is a delayed write error, and for a boot
volume it will result in the guest OS crashing. Windows Server, for example, has a disk time-
out default of 60 seconds. A recommendation is to increase the guest OS disk time-out value
to match the NFS datastore time-out value. Otherwise, the VMs can timeout their boot storage
(which will cause a crash) while ESXi is still waiting for the NFS datastore within the longer
time-out value. Without extending the guest time-out, if vSphere HA is coni gured for VM
monitoring, the VMs will reboot (when the NFS datastore returns), but obviously extending the
time-out is preferable to avoid this extra step and the additional delay and extra I/O workload it
generates.
Perform the following steps to set operating system time-out for Windows Server to match
the 125-second maximum set for the datastore. You'll need to be logged into the Windows
Server system as a user who has administrative credentials.
1.
Back up your Windows Registry.
➢
2.
Select Start
Run, type
regedit.exe
, and click OK.
3.
In the left panel hierarchy view, double-click HKEY_LOCAL_MACHINE, then System,
then CurrentControlSet, then Services, and then Disk.
4.
Select the TimeOutValue value, and set the data value to 125 (decimal).
There are two sub-cases of NFS that we want to examine briel y before we start showing you
how to create and manage NFS datastores: large bandwidth workloads and large throughput
workloads. Each of these cases deserves a bit of extra attention when planning your highly
available design for NFS.
Supporting Large Bandwidth (MBps) Workloads on NFS
Bandwidth for large I/O sizes is generally gated by the transport link (in this case the TCP ses-
sion used by the NFS datastore being 1 Gbps or 10 Gbps) and overall network design. At larger
scales, you should apply the same care and design as you would for iSCSI or Fibre Channel
networks. In this case, it means carefully planning the physical network/VLAN, implementing
end-to-end jumbo frames, and leveraging enterprise-class Ethernet switches with sufi cient buf-
fers to handle signii cant workload. At 10 GbE speeds, features such as TCP Segment Ofl oad
(TSO) and other ofl oad mechanisms, as well as the processing power and I/O architecture of
the NFS server, become important for NFS datastore and ESXi performance.
So, what is a reasonable performance expectation for bandwidth on an NFS datastore? From a
bandwidth standpoint, where 1 Gbps Ethernet is used (which has 2 Gbps of bandwidth bidirec-
tionally), the reasonable bandwidth limits are 80 MBps (unidirectional 100 percent read or 100
percent write) to 160 MBps (bidirectional mixed read/write workloads) for a single NFS data-
store. That limits scale accordingly with 10 Gigabit Ethernet. Because of how TCP connections
are handled by the ESXi NFS client, and because of how networking handles link selection in
link aggregation or layer 3 routing decisions, almost all the bandwidth for a single NFS datas-
tore will always use only one link. If you therefore need more bandwidth from an NFS datastore
than a single Gigabit Ethernet link can provide, you have no other choice than to migrate to 10
Gigabit Ethernet, because link aggregation won't help (as we explained earlier).
