Browse Prior Art Database

Persistent Reservation Translation for Faster Port Failover on a Storage Controller Disclosure Number: IPCOM000247664D
Publication Date: 2016-Sep-26
Document File: 2 page(s) / 53K

Publishing Venue

The Prior Art Database


Persistent Reservations are traditionally stored against the port through which they are registered. In a Storage Controller, Failover ports may become available to provide redundancy during the loss of a port. A method is presented where Persistent Reservations are translated at the time of creation to be stored against these Failover ports, rather than requiring migration of the Persistent Reservations to Failover ports at the time of failover.

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

Page 01 of 2

Persistent Reservation Translation for Faster Port Failover on a Storage Controller

Disclosed is a system for translating SCSI Persistent Reservations in a storage controller, so that they are held against both the port through which they originated, and also against any failover ports that are expected to replace that original port during failover of a single node in the storage controller. The novel element is that translation occurs at the time of creation, with the Persistent Reservation stored

against a failover port that will not be presented to hosts during normal operations. In the event of failover, the port will be made available with the Persistent Reservation already in place. This is an alternative to migrating Persistent Reservations immediately after the failover occurs.

    SCSI Initiators may take SCSI-3 Persistent Reservations against a volume to restrict access to that volume to themselves/a set of Initiators. This allows access from an Initiator, through a particular Port, to a particular Volume.

    With NPort ID Virtualisation, two virtual ports may be logically equivalent in terms of their behaviour - for example, a Host port on Node 1 of a Storage Controller may normally provide access to a volume. But in the event that Node 1 fails, a Failover port on Node 2 should provide access to the same volume.

    If a reservation exists on these volumes, it needs to allow access through either port. Traditionally this might be solved by clearing the reservations on node failure and requiring hosts to re-take the reservation; or by the Storage Controller migrating the reservation at the time of failover, by changing its definition so that it no longer relates to the original port, and now relates to the failover port. This migration would also need to be reversed when the original node is restored.

Both of these processes take time/effort at the time of the failure, where

storage controller resources may already be stressed. They may require manual steps. And they increase the duration of the volume being unavailable to the host.

    A novel method is proposed to translate the Persistent Reservations at the time of creation, so that at the time of a node failover the reservations are already in place as soon as a failover port is opened. These reservations can be left in place, and do not need to be migrated/translated when the failed node is restored. Any new reservations created during failover do not require migration when a node is restored.

    Traditionally, a registration or reservation for a volume is taken through a port on a node of a storage controller. Information about that registration/reservation is cascaded to all nodes in the storage controller, such that when an attempt is made to access the volume through any port or any node, it is blocked unless it is the original port/node.

    With the proposed implementation, at the point where the registration/ reservation information is transmitted through the storage controller,...