本繁體中文版使用機器翻譯，譯文僅供參考，若與英文版本牴觸，應以英文版本為準。

自動接管和恢復的運作方式

12/08/2023 貢獻者

PDF

自動接管和恢復作業可搭配運作、以減少並避免用戶端中斷運作。

根據預設、如果HA配對中的某個節點出現問題、重新開機或暫停、則當受影響的節點重新開機時、合作夥伴節點會自動接管、然後返回儲存設備。然後HA配對會恢復正常運作狀態。

如果其中一個節點沒有回應、也可能會自動移轉。

預設會自動還原。如果您想控制對用戶端的恢復影響、可以停用自動恢復並使用 storage failover modify -auto-giveback false -node <node> 命令。在執行自動恢復之前（無論觸發的是什麼）、合作夥伴節點會等待由控制的固定時間量 -delay- seconds 的參數 storage failover modify 命令。預設延遲為600秒。藉由延遲恢復、此程序會導致兩次短暫的中斷：一次發生在接管期間、另一次發生在恢復期間。

此程序可避免單一、長時間的停機、包括下列需求所需的時間：

接管作業
接管節點、以開機至準備好恢復的點
恢復作業

如果任何非根集合體的自動恢復失敗、系統會自動再嘗試兩次完成恢復。

在接管過程中、自動恢復程序會在合作夥伴節點準備好進行恢復之前開始。當自動恢復程序的時間限制到期、且合作夥伴節點仍未就緒時、定時器會重新啟動。因此、合作夥伴節點準備就緒與實際執行的恢復之間的時間、可能會比自動恢復時間短。

接管期間會發生什麼事

當節點接管其合作夥伴時、它會繼續提供及更新合作夥伴的集合體和磁碟區中的資料。

在接管過程中會執行下列步驟：

如果交涉接管是由使用者啟動、則彙總資料會從合作夥伴節點移至執行接管的節點。當每個集合體的目前擁有者（根集合體除外）變更為接管節點時、會發生短暫的停機。這種停機時間比在接管期間發生的停機時間更為短暫、而且不會進行集合體重新配置。

在發生恐慌時、無法進行協商的接管。接管可能是因為故障與恐慌無關。當節點與其合作夥伴之間的通訊中斷、也稱為心跳中斷時、就會發生故障。如果因故障而發生接管、中斷時間可能會較長、因為合作夥伴節點需要時間來偵測心跳中斷。

您可以使用監控進度 storage failover show‑takeover 命令。
您可以使用、避免在此接管執行個體期間重新配置 Aggregate ‑bypass‑optimization 參數 storage failover takeover 命令。

在計畫性的接管作業期間、集合體會依序重新定位、以減少用戶端中斷。如果跳過集合體重新配置、則在計畫性接管事件期間、會發生較長的用戶端停機時間。

如果使用者啟動的接管是協調式接管、則目標節點會正常關機、接著接管目標節點的根Aggregate、以及步驟1中未重新放置的任何集合體。
資料生命（邏輯介面）會根據 LIF 容錯移轉規則、從目標節點移轉至接管節點、或移轉至叢集中的任何其他節點。您可以使用避免 LIF 移轉 ‑skip‑lif-migration 參數 storage failover takeover 命令。如果是由使用者啟動的接管、則會在開始接管儲存設備之前移轉資料生命。萬一發生恐慌或故障、資料生命與儲存設備會一起移轉。

當發生接管時、現有的SMB工作階段會中斷連線。

由於SMB傳輸協定的本質、所有SMB工作階段都會中斷（連線至「持續可用度」內容集之共用的SMB 3.0工作階段除外）。SMB 1.0和SMB 2.x工作階段在接管事件之後無法重新連線、因此接管作業會中斷運作、而且可能會發生部分資料遺失。

SMB 3.0工作階段是為了與啟用的Continuous Availability屬性共用而建立、可在接管事件發生後重新連線至中斷連線的共用區。如果您的站台使用SMB 3.0連線至Microsoft Hyper-V、且相關共用上已啟用Continuous Availability屬性、則這些工作階段的接管作業將不會中斷營運。

執行接管的節點會發生什麼情況

如果在啟動接管後60秒內執行接管的節點出現問題、則會發生下列事件：

系統重新開機的節點。
重新開機後、節點會執行自我恢復作業、不再處於接管模式。
容錯移轉已停用。
如果節點仍擁有部分合作夥伴的集合體、則在啟用儲存容錯移轉之後、請使用將這些集合體傳回合作夥伴 storage failover giveback 命令。

恢復期間會發生什麼事

當問題解決、合作夥伴節點開機或啟動恢復時、本機節點會將擁有權傳回給合作夥伴節點。

