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

[[212344]]

1 背景

1.1 Ceph の紹介

Ceph は、高いスケーラビリティ、高いパフォーマンス、高い信頼性の利点を備えた、非常に人気のあるオープンソースの分散ストレージシステムです。また、ブロックストレージサービス (rbd)、オブジェクトストレージサービス (rgw)、ファイルシステムストレージサービス (cephfs) も提供します。これは現在、OpenStack の主流のバックエンドストレージであり、OpenStack に兄弟のように近い存在であり、OpenStack に統合された共有ストレージサービスを提供します。 Ceph を OpenStack バックエンドストレージとして使用すると、次の利点があります。

すべてのコンピューティングノードはストレージを共有するため、移行中にルートディスクをコピーする必要はありません。コンピューティングノードがクラッシュした場合でも、仮想マシンは別のコンピューティングノード上ですぐに起動できます (退避)。
COW (Copy On Write) 機能を使用すると、仮想マシンを作成するときに、イメージ全体をダウンロードせずに、イメージに基づいてクローンを作成するだけで済みます。クローン作成操作には基本的にオーバーヘッドがないため、数秒で仮想マシンを作成できます。
Ceph RBD はシンプロビジョニングをサポートしています。これは、オンデマンドでスペースを割り当てることを意味し、Linux ファイルシステムのスパースファイルに似ています。 20 GB の仮想ハードディスクを作成すると、最初は物理的なストレージ領域を占有しません。ストレージスペースは、データが書き込まれるときにのみオンデマンドで割り当てられます。

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

 rbd snap create --pool openstack --image test-image --snap test-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 export-diff int32bit-test-1 --from-snap snap-1 --snap snap-2 int32bit-test-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 ソースコードの読み方に関する以前の記事を参照してください。

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

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

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

なお、この記事では最初にソースコードを掲載しますが、これは非常に長くて退屈です。概要セクションにすぐにジャンプして、各 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 アドレスからイメージをダウンロードします。

2.2 画像のアップロード

前回の紹介からわかるように、画像のアップロードは主にストアの add メソッドによって実装されます。

 @機能チェック 
 def add (self, image_id, image_file, image_size, context=None,
        検証者=なし):
    チェックサム = hashlib.md5()
    画像名 = str(画像ID)
 self.get_connection(conffile=self.conf_file,で
                             rados_id= self.user )を connとして:
        fsid = なし
        hasattr(conn, 'get_fsid' )の場合:
            fsid = conn.get_fsid()
 conn.open_ioctx(self.pool)をioctxとして使用します。
順序= int (math.log(self.WRITE_CHUNKSIZE, 2))
            試す：
                loc = self._create_image(fsid, conn, ioctx, イメージ名,
                                         画像サイズ、順序)
 rbd.ImageExistsを除く:
                msg = _( 'RBD イメージ %s は既に存在します' ) % image_id
                例外を発生させます。重複(メッセージ=msg)
                ...

image_file はファイルではなく、イメージのすべてのデータを保存し、read(bytes) メソッドを通じてイメージの内容を読み取る LimitingReader インスタンスであることに注意してください。

上記のソースコードから、glance はまず ceph 接続セッションを取得し、次に _create_image メソッドを呼び出して、イメージと同じサイズの rbd イメージを作成します。

 def _create_image(self, fsid, conn, ioctx, イメージ名,
サイズ、順序、コンテキスト=なし):
    librbd = rbd.RBD()
    機能 = conn.conf_get( 'rbd_default_features' )
    librbd。作成(ioctx、イメージ名、サイズ、順序、古いフォーマット= False 、
                  機能 = int (機能))
店舗所在地を返す({
 'fsid' : fsid,
 'プール' : self.pool,
 '画像' : 画像名,
 'スナップショット' : DEFAULT_SNAPNAME、
    }, self.conf)

したがって、上記の手順は、rbd コマンドを通じて大まかに表現されます。

 rbd -p ${rbd_store_pool}を作成します  --size ${画像サイズ} ${画像ID}

ceph で rbd イメージを作成したら、次のようにします。

 rbd.Image(ioctx, image_name)をイメージとして使用します:
    書き込まれたバイト数 = 0
    オフセット = 0
    チャンク = utils.chunkreadable(image_file,
                                 自己.WRITE_CHUNKSIZE)
チャンク内のチャンクの場合:
        オフセット += image.write(チャンク, オフセット)
        チェックサム更新(チャンク)

Glance は image_file からブロックごとにデータを読み取り、新しく作成された rbd イメージに書き込み、チェックサムを計算していることがわかります。ブロックサイズは rbd_store_chunk_size によって構成され、デフォルトは 8MB です。

*** ステップを見てみましょう:

 loc.snapshotの場合:
    image.create_snap(loc.snapshot)
    image.protect_snap(loc.snapshot)

コードからわかるように、最初のステップはイメージスナップショット (スナップショットの名前は snap) を作成し、それを保護することです。

アップロードしたイメージが cirros、イメージサイズが 39 MB、イメージ UUID が d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6、設定が ceph の openstack プールに保存されていると仮定すると、対応する ceph 操作プロセスはおおよそ次のようになります。

 rbd -p オープンスタック作成  --サイズ 39 d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6  
 rbd -p openstack スナップ作成d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@snap
 rbd -p openstack スナップ保護 d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@snap

これは rbd コマンドで確認できます。

 int32bit rbd ls -l | grep d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6
 d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6 40162k 2
 d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@snap 40162k 2 はい

意味合い

これまで、Ceph にイメージをアップロードするプロセスを紹介してきましたが、Glance にイメージをアップロードするプロセスは省略しました。ただし、画像は Glance API を介して Glance にアップロードする必要があることは間違いありません。画像が非常に大きい場合、Glance API を介して HTTP プロトコルが使用されますが、これは非常に時間がかかり、API 管理ネットワークの帯域幅を占有します。 rbd import を通じて画像を直接インポートすることで、画像のアップロードの効率を大幅に向上できます。

まず、Glance を使用して空のイメージを作成し、その uuid をメモします。

一目でわかるイメージ-作成

uuid が d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6 であると仮定して、rbd コマンドを使用してイメージを直接インポートし、スナップショットを作成します。

 rbd -p openstack import cirros.raw --image=d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6  
 rbd -p openstack スナップ作成d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@snap
 rbd -p openstack スナップ保護 d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@snap

Glance ミラーの場所の URL を設定します。

 FS_ID=`ceph -s | grep クラスター | awk '{print $2}' `
一目で場所を確認- 追加  --url rbd://${FS_ID}/openstack/d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6/snap d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6

Glance イメージのその他のプロパティを設定します。

一目でわかる画像 -更新  --name="シロ" \  
 --ディスクフォーマット=raw --コンテナフォーマット=bare d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6

2.3 画像の削除

イメージを削除する場合は、逆のプロセスになります。つまり、次のように、最初に unprotext -> snap rm -> rm を実行します。

試す：
    self._unprotect_snapshot(イメージ、スナップショット名)
    image.remove_snap(スナップショット名)
 rbd.ImageBusyを除く:
    例外を発生させる。InUseByStore()
 rbd.RBD().remove(ioctx, イメージ名)

イメージを削除するときは、現在の rbd イメージにサブイメージがないことを確認する必要があります。サブイメージがないと、削除は失敗します。

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 クラスモジュールによって実装されます。

3.2 仮想マシンを作成する

仮想マシンを作成するプロセスについては詳細に分析しません。よく分からない場合は、以前のブログを確認してください。 Nova の libvirt ドライバーが仮想マシンのルートディスクイメージをどのように準備するかを直接学習してみましょう。コードは nova/virt/libvirt/driver.py の spawn メソッドにあり、イメージを作成するために _create_image メソッドが呼び出されます。

 def spawn(self, コンテキスト, インスタンス, image_meta, 注入されたファイル,
          admin_password、network_info=なし、block_device_info=なし):
    ...
    self._create_image(コンテキスト、インスタンス、disk_info[ 'マッピング' ]、
                       injection_info=注入情報、
                       ブロックデバイス情報=ブロックデバイス情報)
    ...

