A storage network environment may comprise one or more storage clusters of storage controllers (e.g., nodes) configured to provide clients with access to user data stored within storage devices. For example, a first storage cluster may comprise a first storage controller configured to provide clients with access to user data stored within a first storage device. A second storage cluster may be configured according to a disaster recovery configuration with respect to the first storage cluster, such that user data (e.g., user files, applications, etc.) and configuration data (e.g., a name and size of a volume, a replication policy, a user access policy, a network interface configuration, an IP address, and/or other back-end configuration data of the storage network environment) are replicated from the first storage cluster to the second storage cluster. In this way, when a disaster occurs at the first storage cluster and clients are unable to access user data within the first storage device because the first storage controller may be unavailable or may have failed from the disaster, a second storage controller of the second storage cluster may provide clients with failover access to replicated user data that was replicated from the first storage device to a second storage device accessible to the second storage controller. When the first storage cluster recovers from the disaster, the second storage cluster may switch back to the first storage cluster such that the first storage controller provides clients with access to user data from the first storage device. In this way, user data and configuration data may be backed up between storage clusters for disaster recovery.
Synchronization of configuration data from the first storage cluster to the second storage cluster may fail for various reasons. In an example, configuration mirroring data (e.g., a volume rename operation for a volume at the first storage cluster may be mirrored as the configuration mirroring data to the second storage cluster to rename a corresponding replicated volume to match a new name of the volume) that is to be sent from the first storage cluster to the second storage cluster may fail to be transmitted. In another example, the configuration mirroring data may fail to be applied at the second storage cluster (e.g., configuration data of a first storage virtual machine of the first storage cluster may fail to be applied to a second storage virtual machine, of the second storage cluster, that is configured as a backup storage virtual machine for the first storage virtual machine). In another example, the configuration mirroring data may fail to be recorded at the second storage cluster. Thus, a client may be unaware of the inconsistency in configuration data between the storage clusters (e.g., a volume name change or resize operation may modify volume name configuration data or volume size configuration data at the first storage cluster, but a failure to propagate such configuration data to the second storage cluster may result in the second storage cluster comprising a mirrored volume with a stale/incorrect name or size), which may result in errors (e.g., an error when attempting to access a replicated storage object having a stale out-of-date internet protocol (IP) address), security issues such as unauthorized access (e.g., a stale out-of-date user access policy may still grant a user with access to replicated user data that the user is now not supposed to access), an inability for clients to access to client data (e.g., a user may be unable to access a replicated volume having a stale out-of-date volume name), and/or other failures.
USPTO Backgrounds
USPTO Backgrounds