フェイルオーバー
フェイルオーバーとは、スタンバイサーバ(または転送スタンバイサーバ)が、標準サービス、コミットサーバサービス、またはエッジサーバサービスを実行するサーバに代わって稼働するプロセスのことです。 フェイルオーバー時にスタンバイサーバによって代行されるサーバのことを、通常は「マスターサーバ」といいます。
高可用性と障害回復
フェイルオーバー機能は2つのシナリオをサポートします。
- 高可用性(HA)
-
マスターはマスターサーバ、コミットサーバ、またはエッジサーバとして構成できます。
-
通常、スタンバイサーバはマスターサーバと同じハードウェアラックに配置されます。
-
標準的な使用例: 保守は定期的に行われますが、マスターハードウェアに障害が発生した場合も行われます。
-
マスターサーバは通常、フェイルオーバー処理に参加します。
-
マスターは規則的な方法で無効な状態になります
-
残りのトランザクションによってデータがスタンバイにジャーナルコピーされるのを待機します
-
スタンバイサーバがマスターサーバの停止を許可します
注意マスターサーバがフェイルオーバーに参加しない場合、フェイルオーバー先のスタンバイサーバにmandatoryオプションが設定されているか確認されます。 マスターサーバが参加しない場合は、mandatoryスタンバイサーバにフェイルオーバーする必要があります。これにより、フェイルオーバーの発生後に他のレプリカサーバが新しいマスターサーバと整合した状態になります。 実稼働環境では、すべてのmandatoryスタンバイサーバでメタデータをジャーナルコピーしてから、そのメタデータを他のレプリカに複製する必要があるため、整合した状態が確保されることになります。 1台以上のmandatoryスタンバイサーバをマスターサーバに対してローカルに展開することをお勧めします。 mandatoryスタンバイサーバのジャーナルコピーのパフォーマンスによっては、実稼働環境における他のレプリカへの複製が影響を受ける可能性があるためです。
-
-
- 障害回復(DR)
- 標準的な使用例: 突然の大災害のため、マスターサーバとそのHAスタンバイが稼働できない状態になります。
-
マスターサーバがアクセスできない状態にあるときに、mandatory以外のスタンバイサーバにフェイルオーバーする場合は、サポートにお問い合わせください。
ダウンストリームレプリカのフェイルオーバー時の整合性は、以下のように確保されます。
- マスターサーバが参加する場合:
- スタンバイサーバは「mandatory」スタンバイとなる必要はありません
- スタンバイサーバのjournalcopy、pull -L、pull -uの各スレッドがフェイルオーバー処理に含まれます
- マスターサーバが参加しないとき、スタンバイサーバが「mandatory」スタンバイである場合は、スタンバイサーバのpull -Lスレッドのみがフェイルオーバー処理に含まれます
正常なフェイルオーバーの前提条件
-
p4 failoverコマンドは、standbyタイプまたはforwarding-standbyタイプのサーバで実行する必要があります。 詳細については、「スタンバイサーバと転送スタンバイサーバ」を参照してください。
- スタンバイサーバ(または転送スタンバイサーバ)をフェイルオーバーで使用するには、適切なライセンスが必要になります。 そのため、サーバ複製リクエストを送信することをお勧めします。
- 新しいスタンバイサーバ(以前のマスターサーバまたはコミットサーバ)に対して、モニタリング機能(p4 monitor)が有効になっていることを確認します。
フェイルオーバーの処理中、journalcopy、pull -L、pull -uの各スレッドを終了する際に監視サブシステムが使用されるため、スタンバイサーバの起動時に監視機能が有効になっている状態でp4 failoverコマンドを実行する必要があります。
-
それぞれのstandbyサーバとforwarding-standbyサーバでサーバ仕様を開き、 ReplicatingFromフィールドにマスターサーバのP4PORTの値を入力します。 これにより、新しいマスターサーバのP4ROOTにあるstatefailoverファイルは、不要になった時点で自動的に削除されるようになります。
- エッジサーバにフェイルオーバーする場合、エッジサーバのサービスユーザは、エッジサーバのスタンバイに定義されているP4TICKETS構成可能変数(またはP4TRUST構成可能変数)で指定されたファイルを使用してコミット(またはマスター)サーバにログインする必要があります。 例えば、新しいマスターになるスタンバイサーバ上で次のコマンドを実行するとします。
p4 -E P4TICKETS=directory/.p4tickets -p master:port -u service-user:login - DNSエイリアスはマスターサーバのIPアドレスを指していることをお勧めします。 これによって、同じDNSエイリアスが新しいマスターサーバ(以前のスタンバイサーバ)を指すことが可能になります。
- フェイルオーバー処理が必要かどうかを判断しなければならない場合に備えて、ハートビートでのトリガ(サーバの応答性)を設定してターゲットサーバをモニタリングすることをお勧めします。
- スタンバイサーバのないレプリカおよびマスターの構成の場合は、ナレッジベースの記事「レプリカサーバにフェイルオーバーする」を参照してください。
スタンバイサーバまたは転送スタンバイサーバへのフェイルオーバー
通常、forwarding-standbyタイプのサーバにフェイルオーバーするよりも、standbyタイプの専用サーバにフェイルオーバーする方が処理速度が上がります。 フェイルオーバーにかかる時間がそれほど重要ではない場合は、forwarding-standbyタイプのサーバにフェイルオーバーすることをお勧めします。 詳細については、『Helix Core P4コマンドリファレンス』の「p4 server」の「standby」と「forwarding standby」を参照してください。
サーバ仕様のmandatoryオプションを使用した高可用性フェイルオーバー
複製の中断を最小限に抑えてスタンバイサーバを展開するには、スタンバイをmandatoryに設定する前に、新しいスタンバイサーバのjournalcopyのスレッドがジャーナルコピー元のサーバと整合性がとれていることを確認します。 以下のプロセスを実行します。
- デフォルト設定のnomandatoryでスタンバイサーバを展開します
- スタンバイのジャーナルコピーの進行状況をモニターするには、スタンバイがジャーナルコピーを実行しているサーバ上で、p4 servers -Jを起動します
この例では、master上でp4 servers -Jを起動して、standby2は400で、master上の682の値とまだ一致していないことを確認します。
その後、再びmasterで、つまりスタンバイがジャーナルコピーを実行しているサーバで、p4 servers -Jを再び起動します。
この例では、standby2が682に進み、これがmasterと一致するので、standby2に最新のジャーナルコピーがあることが示されます。 - standby2のサーバ仕様をmandatoryに指定するように変更します
最も内側にあるマスターサーバ上で、standby2のサーバ仕様の[オプション]では、standby(またはforwarding-standby)サーバにmandatoryが適切になりました。 このオプションを使用すると、すべてのmandatory standby(またはforwarding-standby)サーバのジャーナルコピーにコピーされていないメタデータがレプリカに作成されることはなくなります。
マスターが使用できなかった場合、standby1はmandatoryのスタンバイではないため、フェイルオーバーには使用できません。
マスターが使用できる場合は、4つのスタンバイサーバのすべてをフェイルオーバーに使用することができます。
フェイルオーバーの発生元となるサーバが(マスターが有効な状態になっていないか-iオプションによって無視されているため)フェイルオーバーに参加していない場合、standby (またはforwarding-standby)サーバがmandatoryオプションを使用して適切に設定されていないと、p4 failoverコマンドの実行時にエラーが返ります。
サーバ仕様のnomandatoryオプションを使用した障害回復
障害回復フェイルオーバーの場合、リモートスタンバイサーバのサーバ仕様のOption:
フィールドは通常、デフォルト値のnomandatoryに設定されています。 mandatoryスタンバイのジャーナルコピーのパフォーマンスによっては、マスターのレプリカに複製する速度に影響する可能性があるためです。
データ損失の可能性
マスターサーバがフェイルオーバーに参加する場合
-
フェイルオーバーの開始時に完了していなかったコマンドは、新しいマスターサーバで再度実行する必要がある場合があります。
- データ損失は発生しません。
マスターサーバがフェイルオーバーに参加しない場合
- スタンバイはmandatoryである必要があります。
-
フェイルオーバーの開始時に完了していなかったコマンドは、新しいマスターサーバで再度実行する必要がある場合があります。
- フェイルオーバーの発生前にマスター上で直接行われたトランザクションのうち、フェイルオーバーに使用されたスタンバイにジャーナルコピーされなかったトランザクションは失われます。
-
データの損失を最小限に抑えるには、フェイルオーバー発生時にマスターサーバと最も整合性がとれているサーバをスタンバイサーバとして使用する必要があります。 通常は、マスターサーバと同じラックに配置されているサーバをスタンバイサーバとして使用します。
-
ダウンストリームレプリカでは新しいマスターサーバとの整合性が確保されます。
-
ダウンストリームレプリカでは新しいマスターサーバに関連したデータ損失は発生しません。
-
フェイルオーバー処理
スーパーユーザはフェイルオーバーの機能を使用して以下の操作を実行できます。
- フェイルオーバーが成功した後に問題が発生していないかどうかを示すレポートを取得します。警告
既存のマスターサーバがまだアクセス可能であり、-iオプションの要求が無視されているとレポートに示された場合、2つのサーバが相互に認識していない状態で存在することになります。 この「スプリットブレイン」が発生すると、矛盾が生じてデータの整合性が失われる可能性があります。
- フェイルオーバー処理を開始します。
新しいマスターとなるスタンバイ(または転送スタンバイ)サーバが自動的に停止します。
フェイルオーバーの処理中、マスターサーバは新しいコマンドを処理せず、エンドユーザは「failoverMessage」を受信します(p4 failoverコマンドを参照してください)。
検証処理により、最新ファイルの内容が新しいマスターに適切に複製されたことが確認されます。 p4 failoverコマンドの-vオプションを参照してください。
フェイルオーバーの処理中、P4ROOTディレクトリに新しい名前のstatefailoverファイルが作成されます。 このファイルはフェイルオーバーの直前にスタンバイによってジャーナルコピーされた最後の整合性ポイントです。 このファイルは必要なくなると新しいマスターサーバによって削除されます。
例えば、
p4 failover
を実行してプレビューが正しいことを確認してください。
正しい場合は、
p4 failover -y を実行します
-
処理中に報告された手順を監視します。 フェイルオーバーの処理中にエラーが発生すると、スーパーユーザに通知が送られ、フェイルオーバー処理が停止します。これにより、修正措置を行って新たに処理を試行できます。
-
スタンバイサーバがマスターサーバを停止した後にエラーが発生した場合、スタンバイサーバはマスターサーバを再起動しません。
-
フェイルオーバーが正常に完了したら、元のスタンバイサーバ(または元の転送スタンバイサーバ)が新しいマスターサーバとして稼働しているかどうかを確認します。これを行うには、p4 infoコマンドを実行し、新しいマスターサーバのServerIDの値が、元のマスターサーバのServerIDと同じになっているかどうかを確認します。
-
フェイルオーバーが成功した後、新しいマスターサーバを使用するためにサイト固有の変更を加える必要がある場合があります。 ユーザおよびレプリカが新しいマスターサーバに接続するには、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コマンドを発行し、正しいホスト名とポート番号を使用してサーバ仕様を更新します。
これでエンドユーザが新しいコマンドを発行できるようになります。
フェイルオーバー後のフェイルバックに記載されている手順を実行して、元の構成に戻すことができます。
-
影響を受ける構成可能変数
フェイルオーバー処理:
- 元のマスターサーバの構成可能変数に対して変更を加えません
- 新しい環境に適した値になるように、新しいマスターサーバの以下の構成可能変数を変更することができます。
client.readonly.dir P4AUDIT client.sendq.dir P4JOURNAL journalPrefix P4LOG pull.trigger.dir P4TICKETS server.depot.root P4TRUST server.locks.dir P4ROOT statefile
構成可能変数とエッジサーバ
エッジ(または他のレプリカ)サーバからスタンバイにフェイルオーバーする際、エッジサーバで更新された構成可能変数はコミットサーバで手動で変更する必要があります。 更新された構成可能変数はコミット(またはアップストリーム)サーバに自動的に伝播されないためです。これはエッジサーバがフェイルオーバーに参加しているかどうかを問いません。