それ、レプリケーションでよろしく。UDPともども。

■ おさらい：Arcserve UDP の重複排除とハッシュ メモリ

本題に入る前に、Arserve UDP の重複排除の仕組みを理解しておく必要があります。いきなり脱線ですが、少しお付き合いください。

重複排除では過去にバックアップしたデータ ブロックを再度バックアップしなくて済むように、データ ブロックごとに計算したハッシュ値を比較します。

ハッシュ値は RPS 内のハッシュ デスティネーション（※1）に記録されますが、都度、ディスクの中のハッシュを読み出すとバックアップが遅くなってしまいます。そこで、Arcserve UDP では RPS のメモリにハッシュをキャッシュし、過去に同じデータ ブロックをバックアップしたかどうかの判定を高速に行えるようになっています。

（デフォルトだとすべてのハッシュがメモリ上でキャッシュされます。）

デフォルトの設定だと、RPS はすべてのハッシュをメモリ（RAM）に展開します。この状態を「RAM モード」と呼んでいます。

ハッシュを展開するための十分な物理メモリを RPS に積んでいない場合は「SSDモード」という設定にします。これは、ハッシュ デスティネーションが SSD 上にあるとみなして、一部のハッシュのみをメモリにキャッシュするモードです。メモリに展開するハッシュの量を管理者側で決められます。

下の画像はデータ ストアの設定画面の抜粋です。ここで [ハッシュ デスティネーションは SSD（Solid State Drive）上にあります。] にチェックを入れないのが RAM モード。チェックを入れるのが SSD モードです。

[ハッシュ メモリの割り当て] はハッシュの展開先としてデータ ストアに割り当てられているメモリの量です。

■ ジャンプスタートでは一時的にメモリ使用量が2倍に……

さて、いよいよジャンプスタートの話です。

ジャンプスタートでは最初に本番サイトの RPS に NAS や外付け HDD などの外部ストレージを接続してデータを複製します。本番サイトの RPS は元々のデータ ストアと複製先の一時データ ストアの2つをもつ形になります。

ジャンプスタートによるデータのコピーは内部ではレプリケート（複製）タスクとして実行されます。バックアップ データが元のデータ ストアからジャンプスタート用の一時データ ストアに複製されると同時に、ハッシュもメモリに展開されます。

（ハッシュ デスティネーションは外部ストレージでも、キャッシュ先のメモリは RPS のものが使われます）

おわかりいただけましたでしょうか……ジャンプスタートにより RPS 全体のバックアップ データの容量は一時的に2倍（※2）になるので、ハッシュのキャッシュ先として使用されるメモリも2倍になります。

ここで怖いのが物理メモリ不足です。ジャンプスタートを想定してサーバのサイジングをすることはあまりないので、2倍のハッシュを物理メモリに展開しきれないことがあります。

物理メモリが枯渇するとページングが発生してジャンプスタートのスループット（データをコピーする速度）が遅くなります。最悪データ ストアが停止してジャンプスタートが失敗します。

■ ハッシュ メモリ不足を回避する3つの方法

この物理メモリ不足問題を回避する方法として、以下の3つが考えられます。

回避策 1：デデュプリケーション ブロック サイズを大きくする

回避策 2：ノードごとに小分けにしてジャンプスタートを行う

回避策 3：SSD モードを使う

1つ目は [デデュプリケーション ブロック サイズ] の調整です。この値が小さいほど効率よく重複排除が行われますが、ハッシュの量は増えることになります。逆にこの値を大きくすれば重複排除の効率が落ちる代わりにハッシュ メモリの使用量が減るというわけです。デフォルト値は「16 KB」で、「4 KB」 ～「64 KB」の範囲で設定できます。

ブロック サイズはデータ ストアの作成時に設定できるので、メモリが不足しそうな場合は、外部ストレージ上の一時データ ストアのデデュプリケーション ブロック サイズは大きく設定しておきましょう。

<参考記事>

Arcserve UDP 機能紹介 ～ (10) バックアップデータの重複排除 ～

2つ目の回避策ではジャンプスタートをノード毎に分けて行います。

ジャンプスタートでは以下の画面でデータを複製するバックアップ対象ノードを指定することが出来ます。一度にすべてのノードのデータをジャンプスタートするのではなく、いくつかの一時データ ストアに分けてジャンプスタートすれば、瞬間的なメモリ使用量は小さく抑えられます。

<参考記事>

Arcserve UDP のジャンプスタートを試してみる

3つ目の回避策では先ほどご紹介した SSD モードを使います。SSD モードであればすべてのハッシュをメモリに展開することはないので、物理メモリ枯渇を回避できます。

（一時データ ストアを SSD モードにすれば、その分だけ RPS のメモリ使用量が減ります。）

SSD モードではどこを [ハッシュ デスティネーション] にするのかが問題になります。ハッシュもジャンプスタートで災害対策サイトの RPS へ運ばなければいけないので、当然搬送用の外部ストレージ上のフォルダを指定する必要があります。

実は、SSD モードはハッシュ デスティネーションが SSD 上のフォルダでなくても有効にすることが出来ます。しかし、HDD は RAM や SSD に比べて IOPS が劣るので、ジャンプスタート ジョブに時間がかかります。できれば外部ストレージにも SSD を搭載しておきたいところです。

■ ジャンプスタートのベンチマーク結果を大公開！！

そこで、遠隔地の RPS にデータを運ぶ物理媒体として SSD を搭載した NAS を用意し、RAM モード、SSD モード（ハッシュは NAS の HDD 上に保存）、SSD モード（ハッシュは NAS の SSD 上に保存）の3パターンでジャンプスタートを行い、所要時間を測定しました。

1.32 TB のバックアップ データ（重複排除/圧縮済み）をジャンプスタートで複製した際の時間の比較がこちらです。

Case 1 は RAM モードで、やはりこの条件が一番短時間にジャンプスタートできています。RPS にジャンプスタート分のメモリの余裕があれば、このモードがベストです。

Case 2 は ハッシュを外部ストレージの HDD に保存するにも関わらず、SSD モードを有効にしています。RPS のメモリを 1 GB しか使っておらず、メモリに納まらないハッシュは NAS の HDD 上にあるハッシュ デスティネーションを直接参照しに行っており、3つのケースの中で一番時間がかかっています。

Case 3 は NAS 上の SSD にハッシュを保存し、SSD モードを有効にしています。RAM モードよりは多少時間がかかっていますが、ハッシュ デスティネーションを HDD にしている Case 2 と比べて大きく時間が短くなっています！！

以上のベンチマークから、SSD を搭載した外部ストレージを使用すれば、本番サイトの RPS に十分なメモリが無かったとしても、速度を大きく落とさずにジャンプスタートを行えることが分かりました。

なお、ベンチマーク テストの概要と各マシンのスペックは以下をご覧ください。SSD は SATA 接続のものを使っています。

以上、ジャンプスタート実行時の注意点と回避策、ベンチマーク テストをホテがご紹介しました。大容量のデータを災害対策サイトに複製する際にお役に立てば幸いです。

※1 バックアップ データの保存先のことを「デスティネーション」と呼んでいます。

※2 各データ ストアのデデュプリケーション ブロックサイズや、バックアップ対象ノードが異なればこの比率は変わってきますが、ここでは話を単純にするために2倍と言っています。