Abstract: Methods and systems for Vserver migration are provided. Update after claims are finalized. One method includes generating a consistency group (CG) having a plurality of source storage volumes of a source storage virtual machine (Vserver) of a source cluster for a migrate operation to migrate the source storage volumes as a group to a plurality of destination storage volumes of a destination cluster; establishing a mirroring relationship between the source and destination cluster for managing asynchronous transfer of the source storage volumes in the CG to the destination storage volumes during a transfer phase of the migrate operation; replicating a logical interface of the source cluster to the destination cluster, the logical interface providing a network address to access the source cluster; and automatically selecting a destination port at the destination cluster, associated with the replicated logical interface.

Abstract: Methods and systems for Vserver migration are provided. One method includes maintaining a state of a migrate operation for migrating a plurality of source storage volumes managed by a source storage virtual machine (Vserver) of a source cluster to a plurality of destination storage volumes of a destination cluster of a networked storage environment; restarting a process at a healthy node of the source cluster or the destination cluster to continue the migrate operation, in response to detecting an unhealthy node at the source cluster or the destination cluster executing the process; retrying a task associated with the migrate operation experiencing intermittent failure for a certain number of times, and upon successful execution, continuing the migration operation; and checking the state of the migrate operation and in response to the state of the migrate operation, continuing the migrate operation or restarting the migration operation.

Abstract: Methods and systems for Vserver migration are provided. One method includes executing a transfer phase of a migrate operation for migrating a Vserver of a source cluster to a destination cluster, using asynchronous baseline transfer to transfer a plurality of source storage volumes configured in a consistency group (CG) for the migrate operation to a plurality of destination storage volumes of a destination cluster; updating a state of each of the plurality of source storage volumes to a sync state indicating completion of a pre-commit phase of the migrate operation to initiate a commit phase of the migrate operation; and generating a snapshot of the plurality of destination storage volumes for performing data integrity checks between data stored at the source cluster and migrated data at destination cluster, after completing a commit phase of the migrate operation.

Abstract: Direct monitoring of a plurality of storage nodes in a primary cluster is performed based on connectivity with the storage nodes. Indirect monitoring of a first storage node is performed, in response to direct monitoring of the first storage node indicating failure of the connectivity with the first storage node, wherein a second storage node of the plurality of nodes is a backup node for the first storage node. The indirect monitor of the first storage node indicates failure of the first storage node in response to performance of storage access operations by the second storage node that were previously performed by the first storage node. A cluster-switch operation is initiated to switch to from the primary cluster to a backup cluster based on an occurrence of at least one cluster-failure condition that comprises the indirect monitor of the first storage node indicating failure of the first storage node.

Abstract: Monitoring health of associated, but separated storage clusters can be done at both a node scope and a cluster scope. Monitoring the storage clusters at the cluster scope includes monitoring the network elements that support the storage clusters and connect the storage clusters. Initially, a fabric monitor in each cluster discovers cluster topology. This cluster topology is communicated and maintained throughout the managing storage elements of the storage clusters. After the storage cluster topologies have been discovered, the fabric monitors of each cluster can periodically determine status of network elements of the storage clusters. This allows the storage clusters to maintain awareness of interconnect status, and react to changes in status. In addition, each managing storage element monitors its own health. This information is aggregated to determine when to trigger corrective actions, alerts, and/or storage features in accordance with rules defined at the managing storage elements.

Abstract: One or more techniques and/or devices are provided for storage virtual machine relocation (e.g., ownership change) between storage clusters. For example, operational statistics of a first storage cluster and a second storage cluster may be evaluated to identify a set of load balancing metrics. Ownership of one or more storage aggregates and/or one or more storage virtual machines may be changed (e.g., permanently changed for load balancing purposes or temporarily changed for disaster recovery purposes) between the first storage cluster and the second storage cluster utilizing zero-copy ownership change operations based upon the set of load balancing metrics. For example, if the first storage cluster is experiencing a relatively heavier load of client I/O operations and the second storage cluster has available resources, ownership of a storage aggregate and a storage virtual machine may be switched from the first storage cluster to the second storage cluster for load balancing.

Abstract: One or more techniques and/or devices are provided for storage virtual machine relocation (e.g., ownership change) between storage clusters. For example, operational statistics of a first storage cluster and a second storage cluster may be evaluated to identify a set of load balancing metrics. Ownership of one or more storage aggregates and/or one or more storage virtual machines may be changed (e.g., permanently changed for load balancing purposes or temporarily changed for disaster recovery purposes) between the first storage cluster and the second storage cluster utilizing zero-copy ownership change operations based upon the set of load balancing metrics. For example, if the first storage cluster is experiencing a relatively heavier load of client I/O operations and the second storage cluster has available resources, ownership of a storage aggregate and a storage virtual machine may be switched from the first storage cluster to the second storage cluster for load balancing.

