Silicon Graphics InfiniteStorage 4000 Series User manual

SGI InfiniteStorage 4000 Series and 5000 Series
Failover Drivers Guide for SANtricity ES
(ISSM 10.86)






007-5886-002 April 2013

The information in this document supports the SGI InfiniteStorage 4000 series and 5000 series storage
systems (ISSM 10.86). Refer to the table below to match your specific SGI InfiniteStorage product
with the model numbers used in this document.

SGI Model #
NetApp Model
TP9600H 6091
TP9700F 6091
IS4500F 6091
TP9600F 3994 and 3992
IS4000H 3994
IS350 3992
IS220 1932
1333
DE1300
IS4100 4900
IS-DMODULE16-Z FC4600
IS-DMODULE60 DE6900
IS4600 7091
IS-DMODULE12 & IS2212 (JBOD) DE1600
IS-DMODULE24 & IS2224 (JBOD) DE5600
IS-DMODULE60-SAS DE6600
IS5012 E2600
IS5024 E2600
IS5060 E2600
IS5512 E5400
IS5524 E5400
IS5560 E5400
IS5600 E5500

ii Copyright information
Copyright information
Copyright © 1994–2012 NetApp, Inc. All rights reserved. Printed in the U.S.A.
No part of this document covered by copyright may be reproduced in any form or by any means—
graphic, electronic, or mechanical, including photocopying, recording, taping, or storage in an
electronic retrieval system—without prior written permission of the copyright owner.
Software derived from copyrighted NetApp material is subject to the following license and disclaimer:
THIS SOFTWARE IS PROVIDED BY NETAPP "AS IS" AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES
OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE, WHICH ARE
HEREBY DISCLAIMED. IN NO EVENT SHALL NETAPP BE LIABLE FOR ANY DIRECT,
INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
NetApp reserves the right to change any products described herein at any time, and without notice.
NetApp assumes no responsibility or liability arising from the use of products described herein, except
as expressly agreed to in writing by NetApp. The use or purchase of this product does not convey a
license under any patent rights, trademark rights, or any other intellectual property rights of NetApp.
RESTRICTED RIGHTS LEGEND: Use, duplication, or disclosure by the government is subject to
restrictions as set forth in subparagraph (c)(1)(ii) of the Rights in Technical Data and Computer
Software clause at DFARS 252.277-7103 (October 1988) and FAR 52-227-19 (June 1987).

Trademark information iii
Trademark information
NetApp, the NetApp logo, Network Appliance, the Network Appliance logo, Akorri, ApplianceWatch,
ASUP, AutoSupport, BalancePoint, BalancePoint Predictor, Bycast, Campaign Express,
ComplianceClock, Cryptainer, CryptoShred, Data ONTAP, DataFabric, DataFort, Decru, Decru
DataFort, DenseStak, Engenio, Engenio logo, E-Stack, FAServer, FastStak, FilerView, FlexCache,
FlexClone, FlexPod, FlexScale, FlexShare, FlexSuite, FlexVol, FPolicy, GetSuccessful, gFiler, Go
further, faster, Imagine Virtually Anything, Lifetime Key Management, LockVault, Manage ONTAP,
MetroCluster, MultiStore, NearStore, NetCache, NOW (NetApp on the Web), Onaro, OnCommand,
ONTAPI, OpenKey, PerformanceStak, RAID-DP, ReplicatorX, SANscreen, SANshare, SANtricity,
SecureAdmin, SecureShare, Select, Service Builder, Shadow Tape, Simplicity, Simulate ONTAP,
SnapCopy, SnapDirector, SnapDrive, SnapFilter, SnapLock, SnapManager, SnapMigrator,
SnapMirror, SnapMover, SnapProtect, SnapRestore, Snapshot, SnapSuite, SnapValidator, SnapVault,
StorageGRID, StoreVault, the StoreVault logo, SyncMirror, Tech OnTap, The evolution of storage,
Topio, vFiler, VFM, Virtual File Manager, VPolicy, WAFL, Web Filer, and XBB are trademarks or
registered trademarks of NetApp, Inc. in the United States, other countries, or both.
IBM, the IBM logo, and ibm.com are trademarks or registered trademarks of International Business
Machines Corporation in the United States, other countries, or both. A complete and current list of
other IBM trademarks is available on the Web at www.ibm.com/legal/copytrade.shtml.
Apple is a registered trademark and QuickTime is a trademark of Apple, Inc. in the U.S.A. and/or other
countries. Microsoft is a registered trademark and Windows Media is a trademark of Microsoft
Corporation in the U.S.A. and/or other countries. RealAudio, RealNetworks, RealPlayer, RealSystem,
RealText, and RealVideo are registered trademarks and RealMedia, RealProxy, and SureStream are
trademarks of RealNetworks, Inc. in the U.S.A. and/or other countries.
All other brands or products are trademarks or registered trademarks of their respective holders and
should be treated as such.
NetApp, Inc. is a licensee of the CompactFlash and CF Logo trademarks.
NetApp, Inc. NetCache is certified RealSystem compatible.

