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

Data Domainに関連する容量管理の課題については、『Avamar and Data Domain System Integration Guide』の「Reclaiming storage on a full Data Domain system」セクションを参照してください。

お使いの操作環境に関連するガイドは、次の場所にあります。「Dellサポート サイトでAvamarのマニュアルを見つける方法」

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

この記事では、読者がAvamar運用のベスト プラクティス ガイドの「容量の管理」セクションに精通していることを前提としています。

繰り返しになりますが、お使いの操作環境に関連するガイドは、次の場所にあります。Dellサポート サイトでAvamarドキュメントを見つける方法

高いOS容量に影響する、または高いOS容量の症状を示す一般的な問題は次のとおりです。

• チェックポイントの検証 (hfscheck)が失敗しています。
• ガベージ コレクションの実行に失敗し、レポートが報告される MSG_ERR_DISKFULLの詳細を確認してください。
• チェックポイントの作成に失敗した。

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

この記事では、Avamar容量管理の概念とトレーニングについて説明します。

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

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

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

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

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

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

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

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

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

• 100%ユーザー容量マーカー(読み取り専用制限)は、重複排除データのストレージにデータパーティション内の合計領域の最大65%が使用可能であることを示します。
• この100%のユーザー容量マーカーの下のスペースは、管理者UIに表示されるサーバー使用率の値に相当します。

任意のノード上の任意のデータパーティションに格納されている重複排除データの量が65%に達すると、Avamarは読み取り専用になり、それ以降のバックアップ データを拒否します。

上記に基づいて、Avamar Administrator UIからは、バックアップによって消費された領域は表示されますが、オペレーティング システムのデータ パーティションで消費されている領域は表示されません。

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

高い「ユーザー容量」とチェックポイント オーバーヘッドの関係には、システムがフル容量に近づくにつれて、バックアップ データのわずかな増加でもチェックポイント オーバーヘッドの大幅な増加につながってくるという特徴があります。

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

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

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

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

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

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

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

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

OSデータパーティションの使用率を監視する正しい方法は、Avamar ユーティリティノードから次の Avamar コマンドを使用することです。

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 コマンドは意味がありません。これは、ストライプがファイル プールに事前に割り振られており、ストライプの多くが使用されていない可能性があるためです。

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

ユーザーの視点から見ると、データパーティションの使用率が制御不能であることを示す最初の兆候は、データパーティション使用率が 89% を超えたときに発生します。

ガベージコレクションを実行できなくなり、 MSG_ERR_DISKFULL エラー メッセージの解決法」を参照してください。

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

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

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

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

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

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

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

次の記事を参照して、 MSG_ERR_DISKFULL シナリオ：Avamar：1つ以上のデータ パーティションのオペレーティング システムの容量が89%を超えているため、メンテナンス タスクがMSG_ERR_DISKFULLで失敗します

オペレーティング システムの高容量を調査して軽減するためのアクション:

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

• Avamar Java管理者UIで、次の手順を実行します。
  • [Server > Checkpoint Management]タブに移動します。
  • ［Checkpoint Validation］列に表示されている最新の日時を確認します。これは、過去24時間以内に発生しているはずです。

--または--

• Avamarユーティリティー ノードのコマンド ラインを使用する場合:
  • 次のコマンドを実行します： 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

• • • • ここに表示されている検証済みチェックポイントのうち、最新のものは1月14日11:14です。
      • これは、「valid」マーカーの直後のフラグによって識別されます。
      • システムに設定されているチェックポイント検証のタイプに応じて、フラグは rol または hfsの詳細を確認してください。
      • これは、 rol (ローリング) hfscheckの詳細を確認してください。

最新の検証済みチェックポイントが24時間よりも古いことが結果に示されている場合は、その原因を確認します。これは、 HFScheck 実行されなかったか、失敗したため。

2.かどうかを確認します HFScheck 実行または失敗した場合:

Avamar ユーティリティノードで、 status.dpn コマンドを実行し、"Last hfscheck」。

例えば、

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

終了日時とステータス（上の行ではステータスは「OK」と表示）をメモしておきます。

「Fusion」 hfscheck ジョブが失敗しています。すぐに調査する必要があります。

「Fusion」 hfscheck 最近実行されていない場合は、次のコマンドを実行してメンテナンス スケジューラーが有効になっていることを確認します。dpnctl status maint" を Avamar ユーティリティノードで実行します。の詳細を確認してください。

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機能で導入されたハッシュ参照ビット マップ機能を使用すると、GCメンテナンス アクティビティ中にバックアップを実行できます。この機能では、これらの「マップ」には、リセットできるようにバックアップが実行されない「quiet」時間が1日あたり少なくとも5分間必要です。

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

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

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

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

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

容量の問題に対処するには、Avamarシステムへのデータ追加に最も多くの役割を担うクライアントを特定します。

「 capacity.sh スクリプト(Avamarユーティリティー ノードのコマンド ラインから実行)を使用して、変更率が最も高いクライアントを特定することもできます。

「Avamar: を使用して容量を管理する方法 capacity.sh script の使用方法の詳細については、 capacity.sh スクリプト。

多くの場合、「hungriest」クライアントはSQLデータベースまたはEメール サーバーをバックアップするものであり、特に注意を払う必要があります。

4.保存ポリシーを見直す。

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

システムが古いため、保存されている最長のバックアップの有効期限が切れ始めている場合は、保存ポリシーを減らした後、ガベージ コレクションによって毎日削除されるデータの量が増加すると予想されます。この傾向をモニタリングするには capacity.shの詳細を確認してください。

Avamarシステムがまだ、バックアップの期限切れ処理を開始できるほど古くない場合は、保存ポリシーを変更して、最も古いバックアップの期限切れ処理を開始できるようにする必要があります。

規制要件により保存ポリシーを減らすことができない場合は、Avamarシステムを拡張するか、使用頻度の低い別のAvamarにクライアントを移行することを検討してください。

5.代替Avamarシステムにクライアントを移行する

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

6.古いバックアップを削除する。

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

Dellユーザーは、記事 Avamar: 容量管理 - 「」を使用してバックアップを一括で削除または期限切れにする方法modify-snapups」ツール

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

7.次を使用したデータ変更の監視 capacity.shの詳細を確認してください。

バックアップが削除され、保存ポリシーが変更された後は、 capacity.sh スクリプト。「削除済み」データの値は増加し、「Net Change」の値は負になります。最終的には、超過したデータがシステムからクリアされると、「削除された」値が通常のレベルに戻り始めます。「削除された」値のモニターを続行します。

正味変更値が負にならない場合は、GCログをチェックして、ガベージ コレクションが実行されている時間と、メンテナンス ウィンドウ内で達成されている作業量を確認します。

「 Avamar: を使用して容量を管理する方法 capacity.sh script の使用方法の詳細については、 capacity.sh スクリプト。

8.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 Summary Report
• replcnt.sh
• Avamar Client Manager

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