自動テイクオーバーと自動ギブバックの仕組み
変更を提案
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`使用すると、LIFの移行を回避できます `-skip-lif-migration。ユーザが開始したテイクオーバーの場合、ストレージのテイクオーバーの開始前にデータLIFが移行されます。パニックまたは障害が発生した場合、構成によっては、ストレージとともに、またはテイクオーバーの完了後にデータLIFが移行される可能性があります。 -
テイクオーバーの発生時に既存のSMBセッションが切断されます。
SMBプロトコルの性質上、すべてのSMBセッションが中断されます（Continuous Availabilityプロパティが設定された共有に接続しているSMB 3.0セッションを除く）。SMB 1.0およびSMB 2.xセッションでは、テイクオーバー後に開いているファイルハンドルを再接続できません。そのため、テイクオーバーの際に停止が発生し、一部のデータが失われる可能性があります。 -
継続的な可用性が有効になっている共有に対するSMB 3.0セッションは、テイクオーバー後に切断された共有に再接続できます。サイトでMicrosoft Hyper-VへのSMB 3.0接続を使用していて、関連付けられている共有で継続的な可用性プロパティが有効になっている場合、テイクオーバーはそれらのセッションで無停止で実行されます。
テイクオーバーを実行中のノードがパニック状態になった場合の動作
テイクオーバーを実行中のノードが、テイクオーバーを開始してから60秒以内にパニック状態になると、次のような状況が発生します。
-
パニックが発生したノードがリブートします。
-
リブート後、ノードは自己リカバリ処理を実行し、テイクオーバーモードではなくなります。
-
フェイルオーバーが無効になります。
-
パートナーの一部のアグリゲートをまだ所有している場合は、ストレージフェイルオーバーを有効にしたあとに、コマンドを使用してそれらのアグリゲートをパートナーに戻します
storage failover giveback。
ギブバック時の動作
問題が解決されたとき、パートナーノードがブートしたとき、またはギブバックが開始されたときに、ローカルノードからパートナーノードに所有権が戻されます。
通常のギブバック処理では次のプロセスが実行されます。ここでは、ノードAがノードBをテイクオーバーしたものとします。ノードBの問題は解決されており、データの提供を再開できる状態になっています。
-
ノードBの問題が解決され、次のメッセージが表示されます。
Waiting for giveback -
コマンドまたは自動ギブバック（設定されている場合）でギブバックが開始され `storage failover giveback`ます。これにより、ノードBのアグリゲートおよびボリュームの所有権をノードAからノードBに戻すプロセスが開始されます。
-
ノードAからルートアグリゲートの制御が最初に返されます。
-
ノードBを通常の動作状態でブートするプロセスが完了します。
-
ノードBのブートプロセスでルート以外のアグリゲートを受け取れる状態になった時点で、すぐに他のアグリゲートの所有権が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`をに設定し `true`てテイクオーバーを開始した `-bypass-optimization`場合は、デスティネーションノードでディスクファームウェアのバックグラウンド更新を実行していても、テイクオーバーには影響しません。
-
ソース（テイクオーバー）ノードのディスクでディスクファームウェアのバックグラウンド更新を実行中の場合、コマンドのパラメータを `storage failover takeover`に設定して `immediate`手動で開始したテイクオーバー `-options`処理はすぐに開始されます。
-
ノードのディスクでディスクファームウェアのバックグラウンド更新を実行中の場合、そのノードがパニック状態になると、パニック状態になったノードのテイクオーバーがただちに開始されます。
-
いずれかのノードのディスクでディスクファームウェアのバックグラウンド更新を実行中の場合、データアグリゲートのギブバックは、そのディスクでディスクファームウェアの更新が完了するまで保留されます。
-
ディスクファームウェアのバックグラウンド更新が120秒経っても完了しないと、ギブバック処理は中止され、ディスクファームウェアの更新の完了後に手動で再開する必要があります。
-
いずれかのノードのディスクでディスクファームウェアのバックグラウンド更新を実行中の場合、アグリゲートの再配置処理は、そのディスクでディスクファームウェアの更新が完了するまで保留されます。ディスクファームウェアのバックグラウンド更新が120秒経っても完了しないと、アグリゲートの再配置処理は中止され、ディスクファームウェアの更新の完了後に手動で再開する必要があります。コマンドの `storage aggregate relocation`をに設定し `true`てアグリゲートの再配置を開始した場合 `-override-destination-checks`は、デスティネーションノードでディスクファームウェアのバックグラウンド更新を実行していても、アグリゲートの再配置には影響しません。