NetApp Tech OnTap
NetApp VTLによるバックアップデータストリームの重複排除

ここ1年ほどTech OnTapを定期購読されている方であれば、FASストレージシステムのNetApp重複排除テクノロジについて、多くの記事を目にされたことと思います。この記事では、従来とは違った新しい重複排除テクノロジである、VTLシステムでの重複データの排除について説明します。冗長なデータを排除してスペースを節約するという結果は同じですが、NetApp® VTLでは、まったく違った方法でこの目的が達成されます。

NetApp VTLで使用される重複排除テクノロジは、Symantec™ NetBackup™、Tivoli Storage Managerなど、一般的なバックアップアプリケーションで生成されるバックアップデータフォーマットの重複排除に関する特有の要件を満たすように設計された、完全に新しいテクノロジです。NetApp VTLの重複排除は、独自に開発した新しい重複排除アルゴリズムに、NetAppの高性能なハードウェア圧縮など、NetApp VTLの各種機能を組み合わせることで、バックアップデータセットの20:1以上のスペース削減という非常に高度なストレージの利用効率を達成します。



NetApp VTLの重複排除および圧縮パイプライン

図1)NetApp VTLの重複排除および圧縮パイプライン

VTLの重複排除に関する重要な考慮事項

データセンターで従来使用されてきたテープライブラリの代わりに仮想テープライブラリを使用すると、複数のバックアップデータストリームをきわめて高速に、直接ディスクストレージに書き込むことが可能になります。このような環境で重複排除を提供する場合、考慮すべき独自の要件がいくつかあります。

重複をデータ配列に依存せずに検索できること: VTL重複排除の最大の要件は、データアラインメントから独立する必要性です。ほとんどのバックアップアプリケーションで生成されるフォーマットでは、重複データはバックアップデータストリーム内のあらゆるオフセットに存在する可能性があります。そのため、どの場所にどれほどの長さの重複データが存在しても、確実に発見できるような方法で重複排除分析を行う必要があります。これは、重複した固定サイズブロックを発見するというような単純な処理ではありません。
NetApp VTLがどのような方法で重複データを検出するかについては、このあとのセクションで詳しく説明します。今のところは、重複データがどの場所で始まり終わったとしても、NetApp VTLは必ずその重複データを検出できるという点を理解するだけで十分です。

フォーマットからの独立性: ある種の重複排除アルゴリズムでは、バックアップデータフォーマットのリバースエンジニアリングを行い、そのフォーマットに関して事前に得た知識に基づいて重複データを排除するというアプローチが採用されています。このようなアプローチの場合、フォーマットには非常に多くの種類が存在するという問題点があります。
現在、広く普及しているバックアップアプリケーションだけでも5、6種類はあり、それぞれデータフォーマットが異なります。さらに、1つのアプリケーションだけでもデータタイプ別(データベース、ファイルデータなど)に異なるデータフォーマットを使用している場合があります。これらのフォーマットは独自仕様のものが多く、予告なく変更されることがあります。NetApp VTLは、フォーマットに依存したアプローチは潜在的に問題が多いという認識に基づき、バックアップ(またはすべての)データストリームをあいまいなデータとして処理し、データストリームをデコードする機能に頼らずに重複排除を実行します。

インラインまたはポストプロセス:もう1つの重要な考慮事項は、重複排除をインラインで(各データストリームを取り込んだ時点で)実行するか、それとも、データストリームをディスクに書き込んだあと重複排除をポストプロセスモードで実行するかという点です。ストレージの観点からみると、インラインアプローチの方がより効率的です(なぜなら一時的にせよ、重複データがディスクに書き込まれることがないからです)。一方、重複排除をインラインで実行すると、アプリケーションによるデータストリームの書き込みが低速化し、それによってバックアップの所要時間が長引くというリスクがあります。

