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

「サーバー使用率」値の違いの原因と考えられる理由：

グリッド間の論理的または物理的な違い：

• ソース グリッドとターゲット グリッドでデータ ノードの数が異なります。
• 各グリッドのデータ ノードのディスク構成が異なります。
• 各システム内のデータ ノード間でストライプが適切にバランスよく分散されています（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システムでは、データが最初にバックアップされたソース グリッドよりも効率的にデータを保存できる場合があります。

レプリケーション環境について理解します。

• ソース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

• この情報を使用して、次の点を確認します。

ソフトウェアのバージョンと設定を確認する：

• 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スクリプトを使用すると、このシナリオを確認するのに役立ちます。