rbd export V2

6776 ワード
ceph
昨年からcephに触れて、多くの問題に直面して、ずっと記録する時間がなくて、次はゆっくり記録します.今日の話題は実は1年くらい前の話です...
背景:
      cephをクラウドプラットフォームのバックエンドストレージとして使用する場合、rbdを使用してopenstackにブロックストレージを提供します.この場合、システムデータのセキュリティを保証する必要があります.もちろんこれは複雑な話題で、多くのシナリオが含まれていますが、後で単独でトピックを開くことができます.ここでは、そのうちの1つだけを「定期的なバックアップ」と言います.
      簡単な調査の結果、rbdのサブコマンド「rbd export/import」がこのことを完了できることが分かった.そこで試してみました.しかし、次のような問題が発生しました.http://tracker.ceph.com/issues/13186
つまり、exportがimageになった後、再びimportが入ってきて、すべてのsnapshotがなくなりました.内容だけが同じで、イメージ全体が変わっています.
[root@node-1 ~]# rbd create test_export_v2 -s 1G
[root@node-1 ~]# rbd info test_export_v2
rbd image 'test_export_v2':
	size 1024 MB in 256 objects
	order 22 (4096 kB objects)
	block_name_prefix: rbd_data.f5516b8b4567
	format: 2
	features: layering, striping, exclusive-lock, object-map, fast-diff, deep-flatten
	flags: 
	stripe unit: 128 kB
	stripe count: 16
[root@node-1 ~]# rm -rf export.file 
[root@node-1 ~]# rbd export test_export_v2 export.file
Exporting image: 100% complete...done.
[root@node-1 ~]# ll export.file 
-rw-r--r-- 1 root root 1073741824 Oct 17 20:04 export.file
[root@node-1 ~]# rbd import export.file test_import_v2
Importing image: 100% complete...done.
[root@node-1 ~]# rbd info test_import_v2
rbd image 'test_import_v2':
	size 1024 MB in 256 objects
	order 22 (4096 kB objects)
	block_name_prefix: rbd_data.f55a6b8b4567
	format: 2
	features: layering
	flags:

      これは、タイミングバックアップの要件を完全に満たすことはできません.システムがクラッシュすると、バックアップファイルでリカバリできません.
理由:
       コード研究によりrbd exportコマンドは単純にimageの内容を読み出し、ファイルに書き込むだけであることが分かった.rbd importは、新しいimageを作成し、ファイルから最初から最後までデータを読み込み、imageに書きます.このような設計は私たちのニーズを満たすことはできません.
解決:
      この問題を解決するために、私はコミュニティにpatchのセットを提出してV 2バージョンのrbd exportとrbd importを導入しました. https://github.com/ceph/ceph/pull/10487
実装方法を簡単に説明できます.
RBD Export & Import
===================

This is a file format of an RBD image or snapshot. It's a sparse format
for the full image. There are three recording sections in the file.

(1) Header.
(2) Metadata.
(3) Diffs.

Header
~~~~~~

"rbd image v2\
"

Metadata records
~~~~~~~~~~~~~~~~

Every record has a one byte "tag" that identifies the record type,
followed by length of data, and then some other data.

Metadata records come in the first part of the image.  Order is not
important, as long as all the metadata records come before the data
records.

In v2, we have the following metadata in each section:
(1 Bytes) tag.
(8 Bytes) length.
(n Bytes) data.

In this way, we can skip the unrecognized tag.

Image order
-----------

- u8: 'O'
- le64: length of appending data (8)
- le64: image order

Image format
------------

- u8: 'F'
- le64: length of appending data (8)
- le64: image format

Image Features
--------------
--------------

- u8: 'T'
- le64: length of appending data (8)
- le64: image features

Image Stripe unit
-----------------

- u8: 'U'
- le64: length of appending data (8)
- le64: image striping unit

Image Stripe count
------------------

- u8: 'C'
- le64: length of appending data (8)
- le64: image striping count

Final Record
~~~~~~~~~~~~

End
---

- u8: 'E'


Diffs records
~~~~~~~~~~~~~~~~~
Record the all snapshots and the HEAD in this section.

- le64: number of diffs
- Diffs ...

Detail please refer to rbd-diff.rst

