①ローカルコピー機能の特徴 ― ShadowImage、Thin Image ―
ローカルコピーは、バックアップを目的として、ストレージシステム内にデータのコピーを作成することだと伺いました
それを実現する機能として、「ShadowImage」と「Thin Image」という2つの機能がありますが、何が違うのでしょうか？
- 長江
- それは「バックアップに必要な容量の低減」に関係するのですが、後ほどご説明します。
まず ShadowImage ですが、「同一のストレージシステム内で、正ボリュームの全てのデータを副ボリュームにコピーする機能」と言うことができます。
ローカルコピー機能 1ShadowImage
同一のストレージシステム内で、正ボリュームの全てのデータを副ボリュームにコピーする機能
- 国府津
- データのバックアップには世代管理が必要不可欠ですが、ShadowImageで実現できるのでしょうか？
- 長江
- もちろんです。次の図に示す構成で最大9世代分のバックアップを作成できます。
例えば1日1回バックアップを取るとして、1日目のデータを副1へ、2日目のデータを副2へというふうに、正ボリュームから副1〜副3ボリュームへ3日分のバックアップを取得できます。
正ボリュームと副ボリュームのペアを「コピーペア」と呼ぶのですが、正ボリュームと副1〜副3のコピーペアは第1階層のコピーペア（L1ペア）となります。
- 長江
- 次に、4日目のデータを副1に書き込む場合のことを考えてみましょう。副1に格納されている1日目のデータは、副1を正ボリュームとしたShadowImageで副4にバックアップすることで、保持することができます。このようにして、最大9世代分のバックアップが可能になるのです。
なお、L1ペアの副ボリュームを正ボリュームとしたコピーペアを、第2階層のコピーペア（L2ペア）と呼びます。
バックアップ業務では、バックアップサーバから副ボリュームにアクセスし、データをバックアップ装置にコピーします
問題は、その日更新されたデータのバックアップを取得する際に、正ボリュームから副ボリュームへのコピーが完了するまでバックアップ業務を開始できないことです
更新データのコピーが完了するまでの待ち時間を短縮する、「Quick Resync」と「Quick Split」をご紹介しましょう
ShadowImageのQuick Resync／Quick Splitでバックアップ業務時間を短縮
- 長江
- まず、更新データをバックアップする際の一般的な流れを確認しましょう。赤い色で示した部分に待ち時間が発生するのですが、Quick ResyncとQuick Splitはこの部分の処理を高速化します。
■Quick Resync
- 長江
- Quick Resyncは、正ボリュームと副ボリュームの再同期の指示を出した直後に、コピーペアの状態を「正ボリュームと副ボリュームの同期が完了した」状態にする機能です。
- 国府津
- これから更新データのコピーを始めようというところなのに、ですか。
- 長江
- はい。更新データのコピーは、バックグラウンドで実行されます。続いて、Quick Splitを実行します。
■Quick Split
- 長江
- Quick Splitは、更新データのコピーが完了するのを待たずに、コピーペアを分割する機能です。コピーペアを分割すれば、副ボリュームをバックアップサーバにマウントできるようになります。
- 国府津
- …なるほど、更新データのコピー中に副ボリュームへのマウントを可能にすることで、副ボリュームにコピーされたデータから順次バックアップ装置にコピーできるようにしたのですね。これで、更新データのコピーが完了するのを待つ時間がなくなり、バックアップ業務全体にかかる時間を短縮できますね。
- 長江
- 一般的なバックアップの流れと、Quick Resync / Quick Splitを用いたバックアップの流れを比較してみましょう。バックアップ業務の時間が大幅に短縮できていることがわかります。
■一般的なバックアップの流れ
■Quick Resync / Quick Splitを用いた場合
- 国府津
- もう1つお聞きしたいことがあります。データベースのように、複数のボリュームで構成されているものをバックアップする際には、データの整合性は確保できるのでしょうか。一般的にデータベースは、データファイル、制御ファイル、ログファイルがそれぞれのボリュームに格納されています。
各ボリュームをバックアップするために副ボリュームにコピーした後、各コピーペアを分割するタイミングにばらつきが出ると、ボリューム間のデータの整合性を維持できず、バックアップデータとして使えなくなります。
- 長江
- 複数のコピーペアを「コンシステンシーグループ」というグループに登録しておけば、同じタイミングで分割できるのでデータの整合性を保つことができます。障害が発生してバックアップデータをリストアする際も、グループで管理していれば、どれか一つのボリュームをリストアし忘れる、などということがなくなります。コンシステンシーグループの考え方は、このあとご説明するThin Imageや、次ページでご説明するリモートコピー機能でも適用されていますので、覚えておくと良いと思います。
■個別のコピーペアとして管理している場合
■コンシステンシーグループで管理している場合
- 国府津
- 便利な機能がいくつもある印象のShadowImageですが、正ボリュームの全てのデータをバックアップするため、正ボリュームと同じだけの容量が、バックアップ用に必要になりますよね。その分、コストがかかるのが悩みの種です。
- 長江
- 実は、バックアップ容量のお悩みを解決する手段が、Thin Imageなのです。このページの冒頭で国府津さんが、2種類のローカルコピー機能の違いについて、疑問を持たれていましたよね。
- 国府津
- はい。Thin Imageでは、バックアップ用に正ボリュームと同等の容量は不要ということでしょうか？
もしそうであれば、ローカルコピー機能としてThin Imageだけあれば十分な気もしますが…
- 長江
- その辺りのメリットとデメリットも踏まえて、Thin Imageについてご説明します。
Thin Imageは、バックアップ容量低減のために、完全なコピーとしての副ボリュームを持たないコピー機能です。もう少し詳しく説明すると、「正ボリュームで更新が発生した個所のデータだけを、更新前にThin Imageプールに格納することで、コストパフォーマンスの良いコピーを実現する機能」と言えます。
ローカルコピー機能 2Thin Image
正ボリュームで更新が発生した個所のデータだけを、更新前に仮想ボリュームに格納することで、コストパフォーマンスの良いコピーを実現する機能
- 国府津
- 少しイメージしづらいですね…
- 長江
- 次の図で具体的にご説明しましょう。ホストサーバからの更新データ1が正ボリュームに書き込まれる前に、該当部分の更新前のデータが、スナップショットデータとして仮想的なデータプールであるThin Imageプールに格納されます。その後、更新データ2や更新データ3が来た場合も同様に、更新前のデータだけがThin Imageプールに格納されていきます。副ボリュームは、1つの正ボリュームに対して最大1,024個作成することが可能です。
- 国府津
- 更新個所だけのデータをバックアップすれば、正ボリュームを丸ごとバックアップすることに比べて、バックアップ容量を低減できるのですね。スナップショットデータを、個別のボリュームではなくプールに格納するメリットは何でしょうか。
- 長江
- 正ボリュームごとにスナップショットデータの格納領域を用意すると、更新量が少ない場合は用意した領域が無駄になる場合があります。プールを利用すればデータの更新量の差を平準化でき、リソースの無駄をなくすことができます。
- 国府津
- 副ボリュームのデータは、ホストサーバからはどのように見えるのでしょうか。
- 長江
- 正ボリュームのデータとスナップショットデータが組み合わさったボリュームとして見えます。
例えば副1のボリュームは、更新データ1が反映された正ボリュームと、Thin Imageプールのスナップショットデータが組み合わさったボリュームとして見えます。つまり、更新データ1が反映される前の正ボリュームが見えるというわけです。
- 国府津
- ShadowImageと違い、副ボリュームは正ボリュームの完全なコピーではないため、正ボリュームのデータを障害などで損失すると、データの復旧はできないですね。
- 長江
- その通りです。ShadowImageとThin Imageは、次のように使い分けると良いでしょう。
例えば、1週間に1回ShadowImageでフルバックアップを取得し、それ以外の日はThin Imageで差分バックアップを取得する。そうすれば、毎日ShadowImageでフルバックアップを取得するよりも、大幅にバックアップ容量を削減できます。
- 国府津
- ShadowImageとThin Imageを組み合わせて使えば、確実で効率の良いバックアップを実現できるのですね。
キャプションを入れてください。
| 機能 |
用途 |
バックアップ容量 |
データ保全性 |
| フルバックアップ |
正ボリュームと同じ容量が必要 |
高い |
| 差分バックアップ |
更新箇所のデータのみのコピーで少容量を実現 |
低い |
