Ceph RBD - ceph
#
Ceph はオープンソースのストレージプラットフォームで、データを RADOS に基づいたストレージクラスタ内に保管します。 非常にスケーラブルで、単一障害点がない分散システムであり非常に信頼性が高いです。
Tip
ベーシックなCephクラスタを素早く構築したい場合、MicroCephをチェックしてみてください。
Ceph はブロックストレージ用とファイルシステム用に異なるコンポーネントを提供します。
Ceph RBD はデータとワークロードを Ceph クラスタに分散する Ceph のブロックストレージコンポーネントです。 これは薄いプロビジョニングを使用し、リソースをオーバーコミットできることを意味します。
用語#
Ceph は保管するデータに オブジェクト という用語を使用します。 データを保存と管理する責任を持つデーモンは Ceph OSD です。 Ceph のストレージは プール に分割されます。これはオブジェクトを保管する論理的なパーティションです。 これらは データプール, ストレージプール, OSD プール とも呼ばれます。
Ceph ブロックデバイスは RBD イメージ とも呼ばれ、これらの RBD イメージの スナップショット と クローン を作成できます。
LXD の ceph
ドライバ#
注釈
Ceph RBD ドライバを使用するには ceph
と指定する必要があります。
これは少し誤解を招く恐れがあります。 Ceph の全ての機能ではなく Ceph RBD (ブロックストレージ) の機能しか使わないからです。
コンテントタイプ filesystem
(イメージ、コンテナとカスタムファイルシステムボリューム) のストレージボリュームには ceph
ドライバは Ceph RDB イメージをその上にファイルシステムがある状態で使用します (block.filesystem
参照)。
別の方法として、コンテントタイプ filesystem
でストレージボリュームを作成するのに CephFS を使用することもできます。
他のストレージドライバとは異なり、このドライバはストレージシステムをセットアップはせず、既に Ceph クラスタをインストール済みであると想定します。
このドライバはリモートのストレージを提供するという意味でも他のドライバとは異なる振る舞いをします。 結果として、内部ネットワークに依存し、ストレージへのアクセスはローカルのストレージより少し遅くなるかもしれません。 一方で、リモートのストレージを使うことはクラスタ構成では大きな利点があります。これはストレージプールを同期する必要なしに、全てのクラスタメンバが同じ内容を持つ同じストレージプールにアクセスできるからです。
LXD 内の ceph
ドライバはイメージ、スナップショットに RBD イメージを使用し、インスタンスとスナップショットを作成するのにクローンを使用します。
LXD は OSD ストレージプールに対して完全制御できることを想定します。 このため、 LXD OSD ストレージプール内に LXD が所有しないファイルシステムエンティティは LXD が消してしまうかもしれないので決して置くべきではありません。
Ceph RBD 内で copy-on-write が動作する方法のため、親の RBD イメージは全ての子がいなくなるまで削除できません。
結果として LXD は削除されたがまだ参照されているオブジェクトを自動的にリネームします。
そのようなオブジェクトは全ての参照がいなくなりオブジェクトが安全に削除できるようになるまで zombie_
接頭辞をつけて維持されます。
制限#
ceph
ドライバには以下の制限があります。
- インスタンス間でのカスタムボリュームの共有
コンテントタイプ
filesystem
のカスタムストレージボリュームは異なるクラスタメンバの複数のインスタンス間で通常は共有できます。 しかし、 Ceph RBD ドライバは RBD イメージ上にファイルシステムを置くことでコンテントタイプfilesystem
のボリュームを「シミュレート」しているため、カスタムストレージボリュームは一度に1つのインスタンスにしか割り当てできません。 コンテントタイプfilesystem
のカスタムボリュームを共有する必要がある場合は代わりに CephFS - cephfs ドライバを使用してください。- 複数インストールされた LXD 間で OSD ストレージプールの共有
複数インストールされた LXD 間で同じ 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 |
ブロックベースドライバ |
|
ブロックデバイスのマウントオプション |
|
bool |
カスタムボリューム |
|
ID シフトオーバーレイを有効にする (複数の分離されたインスタンスによるアタッチを許可する) |
|
bool |
カスタムボリューム |
|
ボリュームの ID マッピングを無効にする |
|
string |
適切なドライバ |
|
ストレージボリュームのサイズ/クォータ |
|
string |
カスタムボリューム |
|
スナップショットをいつ削除するかを制御 ( |
|
string |
カスタムボリューム |
|
スナップショットの名前を表す Pongo2 テンプレート文字列 (スケジュールされたスナップショットと名前無しのスナップショットで使用) 1 |
|
string |
カスタムボリューム |
|
Cron 表記 ( |
- 1
snapshots.pattern
オプションはスナップショット名をフォーマットする Pongo2 テンプレート文字列です。スナップショット名にタイムスタンプを追加するには、Pongo2 コンテキスト変数
creation_date
を使用します。 スナップショット名に使用できない文字を含まないようにテンプレート文字列をフォーマットするようにしてください。 例えば、snapshots.pattern
を{{ creation_date|date:'2006-01-02_15-04-05' }}
に設定し、作成日時を秒の制度まで落として、スナップショットを命名するようにします。名前の衝突を防ぐ別の方法はパターン内に
%d
プレースホルダを使うことです。 最初のスナップショットでは、プレースホルダは0
に置換されます。 後続のスナップショットでは、既存のスナップショットが考慮され、プレースホルダの位置の最大の数を見つけます。 この数が 1 増加されて新しい名前に使用されます。