OpenStack は Ceph ストレージを使用します。 Ceph は何をしますか?

1 背景

1.1 Ceph の紹介

• Ceph は、高いスケーラビリティ、高いパフォーマンス、高い信頼性の利点を備えた、非常に人気のあるオープンソースの分散ストレージ システムです。また、ブロック ストレージ サービス (rbd)、オブジェクト ストレージ サービス (rgw)、ファイル システム ストレージ サービス (cephfs) も提供します。これは現在、OpenStack の主流のバックエンド ストレージであり、OpenStack に兄弟のように近い存在であり、OpenStack に統合された共有ストレージ サービスを提供します。 Ceph を OpenStack バックエンド ストレージとして使用すると、次の利点があります。
• すべてのコンピューティング ノードはストレージを共有するため、移行中にルート ディスクをコピーする必要はありません。コンピューティング ノードがクラッシュした場合でも、仮想マシンは別のコンピューティング ノード上ですぐに起動できます (退避)。
• COW (Copy On Write) 機能を使用すると、仮想マシンを作成するときに、イメージ全体をダウンロードせずに、イメージに基づいてクローンを作成するだけで済みます。クローン作成操作には基本的にオーバーヘッドがないため、数秒で仮想マシンを作成できます。

Ceph RBD はシンプロビジョニングをサポートしています。これは、オンデマンドでスペースを割り当てることを意味し、Linux ファイルシステムのスパースファイルに似ています。 20 GB の仮想ハードディスクを作成すると、最初は物理的なストレージ領域を占有しません。ストレージ スペースは、データが書き込まれるときにのみオンデマンドで割り当てられます。

[[229974]]

Ceph の詳細については、公式ドキュメントを参照してください。ここでは RBD のみに焦点を当てます。 RBD によって管理されるコア オブジェクトはブロック デバイスであり、通常はボリュームと呼ばれますが、Ceph ではイメージと呼ばれます (OpenStack イメージとの違いに注意してください)。 Ceph には、名前空間に似たプールの概念もあります。異なるプールでは、異なるレプリカ数、PG 数、配置戦略などを定義できます。各イメージではプールを指定する必要があります。イメージの命名規則は pool_name/image_name@snapshot です。たとえば、openstack/test-volume@test-snap は、openstackpool 内の test-volumeimage のスナップショット test-snap を意味します。したがって、次の 2 つのコマンドは同等です。

 rbd スナップ作成  --pool openstack --image テストイメージ --snap テストスナップ 
 rbd スナップはopenstack/test-image@test-snapを作成します。

OpenStack プールに 1G イメージを作成するコマンドは次のとおりです。

 rbd -p オープンスタック作成  --size 1024 int32bit-テスト-1  

イメージはスナップショット機能をサポートしています。スナップショットを作成すると、現在のイメージのステータスが保存されます。これは、git commit 操作と同等です。ユーザーはいつでもイメージを任意のスナップショット ポイントにロールバックできます (git reset)。スナップショットを作成するコマンドは次のとおりです。

 rbd -p openstack snapを作成しますint32bit-test-1@snap-1

rbd リストを表示します:

 rbd コマンドは、次の例のように openstack ノードに対して実行されます。 grep int32bitテスト
int32bit-テスト-1 1024M 2
 int32bit-テスト-1@スナップ-1 1024M 2

スナップショットに基づいて、クローンと呼ばれる新しいイメージを作成できます。クローンでは元のイメージがすぐにコピーされるのではなく、COW 戦略、つまりコピーオンライトが使用されます。オブジェクトを書き込む必要がある場合にのみ、オブジェクトが親からローカルにコピーされます。したがって、クローン操作は基本的に数秒で完了します。同じスナップショットに基づいて作成されたすべてのイメージは、スナップショット前のイメージ データを共有することに注意してください。したがって、クローンを作成する前にスナップショットを保護する必要があります。保護されたスナップショットは削除できません。クローン操作は、git ブランチ操作に似ています。イメージを複製するコマンドは次のとおりです。

 rbd -p openstack snap は int32bit-test-1@snap-1 を保護します
rbd -p openstack クローン int32bit-test-1@snap-1 int32bit-test-2

