データ重複排除性能を自分でテストしよう

皆さんなら、ベンダーの言うことをそのまま鵜呑みにして、データの重複排除率やそのパフォーマンスに賭けるだろうか？ それとも自分でシステムをテストして確かめてみるだろうか？

なかには、自社のデータ重複排除性能を誇張して伝えるベンダーもある。わたし自身はそのことを認識していたのだが、これが問題として明らかになったのは、わたしがBackupCentral.comのブログにデータ重複排除性能に関する記事を書いて、読者からフィードバックをもらったときのことだった。この記事はわたしが公になっている情報を編集してまとめたものに過ぎないのだが、一部、わたしがそれらのベンダーの主張を保証しているような印象を受けた人もいたようだ。

わたしがベンダーあるいはユーザーから公に、あるいは個人的にもらったコメントは以下のようなものだった。「○○社の製品がxxx MB/secだって？ あそこの製品はその半分も出ないぞ！」とか、「ベンダーに参考資料は請求されたのでしょうか？ わたしの知るかぎり、記事に書かれているような構成のシステムを使っているユーザーは1人もいませんよ！」とか。わたしの挙げた数字は、ベンダーが公表している数字だったのだが、そのなかには全くのでっちあげの数字が入っていた、と言えば十分だろう。それなら、何を信じるか？ 公表されている数字が信用できないこと、また、これらの製品に関して独立した試験がほとんどないことを考えると、信頼できる数字を得るには、自分でテストするしかないのだ。そこでこれから、実施すべきテストの内容、および、そうしたテストの最良の実施方法を説明していこうと思う。

ターゲット型重複排除とソース型重複排除

重複排除技術には2種類のタイプがあり、それぞれにまったく異なる試験方法が必要となる。ターゲット型重複排除とは、「定期的に」バックアップを受け取るアプライアンス内で重複が排除される仕組みになっているものであり、従来のバックアップ・アプリケーションを利用したバックアップがこれに相当する。これらのアプライアンスは通常、仮想テープ・インタフェース、NFS、CIFSや、シマンテックのVeritas NetBackupに採用されているOpenStorage API（OST API）をはじめとするメーカ独自のAPIなどを通じてバックアップを受け取る。バックアップは、いったんそのままの形でアプライアンスに届き、そののちに重複排除が実行される仕組みとなっている。ターゲット型重複排除では、ターゲット・デバイスのディスクスペースが節約できるが、バックアップ・クライアントとバックアップ・サーバ間のネットワーク負荷は一切軽減することができない。そのため、ターゲット型重複排除は、集中管理型のデータセンターなど、帯域幅の利用率があまり問題にならない環境に適していると言える。

これに対してソース型重複排除を行う製品は、バックアップ・クライアントとバックアップ・サーバに、カスタムメイドのバックアップ・ソフトウェアを必要とする。クライアントは、新規のユニークデータ群を検出して、サーバに、そのデータの重複の有無を問い合わせる。サーバが、クライアント（その他）のデータ群を過去にバックアップしていれば、サーバはクライアントに、ネットワーク経由でそのデータ群を送信してこないよう伝え、問題のデータ群が別の場所にあることを知らせる。そのデータ群が真にユニークなものと判断された場合は、データ群がネットワークを介して送られて、その由来が記録される。したがって、ソース型重複排除は、リモートオフィスやモバイルユーザーなど、帯域幅が非常に重要な環境に最も適している。

ターゲット型重複排除ソリューションのテスト

ターゲット型重複排除ソリューションを検討する際には、確認すべき事柄が3つある。それは、コスト、容量、それにスループットだ。重複排除システム（さらに言うならシステム全般）のコストというものを考えるとき、導入コスト（Capital expentidures: CAPEX）と運用コスト（Operational expenditures: OPEX）の両方を考慮に入れることを覚えておかなければならない。あるアプライアンスを使って、求めるスループットと容量モデルを実現するには、どのようなハードウェアおよびソフトウェアを入手しなければならないか。重複排除ソリューションのベンダーのなかには、システム購入の費用で、いとも簡単にCAPEX予算に達してしまうものがある。たとえば、30TBのデータ保存容量が必要で、1日に5TBのバックアップを取る場合、こちらの要求するコンピューティング性能、およびストレージ容量をすべて満たすには、「モデル x」のシステムが必要ですね、という具合だ。一方、ゲートウェイだけを提供して、既存のストレージに接続できるようにしているベンダーもある。また、ソフトウェアだけを提供しているベンダーもあって、この場合、ハードウェアの購入は顧客に一任されることになる。そのため、サーバの構成がベンダーの仕様に合っていることを確認して、サーバ（ハードウェア）の費用をコストに含めることも忘れてはならない。ゲートウェイのみ、ソフトウェアのみを購入するモデルの場合、比較のために、（たとえそれが「無償」だったとしても）ディスクの費用も含めておくようにしよう。重複排除ソリューションのコスト計算の方法は非常に個性的なので、既存のディスクを使わずに、実際に費用を節約できる方法が必ずある。

