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

自動テイクオーバーと自動ギブバックの仕組み

寄稿者 このページの PDF をダウンロード

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

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

自動テイクオーバーは、いずれかのノードが応答しなくなった場合にも実行されます。

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

これにより、次の処理に必要な時間を含む 1 回の長時間の停止が回避されます。

  • テイクオーバー処理

  • テイクオーバーされたノードがブートし、ギブバック可能な状態になります

  • ギブバック処理

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

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

テイクオーバー時の動作

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

テイクオーバープロセスの実行中は次の手順が実行されます。

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

    • 「 storage failover show ‑ takeover 」コマンドを使用すると、進行状況を監視できます。

    • このテイクオーバーインスタンス中にアグリゲートの再配置を回避するには、「 storage failover takeover 」コマンドで「‑ bypass ‑ optimization 」パラメータを使用します。

      注記 計画的テイクオーバー処理では、クライアントの停止を最小限にするため、アグリゲートが順に再配置されます。アグリゲートの再配置を省略すると、計画的テイクオーバーの際のクライアントの停止時間が長くなります。
  2. ユーザが開始したネゴシエートテイクオーバーの場合は、ターゲットノードが正常にシャットダウンされ、そのあとにルートアグリゲートと手順 1 で再配置されなかったアグリゲートのテイクオーバーが実行されます。

  3. ストレージテイクオーバーの開始前に、ターゲットノードのデータ LIF (論理インターフェイス)が、 LIF のフェイルオーバールールに基づいて、テイクオーバーノードまたはクラスタ内のその他のノードに移行されます。「 storage failover takeover 」コマンドで「‑ skip-lif-migration 」パラメータを使用すると、 LIF の移行を回避できます。

  4. テイクオーバーの発生時に既存の SMB ( CIFS )セッションが切断されます。

    注記 SMB プロトコルの性質上、すべての SMB セッションは中断されます( Continuous Availability プロパティが設定された共有に接続している 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 から 1 つずつ戻されます。ギブバックの進捗は、「 storage failover show-giveback 」コマンドで監視できます。

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

    各アグリゲートの I/O は、そのアグリゲートのギブバックが完了したあとに再開されます。これにより、アグリゲートの全体的な停止時間が短くなります。

テイクオーバーおよびギブバックに対する HA ポリシーの影響

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

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

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