Geo 冗長性スイッチオーバー

この章は次のトピックで構成されています。

スイッチオーバーの概要

スイッチオーバーは、障害発生時にアクティブクラスタとスタンバイクラスタのロールを交換するプロセスです。障害時に、システムは複数の予備チェック(ハートビート数、接続チェック、HTTP および SSH のログインチェック)を実行し、これらのチェックのいずれかが失敗した場合はアラームを発生させます。

スイッチオーバーは、自動または手動で実行できます。自動スイッチオーバーは、自動調停設定を使用して有効になります。

手動のスイッチオーバーでは、アラームが発生した場合、スイッチオーバーを開始する前に、両方のクラスタをチェックしてアラームの真正性を確認する必要があります。


注目


  • スイッチオーバー操作が(同期操作の前に)スタンバイ VM で完了した場合、テクニカルサポートジョブの [詳細情報の公開(Publish Details)] に行またはエントリは表示されません。これは、テクニカルサポート履歴が ETCD に書き込まれ、Geo 冗長設定全体では同期されないために発生します。これは想定されているシステム動作です。

  • AZ1 でプロビジョニングされるすべてのサービスは、ライブ非同期レプリケーションによって AZ2 に継続的に同期されます。

  • トポロジはゼロからではなく再同期によって構築されるため、スイッチオーバー後は AZ2 でより迅速に検出されます。

  • スイッチオーバー操作の後、オンデマンド同期操作を実行する必要があります。そうしないと、Postgres および Timescale データストアに不正確な状態情報が表示される可能性があります。

  • 単一の VM 展開のセットアップにおける Geo 冗長性のスイッチオーバー中に、依存システムリソース(Postgres データベースなど)が使用できなくなると、サービスの可用性における最大 5 分の追加の遅延が発生する可能性があります。単一の VM 展開のシナリオは、サービスを手動で再起動しない限り、2 番目のサービスのスタートアップを試行できるセカンダリ HA インスタンスがないため、この問題に特に影響を受けます。

  • 最後の同期操作後に新しいアプリケーションがインストールされた場合は、スイッチオーバーを開始する前に新しい同期を実行する必要があります。

  • L2 リンク検出には、Geo 冗長性スイッチオーバー中に拡張システムで最大 2 時間かかる場合があります。

  • スイッチオーバー後、クライアントが以前のアクティブクラスタによって発行された JWTトークンで認証しようとすると、403(「キーが認証されていません」)エラーが表示されます。クライアントは、正常に再接続するために、現在のアクティブクラスタから新しい JWTトークンを取得する必要があります。


スイッチオーバーのトリガー

スイッチオーバーは、手動による介入やシステムの障害など、さまざまなイベントによってトリガーされます。スイッチオーバープロセスを開始する主なトリガーは次のとおりです。

オンデマンドスイッチオーバー

これは、ユーザーがスイッチオーバープロセスをトリガーすることを手動で決定したときに発生します。

クラスタノード障害

これは、マルチクラスタセットアップで 2 つ以上のハイブリッドノードに障害が発生して、スイッチオーバーをトリガーした場合に発生します。

Crosswork Data Gateway の障害

Crosswork Network Controller は、アクティブクラスタ内の Data Gateway の動作状態を継続的に監視およびポーリングします。アクティブクラスタ内のすべての Data Gateway が 30 分以上または設定された調停期間エラー状態のままになっている場合、Crosswork Network Controller は自動スイッチオーバーをトリガーします。このメカニズムには、エラー状態になっている場合、メンテナンスモードの Data Gateway も含まれます。

Crosswork はスケジュールされた時間にのみ Data Gateway ステータスをポーリングするため、ポーリングサイクルの直前または後に発生する障害の検出を見逃したり、遅延したりする可能性があります。遅延、考慮事項、および遅延検出で発生するアラームの詳細については、 Data Gateway の障害による考慮事項、条件、およびアラームのトリガーを参照してください。

