ノード間のコミュニケーション(ゴシップ)

DataStax Enterpriseは、ゴシップと呼ばれるプロトコルを使用して、クラスターに参加している他のノードの場所および状態に関する情報を得ます。

DataStax Enterpriseは、ゴシップと呼ばれるプロトコルを使用して、クラスターに参加している他のノードの場所および状態に関する情報を得ます。

ゴシップとは

ゴシップは、ノードが自身や他のノードの状態に関する情報を定期的に交換するピアツーピア通信プロトコルです。ゴシップ・プロセスは毎秒実行され、クラスター内で最大3つのノードとの間で状態メッセージを交換します。各ノードは、自身およびゴシップを通じて入手した他のノードの情報を交換するので、すべてのノードがクラスターの他のすべてのノードについてすばやく知ることができます。ゴシップ・メッセージにはバージョンが付与されているため、ゴシップ交換の際に、古い情報は特定のノードの最新情報で上書きされます。

ゴシップ通信での問題を回避する

ゴシップ通信の問題を回避するには、クラスターにあるすべてのノードで同じシード・ノードのリストを使用します。これは、ノードが初めて起動するときに最も重要になります。デフォルトでは、ノードは以降の再起動のたびに、それまでのゴシップ相手を記憶しています。シード・ノードの指定には、クラスターに新しく参加するノードのゴシップ・プロセスをブートストラップする以外に目的はありません。シード・ノードは単一障害点ではなく、ノードのブートストラップ以外、クラスター運用上の特別な目的はありません。

重要: 保守タスクが増え、ゴシップのパフォーマンスが低下するため、すべてのノードをシード・ノードにすることは推奨しません。ゴシップの最適化は重要ではありませんが、シード・リストを小さくすることを推奨します(データ・センターあたり約3つのノード)。

障害検知と復旧について

障害検知とは、システム内のノードがダウンしているか、復旧しているかどうかを、ゴシップ状態と履歴からローカルに特定するための方法です。DataStax Enterpriseデータベースはこの情報を使用して、到達不能なノードにクライアント要求をルーティングするのを可能な限り回避します(このデータベースは、動的スニッチを通じて、パフォーマンスの低いノードへのルーティングを避けることもできます)。

ゴシップ・プロセスは、他のノードから、状態情報を直接的に(直接の通信先ノードから)および間接的に(二次情報、三次情報などとして)得て追跡します。障害の発生したノードをマーキングするために固定のしきい値を使用するのではなく、データベースは累積検出メカニズムを使用してノードごとのしきい値を計算します。このしきい値には、ネットワークのパフォーマンス、ワークロード、および履歴条件が考慮されます。ゴシップ交換中、各ノードは、クラスターの他のノードからのゴシップ・メッセージの到着間隔のスライディング・ウィンドウを維持します。

障害検知の感度を調整するには、phi_convict_thresholdプロパティを構成します。値を小さくすると、応答しないノードがダウンしているとマークされる可能性が高くなります。ほとんどの場合はデフォルト値を使用しますが、Amazon EC2の場合には値を10または12まで上げます(ネットワークの頻繁な輻輳のため)。不安定なネットワーク環境では(EC2で時々)、この値を10~12に上げることで偽障害を防止しやすくなります。12よりも大きい値、または5よりも小さい値は推奨しません。

ノードの障害は、ハードウェアの障害やネットワークの停止などさまざまな原因で発生します。ノードの停止は、ほとんどの場合一時的なものですが、長期にわたることもあります。ノードの停止は、クラスターからの永久的な離脱を意味することはまれであるため、リングからのノードの永続的な除去という結果にはなりません。他のノードは、障害のあるノードが復旧したかどうかを確かめるために、定期的に接続を再確立しようと試みます。クラスターのノードのメンバーシップを恒久的に変更するには、クラスターから明示的にノードを追加または除去する必要があります。

停止の後でノードがオンラインに復帰したとき、そのノードが維持しているレプリカ・データの書き込みを取りこぼしている可能性があります。nodetool repairを使用したヒンテッド・ハンドオフや手動リペアなど、失われたデータを復旧するためにリペア・メカニズム があります。機能停止の長さは、データの整合性を保つためにどのリペア・メカニズムを使用するかによって決まります。