Skip to main content
简体中文版经机器翻译而成，仅供参考。如与英语版出现任何冲突，应以英语版为准。

自动接管和交还的工作原理

贡献者
PDF

自动接管和交还操作可以协同工作，以减少和避免客户端中断。

默认情况下，如果 HA 对中的一个节点发生崩溃，重新启动或暂停，则配对节点会自动接管，然后在受影响节点重新启动时返回存储。然后， HA 对恢复正常运行状态。

如果其中一个节点无响应，也可能发生自动接管。

默认情况下会自动交还。如果您要控制交还对客户端的影响、则可以禁用自动交还并使用 storage failover modify -auto-giveback false -node <node> 命令：在执行自动交还之前(无论什么触发了交还)、配对节点会等待固定的时间量、此时间量由控制 -delay- seconds 的参数 storage failover modify 命令：默认延迟为 600 秒。通过延迟交还，此过程会导致两个短暂中断：一个在接管期间中断，一个在交还期间中断。

此过程可避免一次长时间的中断，包括以下操作所需的时间：

  • 接管操作

  • 要启动到准备好进行交还的接管节点

  • 交还操作

如果任何非根聚合的自动交还失败，系统将自动再尝试两次以完成交还。

备注 在接管过程中，自动交还过程会在配对节点准备好进行交还之前启动。当自动交还过程的时间限制到期且配对节点仍未准备就绪时，计时器将重新启动。因此，配对节点准备就绪与实际执行交还之间的时间可能比自动交还时间短。

接管期间会发生什么情况

当节点接管其配对节点时，它会继续提供并更新配对节点的聚合和卷中的数据。

在接管过程中会执行以下步骤：

  1. 如果协商接管由用户启动，则聚合数据将从配对节点移至执行接管的节点。当每个聚合的当前所有者（根聚合除外）更改为接管节点时，会发生短暂中断。与在不重新定位聚合的情况下进行接管期间发生的中断相比，此中断更短。

    备注 在发生崩溃时、无法在崩溃期间进行协商接管。 接管可能是由与崩溃无关的故障引起的。如果节点与其配对节点之间的通信中断、则会发生故障、也称为检测信号丢失。如果因故障而发生接管、则中断时间可能会更长、因为配对节点需要时间来检测检测检测检测检测信号丢失。

    • 您可以使用监控进度 storage failover show‑takeover 命令：

    • 在此接管实例期间、您可以使用来避免聚合重新定位 ‑bypass‑optimization 参数 storage failover takeover 命令：

      在计划内接管操作期间，聚合会按顺序重新定位，以减少客户端中断。如果绕过聚合重新定位，则在计划内接管事件期间，客户端中断时间会更长。

  2. 如果用户启动的接管是协商接管，则目标节点会正常关闭，然后接管目标节点的根聚合以及步骤 1 中未重新定位的任何聚合。

  3. 根据LIF故障转移规则、数据LIF (逻辑接口)会从目标节点迁移到接管节点或集群中的任何其他节点。您可以使用避免LIF迁移 ‑skip‑lif-migration 参数 storage failover takeover 命令：如果发生用户启动的接管、则会在存储接管开始之前迁移数据生命周期。 发生崩溃或故障时、数据生命周期和存储会一起迁移。

  4. 发生接管时，现有 SMB 会话将断开连接。

    备注 由于 SMB 协议的性质，所有 SMB 会话都会中断（连接到设置了持续可用性属性的共享的 SMB 3.0 会话除外）。发生接管事件后， SMB 1.0 和 SMB 2.x 会话无法重新连接；因此，接管会造成中断，并可能发生部分数据丢失。

  5. 与启用了持续可用性属性的共享建立的 SMB 3.0 会话可以在接管事件后重新连接到已断开连接的共享。如果您的站点使用 SMB 3.0 连接到 Microsoft Hyper-V ，并且关联共享上已启用持续可用性属性，则这些会话的接管不会造成中断。

执行接管的节点发生崩溃时会发生什么情况

如果执行接管的节点在启动接管后 60 秒内崩溃，则会发生以下事件：

  • 崩溃的节点将重新启动。

  • 重新启动后，节点将执行自恢复操作，并且不再处于接管模式。

  • 故障转移已禁用。

  • 如果节点仍拥有配对节点的某些聚合、则在启用存储故障转移后、使用将这些聚合归还给配对节点 storage failover giveback 命令：

交还期间会发生什么情况

当问题得到解决，配对节点启动或启动交还时，本地节点会将所有权归还给配对节点。