Table of Contents
Table of Contents v
Chapter 1 Overview of Failover Drivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Failover Driver Setup Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Supported Failover Drivers Matrix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
I/O Coexistence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Failover Configuration Diagrams. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Single-Host Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Host Clustering Configurations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Supporting Redundant Controllers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
How a Failover Driver Responds to a Data Path Failure . . . . . . . . . . . . . . . . . . . 8
User Responses to a Data Path Failure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Load-Balancing Policies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Least Queue Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Round Robin with Subset I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Weighted Paths . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Dividing I/O Activity Between Two RAID Controllers to Obtain the Best
Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Changing the Preferred Path Online Without Stopping the Applications . . . . . 10
Chapter 2 Failover Drivers for the Windows Operating System . . . . . . . . . . . . . . . . . . . . . 11
Microsoft Multipath Input/Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Device Specific Module for the Microsoft MPIO Solution . . . . . . . . . . . . . . . . 11
Windows OS Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Per-Protocol I/O Timeout Values. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Selective LUN Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Windows Failover Cluster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
I/O Shipping Feature for Asymmetric Logical Unit Access (ALUA) . . . . . . . . 14
Verifying that the I/O Shipping Feature for ALUA Support is Installed on
the Windows OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Disabling the I/O Shipping Feature for ALUA Support on the
Windows OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

vi Table of Contents
Reduced Failover Timing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Path Congestion Detection and Online/Offline Path States . . . . . . . . . . . . . . . . 17
Configuration Settings for the Windows DSM and the Linux RDAC. . . . . . . . 17
Wait Time Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Configuration Settings for Path Congestion Detection and Online/Offline Path
States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Example Configuration Settings for the Path Congestion Detection Feature . . 24
Running the DSM Failover Driver in a Hyper-V Guest with Pass-Through
Disks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
dsmUtil Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Device Manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Determining if a Path Has Failed . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
Installing or Upgrading SANtricity ES and DSM on the Windows OS . . . 29
Removing SANtricity ES Storage Manager and the DSM Failover
Driver from the Windows OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
WinObj . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Device Specific Module Driver Directory Structures . . . . . . . . . . . . . 30
Frequently Asked Questions about Windows Failover Drivers . . . . . . . . . . . . . 32
Chapter 3 Failover Drivers for the Linux Operating System . . . . . . . . . . . . . . . . . . . . . . . . 37
Linux OS Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Features of the RDAC Failover Driver from NetApp . . . . . . . . . . . . . . . . . . . . 37
Prerequisites for Installing RDAC on the Linux OS . . . . . . . . . . . . . . . . . . . . . 38
Installing SANtricity ES Storage Manager and RDAC on the Linux OS . . . . . 39
Installing RDAC Manually on the Linux OS . . . . . . . . . . . . . . . . . . . . . . . 40
Making Sure that RDAC Is Installed Correctly on the Linux OS. . . . . . . . 41
Configuring Failover Drivers for the Linux OS . . . . . . . . . . . . . . . . . . . . . . . . . 42
Compatibility and Migration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
mppUtil Utility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Frequently Asked Questions about Linux Failover Drivers. . . . . . . . . . . . . . . . 46

