自動テイクオーバーと自動ギブバックの仕組み
-
このドキュメント ページのPDF
-
ボリューム管理
- CLI を使用した論理ストレージ管理
-
NAS ストレージ管理
-
CLIを使用したSMBの管理
- SMB を使用したファイルアクセスの管理
-
CLIを使用したSMBの管理
- セキュリティとデータ暗号化
-
ボリューム管理
PDF版ドキュメントのセット
Creating your file...
自動テイクオーバー処理と自動ギブバック処理を組み合わせて使用することで、クライアントの停止を短くしたり回避したりできます。
デフォルトでは、 HA ペアの一方のノードでパニック、リブート、または停止が発生すると、パートナーノードに自動的にテイクオーバーされ、影響を受けたノードのリブート時にストレージが戻されます。その後、 HA ペアが通常の動作状態に戻ります。
自動テイクオーバーは、いずれかのノードが応答しなくなった場合にも実行されます。
自動ギブバックがデフォルトで実行されます。ギブバックによるクライアントへの影響を制御する場合は、自動ギブバックを無効にしてを使用します storage failover modify -auto-giveback false -node <node>
コマンドを実行します自動ギブバックは、トリガーされた状況に関係なく実行されます。パートナーノードでは、で制御される一定の時間待機します -delay- seconds
のパラメータ storage failover modify
コマンドを実行しますデフォルトの遅延は 600 秒です。ギブバックを遅らせることで、このプロセスでは短時間の停止が 2 回発生します。テイクオーバー時とギブバック時の 2 回です。
これにより、次の処理に必要な時間を含む 1 回の長時間の停止が回避されます。
-
テイクオーバー処理
-
テイクオーバーされたノードがブートし、ギブバック可能な状態になります
-
ギブバック処理
ルート以外のアグリゲートで自動ギブバックが失敗した場合、自動的にあと 2 回ギブバックが試行されます。
テイクオーバープロセスでは、パートナーノードがギブバック可能な状態になる前に自動ギブバックプロセスが開始されます。自動ギブバックプロセスの期限内にパートナーノードがギブバック可能な状態にならないと、タイマーがリスタートします。その結果、パートナーノードがギブバック可能な状態になってから実際にギブバックが実行されるまでの時間が自動ギブバック時間よりも短くなる可能性があります。 |
テイクオーバー時の動作
パートナーをテイクオーバーしたノードは、パートナーのアグリゲートとボリュームのデータを引き続き提供および更新します。
テイクオーバープロセスの実行中は次の手順が実行されます。
-
ユーザが開始したネゴシエートテイクオーバーの場合は、集約されたデータがパートナーノードからテイクオーバーを実行中のノードに移動されます。短時間の停止は、各アグリゲート(ルートアグリゲートを除く)の現在の所有者がテイクオーバーノードに切り替わったときに発生します。ただし、アグリゲートの再配置を伴わないテイクオーバーに比べると短時間で済みます。
パニック時のネゴシエートテイクオーバーは実行できません。 テイクオーバーが発生する原因としては、パニックに関連しない障害が考えられます。ノードとそのパートナー間の通信が失われると、障害が発生します(ハートビート損失とも呼ばれます)。障害が原因でテイクオーバーが発生した場合は、パートナーノードがハートビートの損失を検出するために時間がかかるため、停止時間が長くなる可能性があります。 -
進捗状況はを使用して監視できます
storage failover show‑takeover
コマンドを実行します -
を使用すると、このテイクオーバーインスタンスの実行中にアグリゲートの再配置を実行しないことができます
‑bypass‑optimization
パラメータとstorage failover takeover
コマンドを実行します計画的テイクオーバー処理では、クライアントの停止を最小限にするため、アグリゲートが順に再配置されます。アグリゲートの再配置を省略すると、計画的テイクオーバーの際のクライアントの停止時間が長くなります。
-
-
ユーザが開始したネゴシエートテイクオーバーの場合は、ターゲットノードが正常にシャットダウンされ、そのあとにルートアグリゲートと最初の手順で再配置されなかったアグリゲートのテイクオーバーが実行されます。
-
LIFのフェイルオーバールールに基づいて、ターゲットノードからテイクオーバーノード、またはクラスタ内の他のノードにデータLIF(論理インターフェイス)が移行されます。コマンドでパラメータを使用すると、LIFの移行を回避できます
‑skip‑lif-migration
storage failover takeover
。ユーザが開始したテイクオーバーの場合、ストレージのテイクオーバーの開始前にデータLIFが移行されます。パニックまたは障害が発生した場合、構成によっては、ストレージとともに、またはテイクオーバーの完了後にデータLIFが移行される可能性があります。 -
テイクオーバーの発生時に既存の SMB セッションが切断されます。
SMBプロトコルの性質上、すべてのSMBセッションが中断されます(Continuous Availabilityプロパティが設定された共有に接続している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 の 2 つのうち、どちらが割り当てられているかによって、 ONTAP がストレージフェイルオーバーおよびギブバック処理で使用するアグリゲートの制御順序が決まります。
CFO および SFO という用語は、ストレージフェイルオーバー(テイクオーバーとギブバック)処理を表すこともありますが、実際はアグリゲートに割り当てられる HA ポリシーのことを表しています。たとえば、 SFO アグリゲートや CFO アグリゲートという表現は、単にアグリゲートに割り当てられた HA ポリシーを指しています。
HA ポリシーは、テイクオーバー処理とギブバック処理に次のように影響します。
-
ONTAP システムで作成されたアグリゲート(ルートボリュームを含むルートアグリゲートを除く)には、 SFO の HA ポリシーが割り当てられます。手動で開始されたテイクオーバーでは、テイクオーバー前に SFO (ルート以外)アグリゲートをパートナーに順番に再配置することで、パフォーマンスが最適化されます。ギブバック処理では、テイクオーバーされたシステムがブートして管理アプリケーションがオンラインになり、ノードがアグリゲートを受け取れる状態になってから、アグリゲートが順番にギブバックされます。
-
アグリゲートの再配置処理では、アグリゲートのディスク所有権が再割り当てされ、ノードの制御がパートナーに移るため、 SFO の HA ポリシーが割り当てられたアグリゲートだけが再配置の対象になります。
-
ルートアグリゲートには常に CFO の HA ポリシーが割り当てられ、ギブバック処理の開始時にアグリゲートがギブバックされます。これは、テイクオーバーされたシステムをブートできるようにするために必要です。その他のすべてのアグリゲートは、テイクオーバーされたシステムのブートプロセスが完了して管理アプリケーションがオンラインになり、ノードがアグリゲートを受け取れる状態になってから、順番にギブバックされます。
アグリゲートの HA ポリシーを SFO から CFO に変更する処理はメンテナンスモードの処理です。この設定は、カスタマーサポート担当者から指示がないかぎり変更しないでください。 |
バックグラウンド更新がテイクオーバーとギブバックに与える影響
ディスクファームウェアのバックグラウンド更新による HA ペアのテイクオーバー、ギブバック、およびアグリゲートの再配置の処理に対する影響は、処理がどのように開始されたかによって異なります。
ディスクファームウェアのバックグラウンド更新によるテイクオーバー、ギブバック、およびアグリゲートの再配置に対する影響は次のとおりです。
-
いずれかのノードのディスクでディスクファームウェアのバックグラウンド更新を実行した場合、手動で開始したテイクオーバー処理は、そのディスクでディスクファームウェアの更新が完了するまで保留されます。ディスクファームウェアのバックグラウンド更新が 120 秒経っても完了しないと、テイクオーバー処理は中止され、ディスクファームウェアの更新の完了後に手動で再開する必要があります。でテイクオーバーが開始された場合
‑bypass‑optimization
のパラメータstorage failover takeover
コマンドをに設定します `true`デスティネーションノードでディスクファームウェアのバックグラウンド更新を実行していても、テイクオーバーには影響しません。 -
ソース(テイクオーバー)ノードのディスクでディスクファームウェアのバックグラウンド更新を実行中の場合、を使用してテイクオーバーが手動で開始されたとき
‑options
のパラメータstorage failover takeover
コマンドをに設定します `immediate`テイクオーバー処理がただちに開始されます。 -
ノードのディスクでディスクファームウェアのバックグラウンド更新を実行中の場合に、そのノードがパニック状態になると、パニック状態になったノードのテイクオーバーが開始されます。
-
いずれかのノードのディスクでディスクファームウェアのバックグラウンド更新を実行中の場合、データアグリゲートのギブバックは、そのディスクでディスクファームウェアの更新が完了するまで保留されます。
-
ディスクファームウェアのバックグラウンド更新が 120 秒経っても完了しないと、ギブバック処理は中止され、ディスクファームウェアの更新の完了後に手動で再開する必要があります。
-
いずれかのノードのディスクでディスクファームウェアのバックグラウンド更新を実行中の場合、アグリゲートの再配置処理は、そのディスクでディスクファームウェアの更新が完了するまで保留されます。ディスクファームウェアのバックグラウンド更新が 120 秒経っても完了しないと、アグリゲートの再配置処理は中止され、ディスクファームウェアの更新の完了後に手動で再開する必要があります。アグリゲートの再配置をで開始した場合
-override-destination-checks
のstorage aggregate relocation
コマンドをに設定します `true`デスティネーションノードでディスクファームウェアのバックグラウンド更新を実行していても、アグリゲートの再配置には影響しません。