Avamar：レプリケーション ペアに異なる容量使用率が表示される場合に原因を調査する方法

Summary: この記事では、Avamarレプリケート ペアで異なるレベルの容量使用率が表示される問題について、考えられる原因とその調査方法について説明します。

Ez a cikk a következő(k)re vonatkozik: Ez a cikk nem vonatkozik a következő(k)re: Ez a cikk nem kapcsolódik egyetlen konkrét termékhez sem. Ez a cikk nem azonosítja az összes termékverziót.
További források megtekintése

Symptoms

この記事では、2つのAvamarシステム（ソースとターゲット）がレプリケート ペアとして構成されているシナリオについて説明します。両方のAvamar Serverが同じバックアップを格納しているはずなのに、一方のグリッドで他方のグリッドよりも容量使用率が著しく高くなります。

続行する前に、次の点について理解してください。
 
1.Avamarソースは、選択したデータをターゲット システムに毎日非同期でレプリケートします。 
 
レプリケーションが毎日完了すると、ソース システム上のデータは、ターゲット システムに格納されているデータより1日遅れたままになります。 


2.毎日のデータ変更により、ソースとターゲットの容量値に数パーセントの差が生じる場合があります。この差が5%を下回っている場合、問題とはみなされません。レプリケーション ペアで高容量を管理する場合は、この点を考慮してください。
 

3.レプリケーションは付加的です。システム間の同期は一切実行されません。ソースとターゲットの両方に同じ情報を格納することは意図されていません。これらは完全に独立したシステムです。

Cause

「サーバー使用率」値の違いの原因と考えられる理由：
 
グリッド間の論理的または物理的な違い：
  • ソース グリッドとターゲット グリッドでデータ ノードの数が異なります。
  • 各グリッドのデータ ノードのディスク構成が異なります。
  • 各システム内のデータ ノード間でストライプが適切にバランスよく分散されています（2%以内）。
  • ストレージとパリティーの要件は、Avamarのバージョンによって異なります。ソース ソフトウェアとターゲット ソフトウェアのバージョンが異なる場合、使用率に違いが生じることがあります。
  • Avamar Serverのディスク読み取り専用レベルが、2つのグリッド間で異なる可能性があります。   
  • 一方のグリッドでRAINパリティーが設定されていても、もう一方では設定されていない可能性があります。

レプリケーション構成：
  • ターゲット システムにレプリケートされたバックアップは、ソースとは異なる保存ポリシーを持つ場合があります。詳細については、expiredeltaフラグを確認してください。または、レプリケートされたバックアップが特定のタイムスパンのみをカバーする場合もあります。例えば、ソースからの過去4週間のバックアップなどです。
  • レプリケーションが、クライアントのサブセットのみをソース システムからターゲット システムにレプリケートするように構成されている可能性があります。「包含」設定または「除外」設定が使用されているかどうかを確認します。
  • クライアントとそれに関連付けられたバックアップがソース システムから削除されている可能性があります。ソース上のクライアントまたはバックアップを削除しても、ターゲット システムから同じバックアップが削除されることはありません。バックアップは、保存設定に従って有効期限が切れるまでターゲット上に残ります。
  • ソース システム上のバックアップまたはクライアントに対する保存ポリシーは変更できます。保存ポリシーの変更は、新しいバックアップにのみ影響します。新しいバックアップはターゲットにレプリケートされ、更新された保存ポリシーに従います。ターゲット上にすでに存在するバックアップは、レプリケートされたときに適用された保存ポリシーを保持します。

以前の容量管理アクティビティー：
  • お客様がいずれかのAvamarレプリケーション ペア システムが容量に近づいていることに気付き、容量を削減する措置を取ることは珍しくありません。Avamarレプリケーション ペアは、個別に管理される2つのシステムで構成されています。一方のシステムでアクションを実行する場合は、もう一方のシステムでも実行する必要があります。 
  • ソース システムでバックアップが削除されたり、保存期間が短縮されたりした場合は、ターゲットでも同じ変更を行う必要があります。この方法で最適に容量を管理するには、modify-snapupsスクリプトを使用することをお勧めします。これは、同じバックアップの変更または削除オプションを使用して、両方のAvamar Serverで実行できます。  