NetApp VTLでは、「両方の良い部分を採用する」アプローチを選びました。NetApp VTLの重複排除アルゴリズムは、「レート適応型」設計となっています。つまり、バックアップアプリケーションのスループット要件に応じて、インラインで動作する場合もあれば、ポストプロセスを実行する場合もあるということです。バックアップワークロードが変化した時点で、動作モードを自動的に切り替えるように設計されています。このレート適応機能は、段階的にロールアウトしていく予定です。最初の実装では、データ取り込み速度を高く保つために、ポストプロセスだけを実行するようになっています。初期リリースでは、ポストプロセスだけで重複排除が実行されますが、重複排除プロセスの一部はインラインで実行され、インラインモードとポストプロセスモードがレート適応型方式で切り替わります(この記事で後述する、アンカー生成についての説明を参照してください)。

ハッシュレベルまたはバイトレベルの比較:重複排除の分野では、「ハッシュコリジョン」、すなわち2つの異なるデータに対して同じハッシュ値が作成されて、一意のデータが廃棄される状況が発生するという問題が、長年にわたって論議を呼んでいます。NetApp VTLの場合、この潜在的な問題による影響はありません。ほとんどのアルゴリズムと同様、NetApp VTLはハッシュを使用して潜在的な重複データを識別しますが、そのあと完全なバイト単位の比較を実行することで、一意のデータの消失または破損を回避します。

圧縮:もう1つ重要なのは、重複排除にデータ圧縮のメリットを組み合わせることが可能かどうかという問題です。NetApp VTLでは、重複排除とハードウェアベース圧縮のメリットをどちらも完全に利用できます(NetApp VTLに実装されたハードウェア圧縮については、Tech OnTapの過去記事 で紹介しています)。重複排除に加えてソフトウェアベース圧縮を提供しているベンダーもありますが、ハードウェアアクセラレートされた圧縮のメリットを重複排除に組み込むことができるのはNetAppだけです(図1)。

重複排除すべきかどうか: 最後の問題は、着信データの重複排除が本当に必要かどうかという点です。重複データの排除処理は、(どのように実装しても)必然的にかなりの処理能力の犠牲を必要とします。つまり、さほどメリットがないと予測される状況で、データの重複排除を実行するのは合理的ではないのです。たとえば、保存期間の短い増分バックアップの場合、重複排除によるオーバーヘッドを正当化できるほど、十分なスペース節約効果が上がらない可能性があります。

NetAppであれば、仮想ライブラリごとに重複排除をオンまたはオフに設定できます(1つのNetApp VTLを複数の仮想ライブラリで構成可能です)。他社製のVTLでは、重複排除が常に必須となっている場合があります。

NetApp VTLの重複排除アルゴリズム

NetApp VTLは、可変ブロックサイズおよび可変バイトオフセットに加えて、スキップフィルタなどの高度な技法を使用し、どのようなオフセットの重複データも識別して、バックアップデータストリームを重複排除するときの効率性を最大限に高めます。この設計では、NetApp独自のポリシー駆動によるレート適応型方式の利点を活かし、要求されるデータ取り込み速度に応じて、部分的インライン重複排除(アンカー生成)と完全なポストプロセスを自動的に切り替えることにより、バックアップウィンドウに確実に適合します。

NetAppはVTL専用にこのテクノロジを自社開発しました。既存のVTLコードベースに付け足された他社の重複排除テクノロジとは異なり、このテクノロジはコアVTLソフトウェア内部に組み込まれています。NetAppは、このアルゴリズムで複数の特許を申請中です。
NetApp VTL重複排除アルゴリズムは、次の4つの主要テクノロジに依拠しています。

  • アンカー生成
  • Grow by Compare(GBC)
  • スキップ
  • ハードウェア圧縮

アンカー生成: このテクノロジは、データストリーム内で「関係のある」データポイントの初期的なマークアップを実行します。これらの「関係のある」データポイントの一部が「アンカーポイント」になり、同じデータセグメントを識別するための開始点として使用されます。アンカー生成は、高速かつ効率的なローリングハッシュ関数を使用し、通常はインラインで(データの取り込みと並行して)実行されます。重複データの位置がバックアップのたびに変化する場合、そのデータに含まれる一意のアンカーも一緒に移動するため、迅速な識別が可能になります。

