Browse Prior Art Database

Prioritizing IO Requests within a group of VSCSI Adapters

IP.com Disclosure Number: IPCOM000236970D
Publication Date: 2014-May-23
Document File: 2 page(s) / 30K

Publishing Venue

The IP.com Prior Art Database

Abstract

In a virtualized environment , multiple Virtual SCSI Adapters are typically serviced by the same storage port in SAN. As long as the number of pending exchanges on a storage port remain below a threshold , there is no resource contention amongst the VSCSI Adapters . If the workload exceeds this threshold , Storage servers typically start throttling requests , leading to performance degradation. The innovation proposes a method to anticipate this performane degradation and provide quality of service via IO prioritization within the group of VSCSI Adapters.

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

Page 01 of 2

Prioritizing IO Requests within a group of VSCSI Adapters

Anticipating Performance Degradation -------------------------------------------------
Consider a typical Storage Server DS8000 as an example :

As soon as a storage port has more than 1500 exchanges pending, it allows only one open exchange per ITL(ITL = Initiator-Target-LUNs).

This forces the server to slow down and provides a fair ratio for all connected server to the ports. As soon as 2000 exchanges are queued on the port, a SCSI
status code 'busy' will be sent out to all connected server. This allows the DS8000 to work on all queued commands.

The 'busy' will be lifted as soon as less then 1700 commands are left in the queue.

From this example it is clear that here would be performance degradation once throttling mechanism kicks after the threshold of pending exchanges is reached
[ in the case above , threshold mark is 1500 ]

The idea here is to get feedback information from Storage Server once the number of pending exchanges on the storage port exceeds a limit.

This limit will be defined as the throttling point minus the maximum queue depth of the LUN amongst the LUNs backing the VSCSI Adapter group.

To achieve this objective, a method is proposed on similar lines to proposal X3T9.2/92-214 rev 0from T10 Technical Committee :

During RESET sequence of LUNs , initiator would inform the Storage Server of the command queue depth via a new QUEUE DEPTH INFO Message.
[ Similar to MINIMUM QUEUING DEPTH REQUEST (MQDR) message ]

Storage Server would calculate the limit as defined above , based on all...