ノードのフェイルオーバはクラスタのパフォーマンスを低下させる可能性を秘めているため、フェイルオーバの状況を処理する最善の方法を検討する必要があります。自動フェイルオーバを使用すると、ユーザの介入なしで、ノード障害の原因となった問題の知識や識別なしにクラスタがノードをフェールオーバできることを意味します。それでもまだ、正常な状態にクラスタを戻すためにリバランスを開始する必要があります。
クラスタを管理するために手動でのフェイルオーバを選択する場合、クラスタを監視し、問題の発生を識別する必要があります。問題が発生した場合、手動でのフェイルオーバとリバランスの操作を開始します。より多くの監視や手動での対話的操作を必要としますが、フェールオーバとリバランスを開始する前にクラスタやデータのアクセスが低下する可能性があります。
次のセクションでは、2つの選択肢とその問題点をより詳細に説明します。
分散システムでの自動的なコンポーネントの障害復旧は、問題を引き起こす可能性があります。障害の原因を特定できず、残りのシステムに置かれる負荷を理解していない場合、自動フェイルオーバは解決するために設計されているものよりも多くの問題を引き起こす可能性があります。問題につながる可能性がある状況の一部が含まれます：
フェイルオーバによる連鎖反応(Thundering Herd)の回避
5ノードのCouchbase Serverクラスタがネットワーク負荷の観点から80-90%の総容量で動作しているシナリオを仮定します。すべてがうまく実行されていますが、クラスタの容量の限界となっています。あるノードに障害が発生し、ソフトウェアが自動的にそのノードをフェイルオーバすることを決定するとします。残りの4つのすべてのノードが追加の負荷を正常に処理することができる見込みはありません。
その結果、増加した負荷が他のノードの障害や自動的なフェイルオーバにつながります。これらの障害は、連鎖的に発生し、クラスタ全体の最終的な損失につながります。単一ノードの障害が原因でリクエストの5分の1がサービスされなくなることは、クラスタ全体の障害が原因でサービスされているリクエストがなくなることよりも望ましいでしょう。
この場合の解決策は、単一のノード障害のままクラスタ操作を継続し、失われた容量を処理できる新しいサーバをクラスタに追加し、障害ノードを削除とマークして、リバランスすることです。この方法では、クラスタ全体がダウンするよりむしろ、短時間の部分的停止があります。
一つの代替となる予防策としては、予期しないノード障害発生時にレプリカが処理を引き継げるような余剰能力を用意しておくことです。
ネットワークパーティションを伴うフェイルオーバの処理
Couchbaseクラスタでノードをまたいだネットワークパーティションがある場合、自動フェイルオーバは両方のパーティションのノードが自動的にフェイルオーバすることにつながります。この状況では、それぞれ機能しているクラスタがドキュメントID空間全体の責任を負うことになります。各部分的なクラスタ内でドキュメントIDの一貫性があるので、部分的なクラスタ間のデータに矛盾がでます。扱うデータやアクセスパターンの性質によっては、これらの差異を修復することは困難かもしれません。
2つの部分的なクラスタの1つがすべてのトラフィックに対応するのに十分な大きさであると仮定すると、その解決策はその単一の部分的なクラスタにクラスタのすべてのトラフィックを向けることです。分離したノードは、その元のサイズをクラスタにもたらすためにクラスタに再度追加することができます。
異常な動作をするノードの処理
ひとつのノードがクラスタへの接続を失う、もしくはクラスタへの接続を失ったかのように動作する場合があります。クラスタの残りを自動的にフェイルオーバすることができる場合、そのノードは単一ノードのクラスタを作成することになります。クラスタの結果は前に説明したパーティションの状況と同じです。
このケースでは、クラスタにスペアノードの容量があるか、ネットワーク問題によるノードのフェールオーバがあるかを確認すべきです。十分な容量がないと判断した場合、問題のノードをフェイルオーバした後、その容量を処理するノードを追加してください。
監視を通じて手動フェイルオーバを実行するには、2つの形式、人間の監視によるもの、もしくはCouchbase Serverクラスタの外部システムを使用によるもののどちらかの形式を取ることができます。外部監視システムは、クラスタとノード環境の両方を監視し、より多くの情報駆動型決定を行うことができます。手動フェイルオーバソリューションを選択した場合、知っておくべき問題点もあります。自動フェイルオーバは潜在的な問題を持っていますが、手動または監視フェイルオーバを使用するように選択しても潜在的な問題がないわけではありません。
人間の介在
ひとつのオプションは、人間のオペレータが警告に応答して、何をすべきかについて判断を下すことです。人間は、状況を最善に解決するための幅広いデータ、観測や経験を考慮するユニークな能力があります。多くの企業は人間が暗示するものを考慮せずに自動フェイルオーバを無効にしています。人間による介在を使用する欠点は、コンピュータベースの監視システムを使用するよりも応答が遅くなることです。
外部システムによる監視
もうひとつのオプションは、システムにManagement REST APIを介してクラスタを監視させることです。Couchbase Serverのスコープ外に存在することを考えると、このような外部システムは非常に優れた位置にあります。
たとえば、監視ソフトウェアは、ネットワークスイッチが故障していることと、Couchbaseクラスタがそのスイッチに依存性があることを観察することができます。システムはCouchbase Serverノードのフェイルオーバがその状況で必要ないこと、そしてノードをフェイルオーバしないことを決定することができます。
監視システムはまた、Couchbase Server周りのコンポーネントが機能していて、クラスタ内のさまざまなノードが健全であることを決定することができます。監視システムが問題は単一のノードのみであり、クラスタの残りのノードは集約したトラフィックを処理できる判断した場合、システムはREST APIもしくはコマンドラインツールを使用してノードをフェイルオーバします。