以下过程会在正常交还操作中进行。在本讨论中，节点 A 接管了节点 B节点 B 上的所有问题均已解决，并且可以恢复提供数据。

  1. 节点B上的所有问题均已解决、并显示以下消息： Waiting for giveback

  2. 可通过启动此回给 storage failover giveback 命令或自动交还(如果系统已配置)。这将启动将节点 B 的聚合和卷的所有权从节点 A 返回到节点 B 的过程

  3. 节点 A 首先返回根聚合的控制权。

  4. 节点 B 完成启动至其正常运行状态的过程。

  5. 一旦节点 B 达到启动过程中可接受非根聚合的时间点，节点 A 就会返回其他聚合的所有权，一次返回一个，直到交还完成为止。您可以使用监控此类功能的进度 storage failover show-giveback 命令：

    备注 。 storage failover show-giveback 命令不会(也不会显示)显示有关存储故障转移恢复操作期间发生的所有操作的信息。您可以使用 storage failover show 命令以显示有关节点当前故障转移状态的其他详细信息、例如节点是否完全正常运行、是否可以接管以及是否完成了恢复。

    每个聚合在交还完成后会恢复 I/O ，从而缩短其整体中断时间。

HA 策略及其对接管和交还的影响

ONTAP 会自动将 CFO （控制器故障转移）和 SFO （存储故障转移）的 HA 策略分配给聚合。此策略可确定聚合及其卷如何执行存储故障转移操作。

CFO 和 SFO 这两个选项可确定 ONTAP 在存储故障转移和交还操作期间使用的聚合控制序列。

尽管有时会非正式地使用 CFO 和 SFO 这两个术语来指代存储故障转移（接管和交还）操作，但它们实际上表示分配给聚合的 HA 策略。例如，术语 SFO 聚合或 CFO 聚合只是指聚合的 HA 策略分配。

HA 策略会对接管和交还操作产生如下影响：

  • 在 ONTAP 系统上创建的聚合（包含根卷的根聚合除外）的 HA 策略为 SFO 。手动启动的接管经过优化，可在接管之前将 SFO （非根）聚合按顺序重新定位到配对节点，以提高性能。在交还过程中，聚合会在被接管系统启动且管理应用程序联机后按顺序交还，从而使节点能够接收其聚合。

  • 由于聚合重新定位操作需要重新分配聚合磁盘所有权并将控制权从节点转移到其配对节点，因此只有 HA 策略为 SFO 的聚合才有资格进行聚合重新定位。

  • 根聚合的 HA 策略始终为 CFO ，并在交还操作开始时交还。要使被接管系统能够启动，必须执行此操作。所有其他聚合都会在被接管系统完成启动过程并使管理应用程序联机后按顺序交还，从而使节点能够接收其聚合。

备注 将聚合的 HA 策略从 SFO 更改为 CFO 是一项维护模式操作。除非客户支持代表指示，否则请勿修改此设置。

后台更新如何影响接管和交还

磁盘固件的后台更新会对 HA 对接管，交还和聚合重新定位操作产生不同的影响，具体取决于这些操作的启动方式。

以下列表介绍了后台磁盘固件更新如何影响接管，交还和聚合重新定位：

  • 如果在任一节点的磁盘上进行后台磁盘固件更新，则手动启动的接管操作将延迟，直到该磁盘上的磁盘固件更新完成。如果后台磁盘固件更新所需时间超过 120 秒，接管操作将中止，必须在磁盘固件更新完成后手动重新启动。如果接管是使用启动的 ‑bypass‑optimization 的参数 storage failover takeover 命令设置为 true，则在目标节点上进行的后台磁盘固件更新不会影响接管。

  • 如果在源(或接管)节点的磁盘上进行后台磁盘固件更新、并且接管是使用手动启动的 ‑options 的参数 storage failover takeover 命令设置为 immediate、则接管操作将立即启动。

  • 如果节点上的磁盘正在进行后台磁盘固件更新，但该更新发生崩溃，则会立即开始接管发生崩溃的节点。

  • 如果在任一节点的磁盘上进行后台磁盘固件更新，则数据聚合的交还将延迟，直到该磁盘上的磁盘固件更新完成。

  • 如果后台磁盘固件更新所需时间超过 120 秒，则交还操作将中止，必须在磁盘固件更新完成后手动重新启动。

  • 如果在任一节点的磁盘上进行后台磁盘固件更新，则聚合重新定位操作将延迟，直到该磁盘上的磁盘固件更新完成。如果后台磁盘固件更新所需时间超过 120 秒，则聚合重新定位操作将中止，并且必须在磁盘固件更新完成后手动重新启动。聚合重新定位是使用启动的 -override-destination-checks 的 storage aggregate relocation 命令设置为 true，则在目标节点上进行的后台磁盘固件更新不会影响聚合重新定位。