「Avamar：バックアップ パフォーマンスの動作と理論

この記事の目的は、読者がバックアップ パフォーマンスの動作を理解できるようにすることに焦点を当てて、Avamarバックアップ中に何が起こるかを説明することです。

この記事は、次の記事に付随するものです。

• 「Avamar：バックアップ パフォーマンスが低下する場合のトラブルシューティング
• 「Avamar：バックアップをチューニングして迅速に完了

Avamarバックアップ中に何が起こりますか?

avtarバックアップ プロセス:

1)ファイルとハッシュ キャッシュ ファイルをメモリーにロードする

2017-06-09 23:00:25 avtar Info <5586>: Loading cache files from C:\Program Files\avs\var
2017-06-09 23:00:25 avtar Info <8650>: Opening filename cache file 'C:\Program Files\avs\var\f_cache2.dat'
2017-06-09 23:00:25 avtar Info <5573>: - Loaded filename cache file (6,532,792 bytes)
2017-06-09 23:00:26 avtar Info <8650>: Opening hash cache file 'C:\Program Files\avs\var\p_cache.dat'
2017-06-09 23:00:28 avtar Info <5573>: - Loaded hash cache file (402,653,728 bytes)
2017-06-09 23:01:01 avtar Info <6426>: Done loading cache files

2)VSSスナップショットを作成します(Windowsの場合)。

2017-06-09 23:04:32 avtar Info <19008>: Obtaining available VSS providers
2017-06-09 23:04:32 avtar Info <8776>: Freezing volumes now...
2017-06-09 23:04:32 avtar Info <8780>: Creating the shadow copy set (DoSnapshotSet) ... 
2017-06-09 23:14:33 avtar Info <8781>: Shadow copy set successfully created.
2017-06-09 23:14:34 avtar Info <6074>: VSS snapshot set creation successful

3)データセット
によって定義されたすべてのファイルをウォークします ソースデータセット内のすべてのファイルについて、avtarはフルパスを取得し、それをstatのようなメタデータと組み合わせてハッシュを計算し、ファイルを一意に識別します。

詳細については、「Avamar: avtarがファイル スキャン フェーズ中にファイルを読み取ると何が起こるか。

4)計算されたハッシュをローカルクライアントキャッシュ内のハッシュと比較しますAvtar

は、ファイルキャッシュ内のファイルのハッシュを検索します。新しいものか、前回のバックアップ以降に変更されたものかをチェックします。

ファイル キャッシュ ルックアップが成功した場合、ファイルは存在し、変更されていません。

検索に失敗した場合、ファイルは新しいか、変更されています。これを読み取って処理する必要があります。

詳細については、「Avamar Client - avtarがファイルが変更されたと見なす前に何を変更する必要がありますか?」を参照してください。

5)新規および変更されたファイルを処理する。新規または変更されたファイル

については、 avtar は次のことを行う必要があります。

• ファイル全体を読み取ります
• 可変サイズのチャンクに分割する
• 各チャンクを圧縮
• 各チャンクのハッシュを計算する

6)欠落しているハッシュがAvamar Serverに存在するかどうかを確認します。

Avtar は、欠落しているハッシュのデータをネットワーク経由でAvamar Serverに送信し、すでに存在するかどうかを確認します。これらは「ispresent」要求と呼ばれます。

7)データがAvamar Server(および該当する場合はData Domain)に書き込まれます。

詳細なワークフローについては、添付の Avtarprocess.pdfを参照してください。


パフォーマンスの観点から見たAvamarバックアップの概要:

上記の段階を、バックアップ パフォーマンス

に最も大きな影響を与える「フェーズ」、つまりフェーズ0に分割します。VSSスナップショットを作成します。

ボリューム シャドウコピー サービス(VSS)は、ソース データセット内で指定されたボリュームのスナップショットを作成します。アプリケーションは、バックアップの実行中もボリュームへの書き込みを続行できます。
Avamarは、書き込み可能ボリュームではなく、ボリュームの読み取り専用の「フリーズ」スナップショットをバックアップします。これにより、バックアップするデータの整合性が確保されます。

VSSスナップショットの完了には数秒かかります。クライアントでVSSの問題が発生している場合、この遅延によってバックアップの続行が妨げられます。

フェーズ1。ファイル スキャン フェーズ。avtarプロセスは、ターゲット データセット

内のすべてのファイルを統計します何百万ものファイルを持つクライアントの場合、このフェーズは最も時間がかかる可能性があります。
データベース データには大きなファイルが少ないため、ファイル スキャン フェーズにはほとんど時間がかかりません。データベース クライアントは通常、フェーズ #2 で時間を消費します。

RAID 5構成の回転ディスクを搭載したクライアントの場合、1時間あたり~100万ファイルのファイル スキャン パフォーマンスが一般的です。これは、毎時 300,000 から 300 万までさまざまです。これは 、クライアント環境とバックアップされるデータの特性によって異なります。

