Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Method to reduce latency in MPIO failover

IP.com Disclosure Number: IPCOM000247800D
Publication Date: 2016-Oct-06
Document File: 3 page(s) / 63K

Publishing Venue

The IP.com Prior Art Database

Abstract

Typically, storage driver stack is a layered stack where HBA driver is at lowest level and above that SCSI and Multipath I/O (MPIO) driver/software sits. The reason for I/O failure is determined at HBA driver level but MPIO software is not aware or does not take action based on that. Following article proposes a method where, the I/O from HBA driver will be failed back to MPIO software with a specific reason that will be understood by the MPIO software. MPIO software will take decision based on the specific reason for selecting the next path. If the I/O failed because of a storage port failure, then don't select path that has same storage port if there are more path available. If I/O failed because of an HBA port failure, then don't select the path that has same HBA port if there are more path available.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 53% of the total text.

Page 01 of 3

Method to reduce latency in MPIO failover

In a typical SAN configuration, servers are connected to storages using multiple HBA ports and multiple storage ports. This enables access to storage from server using multiple paths also called MPIO. MPIO is essential for high availability for storage I/O. If there is a failure on one of the path then I/O is tried on the other path but there are chances that the same failure exists on the newly selected path, this introduces unnecessary latency for I/O completion.

For example, if in a SAN configuration there are 2 HBA ports (HA and HB) connected to 2 target ports (TA and TB) then there will be four paths to a disk as depicted in Figure 1.


1. HA->TA
2. HB->TA
3. HA->TB
4. HB->TB

Figure 1

Let us say if an I/O fails because the storage port TA went down (as shown in Figure 2), then I/O will fail on that path (path 1) and next path (path 2) will be tried. Since this path also uses TA, I/O will fail on this path as well. Many times in SAN environment when storage port goes down then I/O are lost in SAN and server has to wait for I/O timeout. The I/O timeout ranges from 30 seconds to couple of minutes depending on the storage. This is a huge delay in I/O completion when there are healthy paths available. The same issue exists when HBA port gone bad (link went down etc.,) as shown in Figure 3.

1


Page 02 of 3

Figure 2 Figure 3

This article proposes a method for efficient path selection which determines and make use of the I/O failure type.

Storage Port Failure:


1. When there is a failure of storage port, then I/O will either timeout or a notification will be received by the HBA driver. For example, Fibre Channel Registered state change notification(RSCN) will be received by HBA driver in the event of storage port leaving SAN.

2. HBA driver will use discovery method to find storage port is available on SAN. For example, in Fibre channel, Get Port Identifier(GID_PN) Common Transport for Generic Services (CTIU) can be used to discover the target port availability on the fabric.

3. If target port is not found...