Helix Coreサーバ管理者ガイド: 基本 (2019.1)

フェイルオーバー

フェイルオーバーとはスタンバイサーバが新しいマスターサーバまたはコミットサーバとして役割を引き継ぐプロセスです。

ヒント

スタンバイサーバのないレプリカおよびマスターの構成の場合は、ナレッジベースの記事「レプリカサーバにフェイルオーバーする」を参照してください。

高可用性と障害回復

フェイルオーバー機能は2つのシナリオをサポートします。

  • 高可用性(HA)
    • マスターはマスターサーバ、コミットサーバ、またはエッジサーバとして構成できます。

    • 通常、スタンバイサーバはマスターサーバと同じハードウェアラックに配置されます。

    • 標準的な使用例: 保守は定期的に行われますが、マスターハードウェアに障害が発生した場合も行われます。

    • マスターサーバは通常、フェイルオーバー処理に参加します。

      • マスターは規則的な方法で無効な状態になります

      • 残りのトランザクションによってデータがスタンバイにジャーナルコピーされるのを待機します

      • スタンバイサーバがマスターサーバの停止を許可します

      注意

      マスターサーバがフェイルオーバーに参加しない場合、フェイルオーバー先のスタンバイサーバにmandatoryオプションが設定されているか確認されます。マスターサーバが参加しない場合は、mandatoryスタンバイサーバにフェイルオーバーする必要があります。これにより、フェイルオーバーの発生後に他のレプリカサーバが新しいマスターサーバと整合した状態になります。実稼働環境では、すべてのmandatoryスタンバイサーバでメタデータをジャーナルコピーしてから、そのメタデータを他のレプリカに複製する必要があるため、整合した状態が確保されることになります。1台以上のmandatoryスタンバイサーバをマスターサーバに対してローカルに展開することをお勧めします。mandatoryスタンバイサーバのジャーナルコピーのパフォーマンスによっては、実稼働環境における他のレプリカへの複製が影響を受ける可能性があるためです。

  • 障害回復(DR)
    • 標準的な使用例: 突然の大災害のため、マスターサーバとそのHAスタンバイが稼働できない状態になります。
    • マスターサーバがアクセスできない状態にあるときに、mandatory以外のスタンバイサーバにフェイルオーバーする場合は、サポートにお問い合わせください。

ダウンストリームレプリカのフェイルオーバー時の整合性は、以下のように確保されます。

  • マスターサーバが参加する場合:
    • スタンバイサーバは「mandatory」スタンバイとなる必要はありません
    • スタンバイサーバのjournalcopypull -Lpull -uの各スレッドがフェイルオーバー処理に含まれます
  • マスターサーバが参加しないとき、スタンバイサーバが「mandatory」スタンバイである場合は、スタンバイサーバのpull -Lスレッドのみがフェイルオーバー処理に含まれます

正常なフェイルオーバーの前提条件

  • p4 failoverコマンドはstandbyまたはforwarding-standbyタイプのサーバで実行する必要があります。

  • フェイルオーバーの発生元のサーバは通常、マスターと呼ばれます。ただし、フェイルオーバーはstandardcommit-server、またはedge-serverの各サービスを提供するサーバでも発生します。
  • 新しいスタンバイサーバ(以前のマスターサーバまたはコミットサーバ)に対して、モニタリング機能(p4 monitor)が有効になっていることを確認します。
    • フェイルオーバーの処理中、journalcopypull -Lpull -uの各スレッドを終了する際に監視サブシステムが使用されるため、スタンバイサーバの起動時に監視機能が有効になっている状態でp4 failoverコマンドを実行する必要があります。

  • すべてのstandbyサーバとforwarding-standbyサーバのサーバ仕様のReplicatingFromフィールドに値が指定されていることを確認します。これにより、新しいマスターサーバのP4ROOTにあるstatefailoverファイルは、不要になった時点で自動的に削除されるようになります。

  • エッジサーバにフェイルオーバーする場合、エッジサーバのサービスユーザは、エッジサーバのスタンバイに定義されているP4TICKETS構成可能変数(またはP4TRUST構成可能変数)で指定されたファイルを使用してコミット(またはマスター)サーバにログインする必要があります。例えば、新しいマスターになるスタンバイサーバ上で次のコマンドを実行するとします。
    p4 -E P4TICKETS=directory/.p4tickets -p master:port -u service-user:login
  • フェイルオーバーの完了後、新しい役割に合わせてスタンバイサーバに適切なライセンスを付与する必要があります。

  • DNSエイリアスはマスターサーバのIPアドレスを指していることをお勧めします。これによって、同じDNSエイリアスが新しいマスターサーバ(以前のスタンバイサーバ)を指すことが可能になります。

