Avamar：容量管理の概念とトレーニング

Data Domainに関連する容量管理の課題については、『Avamar and Data Domain System Integration Guide』の「Reclaiming storage on a full Data Domain system」セクションを参照してください。お使いの操作環境に関連するガイドは、「Dellサポート サイトでAvamarのマニュアルを見つける方法」を参照してください。

この記事の目的：
 

• /data*パーティションに格納されているデータのタイプを要約する。
• 「オペレーティング システム容量」の概念を説明し、これを「ユーザー容量」（「GSAN容量」とも呼ばれる）の概念と比較する。
• Avamarをユーザー容量の制限近くまで実行すべきではない理由を説明する。
• チェックポイントのオーバーヘッドを引き起こす要因を挙げる。
• データ パーティションの使用率をモニターする方法を説明する。
• オペレーティング システム容量が制御不能になった場合に発生する症状を説明する。
• 「 MSG_ERR_DISKFULL 」メッセージの一般的な原因を列挙する。
• オペレーティング システム容量が大きく、通常のシステム運用に影響する場合に使用されるリカバリー方法の概要を説明する。
• ユーザー容量がユーザー容量制限を超過した場合に発生する症状を説明する。
• ユーザー容量が高い状況からのリカバリー方法について説明する。

この記事では、読者が『Avamar Operational Best Practices Guide』の「Managing Capacity」セクションを理解していることを前提としています。

お使いの操作環境に関連するガイドは、「Dellサポート サイトでAvamarのマニュアルを見つける方法」を参照してください。

「オペレーティング システム容量」が大きすぎる場合に影響する、あるいはその症状として発生する一般的な問題は次のとおりです。

• チェックポイントの検証(hfscheck)が失敗した。
• ガベージ コレクションの実行に失敗し、
• チェックポイントの作成に失敗した。

「ユーザー容量」が大きすぎる場合と密接に関連する共通の症状は次のとおりです。

• バックアップに失敗した。
• 受信レプリケーション ジョブが失敗する。
• 管理者インターフェイスでは、バックアップ ウィンドウ中にシステムが「Admin」モードで表示される。

「解決方法」セクションを参照してください。

Avamarグリッドにはどのようにしてデータが格納されていますか？

Avamar容量管理では、すべてのAvamarデータ ノードの/data*パーティションに格納されているデータが考慮されます。次のようなデータで構成されます。

• 重複排除バックアップ データ
• RAINパリティー データ
• チェックポイントのオーバーヘッド データ

RAINパリティーとチェックポイント データはどちらも、RAIDとレプリケーションに加えてAvamarで使用可能な冗長性のレイヤーです。

ガベージ コレクションや非同期のストライプ処理などのメンテナンス タスクを正しく実行するには、データ パーティションの空き領域も必要です。

次に、Avamarストレージ ノード上のデータ パーティション内で使用可能な物理ストレージ スペースをグラフィック表示します。

 

データ パーティションにはどのようにしてデータが格納されていますか？

前掲の図は、データ パーティションでスペースがどのように使用されているかを簡単に表しています。

左側の100%の値は、データ パーティション内のオペレーティング システムで使用可能な物理スペースの合計量として定義されています。

いずれかのデータ パーティションが合計領域の85%以上を消費している場合、ガベージ コレクションは実行できません。

100%ユーザー容量マーカー（読み取り専用制限）は、データ パーティション内の全容量の65%までが重複排除データの保存に使用可能であることを示しています。この100%のユーザー容量マーカーの下のスペースは、管理者UIに表示されるサーバー使用率の値に相当します。任意のノード上の任意のデータ パーティションに格納されている重複排除データの量が65%に達すると、Avamarシステムは読み取り専用になり、それ以降のバックアップ データは拒否されます。

Avamar Administrator UIから、ユーザーはバックアップによって消費された領域を確認できますが、オペレーティング システムのデータ パーティションで消費された領域は確認できないことが分かります。

 

「ユーザー容量」の制限近くまでAvamarシステムを実行してはいけない理由は何ですか？

高い「ユーザー容量」とチェックポイント オーバーヘッドの関係は、システムが上限に近付くにつれて、バックアップ データがわずかに増加しただけでもチェックポイント オーバーヘッドの大幅な増加につながるというものです。

このようなことが起こる理由の詳細については、この記事の範囲を超えていますが、覚えておくべき重要な点は次のとおりです。Avamarシステムのユーザー容量が100%に近づくと、チェックポイント オーバーヘッドで使用できるオペレーティング システム容量が少なくなります。

上の図に示すように、フル システムでは、チェックポイント オーバーヘッドは、データ パーティション内のオペレーティング システムの合計領域の20%に制限されます。

