Some content of this application is unavailable at the moment.
If this situation persist, please contact us atFeedback&Contact
1. (WO2016043953) FIBRE CHANNEL STORAGE ARRAY METHODS FOR PORT MANAGEMENT
Note: Text based on automatic Optical Character Recognition processes. Please use the PDF version for legal matters

CLAIMS

1. A storage array, comprising,

a controller of the storage array configured to operate a Fibre Channel protocol, the controller including memory and a processor,

the processor is configured to execute a driver and user-space processes that include a primary process and a secondary process, the user-space processes are configured to process SCSI events for the driver to service one or more IT Nexus connections for one or more initiators, wherein a port of the driver is assigned to the primary process to execute input/output (I/O) requests to the storage array from the one or more initiators, wherein when the primary process fails to operate the secondary process performs a port grab of the port and the driver allows the secondary process to perform the port grab since the primary process is not operational,

wherein the secondary process executes limited requests that do not include I/O requests to the storage array;

wherein the port grab by the secondary process maintains the one or more IT Nexus connections active between the storage array and the one or more initiators.

2. The storage array of claim 1,

wherein the processor is configured to enable the primary process to become operational, the return of the primary process acting to force a port grab by the primary process;

wherein the port grab by the secondary process maintains the one or more IT Nexus connections active between the storage array and the one or more initiators.

3. The storage array of claim 1, wherein the secondary process terminates in-process commands that had been intended for the primary process, wherein terminating the in-process commands enables the one or more initiators to perform recovery actions that cause a resending of the in-process commands to the secondary process for handling.

4. The storage array of claim 1, wherein the secondary process processes in-process commands that had been intended for the primary process, wherein processing the in-process commands enables the one or more initiators to perform recovery actions.

5. The storage array of claim 2, wherein the primary process terminates in-process commands that had been intended for the secondary process, wherein terminating the in-process commands enables the one or more initiators to perform recovery actions that cause a resending of the in-process commands to the primary process for handling.

6. The storage array of claim 1, further comprising,

a Fibre Channel (FC) card for connecting to an FC fabric, the FC card being in communication with the driver of the controller and the FC fabric provides interconnection to the one or more initiators.

7. The storage array of claim 1, further comprising,

wherein the primary process execute input/output (I/O) requests using an asymmetric logical unit access (ALUA) active/optimized process; and

wherein the limited requests executed by the secondary process use an ALUA transitioning process.

8. The storage array of claim 2, wherein the driver advertises a file through which the driver communicates with the primary process,

wherein the primary process writes code to the file to force the port grab by the primary process; and

wherein the secondary process writes code to the file to request the port grab by the secondary process when the primary process is not operational.

9. A method for processing failover operations in a storage array configured for Fibre Channel communication, comprising:

executing a primary process in user space of a controller of the storage array, the primary process configured to process request commands from one or more initiators via one or more connections, the primary process connecting to a port of the storage array when in operation;

executing a secondary process in the user space of the controller, the secondary process configured to process request commands from one or more of the initiators, and the secondary process not having a connection to the port when the primary process is in operation;

detecting that the primary process has entered a state of non-operation, and in response allowing the secondary process to perform a port grab of the port while maintaining the one or more connections;

resuming execution by the secondary process while the primary process is in the non-operation state.

10. The method of claim 9, further comprising,

causing a replay of in-progress commands that were to be executed by the primary process before entering the state of non- operation;

deleting the in-progress commands before resuming execution by the secondary process.

11. The method of claim 9, further comprising,

detecting that the primary process has returned from the state of non-operation, wherein the primary process forces a port grab of the port while maintaining the one or more connections;

resuming execution by the primary process.

12. The method of claim 11,

wherein the primary process is configured to execute input/output (I/O) requests using an asymmetric logical unit access (ALUA) active/optimized process; and

wherein limited requests are executed by the secondary process using an ALUA transitioning process.

13. The method of claim 11, wherein a driver of the controller is configured to manage the port, the driver is further configured to delegate operations to the primary process and the secondary process, depending on which has control of the port, further comprising,

advertising, by the driver, a file through which the driver communicates with the primary process,

wherein the primary process writes code to the file to force the port grab by the primary process; and

wherein the secondary process writes code to the file to request the port grab by the secondary process when the primary process is not operational.