Abstract: Direct monitoring of a plurality of storage nodes in a primary cluster is performed based on connectivity with the storage nodes. Indirect monitoring of a first storage node is performed, in response to direct monitoring of the first storage node indicating failure of the connectivity with the first storage node, wherein a second storage node of the plurality of nodes is a backup node for the first storage node. The indirect monitor of the first storage node indicates failure of the first storage node in response to performance of storage access operations by the second storage node that were previously performed by the first storage node. A cluster-switch operation is initiated to switch to from the primary cluster to a backup cluster based on an occurrence of at least one cluster-failure condition that comprises the indirect monitor of the first storage node indicating failure of the first storage node.

Abstract: Monitoring health of associated, but separated storage clusters can be done at both a node scope and a cluster scope. Monitoring the storage clusters at the cluster scope includes monitoring the network elements that support the storage clusters and connect the storage clusters. Initially, a fabric monitor in each cluster discovers cluster topology. This cluster topology is communicated and maintained throughout the managing storage elements of the storage clusters. After the storage cluster topologies have been discovered, the fabric monitors of each cluster can periodically determine status of network elements of the storage clusters. This allows the storage clusters to maintain awareness of interconnect status, and react to changes in status. In addition, each managing storage element monitors its own health. This information is aggregated to determine when to trigger corrective actions, alerts, and/or storage features in accordance with rules defined at the managing storage elements.

Abstract: Direct monitoring of a plurality of storage nodes in a primary cluster is performed based on connectivity with the storage nodes. Indirect monitoring of a first storage node is performed, in response to direct monitoring of the first storage node indicating failure of the connectivity with the first storage node, wherein a second storage node of the plurality of nodes is a backup node for the first storage node. The indirect monitor of the first storage node indicates failure of the first storage node in response to performance of storage access operations by the second storage node that were previously performed by the first storage node. A cluster-switch operation is initiated to switch to from the primary cluster to a backup cluster based on an occurrence of at least one cluster-failure condition that comprises the indirect monitor of the first storage node indicating failure of the first storage node.

Abstract: One or more techniques and/or devices are provided for storage virtual machine relocation (e.g., ownership change) between storage clusters. For example, operational statistics of a first storage cluster and a second storage cluster may be evaluated to identify a set of load balancing metrics. Ownership of one or more storage aggregates and/or one or more storage virtual machines may be changed (e.g., permanently changed for load balancing purposes or temporarily changed for disaster recovery purposes) between the first storage cluster and the second storage cluster utilizing zero-copy ownership change operations based upon the set of load balancing metrics. For example, if the first storage cluster is experiencing a relatively heavier load of client I/O operations and the second storage cluster has available resources, ownership of a storage aggregate and a storage virtual machine may be switched from the first storage cluster to the second storage cluster for load balancing.

Abstract: Monitoring health of associated, but separated storage clusters can be done at both a node scope and a cluster scope. Monitoring the storage clusters at the cluster scope includes monitoring the network elements that support the storage clusters and connect the storage clusters. Initially, a fabric monitor in each cluster discovers cluster topology. This cluster topology is communicated and maintained throughout the managing storage elements of the storage clusters. After the storage cluster topologies have been discovered, the fabric monitors of each cluster can periodically determine status of network elements of the storage clusters. This allows the storage clusters to maintain awareness of interconnect status, and react to changes in status. In addition, each managing storage element monitors its own health. This information is aggregated to determine when to trigger corrective actions, alerts, and/or storage features in accordance with rules defined at the managing storage elements.

Abstract: One or more techniques and/or devices are provided for storage virtual machine relocation (e.g., ownership change) between storage clusters. For example, operational statistics of a first storage cluster and a second storage cluster may be evaluated to identify a set of load balancing metrics. Ownership of one or more storage aggregates and/or one or more storage virtual machines may be changed (e.g., permanently changed for load balancing purposes or temporarily changed for disaster recovery purposes) between the first storage cluster and the second storage cluster utilizing zero-copy ownership change operations based upon the set of load balancing metrics. For example, if the first storage cluster is experiencing a relatively heavier load of client I/O operations and the second storage cluster has available resources, ownership of a storage aggregate and a storage virtual machine may be switched from the first storage cluster to the second storage cluster for load balancing.