Avamarシステムを高いレベルの「ユーザー容量」で確実に実行するには、次の基準を満たしている必要があります。

• システムは、毎日変更されるデータを低率（1%以下）で保有している必要があります。
• 容量は安定した状態である必要があります（『Avamar Operational Best Practices Guide』の「Managing Capacity」セクションを参照）。お使いの操作環境に関連するガイドは、次の場所にあります。「Dellサポート サイトでAvamarのマニュアルを見つける方法」
• メンテナンス タスクは毎日正常に完了する必要があります。

これらのステートメントのいずれかがtrueからfalseに変化した場合、チェックポイント オーバーヘッドが徐々に、または急激に増加して、深刻な運用上の問題につながることが予想されます。

 

チェックポイント オーバーヘッドを引き起こす要因：

次の要因によって、チェックポイント オーバーヘッドが増加する可能性があります。

• ストライプの非同期処理（デフォルトでは有効）
• システムに格納されているチェックポイントの数
• チェックポイントの検証が毎日正常に完了していない
• Avamar Serverが再利用する場合の空のストライプの仕組み（サーバーの使用率が高くなると、より重大になります）
• 日次バックアップ変化率 <

システム管理者は、これらの要因に対して特定のレベルの制御を行うことができます。非同期処理の設定はサポート専用ですが、管理者は余分なチェックポイントを削除し、チェックポイントの障害を調査して、サーバー使用率と日次データ変化率の改善を図ることができます。

 

データ パーティションの使用率をモニターする方法

オペレーティング システムのデータ パーティションの使用率を正しくモニターする方法は、Avamar Utility Nodeから次のAvamarコマンドを使用することです。

例えば、

admin@utilitynode:~/>: avmaint nodelist | grep fs-percent
        fs-percent-full="7.8"
        fs-percent-full="6.3"
        fs-percent-full="6.4"
        fs-percent-full="6.4"
        fs-percent-full="7.6"
        fs-percent-full="6.2"
        fs-percent-full="6.1"
        fs-percent-full="6.6"
        fs-percent-full="7.8"
        fs-percent-full="6.4"
        fs-percent-full="6.5"
        fs-percent-full="6.8"

この出力には、オペレーティング システムの容量使用率の正確な状態が示されます。データ ノードがファイル プールを使用するグリッドでは、Linuxの df コマンドは意味がありません。これは、ストライプがファイル プールに事前に割り振られており、ストライプの多くが使用されていない可能性があるためです。

 

オペレーティング システム容量の使用率が制御不能になった場合はどうなりますか？

ユーザーの観点から見ると、データ パーティションの使用率が制御不能になったことに初めて気づくのは、使用率が85%を超えたときです。

ガベージ コレクションは実行できなくなり、「 MSG_ERR_DISKFULL 」というエラー メッセージで失敗します。

ここで多くの場合、誤解が生じます。ユーザーは多くの場合、メッセージ「 MSG_ERR_DISKFULL 」を、システムにバックアップ用の領域がなくなったという意味で解釈します。

しかし、この解釈は正しくありません。ユーザーは通常、Avamar Administrator UIでサーバー使用率の値を確認し、許容できる値（たとえば60%）を見つけます。

ユーザーは、Avamar UIのバックアップ管理インターフェイスからバックアップの削除を試みることができます。ユーザー容量レベルが高い場合でも、ガベージ コレクションを実行できず、期限切れのデータ チャンクをシステムから削除できないため、バックアップを削除しても状況は緩和されません。

オペレーティング システム容量が大きい問題とユーザー容量が大きい問題の両方が発生している場合は、最初に大容量オペレーティング システムの問題の解決に焦点を当てます。

オペレーティング システムの容量使用率が高い場合、システムでチェックポイントを作成するためのスペースが不足する場合があります。

 

MSG_ERR_DISKFULLメッセージが表示される原因とは

最も一般的な原因としては、チェックポイント オーバーヘッドが非常に高くなっていることが挙げられます。チェックポイント オーバーヘッド増加の一般的な原因は次のとおりです。

• チェックポイントの検証(hfscheck)が繰り返し失敗した。
• hfscheck障害には、考えられる根本原因が多数あります（突然のキャンセル、ソフトウェア障害など）。
• システムがフル稼働しすぎて、日次データ変化率が高くなっている。
• データ変化率を処理し、データを格納するために、システムにより多くのデータ ノードが必要である。
• 設定されたサイズよりも多くのデータやクライアントをバックアップするようにシステムが構成されている。
• 格納されているチェックポイントが多すぎる（Avamarはデフォルトでは2つのチェックポイントを格納し、そのどちらかが検証されています）。
• システム管理者が過剰なチェックポイントを作成した。
• メンテナンスが最近実行されたが、デフォルトのチェックポイントの保存は再開されなかった。

