Abstract: A high availability (HA) failover manager maintains data availability of one or more input/output (I/O) resources in a cluster by ensuring that each I/O resource is available (e.g., mounted) on a hosting node of the cluster and that each I/O resource may be available on one or more partner nodes of the cluster if a node (i.e., a local node) were to fail. The HA failover manager (HA manager) processes inputs from various sources of the cluster to determine whether failover is enabled for a local node and each partner node in an HA group, and for triggering failover of the I/O resources to the partner node as necessary. For each I/O resource, the HA manager may track state information including (i) a state of the I/O resource (e.g., mounted or un-mounted); (ii) the partner node(s) ability to service the I/O resource; and (iii) whether a non-volatile log recording I/O requests is synchronized to the partner node(s).

Abstract: A storage object is migrated between nodes by a source node automatically verifying that another node is configured to service the storage object and changing ownership of the storage object based on the verifying. A cluster manager for the clustered storage system receives a request and provides the request to the source which owns the storage object. The source verifies that the destination is configured according to a predetermined configuration for servicing the storage object. Based on the verifying, the source offlines the storage object and updates ownership information of the storage object, thereafter allowing the destination to online the storage object. The cluster manager further provides the updated ownership information to all the nodes in the cluster, so an access request intended for the storage object may be received by any node and forwarded to the destination using the updated ownership information to effect a transparent migration.

Abstract: A high availability (HA) failover manager maintains data availability of one or more input/output (I/O) resources in a cluster by ensuring that each I/O resource is available (e.g., mounted) on a hosting node of the cluster and that each I/O resource may be available on one or more partner nodes of the cluster if a node (i.e., a local node) were to fail. The HA failover manager (HA manager) processes inputs from various sources of the cluster to determine whether failover is enabled for a local node and each partner node in an HA group, and for triggering failover of the I/O resources to the partner node as necessary. For each I/O resource, the HA manager may track state information including (i) a state of the I/O resource (e.g., mounted or un-mounted); (ii) the partner node(s) ability to service the I/O resource; and (iii) whether a non-volatile log recording I/O requests is synchronized to the partner node(s).

Abstract: A high availability (HA) failover manager maintains data availability of one or more input/output (I/O) resources in a cluster by ensuring that each I/O resource is available (e.g., mounted) on a hosting node of the cluster and that each I/O resource may be available on one or more partner nodes of the cluster if a node (i.e., a local node) were to fail. The HA failover manager (HA manager) processes inputs from various sources of the cluster to determine whether failover is enabled for a local node and each partner node in an HA group, and for triggering failover of the I/O resources to the partner node as necessary. For each I/O resource, the HA manager may track state information including (i) a state of the I/O resource (e.g., mounted or un-mounted); (ii) the partner node(s) ability to service the I/O resource; and (iii) whether a non-volatile log recording I/O requests is synchronized to the partner node(s).

Abstract: A high availability (HA) failover manager maintains data availability of one or more input/output (I/O) resources in a cluster by ensuring that each I/O resource is available (e.g., mounted) on a hosting node of the cluster and that each I/O resource may be available on one or more partner nodes of the cluster if a node (i.e., a local node) were to fail. The HA failover manager (HA manager) processes inputs from various sources of the cluster to determine whether failover is enabled for a local node and each partner node in an HA group, and for triggering failover of the I/O resources to the partner node as necessary. For each I/O resource, the HA manager may track state information including (i) a state of the I/O resource (e.g., mounted or un-mounted); (ii) the partner node(s) ability to service the I/O resource; and (iii) whether a non-volatile log recording I/O requests is synchronized to the partner node(s).