スタンバイまたは転送スタンバイでフェイルオーバーする手順

フェイルオーバーを効率化する場合は、専用のstandbyの使用を検討します。

フェイルオーバーを迅速に完了する必要がない場合は、forwarding-standbyを使用するとハードウェアの費用を低減できます。

サーバ仕様のmandatoryオプションを使用した高可用性フェイルオーバー

重要

既存のインストール内の高可用性スタンバイを、最初に'mandatory'として展開しないでください。

複製の中断を最小限に抑えてスタンバイサーバを展開するには、スタンバイをmandatoryに設定する前に、新しいスタンバイサーバのjournalcopyのスレッドがジャーナルコピー元のサーバと整合性がとれていることを確認します。以下のプロセスを実行します。

  1. デフォルト設定のnomandatoryでスタンバイサーバを展開します
  2. スタンバイのジャーナルコピーの進行状況をモニターするには、スタンバイがジャーナルコピーを実行しているサーバ上で、p4 servers -Jを起動します

    この例では、master上でp4 servers -Jを起動して、standby2400で、master上の682の値とまだ一致していないことを確認します。

    その後、再びmasterで、つまりスタンバイがジャーナルコピーをコピーを実行しているサーバで、p4 servers -Jを再び起動します。
    この例では、standby2682に進み、これがmasterと一致するので、standby2に最新のジャーナルコピーがあることが示されます。


  3. standby2のサーバ仕様をmandatoryに指定するように変更します

    最も内側にあるマスターサーバ上で、standby2のサーバ仕様の[オプション]では、standby(またはforwarding-standby)サーバにmandatoryが適切になりました。このオプションを使用すると、すべてのmandatory standby(またはforwarding-standby)サーバのジャーナルコピーにコピーされていないメタデータがレプリカに作成されることはなくなります。

    マスターが使用できなかった場合、standby1はmandatoryのスタンバイではないため、フェイルオーバーには使用できません。

    マスターが使用できる場合は、4つのスタンバイサーバのすべてをフェイルオーバーに使用することができます。

注意

フェイルオーバーの発生元となるサーバが(マスターが有効な状態になっていないか-iオプションによって無視されているため)フェイルオーバーに参加していない場合、standby (またはforwarding-standby)サーバがmandatoryオプションを使用して適切に設定されていないと、p4 failoverコマンドの実行時にエラーが返ります。

サーバ仕様のnomandatoryオプションを使用した障害回復

障害回復フェイルオーバーの場合、リモートスタンバイは通常、サーバ仕様の[オプション]がデフォルトのnomandatoryに設定されています。mandatoryスタンバイのジャーナルコピーのパフォーマンスによっては、マスターのレプリカに複製する速度に影響する可能性があるためです。

データ損失の可能性

マスターが参加する場合 マスターが参加しない場合

 

スタンバイはmandatoryである必要があります。

フェイルオーバーの開始時に完了していなかったコマンドは、新しいマスターサーバで再度実行する必要がある場合があります。

データ損失は発生しません。

フェイルオーバーの発生前にマスター上で直接行われたトランザクションのうち、フェイルオーバーに使用されたスタンバイにジャーナルコピーされなかったトランザクションは失われます。

 

