Skip to main content

What happens during takeover

When a node takes over its partner, it continues to serve and update data in the partner's aggregates and volumes. To do this, the node takes ownership of the partner's aggregates, and the partner's LIFs migrate according to network interface failover rules. Except for specific SMB 3.0 connections, existing SMB (CIFS) sessions are disconnected when the takeover occurs.

The following steps occur when a node takes over its partner:

  1. If the negotiated takeover is user-initiated, aggregate relocation is performed to move data aggregates one at a time from the partner node to the node that is performing the takeover.

    The current owner of each aggregate (except for the root aggregate) is changed from the target node to the node that is performing the takeover. There is a brief outage for each aggregate as ownership changes. This outage is briefer than an outage that occurs during a takeover without aggregate relocation.

    • You can monitor the progress using the storage failover show‑takeover command.

    • The aggregate relocation can be avoided during this takeover instance by using the ‑bypass‑optimization parameter with the storage failover takeover command. To bypass aggregate relocation during all future planned takeovers, set the ‑bypass‑takeover‑optimization parameter of the storage failover modify command to true.

    Note
    Aggregates are relocated serially during planned takeover operations to reduce client outage. If aggregate relocation is bypassed, longer client outage occurs during planned takeover events. Setting the ‑bypass‑takeover‑optimization parameter of the storage failover modify command to true is not recommended in environments that have stringent outage requirements.

  2. If the user-initiated takeover is a negotiated takeover, the target node gracefully shuts down, followed by takeover of the target node's root aggregate and any aggregates that were not relocated in Step 1.

  3. Before the storage takeover begins, data LIFs migrate from the target node to the node performing the takeover or to any other node in the cluster based on LIF failover rules.

    The LIF migration can be avoided by using the ‑skip‑lif-migration parameter with the storage failover takeover command. Refer to the following guides for more information:

    SMB/CIFS File Access Reference Guide

    NFS File Access Reference Guide

    Network Management Guide

  4. Existing SMB (CIFS) sessions are disconnected when takeover occurs.

    Attention
    Due to the nature of the SMB protocol, all SMB sessions except for SMB 3.0 sessions connected to shares with the Continuous Availability property set, will be disruptive. SMB 1.0 and SMB 2.x sessions cannot reconnect after a takeover event. Therefore, takeover is disruptive and some data loss could occur.

  5. SMB 3.0 sessions established to shares with the

    Continuous Availability property set can reconnect to the disconnected shares after a takeover event.

    If your site uses SMB 3.0 connections to Microsoft Hyper-V and the Continuous Availability property is set on the associated shares, takeover will be nondisruptive for those sessions.

    Refer to SMB/CIFS File Access Reference Guide .

If the node doing the takeover panics​

If the node that is performing the takeover panics within 60 seconds of initiating takeover, the following events occur:

  • The node that panicked reboots.

  • After it reboots, the node performs self-recovery operations and is no longer in takeover mode.

  • Failover is disabled.

  • If the node still owns some of the partner's aggregates, after enabling storage failover, return these aggregates to the partner using the storage failover giveback command.