OSDMapメカニズムはCephアーキテクチャの非常に重要な部分であり、OSD上のPGの配布と監視はOSDMapメカニズムによって実行されます。OSDMapメカニズムとCRUSHアルゴリズムは共に、Cephの分散アーキテクチャの基礎を形成します。
OSDMapメカニズムには、主に次の3つの側面があります。
1.モニターは、プールコレクション、コピー数、PG番号、OSDコレクション、OSDステータスなどのOSDMapデータを監視します。
2. OSDはそのステータスをモニターに報告し、ピアOSDのステータスをモニターして報告します。
3. OSDは、新しいPGの作成、PGの移行、PGの削除など、それに割り当てられたPGを監視します。
OSDMapメカニズム全体で、OSDはMonitorを完全に信頼し、OSDMapが維持するOSDMapデータが完全に正しいと信じています。PGでOSDが実行するすべてのアクションはOSDMapデータに基づいています。つまり、モニターはOSDにPGの配布方法を指示します。
OSDMapデータでは、プールコレクション、コピー数、PGの数、およびOSDコレクションは、運用および保守担当者によって指定されます。OSDの状態は、運用および保守担当者によっても変更できますが、CephクラスターAの実際の運用は時々分散されます。運用と保守の担当者はCephクラスターに関与する時間の割合が非常に少ないため、OSD（OSD状態）の障害がモニター監視の主なターゲットであることがわかります。
OSD障害の監視は、モニターとOSDによって一緒に行われます。モニター側では、OSDMonitorと呼ばれるPaxosServiceスレッドを使用して、OSDから送信されたレポートデータをリアルタイムで監視します（もちろん、OSDMapデータの運用および保守担当者が実行した操作も監視します）。OSD側で、一方ではティックスレッドを実行し、定期的にそのステータスをモニターに報告します。他方では、OSDはピアOSDでハートビートモニタリングを実行し、ピアOSDの障害が検出された場合は、モニターにタイムリーにフィードバックします。この記事では、特定のOSD障害監視の詳細については分析していません。
OSDMapメカニズムの1番目と2番目のポイントは比較的理解しやすく、次の記事では主に3番目のポイントを詳細に分析します。
image.png
上の図に示すように、3つのOSDのCephクラスターでは、プールのコピー数は3で、PGのプライマリOSDはOSD0です。モニターは、3つのOSDのOSD障害を検出すると、最新のOSDMapデータを送信します残りの2つのOSDに移動し、対応する対策を講じるように通知します。
image.png
上の図に示すように、OSDはMOSDMapを受け取った後、主に3つの側面を扱います
ObjectStore ::トランザクション::書き込み（coll_t ::メタ（））OSDMapをディスクに更新し、ディレクトリ/ var / lib / ceph / OSD / ceph- <id> / current / meta /に保存して、OSDMapデータを永続化しますログのような役割に。
OSD :: consumer_map（）は、PG処理を実行します。これには、プールに存在しないPGの削除、PGエポック（OSDmapエポック）のディスク（LevelDB）への更新、AdvMapおよびActMapイベントの生成、PG状態マシンstate_machineのトリガーによる状態の更新が含まれます。
OSD :: activate_map（）は、必要に応じて、PGリカバリのrecovery_tpスレッドプールを開始するかどうかを決定します。
OSD側では、PGがI / O処理を担当するため、PGの状態はI / Oに直接影響し、pgstate_machineはPG状態の制御メカニズムですが、内部の状態遷移は非常に複雑であり、ここでは特定の分析は行われません。
以下は、PGの作成、削除、移行の分析を開始します。
PGの作成は、運用および保守担当者によってトリガーされます。新しいプールを作成するときにPGの数を指定するか、既存のプールPGの数を増やします。このとき、OSDMonitorはOSDMapの変更を監視し、最新のMOSDMapをすべてのOSDに送信します。
PGに対応するOSDのグループでは、OSD :: handle_pg_create（）関数がディスクにPGディレクトリを作成し、PGメタデータを書き込み、ハートビートピアやその他の操作を更新します。
PGの削除は、運用および保守要員によってもトリガーされます。OSDMonitorはMOSDMapをOSDに送信します。PGに対応するOSDのグループでは、OSD :: handle_PG _remove（）関数は、PGが配置されているディレクトリをディスクから削除し、PGMapからPGを削除します。 PGメタデータとその他の操作を削除します。
PGの移行はより複雑で、2つのOSDとモニターの共同処理が含まれます。たとえば、OSD3を3つの既存のOSDを持つクラスターに追加すると、CRUSHがPGを再配布します。PG割り当て変更の結果は、[0、1、2]-> [3、1、2]です。もちろん、CRUSHの分布はランダムです。異なるPGでは、OSD3がプライマリOSDまたはレプリケートOSDのいずれかになる可能性があります。ここでは、OSD3をプライマリOSDとして例に取ります。
新しく追加されたOSD3は、元のOSD0を置き換えてプライマリOSDになります。PGはOSD3で作成されず、データがないため、PGでI / Oを実行できません。したがって、ここでPG Tempメカニズムが導入されます。つまり、OSD3はMOSDPG Tempをモニターに送信します、プライマリOSDをOSD1として指定します。PGのデータはOSD1に保存されるため、クライアントからPGに送信された要求はOSD1に転送されます。同時に、OSD1はPGのデータをOSD3に送信し、PGデータのコピーが完了するまで、OSD1がプライマリになりますOSDの役割がOSD3に返され、クライアントのI / O要求が直接OSD3に送信され、PGの移行が完了します。プロセス全体を次の図に示します。
image.png
別のPG移行シナリオは、OSD3がレプリケートOSDとして使用されている場合、Primay OSDからOSD3へのPGデータの移行は、上記のPG移行プロセスよりも簡単であるため、ここでは詳しく説明しません。
この記事では、PGの観点からOSDMapメカニズムの基本原理を説明し、モニター、OSD、PGの関係について説明します。実際の運用や保守では、OSDの状態や量の変化によるPGの状態の変化に戸惑うことが多く、本記事がPGの状態の問題を解決してくれることを期待しています。
著者：Lucien_168
リンクします。https：//www.jianshu.com/p/8ecd6028f5ff
出典：ジェーンの本が
著者によって著作権で保護されています。営利目的の複製については、作者に連絡して承認を得てください。非営利目的の複製については、出典を明記してください。
