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: A method includes receiving a change in a primary configuration of a primary storage node while the primary storage node is operational, wherein primary data stored in the primary storage node is to be backed up as backup data in a backup storage node. The method includes locating at least one identifier in the change that identifies the primary storage node. The method includes replacing the at least one identifier in the change that identifies the primary storage node with an identification of the backup storage node to create an updated configuration change. The method includes updating a backup configuration of the backup storage node based on the updated configuration change.

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 systems are provided for migrating a trust relationship. For example, a first storage cluster and a second storage cluster have a disaster recovery relationship where the second storage cluster provides failover client access to replicated data, replicated from the first storage cluster to the second storage cluster, in the event the first storage cluster fails. The first storage cluster may have a trust relationship with a third storage cluster, such that data is mirrored from a volume of the first storage cluster into a mirrored volume of the third storage cluster based upon the trust relationship. In the event the first storage cluster fails over to the second storage cluster due to a disaster at the first storage cluster, the trust relationship is migrated to be between the second storage cluster and the third storage cluster for non-disruptive mirroring of data to the mirrored volume.

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 systems are provided for migrating a trust relationship. For example, a first storage cluster and a second storage cluster have a disaster recovery relationship where the second storage cluster provides failover client access to replicated data, replicated from the first storage cluster to the second storage cluster, in the event the first storage cluster fails. The first storage cluster may have a trust relationship with a third storage cluster, such that data is mirrored from a volume of the first storage cluster into a mirrored volume of the third storage cluster based upon the trust relationship. In the event the first storage cluster fails over to the second storage cluster due to a disaster at the first storage cluster, the trust relationship is migrated to be between the second storage cluster and the third storage cluster for non-disruptive mirroring of data to the mirrored volume.

Abstract: A volume rehost tool migrates a storage volume from a source virtual server within a distributed storage system to a destination storage server within the distributed storage system. The volume rehost tool can prevent client access to data on the volume through the source virtual server until the volume has been migrated to the destination virtual server. The tool identifies a set of storage objects associated with the volume, removes configuration information for the set of storage objects, and removes a volume record associated with the source virtual server for the volume. The tool can then create a new volume record associated with the destination virtual server, apply the configuration information for the set of storage objects to the destination virtual server, and allow client access to the data on the volume through the destination virtual server.

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 systems are provided for migrating a trust relationship. For example, a first storage cluster and a second storage cluster have a disaster recovery relationship where the second storage cluster provides failover client access to replicated data, replicated from the first storage cluster to the second storage cluster, in the event the first storage cluster fails. The first storage cluster may have a trust relationship with a third storage cluster, such that data is mirrored from a volume of the first storage cluster into a mirrored volume of the third storage cluster based upon the trust relationship. In the event the first storage cluster fails over to the second storage cluster due to a disaster at the first storage cluster, the trust relationship is migrated to be between the second storage cluster and the third storage cluster for non-disruptive mirroring of data to the mirrored volume.

Abstract: Methods and systems for managing access to virtual storage systems is provided. A listening socket is configured for an application for detecting communication for a plurality of virtual storage systems presented by a clustered storage system having a plurality of nodes. A packet is received at a node of the clustered storage system from a client system for a virtual storage system from among the plurality of virtual storage systems. An identifier for the virtual storage system for which the packet is destined is determined. A connection socket is cloned for the virtual storage system such that any other packet for a same connection and for the virtual storage system can be forwarded to the virtual storage system. Thereafter, the packet is processed by the application on behalf of the virtual storage system.

Abstract: A method includes receiving a change in a primary configuration of a primary storage node while the primary storage node is operational, wherein primary data stored in the primary storage node is to be backed up as backup data in a backup storage node. The method includes locating at least one identifier in the change that identifies the primary storage node. The method includes replacing the at least one identifier in the change that identifies the primary storage node with an identification of the backup storage node to create an updated configuration change. The method includes updating a backup configuration of the backup storage node based on the updated configuration change.

Abstract: A method, non-transitory computer readable medium and storage controller computing device that receives a configuration change request for a storage virtual machine, the configuration change request including a configuration change operation. A determination is made when configuration settings for the storage virtual machine are locked. The configuration change operation is applied to the configuration settings for the storage virtual machine when the determining indicates the configuration settings for the storage virtual machine are not locked. A failure message is sent in response to the configuration change request when the configuration settings for the storage virtual machine are determined to be locked.

Abstract: Method and system for a non-disruptive migration of a source virtual storage system from a source cluster to a destination cluster is provided. The method includes monitoring a current transfer rate for migrating information from the source cluster to the destination cluster during a migration operation; iteratively reducing a rate at which I/O requests are processed until a transfer rate for transferring the information from the source cluster to the destination cluster within the duration is reached; and entering a cutover phase for the migration operation when the virtual storage system presented by the source cluster is taken offline for the duration and after the information is migrated to the destination cluster, the virtual storage system is presented by the destination cluster.

Abstract: Method and system for a non-disruptive migration of a source virtual storage system from a source cluster to a destination cluster is provided. The method includes monitoring a current transfer rate for migrating information from the source cluster to the destination cluster during a migration operation; iteratively reducing a rate at which I/O requests are processed until a transfer rate for transferring the information from the source cluster to the destination cluster within the duration is reached; and entering a cutover phase for the migration operation when the virtual storage system presented by the source cluster is taken offline for the duration and after the information is migrated to the destination cluster, the virtual storage system is presented by the destination cluster.

Abstract: A context-based file system (CBFS) receives a request to perform an operation in a hierarchy of directories from a virtual host running on a node in a storage server, the hierarchy having a parent-child relationship and a root directory. An identifier is obtained for the virtual host from an operating system. A directory associated with the virtual host is selected from the hierarchy based on a type of the operation and a position of the directory in the hierarchy. A result is received as a result of performing the operation on the selected directory.

Abstract: A system and method addresses data containers in a clustered storage system. Each instantiation of a volume, or other container set, is associated with a data set identifier (DSID). All instantiations of data that represent a single point in time are associated with a master data set identifier (MSID). A volume location database (VLDB), utilizing a replicated database among the nodes of the cluster, stores a data set data structure containing appropriate mapping information between the MSIDs and DSIDs. Clients of the clustered storage system utilize MSIDs to reference data that is desired to be accessed. When a storage system receives a data access request containing a MSID, the storage system accesses the VLDB to identify an appropriate DSID to which to forward the request. The data access request is then forwarded to the appropriate storage system for processing.

Abstract: A technique provides a dedicated software thread for communicating backup history to clients of a storage system during backup operations. Illustratively, an operating system of the storage system may execute one or more “session” (e.g., backup) threads and a “worker” (e.g., backup history) thread. In particular, the one or more session threads are each configured to backup stored data for a corresponding client to a backup storage device and to generate backup history of data backed up to the backup storage device. Also, the worker thread is configured to obtain the backup history from the one or more session threads, and transmit the backup history to the corresponding client of each of the one or more session threads. In this manner, the worker thread may wait for a response from the corresponding clients, while the one or more corresponding session threads continue to backup the stored data and generate backup history.