調停期間は、調停期間 API を使用して設定されます。API の詳細については、Cisco DevNet を参照してください。

Data Gateway の障害による考慮事項、条件、およびアラームのトリガー

主な考慮事項

  • 調停期間は、デフォルトで 30 分です。

  • Data Gateway の正常性は、ポーリング間隔でのみ評価されます。

  • Data Gateway ステータスの変更は、設定されているポーリング間隔および調停期間外に発生した場合、即時検出またはスイッチオーバーをトリガーしない場合があります。

  • メンテナンスモードの Data Gateway は、スイッチオーバーの対象と見なされます。

エッジケースでの検出の遅延

Crosswork は、スケジュールされたポーリング間隔中にのみ、Data Gateway の正常性を評価します。検出基準が満たされると、スイッチオーバーがトリガーされます。たとえば、アクティブな可用性ゾーン内のすべての Data Gateway が調停期間中にエラー状態のままになっている場合などです。ただし、Data Gateway の状態変更とポーリングサイクル間のタイミングの不一致による検出は次のようになります。

  • ポーリングの直前に Data Gateway に障害が発生している場合:

    • シナリオ:ポーリングが開始される直前に、Data Gateway はエラー状態に遷移します。

    • 例:Data Gateway は午後 9 時 59 分にエラー状態になりますが、ポーリングは午後 10 時にスケジュールされています。

    • 結果:Crosswork は、ポーリング開始時に 30 分間の調停期間を満たしていないため、これらの Data Gateway がスイッチオーバー用であるとは見なしません。

  • ポーリング直後に Data Gateway に障害が発生している場合:

    • シナリオ:ポーリングが開始された直後に、Data Gateway はエラー状態に遷移します。

    • 例:ポーリングは午後 10 時に行われ、Data Gateway は午後 10 時 5 分にエラー状態になります。

    • 結果:Crosswork は、30 分の調停期間を満たしていないため、次のポーリングサイクルまでこれらの Data Gateway を障害として検出しません。

Data Gateway のアラーム

Crossswork Network Controller が Geoスイッチオーバーをトリガーしようとしていることを示す重大アラームが発生します。アラームは手動でクリアする必要があります。


(注)  


アラームは各可用性ゾーン(AZ)に対してローカルであり、AZ 間で共有されません。

自動調停ワークフロー

このトピックでは、自動スイッチオーバープロセスの手順の概要について説明します。自動調停の詳細については、 Crosswork Network Controller の自動調停を参照してください。

  1. 自動調停は、調停設定で有効になっています。詳細については、クロスクラスタの設定 を参照してください。

  2. ハートビートと障害検出の間隔が設定されます。

  3. リーダー選出プロセスが開始され、クラスタの 1 つがリーダーとして選出されます。

  4. 自動スイッチオーバーは、システムでスイッチオーバーイベントが発生したときにトリガーされます(障害検出間隔を超えてその状態が続いている場合)。


(注)  


自動調停モードでは、各クラスタまたは可用性ゾーンに、システムを個別に監視する 2 つのピアがあります。アクティブクラスタで障害が発生すると、両方のピアがイベントを検出し、それぞれがスイッチオーバー要求を開始します。スプリットブレインシナリオを防ぐために単一の決定権限者として機能するリーダーは、両方の要求を受け取りますが、設計上、最初の要求のみを処理し、2 番目の要求は無視します。両方の要求はトラッキングのために記録されるため、重複しているように見えるスイッチオーバー要求の存在は、実際には予想される動作です。


手動でのスイッチオーバーの実行

Crosswork Network Controller UI でスイッチオーバーを実行するには、次の手順を実行します。

始める前に

両方のクラスタで同じアプリケーションバージョンとリソースフットプリントが使用されていることを確認します。

手順


ステップ 1

スタンバイクラスタにログインします。

ステップ 2