異なるストライプ構造（例えば、1つのシステムに複数のパリティー ストライプがある場合）：
  • 2つのAvamarシステムは独立しているため、ストライプ構造が異なる可能性があります。マルチノード システムでは、データを保護するためにパリティー ストライプを使用しているため、違いが生じる場合があります。容量履歴に応じて、2つのマルチノード システムには同じバックアップが含まれていますが、一方のパリティー ストライプの数がもう一方のシステムよりも多くなる可能性があります。
  • 通常のストライプと同様に、パリティー ストライプは一度作成されると、常にシステムに残ります。通常のストライプとは異なり、Avamar Server内の一定量の領域を常に消費します。これは、パリティー グループのセーフ ストライプにデータが含まれていない場合でも消費します。ガベージ コレクションは、この動作には影響しません。
  • レプリケーション ターゲット システムは、レプリケーション ソースの主要な容量の問題から間接的に保護されます。ただし、容量の観点から一方の管理が不十分な場合は、どちらのマシンでもこの状況が発生する可能性があります。
  • 関連記事: 「すべてのバックアップが削除され、ガベージ コレクションが行われた後でも、Avamarは最大～30%の使用率を示す」

MC_DELETEDでのバックアップ保持：
  • 注意すべきシナリオとして、ソースでクライアントが削除されても、そのバックアップが保持されることがまれにあります。これにより、バックアップが自然に期限切れになるターゲットよりも、ソースの使用率が高くなる可能性があります。backupcompareオプションを指定してdump_root_hashes.rbスクリプトを使用すると、このシナリオを確認するのに役立ちます。

レプリケートされていないバックアップからのターゲット システム上のデータ：
  • システムが「一方向のみで」レプリケートする場合は、/REPLICATEとMC_SYSTEMの外部にクライアントが存在しないことをターゲットで確認します。
このようなデータが存在する場合は、容量の使用量に違いが生じることが予想されます。

 

その他の動作：
  • レプリケーション ジョブが確実に完了していない場合があります。ターゲットに送信されるデータは、ソースより数日「遅れる」可能性があります。
  • どちらのシステムにも同じ量の重複排除データが含まれていますが、それぞれのパリティー オーバーヘッドの量は異なります。これは、次のシナリオで発生します。 
    • Avamarソース システムの容量が上限に近付く。 
    • その容量レベルを下げるために、多くのバックアップがソース システムから削除される。 
    • その後、重複排除されたデータのレプリケーションがソースからターゲットに対して実行される。 
    • 重複排除されたデータの量は、両方のシステムで同じ。
    • ソース システムは、最初にターゲットよりも多くのパリティー オーバーヘッドを格納する。
  • レプリケーションでは、ソースからターゲット グリッドに物理ストライプはコピーされません。代わりに、ターゲット グリッドは、データのストリップとチャンクが格納される場所を自身で決定できます。
  • ターゲットAvamarシステムでは、データが最初にバックアップされたソース グリッドよりも効率的にデータを保存できる場合があります。

Resolution

このセクションでは、収集するべき情報と、この情報を解釈して容量差の原因を特定する方法について説明します。 
 
レプリケーション環境について理解します。
  • ソースAvamarグリッドの完全なホスト名をメモします。
  • 該当するシステムのレプリケーション構成を調べて、どのシステムがどのデータをどこにレプリケートするかを把握します。 
    • あるAvamar Serverから別のAvamar Serverへのレプリケーションよりも環境が複雑な場合は、概略図を描画すると役立つ場合があります。
  • ソースがData Domain (DD)と統合されている場合は、お客様の懸念事項がDDデバイス間でレプリケートされたバックアップに関連しているかどうかを確認します。
  • ターゲットAvamarグリッドの完全なホスト名と、レプリケートされたバックアップを受信する、関連づけられているDDデバイスをすべてメモしておきます。

グリッドの全体的な正常性と状況を確認する：
  • 両方のグリッドでproactive checkスクリプトを実行し、hc_results.txtのコピーを取得して確認し、システムの全体的な状況を把握します。 
スクリプトのダウンロードと実行の詳細については、制限付きメモの「ヘルス チェック スクリプト」セクションを参照してください。

容量の差よりも深刻な問題が存在する場合は、最初に対処する必要があります。

容量差の深刻度：
  • お客様は、ソースとターゲットの間で容量消費量に差があると思われる内容を示すスクリーンショットを提供する必要があります。
  • 容量の差が5%未満の場合、問題とは見なされません。
  • Avamar Administrator UIを確認して、Avamar Serverの容量のレベルと（Data Domainが統合されている場合の）メタデータ容量のレベルを確認します。
  • UI容量表示の仕組みに注意してください（「Avamar 7.2以降のAvamar UIダッシュボードにAvamar使用率ではなくメタデータ使用率が表示される」で取り上げられています）。
  • 両方のシステムで次のコマンドを実行します。サーバー使用率の値は、Avamar Server（Data Domainは除く）の容量レベルの全体的な値を示します。
admin@utility:~/>: mccli server show-prop | grep "utilization"

Server utilization               3.7%