アンカーはディスクに保存され、アグレッシブにキャッシングされて、高速ルックアップに対応します。NetAppのアルゴリズムでは通常、64 Kのデータごとに約3つのアンカーが生成されます。同じハッシュIDを持つアンカーがある場合、それらのアンカーが存在するデータストリームに重複データがある可能性が高いと考えられますが、バイト比較を実行するまでは完全に同じであるとはみなされません。

Grow by Compare(GBC): 重複する値のアンカーが発見された場合、シーケンシャルバイト比較が実行されて、データが100%確実に一致しているかどうかが判別されます。この比較はアンカーポイントから前後両方向に実行され、一致しているデータセグメントの全長が判別されます。

GBCのユニークな点は、任意の長さの重複シーケンスを排除できる点です。つまり、単なる固定長ブロックではなく、真のバイトレベルのきめ細かさで無制限の可変長セグメントが排除されます。保存済みのデータと一致するデータセグメントが発見された場合、そのデータは保存済みセグメントへの参照に置き換えられます。


図2)アンカー生成とGBCの概念を紹介するビデオ


GBCチェックでは、すべてのバイトの一意性がチェックされるので、他社が使用しているハッシュベースアルゴリズム(ハッシュコリジョンが起こるとデータが損失する)よりも安全です。

スキップは、本来であれば重複しているはずのデータセグメント間で発生する、ファイルヘッダーやバックアップアプリケーションのメタデータによる些細なバリエーションに効率的に対応します。スキップは、データストリームに埋め込まれたメタデータの変化を除外し、ディスクから効率的に読み取ることが可能な、長い範囲に及ぶrawバックアップデータを残すことによって、GBCの効率性を著しく高めます。競合他社ソリューションでは、重複排除アルゴリズムによってデータが細分化する作用があるためにパフォーマンスの問題が見られますが、スキップはそのような問題を実質的に解消します。


図3)スキップの概念を紹介するビデオ


ハードウェアベース圧縮: 一意のデータはすべて、NetApp VTLのハードウェアベース圧縮カードを介してディスクに書き込まれます。これらのカードでは、効率的な従来型の圧縮アルゴリズム(ディスクに保存可能なデータ容量を通常2倍に増やし、重複排除の有無を問わず使用可能)を採用しています。ハードウェア圧縮は、ポストプロセス重複排除と連携して動作します。すべてのデータが取り込みと同時に圧縮されるので、ディスクに保存するデータ量は約半分だけで済み、そのあとで重複排除が実行されます。

まとめ

NetAppはVTLの要件に独自の方法で対応する、効率性に優れた重複排除方式の開発に取り組んできました。このテクノロジには、次のような特長があります。

  • バックアップフォーマットに依存しないため、あらゆる種類のデータストリームに対応します。
  • インラインモードおよびポストプロセスモードの両方で動作します。
  • ハッシュコリジョンによるデータ損失の可能性がありません。
  • ハードウェア圧縮と連携し、最高のパフォーマンスを達成します。
  • 重複排除が不要なデータセットについてはオフに設定して、処理性能の消費を回避できます。

NetApp独自のアプローチでは、ローリングハッシュ比較によって作成される一意のアンカー、同じアンカーの前後両方向での比較による重複データセグメントの識別、および本来であれば重複しているはずのデータに埋め込まれたファイルヘッダーやバックアップメタデータをスキップする機能を組み合わせることで、アラインメントの独立性を達成し、最高の効率性を実現しています。


Keith Brown Keith Brown
テクノロジ担当ディレクター、NetApp

Keithは11年以上前にNetAppに入社し、現在はData Protection and Retention Groupに所属しています。彼はさまざまなNetApp製品およびテクノロジについて技術およびマーケティングを担当してきました。現在、Keithの仕事の中心はData ONTAP™ Snapshot™ベースのバックアップおよびレプリケーション製品、NetAppのデータ重複排除テクノロジ、およびNetApp VTLです。


関連情報