イメージにどの子があるかを確認できるほか、イメージがどのイメージ クローンに基づいているか (親) も確認できます。

 $ rbd -p openstack children int32bit-test-1@snap-1
 openstack/int32bit-テスト-2
 rbd -p openstack 情報 int32bit-test-2 | grep 親
親: openstack/int32bit-test-1@snap-1

上記から、int32bit-test-2 は int32bit-test-1 の子であり、int32bit-test-1 は int32bit-test-2 の親であることがわかります。

スナップショットを継続的に作成し、イメージを複製すると、非常に長いイメージ チェーンが形成されます。チェーンが非常に長い場合、読み取りおよび書き込みのパフォーマンスに影響するだけでなく、管理も非常に面倒になります。幸いなことに、Ceph はチェーン上のすべてのイメージを 1 つのイメージにマージすることをサポートしています。この操作は flatten と呼ばれ、git merge 操作に似ています。フラット化では、最上位レベルの存在しないデータをすべてレイヤーごとにコピーする必要があるため、通常は非常に時間がかかります。

 $ rbd -p openstack フラット化 int32bit-test-2
画像の平坦化: 31% 完了...

この時点で、親子関係をもう一度見てみましょう。

 rbd -p openstack children int32bit-test-1@snap-1

この時点では、int32bit-test-1 には子がなく、int32bit-test-2 は完全に独立しています。

もちろん、Ceph は copy と呼ばれる完全なコピーもサポートしています。

 rbd -p openstack cp int32bit-test-1 int32bit-test-3

コピーはイメージを完全にコピーするため、非常に時間がかかりますが、コピーでは元のスナップショット情報はコピーされないことに注意してください。

Ceph は RBD イメージのエクスポートをサポートしています。

 rbd -p openstack エクスポート int32bit-test-1 int32bit-1.raw

「エクスポート」では画像全体がエクスポートされます。 Ceph は、特定のスナップショット ポイントからエクスポートを開始することを指定する差分エクスポート (export-diff) もサポートしています。

 rbd -p openstack エクスポート差分 \
 int32bit-test-1 --from-snap スナップ-1 \  
 --snap スナップ 2 int32bit-テスト-1-diff.raw  

上記は、スナップショット ポイント snap-1 からスナップショット ポイント snap-2 にデータをエクスポートします。

もちろん、反対の操作は import と import-diff です。エクスポート/インポートは完全なイメージ バックアップをサポートしますが、エクスポート diff/インポート diff は差分イメージ バックアップを実装します。

Rbd イメージはストレージ スペースを動的に割り当てます。 du コマンドを使用すると、イメージが占有する実際の物理ストレージ領域を表示できます。

 $ rbd デュ int32bit-test-1
名前提供 使用
int32bit-テスト-1 1024M 12288k

上記のイメージ割り当てのサイズは 1024M で、実際に占有されるスペースは 12288KB です。

画像を削除します。最初にすべてのスナップショットを削除し、依存する子がないことを確認する必要があることに注意してください。

 rbd -p openstack snap unprotect int32bit-test-1@snap-1
 rbd -p openstack スナップ rm int32bit-test-1@snap-1
 rbd -p openstack rm int32bit-test-1

1.2 OpenStackの概要

OpenStack は、IaaS レイヤーにおけるクラウド コンピューティング プラットフォームのオープン ソース実装です。 OpenStack の詳細については、私の個人ブログをご覧ください。ここでは、OpenStack が Ceph ストレージ システムに接続されたときに、ソース コード分析に基づいて Ceph が段階的に実行する内容にのみ焦点を当てます。この記事では、OpenStack のワークフロー全体を詳細に紹介するのではなく、Ceph に関連する実装にのみ焦点を当てます。 OpenStack ソース コードのアーキテクチャがよくわからない場合は、OpenStack ソース コードの読み方に関する以前の記事を参照してください。

この記事を読むと、次の質問が理解できるようになります。

1. アップロードされた画像をなぜ RAW 形式に変換する必要があるのですか?
2. 大きな画像ファイルを効率的にアップロードするにはどうすればいいですか?
3. 仮想マシンを数秒で作成できるのはなぜですか?
4. VM スナップショットの作成には数分かかるのに、ボリューム スナップショットの作成には数秒しかかからないのはなぜですか?
5. 仮想マシンが存在する場合、イメージを削除できないのはなぜですか?
6. 既存のボリュームを上書きするのではなく、空のボリュームにバックアップを復元する必要があるのはなぜですか?
7. 画像からボリュームを作成しました。画像を削除してもいいですか？