Table of Contents vii
Chapter 4 Device Mapper Multipath for the Linux Operating System . . . . . . . . . . . . . . . . 49
Device Mapper Features. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
Known Limitations and Issues of the Device Mapper . . . . . . . . . . . . . . . . . . . 49
Device Mapper Operating Systems Support . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
I/O Shipping Feature for Asymmetric Logical Unit Access (ALUA) with
Linux Operating Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Installing the Device Mapper Multi-Path for the SUSE Linux Enterprise
Server Version 11 Service Pack 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Installing the Device Mapper Multi-Path for the Red Hat Enterprise Linux
Operating System Version 6.3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Verifying that the I/O Shipping Feature for ALUA Support is Installed on the
Linux OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Setting Up the multipath.conf File . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Updating the Blacklist Section . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Updating the Devices Section of the multipath.conf File . . . . . . . . . . . . . . 54
Setting Up DM-MP for Large I/O Blocks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Using the Device Mapper Devices. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Trouble-
shooting the Device Mapper. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Chapter 5 Failover Drivers for the Solaris Operating System . . . . . . . . . . . . . . . . . . . . . . . 59
Solaris OS Restrictions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Prerequisites for Installing MPxIO on the Solaris OS for the First Time . . . . . 59
Prerequisites for Installing MPxIO on a Solaris OS that Previously Ran
RDAC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Installing MPxIO on the Solaris 9 OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Enabling MPxIO on the Solaris 10 OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Enabling MPxIO on the Solaris 11 OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Configuring Failover Drivers for the Solaris OS . . . . . . . . . . . . . . . . . . . . . . . . 63
Frequently Asked Questions about Solaris Failover Drivers . . . . . . . . . . . . . . . 63
Chapter 6 Installing ALUA Support for VMware Versions ESX4.1U3, ESXi5.0U1, and
Subsequent Versions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67

viii Table of Contents

Chapter 1: Overview of Failover Drivers 1
1
Overview of Failover Drivers
Failover drivers provide redundant path management for storage devices and cables in
the data path from the host bus adapter to the controller. For example, you can connect
two host bus adapters in the system to the redundant controller pair in a storage array,
with different buses for each controller. If one host bus adapter, one bus cable, or one
controller fails, the failover driver automatically reroutes input/output (I/O) to the
good path, which permits the storage array to continue operating without interruption.
Failover drivers provide these functions:
They automatically identify redundant I/O paths.
They automatically reroute I/O to an alternate controller when a controller fails
or all of the data paths to a controller fail.
They check the state of known paths to the storage array.
They provide status information on the controller and the bus.
They check to see if the Service mode is enabled and if the modes have switched
between Redundant Dual Active Controller (RDAC) and Auto-Volume Transfer
(AVT).
They check to see if Service mode is enabled on a controller and if the AVT or
asymmetric logical unit access (ALUA) mode of operation has changed.
Failover Driver
Setup
Considerations
Most storage arrays contain two controllers that are set up as redundant controllers. If
one controller fails, the other controller in the pair takes over the functions of the
failed controller, and the storage array continues to process data. You can then replace
the failed controller and resume normal operation. You do not need to shut down the
storage array to perform this task.
The redundant controller feature is managed by the failover driver software, which
controls data flow to the controller pairs independent of the operating system (OS).
This software tracks the current status of the connections and can perform the
switch-over without any changes in the OS.
Whether your storage arrays have the redundant controller feature depends on a
number of items:
Whether the hardware supports it. Refer to the hardware documentation for your
storage arrays to determine whether the hardware supports redundant controllers.
Whether your OS supports certain failover drivers. Refer to the installation and
support guide for your OS to determine if your OS supports redundant
controllers.
How the storage arrays are connected. The storage array must have two
controllers installed in a redundant configuration. Drive trays must be cabled
correctly to support redundant paths to all drives.