CAPEXについて考慮すべき最後の要素。それは、（必要に応じて）加える「追加」ディスクの費用だ。たとえば、ポストプロセス・システムに見られる「ランディングゾーン」や、データをオリジナルのフォーマットで保存し、迅速な取り出しに備える「キャッシュ」、あるいは重複排除データの保存に使用しないディスクなどがこれに当たる。これらのディスクもまた、購入システムの費用合計に加算しなければならない。

次に計算しなければならないのがOPEX。各ベンダーの評価を行う際には、メモを取りながら、システムの管理方法、ならびにシステムとバックアップ・ソフトウェア・ベンダーとの連携運用性を確認していこう。ハードとソフトを接続するカスタムメイドのインタフェース（Veritas NetBackupのOST APIなど）はあるか？ それとも、システムが単にテープライブラリあるいはファイルシステムとして仮想的に機能するだけか？ それによってOPEXはどうなるか？ ディスクドライブ、ディスクアレイなどシステム構成の一部を置き換えたらどうなるか？ グローバル重複排除を採用したら、あるいは採用しなかったら、ニーズに応じてシステムを拡張する際に、どのような問題が生じるか？

容量を試験する方法は2通りある。1つは、大量のバックアップを対象デバイスに送信し、そのバックアップの容量と、それがターゲットシステム上のストレージに占める容量を比較する、というものだ。この方法では、重複排除比率がわかる。この比率を増大させて、ディスク容量と、重複排除データがディスク内に占める容量を一致させれば、効率の良い容量が得られる。もう1つは、バックアップを対象デバイスの容量限界まで送信し、そこで送信完了したバックアップの容量を記録するという方法だ。この方法は先に述べた方法より時間がかかるが、長期的なシステムのパフォーマンスを測定するには、この方法しかない。（システムのなかには、容量限界近くに達すると、パフォーマンスが低下するものがある。）

最後に、パフォーマンス面でのテスト項目がいくつかあるので、それを挙げておこう。

データの取得／書き込み：（重複排除システムであるか否かに拘わらず）ディスクシステムで最初に測定すべき項目は、バックアップの取得（書き込み）性能だ。（技術的には、データのリストア性能のほうが重要だが、バックアップされていなければリストアもできない。）集合バックアップとシングルストリーム・バックアップの両性能を、忘れずにテストすること。

リストア／コピー／読み込み速度：（これも重複排除システムであるか否かに拘わらず）2つめの測定項目は、データのリストア／コピー（すなわち読み込み）性能である。ディスク・ツー・ディスク・ツー・テープ（D2D2T）のバックアップから始める理由は、ひとえに、ディスクをテープのバッファとして使用するため、ということを明らかにしておきたい。したがって、テープにバックアップコピーを取ろうとする際に、近代的なテープドライブへのI/Oを行なえないディスクシステムは、（重複排除システムか否かに拘わらず）的外れとなる。テープコピーのテストは、コピーを考えているシステムのテープドライブで行うこと。たとえば、別のシステムにレプリケートして、テープを作成する計画なら、そこでテストを行う。最後に、リストア速度については多くを期待してはいけない。そして、シングルストリーム・リストアと集合リストアの両性能をテストすること。

重複排除：データがネイティブフォーマットでデバイスに届いたら、そこで重複が排除されなければならない。インライン型のアプライアンスは、データ到達と同時に重複排除を行う。オリジナルのデータがディスクに到達することはないので、インライン型アプライアンスの重複排除速度は、データの取得速度に等しい。ポストプロセス型の場合は、データの重複排除に数秒から数時間程度の時間を要する。ここで必要なのは、実際に重複排除にかかった時間を測定することだ。

レプリケーション：重複排除率はレプリケーションにも関わってくる。重複排除率が高ければ、レプリケートされるデータブロックがそれだけ少なくなるはずだ。しかし、レプリケーションの機能のしかたを確かめるには、実際にレプリケーションを実行してみるしかない。レプリケート（複製）されたデータブロックの量をチェックして、レプリケーションの開始時刻と終了時刻を記録する。この測定データは、重複排除システムのベンダーから入手できる可能性があるということと、自分で試験する場合、このデータを得るにはネットワークツールが必要になる場合がある、ということを覚えておいてほしい。そして、必ずしもすべてのベンダーが、重複排除と同時にレプリケーションを開始していないということも。もちろん、重複排除が行われないかぎり、レプリケーションも開始されないのだが、インライン型のベンダーが必ず、重複排除と同時にバックアップのレプリケートを行っていると考えてはいけない。実際には、テープ容量がフルになってから、あるいは（NASの場合）ファイルが閉じられてから、レプリケートを行うベンダーが多いはずである。