14. The method of claim 13, further comprising,

replaying in-progress commands, by the driver, after the port grab by the secondary process or the primary process; and

terminating the in-progress commands before resuming execution by either the secondary process or the primary process.

15. The method of claim 9, wherein the one or more connections are IT_Nexus connections of a Fibre Channel storage network.

16. A method for processing failover operations in a storage array configured for Fibre Channel communication, comprising:

executing a primary process in user space of a controller of the storage array, the primary process configured to process request commands from one or more initiators, the primary process having access to a volume manager for serving data input/output (I/O) requests, and the primary process having a connection to a port of the storage array when in operation; executing a secondary process in the user space of the controller, the secondary process configured to process request commands from one or more of the initiators, the secondary process not having access to the volume manger and having access to data for responding to non-I/O requests, and the secondary process not having a connection to the port when the primary process is in operation;

detecting, by the secondary process, that the primary process has entered a state of non-operation, and in response performing a port grab of the port by the secondary process;

causing a replay of in-progress commands that were to be executed by the primary process before entering the state of non- operation;

deleting the in-progress commands; and

continuing to execute the secondary process while the primary process is the non-operation state.

17. The method of claim 16, wherein when the primary process returns to operation, the method includes,

performing a port grab of the port by the primary process;

causing a replay of in-progress commands that were to be executed by the secondary process before the port grab by the primary process;

deleting the in-progress commands of the secondary process; and

continuing to execute the primary process.

18. The method of claim 16, wherein the controller is an active controller that processes each of the primary process and the secondary process.

19. The method of claim 16, wherein the port is provided by a driver of the controller, and the driver serves as a target-side endpoint for one or more SCSI IT Nexus handled by the port.

20. A storage system, comprising,

an active controller having program instructions for,

executing a primary process in user space of the active controller, the primary process configured to process request commands from one or more initiators, the primary process having access to a volume manager for serving data input/output (I/O) requests, and the primary process having a connection to a port of storage system when in operation;

executing a secondary process in the user space of the controller, the secondary process configured to process request commands from one or more of the initiators, the secondary process not having access to the volume manger and having access to data for responding to non-I/O requests, and the secondary process not having a connection to the port when the primary process is in operation;

detecting, by the secondary process, that the primary process has entered a state of non-operation, and in response performing a port grab of the port by the secondary process;

causing a replay of in-progress commands that were being executed by the primary process before entering the state of non-operation;

deleting the in-progress commands; and

continuing to execute the secondary process while the primary process is in the non-operation state.

21. Computer program instructions stored on non-transitory storage, the computer program instructions configured to process failover operations in a storage array configured for Fibre Channel communication, comprising:

instructions for executing a primary process in user space of a controller of the storage array, the primary process configured to process request commands from one or more initiators via one or more connections, the primary process connecting to a port of the storage array when in operation;

instructions for executing a secondary process in the user space of the controller, the secondary process configured to process request commands from one or more of the initiators, and the secondary process not having a connection to the port when the primary process is in operation;

instructions for detecting that the primary process has entered a state of non-operation, and in response allowing the secondary process to perform a port grab of the port while maintaining the one or more connections;

instructions for resuming execution by the secondary process while the primary process is the non-operation state.

22. The computer program instructions of claim 21, further comprising,

instructions for causing a replay of in-progress commands that were to be executed by the primary process before entering the state of non-operation;

instructions for deleting the in-progress commands before resuming execution by the secondary process.

23. The computer program instructions of claim 21, further comprising,

instructions for detecting that the primary process has returned from the state of non-operation, wherein the primary process forces a port grab of the port while maintaining the one or more connections;

instructions for resuming execution by the primary process.

24. The computer program instructions of claim 21,

wherein the primary process is configured to execute input/output (I/O) requests using an asymmetric logical unit access (ALUA) active/optimized process; and

wherein limited requests are executed by the secondary process using an ALUA transitioning process.

25. The computer program instructions of claim 21, wherein a driver of the controller is configured to manage the port, the driver is further configured to delegate operations to the primary process and the secondary process, depending on which has control of the port, further comprising,

instructions for advertising, by the driver, a file through which the driver communicates with the primary process,

wherein the primary process writes code to the file to force the port grab by the primary process; and

wherein the secondary process writes code to the file to request the port grab by the secondary process when the primary process is not operational.