2Supported Failover Drivers Matrix
The I/O Shipping feature implements support for ALUA. With the I/O Shipping
feature, a storage array can service I/O requests through either controller in a duplex
configuration. However, I/O shipping alone does not guarantee that I/O is routed to
the optimized path. With Windows, Linux and VMWare, your storage array supports
an extension to ALUA to address this problem so that volumes are accessed through
the optimized path unless that path fails. With SANtricity ES 10.86 and subsequent
releases, Windows and Linux DM-MP have I/O shipping enabled by default.
Supported
Failover Drivers
Matrix Table 1 Matrix of Supported Failover Drivers by Operating System (OS)
Windows Server
2012, Windows 2008,
Vista and Hyper-V
Red Hat Enterprise
Linux (RHEL) 5.8
and 5.9 OSs and
SUSE Linux
Enterprise (SLES)
10.4 OS
RHEL 6.3 OS and
SUSE Linux
Enterprise 11.2
Solaris 10 U10,
Solaris 10 u11
Failover driver
type
MPIO with NetApp
DSM-ALUA
RDAC DMMP (with E5500)
or RDAC
MPxIO (non-TPGS)
Storage array
mode
Mode Select, or
ALUA
Either Mode Select or
AV T
Mode Select. Mode Select or
Asymmetric Logical
Unit Access (ALUA)
Number of
volumes supported
per partition
255 256 256 255
Cluster support? Yes Yes Yes Yes
Controller-drive
trays supported
E2600 and E5400
E5500 (Windows
2012 only)
E2600 and E5400 E2600, E5400, and
E5500
E2600 and E5400

Chapter 1: Overview of Failover Drivers 3
Table 2 Matrix of Supported Failover Drivers by Operating System (OS)
I/O Coexistence A host can have connections to more than one storage array. The connected storage
arrays can have different controller firmware levels, provided that they share common
components (HBAs, switches, and operating system versions) and common failover
drivers.
Failover
Configuration
Diagrams
You can configure failover in several ways. Each configuration has its own advantages
and disadvantages. This section describes these configurations:
Single-host configuration
Multi-host configuration
This section also describes how the storage management software supports redundant
controllers.
NOTE For best results, use the multi-host configuration. It provides the fullest failover
protection and functionality in the event that a problem exists with the connection.
Single-Host
Configuration
In a single-host configuration, the host system contains two host bus adapters
(HBAs), with each HBA connected to one of the controllers in the storage array. The
storage management software is installed on the host. The two connections are
required for maximum failover support for redundant controllers.
Although you can have a single controller in a storage array or a host that has only
one HBA port, you do not have complete failover data path protection with either of
those configurations. The cable and the HBA become a single point of failure, and
Solaris 11, Solaris
11.1 HPUX 11.31 VMWare 4.1 u3, 5.1, ad 5.0 u2
Mac OS 10.6 and
10.7
Failover driver
type
MPxIO
(TPGS/ALUA)
TPGS/ALUA VMWare native -
SATP/ALUA
ATTO driver with
TPGS/ALUA
Storage array
mode
Mode Select or
ALUA
Number of
volumes per
partition
255
Cluster support? No No Yes NA
Controller-drive
trays supported
E2600, E5400, and
E5500
E2600 and E5400 E2600 and E5400 E2600 and E5400

4Failover Configuration Diagrams
any data path failure could result in unpredictable effects on the host system. For the
greatest level of I/O protection, provide each controller in a storage array with its own
connection to a separate HBA in the host system.
Figure 1 Single-Host-to-Storage Array Configuration
1. Host System with Two Fibre Channel Host Bus Adapters
2. Fibre Channel Connection – Fibre Channel Connection
Might Contain One or More Switches
3. Storage Array with Two Fibre Channel Controllers
Host Clustering
Configurations
In a clustering configuration, two host systems are each connected by two
connections to both of the controllers in a storage array. SANtricity ES Storage
Manager, including failover driver support, is installed on each host.
Not every operating system supports this configuration. Consult the restrictions in the
installation and support guide specific to your operating system for more information.
Also, the host systems must be able to handle the multi-host configuration. Refer to
the applicable hardware documentation.