Abstract: A storage object is migrated between nodes by a source node automatically verifying that another node is configured to service the storage object and changing ownership of the storage object based on the verifying. A cluster manager for the clustered storage system receives a request and provides the request to the source which owns the storage object. The source verifies that the destination is configured according to a predetermined configuration for servicing the storage object. Based on the verifying, the source offlines the storage object and updates ownership information of the storage object, thereafter allowing the destination to online the storage object. The cluster manager further provides the updated ownership information to all the nodes in the cluster, so an access request intended for the storage object may be received by any node and forwarded to the destination using the updated ownership information to effect a transparent migration.

Abstract: A storage object is migrated between nodes by a source node automatically verifying that another node is configured to service the storage object and changing ownership of the storage object based on the verifying. A cluster manager for the clustered storage system receives a request and provides the request to the source which owns the storage object. The source verifies that the destination is configured according to a predetermined configuration for servicing the storage object. Based on the verifying, the source offlines the storage object and updates ownership information of the storage object, thereafter allowing the destination to online the storage object. The cluster manager further provides the updated ownership information to all the nodes in the cluster, so an access request intended for the storage object may be received by any node and forwarded to the destination using the updated ownership information to effect a transparent migration.

Abstract: A method and system are provided for transparently migrating a storage object (aggregate) between nodes by one of the nodes (source), automatically verifying another node (destination) is configured to service the aggregate, and changing ownership of the aggregate based on the verifying to enable servicing of the aggregate at the destination. A cluster manager receives an aggregate migration request and provides the request to the source owning the aggregate. The source verifies the destination is configured according to a predetermined configuration for servicing the aggregate. Based on the verifying, the source offlines the aggregate and updates ownership information of the aggregate, thereafter allowing the destination to online the aggregate. The cluster manager provides the updated ownership information to all nodes in the cluster, so an access request intended for the aggregate may be received by any node and forwarded to the destination using the updated ownership information.

Abstract: A cluster comprises a plurality of nodes that access a shared storage, each node having two or more partner nodes. A primary node may own a plurality of aggregate sub-sets in the shared storage. Upon failure of the primary node, each partner node may take over ownership of an aggregate sub-set according to an aggregate failover data structure (AFDS). The AFDS may specify, an ordered data structure of two or more partner nodes to take over each aggregate sub-set, the ordered data structure comprising at least a first-ordered partner node assigned to take over the aggregate sub-set upon failure of the primary node and a second-ordered partner node assigned to take over the aggregate sub-set upon failure of the primary node and the first-ordered partner node. The additional workload of the failed primary node is distributed among two or more partner nodes and protection for multiple node failures is provided.

Abstract: A method and system manages ownership information about disks in a storage network without the need for an emulated, partner mode system. The method and system provides for ownership information, including a current owner and a home owner for resources, such as disks, to be stored on each disk in a storage system, as well as to be stored in memory on each storage system node in the network. A further aspect of the invention is a disk homeness application program interface (API), which provides commands that can be utilized by an administrator at a host computer to set, modify and disco play ownership information about each disk in the cluster. Upon a takeover, any node in the network can takeover one or more disks by reading the ownership information stored on the disks or in the tables.

Abstract: A system and method for coordinated bringup of a storage appliance in a storage appliance cluster. The repaired storage appliance, during its initialization, sets a variety of state values in a predetermined memory location comprising a state data structure, which is detected by a remote direct memory access read operation by the surviving storage appliance. By the use of the RDMA operations, the repaired storage appliance and surviving storage appliance coordinate the bringup and giveback of data servicing functionality.

Abstract: A system and method for operating a storage system is provided. A plurality of operating system transaction entries are stored in a log, and a swarm of messages with respect to the plurality of operating system transaction entries is established. The swarm of messages is delivered to an operating system of the storage system. A processor performs a parallel retrieval process for a plurality of messages in the swarm of messages by processing the plurality of messages in an arbitrary order without regard to an underlying order of the messages.

Abstract: A system and method for performing a takeover procedure is disclosed. A plurality of storage system nodes is coupled in a cluster. One or more of the plurality of storage system nodes in the cluster is notified to takeover at least a portion of a writable storage device serviced by another storage system node in the cluster. In response to the notification, the portion of the writable storage device is assimilated into at least one of the notified storage system nodes.

