Ceph RBD - ceph
¶
Ceph はオープンソースのストレージプラットフォームで、データを RADOS に基づいたストレージクラスタ内に保管します。 非常にスケーラブルで、単一障害点がない分散システムであり非常に信頼性が高いです。
Ceph はブロックストレージ用とファイルシステム用に異なるコンポーネントを提供します。
Ceph RBD はデータとワークロードを Ceph クラスタに分散する Ceph のブロックストレージコンポーネントです。 これは Thin provisioning を使用し、リソースをオーバーコミットできることを意味します。
用語¶
Ceph は保管するデータに オブジェクト という用語を使用します。 データを保存と管理する責任を持つデーモンは Ceph OSD です。 Ceph のストレージは プール に分割されます。これはオブジェクトを保管する論理的なパーティションです。 これらは データプール, ストレージプール, OSD プール とも呼ばれます。
Ceph ブロックデバイスは RBD イメージ とも呼ばれ、これらの RBD イメージの スナップショット と クローン を作成できます。
Incus の ceph
ドライバー¶
注釈
Ceph RBD ドライバを使用するには ceph
と指定する必要があります。
これは少し誤解を招く恐れがあります。 Ceph の全ての機能ではなく Ceph RBD(ブロックストレージ)の機能しか使わないからです。
コンテントタイプ filesystem
(イメージ、コンテナとカスタムファイルシステムボリューム)のストレージボリュームには ceph
ドライバは Ceph RDB イメージをその上にファイルシステムがある状態で使用します(block.filesystem
参照)。
別の方法として、コンテントタイプ filesystem
でストレージボリュームを作成するのに CephFS を使用することもできます。
他のストレージドライバーとは異なり、このドライバーはストレージシステムをセットアップはせず、既に Ceph クラスタをインストール済みであると想定します。
このドライバーはリモートのストレージを提供するという意味でも他のドライバーとは異なる振る舞いをします。 結果として、内部ネットワークに依存し、ストレージへのアクセスはローカルのストレージより少し遅くなるかもしれません。 一方で、リモートのストレージを使うことはクラスタ構成では大きな利点があります。これはストレージプールを同期する必要なしに、すべてのクラスタメンバーが同じ内容を持つ同じストレージプールにアクセスできるからです。
Incus 内の ceph
ドライバーはイメージ、スナップショットに RBD イメージを使用し、インスタンスとスナップショットを作成するのにクローンを使用します。
Incus は OSD ストレージプールに対して完全制御できることを想定します。 このため、 Incus OSD ストレージプール内に Incus が所有しないファイルシステムエンティティは Incus が消してしまうかもしれないので決して置くべきではありません。
Ceph RBD 内で copy-on-write が動作する方法のため、親の RBD イメージはすべての子がいなくなるまで削除できません。
結果として Incus は削除されたがまだ参照されているオブジェクトを自動的にリネームします。
そのようなオブジェクトはすべての参照がいなくなりオブジェクトが安全に削除できるようになるまで zombie_
接頭辞をつけて維持されます。
制限¶
ceph
ドライバーには以下の制限があります。
- インスタンス間でのカスタムボリュームの共有
コンテントタイプ
filesystem
のカスタムストレージボリュームは異なるクラスタメンバーの複数のインスタンス間で通常は共有できます。 しかし、 Ceph RBD ドライバーは RBD イメージ上にファイルシステムを置くことでコンテントタイプfilesystem
のボリュームを「シミュレート」しているため、カスタムストレージボリュームは一度に 1 つのインスタンスにしか割り当てできません。 コンテントタイプfilesystem
のカスタムボリュームを共有する必要がある場合は代わりに CephFS - cephfs ドライバーを使用してください。- 複数インストールされた Incus 間で OSD ストレージプールの共有
複数インストールされた Incus 間で同じ OSD ストレージプールを共有することはサポートされていません。
- タイプ "erasure" の OSD プールの使用
タイプ "erasure" の OSD プールを使用するには事前に OSD プールを作成する必要があります。 さらにタイプ "replicated" の別の OSD プールを作成する必要もあります。これはメタデータを保管するのに使用されます。 これは Ceph RBD が
omap
をサポートしないために必要となります。 どのプールが "erasure coded" であるかを指定するためにceph.osd.data_pool_name
設定オプションをイレージャーコーディングされたプールの名前に設定しsource
設定オプションをリプリケートされたプールの名前に設定します。
設定オプション¶
ceph
ドライバーを使うストレージプールとこれらのプール内のストレージボリュームには以下の設定オプションが利用できます。
ストレージプール設定¶
キー |
型 |
デフォルト値 |
説明 |
---|---|---|---|
|
string |
|
新しいストレージプールを作成する Ceph クラスタの名前 |
|
string |
- |
OSD data pool の名前 |
|
string |
|
OSD ストレージプール用の placement グループの数 |
|
string |
プールの名前 |
OSD ストレージプールの名前 |
|
bool |
|
フルのデータセットコピーではなく RBD のライトウェイトクローンを使うかどうか |
|
bool |
|
停止したインスタンスのディスク使用データを取得するのに RBD |
|
string |
|
ボリュームで有効にする RBD の機能のカンマ区切りリスト |
|
string |
|
ストレージプールとボリュームの作成に使用する Ceph ユーザー |
|
string |
- |
使用する既存の OSD ストレージプール |
|
string |
|
プールが作成時に空かどうか |
Tip
これらの設定に加えて、ストレージボリューム設定のデフォルト値を設定できます。 ストレージボリュームのデフォルト値を変更する を参照してください。
ストレージボリューム設定¶
キー |
型 |
条件 |
デフォルト値 |
説明 |
---|---|---|---|---|
|
string |
|
ストレージボリュームのファイルシステム: |
|
|
string |
|
block-backedなファイルシステムボリュームのマウントオプション |
|
|
bool |
カスタムブロックボリューム |
|
複数のインスタンスでのボリュームの共有を有効にする |
|
bool |
カスタムボリューム |
|
ID シフトオーバーレイを有効にする (複数の分離されたインスタンスによるアタッチを許可する) |
|
bool |
カスタムボリューム |
|
ボリュームの ID マッピングを無効にする |
|
string |
|
ストレージボリュームのサイズ/クォータ |
|
|
string |
カスタムボリューム |
|
スナップショットをいつ削除するかを制御 ( |
|
string |
カスタムボリューム |
|
スナップショットの名前を表す Pongo2 テンプレート文字列 (スケジュールされたスナップショットと名前無しのスナップショットで使用) [1] |
|
string |
カスタムボリューム |
|
Cron 表記 ( |