メインメニューから、[管理(Administration)] > [クロスクラスタ(Cross Cluster)] を選択します。[クロスクラスタ(Cross Cluster)] ウィンドウが表示されます。

ステップ 3

スイッチオーバーは、これらのオプションのいずれかを使用して実行できます。

  • [アクション(Actions)] > [スイッチオーバー(Switchover)] をクリックし、スイッチオーバーを開始します。これは、スイッチオーバープロセスの 3 つの手順を実行するワンクリックコントロールです。2 つのロールの設定と DNS の更新を 1 つの機能で自動化します。

    このシステムは、リーダーとして機能するクラスタにスイッチオーバー要求を転送し、スイッチオーバージョブを作成します。ジョブの進行状況を監視するには、[クロスクラスタジョブ(Cross cluster jobs)] タブをクリックします。

  • [アクション(Actions)] > [クラスタロールの設定(Set cluster role)] をクリックします。このオプションを使用すると、クラスタのロールを手動で割り当てることができます。

    重要

     

    [クラスタロールの設定(Set cluster role)] オプションは、自動スイッチオーバープロセス中にクラスタが応答しなくなり、両方のクラスタが同じステータスになる場合に特に役立ちます。この場合、[クラスタロールの設定(Set cluster role)] オプションを使用してスイッチオーバープロセスをオーバーライドし、クラスタロールを手動で割り当てることができます。

    1. [クラスタロールの切り替え(Switch Cluster Role)] ダイアログボックスが表示され、クラスタの初期状態が示されます。このトピックでは、Bengaluru クラスタ(cluster-sjc)はアクティブ状態で、San Jose クラスタ(cluster-nyc)はスタンバイ状態です。

      図 1. クラスタロールの切り替え
    2. San Jose クラスタをクリックして、アクティブ状態に変更します。[保存(Save)] をクリックして変更を確定します。

      図 2. スタンバイクラスタのアクティブへの切り替え
    3. 新しいアクティブクラスタを指すように、管理 FQDN とデータ FQDN の DNS サーバーレコードを更新します。

    4. ここで Bengaluru クラスタ(すでにアクティブ)にログインします。[クロスクラスタ(Cross Cluster)] ウィンドウで、[アクション(Actions)] > [クラスタロールの設定(Set cluster role)] をクリックします。

      (注)  

       

      この時点では、クラスタの状態を変更するまで、両方のクラスタがアクティブ状態になります。

    5. [クラスタロールの切り替え(Switch Cluster Role)] ダイアログボックスで、クラスタをクリックしてスタンバイ状態に変更します。

      図 3. アクティブクラスタのスタンバイへの切り替え

      [保存(Save)] をクリックして変更を確定します。

      (注)  

       

      デバイスの到達可能性がコンバージするのを待ってから、スタンバイクラスタでの操作を再開します。

    6. 数分後、最初のクラスタにログインします。スイッチオーバーが完了します。

ステップ 4

スイッチオーバー後、次のことを確認してください。

  1. クラスタの正常性とデバイスのステータスを確認して、システムが正常に機能していることを確認します。

  2. Crosswork Data Gateway の正常性ステータスをチェックして、正常に機能していることを確認します。

  3. HA プールのステータスをチェックします。

  4. 収集ステータスをチェックし、トラフィックが新しくアクティブになったクラスタにスムーズに流れていることを確認します。


スイッチオーバー後の Crosswork Optimization Engine のライセンス数

Crosswork Optimization Engine の場合、[スマートライセンス(Smart Licenses)] ページには、スイッチオーバー後 24 時間後または午前 1 時までに正しいライセンス数が反映されます。

24 時間後または午前 1 時まで待てない場合は、次の 2 つの方法でライセンスを強制的に更新できます。

  • 機能パック(オンデマンド帯域幅、回線型マネージャ、またはローカル輻輳マネージャ)を無効または有効にする。

  • デバイスを切り離して再度追加する。