MSR_ERR_DISKFULLのシナリオを解決するには、次の記事を参照してください。「データ パーティション オペレーティング システムの容量 > 89%が原因で、Avamarのメンテナンス タスクが「MSG_ERR_DISKFULL」で失敗する」

 

オペレーティング システム容量が大きい問題を調査および緩和するための処置

1.最後のhfscheckがいつ終了したかを判断します。これを実行するには、Avamar AdministratorまたはAvamar Utility Nodeのコマンド ラインのいずれかを使用します。

• Avamar Administratorで、［Server］ > ［Checkpoint Management］タブに移動します。
• ［Checkpoint Validation］列に表示されている最新の日時を確認します。これは、過去24時間以内に発生しているはずです。

• Avamar Utility Nodeのコマンド ラインを使用して、コマンドcplistを実行します。

admin@utilitynode:~/>: cplist

cp.20110114111419 Fri Jan 14 11:14:19 2011   valid rol ---  nodes   3/3 stripes   1131
cp.20110114194457 Fri Jan 14 19:44:57 2011   valid --- ---  nodes   3/3 stripes   1131

 

2.HFScheckが実行されたか、失敗したかを確認します。

Last hfscheck: finished Sat Jan 15, 11:07:17 2011 after 06m 41s >> checked 528 of 528 stripes (OK)

admin@utilitynode:~/>: dpnctl status maint

Identity added: /home/admin/.ssh/dpnid (/home/admin/.ssh/admin_key)
dpnctl: INFO: Maintenance windows scheduler status: enabled.

• メンテナンスWindowsスケジューラーがダウン、無効化、または中断されている場合は、コマンド「dpnctl start maint」を使用して有効にします。
• 必要に応じて、新しいチェックポイントを取得してhfscheckを実行するか、次にスケジュールされたメンテナンス ウィンドウが完了するまで待ちます。

hfscheckが正常に完了すると（問題があれば対処するか、メンテナンス スケジューラーを再起動した後）、最も古いチェックポイントが「ロールオフ」され、オペレーティング システムの容量が大幅に削減されます。

• オペレーティング システム容量がそれでも大きすぎて、ガベージ コレクションがMSG_ERR_DISKFULLメッセージで失敗し続ける場合は、Dellテクニカル サポート チームの支援を受けてください。
• それ以外で、オペレーティング システム容量がガベージ コレクションを完了させるのに十分低い場合は、「ユーザー容量」を削減し、「サーバー使用率」の値を低くします。

 

 

大きいユーザー容量を軽減する処理

オペレーティング システム容量とは異なり、ユーザー容量レベルは、Avamarシステム管理者によってより簡単に、直接的に影響を受けます。

1.ガベージ コレクションを毎日実行し、バックアップによって中断されないようにする。

ガベージ コレクションが定期的または確実に実行されないと、適切なサイズのシステムでもすぐにユーザー容量が大きくなるため、これは最も重要なポイントです。

前述のように、メンテナンス ウィンドウが有効になっていることを確認し、capacity.shスクリプトとsched.shスクリプトを使用して、ガベージ コレクションが実行されていること、およびデータが削除されていることを確認します。

Avamar v7.xより前のバージョンでは、ガベージ コレクションの「制限」期間中はバックアップを実行できませんでした。

Avamar v7.xで導入されたハッシュ参照ビットマップ機能を使用すると、ガベージ コレクションのメンテナンス アクティビティー中にバックアップを実行できます。この機能では、これらの「マップ」がリセットできるように、バックアップが実行されない「静かな」時間が1日あたり少なくとも5分間必要です。

この機能に関するコンテンツには、次の記事へのリンクからアクセスできます。「Avamar v7以降 : データの使用中に「ハッシュ参照ビット マップ」が原因でクリーンアップできない「スキップハッシュ」を報告するガベージ コレクション」」

2.グリッドへの新しいクライアントの追加を停止する。
 

Avamarグリッドが容量に近づいたら、状況の悪化を防ぐために、新しいクライアントの追加を直ちに停止する必要があります。

サーバー使用率の低いレベルで実行されている別のAvamarグリッドがある場合は、満杯になりつつあるサーバーではなく、そのグリッドに新しいクライアントを追加することを検討してください。


3.ストレージ スペースを特に多く使用しているクライアントを確認する。

