LIF Placement in SAN Storage Cluster Disaster Recovery

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing storage area network (SAN) systems face challenges in providing fast and efficient disaster recovery operations, particularly in maintaining data availability and minimizing disruption to host devices during cluster failures.

Innovation Solution

The implementation of techniques for LIF (Logical Interface) placement in SAN storage cluster synchronous disaster recovery, which involves configuring a secondary Vserver as a backup to a primary Vserver, allowing for seamless switchover during failures, and maintaining consistent LIF identities across clusters to ensure uninterrupted data access.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional disaster recovery methods are used in SAN storage clusters, then data can be recovered after failure, but the recovery time is long and host devices experience significant disruption

Engineering Contradiction:
Improvedata availabilityVSAvoidrecovery time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent applies preliminary action by pre-configuring LIF identities and network paths in the secondary cluster before failure occurs. The secondary Vserver is pre-populated with LIF configurations that match the primary Vserver, so that upon failure, the secondary can immediately assume the primary's identity and continue serving hosts without requiring time-consuming reconfiguration or identity resolution.

Inventive Principle:
Principle #10Preliminary action

2Adaptability or versatility

If LIF identities are changed during disaster recovery, then the secondary cluster can operate independently, but host devices must update their connections causing disruption

Engineering Contradiction:
Improvecluster independenceVSAvoidhost connection stability
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent applies copying by replicating the LIF identity configuration from the primary Vserver to the secondary Vserver. The secondary cluster receives and stores a copy of the LIF identity information, allowing it to present identical network interfaces to hosts. This enables the secondary to operate independently while maintaining the same LIF identities, so hosts experience no connection changes.

Inventive Principle:
Principle #26Copying

3Speed

If fast switchover is implemented, then host disruption is minimized, but complex LIF placement and identity management is required

Engineering Contradiction:
Improveswitchover speedVSAvoidLIF configuration complexity
Core Design Contradiction:
SpeedVSDevice complexity

Solution Approach 1:

The patent introduces an intermediary mechanism in the form of a LIF placement module that automatically manages LIF identity mapping between primary and secondary clusters. This intermediary handles the complex task of matching and transferring LIF configurations, shielding operators from the complexity while enabling fast switchover. The intermediary module coordinates the identity transfer and ensures proper routing without requiring manual configuration.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS12339752B2Techniques for LIF placement in san storage cluster synchronous disaster recovery
Publication Date: 2025.06.24 NETAPP INC
  • US12339752B2 patent drawing
  • US12339752B2 patent drawing
  • US12339752B2 patent drawing

AI summary

Improved techniques for disaster recover within storage area networks are disclosed. Embodiments include replicating a LIF of a primary cluster on a secondary cluster. LIF configuration information is extracted from the primary cluster. A peer node from a secondary cluster is located. One or more ports are located on the located peer node that match a connectivity of the LIF from the primary cluster. One or more ports are identified based upon one or more filtering criteria to generate a candidate port list. A port from the candidate port list is selected based at least upon a load of the port. Other embodiments are described and claimed.