マスターサーバがフェイルオーバーに参加しない場合にデータ損失を最小限に抑えるには、フェイルオーバーに使用するスタンバイがフェイルオーバーの発生時点でマスターと最も整合性がとれている必要があります。マスターと同じラックに配置されているスタンバイが最も整合性がとれている可能性があります。

ダウンストリームレプリカでは新しいマスターサーバとの整合性が確保されます。

ダウンストリームレプリカでは新しいマスターサーバに関連したデータ損失は発生しません。

フェイルオーバー処理

スーパーユーザはフェイルオーバーの機能を使用して以下の操作を実行できます。

  1. フェイルオーバーが成功した後に問題が発生していないかどうかを示すレポートを取得します。
    警告

    既存のマスターサーバがまだアクセス可能であり、-iオプションの要求が無視されているとレポートに示された場合、2つのサーバが相互に認識していない状態で存在することになります。この「スプリットブレイン」が発生すると、矛盾が生じてデータの整合性が失われる可能性があります。

  2. フェイルオーバー処理を開始します。
    1. 新しいマスターとなるスタンバイ(または転送スタンバイ)サーバが自動的に停止します。

    2. フェイルオーバーの処理中、マスターサーバは新しいコマンドを処理せず、エンドユーザは「failoverMessage」を受信します(p4 failoverコマンドを参照してください)。

    3. 検証処理により、最新ファイルの内容が新しいマスターに適切に複製されたことが確認されます。p4 failoverコマンドの-vオプションを参照してください。

    4. フェイルオーバーの処理中、P4ROOTディレクトリに新しい名前のstatefailoverファイルが作成されます。このファイルはフェイルオーバーの直前にスタンバイによってジャーナルコピーされた最後の整合性ポイントです。このファイルは必要なくなると新しいマスターサーバによって削除されます。

      例えば、
      p4 failover
      を実行してプレビューが正しいことを確認してください。
      正しい場合は、
      p4 failover -y

      を実行しますServerIDファイルは、以前のマスターに変更されることに注意してください。

  3. 処理中に報告された手順を監視します。フェイルオーバーの処理中にエラーが発生すると、スーパーユーザに通知が送られ、フェイルオーバー処理が停止します。これにより、修正措置を行って新たに処理を試行できます。

  4. スタンバイサーバがマスターサーバを停止した後にエラーが発生した場合、スタンバイサーバはマスターサーバを再起動しません。

  5. フェイルオーバーが成功した後、p4 infoコマンドを発行して前のスタンバイ(または転送スタンバイ)が新しいマスターとして再起動されていることを検証し、ServerIDを確認してマスターサーバのServerIDがフェイルオーバーされていることを検証します。

  6. フェイルオーバーが成功した後、新しいマスターサーバを使用するためにサイト固有の変更を加える必要がある場合があります。ユーザおよびレプリカが新しいマスターサーバに接続するには、DNSの変更が必要になる場合があります。以下に例を示します。

    • DNSエイリアスセットアップがある場合、そのDNSエイリアスのIPアドレスを新しいマスターサーバまたはコミットサーバのIPアドレスを指すように更新します。
    • DNSエイリアスセットアップがない場合:
      • p4 configure show allserverコマンドおよび以下を発行して、各レプリカまたはエッジサーバのP4TARGET環境変数を変更します。
        p4 configure set "replica-name#P4TARGET=new-master-server:port-number"
      • p4 server servernameコマンドを発行し、正しいホスト名とポート番号を使用してサーバ仕様を更新します。

これでエンドユーザが新しいコマンドを発行できるようになります。

  • 影響を受ける構成可能変数

    フェイルオーバー処理:

    構成可能変数とエッジサーバ

    エッジ(または他のレプリカ)サーバからスタンバイサーバにフェイルオーバーする際、エッジサーバで更新された構成可能変数はコミットサーバで手動で変更する必要があります。更新された構成可能変数はコミット(またはアップストリーム)サーバに自動的に伝播されないためです。これはエッジサーバがフェイルオーバーに参加しているかどうかを問いません。