概要
QueryChangedDiskAreas + VDDK API を使ったバックアップ手法について認識を深めるために、プログラミングガイドラインの「Backup and Recovery Example」の部分を翻訳し自分なりに解説してみたいと思います
環境
- CentOS 7
- VCSA 6.5.0 9451637
- VDDK API 6.7.1
QueryChangedDiskArea + VDDK API で増分バックアップを取得できる
まず vSphere API から提供される QueryChangedDiskArea は、スナップショットと ChangeID と呼ばれるディスクの変更を管理する識別子を使ってディスクセクタの変更差分をリストで返します
ディスクセクタの差分のリストは変更があった箇所 (offset) とそこから何バイト変更があったかのサイズ (length) のペアになります
例えば「差分1」は「ss1」と「*」を使って差分を出します
「差分2」の場合は「ss2」と「56 ac 13･･･ba/1」を使って差分を出します
「ss3」と「*」を比較すれば最新のスナップショットまでのすべての差分を取得することもできます
ここで言う差分がディスクの増分になります
いわゆる増分バックアップする場合に使います
VixDiskLib_QueryAllocatedBlocks と連携する
VixDiskLib_QueryAllocatedBlocks は vSphere API ではなく VDDK API と呼ばれる vmdk を直接操作することができる API です
VixDiskLib_QueryAllocatedBlocks はディスクに割り当てられている領域を取得することができます
つまり QueryChangedDiskArea で取得した増分の領域と VixDiskLib_QueryAllocatedBlocks で取得した使用済みの領域とを比較し積集合を取得することで正確な増分領域を取得することができます
具体的にどのように増分バックアップを実現するか
1. フルバックアップを取得する
vm からスナップショット (ss1) を作成します
そして ChangeID (56 ac 13 ･･･ ba/1) をメモしておきます
この ChangeID はフルバックアップ時点での ChangeID になるので大元の VM の ChangeID になります
次にフルバックアップを取得します
フルバックアップの領域情報は VixDiskLib_QueryAllocatedBlocks を使います
理由は単純で未使用の領域もバックアップしてしまうと時間がかかるため VixDiskLib_QueryAllocatedBlocks を使って割り当て済みの領域のみバックアップします
セクタ情報の書き込みは VixDiskLib_Write を使います (たぶん)
またこのタイミングで ss1 は不要なので削除して OK です
2. 増分バックアップを取得する
あるタイミングで増分バックアップを取得します
まずは新しいスナップショットを作成します (ss2)
ここでも ChangeID が生成されるのでメモしておきましょう
そして ss2 と先ほどメモしておいた ss1 の ChangeID (56 ac 13 ･･･ ba/1) を QueryChangedDiskAreas 使って増分バックアップを取得します
あとはこの増分を VixDiskLib_Write を使って書き込みます
増分の領域の取得と ss2 の ChangeID のメモができれば ss2 は不要なので削除して OK です
3. 更に増分バックアップを更に取得する
基本的な流れは 2. と同じです
ss3 を作成して ss2 の ChangeID を使って QueryChangedDiskAreas を使って増分を取得します
4. リストアする
事前に取得しておいた VM の設定から新規で空の VM を作成します
そして事前に作成しておいたバックアップ用のディスクを接続するだけでリストアできます
これで 3. の段階の VM を簡単に復元することができます
ドキュメントでは VixDiskLib_QueryAllocatedBlocks で取得したフルバックアップのセクタ情報、QueryChangedDiskAreas で取得した増分バックアップ分のセクタ情報をどこかに格納しておいてリストアする際に VixDiskLib_Write で書き込む流れになっていました
おそらくどちらの流れでも問題ないと思います
考察 (メリット・デメリット)
この方法の利点は別の VM としてリストアできることかなと思います
スナップショットからリストアする場合は同じ VM に対してリストアするのでリストアしたら前の状態に戻れません
今回の場合はバックアップ元の VM も残ります
あとは増分バックアップなので無駄なバックアップ用の領域を使わないのもメリットかなと思います
バックアップする方法はいろいろあると思いますが単純にやろうとすれば VM 自体のクローンを取ったりすると思います
そうすると今回の場合であれば 3 回バックアップするので約 3 台分 VM の領域が必要になります
それに比べて増分であれば既存の領域はバックアップしないので領域を節約できます
デメリットとしては今回の方法は VDDK API と vSphere API を組み合わせて使う手法のため技術力が必要だということです
vSphere API に使い慣れている人は多いと思いますが VDDK API 慣れている人は少ないと思います
情報も VDDK API はかなり少ないです (自分も頑張って発信するようにしていますが、、)
なので学習のハードルがグンと上がるのでそういった意味で採用が難しくなる可能性があります
また VixDiskLib_Write がかなり危ない API になっています
vmdk に直接書き込む仕様になっているので間違った情報を書き込むとすぐに VM を破壊する行為に繋がりかねません
セクタ情報や書き込む量などは API で取得できるのでそれを間違えることはないと思いますが、単純に API が間違った値を返却する可能性もゼロではありません
そういった意味でかなり危険な構成になると自分は思っています
最後に
VDDK API の Programming Guide の「Backup and Recovery Example」の章を理解を深めるために翻訳して説明してみました
たぶん間違っていないと思います (間違っていたらごめんなさい、、)
今回はバックアップの構成を紹介しましたが、VDDK API は他にも「ウイルススキャン」や「パッチ適用」などできるようです
確かにディスクを直接操作するので何でもできるような気がします
またそれらがオフラインでできるというのもメリットのようです
が、やはりこれらもかなりハードルは高いかなと思います
さすがにこのレベルになると VMware さんのサポートなしではかなり厳しくなるかなと思います (VDDK API が OSS でもないので)
0 件のコメント:
コメントを投稿