Chapter 1: Overview of Failover Drivers 5
Both hosts have complete visibility of both controllers, all data connections, and all
configured volumes in a storage array, plus failover support for the redundant
controllers. However, in this configuration, you must use caution when you perform
storage management tasks (especially deleting and creating volumes) to make sure
that the two hosts do not send conflicting commands to the controllers in the storage
arrays.
The following items apply to these clustering configurations:
Both hosts must have the same operating system version and SANtricity ES
Storage Manager version installed.
The failover driver configuration might require tuning.
Both host systems must have the same volumes-per-host bus adapter capacity.
This capacity is important for failover situations so that each controller can take
over for the other and show all of the configured volume groups and volumes.
If the operating system on the host system can create reservations, the storage
management software honors them. Each host might have reservations to
specified volume groups and volumes, and only the software on that host can
perform operations on the reserved volume group and volume. Without
reservations, the software on either host system is able to start any operation.
Therefore, you must use caution when you perform certain tasks that need
exclusive access. Especially when you create and delete volumes, make sure that
you have only one configuration session open at a time (from only one host), or
the operations that you perform could fail.

6Failover Configuration Diagrams
Figure 2 Multi-Host-to-Storage Array Configuration
1. Two Host Systems, Each with Two Fibre Channel Host Bus
Adapters
2. Fibre Channel Connections with Two Switches (Might
Contain Different Switch Configurations)
3. Storage Array with Two Fibre Channel Controllers
Supporting
Redundant
Controllers
The following figure shows how failover drivers provide redundancy when the host
application generates a request for I/O to controller A, but controller A fails. Use the
numbered information to trace the I/O data path.

Chapter 1: Overview of Failover Drivers 7
Figure 3 Example of Failover I/O Data Path Redundancy
1. Host Application
2. I/O Request
3. Failover Driver
4. Host Bus Adapters
5. Controller A Failure
6. Controller B
7. Initial Request to the HBA

8How a Failover Driver Responds to a Data Path Failure
8. Initial Request to the Controller Failed
9. Request Returns to the Failover Driver
10. Failover Occurs and I/O Transfers to Another Controller
11. I/O Request Re-sent to Controller B
How a Failover
Driver
Responds to a
Data Path
Failure
One of the primary functions of the failover feature is to provide path management.
Failover drivers monitor the data path for devices that are not working correctly or for
multiple link errors. If a failover driver detects either of these conditions, the failover
driver automatically performs these steps:
The failover driver checks the pair table for the redundant controller.
The failover driver forces volumes to the other controller and routes all I/O to the
remaining active controller.
The failover driver performs a path failure if alternate paths to the same controller
are available. If all of the paths to a controller fail, RDAC performs a controller
failure. The failover driver provides notification of an error through the OS error
log facility.
When a drive and a controller fail simultaneously, the event is considered to be a
double failure. The storage management software provides data integrity as long as all
drive failures and controller failures are detected and fixed before more failures occur.
User
Responses to a
Data Path
Failure
Use the Major Event Log (MEL) to respond to a data path failure. The information in
the MEL provides the answers to these questions:
What is the source of the error?
What is required to fix the error, such as replacement parts or diagnostics?
Under most circumstances, contact your Technical Support Representative any time a
path fails and the storage array notifies you of the failure. Use the Recovery Guru in
the storage management software to diagnose and fix the problem, if possible. If your
controller has failed and your storage array has customer-replaceable controllers,
replace the failed controller. Follow the manufacturer’s instructions for how to replace
a failed controller.
Load-Balancing
Policies
Load balancing is the redistribution of read/write requests to maximize throughput
between the server and the storage array. Load balancing is very important in high
workload settings or other settings where consistent service levels are critical. The
multi-path driver transparently balances I/O workload without administrator
intervention. Without multi-path software, a server sending I/O requests down several
paths might operate with very heavy workloads on some paths, while other paths are
not used efficiently.

