Best Practices Guide - For XIOtech ISE Storage
Best Practices Guide - For XIOtech ISE Storage
5300 Customer Support: 1.800.734.4716 IMPORTANT NOTICE This manual is provided to you by Xiotech Corporation (Xiotech), and your receipt and use of this manual is subject to your agreement to the following conditions: This manual and the information it contains are the property of Xiotech and are confidential. You agree to keep this manual in a secure location and not disclose or make available its contents to any third party without Xiotechs written permission. Reproduction or distribution of this document, in whole or in part, may only be made with Xiotechs written permission. This manual is not an endorsement or recommendation of any of the products or services provided by third parties and referred to herein. Use of this manual does not assure legal or regulatory compliance. This document is not a warranty of any kind. The only warranties given in connection with this product are those contained in Xiotechs standard terms and conditions. Xiotech, Magnitude, Magnitude 3D, and TimeScale are registered trademarks of Xiotech Corporation. Emprise, ISE, Dimensional Storage Cluster, DataScale, and GeoRAID are trademarks of Xiotech Corporation. Other trademarks or service marks contained herein are the property of their respective owners. Trademarks and service marks belonging to third parties appear in this document for the purposes of identification of the goods or services of that third party only. No reproduction of any trademark or service mark is authorized by this document. No right or title or other proprietary interest in any mark is transferred because of this document.
2012 Xiotech Corporation. All rights reserved. Publication Number: 160347-000 Rev C Janaury 2013
Table of Contents
Table of Contents
Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .1
Intended Audience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
Hardware Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .3
ISE-2 Components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 MRCManaged Reliability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 DataPacsTypes and Capacities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 End-to-End Solution Diagrams . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Sample Environments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 ISE Physical Connectivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Fibre Channel Cables . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Direct Attached . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 ISE Host Limits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 FC Switched Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Switch Configuration Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Brocade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 ISE Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Open Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Host-Based Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Single Initiator Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 One-To-One Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 HBA Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Connection Options (QLogic specific) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 Data Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Adapter BIOS/Boot from SAN Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 LUNs per Target . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Execution Throttle / Queue-Depth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Vendor-Specific Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Page i
Table of Contents
Windows 2008 SP2 / Windows 2008 R2 SP1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi-pathing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Native MPIO Registry Key Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Disabling FUA for ISE Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Required Hot Fixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ISE Firmware Upgrade Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Windows 2012 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Multi-pathing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES) . . . . . . . . . . . Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . AIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VMware ESXi . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.x . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Physical Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SVC Logical Topology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zoning . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Single Fabric. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Redundant Fabric . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Zoning Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ISE Volumes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Volume Size . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Volume Placement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Host Queue Depth Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Storage and Networking Industry Association (SNIA) Dictionary . . . . . . . . . . . . . . . . . . . . . . . . . . IBM Fiber Cable Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VMware Queue Depth Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . VMware Maximum Disk Requests per VM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Red Hat Enterprise Linux (RHEL) MPIO Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . SUSE Linux Enterprise Server (SLES) MPIO Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . QLogic Red Hat Enterprise Linux 6.x Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
23 23 24 24 26 27 32 32 32 32 36 36 36 36 41 42 42 42 43 43 43 43 43 43 45 45 45 45 45 45 45
Page ii
ISE
Best Practices
Introduction
Storage solutions such as the ISE-2 can be configured in many different ways, each with their own set of risks and rewards. This document presents the optimal configurations for various purposes and demonstrates options at various points from ISE-2 to the HBA and Operating Systems.
Intended Audience
This document is intended for IT Administrators, Desktop Specialists, Partners, and Field Services.
Page 1
Best Practices
ISE
Page 2
ISE
Best Practices
Hardware Configuration
ISE-2 Components
Refer to the Introduction of the ISE User Guide for a more complete description of each component. This is a quick reference only.
1. DataPac(s) 2. System Status Module 3. Managed Reliability Controllers (MRCs) 4. Supercapacitors (Supercaps) 5. System Chassis 6. Power Supplies
Page 3
Best Practices
ISE
MRCManaged Reliability
The X-IO Managed Reliability Controller (two per ISE) uses built-in diagnostics and recovery tools to analyze, identify, and recover from a large number of common drive problems. These are the same diagnostics and tools that are used by the drive manufacturer to repair and refurbish a drive that has been sent back for repairs. This ability to take a drive offline and repair it is what X-IO calls managed reliability, and it helps drive the 5year warranty on DataPacs. Each MRC has the ability to send information back to X-IO headquarters and notify the services organization that something has gone wrong. This is disabled by default and should be enabled on every ISE upon installation unless the customers business does not allow it. X-IO also makes an ISE Analyzer product that can be installed at the customer site to capture this telemetry data from multiple ISEs and display it to the customer. It is not necessary to have an ISE Analyzer at the customer site if the customer is willing to monitor their ISE products through other means because the telemetry can be sent to X-IO headquarters with or without an ISE Analyzer. Each ISE also has SNMP capability built in, which allows external monitoring tools to be used to monitor and alert on changes in state of the ISE.
Page 4
ISE
Best Practices
Note that the ISE-2 14.4H also goes by the name Hyper-ISE (the H stands for Hyper) because it uses solid state disks (SSD) to provide faster access to the most frequently accessed data via X-IOs proprietary CADP algorithm. Each DataPac contains either 10 or 20 industry-standard hard drives or a mix of 10 hard drives and 10 solid state drives in the case of the Hyper DataPacs. These drives are grouped together into one or two pools. When the ISE is initialized, 20% of the drive capacity is reserved for data recovery operations (sparing). This spare capacity is equivalent to hot-spare drives in a more traditional storage solution.
Sample Environments
A typical environment is more than just a single server and more than just one application. In the environment below there are three ISE-2s, two Fibre Channel switches for redundant fabrics, five dual-port HBAs (one per server), five physical servers, and five different applications. Each switch represents a separate fabric, and the lines representing Fibre Channel cables are color-coded to represent which fabric they are on.
Page 5
Best Practices
ISE
Page 6
ISE
Best Practices
Direct Attached
When using one of the supported Operating System (OS) versions and supported HBAs (see the lists on X-IOs Support Matrix), a host can connect directly to the MRC ports with a Fibre Channel cable. In a direct attach scenario, it is required to have at least two ports per server, with each port connected to a different MRC. This ensures that the host stays online in the event of an MRC failure or a normal failover as part of an ISE-2 firmware upgrade process. X-IO strongly recommends setting the HBA ports and the ISE ports to the same data rate for direct attached configurations. Auto-speed negotiation does not always work reliably during failover/failback scenarios or certain failure conditions.
FC Switched Fabric
Single SwitchNon-Redundant It is possible to connect both MRCs and all hosts to a single fiber switch. X-IO does not recommend the use of a single switch as this type of configuration implies a single point of failure. Single SwitchRedundant Fabrics The default configuration for an ISE-2 is to connect one MRC to one fabric, and the other MRC connects to the other fabric.
Page 7
Best Practices
ISE
The best practice for an ISE-2 is to connect at least one port from each MRC to each fabric. This provides at least one path to the preferred MRC for any given LUN on each fabric.
Figure 6. Both MRCs on Each FabricBest Practice for Performance and Redundancy
Multi-switch Fabrics If there are two switches in a given fabric, cable one port per MRC to each switch and distribute the host ports across both switches in each fabric equally. Traffic between devices on the same fabric but on different switches must share the interswitch link (ISL). X-IO recommends having a minimum of two ISLs between each switch. If the switch supports high-speed ISLs, it is preferable to use them. X-IO recommends using unique domain IDs for each switch in a solution, regardless of whether the switches are on the same fabric. This allows easier troubleshooting when viewing event logs and vendor support tools.
Page 8
ISE
Best Practices
Very Large Fabrics Daisy-chaining multiple switches together in large fabrics is not advised, as the traffic between devices on different switches must share the link and daisy-chaining reduces throughput. To alleviate this condition, use a mesh topology; however, this is generally considered cost-prohibitive at any scale beyond three or four switches. X-IO recommends using a Core / Edge model, which has a director class switch in the center of each fabric, with top-of-rack edge switches forming the edge. X-IO recommends connecting the ISE MRCs directly to the director class switches. This minimizes the number of ISL links data has to cross to reach a given host. In the model below, a director class switch connects to multiple edge switches, which then connect to hosts. In this large fabric, X-IO recommends connecting each edge switch to at least two different blades on the director and connecting two ports on each ISE-2 MRC to different blades on the director as well. This reduces the impact of a blade failure and minimizes the number of hops data has to travel through a shared ISL.
Page 9
Best Practices
ISE
If the servers that communicate with a given ISE are in the same rack, it is advised to connect the ISE MRC ports and the server ports to the same top-of-rack switches. This avoids any extra traffic on the core.
Brocade
Port Settings Brocade switches allow ports to be set to different types. X-IO recommends disabling the Loop option to prevent attempts to use FL-Port as an option. This speeds up the switch login time for an ISE. From CLI, type switch> portcfggport <port#> 1 From GUI, uncheck L Port.
Page 10
ISE
Best Practices
Brocade Node WWN Checking Configuration Brocade switches have a feature known as Node WWN checking, which can cause some unintended paths to storage LUNs to appear on certain ISE MRC ports. This happens because the ISE uses the port WWN of the first port on MRC A as the Node WWN for all ports. See the table below as an example:
Node WWN Port WWN MRC and Port Number
MRC A Port 1 MRC A Port 2 MRC A Port 3 MRC A Port 4 MRC B Port 5 MRC B Port 6 MRC B Port 7 MRC B Port 8
Consider the solution below, in which there are two ports from a server as well as the first port on each MRC connected to a Brocade switch. The zoning is configured to allow one port on the server to see MRC A and the other port to see MRC B. This should result in a total of two paths to any LUN presented from the ISE to the host. When Brocades Node WWN checking feature is enabled, the real number of paths found for each LUN is three.
Page 11
Best Practices
ISE
Assuming that the host WWNs are 21000024ff26415e and 21000024ff26415f, the zones would look similar to the following.
Zone Name Member Port WWNs
MrcAPort1_HostPort1 MrcBPort5_HostPort2
Table 3:
Brocade switches can build zones based on either Port WWNs or Node WWNs. When a zone is created that contains a member with identical Node and Port WWNs, the zone is assumed to be using Node WWN zoning; therefore, all other ports with the same Node WWN are added to this zone. The Node WWN checking option impacts any zones containing the first port of the first MRC on any ISE. This can be avoided by either using a different port on the first MRC of an ISE-2 or by disabling the Node WWN checking on each Brocade switch in a given fabric. Node WWN Checking Brocade Fibre Channel (FC) switches have a configuration option that is on by default and that can cause some unexpected zoning behaviors with an ISE (both ISE-1 and ISE-2). The ISE best practice is to set zoning.check.nodeNameDisabled to 1, which disables checking the node WWN. Each FC device has a minimum of two worldwide names (WWNs). One is assigned to the device and is the node WWN, and the other is assigned to the FC port. A two-port FC HBA has a common node WWN for the HBA, and each port has a unique port WWN. The ISE WWN assignment mechanism uses the same value for both the node WWN and the WWN of the first port on the first MRC. Consider a Brocade fabric with one switch and Node WWN checking enabled (the default behavior) that has an ISE-2 connected and zoning set up per the following list: HBA Port 1 to MRC A Port 1 (Port WWN) HBA Port 2 to MRC B Port 5 (Port WWN) The expected number of paths to a LUN should be two; however, the observed number of paths is three. HBA Port 1 sees both MRC A Port 1 and MRC B Port 5 because the zoning is built by node WWN first and then by port WWNs. MRC B Port 5 has the same node WWN as MRC A Port 1s port WWN and so is included in the zone. Use the following procedure to disable and reconfigure the switch parameter. WARNING: This procedure disrupts I/O through the switch until the configuration process is complete. 1. Disable the switch by typing the following line at the switch command prompt:
Page 12
ISE
Best Practices
switchdisable 2. Configure the setting using the following steps. 3. At the switch command prompt, type: Configure 4. Select Zoning Operation Parameters from the menu. 5. Change the Disable NodeName Zone Checking to one. 6. Re-enable the switch by typing the following line at the switch command prompt: Switchenable 7. Check the setting by typing the following line at the switch command prompt: configshow | grep zoning 8. Verify that the switch displays zoning.check.nodeNameDisabled:1. Note. If your previous configuration utilized zones, review the configuration to ensure the change correctly represents your zoning preferences.
ISE Zoning
Think of Fiber Channel zones as virtual SCSI cables with two or more connectors (up to the maximum number of zone members supported by the switch). If a zone does not connect two devices explicitly, then the devices do not communicate unless the switch is configured for open zones. Open zoning allows all devices to connect and communicate with all other devices since the storage products (targets) are required to implement a LUN masking model, which selectively presents storage to individual hosts. If there are older storage devices that do not allow selective presentation, then zoning is required to provide the isolation necessary to make things work as expected. There are several Fiber Channel zoning models, each of which has its own set of challenges and benefits. The most common zoning models are open-zoning, single-host, single-initiator, and one-to-one. One of the largest impacts the zoning model has is reducing the number of fabric-wide events that happen when a change is made. For example, rebooting a single host will cause each FC port to log out of the fabric, log back in to the fabric, and then connect to storage devices and begin I/O. Every time a port logs into or out of a fabric, a registered state change notification (RSCN) event occurs, which is sent to every device already connected to the fabric. If the zoning does not handle this to prevent the broadcasts, server performance and access to storage can be negatively impacted.
Page 13
Best Practices
ISE
In this sample fabric, the host port WWNs are 21000024ff26415e and 21000024ff26415f, and the ISE port WWNs are 2000001F93103688 and 2000001F9310368C. It is assumed that under each zoning model described, each host port will see both MRC ports for redundancy.
Open Zoning
Open zoning is the simplest and easiest Fibre Channel fabric model to use, because under this model all nodes connected to the fabric can automatically see each other. Open zoning increases the number of devices that a host port must scan during boot or bus rescan operations. This can increase the host boot times, especially when using boot from SAN. In contrast, this model requires very little documentation to manage, and zone configurations do not need to be backed up. This model is most appropriate for fabrics consisting of a single FC switch due to the risk of RSCN broadcasts taking hosts offline.
Host-Based Zoning
Host-based zoning is the next simplest to implement. In this model, all target ports that a given host needs to access are included in the same zone with all initiators from the same host. This model reduces the RSCN broadcasts to only the zones containing the device that logged into or out of the fabric. In situations where one host port has a problem and sends out a lot of packets incorrectly, it is possible that the healthy host port will also be impacted because the same zone includes both host ports. This model has the fewest possible number of zones to manage, back up, and document. This model is most appropriate for smaller fabrics of just a few switches. The host-based zone membership for the fabric in Figure 12 would look like the following table:
Zone Name Members
HostA_ISE
HostAPort1_ISE HostAPort2_ISE
Page 14
ISE
Best Practices
One-To-One Zoning
One-to-One zoning is the most controlled model. Under this model, each zone represents a single virtual SCSI cable with exactly two connectors. If a host has two initiator ports per fabric and there are three storage devices with two ports on each fabric, then there are 12 zones per fabric per server. Obviously, this can get to be a very large number of zones very quickly, but RSCN broadcasts are kept to an extremely narrow set of devices, so the impact of a failing FC port is very small. The One-To-One based zone membership for the fabric in Figure 1 should be similar to that listed in the following table.
Zone Name Members
Recommendations
X-IO recommends the use of Single Initiator or One-To-One zoning for most applications to prevent RSCN broadcasts from negatively impacting an environment and to reduce the risk of accidentally presenting storage to the wrong server(s). Note that this zoning covers ISE-2 to servers and does not apply to zoning requirements for clusters, storage virtualizers such as Datacore, IBMs SVC, or ISE Mirroring. These types of zones may need to have multiple initiators in the same zone. Refer to the appropriate user guide for the cluster, storage virtualizer, or mirroring tool for the specific zoning configurations needed.
HBA Settings
A host bus adapter (HBA) is used to connect a server to a storage solution, such as an ISE. An HBA can have one, two, or four ports each and can communicate at 2, 4, 8, or 16 Gb per second. An HBA has several configurable parameters that control how it behaves with storage solutions. Different HBA vendors may have different terms for these parameters; please refer to vendor documentation for exact details on how to set these values. The individual parameters that are commonly adjusted for an ISE-2 are described below. Note. When storage products have conflicting HBA settings we recommend that different HBAs be used. This may apply to storage from different vendors or to storage products from the same vendor with different requirements.
Page 15
Best Practices
ISE
0Loop Only 1Point to Point Only 2Loop Preferred, Otherwise Point to Point (default) 3Point to Point, Otherwise Loop
Data Rate
An HBA port is normally set to auto-detect the maximum speed possible when connected to a switch or storage port. ISE-1 requires the MRC, switch, and HBA ports to be set to a fixed data rate. An ISE-2 can use auto-speed negotiation; however, X-IO recommends that the MRC and HBA ports be set to a fixed data rate when directly connected together (no switch between).
Page 16
ISE
Best Practices
Vendor-Specific Parameters
QLogic
QLogic HBA Settings
Parameter Name Connection Option Data Rate HBA BIOS Execution Throttle LUNs per Target
Table 4:
Fabric Value 2 2/4/8 Gbps Enabled (if Boot from SAN) 256 256
Direct Attach Value 2 (Required) 2/4/8 Gbps Enabled (if Boot from SAN) 256 256
*Depends on the HBA model, driver, and software being used. Emulex
Emulex HBA Settings
Parameter Name Link Timeout Node Timeout Queue Depth Queue Target / LUN
Table 5:
Default Value 30 30 32 0
Direct Attach Value ISE Not Supported ISE Not Supported ISE Not Supported ISE Not Supported
Cisco UCS To date there has been no need to alter the default HBA parameters for a Cisco UCS to work with an ISE-2. The adapter defaults for the HBA are shown in the figure below:
Page 17
Best Practices
ISE
The defaults apply to all HBA profiles, with the exception of VMware, which changes the highlighted Port Down Timeout (ms) from 30000 (30 seconds) to 10000 (10 seconds). All other values are identical between all profiles as of ISE-2 firmware 2.0.0.
Page 18
ISE
Best Practices
ISE Performance
Thrashing
Any array of hard disks lowers its performance characteristics as the disks are sliced up and populated with data since the heads require additional time to seek back and forth to the next requested block of data. This is commonly known as thrashing. The common root causes of thrashing are: Multiple applications accessing the same spinning media Frequently accessed data in LUNs at opposite ends of the storage pool Files at opposite ends of a file system being accessed (same LUN) The data access pattern of each application (sequential read / sequential write / random read / random write) Note. The data access pattern is typically the single largest contributor to thrashing.
Minimize Thrashing
Follow the best practices below to minimize thrashing. 1. Put frequently accessed data on separate DataPacs if at all possible. 2. Separate the high traffic applications onto separate ISEs or DataPacs. 3. Use separate LUNs for frequently accessed data and create these LUNs one after the other so that they are close to each other on the disks to minimize seek time. 4. Avoid deleting LUNs and creating new ones or resizing LUNs as this may fragment the LUN across the disks and impact performance. 5. Run a file system defragmentation tool of some sort. a. Ideally this tool will put the most frequently accessed files together at the front of the file system to minimize seek time. b. At a minimum, files should be re-arranged so that all blocks of a file are next to the other blocks of the file. 6. Consider RAID-10 for read-intensive applications since the data can be accessed from two different sources at once. All X-IO DataPacs ship with either 10 or 20 spinning drives, and the Hyper DataPac includes 10 solid state drives in addition to the 10 spinning drives. The ISE data placement algorithm distributes the data across these drives to maintain the performance of reading and writing to all drives in a DataPac at any point in time while maintaining the proper RAID level for each ISE volume (LUN).
Page 19
Best Practices
ISE
Page 20
ISE
Best Practices
Offline Upgrade
An offline upgrade is when an ISE-2 firmware upgrade is performed while the connected servers are shut down or the applications that use the storage are stopped. When an HBA sees a path go away, it waits for some period of time (typically 30 seconds) to see if the path is restored and then moves I/O to an alternate path. This timeout period and the associated lack of I/O is HBA specific and not directly related to the ISE-2. If the operating system, file system, or application cannot survive without I/O for this period of time, an offline upgrade is required.
Page 21
Best Practices
ISE
3. Select Properties.
Page 22
ISE
Best Practices
5. Ensure that the Enable write caching on the disk and Enable advanced performance check boxes are selected. 6. Click OK. 7. Repeat for each ISE volume.
Page 23
Best Practices
ISE
X-IO Value 0 30 50 10 1 1 25
0 30 20 3 1 0 40
Page 24
ISE
Best Practices
Page 25
Best Practices
ISE
5. Ensure that the Enable write caching on the disk and Enable advanced performance check boxes are selected. 6. Click OK. 7. Repeat for each ISE volume.
Note.
Page 26
ISE
Best Practices
Microsoft Knowledge Base Article ID 2468345 Microsoft Knowledge Base Article ID 2460971
Required Hot-Fixes for Windows 2008 SP2 Microsoft Knowledge Base Article ID 968675 Microsoft Knowledge Base Article ID 970525 Microsoft Knowledge Base Article ID 972797 Microsoft Knowledge Base Article ID 974878 Microsoft Knowledge Base Article ID 976674 Microsoft Knowledge Base Article ID 976748 Microsoft Knowledge Base Article ID 977001 Microsoft Knowledge Base Article ID 977153 Microsoft Knowledge Base Article ID 977287 Microsoft Knowledge Base Article ID 977675 Microsoft Knowledge Base Article ID 977890 Microsoft Knowledge Base Article ID 978157 Microsoft Knowledge Base Article ID 979458 Microsoft Knowledge Base Article ID 979743 Microsoft Knowledge Base Article ID 979764 Microsoft Knowledge Base Article ID 981357 Microsoft Knowledge Base Article ID 2406705
Offline Upgrade ISE-2 Firmware 2.2.1 or older must be upgraded offline due to the amount of time required to perform certain parts of the upgrade. All hot fixes listed must be installed. ISE Multi-Path Suite (ISE-MP) 6.6.0.10 or newer (improves path stability); exception for Cisco UCS.
Online Upgrade (clusters) ISE firmware 2.2.3 or later. All hot fixes listed must be installed. ISE Multi-Path Suite (ISE-MP) 6.6.0.10 or newer (improves path stability); exception for Cisco UCS. No boot from SAN volumesSome issues have been reported that seem to occur only on cluster nodes booting from SAN. Until the cause is determined and a workaround or a fix is available, X-IO recommends performing offline upgrades with cluster nodes configured to boot from SAN. Cluster Service Resource Maximum Restart count set to be equal to three times the number of ISE2s + 1. As an example, if there are four ISEs that contribute storage to the cluster, the restart count would be set to 13 ((3 * 4) + 1).
Page 27
Best Practices
ISE
Required for the duration of the upgrade processcan be set to other values for normal operations. X-IO recommends using the cluster maintenance mode to perform upgrades.
Configuring Cluster Disk Resource Failover Policies Follow the steps below to configure the cluster resource failover policies. 1. Open the Failover Cluster Manager GUI. 2. Select the Storage node in the left-hand navigation pane. 3. Select an ISE-2 clustered disk, right-click, and then select Properties from the drop-down menu.
Page 28
ISE
Best Practices
5. Change the Maximum restarts in the specified period value. This should be equal to 1 + three times the number of ISE-2s in the cluster. In Figure 22 the value is set to 4, which is appropriate for a single ISE-2. 6. Repeat for each ISE-2 disk in the cluster. Configuring Clustered Services and Applications 1. Expand the Services and Applications node in the left-hand navigation pane. 2. Select each service or application, right-click, and then select Properties from the drop-down. 3. Select the Failover tab.
Page 29
Best Practices
ISE
4. Change the Maximum failures in the specified period. This value should be equal to 1 + three times the number of ISE-2s in the cluster. 5. In the main pane for each clustered application, set the failover properties for each resource.
Page 30
ISE
Best Practices
6. Right-click each resource in the resource list (see Figure 24), select Properties, and then select the Policies tab. 7. Change the Maximum restarts in the specified period to the same value used for the cluster disk resource. 8. Repeat these steps for each resource in each clustered service or application. Setting Maintenance Mode During an Upgrade X-IO strongly recommends placing clustered storage into maintenance mode, which prevents failover of cluster disks while running ISE firmware upgrades. The following process demonstrates how to enable and then disable maintenance mode. 1. Open Failover Cluster Manager. 2. Navigate to the Storage node in the left-hand navigation pane. 3. Right-click each ISE-2 volume, select More Actions, then select Turn On Maintenance Mode for this disk. 4. The GUI shows that the disk is in maintenance mode.
5. Once all ISE-2s are upgraded, turn off maintenance mode using the same process (select Turn Off Maintenance Mode for this disk).
Page 31
Best Practices
ISE
Windows 2012
ISE-1 will require 1.8.0 firmware; ISE-2 will require 2.4.0. Required Hot-Fixes for Windows 2012 Microsoft Knowledge Base Article 2779768
Multi-pathing
X-IO recommends the use of Windows Native MPIO for ISE storage. In order to improve the availability of the storage during common path loss scenarios, including firmware upgrade, the following MPIO DSM registry key changes are recommended:
Parameter Name Default Value
X-IO Value 0 30 50 10 1 1 25
0 30 20 3 1 0 40
Claiming MPIO disks will cause the host the reboot. To configure native MPIO to claim the ISE-1 and ISE-2 volumes, use the command lines below. Note that this assumes that the MPIO feature is already installed, and that the items in the quotes are case sensitive. For ISE-1: mpclaim -r -i -d "XIOTECH ISE1400" For ISE-2: mpclaim -r -i -d "XIOTECH ISE2400"
Linux
Red Hat Enterprise Linux (RHEL) and SUSE Linux Enterprise Server (SLES)
The below are best practices recommendations for RHEL and SLES. HBA Configuration For direct attached systems, the queue depth parameter ql2xmaxqdepth should be 256, and the login timeout ql2xlogintimeout should be 5. Fabric connected systems should use defaults. In order for this parameter to persist across reboots, follow the instructions for rebuilding the RAMDISK image in the QLogics Linux driver documentation from QLogics web site. See the Deploying the Driver section and find the related OS version to follow the instructions for Automatically load the driver by rebuilding the RAM disk. This requires a reboot to take effect.
Page 32
ISE
Best Practices
Multi-path Settings Refer to the RHEL or SLES documentation for the chosen multi-path product for additional information on these parameters. Device-specific modifications must be made in the /etc/multipath.conf file. Verify that the polling interval is set to 10 in the defaults section of the /etc/multipath.conf file, as follows: Defaults { } polling_interval 10 } The following are examples of what the device entries would look like in the multipath.conf file: Note. For ISE-1, use product ID ISE1400, and for ISE-2, use product ID ISE2400
Page 33
Best Practices
ISE
RHEL/CentOS/Oracle EL 4.x
devices { device { vendor product path_grouping_policy getuid_callout path_checker prio_callout path_selector failback no_path_retry user_friendly_names XIOTECH ISE1400 multibus "/sbin/scsi_id -g -u -s /block/%n" tur none round-robin 0 immediate 12 yes
} }
RHEL/CentOS/Oracle EL 5.x
devices { device { vendor product path_grouping_policy getuid_callout path_checker prio_callout path_selector failback no_path_retry user_friendly_names XIOTECH ISE1400 multibus "/sbin/scsi_id -g -u -s /block/%n" tur none round-robin 0 immediate 12 yes
} }
RHEL/CentOS/Oracle EL 6.0/6.1
defaults { udev_dir polling_interval selector path_grouping_policy getuid_callout prio path_checker rr_min_io max_fds rr_weight failback no_path_retry fast_io_fail_tmo dev_loss_tmo user_friendly_names { device /dev 10 round-robin 0 multibus "/lib/udev/scsi_id --whitelisted --device=/dev/%n" alua tur 100 8192 priorities immediate fail 5 600 yes
# # # # # #
} devices { vendor product path_grouping_policy prio_callout path_checker rr_min_io rr_weight failback dev_loss_tmo no_path_retry user_friendly_names
"XIOTECH" "ISE1400" multibus none tur 100 priorities immediate infinity 12 yes
} }
Page 34
ISE
Best Practices
RHEL/CentOS/Oracle EL 6.2
defaults { udev_dir polling_interval selector path_grouping_policy getuid_callout prio path_checker rr_min_io max_fds rr_weight failback no_path_retry fast_io_fail_tmo dev_loss_tmo user_friendly_names { device /dev 10 round-robin 0 multibus "/lib/udev/scsi_id --whitelisted --device=/dev/%n" alua tur 100 8192 priorities immediate fail 5 infinity yes
# # # # # #
} devices { vendor product path_grouping_policy prio_callout path_checker rr_min_io rr_weight failback fast_io_fail_tmo dev_loss_tmo no_path_retry user_friendly_names
"XIOTECH" "ISE1400" multibus none tur 100 priorities immediate 5 infinity 12 yes
} }
SLES 10 SPx
devices { device { vendor product path_grouping_policy getuid_callout path_checker prio_callout path_selector failback no_path_retry user_friendly_names "XIOTECH" "ISE1400" multibus "/sbin/scsi_id -g -u -s /block/%n" tur "none" "round-robin 0" immediate 12 no
} }
SLES 11
devices { device { vendor product path_grouping_policy getuid_callout path_checker prio_callout path_selector failback no_path_retry user_friendly_names "XIOTECH" "ISE1400" multibus "/lib/udev/scsi_id -g -u -d /dev/%n" tur "none" "round-robin 0" immediate 12 no
} } defaults { udev_dir polling_interval path_selector path_grouping_policy getuid_callout path_checker rr_min_io failback no_path_retry /dev 10 "round-robin 0" multibus "/lib/udev/scsi_id -g -u -d /dev/%n tur 100 immediate 12
Page 35
Best Practices
dev_loss_tmo user_friendly_names } 150 no
ISE
Unix
AIX
X-IO does not support online upgrade of ISE-2s and Hyper ISEs on AIX operating systems.
VMware ESXi
Some general guidelines for both ISE-1 and ISE-2 with VMware ESXi are as follows: X-IO recommends using fixed (preferred path) for the native multi-path settings for ISE LUNs. X-IO also supports the use of Round-Robin MPIO for ESXi. For Windows VMs, use the preferred allocation size settings. Refer here for more information about Boot From SAN using ESX systems. Note. Note. This requires Qlogic driver qla2xxx-934.5.4.0-855364 or the inbox driver from Emulex. We currently require round-robin load-balancing to use this.
5.x
Refer to HBA Configuration on page 32 to ensure that the HBA parameters are set correctly. A reboot of the ESXi host will most likely be required when changing these parameters. If you are using a VMware HA configuration, cluster nodes can be rebooted one at a time. The assumption is that virtual machines are migrated to other nodes while doing maintenance on a given cluster node. Verify the changes have been made and then migrate virtual machines back to their preferred nodes if needed after the reboot. Direct Attach Login Timeout Values for QLogic HBAs To facilitate faster logins following link down or link up events in Direct Attach configurations with ISE-2, the following ql2xlogintimeout parameter for QLogic HBAs is recommended for use with ESXi 5. # esxcli system module parameters set -p ql2xlogintimeout=5 -m qla2xxx Following the host reboot, use the following guidelines to check the ql2xlogintimeout parameter and ensure that it is set properly: # esxcli system module parameters list -m qla2xxx | grep ql2xlogintimeout ql2xlogintimeout int 5 Login timeoutvalue in seconds. HBA Queue Depth Considerations Review the VMware Knowledge Base references that relate to setting HBA queue depth and configuring VM disk request limits in attempting to increase queue depth or throttling the queue depth down to prevent overloading the storage.
Page 36
ISE
Best Practices
Changing the Queue Depth for QLogic and Emulex HBAs For example, to set the ql2xmaxqdepth parameter to 256, use the following command on each ESXi node: # esxcli system module parameters set -p ql2xmaxqdepth=256 -m qla2xxx Following the host reboot, check the ql2xmaxqdepth parameter to see if it is set properly: # esxcli system module parameters list -m qla2xxx | ql2xmaxqdepth devices. Note. int grep qdepth
Please use this parameter with caution as it CAN affect other storage used by the same adapters.
Change Maximum Outstanding Disk Requests for Virtual Machines If you adjusted the LUN queue depth, change the Disk.SchedNumReqOutstanding parameter so that its value matches the queue depth. The parameter controls the maximum number of outstanding requests that all virtual machines can issue to the LUN. Change this parameter only when you have multiple virtual machines active on a LUN. The parameter does not apply when only one virtual machine is active. In that case, the bandwidth is controlled by the queue depth of the storage adapter. Procedure 1. In the vSphere Client, select the host in the inventory panel. 2. Click the Configuration tab and click Advanced Settings under Software. 3. Click Disk in the left panel and scroll down to Disk.SchedNumReqOutstanding. 4. Change the parameter value to the number of your choice and click OK. This change can impact disk bandwidth scheduling, but experiments have shown improvements for diskintensive workloads. Raw Device Maps (RDMs) When using RDMs with VMware ESXi 5.0, the SCSI timeouts on RDMs should be adjusted on Linux Guest OS versions. The default SCSI timeouts for RDMs on Linux Guest OS versions are set to 30 seconds. X-IO recommends setting this value to at least 120 seconds to cover certain conditions, such as controller firmware upgrades for the ISE-2 platform. To change these values, the administrator can create a script on the Linux Guest OS under the /etc/udev/ rules.d directory. As an example, the script in use is called 99-scsidisk.rules. This does not affect virtual disk timeout values, which are set to 180 seconds by default. # cat 99-scsi-disk.rules #Addition by USER to test RDM scsi timeout settings. ACTION=="add", SUBSYSTEMS=="scsi", SYSFS{type}=="0|7|14", RUN+="/bin/sh -c 'echo 120 > /sys/$DEVPATH/timeout'" A Linux Guest OS with existing RDMs may need to be rebooted for this to take effect. RDMs look like a normal physical disk when viewed from within the Guest OS with the /usr/bin/lsscsi command: # lsscsi
Page 37
Best Practices
ISE
[1:0:0:0] cd/dvd NECVMWar VMware IDE CDR10 1.00 /dev/sr0 [2:0:0:0] disk VMware Virtual disk 1.0 /dev/sda [2:0:1:0] disk XIOTECH ISE2400 A /dev/sdb [2:0:2:0] disk XIOTECH ISE2400 A /dev/sd Once the parameter is properly set, it can be verified in the /sys/class/scsi_disk directory structure. For example: # cat sys/class/scsi_disk/2:0:1:0/device/timeout120 Mirror Special Considerations
ESXi 5.1 Cluster Active-Active
1. ESXi 5.1 only (no DAS). 2. Up to a 6-node cluster is supported. Note. Windows VMs are not supported at this time for this configuration.
3. Before breaking an active-active mirror, switch to using a fixed path on each lun that will participate in the break. 4. The preferred fixed path must be a path on the mirror master ISE. 5. The preferred path must be set on each cluster node. For example (selected below is a preferred path to the mirror master for the VMirror): From show vmirror: VMirror - tc02esxclu_shared_DS8: Status : Operational (None) Type : High Availability (long lived) GUID : 6001F931005C8000024F000400000000 Created : Wed Dec 19 22:02:43 2012 Synch Progress: 100% SameId : yes VDisk Member Count: 2 Master VDisk Member ISE ID: 2000001F931005C8 Master VDisk Member GUID: 6001F931005C800001B6000200000000 Member VDisks: Member 1: ISE ID: 2000001F931005C8, VDisk GUID: 6001F931005C800001B6000200000000, LDID: 23, Status: Operational (None) Member 2: ISE ID: 2000001F93100150, VDisk GUID: 6001F931001500000441000200000000, LDID: 143, Status: Operational (None) -------------------------------------------------------------------------Matching LUN from within vCenter Server:
Page 38
ISE
Best Practices
ESXi 5.1 BFS Cluster Upgrades with Active-Active Mirrors Requires: 1. http://kb.vmware.com/selfservice/microsites/ search.do?language=en_US&cmd=displayKC&externalId=1033696 2. QLogic driver: 934.5.4.0-855364 3. Emulex driver is inbox 4. Must use Round Robin ESXi 5.1 Cluster Active-Active Mirror Breaks 1. Fixed paths must be used when breaking mirrors.
Page 39
Best Practices
ISE
Page 40
ISE
Best Practices
Page 41
Best Practices
ISE
If any MDISK goes offline, the entire MDISK POOL goes offline. If the MDISK POOL goes offline, all SVC volumes hosted by the MDISK POOL are also offline and hosts will lose access.
Zoning
Single Fabric
Zone Purpose Zone Members
All SVC ports At least one port from each MRC on each ISE-2 Both MRC Ports on each ISE-1 All SVC ports At least one HBA port
Page 42
ISE
Best Practices
Redundant Fabric
Zone Purpose Fabric A Members Fabric B Members
SVC ports 1 and 2 At least one port from each MRC on each ISE-2 Both MRC ports on each ISE-1 SVC ports 1 and 2 At least one host HBA port
SVC ports 3 and 4 At least one port from each MRC on each ISE-2 Both MRC ports on each ISE-1 SVC ports 3 and 4 At least one host HBA port
Zoning Limitations
In order to prevent single points of failure, it is recommended to zone all connected ISE MRC ports to the SVC controller ports. It is possible to have the ISE shared with an SVC and other systems on the same fabric. This will not cause a problem for the SVC or the ISE as long as the LUNs are presented to ONLY one system. If a volume from an ISE is presented to both the SVC as an MDISK and to a host as a LUN, data corruption will occur. To avoid a multi-pathing conflict, it is recommended to have a host view storage from either the SVC or from the ISE but not from both at the same time.
ISE Volumes
Volume Size
There are no hard and fast rules on the size of ISE volumes to use. To maintain consistent performance characteristics of the MDISK POOL, it is recommended to use ISE volumes of equal size within the same MDISK POOL. Different MDISK POOLs can have different LUN sizes behind them with no performance impact.
Volume Placement
While it is technically possible to create a single large MDISK POOL of all LUNs on all ISEs behind an SVC controller pair, it is a very risky move because the failure of a single ISE or a single DataPac will take the entire configuration offline. The recommended practice is to create multiple MDISK POOLs, each of which contain only ISE volumes from a single ISE DataPac.
Page 43
Best Practices
ISE
Page 44
ISE
Best Practices
External References
Storage and Networking Industry Association (SNIA) Dictionary
http://www.snia.org/education/dictionary
Page 45
Best Practices
ISE
Page 46
Best Practices
Page 47