この記事は Ceph ストレージを使用することを前提としていることに注意してください。つまり、Glance、Nova、Cinder はすべて Ceph を使用します。この結論は他の場合には当てはまらない可能性があります。

(注: 元記事にはソースコードがあり、5,000 語の制限を超えているため簡略化されています。詳細な導出と検証のプロセスを確認する必要がある場合は、元のリンクを確認してください。また、要約セクションにすぐにジャンプして、各 OpenStack 操作に対応する Ceph の動作を確認できます。)

2 一目見る

2.1 Glance の紹介

Glance によって管理されるコアエンティティは、OpenStack のコアコンポーネントの 1 つであるイメージです。 OpenStack のイメージ サービス (Image as Service) を提供し、主に OpenStack イメージとイメージ メタデータのライフサイクル管理、取得、ダウンロードを担当します。 Glance は、複数のストレージ システムへのイメージの保存をサポートしています。バックエンドのストレージシステムはストアと呼ばれ、イメージにアクセスするためのアドレスはロケーションと呼ばれます。場所は、http アドレスまたは rbd プロトコル アドレスにすることができます。ストア ドライバーが実装されていれば、Glance のストレージ バックエンドとして使用できます。ドライバーの主なインターフェースは次のとおりです。

• get: 画像の場所を取得します。
• get_size: 画像のサイズを取得します。
• get_schemes: rbd、swift+https、http など、イメージにアクセスするための URL プレフィックス (プロトコル部分) を取得します。
• add: 画像をバックエンドストレージにアップロードします。
• delete: 画像を削除します。
• set_acls: バックエンド ストレージの読み取りおよび書き込みアクセス権限を設定します。

メンテナンスの容易さのため、glance store は独立したライブラリとして Glance コードから分離され、glance_store プロジェクトによってメンテナンスされています。現在コミュニティによってサポートされているストアのリストは次のとおりです。

• ファイルシステム: ローカルファイルシステムに保存します。デフォルトでは、/var/lib/glance/images ディレクトリに保存されます。
• cinder: Cinder に保存します。
• rbd: Ceph に保存します。
• sheepdog: sheepdog に保存します。
• swift: Swift オブジェクト ストレージに保存します。
• vmware データストア: Vmware データストアに保存します。

http: 上記のすべてのストアは画像データを保存しますが、http ストアは特別です。画像データを保存しないため、add メソッドは実装されません。画像のURLアドレスのみが保存されます。仮想マシンが起動すると、コンピューティング ノードは指定された http アドレスからイメージをダウンロードします。

この記事では、ソース コードがここにある rbd ストアに焦点を当てます。このストアのドライバー コードは主に中国の Fei Long Wang によって管理されています。他のストアの実装の詳細については、Glance ストア ドライバーのソース コードを参照してください。

3 ノヴァ

3.1 Novaの紹介

Nova によって管理されるコア エンティティはサーバーであり、OpenStack にコンピューティング サービスを提供して OpenStack のコア コンポーネントとなります。 Nova のサーバーは仮想マシンだけを指すのではなく、あらゆるコンピューティング リソースの抽象化である可能性があることに注意してください。仮想マシン以外にも、ベアメタルマシンやコンテナなどでも構いません。

ただし、ここでは次のことを前提としています。

• サーバーは仮想マシンです。
• イメージタイプはrbdです。
• コンピューティング ドライバーは libvirt です。

仮想マシンを起動する前に、まずルート ディスク (Nova ではイメージと呼ばれます) を準備する必要があります。 Glance と同様に、Nova のイメージはローカル ディスク、Ceph、Cinder (ボリュームからのブート) のストレージもサポートします。画像が保存される場所は画像の種類によって決まることに注意してください。 raw、qcow2、ploop などでローカルディスクに保存できます。イメージタイプが rbd の場合、イメージは Ceph に保存されます。異なる画像タイプは、異なる画像バックエンドによって管理されます。 rbd バックエンドは、nova/virt/libvirt/imageackend の Rbd クラス モジュールによって実装されます。