_create_image メソッドのコードは次のとおりです。

 def _create_image(self, コンテキスト, インスタンス,
                  disk_mapping、injection_info=なし、サフィックス= '' 、
                  disk_images=なし、block_device_info=なし、
                  fallback_from_host=なし、
                  ignore_bdi_for_swap = False ):
    booted_from_volume = self._is_booted_from_volume(block_device_info)
    ...
    # ディレクトリが存在し、書き込み可能であることを確認する
    fileutils.ensure_tree(libvirt_utils.get_instance_path(インスタンス))
    ...
    self._create_and_inject_local_root(コンテキスト、インスタンス、
                                       booted_from_volume、サフィックス、
                                       ディスクイメージ、インジェクション情報、
                                       フォールバック元ホスト
    ...

このメソッドは、まず仮想マシンのデータディレクトリ /var/lib/nova/instances/${uuid}/ をローカルに作成し、次に _create_and_inject_local_root メソッドを呼び出してルートディスクを作成します。

 def _create_and_inject_local_root(self, コンテキスト, インスタンス,
                                  booted_from_volume、サフィックス、ディスクイメージ、
                                  injection_info、fallback_from_host):
    ...
    booted_from_volumeでない場合:
        root_fname = imagecache.get_cache_fname(disk_images[ 'image_id' ])
サイズ= instance.flavor.root_gb * 単位.Gi
        backend = self.image_backend.by_name(インスタンス、 'ディスク' + サフィックス、
                                             CONF.libvirt.images_type)
        backend.SUPPORTS_CLONEの場合:
            def clone_fallback_to_fetch(*args, **kwargs):
                試す：
                    backend.clone(コンテキスト、disk_images[ 'image_id' ])
例外を除く。ImageUnacceptable:
                    libvirt_utils.fetch_image(*引数、**キーワード)
            fetch_func = clone_fallback_to_fetch
それ以外：
            fetch_func = libvirt_utils.fetch_image
        self._try_fetch_image_cache(バックエンド、fetch_func、コンテキスト、
                                    root_fname、ディスクイメージ[ 'image_id' ]、
                                    インスタンス、サイズ、fallback_from_host)
        ...

image_backend.by_name() メソッドは、イメージタイプ名 (ここでは Rbd) でイメージバックエンドインスタンスを返します。コードから、バックエンドがクローン操作 (SUPPORTS_CLONE) をサポートしている場合はバックエンドの clone() メソッドが呼び出され、サポートしていない場合は fetch_image() メソッドを通じてイメージがダウンロードされることがわかります。明らかに、Ceph rbd はクローンをサポートしています。 Rbd の clone() メソッドを見てみましょう。コードは nova/virt/libvirt/imagebackend.py モジュールにあります:

 def clone(self, context, image_id_or_uri):
    ...
場所内の場所:
        self.driver.is_cloneable(location, image_meta): の場合
            LOG.debug( '選択された場所: %(loc)s' , { 'loc' : location})
 self.driver.clone(location, self.rbd_name)を返します。
    ...

このメソッドは、Glance イメージのすべての場所を走査し、driver.is_cloneable() メソッドを使用してクローン作成がサポートされているかどうかを判断します。クローン作成がサポートされている場合は、driver.clone() メソッドが呼び出されます。ドライバーは Nova のストレージドライバーで、コードは nova/virt/libvirt/storage にあり、rbd ドライバーは rbd_utils.py モジュールにあります。まず、is_cloneable() メソッドを確認しましょう。

 def is_cloneable(self、image_location、image_meta):
       url = 画像の場所[ 'url' ]
       試す：
           fsid、プール、イメージ、スナップショット = self.parse_url(url)
 exception.ImageUnacceptableを除き、 e:
戻る 間違い 
       self.get_fsid() != fsid の場合:
戻る 間違い 
       image_meta.get( 'disk_format' ) != 'raw'の場合:
戻る 間違い 
       #画像が読み取れるか確認する
       試す：
 self.exists(イメージ、プール=プール、スナップショット=スナップショット)を返します
rbd.Errorを除き、 e:
           LOG.debug( '画像 %(loc)s を開けません: %(err)s' ,
                     辞書(loc=url, err=e))
戻る 間違い

次の状況ではクローンがサポートされていないことがわかります。

Glance 内の rbd イメージの場所が不正です。 rbd の場所には、fsid、プール、イメージ ID、スナップショットの 4 つのフィールドが含まれている必要があります。フィールドは / で区切られます。
Glance と Nova は異なる Ceph クラスターに接続されています。
Glance 画像は RAW 形式ではありません。
Glance の rbd イメージには snap という名前のスナップショットがありません。

3番目の項目に特に注意してください。イメージが raw 形式でない場合、Nova は仮想マシンの作成時にクローン操作をサポートしないため、イメージは Glance からダウンロードする必要があります。このため、Glance が Ceph ストレージを使用する場合は、イメージを raw 形式に変換する必要があります。

*** clone メソッドを見てみましょう:

 def clone(self, image_location, dest_name, dest_pool=None):
    _fsid、プール、イメージ、スナップショット = self.parse_url(
            画像の場所[ 'url' ])
 RADOSClient(self, str(pool))をsrc_clientとして使用します。
 RADOSClient(self, dest_pool)をdest_clientとして使用します:
            試す：
                RbdProxy().clone(src_client.ioctx,
                                 画像、
                                 スナップショット、
                                 dest_client.ioctx、
                                 str(宛先名)、
                                 機能=src_client.features)
 rbd.PermissionErrorを除く:
                例外が発生します。Forbidden(_( '書き込み権限がありません'  
 'ストレージ プール %s' ) % dest_pool)

このメソッドは、Ceph の clone メソッドのみを呼び出します。同じ Ceph クラスターを使用する場合、なぜ 2 つの ioctx が必要なのか疑問に思う人もいるかもしれません。これは、Glance と Nova が同じ Ceph プールを使用しない可能性があり、1 つのプールが 1 つの ioctx に対応するためです。

上記の操作は、次の rbd コマンドとほぼ同等です。

 rbd クローン ${glance_pool}/${イメージ uuid}@snap ${nova_pool}/${仮想マシン uuid}.disk

Nova と Glance が使用するプールが両方とも openstack であり、Glance イメージの uuid が d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6、Nova 仮想マシンの uuid が cbf44290-f142-41f8-86e1-d63c902b38ed であると仮定すると、対応する rbd コマンドはおおよそ次のようになります。

 rbdクローン\
オープンスタック/d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@スナップ\
オープンスタック/cbf44290-f142-41f8-86e1-d63c902b38ed_ディスク

さらに次のことを確認しました:

 int32bit $ rbd -p openstack ls | grep cbf44290-f142-41f8-86e1-d63c902b38ed
 cbf44290-f142-41f8-86e1-d63c902b38ed_ディスク
int32ビット $ rbd -p openstack情報 cbf44290-f142-41f8-86e1-d63c902b38ed_disk
 rbdイメージ'cbf44290-f142-41f8-86e1-d63c902b38ed_disk' :
サイズ2048 MB 、オブジェクト数 256
オーダー23 (8192 kB オブジェクト)
        ブロック名プレフィックス: rbd_data.9f756763845e
        フォーマット: 2
        機能: レイヤー化、排他ロック、オブジェクト マップ、高速差分、ディープ フラット化
        フラグ:
        create_timestamp: 2017年11月22日水曜日 05:11:17
        親: openstack/d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@snap
        重複: 40162 kB

出力からわかるように、Nova は実際に cbf44290-f142-41f8-86e1-d63c902b38ed_disk という名前の rbd イメージを作成しており、その親は openstack/d1a06da9-8ccd-4d3e-9b63-6dcd3ead29e6@snap です。

意味合い

仮想マシンを作成するときに、イメージをコピーしたりダウンロードしたりする必要はありません。代わりに、単純なクローン操作なので、仮想マシンの作成は数秒で完了します。
イメージに依存する仮想マシンがある場合、イメージを削除することはできません。つまり、イメージを削除する前に、そのイメージに基づいて作成されたすべての仮想マシンを削除する必要があります。

3.3 仮想マシンのスナップショットの作成

まず最初に、本題から外れたことを言わせてください。 Nova がイメージの作成とスナップショットの作成を混同しているように感じます。私はこれら 2 つの違いを理解しています。

イメージの作成: 仮想マシンのルートディスクを Glance にアップロードします。
スナップショットの作成: イメージ形式に従って仮想マシンのスナップショットを作成します。 qcow2 と rbd の両方の形式は明らかにスナップショットをサポートしています。スナップショットは Glance に保存せず、Nova または Cinder (Cinder から起動) で管理する必要があります。

しかし実際には、Nova がスナップショットを作成するためのサブコマンドは image-create であり、API メソッドも _action_create_image() と呼ばれ、その後に呼び出されるメソッドは snapshot() と呼ばれます。実際、ほとんどのイメージタイプでは、クラウドハードディスクから起動されていない場合 (ボリュームから起動)、実際のスナップショットではなく、イメージが作成され、つまり Glance にイメージがアップロードされます。

もちろん、これは単なる名前の違いです。イメージの作成とスナップショットの作成に違いはありません。

仮想マシンのスナップショットは、libvirtdriver の snapshot() メソッドによって実装されます。コードは nova/virt/libvirt/driver.py にあります。コアコードは次のとおりです。

スナップショットを定義します(自己、コンテキスト、インスタンス、イメージ ID、タスクの状態の更新):
    ...
    ルートディスク = self.image_backend.by_libvirt_path(
        インスタンス、ディスクパス、イメージタイプ=ソースタイプ)
    試す：
        update_task_state(task_state=task_states.IMAGE_UPLOADING、
                          予想される状態 = task_states.IMAGE_PENDING_UPLOAD)
        メタデータ[ 'location' ] = root_disk.direct_snapshot(
            コンテキスト、スナップショット名、イメージフォーマット、イメージID、
            インスタンス.image_ref)
        self._snapshot_domain(コンテキスト、live_snapshot、virt_dom、状態、
                              実例）
        self._image_api です。更新（コンテキスト、image_id、メタデータ、
                               purge_props = False )
 (NotImplementedError、exception.ImageUnacceptable)を除き、 e:
        ...

Nova はまず、disk_path を通じて対応するイメージバックエンドを取得し、imagebackend.Rbd を返します。次に、バックエンドの direct_snapshot() メソッドを呼び出します。これは次のようになります。

 def direct_snapshot(self, コンテキスト, スナップショット名, イメージフォーマット,
                    イメージID、ベースイメージID):
    fsid = self.driver.get_fsid()
    parent_pool = self._get_parent_pool(コンテキスト、ベースイメージID、fsid) 
 
    self.driver.create_snap(self.rbd_name, スナップショット名, protect= True )
    場所 = { 'url' : 'rbd://%(fsid)s/%(pool)s/%(image)s/%(snap)s' %
                       dict(fsid=fsid,
                            プール=self.pool、
                            イメージ=self.rbd_name、
                            snap=スナップショット名)}
    試す：
        self.driver.clone(場所、イメージID、dest_pool=親プール)
        self.driver.flatten(イメージID、プール=親プール)
    ついに：
        self.cleanup_direct_snapshot(場所)
    self.driver.create_snap(image_id, 'snap' , pool=parent_pool,
                            保護 = True )
戻り値( 'rbd://%(fsid)s/%(pool)s/%(image)s/snap' %
            dict(fsid=fsid, pool=parent_pool, image=image_id))

コードを分析すると、おおまかに次のステップに分けられます。

Ceph クラスターの fsid を取得します。
仮想マシンのルートディスクに対応する rbd イメージの一時スナップショットを作成します。スナップショット名はランダムな UUID です。
作成したスナップショットを保護します（保護）。
スナップショットに基づいて、スナップショット uuid という名前の新しい rbd イメージを複製します。
クローンされたイメージに対してフラット化操作を実行します。
作成された一時スナップショットを削除します。
クローンされた rbd イメージのスナップショットを作成し、snap という名前を付けて、protect を実行します。

rbd コマンドに対応して、仮想マシンの uuid が cbf44290-f142-41f8-86e1-d63c902b38ed で、スナップショットの uuid が db2b6552-394a-42d2-9de8-2295fe2b3180 であると仮定すると、対応する rbd コマンドは次のようになります。

 # ディスクのスナップショットを作成し、 Glance のストレージ プールにクローンします
rbd -p openstackスナップ作成\
 cbf44290-f142-41f8-86e1-d63c902b38ed_disk@3437a9bbba5842629cc76e78aa613c70
 rbd -p openstack スナップ保護 \
 cbf44290-f142-41f8-86e1-d63c902b38ed_disk@3437a9bbba5842629cc76e78aa613c70
 rbd -p openstackクローン\
 cbf44290-f142-41f8-86e1-d63c902b38ed_disk@3437a9bbba5842629cc76e78aa613c70 \
 db2b6552-394a-42d2-9de8-2295fe2b3180
 # イメージをフラット化して、ソーススナップショットから切り離します
rbd -p openstack フラット化 db2b6552-394a-42d2-9de8-2295fe2b3180
 #ソーススナップショットはすべて完了しました。クリーンアップします
rbd -p openstack snap の保護を解除 \
 cbf44290-f142-41f8-86e1-d63c902b38ed_disk@3437a9bbba5842629cc76e78aa613c70
 rbd -p openstack スナップ rm \
 cbf44290-f142-41f8-86e1-d63c902b38ed_disk@3437a9bbba5842629cc76e78aa613c70
 # 'snap'という保護されたスナップショットを作成します アップロードされた画像にそれを配布する 
 rbd -p openstack スナップ作成db2b6552-394a-42d2-9de8-2295fe2b3180@snap
 rbd -p openstack スナップ保護 db2b6552-394a-42d2-9de8-2295fe2b3180@snap

3437a9bbba5842629cc76e78aa613c70 は一時スナップショットの名前であり、ランダムに生成された UUID です。

意味合い

他のストレージバックエンドでは主にイメージのアップロードに時間がかかりますが、Ceph ストレージを使用する場合は主に rbd フラット化プロセスに時間がかかるため、仮想マシンのスナップショットの作成には通常数分かかります。なぜフラット化操作を実行する必要があるのか疑問に思う人もいるかもしれません。直接クローンすることはできないのでしょうか?コミュニティがこれを実行するのには理由があります:

フラット化操作が実行されない場合、仮想マシンのスナップショットは仮想マシンに依存します。つまり、スナップショットが存在する限り仮想マシンを削除することはできず、これは明らかに不合理です。
前の質問を拡張して、スナップショットに基づいて仮想マシンが作成され、仮想マシンがスナップショットを作成し、このサイクルが繰り返されるとします。 rbd イメージ全体の依存関係が非常に複雑になり、管理できなくなります。
rbd イメージチェーンが長くなるにつれて、対応する IO 読み取りおよび書き込みパフォーマンスも低下します。
…

3.4 仮想マシンの削除

libvirt ドライバーが仮想マシンを削除するコードは、nova/virt/libvirt/driver.py の destroy メソッドにあります。

 def destroy(self, context, instance, network_info, block_device_info=None,
                destroy_disks = True ):
    self._destroy(インスタンス)
    self.cleanup(コンテキスト、インスタンス、ネットワーク情報、ブロックデバイス情報、
                 ディスクを破棄する

前の _destroy メソッドは実際には仮想マシンのシャットダウン操作であることに注意してください。つまり、Nova は最初に仮想マシンをシャットダウンしてから削除操作を実行します。次に、cleanup() メソッドが呼び出され、リソースのクリーンアップが実行されます。ここでは、ディスクをクリーニングするプロセスにのみ焦点を当てます。

 ...
 destroy_disksの場合:
    # NOTE(haomai): 必要に応じてボリュームを破棄する
    CONF.libvirt.images_type == 'lvm'の場合:
        self._cleanup_lvm(インスタンス、ブロックデバイス情報)
    CONF.libvirt.images_type == 'rbd'の場合:
        self._cleanup_rbd(インスタンス)
 ...

イメージタイプは rbd なので、_cleanup_rbd() メソッドが呼び出されます。

 def _cleanup_rbd(self, インスタンス):
    instance.task_state == task_states.RESIZE_REVERTING の場合:
        filter_fn = lambda disk: (disk.startswith(instance.uuid)および 
                                  ディスク.endswith( 'ディスク.local' ))
それ以外：
        filter_fn = lambda ディスク: disk.startswith(instance.uuid)
    LibvirtDriver._get_rbd_driver().cleanup_volumes(filter_fn)

通常の削除操作のみを考慮し、サイズ変更の元に戻す操作は無視します。そのため、filter_fn は lambda disk: disk.startswith(instance.uuid)、つまり仮想マシンの uuid で始まるすべてのディスク (rbd イメージ) になります。ここでは imagebackend の Rbd ドライバーは呼び出されず、ストレージドライバーが直接呼び出されることに注意してください。コードは nova/virt/libvirt/storage/rbd_utils.py にあります:

 cleanup_volumesを定義します(self、filter_fn):
 RADOSClient(self, self.pool)をクライアントとして使用します:
        ボリューム = RbdProxy().list(client.ioctx)
フィルター内のボリューム(filter_fn, volumes):
            self._destroy_volume(クライアント、ボリューム)

このメソッドは、まずすべての rbd イメージのリストを取得し、次に filter_fn メソッドを使用して仮想マシンの uuid から始まるイメージをフィルタリングし、_destroy_volume メソッドを呼び出します。

 def _destroy_volume(self, client, volume, pool=None):
 "" "RBD ボリュームを破棄し、必要に応じて再試行します。" ""  
    def _cleanup_vol(ioctx、ボリューム、retryctx):
        試す：
            RbdProxy().remove(ioctx, ボリューム)
            loopingcall.LoopingCallDone(retvalue= False )を発生させます。
 rbd.ImageHasSnapshotsを除く:
            self.remove_snap(ボリューム、libvirt_utils.RESIZE_SNAPSHOT_NAME、
                             ignore_errors = True )
 (rbd.ImageBusy、rbd.ImageHasSnapshotsを除く):
            LOG.warning( 'rbd によるプール %(pool)s 内の %(volume)s の削除に失敗しました' ,
                        { 'volume' : ボリューム、 'pool' : self.pool})
        retryctx[ '再試行' ] -= 1
        retryctx[ 'retries' ] <= 0の場合:
            loopingcall.LoopingCallDone() を発生させる
 
    # NOTE(danms): 10秒間放置します
    retryctx = { '再試行' : 10}
    タイマー = loopingcall.FixedIntervalLoopingCall(
        _cleanup_vol、client.ioctx、ボリューム、retryctx)
    timed_out = timer.start(interval=1).wait()
    タイムアウトの場合:
        # NOTE(danms):エラーを伝播させるためにこれをもう一度実行しますが、
        # 成功した場合は、loopingcall例外を発生させない
        試す：
            _cleanup_vol(クライアント.ioctx、ボリューム、再試行ctx)
 loopingcall.LoopingCallDoneを除く:
            合格

このメソッドは、_cleanup_vol() メソッドを使用して rbd イメージを最大 10+1 回削除しようとします。スナップショットがある場合は、まずそれが削除されます。

仮想マシンの uuid が cbf44290-f142-41f8-86e1-d63c902b38ed であると仮定すると、対応する rbd コマンドはおおよそ次のようになります。

イメージの場合は$(rbd -p openstack ls | grep '^cbf44290-f142-41f8-86e1-d63c902b38ed' );
 rbd -p openstack rm "$image"を実行します。
終わり

4 シンダー

4.1 Cinderの紹介

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

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

4.2 ボリュームの作成

ボリュームは cinder-volume サービスによって作成され、エントリポイントは cinder/volume/manager.py の create_volume() メソッドです。

 def create_volume(self, context, volume, request_spec=None,
                  filter_properties=なし、allow_reschedule= True ):
    ...
    試す：
        # NOTE(flaper87): ドライバの初期化は 
        #タスク自体によって検証されます。
        フローエンジン = create_volume.get_flow(
            コンテキスト_昇格、
            自己、
            自己.db、
            自己ドライバー、
            自己.scheduler_rpcapi、
            自己ホスト、
            音量、
            再スケジュールを許可、
            コンテクスト、
            リクエスト仕様、
            フィルタープロパティ、
            image_volume_cache=self.image_volume_cache、
        ）
例外を除く:
        msg = _( "マネージャーボリュームフローの作成に失敗しました。" )
        LOG.exception(msg、リソース={ 'type' : 'volume' 、 'id' :volume.id})
        例外を発生させます。CinderException(msg)
 ...

Cinder はタスクフローフレームワークを使用してボリュームを作成します。タスクフローの具体的な実装は、cinder/volume/flows/manager/create_volume.py にあります。ここでは、execute() メソッドに注目します。

 def execute (self、コンテキスト、ボリューム、ボリュームスペック):
    ...
    create_type == 'raw'の場合:
        model_update = self._create_raw_volume(ボリューム、**volume_spec)
    elif create_type == 'snap' の場合:
        model_update = self._create_from_snapshot(コンテキスト、ボリューム、
                                                  **ボリュームスペック)
    elif create_type == 'source_vol' :
        model_update = self._create_from_source_volume(
            コンテキスト、ボリューム、**volume_spec)
    elif create_type == 'image' :
        model_update = self._create_from_image(コンテキスト、
                                               音量、
                                               **ボリュームスペック)
それ以外：
        例外が発生します。VolumeTypeNotFound(volume_type_id=create_type)
    ...

コードから、ボリューム作成には 4 つのタイプがあることがわかります。

raw: 空のボリュームを作成します。
スナップショットから作成: スナップショットに基づいてボリュームを作成します。
ボリュームから作成: これは既存のボリュームをコピーするのと同じです。
イメージから作成: Glance イメージに基づいてボリュームを作成します。

生

最も簡単な方法は、空のボリュームを作成することです。コードは次のとおりです。

 def _create_raw_volume(self, ボリューム, **kwargs):
    ret = self.driver.create_volume(ボリューム)
    ...

ドライバーの create_volume() メソッドを直接呼び出します。ドライバーは RBDDriver で、コードは cinder/volume/drivers/rbd.py にあります。

 def create_volume(self, ボリューム):
 RADOSClient(self)をクライアントとして:
        self.RBDProxy() です。作成(client.ioctx、
                               ボリューム名、
サイズ、
注文、
                               古いフォーマット = False 、
                               機能=クライアント.機能) 
 
        試す：
            volume_update = self._enable_replication_if_needed(ボリューム)
例外を除く:
            self.RBDProxy().remove(client.ioctx、vol_name) を実行します。
            err_msg = (_( 'イメージのレプリケーションを有効にできませんでした' ))
            例外を発生させます。ReplicationError(reason=err_msg,
                                             ボリュームID=ボリュームID)

サイズの単位は MB で、vol_name は volume-${volume_uuid} です。

ボリュームの uuid が bf2d1c54-6c98-4a78-9c20-3e8ea033c3db、Ceph プールが openstack、作成されたボリュームのサイズが 1GB であると仮定すると、対応する rbd コマンドは次のようになります。

 rbd -p openstack作成\
 --新しいフォーマット --サイズ 1024 \  
ボリューム-bf2d1c54-6c98-4a78-9c20-3e8ea033c3db

これは rbd コマンドで確認できます。

 int32bit $ rbd -p openstack ls | grep bf2d1c54-6c98-4a78-9c20-3e8ea033c3db
ボリューム-bf2d1c54-6c98-4a78-9c20-3e8ea033c3db

スナップショットから作成

スナップショットからボリュームを作成する場合も、次のようにドライバーメソッドを直接呼び出します。

 def _create_from_snapshot(self, コンテキスト, ボリューム, スナップショットID,
                          ** クワルグ):
    スナップショット = objects.Snapshot.get_by_id(コンテキスト、スナップショットID)
    model_update = self.driver.create_volume_from_snapshot(ボリューム、
                                                           スナップショット

RBDDriver の create_volume_from_snapshot() メソッドを見てみましょう。

 def create_volume_from_snapshot(自己、ボリューム、スナップショット):
 "" "スナップショットからボリュームを作成します。" 「」  
    volume_update = self._clone(ボリューム、self.configuration.rbd_pool、
                                snapshot.volume_name、スナップショット。名前）
    self.configuration.rbd_flatten_volume_from_snapshotの場合:
        self._flatten(self.configuration.rbd_pool、ボリューム名)
    int (volume.size )の場合:
        self._resize(ボリューム)
ボリューム更新を返す

コードからわかるように、スナップショットからスナップショットを作成する手順は 3 つのステップに分かれています。

rbd スナップショットからクローン操作を実行します。
rbd_flatten_volume_from_snapshot が True に設定されている場合、フラット化操作が実行されます。
作成時にサイズが指定されている場合は、サイズ変更操作が実行されます。

新しく作成されたボリュームの uuid が e6bc8618-879b-4655-aac0-05e5a1ce0e06、スナップショットの uuid が snapshot-e4e534fc-420b-45c6-8e9f-b23dcfcb7f86、スナップショットのソースボリューム uuid が bf2d1c54-6c98-4a78-9c20-3e8ea033c3db、指定されたサイズが 2、rbd_flatten_volume_from_snapshot が False (デフォルト値) であると仮定すると、対応する rbd コマンドは次のようになります。

 rbd クローン openstack/volume-bf2d1c54-6c98-4a78-9c20-3e8ea033c3db@snapshot-e4e534fc-420b-45c6-8e9f-b23dcfcb7f86 openstack/volume-e6bc8618-879b-4655-aac0-05e5a1ce0e06  
 rbd resize --size 2048 openstack/volume-e6bc8618-879b-4655-aac0-05e5a1ce0e06

ソースコードの分析から、Cinder がスナップショットからボリュームを作成するときに、ユーザーはフラット化操作を実行するかどうかを構成できます。

フラット化操作を実行する場合、スナップショットからボリュームを作成するのに数分かかる場合があります。スナップショットは作成後いつでも削除できます。
フラット化操作を実行しない場合は、スナップショットに基づいて作成されたすべてのボリュームを削除する前に、スナップショットまたはスナップショットのソースボリュームを削除できないことに注意してください。

2 番目の点はより複雑かもしれません。たとえば、スナップショットに基づいてボリュームが作成され、そのボリュームに基づいてスナップショットが作成され、そのスナップショットに基づいてボリュームが作成された場合、ユーザーはソースボリュームまたはスナップショットを削除できません。

ボリュームから作成

ボリュームからボリュームを作成するには、ソースボリューム ID (source_volid) を指定する必要があります。

 def _create_from_source_volume(self, コンテキスト, ボリューム, ソースボリュームid,
                               ** クワルグ):
    # NOTE(harlowja): ソースボリュームが消えてしまった場合、これが
    #このデータベース呼び出しは失敗するはずなので、それを検出します。
    #
    # NOTE(harlowja): これはおそらく これが起こるには最適な場所ではない
    #そして、アクションの実行中はソースボリュームに適切なロックをかける必要があります
    ソースボリュームを使用する # が進行中です。
    srcvol_ref = objects.Volume.get_by_id(コンテキスト、ソースボリュームID)
    model_update = self.driver.create_cloned_volume(ボリューム、srcvol_ref)

ドライバーの create_cloned_volume() メソッドを直接確認します。このメソッドには、rbd イメージクローンに対して許可される最大深度である、非常に重要な構成項目 rbd_max_clone_depth があります。 rbd_max_clone_depth <= 0 の場合、クローン作成は許可されません。

 #要求があれば完全なコピーを行う
self.configuration.rbd_max_clone_depth <= 0 の場合:
 RBDVolumeProxy(self, src_name, read_only= True )を volとして使用します。
        vol.copy(vol.ioctx, 宛先名)
        self._extend_if_required(ボリューム、src_vref)
戻る

これは rbd copy コマンドと同等です。

rbd_max_clone_depth > 0 の場合:

 # それ以外の場合は COW クローンを実行します。
 RADOSClient(self)をクライアントとして:
    src_volume = self.rbd.Image(client.ioctx、src_name)
    LOG.debug( "スナップショットを作成しています='%s'" 、 clone_snap)
    試す：
        #ソースボリュームの新しいスナップショットを作成する
        src_volume.create_snap(クローン_snap)
        src_volume.protect_snap(クローン_snap)
        # ソースボリュームのスナップショットをクローンします
        LOG.debug( "'%(src_vol)s@%(src_snap)s' を " にクローンしています 
 「'%(dest)s'」 、
                  { 'src_vol' : src_name, 'src_snap' : clone_snap,
 'dest' : 宛先名})
        self.RBDProxy().clone(client.ioctx, src_name, clone_snap,
                              client.ioctx、dest_name、
                              機能=クライアント.機能)

このプロセスは、仮想マシンのスナップショットを作成するプロセスと非常に似ています。どちらも、まずソースイメージに基づいてスナップショットを作成し、次にスナップショットに基づいてクローン操作を実行します。違いは、フラット化操作が実行されるかどうかにあります。仮想マシンのスナップショットを作成するときは、フラット化操作を実行する必要があり、操作はクローンの深さによって異なります。

深さ = self._get_clone_depth(クライアント、src_name)
深さ >= self.configuration.rbd_max_clone_depth の場合:
        dest_volume = self.rbd.Image(client.ioctx、dest_name)
        試す：
            dest_volume.flatten()
 except例外をeとして:
            ... 
 
        試す：
            src_volume.unprotect_snap(クローン_snap)
            src_volume.remove_snap(クローン_snap)
 except例外をeとして:
            ...

現在の深度が最大許容深度 rbd_max_clone_depth を超える場合、フラット化操作が実行され、作成されたスナップショットが削除されます。

作成されたボリュームの UUID が 3b8b15a4-3020-41a0-80be-afaa35ed5eef で、ソースボリュームの UUID が bf2d1c54-6c98-4a78-9c20-3e8ea033c3db であると仮定すると、対応する rbd コマンドは次のようになります。

ボリュームID=3b8b15a4-3020-41a0-80be-afaa35ed5eef
ソースボリュームID=bf2d1c54-6c98-4a78-9c20-3e8ea033c3db
 CINDER_POOL = オープンスタック
# rbd_max_clone_depth <= 0 の場合は完全コピーを実行します。
 [[ "$rbd_max_clone_depth" -le 0 ]]の場合;次に、 rbd copy ${CINDER_POOL}/volume-${SOURCE_VOLID} openstack/volume-${VOLID} を実行します。
    終了 0
フィ
# それ以外の場合は COW クローンを実行します。
 #ソースボリュームの新しいスナップショットを作成する
rbd スナップは${CINDER_POOL}/volume-${SOURCE_VOLID}@volume-${VOLID}.clone_snapを作成します。
 rbd スナップ保護 ${CINDER_POOL}/volume-${SOURCE_VOLID}@volume-${VOLID}.clone_snap
 # ソースボリュームのスナップショットをクローンします
rbdクローン\
 ${CINDER_POOL}/volume-${SOURCE_VOLID}@volume-${VOLID}.clone_snap \
 ${CINDER_POOL}/ボリューム-${VOLID}
 # 宛先ボリュームがクローンであり、 rbd_max_clone_depthに達した場合、
 # クローン作成後にdestをフラット化します。
深さ=$(get_clone_depth ${CINDER_POOL}/ボリューム-${VOLID})
 [[ "$depth" -ge "$rbd_max_clone_depth" ]] の場合;それから 
    # 宛先ボリュームをフラット化する
    rbd フラット化 ${CINDER_POOL}/ボリューム-${VOLID}
    #一時スナップを削除
    rbd スナップ保護解除 \
    ${CINDER_POOL}/volume-${SOURCE_VOLID}@volume-${VOLID}.clone_snap
    rbd スナップ rm ${CINDER_POOL}/volume-${SOURCE_VOLID}@volume-${VOLID}.clone_snap
フィ

rbd_max_clone_depth > 0 かつ depth < rbd_max_clone_depth の場合、rbd コマンドで確認します。

 int32bit $ rbd情報ボリューム-3b8b15a4-3020-41a0-80be-afaa35ed5eef
 rbd イメージ'volume-3b8b15a4-3020-41a0-80be-afaa35ed5eef' :
サイズ1024 MB 、オブジェクト数 256
オーダー22 (4096 kB オブジェクト)
        ブロック名プレフィックス: rbd_data.ae2e437c177a
        フォーマット: 2
        機能: レイヤー化、排他ロック、オブジェクト マップ、高速差分、ディープ フラット化
        フラグ:
        create_timestamp: 2017年11月22日水曜日12:32:09
        親: openstack/volume-bf2d1c54-6c98-4a78-9c20-3e8ea033c3db@volume-3b8b15a4-3020-41a0-80be-afaa35ed5eef.clone_snap
        重複: 1024 MB

volume-3b8b15a4-3020-41a0-80be-afaa35ed5eef の親は次のようになります。

 volume-bf2d1c54-6c98-4a78-9c20-3e8ea033c3db@volume-3b8b15a4-3020-41a0-80be-afaa35ed5eef.clone_snap`

画像から作成

イメージからボリュームを作成します。 Glance と Cinder が同じ Ceph クラスターを使用していると仮定すると、Cinder はイメージをダウンロードせずに Glance から直接クローンを作成できます。

 def _create_from_image(self, コンテキスト, ボリューム,
                       画像の場所、画像ID、画像メタ、
                       image_service、**kwargs):
    ...
    model_update、クローン = self.driver.clone_image(
        コンテクスト、
        音量、
        画像の場所、
        イメージメタ、
        イメージサービス
   ...

ドライバーの clone_image() メソッドを見てみましょう。

 def clone_image(self, コンテキスト, ボリューム,
                画像の場所、画像のメタ情報、
                イメージサービス):
    #すべての場所を反復処理して、クローン可能な場所を探します。
 url_locationsのurl_locationの場合:
        url_locationとself._is_cloneable(の場合
                url_location、image_meta):
            _prefix、プール、イメージ、スナップショット = \
                self._parse_location(url_location)
            volume_update = self._clone(ボリューム、プール、イメージ、スナップショット)
            volume_update[ 'provider_location' ] = なし
            self._resize(ボリューム)
 volume_update をTrue で返す 
 return （{}、 false ）

RBDは直接クローンであり、このプロセスは基本的に仮想マシンの作成と同じです。ボリュームを作成するときに新しいサイズが指定されている場合は、RBDのサイズを呼び出して容量拡張操作を実行します。

新しく作成されたボリュームUUIDが87EE1EC6-3FE4-413B-A4C0-8EC7756BF1B4であると仮定して、GLANCE画像UUIDはDB2B6552-394A-42D2-9DE8-2295FE2B3180、RBDコマンドは次のとおりです。

 RBDクローンOpenStack/DB2B6552-394A-42D2-9DE8-2295FE2B3180@snap \
 OpenStack/Volume-87EE1EC6-3FE4-413B-A4C0-8EC7756BF1B4 
 
 if [[-n "$ size" ]];その後、 RBDはsezize -size $ size \  
    OpenStack/Volume-87EE1EC6-3FE4-413B-A4C0-8EC7756BF1B4
フィ

次のようにRBDコマンドを介して確認します。

 int32bit $ rbd info openstack/volume-87ee1ec6-3fe4-413b-a4c0-8ec7756bf1b4
 RBD画像'Volume-87EE1EC6-3FE4-413B-A4C0-8EC7756BF1B4' ：
 768オブジェクトのサイズ3072 MB
注文22（4096 KBオブジェクト）
        block_name_prefix：rbd_data.affc488ac1a
        形式：2
        機能：レイヤー化、排他的ロック、オブジェクトマップ、高速ディフ、ディープフラッテン
        フラグ：
        create_timestamp：12月22日水曜日13:07:50 2017年
        親：OpenStack/DB2B6552-394A-42D2-9DE8-2295FE2B3180@SNAP
        オーバーラップ：2048 MB

新しく作成されたRBD画像の親は、OpenStack/DB2B6552-394A-42D2-9DE8-2295FE2B3180@SNAPであることがわかります。

注：実際、私はこの方法がフラットな操作を実行する必要があると個人的に考えています。それ以外の場合、ボリュームが存在する場合、Glanceは画像を削除できません。これは、GINDERサービスのステータスに依存するGLANCEサービスに相当します。これは少し不合理です。

4.3スナップショットの作成

スナップショットエントリは、create_snapshot（）cinder/volume/manager.pyの方法です。この方法では、TaskFlow Frameworkを使用するのではなく、次のようにドライバーCreate_SnapShot（）メソッドを直接呼び出します。

 ...
試す：
    utils.require_driver_initialized（self.driver）
    snapshot.context = context
    model_update = self.driver.create_snapshot（snapshot）
    ...
例外を除く:
    ...

rbddriverのcreate_snapshot（）メソッドは非常に簡単です：

 def create_snapshot（self、snapshot）：
 "" "RBDスナップショットを作成します。" 「」  
 rbdvolumeproxy（self、snapshot.volume_name）をボリュームとして：
        snap = utils.convert_str（ snapshot.name ）
        volume.create_snap（snap）
        volume.protect_snap（snap）

したがって、ボリュームのスナップショットは、実際にはCeph RBD画像スナップショットに対応しています。 Snapshot UUIDがE4E534FC-420B-45C6-8E9F-B23DCFCB7F86であり、ボリュームUUIDがBF2D1C54-6C98-4A78-9C20-3E8EA033C3C3DBであると仮定します。

 rbd -p openstack snap create \
 Volume-BF2D1C54-6C98-4A78-9C20-3E8EA033C3C3DB@SNAPSHOT-E4E534FC-420-45C6-8E9F-B23DCFCB7F86
 RBD -P OpenStack Snap Protect \
 Volume-BF2D1C54-6C98-4A78-9C20-3E8EA033C3C3DB@SNAPSHOT-E4E534FC-420-45C6-8E9F-B23DCFCB7F86

ここから、仮想マシンのスナップショットとボリュームスナップショットの違いを見ることができます。仮想マシンのスナップショットは、ルートディスクRBDイメージスナップショットからクローン化され、平らにする必要がありますが、ボリュームスナップショットはRBDイメージスナップショットを作成するだけです。したがって、仮想マシンのスナップショットには通常数分かかりますが、ボリュームスナップショットは数秒で完了できます。

4.4ボリュームバックアップを作成します

ボリュームバックアップを理解する前に、まずスナップショットとバックアップの違いを明確にする必要があります。 Git Analogyを使用でき、スナップショットはGITコミット操作に似ています。これは、主にバックトラッキングとロールバックに使用されるデータが送信されていることのみを示しています。クラスターがクラッシュすると、通常、データはスナップショットから完全に回復しません。バックアップはGit Pushに似ており、データセキュリティをリモートストレージシステムにプッシュし、主にデータセキュリティを確保するために使用され、ローカルデータが失われた場合でもバックアップから復元できます。 Cinderのディスクバックアップは、複数のストレージバックエンドもサポートしています。ここでは、ボリュームとバックアップドライバーが両方ともCEPHである状況を検討します。その他の詳細については、Cinderデータボリュームバックアップの原則と実践を参照してください。生産では、ボリュームとバックアップが異なるCephクラスターを使用して、ボリュームCEPHクラスターがハングしたときに、データを別のクラスターから迅速に回復できるようにするために使用する必要があります。この記事は機能をテストするためだけのものであるため、同じCephクラスターを使用しています。プールの区別により、VolumeはOpenStackPoolを使用し、バックアップはCinder_Backuppoolを使用します。

さらに、Cinderはインクリメンタルバックアップをサポートし、ユーザーは-incrementalパラメーターを指定して、フルバックアップまたは増分バックアップを使用するかどうかを決定できます。ただし、Ceph Backendの場合、Cinderは常に最初にインクリメンタルバックアップを実行しようとします。インクリメンタルバックアップが失敗した場合にのみ、ユーザーが - インクリメンタルパラメーターを指定したかどうかに関係なく、完全なバックアップにフォールバックします。それにもかかわらず、バックアップを完全なバックアップとインクリメンタルバックアップの2つの状況に分割します。最初のバックアップのみが完全なバックアップになり、残りのバックアップはインクリメンタルバックアップであることに注意してください。

フルバックアップ（***バックアップ）

cephbackupdriverのバックアップ（）メソッドを直接見て、コードはcinder/backup/drivers/ceph.pyにあります。

 self._file_is_rbd（volume_file）の場合：
    ＃RBDのボリュームの場合、インクリメンタルバックアップを試みます。
    log.debug（ "ボリュームファイルはRBD：インクリメンタルバックアップを試みます。" ）
    試す：
        更新= self._backup_rbd（backup、volume_file、
                                   音量。名前、長さ）
例外を除く.backuprbdoperationfailed：
        log.debug（ "Volume％s。"の完全なバックアップの強制
        do_full_backup = true

ここでは、主にソースボリュームがRBDであるか、つまりCephバックエンドが使用されているかどうかを決定します。増分バックアップは、ボリュームがCeph Storageバックエンドも使用する場合にのみ実行できます。

_backup_rbd（）メソッドを確認しましょう。

 from_snap = self._get_most_recent_snap（source_rbd_image）
 base_name = self._get_backup_base_name（volume_id、diff_format = true ）
 image_created = false  
 rbd_driver.radosclient（self、backup.container）をクライアントとして：
    base_nameではない場合  in self.rbd.rbd（）。リスト（ioctx = client.ioctx）：
        ...
        ＃新しいベースイメージを作成します
        self._create_base_image（base_name、length、client）
        image_created = true  
それ以外：
        ...

from_snapは、最後のバックアップのスナップショットポイントです。私たちが最初のバックアップであったため、from_snapはなしであり、base_name形式はボリューム - ％s.backup.baseです。このベースは何をしますか？ _create_base_image（）メソッドを確認しましょう。

 def _create_base_image（self、 name 、 size 、rados_client）：
    old_format、feature = self._get_rbd_support（）
    self.rbd.rbd（）。 create （ioctx = rados_client.ioctx、
 name = name 、
サイズ=サイズ、
                          old_format = old_format、
                          機能=機能、
                          stripe_unit = self.rbd_stripe_unit、
                          stripe_count = self.rbd_stripe_count）

ベースは実際には、前のボリュームと同じサイズの空のボリュームであることがわかります。

つまり、最初のバックアップである場合、バックアップのCephクラスターは最初にボリュームと同じサイズの空のボリュームを作成します。

ソースコードを引き続き見てみましょう。

 def _backup_rbd（self、backup、volume_file、volume_name、length）：
    ...
    new_snap = self._get_new_snap_name（backup.id）
    log.debug（ "バックアップSnapshot = '％s'" 、new_snapの作成）
    source_rbd_image.create_snap（new_snap） 
 
    試す：
        self._rbd_diff_transfer（volume_name、rbd_pool、base_name、
                                backup.container、
                                src_user = rbd_user、
                                src_conf = rbd_conf、
                                dest_user = self._ceph_backup_user、
                                dest_conf = self._ceph_backup_conf、
                                src_snap = new_snap、
                                from_snap = from_snap） 
                             
 def _get_new_snap_name（self、backup_id）：
 return utils.convert_str（ "backup。％s.snap。％s"  
                             ％ （ backup_id 、 time。time （）））

まず、ソースボリュームに新しいスナップショットが作成され、スナップショットはバックアップと呼ばれます。$ {backup_id} .snap。$ {timestamp}、次にrbd_diff_transfer（）メソッドが呼び出されます。

 def _rbd_diff_transfer（self、src_name、src_pool、dest_name、dest_pool、
                       src_user、src_conf、dest_user、dest_conf、
                       src_snap = none、from_snap = none）：
    src_ceph_args = self._ceph_args（src_user、src_conf、pool = src_pool）
    dest_ceph_args = self._ceph_args（dest_user、dest_conf、pool = dest_pool） 
 
    cmd1 = [ 'rbd' 、 'export-diff' ] + src_ceph_args
    from_snapの場合 なし：
        cmd1.extend（[ ' -  from-snap' 、from_snap]））
    src_snapの場合：
        path = utils.convert_str（ "％s/％s@％s"  
                                 ％（src_pool、src_name、src_snap））
それ以外：
        path = utils.convert_str（ "％s/％s" ％（src_pool、src_name）））
    cmd1.extend（[path、 ' - ' ]） 
 
    cmd2 = [ 'rbd' 、 'import-diff' ] + dest_ceph_args
    rbd_path = utils.convert_str（ "％s/％s" ％（dest_pool、dest_name）））
    cmd2.extend（[ ' - ' 、rbd_path]） 
 
    ret、stderr = self._piped_execute（cmd1、cmd2）
    retの場合：
        msg =（_（ "rbd diff op failed-（ret =％（ret）s stderr =％（stderr）s）" ）％
               { 'ret' ：ret、 'stderr' ：stderr}）
        log.info（msg）
        例外を上げる.backuprbdoperationfailed（msg）

このメソッドは、RBDコマンドを呼び出し、最初にエクスポートディフサブコマンドを介してソースRBDイメージの違いファイルをエクスポートし、Import-Diffを介してバックアップ画像にインポートします。

ソースボリュームのUUIDが075C06ED-37E2-407D-B998-E270C4EDC53Cであると仮定し、サイズは1GBで、バックアップUUIDはDB563496-0C15-4349-95F3-FC5194BBB11Aであると仮定します。

 Volume_Id = 075C06ED-37E2-407D-B998-E270C4EDC53C
 backup_id = db563496-0c15-4349-95f3-fc5194bfb11a
 rbd -p cinder_backup create   - サイズ1024 volume-$ {volume_id} .backup.base  
 new_snap = volume-$ {volume_id}@backup.$ {backup_id }.snap.1511344566.67
 rbd -p openstack snap create $ {new_snap}
 rbd export -diff - プールopenstack $ {new_snap}  -  \  
 | rbd import-diff -pool cinder_backup-volume-$ {volume_id} .backup.base

次のように、RBDコマンドを介して確認できます。

 ＃ボリュームセフクラスター
int32bit $ rbd -p openstack snap ls volume-075c06ed-37e2-407d-b998-e270c4edc53c
スナピッド名                                                              サイズ タイムスタンプ 
    52 backup.db563496-0c15-4349-95f3-fc5194bfb11a.snap.151134566.67 1024 mb水曜日11月22日17:56:15 2017
 ＃バックアップCEPHクラスター
int32bit $ rbd -p cinder_backup ls -l
名前                                                                                                                    サイズの親FMTプロトロック
Volume-075C06ED-37E2-407D-B998-E270C4EDC53C.BACKUP.BASE 1024M 2
 Volume-075C06ED-37E2-407D-B998-E270C4EDC53C.backup.base@backup.db5563496-0c15-4349-95f3-fc5194bfb11a.snap.15113456.67 1024m 2

出力から、ソースボリュームはID 52のスナップショットを作成します。バックアップのCEPH、ボリューム-075C06ED-37E2-407D-B998-E270C4EDC53C.BACKUP.BASEのCEPHクラスターに空のボリュームが作成されます。

増分バックアップ

前のプロセスは完全なバックアップと同じです。_backup_rbd（）メソッドに直接ジャンプします。

 from_snap = self._get_most_recent_snap（source_rbd_image）
 rbd_driver.radosclient（self、backup.container）をクライアントとして：
    base_nameではない場合  in self.rbd.rbd（）。リスト（ioctx = client.ioctx）：
        ...
それ以外：
        self._snap_exists（base_name、from_snap、client）でない場合：
            errmsg =（_（ "snapshot = '％（snap）s'はベースに存在しません"  
 "image = '％（base）s'  - 増分の中止"  
 「バックアップ」 ）％
                      { 'snap' ：from_snap、 'base' ：base_name}）
            log.info（errmsg）
            例外を上げる.backuprbdoperationfailed（errmsg）

まず、ソースボリュームに対応するRBD画像の最も親のスナップショットを取得し、バックアップのCephクラスターのベースに同じスナップショットがあるかどうかを判断します（前のバックアップによると、ソースボリュームと同じスナップショットが必要です。

後の部分を見続けましょう：

 new_snap = self._get_new_snap_name（backup.id）
 source_rbd_image.create_snap（new_snap） 
 
試す：
    前=時間。時間（）
    self._rbd_diff_transfer（volume_name、rbd_pool、base_name、
                            backup.container、
                            src_user = rbd_user、
                            src_conf = rbd_conf、
                            dest_user = self._ceph_backup_user、
                            dest_conf = self._ceph_backup_conf、
                            src_snap = new_snap、
                            from_snap = from_snap）
    from_snapの場合：
        source_rbd_image.remove_snap（from_snap）

これは基本的にフルバックアップと同じです。唯一の違いは、from_snapが現時点では誰もいないことであり、from_snapが後で削除されることです。 _RBD_DIFF_TRANSFERメソッドを使用して、前のコードを変換できます。

ソースボリュームUUIDが075C06ED-37E2-407D-B998-E270C4EDC53Cであると仮定します11a、対応するRBDコマンドはほぼ次のとおりです。

 Volume_Id = 075C06ED-37E2-407D-B998-E270C4EDC53C
 backup_id = e3db9e85-d352-47e2-bced-5bad68da853b
 db563496-0c15-4349-95f3-fc5194bfb11a
 rbd -p openstack snap create \
 volume-$ {volume_id}@backup.$ {backup_id} .snap.1511348180.27
 rbd export-diff -pool openstack \  
 -  from-snap backup。$ {parent_id} .snap.15113445667 \ \  
 openstack/volume-$ {volume_id}@backup.$ {backup_id }.snap.1511348180.27- \
 | rbd import -diff -pool cinder_backup- \  
 cinder_backup/volume-$ {volume_id} .backup.base
 rbd -p openstack snap rm \
 volume-$ {volume_id} .backup.base@backup.$ {parent_id} .snap.151134566.67

次のように、RBDコマンドを介してそれを確認します。

 int32bit $ rbd -p openstack snap ls volume-075c06ed-37e2-407d-b998-e270c4edc53c
スナピッド名                                                              サイズ タイムスタンプ 
    53 backup.e3db9e85-d352-47e2-bced-5bad68da853b.snap.1511348180.27 1024 MB水曜日11月22日18:56:20 2017
 int32bit $ rbd -p cinder_backup ls -l
名前                                                                                                                    サイズの親FMTプロトロック
Volume-075C06ED-37E2-407D-B998-E270C4EDC53C.BACKUP.BASE 1024M 2
 Volume-075C06ED-37E2-407D-B998-E270C4EDC53C.backup.base@backup.db5563496-0c15-4349-95f3-fc5194bfb11a.snap.15113456.67 1024m 2
 Volume-075C06ED-37E2-407D-B998-E270C4EDC53C.backup.base@backup.e3db9e85-d352-47e2-bced-5bad68da853b.snap.1511348180.27 1024m 2

分析の結果と一致して、ソースボリュームのスナップショットは古いボリュームを削除し、上部のボリュームのみを保持し、バックアップはすべてのスナップショットを保持します。

4.5バックアップと回復

バックアップ回復は、バックアップの逆プロセスです。つまり、リモートストレージからローカルにデータを復元します。バックアップと回復のソースコードは、cinder/backup/drivers/ceph.pyのrestore（）方法にあります。このメソッドは_restore_volume（）メソッドを直接呼び出すので、_restore_volume（）メソッドを直接見てみましょう。

 def _restore_volume（self、backup、volume、volume_file）：
    length = int （volume。size ） * unit.gi 
 
    base_name = self._get_backup_base_name（backup.volume_id、
                                           diff_format = true ）
 rbd_driver.radosclient（self、backup.container）をクライアントとして：
        diff_allowed、restore_point = \
            self._diff_restore_allowed（base_name、backup、volume、
                                       volume_file、クライアント）

その中で、_diff_restore_allowed（）は非常に重要な方法です。この方法は、直接輸入による回復をサポートするかどうかを決定します。この方法の実装を確認しましょう。

 def _diff_restore_allowed（self、base_name、backup、volume、volume_file、
                          rados_client）：
    rbd_exists、base_name = self._rbd_image_exists（base_name、
                                                   backup.volume_id、
                                                   rados_client）
    rbd_existsではない場合：
戻る 偽、なし
    restore_point = self._get_restore_point（base_name、backup.id）
    restore_pointの場合：
        self._file_is_rbd（volume_file）の場合：
            volume.id == backup.volume_idの場合：
戻る  false 、restore_point
            self._rbd_has_extents（volume_file.rbd_image）の場合：
戻る  false 、restore_point
戻る 確かに、restore_point

この方法から、データを回復するために差分インポート方法をサポートすることで、次のすべての条件を満たす必要があることがわかります。

バックアップクラスターのボリュームに対応するRBDベース画像が存在する必要があります。
回復ポイントが存在する必要があります。つまり、バックアップベース画像に対応するスナップショットが存在する必要があります。
回復ターゲットのボリュームはRBDでなければなりません。つまり、ボリュームのストレージバックエンドもCEPHでなければなりません。
回復ターゲットのボリュームは空のボリュームである必要があり、既存のコンテンツを含む上書き画像をサポートしていません。
回復ターゲットのボリュームUUIDとバックアップのソースボリュームUUIDは同じではありません。つまり、元のボリュームを上書きすることはできません。

言い換えれば、Cinderはデータの再構築を既存のボリューム（ソースボリュームを含む）にサポートしていますが、Ceph Backendを使用すると、増分回復がサポートされず、効率が非常に低くなります。

したがって、CEPHストレージバックエンドを使用する場合は、バックアップを空のボリューム（ボリュームを指定しない）に復元することをお勧めします。既存のボリュームに復元することはお勧めしません。

Cinderは、バックアップが取得した新しいボリュームまたは元のボリュームへの復元をサポートすることに注意してください。後者の場合、これは最も安全なアクションとみなされたため、完全なコピーが実施されます。したがって、常に新しいボリューム（デフォルト）に復元することをお勧めします。

ここでは、空のボリュームに復元すると仮定します。コマンドは次のとおりです。

 Cinder Backup-Restore -Name int32bit-Restore-1 \  
 E3DB9E85-D352-47E2-BCED-5BAD68DA853B

-volumeパラメーターを指定しなかったことに注意してください。現時点では、増分回復が実行され、コードは次のように実装されます。

 def _diff_restore_rbd（self、backup、restore_file、restore_name、
                      restore_point、restore_length）：
    rbd_user = restore_file.rbd_user
    rbd_pool = restore_file.rbd_pool
    rbd_conf = restore_file.rbd_conf
    base_name = self._get_backup_base_name（backup.volume_id、
                                           diff_format = true ）
    前=時間。時間（）
    試す：
        self._rbd_diff_transfer（base_name、backup.container、
                                restore_name、rbd_pool、
                                src_user = self._ceph_backup_user、
                                src_conf = self._ceph_backup_conf、
                                dest_user = rbd_user、dest_conf = rbd_conf、
                                src_snap = restore_point）
例外を除く.backuprbdoperationfailed：
        上げる
    self._check_restore_vol_size（backup、restore_name、restore_length、
                                 rbd_pool）

増分回復が非常に簡単であることがわかるのは非常に簡単です。以前に導入された_rbd_diff_transfer（）メソッドを呼び出して、バックアップCEPHクラスターに対応するベース画像のスナップショットをボリュームCEPHクラスターに対応してサイズ変更します。

バックアップUUIDがE3DB9E85-D352-47E2-BCED-5BAD68DA853Bであると、ソースボリュームUUIDは075C06ED-37E2-407D-B998-E270C4EDC53Cであり、ターゲットボリュームはF65CF53426-5252626-5252626262626262626262626262626262624262626262626262 、次に、対応するRBDコマンドは次のとおりです。

 backup_id = e3db9e85-d352-47e2-bced-5bad68da853b
 source_volume_id = 075c06ed-37e2-407d-b998-e270c4edc53c
 DEST_VOLUME_ID = F65CF534-5266-44BB-AD57-DDBA21D9E5F9
 rbd export-diff - プールcinder_backup \  
 cinder_backup/volume-$（source_volume_id} .backup.base@backup.$ {backup_id} .snap.1511348180.27- \
 | RBD Import-Diff -Pool OpenStack-OpenStack/Volume-$ {dest_volume_id}  
 rbd -p openstack sezize -  -size $ {new_size} volume -$ {dest_volume_id}

上記の5つの条件のいずれかが満たされていない場合、シンダーは完全なバックアップを実行し、完全なバックアップはデータを断片的に書くことです。

 def _transfer_data（self、src、src_name、dest、dest_name、length）：
    chunks = int （length / self.chunk_size）
範囲のチャンク（0、チャンク）：
        前=時間。時間（）
        data = src.read （self.chunk_size）
        Dest.Write（データ）
        dest.flush（）
        delta =（ time。time （） -前）
        rate =（self.chunk_size / delta） / 1024
        ＃降伏 その他の保留中のバックアップ
        eventlet.sleep（0）
    rem = int （length％self.chunk_size）
    remの場合：
        Dest.Write（データ）
        dest.flush（）
        ＃降伏 その他の保留中のバックアップ
        eventlet.sleep（0）

この場合、それは非常に非効率的で時間がかかるため、使用することはお勧めしません。

5 結論

5.1 概要

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

rbd -p ${GLANCE_POOL}を作成  --size $ {size} $ {image_id}  
 rbd -p $ {glance_pool} snap create $ {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 clone $ {glance_pool}/$ {image_id} @snap $ {nova_pool}/$ {server_id} _disk

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

＃ディスクをスナップショットして、視線のストレージプールにクローンします
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}
 ＃ 「スナップ」と呼ばれる保護されたスナップショットを作成します アップロードされた画像に渡されます 
 rbd -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} create   -new-format  -  size $ {size} volume-$ {volume_id}

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

RBDクローン\
 $ {cinder_pool}/volume-$ {source_volume_id} @snapshot- $ {snapshot_id} \
 ${CINDER_POOL}/ボリューム-${VOLUME_ID}
 rbd resize - サイズ$ {size} openstack/volume-$ {volume_id}

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

＃rbd_max_clone_depth <= 0の場合は完全なコピーを行います。
 if [ "$ rbd_max_clone_depth" -le 0]];その後、 rbdコピー\
    $ {cinder_pool}/volume-$ {source_volume_id} $ {cinder_pool}/volume-$ {volume_id}
    終了 0
フィ
＃それ以外の場合は、牛のクローンを行います。
 ＃ソースボリュームの新しいスナップショットを作成します
RBDスナップcreate \
 ${CINDER_POOL}/volume-${SOURCE_VOLUME_ID}@volume-${VOLUME_ID}.clone_snap
 RBDスナップ保護\
 ${CINDER_POOL}/volume-${SOURCE_VOLUME_ID}@volume-${VOLUME_ID}.clone_snap
 ＃ここで、ソースボリュームスナップショットをクローンします
RBDクローン\
 $ {cinder_pool }/volume-$ {source_volume_id }@volume-$ {volume_id} .clone_snap \
 ${CINDER_POOL}/ボリューム-${VOLUME_ID}
 ＃DESTボリュームがクローンで、 RBD_MAX_CLONE_DEPTHが到達した場合、
 ＃クローニング後に運命を平らにします。
深さ= $（get_clone_depth $ {cinder_pool}/volume-$ {volume_id}）
 if [ "$ dept" -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_snap
フィ

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

rbd clone $ {glance_pool}/$ {image_id} @snap $ {cinder_pool}/volume-$ {volume_id}
 if [[-n "$ {size}" ]];その後、 rbd resize --size $ {size} $ {cinder_pool}/volume-$ {volume_id}  
フィ

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

rbd -p $ {cinder_pool} snap create volume-$ {volume_id} @snapshot- $ {snapshot_id}
 rbd -p $ {cinder_pool} snap protect volume-$ {volume_id} @snapshot- $ {snapshot_id}

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

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

rbd -p $ {backup_pool} create   - サイズ \  
 $ {volume_size} volume-$ {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-$ {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.$ {Timestramp}  -  \
 | rbd import-diff --pool ${BACKUP_POOL} - \  
 $ {backup_pool}/volume-$ {volume_id} .backup.base
 rbd -p $ {cinder_pool} snap 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}

【この記事は51CTOコラムニスト「Fu Guangping」によるオリジナル記事です。転載が必要な場合は51CTOまでご連絡ください]

この著者の他の記事を読むにはここをクリックしてください

<<: エッジコンピューティングは AI の開発を促進します。将来、クラウドコンピューティングを排除できるでしょうか?

>>: ブロックチェーンとは何ですか? また、データセンターやクラウドコンピューティングにどのような影響を与えますか?