rbd diffの実装の概要を加えます.
"rbd diff v2
"

Metadata records

Every record has a one byte "tag" that identifies the record type, followed by length of data, and then some other data.

Metadata records come in the first part of the image. Order is not important, as long as all the metadata records come before the data records.

In v2, we have the following metadata in each section: (1 Bytes) tag. (8 Bytes) length. (n Bytes) data.

In this way, we can skip the unrecognized tag.

From snap

u8: 'f'
le64: length of appending data (4 + length)
le32: snap name length
snap name
To snap

u8: 't'
le64: length of appending data (4 + length)
le32: snap name length
snap name
Size

u8: 's'
le64: length of appending data (8)
le64: (ending) image size
Data Records

These records come in the second part of the sequence.

Updated data

u8: 'w'
le64: length of appending data (8 + 8 + length)
le64: offset
le64: length
length bytes of actual data
Zero data

u8: 'z'
le64: length of appending data (8 + 8)
le64: offset
le64: length
Final Record

End

u8: 'e'

これが私がこのPRで導入した案で、以前のv 1 export会ではすべてのデータがあちこちのファイルに保存されていましたが、メタデータやsnapshotの情報を保存することはできませんでした.
だから私はヘッダーをエクスポートしたファイルに導入して、メタデータを保存しました.そして、すべてのファイルはいくつかのsectionに分かれており、各sectionにはtagがあり、異なる意味を表しています.
これにより、インポート時に異なるsectionを解析することで、すべてのメタデータをインポートできます.
 +static const std::string RBD_IMAGE_BANNER_V2 ("rbd image v2
");
 +static const std::string RBD_IMAGE_DIFFS_BANNER_V2 ("rbd image diffss v2
");
 +static const std::string RBD_DIFF_BANNER_V2 ("rbd diff v2
");
 +
 +#define RBD_DIFF_FROM_SNAP	'f'
 +#define RBD_DIFF_TO_SNAP	't'
 +#define RBD_DIFF_IMAGE_SIZE	's'
 +#define RBD_DIFF_WRITE		'w'
 +#define RBD_DIFF_ZERO		'z'
 +#define RBD_DIFF_END		'e'
 +
 +#define RBD_EXPORT_IMAGE_ORDER		'O'
 +#define RBD_EXPORT_IMAGE_FEATURES	'T'
 +#define RBD_EXPORT_IMAGE_STRIPE_UNIT	'U'
 +#define RBD_EXPORT_IMAGE_STRIPE_COUNT	'C'
 +#define RBD_EXPORT_IMAGE_END		'E'

現在の効果は次のとおりです.
[root@node-1 ~]# rbd create test_export_v2 -s 1G
[root@node-1 ~]# rbd info test_export_v2
rbd image 'test_export_v2':
	size 1024 MB in 256 objects
	order 22 (4096 kB objects)
	block_name_prefix: rbd_data.8d9ca36b8b4567
	format: 2
	features: layering, striping, exclusive-lock, object-map, fast-diff, deep-flatten
	flags: 
	create_timestamp: Tue Oct 17 22:25:02 2017
	stripe unit: 128 kB
	stripe count: 32
[root@node-1 ~]# rbd export --export-format 2 test_export_v2 export.file
Exporting image: 100% complete...done.
[root@node-1 ~]# rbd import --export-format 2 export.file test_import_v2
Importing image: 100% complete...done.
[root@node-1 ~]# rbd info test_import_v2
rbd image 'test_import_v2':
	size 1024 MB in 256 objects
	order 22 (4096 kB objects)
	block_name_prefix: rbd_data.8ea2566b8b4567
	format: 2
	features: layering, striping, exclusive-lock, object-map, fast-diff, deep-flatten
	flags: 
	create_timestamp: Tue Oct 17 22:25:55 2017
	stripe unit: 128 kB
	stripe count: 32

次の手順に従います.
          実際には、次のような後続の作業があります.
(1)image-metaデータはエクスポートされていません.この仕事はもうこの間、他の同僚に完成させました.
(2)エクスポートしたファイルにはmd 5値を書き込むことができ,インポート時にデータを検証し,あちこちのファイル内容が修正されないようにする.
JAva ioとjava nio
GCとメモリ漏洩