4 シンダー

4.1 Cinderの紹介

Cinder は AWS の EBS に似た OpenStack のブロック ストレージ サービスであり、管理するエンティティはボリュームです。 Cinder はボリュームプロバイダー機能を実装していませんが、Ceph、Fujitsu、NetApp などのさまざまなストレージシステムのボリュームの管理を担当します。ボリュームの作成、スナップショット、バックアップなどの機能をサポートしています。接続されたストレージ システムはバックエンドと呼ばれます。 cinder/volume/driver.py の VolumeDriver クラスで定義されたインターフェースが実装されている限り、Cinder はストレージ システムに接続できます。

Cinder はローカル ボリュームの管理をサポートするだけでなく、別の Ceph クラスターや Swift オブジェクト ストレージ システムなどのリモート ストレージ システムにローカル ボリュームをバックアップすることもできます。この記事では、ソース Ceph クラスターからリモート Ceph クラスターにバックアップするケースのみを検討します。

5 結論

5.1 概要

1. 画像をアップロードする

rbd -p ${GLANCE_POOL}を作成  --size ${SIZE} ${IMAGE_ID}rbd -p ${GLANCE_POOL} スナップ作成 ${IMAGE_ID}@snap  
 rbd -p ${GLANCE_POOL} スナップ保護 ${IMAGE_ID}@snap

2. 画像を削除する

rbd -p ${GLANCE_POOL} スナップ ${IMAGE_ID}@snap の保護を解除
rbd -p ${GLANCE_POOL} スナップ rm ${IMAGE_ID}@snap
 rbd -p ${GLANCE_POOL} rm ${IMAGE_ID}

5.2 ノヴァ

1 仮想マシンを作成する

rbd クローン \${GLANCE_POOL}/${IMAGE_ID}@snap \${NOVA_POOL}/${SERVER_ID}_disk

2 仮想マシンのスナップショットを作成する

# ディスクのスナップショットを作成し、それをGlanceのストレージ プールにクローンします。rbd -p ${NOVA_POOL} snap create \${SERVER_ID}_disk@${RANDOM_UUID}rbd -p ${NOVA_POOL} snap protect \${SERVER_ID}_disk@${RANDOM_UUID}rbd clone \${NOVA_POOL}/${SERVER_ID}_disk@${RANDOM_UUID} \${GLANCE_POOL}/${IMAGE_ID} # イメージをフラット化して、ソース スナップショットから切り離します。rbd -p ${GLANCE_POOL} flatten ${IMAGE_ID} # ソース スナップショットの処理がすべて完了したので、クリーンアップします。rbd -p ${NOVA_POOL} snap unprotect \${SERVER_ID}_disk@${RANDOM_UUID}rbd -p ${NOVA_POOL} snap rm \${SERVER_ID}_disk@${RANDOM_UUID} #アップロードされたイメージに「 snap」という保護されたスナップショットを作成し、それを outrbd -p ${GLANCE_POOL} snap create ${IMAGE_ID}@snap に渡します
rbd -p ${GLANCE_POOL} スナップ保護 ${IMAGE_ID}@snap

3 仮想マシンの削除

$(rbd -p ${NOVA_POOL} ls | grep "^${SERVER_ID}" );内のイメージに対して
    rbd -p ${NOVA_POOL} rm "$image" ;終わり

5.3 シンダー

1 ボリュームを作成する

（１）空のボリュームを作成する

rbd -p ${CINDER_POOL}を作成します\ --new-format --size ${SIZE} \volume-${VOLUME_ID}  

（２）スナップショットから作成

rbd clone \${CINDER_POOL}/volume-${SOURCE_VOLUME_ID}@snapshot-${SNAPSHOT_ID} \${CINDER_POOL}/volume-${VOLUME_ID}rbd resize --size ${SIZE} \openstack/volume-${VOLUME_ID}  

（３）ボリュームから作成