Abstract: One or more techniques and/or devices are provided for storage virtual machine relocation (e.g., ownership change) between storage clusters. For example, operational statistics of a first storage cluster and a second storage cluster may be evaluated to identify a set of load balancing metrics. Ownership of one or more storage aggregates and/or one or more storage virtual machines may be changed (e.g., permanently changed for load balancing purposes or temporarily changed for disaster recovery purposes) between the first storage cluster and the second storage cluster utilizing zero-copy ownership change operations based upon the set of load balancing metrics. For example, if the first storage cluster is experiencing a relatively heavier load of client I/O operations and the second storage cluster has available resources, ownership of a storage aggregate and a storage virtual machine may be switched from the first storage cluster to the second storage cluster for load balancing.

Abstract: One or more techniques and/or devices are provided for storage virtual machine relocation (e.g., ownership change) between storage clusters. For example, operational statistics of a first storage cluster and a second storage cluster may be evaluated to identify a set of load balancing metrics. Ownership of one or more storage aggregates and/or one or more storage virtual machines may be changed (e.g., permanently changed for load balancing purposes or temporarily changed for disaster recovery purposes) between the first storage cluster and the second storage cluster utilizing zero-copy ownership change operations based upon the set of load balancing metrics. For example, if the first storage cluster is experiencing a relatively heavier load of client I/O operations and the second storage cluster has available resources, ownership of a storage aggregate and a storage virtual machine may be switched from the first storage cluster to the second storage cluster for load balancing.

Abstract: Direct monitoring of a plurality of storage nodes in a primary cluster is performed based on connectivity with the storage nodes. Indirect monitoring of a first storage node is performed, in response to direct monitoring of the first storage node indicating failure of the connectivity with the first storage node, wherein a second storage node of the plurality of nodes is a backup node for the first storage node. The indirect monitor of the first storage node indicates failure of the first storage node in response to performance of storage access operations by the second storage node that were previously performed by the first storage node. A cluster-switch operation is initiated to switch to from the primary cluster to a backup cluster based on an occurrence of at least one cluster-failure condition that comprises the indirect monitor of the first storage node indicating failure of the first storage node.

Abstract: Direct monitoring of a plurality of storage nodes in a primary cluster is performed based on connectivity with the storage nodes. Indirect monitoring of a first storage node is performed, in response to direct monitoring of the first storage node indicating failure of the connectivity with the first storage node, wherein a second storage node of the plurality of nodes is a backup node for the first storage node. The indirect monitor of the first storage node indicates failure of the first storage node in response to performance of storage access operations by the second storage node that were previously performed by the first storage node. A cluster-switch operation is initiated to switch to from the primary cluster to a backup cluster based on an occurrence of at least one cluster-failure condition that comprises the indirect monitor of the first storage node indicating failure of the first storage node.

Abstract: One or more techniques and/or devices are provided for storage virtual machine relocation (e.g., ownership change) between storage clusters. For example, operational statistics of a first storage cluster and a second storage cluster may be evaluated to identify a set of load balancing metrics. Ownership of one or more storage aggregates and/or one or more storage virtual machines may be changed (e.g., permanently changed for load balancing purposes or temporarily changed for disaster recovery purposes) between the first storage cluster and the second storage cluster utilizing zero-copy ownership change operations based upon the set of load balancing metrics. For example, if the first storage cluster is experiencing a relatively heavier load of client I/O operations and the second storage cluster has available resources, ownership of a storage aggregate and a storage virtual machine may be switched from the first storage cluster to the second storage cluster for load balancing.

Abstract: Monitoring health of associated, but separated storage clusters can be done at both a node scope and a cluster scope. Monitoring the storage clusters at the cluster scope includes monitoring the network elements that support the storage clusters and connect the storage clusters. Initially, a fabric monitor in each cluster discovers cluster topology. This cluster topology is communicated and maintained throughout the managing storage elements of the storage clusters. After the storage cluster topologies have been discovered, the fabric monitors of each cluster can periodically determine status of network elements of the storage clusters. This allows the storage clusters to maintain awareness of interconnect status, and react to changes in status. In addition, each managing storage element monitors its own health. This information is aggregated to determine when to trigger corrective actions, alerts, and/or storage features in accordance with rules defined at the managing storage elements.

Abstract: Direct monitoring of a plurality of storage nodes in a primary cluster is performed based on connectivity with the storage nodes. Indirect monitoring of a first storage node is performed, in response to direct monitoring of the first storage node indicating failure of the connectivity with the first storage node, wherein a second storage node of the plurality of nodes is a backup node for the first storage node. The indirect monitor of the first storage node indicates failure of the first storage node in response to performance of storage access operations by the second storage node that were previously performed by the first storage node. A cluster-switch operation is initiated to switch to from the primary cluster to a backup cluster based on an occurrence of at least one cluster-failure condition that comprises the indirect monitor of the first storage node indicating failure of the first storage node.