自動フェイルオーバーの概要

DSE OpsCenterのプライマリ・インスタンスからバックアップ・インスタンスへの自動フェイルオーバーを使用すると、手動介入やダウンタイムに煩わされることなく高い可用性が実現します。

address.yaml

address.yamlファイルの場所は、インストールのタイプによって異なります。
  • パッケージ・インストール:/var/lib/datastax-agent/conf/address.yaml
  • tarボール・インストール:install_location/conf/address.yaml

opscenterd.conf

opscenterd.confファイルの場所は、インストールのタイプによって異なります。
  • パッケージ・インストール:/etc/opscenter/opscenterd.conf
  • tarボール・インストール:install_location/conf/opscenterd.conf

自動フェイルオーバーを使用すると、DataStax Enterprise(DSE)クラスターで重要なデータを管理する際に、手動介入やダウンタイムに煩わされることなく、OpsCenterの高い可用性を維持できます。

現在、OpsCenterのアクティブ-パッシブ構成では、1つのプライマリ・インスタンスに対して1つのバックアップ・インスタンスを使用できます。OpsCenterフェイルオーバーの有効化ベスト・プラクティス・ルールでは、フェイルオーバーを有効にすることを推奨しています。バックアップが構成されていないと、ルールは失敗し、アラートが送信されます。フェイルオーバーを有効にすると、次回の実行時に正しく構成されたバックアップのOpsCenterインスタンスが検出された場合にベスト・プラクティス・ルールは合格します。
注: 自動フェイルオーバーを有効にした後でDataStax Enterprise以外のクラスター(DataStax Communityやオープン・ソースのCassandraなど)を追加すると、自動フェイルオーバーが機能しないことを伝えるアラートが発行され、OpsCenterのバックアップ・インスタンスはシャットダウンします。

フェイルオーバーの動作

OpsCenterのプライマリ・インスタンスとバックアップ・インスタンスは、stompチャネルでハートビート・メッセージの送信とリッスンを行って、相互にステータスを伝えます。OpsCenterプライマリ・インスタンスは、OpsCenterバックアップ・インスタンスが構成されているかどうかにかかわらず、ハードビート・メッセージを送信します。OpsCenterプライマリ・インスタンスは、ハートビート応答のstompチャネルのメッセージをリッスンして、バックアップ・インスタンスが構成されているかどうかを判断します。OpsCenterバックアップ・インスタンスで作成したprimary_opscenter_location構成ファイルには、OpsCenterバックアップ・インスタンスが監視するOpsCenterプライマリ・インスタンスのIPアドレスが含まれています。

構成されたOpsCenterバックアップ・インスタンスはOpsCenterプライマリ・インスタンスのハートビート・メッセージをリッスンして、OpsCenterプライマリ・インスタンスが稼働しているかどうかを判断します。OpsCenterバックアップ・インスタンスによって、構成された時間枠(デフォルトでは60秒)の間にOpsCenterプライマリ・インスタンスのハートビートが検出されなかった場合、OpsCenterバックアップ・インスタンスはフェイルオーバー・プロセスを開始し、OpsCenterプライマリ・インスタンスの役割を自動的に引き継ぎます。OpsCenterバックアップ・インスタンスは、障害が発生したプライマリ・インスタンスの代わりにバックアップ・インスタンスに接続できるようにaddress.yaml で自動的にstomp_interfaceを変更して、エージェントを自動的に再構成します。
警告: サードパーティの構成管理によってaddress.yaml が管理されていないことを確認してください。フェイルオーバー時に、OpsCenterは自動的に、address.yamlstomp_interfaceがOpsCenterバックアップ・インスタンスを指すように変更します。別の構成管理システムがaddress.yamlを管理している場合、構成管理システムが次回の更新をプッシュすると、その変更が元に戻る可能性があります。

フェイルオーバーからの復元