Abstract: A cluster comprises a plurality of nodes that access a shared storage, each node having two or more partner nodes. A primary node may own a plurality of aggregate sub-sets in the shared storage. Upon failure of the primary node, each partner node may take over ownership of an aggregate sub-set according to an aggregate failover data structure (AFDS). The AFDS may specify, an ordered data structure of two or more partner nodes to take over each aggregate sub-set, the ordered data structure comprising at least a first-ordered partner node assigned to take over the aggregate sub-set upon failure of the primary node and a second-ordered partner node assigned to take over the aggregate sub-set upon failure of the primary node and the first-ordered partner node. The additional workload of the failed primary node is distributed among two or more partner nodes and protection for multiple node failures is provided.

Abstract: A system and method for determining a disk ownership model to be utilized by a storage system is disclosed. The storage system and method determines the individual disk ownership of each accessible disk to the storage system. If the number of disks utilizing a first ownership model is exceeded, the storage system utilizes the first ownership model. Otherwise, the storage system utilizes a second ownership model.

Abstract: A method and system manages ownership information about disks in a storage network without the need for an emulated, partner mode system. The method and system provides for ownership information, including a current owner and a home owner for resources, such as disks, to be stored on each disk in a storage system, as well as to be stored in memory on each storage system node in the network. A further aspect of the invention is a disk homeness application program interface (API), which provides commands that can be utilized by an administrator at a host computer to set, modify and display ownership information about each disk in the cluster. Upon a takeover, any node in the network can takeover one or more disks by reading the ownership information stored on the disks or in the tables.

Abstract: A system and method for enabling parallel replay of a backup memory log of client transaction request entries to a network storage appliance file system is provided. The backup memory is typically implemented as a non-volatile random access memory (NVRAM). An initiator establishes a swarm of messages with a plurality of transaction blocks pointing to logged request entries and related states associated therewith. The states represent the various phases of file system recovery and disk storage including a retrieval of disk information (data and meta-data), typically in the form of a LOAD, and a subsequent modify phase. The swarm is transferred to the file system for parallel disk information-retrieval in an interleaved process. Any transactions that cannot be performed due to a required prerequisite action (e.g. a prior file-create) are returned to the initiator for reloading once the prerequisite action has occurred.

Abstract: A system and method for operating a storage system is provided. A plurality of operating system transaction entries are stored in a log, and a swarm of messages with respect to the plurality of operating system transaction entries is established. The swarm of messages is delivered to an operating system of the storage system. A processor performs a parallel retrieval process for a plurality of messages in the swarm of messages by processing the plurality of messages in an arbitrary order without regard to an underlying order of the messages.

Abstract: A takeover system and method for high availability in the face of component failures for a multiple-node storage system cluster is provided. When a takeover is triggered either through a loss of cluster heartbeat, or through a user-initiated command, the system of the present invention is configured such that one or more surviving nodes asserts ownership on one or more of the failed node's disks such that all of the disks become locally owned by one of the surviving nodes. An assimilation of the disks into one or more aggregates is performed, and any duplicated file system identification numbers are corrected to avoid errors. As the disks thus appear to be locally owned by the surviving nodes, one or more newly assimilated aggregates are thus exposed to any N-module that interfaces with the surviving nodes.

Abstract: A method and system performs a sendhome procedure for giving back resources to a node that had been restored after a takeover of that node's resources is provided. Critical operations that may be running are completed prior to the sendhome process. An ownership module consults information in an ownership table about each resource, e.g. a data container. A data container, such as a root aggregate of the waiting node is identified and sent back first, after which the node is booted. When the node has been successfully booted, the remaining aggregates are sent back one at a time until the full compliment of aggregates has been returned. A veto of the sendhome procedure can be invoked by a subsystem that is performing a critical operation prior to the sendhome of the root aggregate and each individual other aggregate.