Ceph分散ストレージのカーネルクライアントの詳細な分析

クラウドコンピューティングの発展により、Ceph はストレージ業界における Linux オペレーティングシステムと同様に、最も人気のある分散ストレージシステムになりました。 Ceph はブロックストレージ、ファイルストレージ、オブジェクトストレージを統合しており、幅広いシナリオに適用でき、多くのユーザーが利用しています。この記事では、カーネルにおける Ceph クライアントの実装を紹介し、特別に中国語に翻訳されています。

[[318499]]

Ceph は、Salesforce でブロックストレージサービスとして使用されているオープンソースの統合分散ストレージシステムです。 Ceph のブロックストレージは、データデーモンから直接 (ゲートウェイを経由せずに) データを読み書きできるクライアントモジュールを通じて実装されます。クライアント統合エコシステムに応じて、クライアントを実装する方法は 2 つあります。

librbd (ユーザーモード)
krbd (カーネルモード)

Librbd は通常、仮想マシン環境 (KVM や QEMu など) で使用され、krbd はコンテナーやベアメタル環境で使用されます。 Salesforce では、Ceph を Docker コンテナとして使用し、アプリケーションコンテナが実行されるホストに krbd モジュールをインストールします。

この記事では、Ceph カーネルクライアントの内部について説明します。この記事で取り上げる内容は次のとおりです。

初期化
カーネルモジュールがCeph設定を取得する方法
構成を処理するためのコードエントリポイント
接続処理
安全性
接続ステートマシン

krbd 初期化

krbd はカーネルモジュールです。カーネル内にブロックデバイスとして実装されています。 Ceph クライアント全体はカーネルモジュールとして実装されています (ユーザーモードのプロセスやデーモンは関連付けられていません)。

Ceph クライアントは、クラスターへの接続方法を認識するための構成ファイル (ceph.conf) を必要とし、クラスターのプロパティを認識する必要があります。この構成ファイルには通常、モニターの IP アドレス、ユーザー証明書、および Ceph 認証 (Cephx) のセキュリティプロパティが含まれます。これらのすべての構成は、初期化中にカーネルモジュールにロードする必要があります。これが完了すると、イメージまたはボリュームのライフサイクル、接続管理、認証、ステートマシンなどの残りの実装はすべてカーネルモジュールで実行できるようになります。

Ceph 設定をカーネルモジュールにプッシュする

ceph-deploy を実行してクライアントをインストールすると、Ceph クライアント (rbd で始まるコマンド) CLI コマンドによって呼び出されるバイナリがインストールされます。

rbd CLI

最初のクライアントコマンドは次のとおりです。

 rbd map <デバイス名> --pool <プール名>

デフォルトでは、rbd は設定ファイル /etc/ceph/ceph.conf から設定情報を読み取ります。ファイルには、モニターアドレス (クライアントはこのアドレスを使用してモニターに接続します)、OSD アイドルタイムアウト、OSD タイムアウト、OSD 要求タイムアウト、暗号化などの情報が含まれています。設定オプションの完全なリストは、http://docs.ceph.com/docs/jewel/man/8/rbd/#kernel-rbd-krbd-options にあります。

OSD

krbd 初期化

rbd mapコマンドラインコマンドは、実際にceph.confファイルの内容を読み取り、Linuxの「バス」インターフェース（/sys/bus/）を介してceph.confファイルにマッピングします。 - このシナリオでは、/sys/bus/rbd/add がこれらの構成情報を krbd カーネルモジュールにプッシュします。

依存関係をここで定義します: https://github.com/torvalds/linux/blob/master/include/linux/device.h

バスは、プロセッサと 1 つ以上のデバイス間のチャネルです。目的は、すべてのデバイスがバス (内部の仮想プラットフォームバスも可能) で接続されるデバイスモデルを実装することです。バスは相互に接続できます。たとえば、USB コントローラーは通常、PCI デバイスです。デバイスモデルは、バスとそれが制御するデバイス間の実際の接続を表します。

Linux デバイスモデルでは、bus_type 構造体はバスを表し、linux/device.h で定義されます。構造は次のとおりです。

この実装のソースコードは、次の ceph/ceph git リポジトリにあります: https://github.com/ceph/ceph/blob/master/src/krbd.cc

KRBD構成分析