フェイルオーバーが発生したあと、プライマリを引き継いだ元のOpsCenterバックアップ・インスタンスはOpsCenterプライマリ・インスタンスになったまま維持されます。この時点でprimary_opscenter_locationファイルを作り直して、別のOpsCenterバックアップ・インスタンスを構成します。このファイルでは、新しいバックアップ・インスタンスが監視対象のプライマリ・インスタンスのIPアドレスを指すように指定します。元のOpsCenterプライマリ・インスタンスを新しいバックアップ・インスタンスとして構成する場合は、サーバーを再起動する前に、このサーバーが正常であることを再度確認します。

注: ネットワーク分割が原因でフェイルオーバーが発生した場合、元のOpsCenterプライマリ・インスタンスを手動でシャットダウンし、ネットワーク接続が復旧したら別のバックアップ・インスタンスを構成する必要があります。起動すると、OpsCenterの各インスタンスで一意のID(uuid)が生成され、failover_idファイルに格納されます。ネットワーク分割が発生すると、failover_idにより、エージェントに対して各OpsCenterが一意に識別され、両方のOpsCenterインスタンスがフェイルオーバー後に動作してデータが破損するのを防ぎます。failover_idファイルの場所は、インストールのタイプによって異なり、構成可能です。

フェイルオーバーの影響

自動フェイルオーバーの後、フェイルオーバーの根本原因やその時点でのプロセスの進行状況に応じて異なりますが、復元に必要な手動介入(ある場合)はごくわずかです。一般に、フェイルオーバーの影響は、OpsCenterを再起動したときと似ていますが、いくつかの点が明らかに異なります。
  • アラート - 通常どおりにトリガーされます。例外として、フェイルオーバーの時間枠内にアラートが発行または解除された場合、アラートはトリガーされません。
  • 認証 - 既存のユーザー・セッションからログアウトします。ユーザー・セッションは維持されません。再度ログインする必要があります。
  • バックアップ - フェイルオーバーの時間内に失敗したスケジュール・バックアップをスキップします。バックアップは次にスケジュールされている日時まで行われません。
  • 復元 - 復元中にフェイルオーバーが発生しても、復元操作は続行されます。ただし復元が発生したことをOpsCenterバックアップ・インスタンスは認識していないため、復元の結果を伝えることはできません。
  • リペア・サービス - 前回保存された状態から再開します。忘れずにRepair Service(リペア・サービス)のディレクトリーのミラーリングを行ってください。OpsCenterインスタンスの障害が現在任意のノードで実行されているリペアに影響を及ぼすことはありません。自動フェイルオーバーが正常に完了するか、障害が発生したOpsCenterインスタンスが再度稼働するまで、新たなリペアは継続されません。
  • プロビジョニング - プライマリのLifecycle Managerがプライマリ・インスタンスで完了できなかった場合、またはその可能性がある場合、進行中だったジョブをプロビジョニングします。Lifecycle ManagerがOpsCenterバックアップ・インスタンスで自動的にジョブを再開することはありませんが、手動で再度ジョブを実行することで、ジョブを完了まで進めることができます。

フェイルオーバーのトラブルシューティング

ほとんどの場合、OpsCenterバックアップ・インスタンスはフェイルオーバーの動作で説明しているようにフェイルオーバー後のエージェントの再構成のために正しいIPアドレスを選択します。何らかの理由で、すべてのエージェントを更新するために、正しくないIPアドレスが自動的に選択されない場合、OpsCenterバックアップ・インスタンス上のopscenterd.conf 内のreport_interfaceプロパティが明示的に設定されます。
注: この回避策は、スニッチがEc2MultiRegionSnitchではないことを前提としています。

OpsCenterアップグレード時のフェイルオーバー

フェイルオーバーが構成されている場合、OpsCenterのアップグレード時に従うべき推奨プロセスがあります。詳細については、フェイルオーバーが有効な場合のDSE OpsCenterのアップグレードを参照してください。