稼働中のデータを使ったテストの注意事項

ターゲット型重複排除システムのテストでは、実際に稼働中のデータを使って、システムへのバックアップ保存を試みなければならない。ただし、稼働中のシステムを直接、重複排除システムにバックアップしようとしないこと。実際の状況と同じように、リストアに備えてバックアップを保存しようとするときに、さらにそのシステムのバックアップを取るのは困難なため、ベンダーはそのような試験のやり方を推奨するだろうが、テストシステムをいきなり稼働中のシステムに組み込むのは好ましくない。

では、稼働中のシステムをテストシステムでバックアップせずに、どうやって重複排除システムのテストを行うか？ その方法はいたってシンプルだ。取得済みバックアップデータを、テープもしくはディスクから重複排除システムにコピーすればいい。リストア／コピー速度を確認したければ、バックアップを重複排除デバイスからディスクあるいはテープにコピーする。なぜなら、コピー時に重複排除システムが必ず通る「再構成」プロセスがまさに、リストア時に行われる処理に等しいからだ。

さて、重複排除システムでバックアップ保存のテストを行う期間を決めよう。これはわたしの意見だが、たとえば、テスト期間を90日と定めたなら、90日間テストシステムでバックアップ保存を行わなければならない。（90日分のバックアップを保存するのに90日はかからない。）

バックアップ・テストの期間を90日と決めたら、開始日を決めてフルバックアップ（あるいはIBMのTivoli Storage Managerなら、バックアップセット）でテストを行い、それを90日間継続する。複数の重複排除システムのテストを行う場合、どのテストでも必ず同じバックアップを使用すること。（条件統一、すなわち、他のファクターがすべて同じ環境で試験を行うということだ。）1日目のフルバックアップ（あるいはバックアップセット）をコピーし、つづいて2日目のバックアップ、3日目のバックアップを順にコピーしていき、この操作を90日目まで続ける。

それぞれの擬似「バックアップ日」は、シングルバックアップ（バックアップ操作1回分のバックアップセットの完全コピー）と、同時バックアップ（テープドライブの数と同数の同時コピー）、重複排除、およびレプリケーションで構成される。可能なら、同時バックアップは、システムのスループット限界で実行されるのが望ましい。これらの操作がすべて完了したら、次のバックアップテープのセットをシステムにコピーして、翌日の「バックアップ」処理を継続すればいい。

バックアップ・テスト最初の週を含む、各擬似「バックアップ週」の初日には、複数回リストアテストを行うものとする。リストア速度を測る最良の方法は、実際に想定されるサイズのバックアップセットを、重複排除システムからテープへコピーするやり方だ。まずは2セットのシングルリストア（1回分のバックアップセットを、重複排除システムからテープへ完全にコピーする）を単独で行って、次に2セットの同時リストア（重複排除システムからテープへ、テープドライブの数と同数の同時コピーを行う）を行う。各テストで2セットのコピーを行うのは、各テストサイクルで、最も古いバックアップのコピーと、最新のバックアップのコピーを試してみるためだ。これにより、様々な条件でのリストアタイムの比較が可能になり、古いバックアップと新しいバックアップでの比較、および、システムがほぼ空の場合と、システムがフルに近い場合の比較ができる。

このテストを正確に行うために重要な鍵となるのは、自動化だ。自動化することで、24時間連続でテストが可能になり、各処理のタイミングが最も正確に測定できる。また、自動化は条件統一にも役立つ。これは、複数のシステムをテストする際には欠かせない条件だ。可能なら、バックアップ・サーバとテープライブラリを完全に分けて、独立させて用いてもいい。この方法では、テストがバックアップトラフィックから切り離されるので、稼働中のバックアップのためにも、また稼働中のバックアップがテストに影響を及ぼさない、という点でも利点がある。

ソース型重複排除ソリューションのテスト

たいていの場合、ソース型重複排除は、すでに廉価なテープドライブへのバックアップを通じて「ジョブを行っている」バックアップ・ソフトウェアの代替技術と考えられている。たしかに、ソース型重複排除に置き換えると改善できる問題点も多いが、既存のシステムを置き換えようというのだから、それだけソース型重複排除製品に大きなメリットが求められることになる。

基本的なバックアップ機能：今、この製品を使って、サポートしているクライアントすべてのバックアップ、およびリストアを行わせようとしていると仮定する。だとすると、現在、既存のバックアップシステムで行っている処理すべてを試してみる必要がある。自動バックアップを実行して、どの程度うまくいくか見てみよう。もし何か不具合が見つかった（故意に不具合を生じさせるほうがいいのだが）場合、次にどのようなことが起こるか？ 失敗したバックアップを再試行したら、どのようになるか？ リストアはどうか？ 管理者、あるいはユーザーはそれらの処理ができるか？ 使いなれたワークフローは、この新システムに適用できるか？

