モニターの紹介
Monitor は Ceph クラスターでマネージャーの役割を果たし、クラスター全体の状態を維持します。クラスターの状態は、monmap、osdmap、mdsmap、authmap、logmap などを含むいくつかの Map オブジェクトに抽象化され、関連するクラスタのコンポーネントには同時にアクセスできます。コンセンサスはリーダーシップに相当します。このうち、osdmapの更新はグレースケールリリースと同様の仕組みを採用しているため、クラスタ内のすべてのOSDまたはクライアントが保持するosdmapのバージョンが、ある瞬間に不整合となる可能性があります。
モニターの役割を一言で言えば、クラスター情報の収集、クラスター情報の更新、およびクラスター情報の解放を担当します。
モニターが 1 つだけであれば、作業ははるかに簡単になります。クラスター情報の追加、削除、変更、クエリはすべてこのモニターによって行われますが、これにより単一障害点やパフォーマンスのホットスポットが発生します。分散ソリューションとして、 Ceph は単一障害点を避けるために複数のモニターをデプロイします。これにより、複数の監視ノードをどのように管理するかなど、新たな問題が生じます。誰がデータを更新するのでしょうか? 複数のモニター間でデータを同期するにはどうすればよいですか? データの一貫性を維持するにはどうすればよいですか? 等 このように、Ceph クラスターで Monitor が行うことは次の 2 点に要約できます。 1) 自分自身を適切に管理する: データをどのように更新するか。データを同期するにはどうすればよいですか? 待って。2) クラスターを適切に管理します。どのようなデータがどこに存在するか? データの一貫性など
モニターの基本構造
Ceph の Monitor は、クラスター マップのマスター コピーを維持します。Ceph には通常、クライアントにマッピングされた一連の Monitor が含まれています。モニターには、K/V ストア、Paxos、および PaxosService が含まれます。K/V ストアは、モニター データを永続的に保存するために使用されます。Paxos は、PaxosService のデータ アクセス ロジックの一貫性を提供します。各 PaxosService は、キーと値の形式で PaxosService レイヤーに書き込まれるクラスターの状態情報を表します。
モニター初期化のメインプロセス:
モニターが起動または再起動すると、Connect は monmap 内の他のモニターに接続します。初めて起動すると、Monitor は設定ファイルに従って monmap を構築し、それを MonitorDBStore データベースに保存します。初めての起動ではない場合、Monitor は MonitorDBStore データベースから monmap を読み取ります。Messenger はネットワーク スレッド モジュールであり、Monitor はこれを初期化し、リクエストのコールバック処理関数を登録します。ブートストラップ処理は複数回呼び出されます。これは、Monitor のライフサイクル全体において非常に重要です。ブートストラップ後、モニターは STATE_PROBING 状態になり、モニターは他のモニターと通信して情報を同期し、クラスターはモニターの役割を決定するための選択を開始します。
状態遷移を監視します。
STATE_PROBING: ブーストラップ プロセス中に、ノードは相互に検出し、データ ギャップを見つけます。
- STATE_SYNCHRONIZING: データ ギャップが大きく、フォローアップ メカニズムでは埋めることができない場合は、完全同期が実行されます。
- STATE_ELECTING: モニターはマスターを選択しています。
- STATE_LEADER: 現在のモニターがリーダーになります。
- STATE_PEON: 非リーダー ノード。
分散システムにおけるデータの一貫性
分散システムでは、データの一貫性が特に重要です。モニター ノードには、リーダーとペオンの 2 つの役割があり、リーダーとペオンの両方がクライアントの読み取り操作を処理し、書き込み操作はリーダー ノードに送信されます。リーダー ノード Peon ノードに分散されます。Paxos アルゴリズムでは、1 つの変更操作に対して 1 つの値のみが承認されるため、分散システムのデータの一貫性が保証されます。
ノード間の通信モデル
通常、共有メモリとメッセージ パッシングの 2 つのタイプがあり、Paxos はメッセージ パッシングに基づいた通信モデルです。
Paxos 変換のタイミング:
#1. モニターの開始時に Paxos の初期化を完了します。
#2. モニターがブートストラップに入ると、Paxos が再起動します。
#3. モニター Paxos は、選挙結果に従って、対応するリーダーまたはペオンに初期化されます。
#4. モニターに異常が発生すると、Paxos は回復フェーズに入ります。
#5. モニターの実行中に、Paxos 解像度を作成します。
コンセプトの説明
エポック値
新しいリーダーが選出されるたびに、新しいエポックも生成されます。選出がない場合、エポックは変更されません。リーダーが送信するすべてのメッセージにはこのエポックが含まれますが、ネットワークの分断などにより新たな選出が行われた場合、リーダーがエポックに従って変更されたことがわかります。リーダーがいないとエポックは必要ありません。
ランク値
Rank 値は、monmap 内でのホストノードの位置を表す IP アドレスに関連付けられた ID 値として把握でき、monmap 内にホストが存在しない場合、この時点では Rank=-1 となります。選挙にはランク値が使用され、リーダーの選出はランク値に基づいて行われ、ランク値が小さい方がリーダーとなるルールとなります。
PN(提案番号)
リーダーが選出された後、最初にフェーズ 1 プロセスが実行されて PN が決定されます。リーダーの場合、すべてのフェーズ 2 操作でこの PN が使用されるため、多くのフェーズ 1 操作が省略されます。これが、Paxos がネットワーク オーバーヘッドを削減できる理由です。PN は必須です。リーダーの有無に関係なく、PN が必要です。
バージョン
これは Paxos のインスタンス ID として理解できます。
「uncommitted」の先頭の値は、通常のシャットダウンなど、すべてのプロポーザルが正常にコミットされた場合には存在しません。また、異常な状況下でのみ、送信されていないプロポーザルが保存されます。
パクソスのいくつかの州:
1)リカバリ状態:リーダーの選挙が終了した後にこの状態に入ります。目的は、定足数メンバー間で状態を同期することです。
2)アクティブ状態:アイドル状態、提案が承認されていない、待機中。
3)更新ステータス:承認提案は実行中です。
4)以前のステータスの更新:最後の提案は承認中です。つまり、リーダー選挙前に古いリーダーによって提案されたがまだ承認されていない提案です。
５）執筆状況：企画書データを提出します。
6)前回ステータス書き込み: 前回の未承認提案データを提出します。
7)更新ステータス:提案は送信されました。
メッセージの配信を監視する
Monitor プロセスは Messenger を 1 つだけ作成します。つまり、dispatch_queue キューとディスパッチャー スレッドが 1 つだけあり、すべてのリクエストがキューに入れられます。また、モニターはタイマーを初期化し、プローブ、提案、リース、その他のメッセージを含むすべてのメッセージ タイムアウト イベントを処理するスレッドを作成するため、これらのメッセージの処理もシリアルになります。
モニターはクライアントのリクエストをどのように処理しますか?
クライアントがモニターにリクエストを送信すると、モニターはまずリクエストを対応する PaxosService に分配し、PaxosService は読み取りまたは書き込み操作に従ってメソッドを呼び出し、PaxosService は提案プロセスをトリガーするかどうかを決定します。