容量の問題に対処するには、どのクライアントが最も多くのデータをAvamarシステムに追加しているかを特定する必要があります。

capacity.shスクリプト（Avamar Utility Nodeのコマンド ラインから実行）を使用して、変更率が最も高いクライアントを特定することもできます。

Dellの登録ユーザーは、次の記事へのリンクからコンテンツにアクセスできます。capacity.shスクリプトの使用方法の詳細については、「Avamar：capacity.sh スクリプトを使用して容量を管理する方法」を参照してください。

多くの場合、「最も負荷の高い」クライアントは、SQLデータベースまたはEメール サーバーをバックアップするクライアントであるため、これらに特に注意してください。

変化率の高いクライアントを特定したら、保存ポリシーを見直して、ストレージ要件を許容可能なレベルに引き下げられるかどうかを確認します。

別のAvamarシステムが使用可能な場合は、Avamar Client Managerインターフェイスを使用して、変化率の大きい、または変化率の高いクライアントを、使用率の高いシステムからより低いシステムに移行する可能性を検討してください。

ユーザー容量レベルが重大(>90%)である場合は、バックアップ管理インターフェイスを使用するか、またはmodify-snapupsツールを使用して古いバックアップを期限切れにする必要があります。

Dellユーザーは、次の記事へのリンクからコンテンツにアクセスできます。「Avamar Capacity Management：「modify-snapups」ツールを使用してバックアップを一括で削除または期限切れにする方法」

バックアップを削除しても、サーバーの使用率レベルがすぐに低下することはありません。バックアップ削除の効果は、ガベージ コレクションの次回の実行時にデータの削除を開始できるようになることです。古いバックアップを削除することは、短期的な回避策です。バックアップは、今後数日間のうちに置き換えられます。バックアップが削除された場合は、保存ポリシーの調整も行う必要があります。

バックアップが削除され、保存ポリシーが変更された後、capacity.shスクリプトを使用して、システム上のデータ変更の量を厳密にモニターします。モニターを始めると、「削除された」データの値が増加して、「正味の変化」の値が負になっていくはずです。最終的には、超過したデータがシステムからクリアされると、「削除された」値が通常のレベルに戻り始めます。「削除済み」の値を引き続き監視します。

正味変化の値が負にならない場合は、ガベージ コレクション ログを確認して、ガベージ コレクションの実行時間と、メンテナンス期間中にガベージ コレクションが達成している作業量を確認します。

Dellユーザーは、次の記事へのリンクからコンテンツにアクセスできます。capacity.shスクリプトの使用方法の詳細については、「Avamar：capacity.sh スクリプトを使用して容量を管理する方法」を参照してください。

多くの場合、Avamarシステムで使用率が高くなる原因は、自然かつ想定内のデータの増加です。本番バックアップを続行するには、より多くのスペースを使用可能にする必要があります。

その方法は、Avamarシステムのタイプによって異なります。

• シングル ノード システムおよびAvamar Virtual Edition（AVE）システム

これらを拡張することはできません。2番目の大規模なAvamarシステムを発注するとともに、Dell Professional Servicesに対して、小規模システムから大規模システムへのシステム移行の実行を要求します。プロフェッショナル サービスには、Dellアカウント マネージャーを介して連絡を取ることができます。

新しいシステムは、ソースよりも多くのストレージ スペースを提供している場合、シングル ノード、AVE、マルチノード システムのいずれかになる可能性があります。

• マルチノード システム

これらのシステムは、最大16個のデータ ノードまで拡張可能です。詳細については、Dellアカウント マネージャーにお問い合わせください。通常のサポート チャネルではノードの追加は実行されないため、この作業をリクエストするためにサービス リクエストを開かないでください。

• Data Domainの統合

Data Domainシステムをバックエンド ストレージ デバイスとして統合することは、Avamarへのバックアップを行うクライアントが使用可能な容量を拡張するための便利な方法です。Dellアカウント マネージャーと、オプションについて話し合います。

便利なツール

• status.dpn
• capacity.sh
• Avalanche
• DPNの概要レポート
• replcnt.sh
• Avamar Client Manager

ベスト プラクティス：

• Avamar Serverの使用率（ユーザー容量）の値が80%を超えないようにしてください。
• ユーザー容量を削減することで、追加されたデータ量の予期しない変更に対する耐障害性を提供し、予期しないエラーやメンテナンス タスクに関する短期的な問題が発生した場合に、システムが使用不能になることを防止できます。
• 80%を超えるユーザー容量を実行しているAvamarシステムでは、メンテナンス タスクが正常に完了し、システムが読み取り専用にならないようにするために、システム管理者による入念なモニタリングが必要です。