一歩進んだバックアップ機能：セカンダリサイトにバックアップをレプリケートしようと計画しているだろうか？ それとも中央の一元管理ステーションにすべてのバックアップをレプリケートしてから、その一部ないしは全部をテープにコピーする計画だろうか？ こうしたニーズはどの程度満たされるか？

パフォーマンス：新システムで獲得できるバックアップ性能は？ レプリケーションの速度は？ ケーブル線を通じてどれくらいのデータが送信できるか？ （機器が異なれば、ケーブル線経由で同じ容量のデータ送信は期待できない。）遠隔地へのレプリケーションを考えている場合、レイテンシーや信頼性の低い接続が製品全体のパフォーマンスおよび安定性に及ぼす影響はどうだろうか？

ターゲット型重複排除と同じく、テストでは生のデータを用いるに越したことはない。しかし、ターゲット型重複排除の場合と異なり、実際にバックアップしようとしているシステムタイプのバックアップを除いて、すべてのテストを確実に行うのは非常に困難な場合がある。テストシステムのバックアップはできるだろう。しかし、そのテストは、「Exchangeデータベースにメールを送信する」とか「ファイルシステムに新規／更新ファイルを書き込む」といったユーザーのアクティビティを模倣できた場合にのみ有効となる。このような内容変更がなければ、ソース型重複排除システムは非常にうまく機能するだろう。しかしそれでは、そのシステムが実際の環境でどの程度のパフォーマンスを示してくれるのか、なんの洞察も得られないことになる。

大規模なテスト環境で、実際にユーザーのアクティビティを模倣できることは、ほとんどない。したがって、その代わりに実際のシステムのバックアップを行うことが、唯一の選択肢となる。問題のソフトウェアが、テストしようとしているシステムタイプのテスト環境で動作することが確認できたら、バックアップしようとしているシステムタイプの代表として、「実際の」システムで概念実証を開始すればよい。リスクを最小限に減らすため、ノートPCなど、現在バックアップを行っておらず、ミッションクリティカルなアップタイム要件のないシステムで始めるのがよいだろう。ソフトウェアのテストユーザーを何人か選び、これが試験プログラムであることを伝えて、その感想を報告してもらう。まずは短期的にこれらのシステムでデータを取れば、そのあとはリモートサイトのファイルサーバに試験を拡張することもできるし、さらには（Exchangeなどの）アプリケーションサーバへと拡大することもできる。新しいシステムタイプのバックアップを開始するときは、システムの安定性あるいはパフォーマンスに悪影響が及ぶ可能性のあることを肝に銘じておくこと。したがって、テスト中は、どんな不安定要素も見逃さないよう、注意してモニターしていなければならない。

概念実証テストでバックアップを行ったシステムは必ず、新システムを実用的に稼働させられるまで、既存のメソッドでバックアップを継続するべきである。Windowsシステムであれば、リセット機能やWindowsのアーカイブビットを用いて、両プログラムが互いに干渉しないようにしておかなければならない。最も悪いのは、両プログラムを併用していて、次の製品が稼働し始めるまで、新しいファイルや更新ファイルのバックアップが行われていて、そのあとの製品にバックアップが引き継がれなかった場合である。並行して動作している2つの製品に、アーカイブビットがどのように影響するか、確認しておかなければならない。

システム導入に際して、これらの疑問はすべて、確実にクリアにしておく必要がある。また、想定される事象は、すべてシミュレートしておこう。たとえば、ノートPCのユーザーが、自分のマシンをバックアップの途中でサスペンド・モードにしてしまったら？ Ethernetケーブルが抜けてしまったら？ あるいはインターネット接続がタイムアウトになってしまったら？ そして、最も答えの出にくいのが、実際にはネットワークを介してどれだけのデータが送信されるかということだろう。これについては、サードパーティのネットワーク監視ソフトウェアを利用して、信頼できる数字を入手しておいたほうがいいかもしれない。

ここで述べてきたことは、どれも容易なことではない。しかし、きちんとしたテストもなく重複排除システムを購入するのは、リスクがあまりにも大きく、それを考えると、やはりテストを省略する気にはならないはずだ。なかには、製品の性能を大幅に誇張して伝えるベンダーもあるだろうから、そこから真実を見つけ出すには、テストをするしかないのである。そして、そのひと手間が経費の節約にもつながるだろう。

All Rights Reserved, Copyright 2000 - 2009, TechTarget
*この翻訳記事の翻訳著作権はJDSFが所有しています。 このページに掲載されている記事・写真・図表などの無断転載を禁じます。