ThinkSystem DM 系列存储的自动接管和归还功能是如何工作的
描述
自动接管和恢复操作可以协同工作，减少和避免客户端服务中断。
默认情况下，如果高可用性 (HA) 对中的一个节点发生故障、重启或停止运行，则另一个节点会自动接管，并在受影响节点重启后恢复存储。之后，HA 对将恢复正常运行状态。如果其中一个节点无响应，也可能发生自动接管。
默认情况下会进行自动恢复。如果您希望控制恢复对客户端的影响，可以禁用自动恢复并使用存储故障转移修改命令。在执行自动恢复之前（无论触发原因是什么），伙伴节点会等待一段由命令参数控制的固定时间。默认延迟时间为 600 秒。通过延迟恢复，该过程会导致两次短暂中断：一次在接管期间，一次在恢复期间。-auto-giveback false -node -delay- secondsstorage failover modify
此流程可避免一次性长时间停机，包括以下所需时间：
1. 收购行动
2. 接管的节点将启动到可以归还的阶段
3. 回馈行动
如果任何非根聚合的自动恢复失败，系统会自动再尝试两次以完成恢复。
笔记：在接管过程中，自动归还流程会在伙伴节点准备好归还之前启动。当自动归还流程的时间限制到期而伙伴节点仍未准备好时，计时器会重新启动。因此，伙伴节点准备好到实际执行归还操作之间的时间可能比自动归还流程所需的时间更短。
如果您想了解更多关于接管/归还过程中发生的情况，包括恐慌或后台操作如何影响接管/归还，请点击下面的箭头展开以下各部分。
收购过程中会发生什么
当一个节点接管其伙伴节点时，它会继续服务和更新伙伴节点聚合和卷中的数据。
收购过程中会发生以下步骤
笔记：在计划接管操作期间，聚合体将按顺序迁移，以减少客户端中断时间。如果跳过聚合体迁移，则在计划接管事件期间会出现更长时间的客户端中断。
笔记：由于 SMB 协议的特性，所有 SMB 会话都会中断（连接到设置了“持续可用性”属性的共享的 SMB 3.0 会话除外）。SMB 1.0 和 SMB 2.x 会话在接管事件后无法重新连接；因此，接管会造成中断，并可能导致部分数据丢失。
1. 如果协商后的接管是由用户发起的，则聚合数据将从合作节点迁移到执行接管的节点。由于每个聚合（根聚合除外）的当前所有者会切换到接管节点，因此会发生短暂的服务中断。此中断时间比未进行聚合迁移的接管过程中发生的中断时间更短。
• 您可以使用该命令监控进度storage failover show-takeover。
• -bypass-optimization您可以通过在命令中使用参数来避免在此接管实例期间进行聚合迁移storage failover takeover。
2. 如果用户发起的接管是协商接管，则目标节点会优雅地关闭，然后接管目标节点的根聚合以及在步骤 1 中未迁移的任何聚合。
3. 在存储接管开始之前，数据逻辑接口 (LIF) 会根据 LIF 故障转移规则，从目标节点迁移到接管节点，或集群中的任何其他节点。您可以使用-skip-lif-migration存储故障转移接管命令的参数来避免 LIF 迁移。
4. 接管发生时，现有的 SMB 会话将被断开。
5. 已建立到启用了“持续可用性”属性的共享的 SMB 3.0 会话，在发生接管事件后可以重新连接到断开连接的共享。如果您的站点使用 SMB 3.0 连接到 Microsoft Hyper-V，并且关联的共享启用了“持续可用性”属性，则接管事件不会中断这些会话。
如果执行接管操作的节点发生恐慌会发生什么？
如果执行接管操作的节点在发起接管后 60 秒内发生 panic，则会发生以下事件：
• 发生故障的节点重启。
• 重启后，节点执行自我恢复操作，不再处于接管模式。
• 故障转移已禁用。
• 如果节点仍然拥有合作伙伴的部分聚合，在启用存储故障转移后，使用以下方式将这些聚合返回给合作伙伴storage failover giveback command：
回馈过程中会发生什么？
当问题解决、伙伴节点启动或发起归还时，本地节点会将所有权归还给伙伴节点。
在正常的交接操作中，会执行以下流程。在本例中，节点 A 已接管节点 B。节点 B 上的所有问题均已解决，现在可以恢复数据服务。
1. 节点 B 上的任何问题都已解决，并显示以下消息：Waiting for giveback
2. 所有权归还可通过storage failover giveback命令发起，如果系统已配置，则可通过自动归还发起。这将启动将节点 B 的聚合和卷的所有权从节点 A 归还给节点 B 的过程。
3. 节点 A 首先返回根聚合的控制权。
4. 节点 B 完成启动过程，进入正常运行状态。
5. 一旦节点 B 启动到可以接受非根聚合的阶段，节点 A 就会逐个将其他聚合的所有权交还给节点 B，直到所有权交还完成。您可以使用该storage failover show-giveback命令监控所有权交还的进度。
笔记：存储故障转移 show-giveback 命令不会（也并非旨在）显示存储故障转移恢复操作期间发生的所有操作的信息。您可以使用存储故障转移 show 命令显示有关节点当前故障转移状态的更多详细信息，例如节点是否完全正常运行、是否可以进行接管以及恢复是否已完成。
每个聚合的 I/O 恢复操作在完成该聚合的恢复操作后进行，从而缩短其整体中断窗口。
HA政策及其对接管和转让的影响
ONTAP 会自动为聚合分配 CFO（控制器故障转移）和 SFO（存储故障转移）的高可用性策略。此策略决定了聚合及其卷的存储故障转移操作如何进行。
CFO 和 SFO 这两个选项决定了 ONTAP 在存储故障转移和恢复操作期间使用的聚合控制顺序。
尽管 CFO 和 SFO 这两个术语有时被非正式地用来指代存储故障转移（接管和恢复）操作，但它们实际上代表分配给聚合的高可用性 (HA) 策略。例如，SFO 聚合或 CFO 聚合仅仅是指聚合的 HA 策略分配。
HA政策对接管和归还操作的影响如下：
• 在 ONTAP 系统上创建的聚合（根聚合包含根卷除外）采用 SFO 高可用性策略。手动发起的接管操作通过在接管前将 SFO（非根）聚合按顺序迁移到伙伴节点来优化性能。在恢复过程中，接管的系统启动且管理应用程序上线后，聚合将按顺序恢复，从而使节点能够接收其聚合。
• 由于聚合迁移操作涉及重新分配聚合磁盘所有权并将控制权从一个节点转移到其伙伴节点，因此只有具有 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`--require` 参数设置为 `true` 的情况下启动的true，则目标节点上正在进行的后台磁盘固件更新不会影响聚合迁移。