Chapter 1: Overview of Failover Drivers 9
The multi-path driver determines which paths to a device are in an active state and can
be used for load balancing. The load-balancing policy uses one of three algorithms:
round robin, least queue depth, or least path weight. Multiple options for setting the
load-balancing policies let you optimize I/O performance when mixed host interfaces
are configured. The load-balancing policies that you can choose depend on your
operating system. Load balancing is performed on multiple paths to the same
controller but not across both controllers.
Table 3 Load-Balancing Policies That Are Supported by the Operating Systems
Least Queue Depth The least queue depth policy is also known as the least I/Os policy or the least
requests policy. This policy routes the next I/O request to the data path on the
controller that owns the volume that has the least outstanding I/O requests queued.
For this policy, an I/O request is simply a command in the queue. The type of
command or the number of blocks that are associated with the command is not
considered. The least queue depth policy treats large block requests and small block
requests equally. The data path selected is one of the paths in the path group of the
controller that owns the volume.
Round Robin with
Subset I/O
The round robin with subset I/O load-balancing policy routes I/O requests, in rotation,
to each available data path to the controller that owns the volumes. This policy treats
all paths to the controller that owns the volume equally for I/O activity. Paths to the
secondary controller are ignored until ownership changes. The basic assumption for
the round robin with subset I/O policy is that the data paths are equal. With mixed
host support, the data paths might have different bandwidths or different data transfer
speeds.
Weighted Paths The weighted paths policy assigns a weight factor to each data path to a volume. An
I/O request is routed to the path with the lowest weight value to the controller that
owns the volume. If more than one data path to the volume has the same weight value,
the round-robin with subset path selection policy is used to route I/O requests
between the paths with the same weight value.
Operating System Multi-Path Driver Load-Balancing Policy
Windows MPIO DSM Round robin with subset, least queue depth,
weighted paths
Red Hat Enterprise Linux (RHEL) RDAC Round robin with subset, least queue depth
DMMP Round robin
SUSE Linux Enterprise (SLES) RDAC Round robin with subset, least queue depth
DMMP Round robin
Solaris MPxIO Round robin with subset

10 Dividing I/O Activity Between Two RAID Controllers to Obtain the Best Performance
Dividing I/O
Activity
Between Two
RAID
Controllers to
Obtain the Best
Performance
For the best performance of a redundant controller system, use the storage
management software to divide I/O activity between the two RAID controllers in the
storage array. You can use either the graphical user interface (GUI) or the command
line interface (CLI).
To use the GUI to divide I/O activity between two RAID controllers, perform one of
these steps:
Specify the owner of the preferred controller of an existing volume – Select
Volume >> Change >> Ownership/Preferred Path in the Array Management
Window.
NOTE You also can use this method to change the preferred path
and ownership of all volumes in a volume group at the same time.
Specify the owner of the preferred controller of a volume when you are
creating the volume – Select Volume >> Create in the Array Management
Window.
To use the CLI, go to the "Create RAID Volume (Free Extent Based Select)" online
help topic for the command syntax and description.
Changing the
Preferred Path
Online Without
Stopping the
Applications
You can change the preferred path setting for a volume or a set of volumes online
without stopping the applications. However, the host multipath driver might not
immediately recognize that the preferred path has changed.
During the interval when the old path is still used, the driver might trigger a volume
not on preferred path Needs Attention condition in the storage
management software. This condition is removed as soon as the state change monitor
is run. A MEL event and an associated alert notification are delivered for the
condition. You can configure the AVT alert delay period with the storage management
software. The Needs Attention reporting is postponed until the failover driver failback
task has had a chance to run.
If the ALUA mode is enabled, the failover driver will continue to use the same data
path or paths. The storage array will, however, use its I/O Shipping feature to service
I/Os requests even if they are directed to the non-owning controller.
NOTE The newer versions of the RDAC failover driver and the DSM failover driver
do not recognize any AVT or ALUA status change (enabled or disabled) until the next
cycle of the state change monitor.

