How to Modify the NFS Block Size (Non-Disruptive)

Transcription

1 How to Modify the NFS Block Size (Non-Disruptive) How To#: 7329 Title: How to Modify the NFS Block Size (Non-Disruptive) Table of Contents Overview Risks Scope Resolution Prerequisites ESXi Hosts SimpliVity ESXi Hosts Non-SimpliVity Hosts OmniStack Virtual Controller UnMount ESXi Datastores Customer Support Updating the NFS Max Block Size on the OVC Article Information Properties Server Platform: All server platforms OmniStack Software Version: v and later Information Level: 1 Date Created: Wednesday, June 15, 2016 Date Revised: Monday, February 6, 2017 Overview This article explains how to change the NFS Block Size for datastores exported from the OmniStack Virtual Controller (OVC) to the SimpliVity OmniStack ESXi host(s) or non-simplivity ESXi host(s). Risks Rolling NFS block size changes can be performed, but they are highly complex and subject to error. SimpliVity recommends performing block size changes during outage windows to eliminate possible data unavailability (DU). If an outage window is not an option, SimpliVity recommends performing NFS block size changes during a maintenance window to reduce the amount of time for potential data unavailability. Scope NFS Block size changes are recommended for performance improvement under certain circumstances. The block size changes should only be performed on SimpliVity OmniStack version and later releases. SimpliVity Omnistack prior to version should be upgraded before a NFS block size change is attempted. 1

2 Resolution Prerequisites Use the following commands to capture data from Non-SimpliVity ESXi hosts, SimpliVity ESXi hosts, and OVCs, and use the data to populate the charts below. ESXi Hosts Run the following commands on each ESXi host (both SimpliVity and non-simplivity) and populate the below tables from the output of the commands. cat /etc/hosts esxcli storage nfs list esxcli storage nfs param get n all This command runs only on ESXi 5.5 and later. SimpliVity ESXi Hosts ESXi Host Name OVC Name Volume Name Share MaxWriteTransferSize Non-SimpliVity Hosts ESXi Host Name OVC Name Volume Name Share MaxWriteTransferSize 2

3 ESXi Host Name OVC Name Volume Name Share MaxWriteTransferSize OmniStack Virtual Controller Run the following command on each OVC, and populate the below table from the output of the command: cat /proc/fs/nfsd/max_block_size OVC Name Max Block Size UnMount ESXi Datastores Prior to starting this procedure, verify if there are any non-simplivity ESXi hosts connected to SimpliVity datastores. It is important to note which interface address the non-simplivity hosts are connected to and how many non-simplivity hosts are mounted. In some cases, this will change the way the rolling block size change is performed. If, for example, there are three non-simplivity hosts with many virtual machines (VMs) connected to one OVC management IP address, the first change that may need to be made is the block size on the OVC, which has no non-simplivity hosts mounted. Evacuate the VMs from two of the three non-simplivity hosts, and modify the /etc/hosts file to force a remount to the OVC with the now modified block size. This then would give the ability to evacuate the other nodes cleanly. This of course depends on VM count and resource utilization such as vcpu and memory from the VM perspective. If a non-simplivity ESXi host(s) is connected to a SimpliVity datastore, proceed with step 1. If not, skip to Step Verify what IP the non-simplivity host is using for its datastore connectivity by logging into the non-simplivity ESXi host and running cat /etc/hosts. Verify the IP address for the omni.cube.io entry. Compare this against the OVC interface addresses to identify which OVC the Non-SimpliVity host is connected to. Example: ~ # cat /etc/hosts # Do not remove the following line, or various programs # that require network functionality will fail localhost.localdomain localhost ::1 localhost.localdomain localhost 3

4 server3.support.local server omni.cube.io 2. vmotion all VMs off the OmniStack that is to be started with, and if it applies, vmotion all VMs off the non-simplivity host or hosts connected to that OVC. Include powered off VMs. Remove any templates from the inventory or convert them to VMs. The templates can be re-added later. 3. After the vmotions have completed, and it has been confirmed that no VMs are currently hosted on this OmniStack, or non-simplivity hosts connected to this OVC, unmount all SimpliVity datastores connected to this OVC using the following command for each mounted volume. The following ESXi CLI command should be run on both SimpliVity ESXi Hosts and non-simplivity ESXi hosts for each datastore connected to the OVC being modified. ~ # esxcli storage nfs remove -v <VolumeName><volumename/> 4. Rerun the following command on each ESXi host to ensure all SimpiVity datastores have been unmounted: esxcli storage nfs list Contact an authorized SimpliVity support provider to update the NFS Max Block Size on the OVC. Customer Support Please be aware of the following: Note: If the non-disruptive procedure is performed on a customer system, detailed Escalation Engineer review and approval of all procedural steps is required in all situations without exception. For more information on the disruptive procedure, refer to How to Modify the Network File System (NFS) Block Size (Disruptive). Updating the NFS Max Block Size on the OVC 1. Log in to the OVC as root. 2. Make a backup copy of the svtfs.xml file by entering this command: # cp /var/svtfs/0/myconfig/static/svtfs.xml /var/svtfs/0/myconfig/static/ svtfs.xml.backup 3. Open the svtfs.xml file in a text editor by entering this command: vi /var/svtfs/0/myconfig/static/svtfs.xml 4. Locate the MaxBlockSize line and replace the value with the new value by entering the following command. The default value to be set should be , which is 128k. <nfs> <MaxBlockSize> </MaxBlockSize> <Nfs> 5. Save the svtfs.xml file. 6. Restart the OVC for the changes to be applied. 7. Confirm SVTFS has started. Run the following command: Grep Claimed IP address $SVTLOG Confirm that the node that claimed the IP address back is the one on which the block size is being changed. The output of the command should read similar to the following: T16:25:10.812Z INFO 0x7f27c [control.ipfail.ipclaimsm] ipclaimsm.cpp:287 [ ] Claimed IP address 4

5 Run the following command to assure that eth2 has been assigned its storage IP address: ifconfig 8. When the Federation member has returned to service, enter the following command to assure the block size has changed on the OVC. If the block size has not changed, repeat steps 5-11 again. # cat /proc/fs/nfsd/max_block_size 9. Remount all datastores by entering the following CLI command or remount them through vcenter. ~ # esxcli storage nfs add -H omni.cube.io -s /mnt/svtfs/0/datastoreguid -v <VolumeName> 10. Confirm ESXi sees the new block size by running the following command from the ESXi console. The MaxWriteTransferSize reflects the block size value. ~ # esxcli storage nfs param get -n all Example Output: Volume Name MaxQueueDepth MaxReadTransferSize MaxWriteTransferSize Datastorename vmotion all VMs back to the ESXi hosts that were evacuated. 12. Repeat steps 1-15 for all other OVCs to be changed. Article Information Article Author: Pete Nisler Article approved by: Pete Nisler Approval date: 2016/12/29 PIR approval date: 2017/02/03 Specify the information level: 1 Customers 5