# rbd_max_clone_depth <= 0 の場合は完全コピーを実行します。if [[ "$rbd_max_clone_depth" -le 0 ]];それから 
    rbd コピー \
    ${CINDER_POOL}/ボリューム-${SOURCE_VOLUME_ID} \
    ${CINDER_POOL}/ボリューム-${VOLUME_ID}
    exit 0fi# それ以外の場合は COW クローンを実行します。#ソースボリュームの新しいスナップショットを作成しますrbd snap create \${CINDER_POOL}/volume-${SOURCE_VOLUME_ID}@volume-${VOLUME_ID}.clone_snap
 rbd snap protect \${CINDER_POOL}/volume-${SOURCE_VOLUME_ID}@volume-${VOLUME_ID}.clone_snap# ソースボリュームのスナップショットをクローンしますrbd clone \${CINDER_POOL}/volume-${SOURCE_VOLUME_ID}@volume-${VOLUME_ID}.clone_snap \${CINDER_POOL}/volume-${VOLUME_ID}# 宛先ボリュームがクローンであり、 rbd_max_clone_depth に達した場合は、# クローン作成後に宛先をフラット化します。depth=$(get_clone_depth ${CINDER_POOL}/volume-${VOLUME_ID})if [[ "$depth" -ge "$rbd_max_clone_depth" ]];それから 
    # 宛先ボリュームをフラット化する
    rbd フラット化 ${CINDER_POOL}/ボリューム-${VOLUME_ID}
    #一時スナップを削除
    rbd スナップ保護解除 \
    ${CINDER_POOL}/volume-${SOURCE_VOLUME_ID}@volume-${VOLUME_ID}.clone_snap
    rbd スナップ rm \
    ${CINDER_POOL}/volume-${SOURCE_VOLUME_ID}@volume-${VOLUME_ID}.clone_snapfi

（４）イメージから作成する

rbd clone \${GLANCE_POOL}/${IMAGE_ID}@snap \${CINDER_POOL}/volume-${VOLUME_ID}if [[ -n "${SIZE}" ]];それから 
    rbd resize --size ${SIZE} ${CINDER_POOL}/volume-${VOLUME_ID}fi  

2 スナップショットを作成する

rbd -p ${CINDER_POOL} スナップ作成\volume-${VOLUME_ID}@snapshot-${SNAPSHOT_ID}rbd -p ${CINDER_POOL} スナップ保護 \volume-${VOLUME_ID}@snapshot-${SNAPSHOT_ID}

3 バックアップを作成する

（１）最初のバックアップ

rbd -p ${BACKUP_POOL}を作成\
 --size ${ボリュームサイズ} \  
ボリューム-${VOLUME_ID}.backup.base
 NEW_SNAP=ボリューム-${VOLUME_ID}@backup.${BACKUP_ID}.snap.${タイムスタンプ}
 rbd -p ${CINDER_POOL} スナップ${NEW_SNAP}を作成します
rbd エクスポート-diff ${CINDER_POOL}/volume-${VOLUME_ID}${NEW_SNAP} - \
 | rbd import-diff --pool ${BACKUP_POOL} - \  
ボリューム-${VOLUME_ID}.backup.base

（２）増分バックアップ

rbd -p ${CINDER_POOL} snap create \volume-${VOLUME_ID}@backup.${BACKUP_ID}.snap.${TIMESTAMP} rbd export-diff --pool ${CINDER_POOL} \--from-snap backup.${PARENT_ID}.snap.${ LAST_TIMESTAMP } \${CINDER_POOL}/volume-${VOLUME_ID}@backup.${BACKUP_ID}.snap.${TIMESTAMP} - \| rbd import-diff --pool ${BACKUP_POOL} - \${BACKUP_POOL}/volume-${VOLUME_ID}.backup.base  
 rbd -p ${CINDER_POOL} スナップ rm \volume-${VOLUME_ID}.backup.base@backup.${PARENT_ID}.snap.${LAST_TIMESTAMP}

4 バックアップとリカバリ

rbd export-diff --pool ${BACKUP_POOL} \volume-${SOURCE_VOLUME_ID}.backup.base@backup.${BACKUP_ID}.snap.${TIMESTRAMP} - \| rbd import-diff --pool ${CINDER_POOL} - \volume-${DEST_VOLUME_ID}rbd -p ${CINDER_POOL} resize \--size ${new_size} volume-${DEST_VOLUME_ID}