日本語は機械翻訳による参考訳です。内容に矛盾や不一致があった場合には、英語の内容が優先されます。

ONTAPクラスタの自動テイクオーバーとギブバックについて学習します

01/23/2026 共同作成者

PDF

自動テイクオーバー処理と自動ギブバック処理を組み合わせて使用することで、クライアントの停止を短くしたり回避したりできます。

デフォルトでは、HAペアの一方のノードでパニック、リブート、または停止が発生すると、パートナーノードにストレージが自動的にテイクオーバーされ、対象のノードのリブートが完了した時点でストレージが戻されます。その後、HAペアは通常の動作状態に戻ります。

自動テイクオーバーは、どちらかのノードが応答しなくなった場合にも実行されることがあります。

自動ギブバックはデフォルトで実行されます。クライアントへのギブバックの影響を制御したい場合は、自動ギブバックを無効にして `storage failover modify -auto-giveback false -node <node>`コマンドを使用できます。自動ギブバックを実行する前に（トリガーの種類に関係なく）、パートナーノードは `storage failover modify`コマンドの `-delay- seconds`パラメータで制御される一定時間待機します。デフォルトの遅延時間は600秒です。

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

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

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

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

テイクオーバー時の動作

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

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

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

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

`storage failover show-takeover`コマンドを使用して進行状況を監視できます。
`storage failover takeover`コマンドで `-bypass-optimization`パラメータを使用すると、このテイクオーバーインスタンス中のアグリゲートの再配置を回避できます。

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

ユーザが開始したネゴシエートテイクオーバーの場合は、ターゲットノードが正常にシャットダウンされ、そのあとにルートアグリゲートと最初の手順で再配置されなかったアグリゲートのテイクオーバーが実行されます。
データ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の問題は解決されており、データの提供を再開できる状態になっています。

Node 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`に設定してアグリゲートの再配置を開始した場合、デスティネーションノードで実行されているディスクファームウェアのバックグラウンド更新は、アグリゲートの再配置に影響しません。