下列程序會在一般的恢復作業中執行。在本討論中、節點A已接管節點B節點B上的任何問題均已解決、可繼續處理資料。

節點 B 上的任何問題均已解決、並顯示下列訊息： Waiting for giveback
贈品由啟動 storage failover giveback 命令或自動恢復（如果系統已設定）。這會啟動將節點B的集合體和磁碟區所有權從節點A傳回節點B的程序
節點A會先傳回根Aggregate的控制權。
節點B完成開機至正常作業狀態的程序。

當節點B到達開機程序中可接受非根集合體的點時、節點A會一次傳回其他集合體的擁有權、直到恢復完成為止。您可以使用監控恢復的進度 storage failover show-giveback 命令。

。 storage failover show-giveback 命令不會（也不會用於）顯示儲存容錯移轉恢復作業期間所有作業的相關資訊。您可以使用 storage failover show 命令顯示有關節點目前容錯移轉狀態的其他詳細資料、例如節點是否完全正常運作、是否可以接管、以及恢復是否完成。

每個集合體的I/O會在該集合體的還原完成後恢復、進而縮短其整體中斷時間。

HA原則及其對接管與恢復的影響

自動將CFO（控制器容錯移轉）和SFO（儲存容錯移轉）的HA原則指派給Aggregate。ONTAP此原則可決定集合體及其磁碟區的儲存容錯移轉作業執行方式。

CFO和SFO這兩種選項可決定ONTAP 儲存容錯移轉和還原作業期間的集合體控制順序。

雖然CFO和SFO這兩個術語有時會非正式地用於指儲存容錯移轉（接管和恢復）作業、但它們實際上代表指派給集合體的HA原則。例如、詞彙SFO Aggregate或CFO Aggregate只是指Aggregate的HA原則指派。

HA原則會影響接管和恢復作業、如下所示：

在不含根磁碟區的根Aggregate以外的ONTAP 任何其他系統上建立的Aggregate、均具有SFO的HA原則。手動啟動的接管功能已針對效能最佳化、因為在接管之前、會將SFO（非root）集合體以序列方式重新定位至合作夥伴。在恢復程序期間、集合體會在接管系統開機且管理應用程式上線後、以序列方式傳回、讓節點能夠接收其集合體。
由於Aggregate重新配置作業需要重新指派Aggregate磁碟擁有權、並將控制權從節點移轉至合作夥伴、因此只有符合SFO HA原則的Aggregate才有資格進行Aggregate重新配置。
根Aggregate一律具有CFO的HA原則、並在恢復作業開始時提供。這是允許接管系統開機的必要步驟。在接管系統完成開機程序且管理應用程式上線之後、所有其他集合體都會連續傳回、讓節點能夠接收其集合體。

將Aggregate的HA原則從SFO變更為CFO是一項維護模式作業。除非客戶支援代表指示、否則請勿修改此設定。

背景更新如何影響接管和恢復

磁碟韌體的背景更新會以不同的方式影響HA配對接管、恢復和集合重新配置作業、具體取決於這些作業的啟動方式。

下列清單說明背景磁碟韌體更新如何影響接管、恢復及集合重新定位：

如果在任一節點的磁碟上進行背景磁碟韌體更新、則手動啟動的接管作業會延遲、直到該磁碟上的磁碟韌體更新完成為止。如果背景磁碟韌體更新所需時間超過120秒、則接管作業將會中止、而且必須在磁碟韌體更新完成後手動重新啟動。如果是使用啟動接管 ‑bypass‑optimization 的參數 storage failover takeover 命令設為 true，目的地節點上發生的背景磁碟韌體更新不會影響接管。
如果來源（或接管）節點上的磁碟發生背景磁碟韌體更新、則會使用手動啟動接管 ‑options 的參數 storage failover takeover 命令設為 immediate，接管操作將立即開始。
如果背景磁碟韌體更新發生在節點上的磁碟上、而且發生問題、則會立即開始接管發生問題的節點。
如果背景磁碟韌體更新發生在任一節點的磁碟上、資料集合體的恢復會延遲、直到磁碟韌體更新完成為止。
如果背景磁碟韌體更新所需時間超過120秒、則會中止還原作業、而且必須在磁碟韌體更新完成後手動重新啟動。
如果在任一節點的磁碟上進行背景磁碟韌體更新、則會延遲Aggregate重新配置作業、直到該磁碟上的磁碟韌體更新完成為止。如果背景磁碟韌體更新所需時間超過120秒、則會中止集合體重新配置作業、而且必須在磁碟韌體更新完成後手動重新啟動。如果已使用啟動 Aggregate 重新定位 -override-destination-checks 的 storage aggregate relocation 命令設為 true、目的地節點上發生的背景磁碟韌體更新不會影響 Aggregate 重新定位。