両方のグリッドでハードウェアが同じであるか確認する：
  • 「類似」システムの容量の違いを比較するのは理にかなっています。 
  • 「proactive check」の出力を使用して、システムに存在するノードのタイプをメモします。
  • 次のコマンドを実行すると、物理ノードの全体的な数、サイズ、領域消費量が表示されます。
admin@utility:~/>: mccli server show-prop | grep "Capacity\|capacity\|nodes"

Total capacity                   23.3 TB
Capacity used                    858.5 GB
Number of nodes                  3
  • この出力により、システム内のノードの数とサイズを簡単に確認できます。ここでは、（23.3 / 3 = ～7.8 TB）です。 
  • 各ノード上のハード ドライブ パーティションの数とサイズがこれを裏付ける必要があります。
例：
  
admin@utility:~/>: mapall 'df -h' | grep data

(0.0) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.2 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   54G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   53G  1.8T   3% /data04
/dev/sde1       1.9T   52G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
(0.1) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.3 'df -h'
/dev/sda3       1.8T   56G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   52G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   53G  1.8T   3% /data06
(0.2) ssh -q  -x  -o GSSAPIAuthentication=no admin@192.168.255.4 'df -h'
/dev/sda3       1.8T   55G  1.8T   4% /data01
/dev/sdb1       1.9T   53G  1.8T   3% /data02
/dev/sdc1       1.9T   53G  1.8T   3% /data03
/dev/sdd1       1.9T   52G  1.8T   3% /data04
/dev/sde1       1.9T   53G  1.8T   3% /data05
/dev/sdf1       1.9T   52G  1.8T   3% /data06
  • この情報を使用して、次の点を確認します。
a. 両方のシステムに同じ数のノードが含まれているか。   
b. 各ノードのデータ パーティションの数は同じか。
c.すべてのデータ パーティションは同じサイズか
d.すべてのデータ パーティションのサイズは同じか。
 
前述の出力は、システムに3つのノードがあり、各ノードに6つのデータ パーティションがあり、各パーティションのサイズが2 TB弱であることを示しています。    


ソフトウェアのバージョンと設定を確認する：
  • status.dpnコマンドの出力を使用して、各システムで実行されているAvamarのバージョンを比較します。
  • マルチノード システムの場合は、「Avamar - サーバーがRAINか非RAINかを判断する方法」に従って、両方ともRAINパリティーを使用して構成されていることを確認します。
  • 2つのシステムの容量に関連するAvamar Server構成パラメーターを確認して比較します。例：
admin@utility:~/>: avmaint config --ava | grep -i "capacity\|disk"

  disknocreate="90"
  disknocp="96"
  disknogc="85"
  disknoflush="94"
  diskwarning="50"
  diskreadonly="65"
  disknormaldelta="2"
  freespaceunbalancedisk0="20"
  diskfull="30"
  diskfulldelta="5"
  balancelocaldisks="false"
 
ストライプ バランシングを確認する：
  • status.dpnの出力を確認し、各データ ノード上のストライプの合計数をメモします。ストライプの数は括弧内で確認できます（例：onl:xxx）。 
  • 各データ ノード上のストライプの合計数の差は2%未満である必要があります。  

両方のシステムでガベージ コレクションが適切に実行されていることを確認します。
  • ガベージ コレクションが一貫して効果的に実行されていない場合、期限切れのデータは削除されません。システムで、予想よりも高い容量使用率が報告されます。 
    • 詳細については、制限付きメモの「GC解決パス」の記事を参照してください。  

レプリケーションが正常に完了していることを確認します。
  • ソースからターゲットへのすべてのレプリケーション タスクが正常に完了していることを確認します。これが完了していない場合は、ソースからターゲットにレプリケートされるデータが残っている可能性があります。  

レプリケーション構成の確認：
  • レプリケーション構成（UI、CLI、またはログ）で次のいずれかのフラグを確認します。  
--before
--after
--include
--exclude
これらのフラグがある場合は、ソース上のすべてのバックアップがターゲットに送信されるわけではないことを示しています。
  
--expiredelta
このフラグがある場合は、異なる有効期限でバックアップがターゲットに送信されることを示しています。したがって、ソースとターゲットで同じ容量は期待できません。  
  
--retention-types
いずれかの保存タイプが欠落している場合、特定のバックアップがレプリケートされない場合があります。すべての保存タイプが指定されていることを確認します。例： 
--retention-types=none,daily,weekly,monthly,yearly
 
