自動ギブバックはデフォルトで実行されます。ギブバックによるクライアントへの影響を制御したい場合は、自動ギブバックを無効にし、storage failover modify -auto-giveback false -node <node>コマンドを使用します。自動ギブバックには、トリガーされた状況に関係なく、パートナーノードで実行されるまでに一定の待機時間が設けられています。この時間は、storage failover modifyコマンドの-delay- secondsパラメーターで制御されます。デフォルトの待機時間は600秒です。ギブバックを遅らせることで、テイクオーバー時とギブバック時の2回、短時間の停止が発生します。

これにより、以下の処理をすべて実行するために必要な長時間の停止が1度だけ発生する状況が回避されます。

テイクオーバー処理
テイクオーバーされたノードをブートしてギブバック可能な状態にする処理
ギブバック処理

ルート以外のアグリゲートで自動ギブバックが失敗した場合、さらに2回、自動でギブバックが試行されます。

テイクオーバープロセスでは、パートナーノードがギブバック可能な状態になる前に自動ギブバックプロセスが開始されます。自動ギブバックプロセスの待機時間内にパートナーノードがギブバック可能な状態にならなかった場合、タイマーがリスタートします。その結果、パートナーノードがギブバック可能な状態になってから実際のギブバックが実行されるまでの時間が自動ギブバックの時間よりも短くなる可能性があります。

テイクオーバー時の動作

パートナーをテイクオーバーしたノードは、パートナーのアグリゲートとボリュームのデータを提供および更新します。

テイクオーバープロセスでは次の処理が実行されます。

ユーザーが開始したネゴシエートテイクオーバーの場合は、テイクオーバーを実行するノードにパートナーノードから集約されたデータが移動されます。各アグリゲート（ルートアグリゲートを除く）の現在の所有者がテイクオーバーノードに切り替わるときに、短時間の停止が発生します。ただし、アグリゲートの再配置を伴わないテイクオーバーに比べると短時間で済みます。

パニック状態になった場合、パニック時のネゴシエートテイクオーバーは行われません。テイクオーバーは、パニックに関連しない障害が原因でも発生します。障害は、ノードとそのパートナー間の通信が失われたとき（ハートビート喪失とも呼ばれます）に発生します。障害が原因でテイクオーバーが発生した場合は、パートナーノードがハートビートの喪失を検出する時間が必要になるためため、停止時間が長くなる可能性があります。

処理の進捗はstorage failover show‑takeoverコマンドを使用して監視できます。
storage failover takeoverコマンドで‑bypass‑optimizationパラメーターを使用すると、このテイクオーバーインスタンスの実行時にアグリゲートの再配置を省略できます。

計画的テイクオーバー処理では、クライアントの停止を最小限にするため、アグリゲートが順に再配置されます。アグリゲートの再配置を行わない場合、計画的テイクオーバーの際のクライアントの停止時間が長くなります。

ユーザーが開始したネゴシエートテイクオーバーの場合は、ターゲットノードが正常にシャットダウンされ、そのあとにルートアグリゲートと手順1で再配置されなかったアグリゲートのテイクオーバーが実行されます。
ターゲットノードのデータLIF（論理インターフェイス）が、LIFのフェイルオーバールールに基づいて、テイクオーバーノードまたはクラスタ内のその他のノードに移行されます。storage failover takeoverコマンドで‑skip‑lif-migrationパラメーターを使用すると、LIFの移行を省略できます。ユーザーが開始したテイクオーバーの場合、ストレージテイクオーバーの開始前にデータLIFが移行されます。パニック状態や障害発生時には、データLIFとストレージが一緒に移行されます。

テイクオーバーが発生すると、既存のSMBセッションは切断されます。

SMBプロトコルの性質上、すべてのSMBセッションが停止されます（継続的可用性プロパティが設定された共有に接続しているSMB 3.0セッションを除く）。SMB 1.0セッションとSMB 2.xセッションは、テイクオーバー後に再接続できません。このため、テイクオーバーは中断を伴い、一部のデータが失われる可能性があります。

継続的可用性プロパティが有効になっている共有に対するSMB 3.0セッションは、テイクオーバー後に元の共有に再接続できます。SMB 3.0を使用してMicrosoft Hyper-Vに接続している場合は、関連する共有で継続的可用性プロパティが有効になっていれば、テイクオーバー時にそれらのセッションが停止することはありません。

テイクオーバーを実行するノードがパニック状態になった場合の動作

テイクオーバーを実行中のノードが、そのテイクオーバーを開始してから60秒以内にパニック状態になると、次のような状態になります。

パニックが発生したノードがリブートします。
リブートしたノードではセルフリカバリー処理が実行され、テイクオーバーモードではなくなります。
フェイルオーバーが無効になります。
パートナーの一部のアグリゲートをまだ所有している場合は、ストレージフェイルオーバーを有効にしたあとに、storage failover givebackコマンドを使用してそれらのアグリゲートをパートナーに戻してください。

ギブバック時の動作

問題が解決されるか、パートナーノードがブートするか、ギブバックが開始されると、ローカルノードからパートナーノードに所有権が戻ります。

通常のギブバック処理のプロセスを次に示します。ここでは、ノードAがノードBをテイクオーバーしたものとします。ノードBの問題は解決されており、データの提供を再開できる状態になっています。

ノードBの問題がすべて解決され、次のメッセージが表示されます。Waiting for giveback
storage failover givebackコマンドまたは自動ギブバック（設定されている場合）でギブバックが開始されます。これにより、ノードBのアグリゲートおよびボリュームの所有権をノードAからノードBに戻すプロセスが開始されます。
ノードAはまずルートアグリゲートの制御を戻します。
ノードBが、正常な動作状態に戻るためのブートプロセスを実行します。

