What are the best practices for ISCSI connections directly from Windows OS servers?
Applies to
- Element Software
- Windows servers directly connected to Element Software
Answer
Configuration Guide
The NetApp SolidFire Storage for Microsoft Windows Configuration Guide details the best practice recommendations and requirements specific to the Windows OS iSCSI connections.
This guide covers the timing changes that must be made when making iSCSI connections to Element storage from the Windows OS.
- See the "Tuning MPIO Path Selection" starting on page 16 for detailed steps on making the changes in Windows
Additional Information on time-outs:
Windows’ default configuration is tuned for local disk. This means various time-outs are set very low, allowing very low tolerance for any transient latency. As such, a single IO taking longer than the set threshold of the lowest level object can cause:
- the IO to fail
- the path to be taken offline
- the application to crash
- the (Windows) cluster to fail over
Depending on the cluster settings, the path may or may not be bought back online, making the cluster potentially unable to restart the application resources.
NetApp Engineering has tested and recommends the following changes to be made to production Windows hosts, including VMs. If the VMs are hosted on Hyper-V, the changes should be made to Hyper-V as well.
Note these settings effect how tolerant the different layers of the Windows IO stack are – there are no application-specific settings included here. While some applications may have additional settings, these settings ensure that the majority of transient IO issues are masked by Windows, benefiting all installed applications.
These settings are valid for both W2k8r2 and W2k12r2. The host must be rebooted for the changes to go into effect.
Please note that these settings MUST BE SET prior to beginning any Element Cluster Upgrade operations to greatly reduce the likelihood of triggering an application failure and subsequent downtime.
Parameter | Default | Preferred | Key |
TimeoutValue | 60 | 60 | HKEY_LOCAL_MACHINESystem CurrentControlSetServicesDiskTimeoutValue |
PDORemovePeriod | 20 | 120 | HKLMSystemCurrentControlSet ServicesmpioParametersPDORemovePeriod |
UseCustomPathRecoveryInterval | 0 | 1 | HKLMSystemCurrentControlSet ServicesmpioParametersUseCustomPathRecoveryInterval |
PathRecoveryInterval | .5 x PDO | 60 | HKLMSystemCurrentControlSet ServicesmpioParametersPathRecoveryInterval |
PathVerifyEnabled | 0 | 1 | HKLMSystemCurrentControlSet ServicesmpioParametersPathVerifyEnabled |
PathVerificationPeriod | 30 | 30 | HKLMSystemCurrentControlSet ServicesmpioParametersPathVerificationPeriod |
MaxRequestHoldTime | 60 | 90 | HKLMSYSTEMCurrentControlSetControlClass{4D36E97B-E325-11CE-BFC1-08002BE10318}<Instance Number>ParametersMaxRequestHoldTime |
LinkDownTime | 15 | 35 | HKLMSYSTEMCurrentControlSetControlClass{4D36E97B-E325-11CE-BFC1-08002BE10318}<Instance Number>ParametersLinkDownTime |
EnableNOPOut | 0 | 1 | HKLMSYSTEMCurrentControlSetControlClass{4D36E97B-E325-11CE-BFC1-08002BE10318}<Instance Number>ParametersEnableNOPOut |
Additional Information
LinkDownTime
setting : For iSCSI only, the LinkDownTime setting specifies the maximum time in seconds that requests are held in the device queue and retried if the connection to the target is lost.- If MPIO is installed, this value is used. If MPIO is not installed,
MaxRequestHoldTime
is used instead.