両方のシステムの取得率とデータ削除率を確認します。
  • 両方のシステムで「proactive_check.pl --capacity」を実行し、ソース システムとターゲット システムの両方の取得レートを比較します。
  • ターゲットが純粋なターゲット システムであり、ソースからすべてのバックアップを受信する場合、その取得レートはソースの取得レートに厳密に従う必要があります。
  • Avamarの新規またはDDRの新規の列には、これらのシステムに追加される新しいデータの量が表示されます。
  • また、「removed」、「mins」、および「pass」の列に細心の注意を払って、両方のシステムでのガベージ コレクションの動作を理解してください。
  • この情報により、両方のシステムで何が起こっているかを明確に把握できます。
  • 出力の解釈の詳細については、「Avamar：capacity.shスクリプトを使用して容量を管理する方法」を参照してください。  

各システムに存在するバックアップのリストをダンプします。
  • dump_root_hashes.rbスクリプトは、Avamarソース システムとターゲット システム間で保存されているバックアップの違いを比較するのに役立つユーティリティーです。これは、バックアップがData Domainストレージでホストされている場合でも同様です。   
  • ユーティリティーのダウンロードと使用例（2つのAvamarシステムのコンテンツの比較など）については「Avamar：dump_root_hashes.rbスクリプトを使用してクライアントとバックアップのリストを生成する方法」を参照してください。
    • ツールを実行します。すべてのクライアントでバックアップの数に不整合がないか確認します。+/-2の違いに注意してください。  
  • 「原因」セクションで説明したように、容量管理が非対称であると、2つのシステム間に違いが生じます。出力を確認して、これが該当する可能性があるかどうかを判断します。
  • また：
    • ターゲット システム上のレプリケートされていないバックアップからのデータを確認します。
    • ターゲットにレプリケートされなかったデータのソースを確認します。  

異なるストライプ構造を確認する（例えば、1つのシステムに複数のパリティー ストライプがあるなど）：
  • 2つのAvamarシステムは独立しているため、異なるストライプ構造を持つ場合があります。マルチノード システムでは、データを保護するためにパリティー ストライプを使用しているため、違いが生じる場合があります。容量履歴に応じて、2つのマルチノード システムには同じバックアップが含まれていますが、一方のパリティー ストライプの数がもう一方のシステムよりも多くなる可能性があります。  
  • 通常のストライプと同様に、パリティー ストライプは一度作成されるとシステム上に残ります。通常のストライプとは異なり、パリティー グループのセーフ ストライプにデータが含まれていない場合でも、Avamar内で常に一定量の領域を消費します。ガベージ コレクションは、この動作には影響しません。
  • レプリケーション ターゲット システムは、レプリケーション ソースの主要な容量の問題から間接的に保護されます。ただし、容量の観点から一方の管理が不十分な場合は、どちらのマシンでもこの状況が発生する可能性があります。
  • 関連記事:  「すべてのバックアップが削除され、ガベージ コレクションが行われた後でも、Avamarは最大～30%の使用率を示す」  

MC_DELETEDでのバックアップ保持：
  • 注意すべきシナリオとして、ソースでクライアントが削除されても、そのバックアップが保持されることがまれにあります。これにより、バックアップが自然に期限切れになるはずのターゲットよりも、ソースの使用率が高くなります。backupcompareオプションを指定してdump_root_hashes.rbスクリプトを使用すると、このシナリオを確認するのに役立ちます。

Additional Information

クロス レプリケーション：
  • この記事は、AvamarソースがAvamarターゲットにバックアップを送信する一方向レプリケーションに特化して記述されています。
  • Avamarシステムがソースとターゲットの両方として機能し、ペア内でデータを送受信することは珍しくありません。これは「クロス レプリケーション」と呼ばれます。 
  • クロス レプリケーション環境で容量の違いを調査することは、両方のシステムがすべてのバックアップをパートナーにレプリケートするように構成されている場合にのみ有効です。 
    • このようなレプリケーション ペアに関する情報を収集するコマンドを実行する場合は、すべてのコマンドを両方のシステムで実行する必要があります。 
  • また、2つの同じサイズのレプリケーション ペアで容量が一致する場合でも、両方のグリッドにまったく同じバックアップが格納されるわけではないことも理解しておいてください。
  • ソースAvamarは、別のAvamarからのレプリケーション データのターゲットになっている場合があります。あるいは、ターゲット グリッドが複数のAvamarソースのターゲットになっている場合もあります。

Érintett termékek

Avamar

Termékek

Avamar
Termék tulajdonságai
Article Number: 000031740
Article Type: Solution
Utoljára módosítva: 12 dec. 2025
Version:  13
Választ kaphat kérdéseire más Dell-felhasználóktól
Támogatási szolgáltatások
Ellenőrizze, hogy a készüléke rendelkezik-e támogatási szolgáltatással.