v7.3以降、Data DomainにバックアップするLinuxクライアントは、Linux高速増分(LFI)機能を利用できます。これにより、バックアップを実行するたびにデータセット全体がスキャンされるのを回避できます。

重要なリソース: バックアップ データが格納されているディスクのパフォーマンスをランダムにシークします。

フェーズ2。Avtarは、変更されたファイルを読み取り、データのチャンク、圧縮、ハッシュ化を行います。

このフェーズでは、多くの計算が行われます。変更されたファイルまたは新しいファイルごとに、avtarはそれを小さなチャンクに分割します。各チャンクを圧縮し、チャンクを識別するための「フィンガープリント」としてハッシュを計算します。

データベース バックアップのファイルは、多くの場合、サイズが大きく、毎日変更される傾向があります。Avtar は、このフェーズでほとんどの時間を費やします。公式のAvamarデータベース プラグインを使用して、増分バックアップ機能、トランザクション ログなどを活用して、データベースが効率的に処理されるようにすることをお勧めします。

一般的なファイル処理パフォーマンスは1時間あたり約100 GBですが、最大で1時間あたり300 GBまで変動する可能性があります。これは環境によって異なります。

重要なリソース: クライアント ディスクとCPU

Avamar Serverへのデータ送信にボトルネックがないLANバックアップの場合、フェーズ#1と#2には最も時間がかかります。

次の表では、グラフの棒の面積がバックアップにかかる時間に対応していることを考慮してください。ファイルが変更されると、特にファイルが大きい場合に、必要な時間が大幅に増加する可能性があります。

ファイルシステムデータセットの場合、ファイルの0~3%が毎日変更されることが予想されます。

Avtar は、2つのI/O操作(1つはファイル属性のチェック、もう1つはセキュリティ属性のチェック)を実行して、変更される各ファイルを「stat()」する必要があります。

ファイル システム バックアップで1~100万ファイル/時のベンチマーク スキャン レート パフォーマンスを達成するには、 avtar では1時間あたり約200万回のシーク操作、つまり1秒あたり600回のシーク操作が必要です。

例：バックアップの変更率が3%の場合、100個のファイルのうち97個のファイルが変更されたかどうかを識別するために、2つのディスク シーク操作が必要です。変更された残りの3つは、スキャン、チャンク化、圧縮、ハッシュ化する必要があります。

この場合、ファイル スキャン フェーズのみが考慮され、変更されたファイルの処理に必要なI/Oリソースは考慮されません。
変更されたファイル内のデータが多いほど、バックアップを完了するために必要な作業が増えます。

フェーズ3。Avamar Server

上のハッシュの有無の確認フェーズ#1と#2では、バックアップの要素を指すハッシュを生成します。これらの要素は、一意のファイル チャンク、ファイル システム、またはバックアップ全体である可能性があります。

ハッシュはクライアント キャッシュ ファイルに書き込まれ、新しいデータを追加する必要があるかどうかを確認するために、Avamar Serverに存在するハッシュと比較されます。これは、Avamar ServerとData Domainのどちらがターゲット ストレージであるかに関係なく当てはまります。

Avamarクライアントとサーバー間のハッシュ比較は通常高速です。Avamar Serverが以下の場合、バックアップのボトルネックにはなりません。

• 健康
• 通常の負荷レベルでは
• クライアントと同じLANセグメントにある

ハッシュのサイズはわずか 20 バイトであるため、このフェーズはネットワーク帯域幅よりもネットワーク遅延の影響を受けます。ハッシュがAvamar Serverに到達すると、データ ノードのディスク サブシステムの一般的な負荷とランダム シーク パフォーマンスによって、ハッシュが取得される速度と、クライアントから送信されたハッシュとの比較が決定されます。

重要なリソース: ネットワーク レスポンス タイムとAvamarデータ ノードのランダム シーク パフォーマンス。

物理Avamarのランダム シーク パフォーマンスは、データ ノードの数とサイズによってスケールされます。AVEシステムのパフォーマンスは、シングル ノード システムと比較して劣ります。

フェーズ 4.ネットワーク経由で新しいチャンクをAvamar ServerまたはData Domain

に送信するクライアントが新しい一意のチャンク(最大64 KBのサイズ)をサーバーに送信する場合、パフォーマンスは主にネットワーク帯域幅に依存します。これは主に、毎日大量の変更データを生成するWANベースのクライアントに影響します。また、輻輳したネットワーク リンク経由で操作しているユーザーにも影響する可能性があります。

以下は、クライアントがAvamarシステムとAvamar - Data Domain統合システムにデータを送信するデータ フローを示す概略図です。






重要なリソース: クライアントとサーバー

間のネットワーク帯域幅フェーズ5。Avamar ServerまたはData Domain

に書き込まれたデータバックアップ データは、Avamar ServerまたはData Domainシステムに書き込む必要があります。

重要なリソース: Avamar Serverのディスク ライト パフォーマンスと一般的なロード。