Chapter 2: Failover Drivers for the Windows Operating System 11
2
Failover Drivers for the Windows Operating System
The failover driver for hosts with Microsoft Windows operating systems is Microsoft
Multipath I/O (MPIO) with a Device Specific Module (DSM) for SANtricity ES
Storage Manager.
Microsoft
Multipath
Input/Output
Microsoft Multipath I/O (MPIO) provides an infrastructure to build highly available
solutions for Windows operating systems (OSs). MPIO uses Device Specific Modules
(DSMs) to provide I/O routing decisions, error analysis, and failover.
NOTE You can use MPIO for all controllers that run controller firmware version 6.19
or later. MPIO is not supported for any earlier versions of the controller firmware, and
MPIO cannot coexist on a server with RDAC. If you have legacy systems that run
controller firmware versions earlier than 6.19, you must use RDAC for your failover
driver. For SANtricity ES Storage Manager Version 10.10 and later and all versions of
SANtricity Storage Manager, the Windows OS supports only MPIO.
Device Specific
Module for the
Microsoft MPIO
Solution
The DSM driver is the hardware-specific part of Microsoft’s MPIO solution. This
release supports Microsoft’s Windows Server 2008 OS, and Windows Server 2008 R2
OS and Windows Server 2012. The Hyper-V role is also supported when running the
DSM within the parent partition. The SANtricity ES Storage Manager Version 10.86
works with the DSM to implement supported features.
Windows OS
Restrictions
The MPIO DSM failover driver comes in these versions:
32-bit (x86)
64-bit AMD/EM64T (x64)
These versions are not compatible with each other. Because multiple copies of the
driver cannot run on the same system, each subsequent release is backward
compatible.
Per-Protocol I/O
Timeout Values
The timeout value associated with a non-passthrough I/O requests, such as read/write
requests, is based on the Microsoft disk driver's TimeOutValue parameter, as
defined in the Registry. A feature within the DSM allows a customized timeout value
to be applied based on the protocol (such as Fibre Channel, SAS, or iSCSI) that a path
uses. Per-protocol timeout values provide these benefits:
Without per-protocol timeout values, the TimeOutValue setting is global and
affects all storage.

12 Selective LUN Transfer
The TimeOutValue is typically reset when an HBA driver is upgraded.
For information about the configurable parameters for the customized timeout
feature, go to Configuration Settings for the Windows DSM and the Linux
RDAC.
The per-protocol timeout values feature slightly modifies the way in which the
SynchTimeout parameter is evaluated. The SynchTimeout parameter
determines the I/O timeout for synchronous requests generated by the DSM driver.
Examples include the native handling of persistent reservation requests and inquiry
commands used during device discovery. It is important that the timeout value for the
requests from the DSM driver be at least as large as the per-protocol I/O timeout
value. When a host boots, the DSM driver performs these actions:
If the value of the SynchTimeout parameter is defined in the Registry key of
the DSM driver, record the current value.
If the value of the TimeOutValue parameter of the Microsoft disk driver is
defined in the Registry, record the current value.
Use the higher of the two values as the initial value of the SynchTimeout
parameter.
If neither value is defined, use a default value of 10 seconds.
For each synchronous I/O request, the higher value of either the per-protocol I/O
timeout or the SynchTimeout parameter is used. For example:
—If the value of the SynchTimeout parameter is 120 seconds, and the value
of the TimeOutValue parameter is 60 seconds, 120 seconds is used for the
initial value.
—If the value of the SynchTimeout parameter is 120 seconds, and the value
of the TimeOutValue parameter is 180 seconds, 180 seconds is used for
the initial value of the synchronous I/O requests for the DSM driver.
—If the I/O timeout value for a different protocol (for example, SAS) is 60
seconds and the initial value is 120 seconds, the I/O is sent using a
120-second timeout.
Selective LUN
Transfer
This feature limits the conditions under which the DSM driver moves a LUN to the
alternative controller to three cases:
1. When a DSM driver with a path to only one controller, the non-preferred path,
discovers a path to the alternate controller.
2. When an I/O request is directed to a LUN that is owned by the preferred path, but
the DSM driver is attached to only the non-preferred path.
3. When an I/O request is directed to a LUN that is owned by the non-preferred
path, but the DSM driver is attached to only the preferred path.
Case 2 and case 3 have these user-configurable parameters that can be set to tune the
behavior of this feature.