Abstract: Techniques for providing a fencing scheme for cluster systems without inherent hardware fencing. Storage nodes in an HA cluster communicate with one another over communication paths implemented through a variety of mechanisms, including drives and network connections. Each storage node in the HA cluster executes a fencing enforcer component operable to enforce actions or processes for initiating fencing of itself and/or initiating self-fencing of another storage node in the HA cluster determined to be malfunctioning. By providing for richer communications between storage nodes in an HA cluster and a richer set of actions or processes for fencing a malfunctioning storage node including self-fencing, the malfunctioning storage node can be made to exit the HA cluster in a more controlled fashion. In addition, a remaining storage node in the HA cluster can more safely take on the role of primary storage node with reduced risk of data corruption on shared resources.

Abstract: Techniques for providing a framework for handling execution of HA flows in an active-active storage node configuration. The techniques include receiving notifications of functional statuses of processes and/or equipment associated with storage nodes in the active-active configuration, making determinations regarding how to address HA events occurring on the processes and/or equipment associated with the storage nodes based on the received notifications, and, in response to a request to execute an HA flow for a respective HA event, determining whether to refuse the request to execute the HA flow, service the request to execute the HA flow, abort one or more HA flows in execution, and/or postpone execution of the HA flow to a later time based on one or more dependencies defining conditions for the HA flow. In this way, mutual interference of HA flows or other process threads in the active-active configuration can be reduced or eliminated.

Abstract: Techniques for providing a fencing scheme for cluster systems without inherent hardware fencing. Storage nodes in an HA cluster communicate with one another over communication paths implemented through a variety of mechanisms, including drives and network connections. Each storage node in the HA cluster executes a fencing enforcer component operable to enforce actions or processes for initiating fencing of itself and/or initiating self-fencing of another storage node in the HA cluster determined to be malfunctioning. By providing for richer communications between storage nodes in an HA cluster and a richer set of actions or processes for fencing a malfunctioning storage node including self-fencing, the malfunctioning storage node can be made to exit the HA cluster in a more controlled fashion. In addition, a remaining storage node in the HA cluster can more safely take on the role of primary storage node with reduced risk of data corruption on shared resources.

Abstract: Techniques for providing a framework for handling execution of HA flows in an active-active storage node configuration. The techniques include receiving notifications of functional statuses of processes and/or equipment associated with storage nodes in the active-active configuration, making determinations regarding how to address HA events occurring on the processes and/or equipment associated with the storage nodes based on the received notifications, and, in response to a request to execute an HA flow for a respective HA event, determining whether to refuse the request to execute the HA flow, service the request to execute the HA flow, abort one or more HA flows in execution, and/or postpone execution of the HA flow to a later time based on one or more dependencies defining conditions for the HA flow. In this way, mutual interference of HA flows or other process threads in the active-active configuration can be reduced or eliminated.

Abstract: An aspect of module mirroring during an non-disruptive upgrade includes creating a mirrored set of management processes for a storage cluster that is subject to an upgrade a new software version, interconnecting components of the mirrored set and an original set of the management processes while the storage cluster is actively managed by an original set of management processes, and performing a handover between the management processes of the storage cluster.

Abstract: Moving from a back-to-back topology to a switched topology in an InfiniBand network includes, prior to connecting a switch for a first storage controller in the network and during reboot of the first storage controller, waiting for a second storage controller in the network to become master, and upon the second storage controller becoming master, changing cache files for local ports on the first storage controller regarding adjacent ports' LID assignments. An aspect further includes restarting a system manager for the first storage controller, connecting the first storage controller to the system with new LID assignments provided by changed files on first storage controller, and upon the first storage controller becoming active, rebooting the second storage controller, changing the LID assignments in the active storage controller, and adding new switches to the system.

Abstract: Moving from a back-to-back topology to a switched topology in an InfiniBand network includes, prior to connecting a switch for a first storage controller in the network and during reboot of the first storage controller, waiting for a second storage controller in the network to become master, and upon the second storage controller becoming master, changing cache files for local ports on the first storage controller regarding adjacent ports' LID assignments. An aspect further includes restarting a system manager for the first storage controller, connecting the first storage controller to the system with new LID assignments provided by changed files on first storage controller, and upon the first storage controller becoming active, rebooting the second storage controller, changing the LID assignments in the active storage controller, and adding new switches to the system.

Abstract: An aspect of module mirroring during an non-disruptive upgrade includes creating a mirrored set of management processes for a storage cluster that is subject to an upgrade a new software version, interconnecting components of the mirrored set and an original set of the management processes while the storage cluster is actively managed by an original set of management processes, and performing a handover between the management processes of the storage cluster.