ブートプロセスの実行中、ノードBがルート以外のアグリゲートを受け取れる状態になった時点で、ノードAが他のアグリゲートの所有権を1つずつ戻し、ギブバックを完了します。ギブバックの進捗は、storage failover show-givebackコマンドで監視できます。

storage failover show-givebackコマンドは、ストレージフェイルオーバーのギブバック処理中に発生するすべての処理の情報を表示するわけではありません（また、それを目的としていません）。storage failover showコマンドを使用して、ノードの現在のフェイルオーバーステータスに関するその他の詳細情報（ノードが完全に機能しているか、テイクオーバーが可能か、ギブバックが完了したかなど）を表示できます。

各アグリゲートのI/Oは、そのアグリゲートのギブバックが完了した時点で再開されるため、アグリゲートの全体的な停止時間が短縮されます。

HAポリシーがテイクオーバーとギブバックに与える影響

ONTAPは、CFO（コントローラーフェイルオーバー）またはSFO（ストレージフェイルオーバー）のHAポリシーを自動でアグリゲートに割り当てます。このポリシーによって、アグリゲートとそのボリュームでストレージフェイルオーバー処理がどのように実行されるかが決まります。

CFOとSFOのどちらのオプションが割り当てられているかによって、ストレージのフェイルオーバー処理とギブバック処理で使用されるアグリゲートの制御順序が決まります。

CFOおよびSFOという用語は、ストレージフェイルオーバー（テイクオーバーとギブバック）処理を表すこともありますが、実際はアグリゲートに割り当てられるHAポリシーのことを表しています。たとえば、SFOアグリゲートやCFOアグリゲートという表現は、単にアグリゲートに割り当てられたHAポリシーを指しています。

HAポリシーは、テイクオーバー処理とギブバック処理に次のように影響します。

ONTAPシステムで作成されたアグリゲート（ルートボリュームを含むルートアグリゲートを除く）には、SFOのHAポリシーが割り当てられます。手動で開始されたテイクオーバーでは、テイクオーバー前にSFOアグリゲート（ルート以外）をパートナーに順番に再配置することで、パフォーマンスが最適化されます。ギブバック処理では、テイクオーバーされたシステムがブートして管理アプリケーションがオンラインになり、ノードがアグリゲートを受け取れる状態になってから、アグリゲートが順番にギブバックされます。
アグリゲートの再配置処理では、アグリゲートのドライブ所有権が再割り当てされ、ノードの制御がパートナーに移るため、SFOのHAポリシーが割り当てられたアグリゲートだけが再配置の対象になります。
ルートアグリゲートには常にCFOのHAポリシーを割り当てられ、最初にギブバックされます。これは、テイクオーバーされたシステムがブートできるようにするためです。その他のすべてのアグリゲートは、テイクオーバーされたシステムのブートプロセスが完了して管理アプリケーションがオンラインになり、ノードがアグリゲートを受け取れる状態になってから、順番にギブバックされます。

アグリゲートのHAポリシーをSFOからCFOに変更する処理はメンテナンスモードの処理です。この設定は、弊社のサポートの担当者から指示がないかぎり変更しないでください。

バックグラウンド更新がテイクオーバーとギブバックに与える影響

ドライブファームウェアのバックグラウンド更新がHAペアのテイクオーバー、ギブバック、アグリゲート再配置の各処理に与える影響は、それらの処理がどのように開始されたかによって異なります。

ドライブファームウェアのバックグラウンド更新がテイクオーバー、ギブバック、およびアグリゲートの再配置に与える影響は次のとおりです。

どちらかのノードのドライブでドライブファームウェアのバックグラウンド更新が実行されると、手動で開始したテイクオーバー処理は、そのドライブのドライブファームウェアの更新が完了するまで保留されます。ドライブファームウェアのバックグラウンド更新が120秒経っても完了しない場合は、テイクオーバー処理は中止され、ドライブファームウェアの更新の完了後に手動で再開する必要があります。storage failover takeoverコマンドの‑bypass‑optimizationパラメーターをtrueに設定してテイクオーバーを開始した場合は、デスティネーションノードでドライブファームウェアのバックグラウンド更新を実行していても、テイクオーバーには影響しません。
ソース（テイクオーバー）ノードのドライブでドライブファームウェアのバックグラウンド更新を実行中の場合、storage failover takeoverコマンドの‑optionsパラメーターをimmediateに設定して手動で開始したテイクオーバー処理はただちに開始されます。
ノードのドライブでドライブファームウェアのバックグラウンド更新を実行中の場合に、そのノードがパニック状態になると、パニック状態になったノードのテイクオーバーが開始されます。
いずれかのノードのドライブでドライブファームウェアのバックグラウンド更新を実行中の場合、データアグリゲートのギブバックは、そのドライブでドライブファームウェアの更新が完了するまで保留されます。
ドライブファームウェアのバックグラウンド更新が120秒経っても完了しない場合は、ギブバック処理は中止され、ドライブファームウェアの更新の完了後に手動で再開する必要があります。
いずれかのノードのドライブでドライブファームウェアのバックグラウンド更新を実行中の場合、アグリゲートの再配置処理は、そのドライブでドライブファームウェアの更新が完了するまで保留されます。ドライブファームウェアのバックグラウンド更新が120秒経っても完了しない場合は、アグリゲートの再配置処理は中止され、ドライブファームウェアの更新の完了後に手動で再開する必要があります。storage aggregate relocationコマンドの-override-destination-checksパラメーターをtrueに設定してアグリゲートの再配置を開始した場合は、デスティネーションノードでドライブファームウェアのバックグラウンド更新が実行されていても、アグリゲートの再配置には影響しません。