Securing crash dump files

Patent metadata

Field	Value
Publication number	US-9720757-B2
Application number	US-201615186754-A
Country	US
Kind code	B2
Filing date	Jun 20, 2016
Priority date	Jul 31, 2012
Publication date	Aug 1, 2017
Grant date	Aug 1, 2017

Abstract

In a computer storage system, crash dump files are secured without power fencing in a cluster of a plurality of nodes connected to a storage system. Upon an occurrence of a panic of a crashing node and prior to receiving a panic message of the crashing node by a surviving node loading, in the cluster, a capturing node to become active, prior to a totem token being declared lost by the surviving node, for capturing the crash dump files of the crashing node.

First claim

What is claimed is:

1. A method for securing crash dump files while avoiding power fencing in a cluster of a plurality of nodes connected to a storage system using a processor device, the method comprising:
upon an occurrence of a panic of a crashing node and prior to receiving a panic message of the crashing node by a surviving node, loading, in the cluster, a capturing node to become active, prior to a totem token being declared lost by the surviving node, for capturing the crash dump files of the crashing node.

2. The method of claim 1 , further including manipulating the surviving node to continue to operate under the assumption the power fencing was performed on the crashing node; and
restricting the capturing node from gaining access to the storage system for preventing unsynchronized access to the storage system in order to prevent data corruption.

3. The method of claim 1 , further including continuously sending the panic message from the crashing node to the surviving node after the end of each of a predetermined time interval, the panic message indicating both the panic occurring in the crashing node and the capturing node capturing the crash dump files.

4. The method of claim 1 , further including issuing a successful notification to the surviving node that the power fencing was performed on the crashing node without actually performing the power fencing.

5. The method of claim 4 , wherein the issuing further includes issuing the successful notification after both the totem token is declared a loss and the panic message is received by the surviving node.

6. The method of claim 1 , further including, performing at least one of:
sending the totem token from each one of the plurality of nodes to each other one of the plurality of nodes to indicate that each one of the plurality of nodes sending the totem token is active and not in a panic mode, wherein the totem token is sent after the end of every panic time interval, and
declaring the totem token as lost by the surviving node if the totem token is not received from the crashing node upon an expiration of the panic time interval.

7. The method of claim 6 , further including determining if the panic time interval has expired by checking if a time stamp of the totem token that was last received is outside of the range of the panic time interval.

8. The method of claim 1 , further including performing a reboot operation by the crashing node upon successfully capturing the crash dump files by the capturing node, wherein an end panic mode message is sent from the crashing node to the surviving node upon successfully capturing the crash dump files by the capturing node.

9. A system for securing crash dump files while avoiding power fencing in a cluster of a plurality of nodes connected to a storage system, the system comprising:
a power fencing device connected to each one of the plurality of nodes in a first layer,
a fencing agent connected to the power fencing device in the first layer in the cluster,
a proprietary fencing agent hierarchically configured in a second layer before the fencing agent and associated with each one of the plurality of nodes,
a processor device controlling the plurality of nodes, the fencing agent, and the propriety fencing agent, wherein processor device:
upon an occurrence of a panic of a crashing node and prior to receiving a panic message of the crashing node by a surviving node, loads in the cluster a capturing node to become active, prior to a totem token being declared lost by the surviving node, for capturing the crash dump files of the crashing node.

10. The system of claim 9 , wherein the processor device manipulates the surviving node to continue to operate under the assumption the power fencing was performed on the crashing node, and
restricts the capturing node from gaining access to the storage system in order to prevent data corruption.

11. The system of claim 9 , wherein the processor device continuously sends the panic message from the crashing node to the proprietary fencing agent associated with the surviving node after the end of each of a predetermined time interval, the panic message indicating both the panic occurring in the crashing node and the capturing node capturing the crash dump files.

12. The system of claim 9 , wherein the processor device issues a successful notification by the proprietary fencing agent to the surviving node that the power fencing was performed by the power fencing device on the crashing node without actually performing the power fencing by the power fencing device.

13. The method of claim 12 , wherein the processor device issues the successful notification by the proprietary fencing agent after both the totem token is declared a loss and the panic message is received by the surviving node.

14. The system of claim 9 , wherein the processor device:
sends the totem token from each one of the plurality of nodes to each other one of the plurality of nodes to indicate that each one of the plurality of nodes sending the totem token is active and not in a panic mode, wherein the totem token is sent after the end of every panic time interval, and
declares the totem token as lost by the surviving node if the totem token is not received from the crashing node upon an expiration of the panic time interval.

15. The system of claim 14 , wherein the processor device determines if the panic time interval has expired by checking if a time stamp of the totem token that was last received is outside of the range of the panic time interval.

16. The system of claim 9 , wherein the processor device performs a reboot operation by the crashing node upon successfully capturing the crash dump files by the capturing node, wherein an end panic mode message is sent from the crashing node to the surviving node upon successfully capturing the crash dump files by the capturing node.

17. A computer program product for securing crash dump files while avoiding power fencing in a cluster of a plurality of nodes connected to a storage system using a processor device, the computer program product comprising a computer-readable storage medium having computer-readable program code portions stored therein, the computer-readable program code portions comprising:
an executable portion that, upon an occurrence of a panic of a crashing node and prior to receiving a panic message of the crashing node by the surviving node, loads in the cluster a capturing node to become active, prior to a totem token being declared lost by a surviving node, for capturing the crash dump files of the crashing node.

18. The computer program product of claim 17 , further including an executable portion that manipulates the surviving node to continue to operate under the assumption the power fencing was performed on the crashing node; and
an executable portion that restricts the capturing node from gaining access to the storage system for preventing unsynchronized access to the storage system in order to prevent data corruption.

19. The computer program product of claim 17 , further including an executable portion that continuously sends the panic message from the crashing node to the surviving node after the end of each of a predetermined time interval, the panic message indicating both the panic occurring in the crashing node and the capturing node capturing the crash dump files.

20. The computer program product of claim 17 , further including an executable portion that issues a successful notification to the surviving node that the power fenci

Assignees

• IBM

Inventors

• Akirav Shay
• Barsky Roman
• Buchbinder Rafael
• Melamed Dan

Classifications

• G06F11/1612

  where the redundant component is persistent storage · CPC title

• G06F11/0778 Primary

  Dumping, i.e. gathering error/state information after a fault for later diagnosis · CPC title

• G06F11/0727

  in a storage system, e.g. in a DASD or network based storage system (drivers for digital recording or reproducing units G06F3/06; circuits for error detection or correction within digital recording or reproducing units G11B20/18; for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS], H04L67/1097) · CPC title

• G06F11/348

  Circuit details, i.e. tracer hardware · CPC title