カーネルモジュールでは、構成ファイルを処理するためのエントリポイントは drivers/block/rbd.c (https://github.com/ceph/ceph-client/blob/for-linus/drivers/block/rbd.c) で定義されています。

静的 ssize_t rbd_add(構造体 bus_type *bus、const char *buf、size_t カウント)

接続設定

カーネルモジュールは、モニターおよび OSD との TCP 接続の確立、これらの接続の検出、問題発生時の接続の再確立、および認証を完全に担当します。この作業はすべてカーネル内で実行されます。

月曜日クライアント初期化

エントリ関数: ceph_monc_init()

この関数は、まずマウント時に提供された IP アドレスを使用して一時的な monmap (build_initial_monmap()) を構築します。この操作は、クライアントがモニターとの新しい接続を確立したときに発生します。その後、認証データ構造を初期化し、接続後の初期ハンドシェイクを完了するために次のメッセージをさらに準備します。

CEPH_MSG_MON_SUBSCRIBE (メッセージID: 15)
CEPH_MSG_MON_SUBSCRIBE_ACK (メッセージ ID: 16)
CEPH_MSG_AUTH (メッセージ ID: 17)
CEPH_MSG_AUTH_REPLY (メッセージID: 18)

接続の初期化

エントリ関数: ceph_con_init()

この時点で、ceph_con_init() 関数 (net/ceph/messenger.c 内) が呼び出され、モニターとの接続の初期化が完了し、接続はステートマシンを介して変換されます。 ceph_con_init() はソケットを初期化し、接続を非同期的に設定するワークキュー関数を開始します。

ceph_con_workfn() 関数は、接続を次のソケット状態 (ceph_connection -> sock_state) で処理し、ESTABLISHED 状態に移行します。

 /*
 * ソケット状態 - 遷移（接続状態はソケット状態と異なります）
 * --------  
 * |新着* |一時的な初期状態
 * --------  
 * | con_sock_state_init()
 * ヴ
 * ----------  
 * |閉店 |初期化されましたが、ソケットがありません（そして いいえ 
 * ---------- TCP接続)  
 * ^ \
 * | \ con_sock_state_connecting()
 * | ----------------------  
 * | \
 * + con_sock_state_closed() \
 * |+ ------------------------ \  
 * | \ \ \
 * | ----------\ \  
 * | |閉会 |ソケットイベント; \ \
 * | ----------- クローズを待つ \ \  
 * | ^ \ |
 * | | \ |
 * | + con_sock_state_closing() \ |
 * | / \ | |
 * | / ---------------- | |  
 * | / \ v v
 * | / --------------  
 * | / ------------------|接続 |ソケットが作成されました。  
 * | | / -------------- TCP接続 
 * | | |開始した
 * | | | con_sock_state_connected()
 * | |ヴ
 * -------------  
 * |接続 | TCP接続が確立されました
 * -------------  
 *
 * 状態値  ceph_connection->sock_stateの場合; NEW は0とみなされます。
 */
 /*
 *接続状態 - 遷移
 * --------  
 * |閉店 |< ----<------------------<-----------<-  
 * -------- | | |  
 * | |失敗について| |
 * ヴ | | |
 * -------- | | |  
 * ---->|プレオープン |---- | |  
 * | -------- ^ ^  
 * | | ceph_tcp_connect() 関数 | |
 * |ヴ | |
 * ^ ------------- | |  
 * | |接続 | ----------------------- |  
 * | ------------- |  
 * | |読む プロセスバナー ( "ceph v027" )、|
 * | |ピアに送信する機能を準備する|
 * | | |
 * |ヴ |
 * | -------------- |  
 * | |交渉中 | ----------------------------------  
 * | --------------  
 * ------- | connect_reply、認証機能の読み取り 
 * |スタンバイ| |仲間から
 * ------- |  
 * |ヴ
 * | -----  
 * < ----- |開く |--------------------------------------->  
 * ----- (最終ハンドシェイク確認応答を完了)  
 *

接続コールバック登録

次のデータ構造は、include/linux/ceph/messenger.h で定義されています。このデータ構造は、モニター接続 (OSD への接続を含む) で接続イベントを処理するためのコールバック関数を定義します。

クライアントが接続されると、次のようなメッセージが届きます。

Mon マップ (net/ceph/mon_client.c の ceph_monc_handle_map())

Osd マップ (net/ceph/osd_client.c の ceph_osdc_handle_map())

Ceph クライアント構成ファイルにクラスター内のすべてのモニターに関する情報が含まれている場合、クライアントはすべてのモニターとの接続を確立します。ただし、クラスター内に 5 つのモニターがあるが、構成ファイルにはモニターが 1 つしかない場合です。この時点で、クライアントは構成ファイル内のモニターとの接続を確立します。モニターとの接続が中断された場合、クライアントはモニターをランダムに選択して接続を確立します (クライアントは受信した monmap を通じてすべてのモニターのリストを取得します)。

モニター接続によって OSD クライアントデータ構造と接続の作成がトリガーされると、クライアントは OSD マップに関する情報を受け取ります。

カーネルソースディレクトリ内のkrbd

ソースファイル:

ドライバー/ブロック/rbd.c
ドライバー/ブロック/rbd_types.h
ネット/セフ/

ヘッダーファイル:

インクルード/Linux/Ceph

パッケージ

この記事では、Ceph クライアント krbd について詳しく説明し、カーネルでの実装について説明します。同時にカーネルに実装されている各種クライアント機能のエントリ関数も紹介します。

結論

この記事では、Ceph クライアントのブロックストレージ部分の初期化と実装の詳細について説明します。 Ceph にはカーネル内の別の部分、有名な Ceph ファイルシステムがあります。この部分の内容は比較的複雑なので、翻訳者は後ほど別の記事を書いて紹介する予定です。

さらに、Linux カーネルにおける Ceph の内容には主に 3 つの側面があることを付け加えておきます。 1 つ目は、ブロックデバイスの実装である krbd の実装 (drivers/block/rbd.c 内) です。 2 つ目は、NFS に似た Ceph ファイルシステム (fs/ceph ディレクトリ内) の実装です。ネットワーク経由で Ceph クラスター分散ファイルシステムへのアクセスを実装します。 3 番目はネットワーク部分 (net/ceph ディレクトリ内) で、これはパブリックであり、ブロックデバイスとファイルシステムの両方で使用されます。

<<: 分散システムにおける「ゴースト再発」を解決するにはどうすればよいでしょうか?

>>: DevOps がクラウドコンピューティングに影響を与える 5 つの領域