EMC Avamar for Network-Attached Storage (NAS) Backups Using NDMP

Transcription

1 ホワイト ペーパー NDMP を使用した NAS( ネットワーク接続型ストレージ ) バックアップのための EMC Avamar Avamar NDMP アクセラレータのベスト プラクティスとパフォーマンスの概要 要約 このホワイト ペーパーでは パフォーマンス テストの結果 顧客シナリオ フィードバックに基づいて EMC Avamar NDMP アクセラレータの構成 サイジング 拡張管理 レポート作成のベスト プラクティスの概要を説明します バックアップとリストアの独自の効率的アプローチにより EMC Avamar は 高度に拡張された NAS 環境の保護を実現する業界最高レベルのソリューションの 1 つとなっています July 2011

2 Copyright 2011 EMC Corporation. All rights reserved. EMC Corporation は この資料に記載される情報が 発行日時点で正確であるとみなしています この情報は予告なく変更されることがあります この資料に記載される情報は 現状有姿 の条件で提供されています EMC Corporation は この資料に記載される情報に関する どのような内容についても表明保証条項を設けず 特に 商品性や特定の目的に対する適応性に対する黙示の保証はいたしません この資料に記載される いかなる EMC ソフトウェアの使用 複製 頒布も 当該ソフトウェア ライセンスが必要です 最新の EMC 製品名リストについては にある EMC Corporation の商標 を参照してください 他のすべての名称ならびに製品についての商標は それぞれの所有者の商標または登録商標です パーツ番号 h8235-j 2

3 目次エグゼクティブ サマリー... 4 対象読者... 4 NAS システム バックアップ ソリューション... 5 NAS システムに対する EMC Avamar NDMP アクセラレータの適合性... 6 NAS のサポート... 6 NDMP アクセラレータ... 7 構成の概要とベスト プラクティス... 7 複数のストリームの管理... 8 パフォーマンスの期待値 レベル 0 フル バックアップのテスト結果 レベル 1( 日次増分 ) バックアップのテスト結果 結果に基づく推定 パフォーマンスと重要な概念のまとめ 適切なサイジングに関するガイドライン サイジング例 この例のソリューション サイジングに関するその他の考慮事項 問題の原因 考えられる提案 キャパシティ プランニングと拡張管理 以前の結果を基にした 8 ストリームの場合の推定 構成の拡張 結論 関連資料 付録

4 エグゼクティブ サマリー NAS バックアップ / リカバリ用 EMC Avamar ソリューションは 革新的な Avamar NDMP アクセラレータを利用して 毎日の高速フル バックアップと 1 ステップのリカバリを実現します 業界の他のソリューションとは異なり Avamar ではリカバリ性に優れたエンタープライズ クラスのシステムに NAS バックアップ データを格納することで 保存期間の延長とシンプルな細分レベルでのリストアを可能にしています このホワイト ペーパーでは NDMP アクセラレータのアーキテクチャ プロセス パフォーマンスの期待値 予測される拡張 ベスト プラクティスのレポート作成 微調整の度合いの概要を説明します このホワイト ペーパーは Powerlink の Avamar NDMP Accelerator User Guide ( アクセス権が必要 ) を補完するものであり このドキュメントに代わるものではありません 対象読者 このホワイト ペーパーは NDMP アクセラレータをすでに導入しているか 近い将来導入を予定している経験豊富な Avamar 管理者を対象としています NDMP バックアップに関する詳しい説明や スケールアウトされたレガシー NAS のバックアップに関連する課題についてはここでは取り上げませんが これらの課題はこのホワイト ペーパーを読む前の基礎知識となります EMC Avamar は エンタープライズ NAS システムの爆発的な増大に対応する NAS システム バックアップの最新の革新的アプローチです このホワイト ペーパーでは EMC バックアップ / リカバリ システム (BRS) 統合ラボで新たに収集されたベスト プラクティスを示します また NDMP アクセラレータをすでに活用し このエンタープライズ NAS システム バックアップ ソリューションを各自のニーズに合わせてサイジング 構成 調整 管理 拡張している EMC の経験豊富なお客様から提供された経験的データとフィードバックも示します 4

5 NAS システム バックアップ ソリューション このホワイト ペーパーでは まず 特定の NAS 環境のバックアップに向けて EMC Avamar NDMP アクセラレータ固有の考慮事項について説明します また Avamar NDMP アクセラレータが 将来の拡張と NAS 環境に関連する拡張に対応する拡張性を備えた NAS バックアップ / リカバリの有効な技術的選択ソリューションであることを示します スループットとバックアップ ウィンドウの時間に関するサイジングの仮定を検証するために実施された具体的なラボ テストの結果も取り上げます 操作と継続的管理の容易性による最高のパフォーマンスを継続的に実現するために これらのパフォーマンス測定結果を使用して 関連する EMC Avamar System Administration Guide には記載されていない構成のベスト プラクティスについて説明します 最後に パフォーマンス キャパシティ プランニングと拡張管理について説明します 図 1 は NAS システムのバックアップ サービスを提供する一連の EMC Avamar NDMP アクセラレータの一般的な構成を示しています 図 1. NAS システムをバックアップする Avamar NDMP アクセラレータの構成 5

6 NAS システムに対する EMC Avamar NDMP アクセラレータの適合性 NAS バックアップ用に Avamar を導入する多くの一般的な理由については EMC Avamar for NAS Backups: An Overview and Business Case という概要的なホワイト ペーパーで取り上げています これらの項目についてここでは繰り返しませんが Avamar ソリューションの NDMP アクセラレータが NAS システムの拡張性に優れた高速バックアップ / リストアに最適であることをすでに理解している必要があります 導入に関するビジネス上の理由も重要ですが ここでは NAS 環境をバックアップするときに このソリューションが従来のテープ バックアップ スナップショットの保存 レプリケーションなどの方法よりも信頼性と拡張性がはるかに高いアプローチを提供する技術的な理由を説明します このホワイト ペーパーでは これらの技術的目標について重点的に説明します NAS のサポート EMC Avamar は NetApp DataOntap と EMC Celerra /VNX DART の 2 つのオペレーティング システムをサポートしています 最新情報については Powerlink の最新の相互運用性マトリックスを参照してください NAS システムは CPU メモリ I/O 接続 クラスタ構成がそれぞれ異なります iscsi ファイバ チャネル SAN FCoE NFS CIFS FTP HTTP などの多数のプロトコルをサポートするさまざまな構成があります これらの各種プロトコルから ファイル ベースとブロック ベースの両方のストレージを提供できます NetApp では 任意のプロトコルによって提供されるどちらのストレージ タイプ ( ブロックまたはファイル ) にも Avamar NDMP アクセラレータを使用できる点に注意してください ただし バックアップとリストアのファイル レベルの細分化は NAS またはファイル ベースのデータでのみ可能です LUN をバックアップおよびリストアするときには LUN 全体がキャプチャされます つまり NDMP を使用して LUN 内のファイルを特定することはできません LUN をバックアップする場合は LUN がプロビジョニングされている各クライアントに Avamar クライアント ソフトウェアをインストールすることをお勧めします EMC Celerra と EMC VNX では NDMP バックアップでサポートされるのは NFS および CIFS 経由で提供されるファイル ベースのデータだけです リストアのファイル レベルの細分化は完全にサポートされています NAS システムは構成とサイズがさまざまである可能性があるため 特定モデルの NAS システムとその関連する容量を前提としたバックアップのサイジングに関する明確な回答や確実な方法はありません 失敗のリスクを最小限に抑え 適切なサイジングを確実に行う最良の方法は さまざまな手段を使用し 場合によっては予備的なベースライン テストを実施して情報を収集することです 6

7 NDMP アクセラレータ 現在 Avamar NDMP アクセラレータのサイズは固定されています CPU とメモリをアプライアンス ユニットに追加することはできません ただし メモリ容量の少ない小規模のユーティリティ / アクセラレータ ノード (Gen3 では 4 GB Gen4 では 12 GB) を購入することは可能です このホワイト ペーパーでは 最大規模の NAS システムの重複除外とバックアップを迅速化することを目的とした大規模な NDMP アクセラレータ ユニットの機能だけを取り上げます これらのユニットには 多数の CPU コアと 36 GB のオンボード メモリ 複数のアカウント / クライアントをサポートする機能 4 つ以上の NDMP 同時ストリームが含まれます オンボード リソースは固定されているため 特定のソリューション用にアクセラレータの数だけを変更できます 今後 EMC は仮想マシン内に展開された仮想環境への NDMP アクセラレータの導入をサポートする予定です そのときに サイジングに関する追加の推奨事項も提供します EMC Avamar NDMP バックアップ ソリューションは 容量を問わず NDMP をサポートするほぼすべての EMC Celerra/VNX システムまたは NetApp FAS システムに適用できます 今日 すでに多くの大企業が EMC Avamar によってバックアップされている NAS システムで大容量を実現し 膨大なファイル数に対応しています ただし お客様の NAS システムに対する NDMP バックアップ プロセスのオーバーヘッド アクセラレータのスキャン速度 提供されるアプライアンスの接続を想定し 次のセクションに示す変数により 実現可能性とバックアップ ウィンドウの実現を特定できます 構成の概要とベスト プラクティス Avamar NDMP アクセラレータを使用した NDMP バックアップの構成については EMC Avamar Backups for NAS Devices に記載されています このドキュメントでは NDMP アクセラレータでアカウントまたは クライアント を作成する方法 管理インタフェースでアカウントまたはクライアントを確認する方法 ファイルシステム (EMC Celerra) またはボリューム (NetApp FAS) の NDMP データセットを作成する方法 Avamar の [Policy] インタフェースでデータセットをクライアント スケジュール 保存期間に関連づけて適切なグループに含める方法についてわかりやすく説明しています 基本構成以外に 複数の使用可能なストリームまたは アカウント 全体でのパフォーマンスのバランス調整 ファイル数の多いファイルシステム / ボリュームに関する考慮事項 PST ファイル VMDK ファイル データベースなどの特定のデータ タイプに関する考慮事項 経時的な拡張管理 高可用性などの他の要素も検討する必要があります 7

8 複数のストリームの管理 複数のストリームでファイルシステムのバランスを取るために Avamar バージョン 5 における構成ではストリームとファイルシステム間の関係が固定されていました そのため 使用可能な限られた数のストリームを使用するために 他のファイルシステムとバランスを取る必要がありました この関係は手動で構成されていました 従来のこの操作では 関係が 1 対 1 で固定されていたため NDMP アクセラレータで構成される アカウント という用語が使用可能な ストリーム とよく間違えられていました Avamar バージョン 6.0 では NDMP ストリームは Avamar データセットに定義された次に使用可能なファイルシステムに 定義済みの最大数まで動的に割り当てられます この最大数は Avamar のデータセット定義内の [Options] タブで定義されます NDMP アクセラレータで 1 つの アカウント を構成して登録すると ストリームが各ファイルシステムに動的に割り当てられます Celerra X-Blade(Data Mover) または NetApp FAS ファイラーによっては 最大 8 つのストリームを使用できます そのため Avamar 6.0 では アカウント と ストリーム の違いに特に注意する必要があります Avamar バージョン 6 におけるストリーム割り当てのこの新しい動的動作により ストリームとファイルシステム間の構成を手動で行う必要がなくなり ファイルシステム データセット グループ ポリシーの各定義間での 1 対 1 の関係も不要になります ファイルシステムをまとめて選択し 1 つのデータセットに含めることで 使用可能なストリーム間でバランスを取る必要のないシンプルな構成が可能となります ストリームは データセットに定義されている最大数までアルファベット順にファイルシステムに割り当てられます バックアップ対象として用意されているファイルシステムで 構成済みのすべてのアクティブ ストリームが利用されていることを想定して アクティブ ストリームの数に対応する avtar プロセスが NDMP アクセラレータで実行されます さらに 進行状況 avtar という別の avtar も表示されます この avtar は avndmp の 1 つのインスタンスに関連するすべてのジョブの進行状況に関する概要情報を提供します マルチストリーミングは単一のファイルシステムでは機能しないことを認識しておくことが重要です 1 つのavtarが 1 つのファイルシステムで動作するように ストリームとファイルシステムの関係は 1 対 1 で維持されますが 使用可能なストリームはNDMPアクセラレータによって特定された構成済みのデータセット / ファイルシステムに動的に割り当てられることが主な利点です これまでと同様に pcache.dat ファイルは 各ファイルシステムに関連づけられた /usr/local/avamar/var/<account name>/ ディレクトリに作成されます 特定のデータ タイプに関する追加情報については 適切なサイジングに関するガイドライン を参照してください 8

9 NAS システムが導入されたリモート オフィスがある環境では これらのオフィスに Avamar NDMP アクセラレータを導入することで 本社やデータセンターへのバックアップを容易に行うことができるようになります この構成により リモート オフィスでのデータの重複除外が可能になるため 別の場所にある Avamar ストレージ ノードまたは Avamar グリッドにバックアップを送信できます これは リモート オフィスのサーバにロードされたクライアントとまったく同様に機能します このようなソリューションを検討するには NAS システムに適用する場合を除き サーバ環境と同じサイジング作業を行う必要があります この作業では 次のような情報を収集します データ タイプ 容量 ファイル数 固有のデータ タイプ データベースの容量 リモート サイトで利用可能な帯域幅 これらのデータ ポイントを把握することにより NDMP アクセラレータを NAS システムの近く ( できれば同じサブネット上 ) に配置し 重複除外後の暗号化されたデータを WAN 経由で Avamar サーバに送信できます Avamar ストレージ ノード / グリッドとほぼ同じ方法で 可用性の高い NDMP アクセラレータを構成できます ネットワーク接続に失敗することはほとんどありませんが ローカル スイッチへの接続を冗長的に構成することもできます ADS サーバの各ノードの Linux ボンディング モードをモード 1( アクティブ バックアップ ) に設定できます この設定により eth0(gb 1 ポート ) として列挙されている NIC ポートがプライマリ接続として機能し eth2(gb 3 ポート ) として列挙されている NIC ポートがバックアップ接続として機能するようになります 詳細については Configuration of High-Availability ADS Network の Changes to Port Bonding Mode を参照してください このテクニカル ノートは EMC 従業員が社内で入手できます また NDMP アクセラレータは 優れた冗長性を実現するために ミラーリングされたデュアル ディスク ドライブ (RAID 1) で構成されます 冗長性を実現するもう 1 つの手段として 同じ NAS システムに対応する複数の アカウント で複数の NDMP アクセラレータを構成できます 次に例を示します 9

10 NDMP アクセラレータ アカウント 1 アカウント 2 A celerra213-to-avamar227-primary celerra210-to-avamar227-secondary B celerra210-to-avamar227-primary celerra213-to-avamar227-secondary これらのアカウントはすべて Avamar サーバ 227 に登録されます ただし グループ ポリシーで使用可能なアカウントを選択するときには *-primary アカウントだけを選択する必要があります 複数のアカウントを選択すると 同じファイルシステムの複数の冗長ジョブが実行されることになり アクセラレータ NAS システム Avamar グリッドに不必要な負担がかかります バックアップ データセットは バックアップ時に使用された対応するアカウントに関連づけられています たとえば 2 月 1 日から 2 月 28 日までのバックアップに celerra213-to-avamar227-primary アカウントが使用された場合 Avamar コンソールの [Restore] インタフェースでは バックアップされたファイルシステムのデータがこのアカウント名の下に表示されます また /usr/local/avamar/var/celerra213-to-avamar227-primary/ ディレクトリに バックアップされたファイルシステムのプレフィックスが付いた pcache(*.dat) ファイルが作成されます 2 月 28 日以降に celerra213-to-avamar227-secondary というもう 1 つのアカウントが使用された場合 同じアクセラレータで構成されたアカウントであるかどうかに関係なく 対応する /usr/local/avamar/var/celerra213-to-avamar227-secondary/ サブディレクトリに新しい pcache ファイル (*.dat) が作成されます 2 月 28 日以降の日付のバックアップ データは Avamar コンソールの [Restore] インタフェースの celerra213-to-avamar227-secondary アカウントの下に配置されます また アカウントを変更すると そのアカウントを使用した対象ファイルシステムのバックアップの履歴がないため 別のレベル 0 バックアップが開始されます レベル 0 バックアップを迅速化するには 以前のアカウントのサブディレクトリから新しいアカウントのサブディレクトリに *.dat ファイルをコピーします ファイルシステムのバックアップに使用するアカウントを変更すると副次的な影響もありますが 障害が発生した NDMP アクセラレータをタイムリーに交換できない場合に アカウントを変更して NAS システムのバックアップを再起動できます 10

11 バックアップのスケジュールを設定するときには Powerlink の EMC Avamar Operational Best Practices を参照してください ただし NAS システムのバックアップ固有の問題として 他のスナップショット ネイティブな重複除外 時間外のレプリケーション アクティビティへの干渉を認識し これを最小限に抑えるようにする必要があります これらの各プロセスは NAS システムに対するオーバーヘッドを発生させ バックアップに影響を及ぼします Avamar によるバックアップのスケジュールを設定する前に これらのアクティビティのスケジュール (NetApp) またはポリシー (EMC Celerra) を確認してください 最後に NAS システムがバックアップの NDMP リクエストを受け取ると ファイルシステムまたはボリュームのスナップショットが取得されます 特定のファイルシステムのスナップショットが複数存在する場合 そのバックアップ用に実行されるスナップショットでそれらのスナップショットはキャプチャされません バックアップ データを特定のスナップショットでキャプチャする必要がある場合は Avamar のデータセット構成でそのスナップショットのファイルシステム パスを明示的に定義する必要があります この場合 最初のレベル 0 バックアップと継続的なレベル 0 バックアップが必要となることに注意してください 明示的に定義されたスナップショット パスからのレベル 1( 増分 ) バックアップは実行されません SnapMirror-to-Tape (SM2T) など NetApp でスナップショットをバックアップするための他のツールを検討しても構いません キャパシティ プランニングと拡張管理 では 大規模な NAS システムや多数の NAS システムをバックアップするための Avamar ソリューションを設計する必要がある場合の考慮事項について説明します BRS ラボ テスト ( 以降のセクションで説明 ) とお客様のフィードバックから収集された経験的データに基づくベースライン テストの結果は このような環境を構成する際の基礎として使用されます まとめ : NDMP アクセラレータを最大限に利用し バックアップ時間を短縮するために 複数のストリームを活用します NAS システムがリモート オフィス / 支社 (ROBO) にある場合は NAS システムに対してローカルの NDMP アクセラレータを使用します 通常 NDMP アクセラレータを複数のネットワーク ポートに接続する必要はありませんが スイッチまたは NIC ポートが停止した場合に役立つ可能性があります 複数の NDMP アクセラレータで冗長アカウントを作成すると 個々のアクセラレータで問題が発生した場合に問題の解決に要する時間を削減できます Avamar バージョン 5 と 6 では ストリームとファイルシステム間の関係が変更されているため これに伴う構成の変更に注意してください 11

12 他のストレージ アレイ スナップショット 重複除外 レプリケーション アクティビティが NDMP/ ダンプ リクエストされたスナップショットの妨げにならない場合は 時間外のバックアップ アクティビティをスケジュールします パフォーマンスの期待値 NASシステムのバックアップのパフォーマンスはさまざまな方法で測定できます NDMPアクセラレータは Avamarシステムにデータを送信する前にアプライアンス内で重複除外を実行するため 論理的 ( 効率的 ) アプローチと物理的アプローチでスループットを測定できます 効率的なスループットとは NASシステムがあたかも毎回フル バックアップされているかのように いかに大量のデータが日常的にNASシステムから効率的にバックアップされているかを示します Avamarでは すべてのクライアントを同じ方法でバックアップします つまり バックアップはすべてフル バックアップです ただし Avamar では ネットワーク経由で Avamar サーバにデータを送信する前に クライアントでデータの重複除外を実行するため 実際にはごくわずかなデータしか送信されません また ( ハッシュ ID と複数階層のインデックスを使用して ) これらの一意のサブファイル データ セグメントが Avamar サーバに格納されるため 最初のレベル 0 ベースラインのデータが送信されたら それ以降は完全なフル バックアップを取得する必要はありません また 複数の増分バックアップから 統合 フル バックアップを再作成するために Avamar サーバで実行される後処理もありません Avamar が NAS システムをバックアップするための優れたソリューションとなっているのはこのためです 毎日の高速フル バックアップではレベル 1 ダンプだけを要求します そのため 生成されるネットワーク トラフィックはごくわずかであり NAS システムに対するリソースのオーバーヘッドが最小限に抑えられます パフォーマンスを評価するには バックアップが完了するまでの時間が非常に重要となります これを測定するために 標準的な Celerra システム上に測定対象となる一連のファイルシステムが存在するという想定で バックアップの速度と時間を確認するさまざまなテストが EMC ラボ環境で作成されました これらの結果は このホワイト ペーパーで後述するサイジング例の基礎として使用されます テスト環境の詳細は次のとおりです 2 台の Data Mover を搭載した Celerra NS-120 NAS システム 1 台 このテスト サイクルで調査対象となった Data Mover は 1 台のみ NS-120 Celerra システム上に 5 つのファイルシステムを配置 開始時の容量は合計 2.5 TB ファイル総数は 320 万個 ファイルシステムの合計サンプル サイズを 3.4 TB( 容量テスト用 ) 1,500 万個以上のファイル ( ファイル数のテスト用 ) に増大 12

13 Avamar 6.0 クライアントと NDMP ソフトウェアが構成された NDMP アクセラレータ 1 台 Avamar 6.0 がインストールされた Avamar ターゲット システム 1 台 まず ベースラインのレベル 0 バックアップ ( シーディング ) を完了しました このテストの前に Avamar ターゲット システム上に存在した既存のデータはそれほど多くはありませんでした そのため データの重複除外によって 本番環境で通常確認されるほどの大きな効果は見られませんでした ただし このテスト中に Avamar システムに送信されたデータの量がインフラストラクチャの閾値を超えることはなかったので 重複除外の効果がバックアップ時間にそれほど影響しなかったと考えられます その他の監視と測定基準 : ジョブの実行中に Avamar コンソール内で Activity Monitor インタフェースを使用 メモリとCPUの統計情報 (vmstatとiostat) をキャプチャし NDMPアクセラレータのavtarプロセスからの出力に日付 / 時刻のスタンプを付与してログに記録するLinuxスクリプトを実行 テストの完了後に Activity Monitor または DPN(Data Protection Network) の概要レポートからジョブ アクティビティの詳細をキャプチャ 簡潔に示すために これらの測定のすべての出力を以下の表にまとめます これらのテストは NAS システムと Avamar システムへの負荷がほとんどない制御されたラボ条件下で実施されたことに注意してください このように既存の負荷が軽いことから ここで示す結果には固有の偏差が含まれています レベル 0 フル バックアップのテスト結果 テストでは レベル 0( 最初のベースライン ) バックアップを常に 190 GB/ 時以下で実行しました ストレージ 1GB あたりのファイル数が相対的に多い場合は サイズの小さいファイルを使用し 1 時間あたり 350 万個の速度で実行しました たとえば お客様の NAS システムに 2,000 万個のファイルがあり ファイル サイズがそれぞれ 20 KB であるとします 消費される合計容量は少ないですが ( 最大 400 GB) このファイルシステムの最初のバックアップに要する時間は約 5.7 時間になります このように レベル 0 の所要時間を見積もる際のおおよその目安として レベル 0 バックアップの予想される総所要時間としては結果的に最長時間となるベースラインの基準 (190 GB/ 時または 350 万ファイル / 時 ) を使用します 5 つのファイルシステム ( 合計 2.37 TB 320 万ファイル ) で レベル 0 バックアップをテストしました ベースライン バックアップ時間 ( ストリームの数は関係なし ) は 最大 12.5 時間 ( 速度 :240,000 ファイル / 時 最大 190 GB/ 時 ) でした 13

14 アクセラレータの CPU 平均使用率は 40~70% でした メモリ平均使用量は最大 3 GB に過ぎず ピーク時でも 7 GB 強でした 信頼性を確保するために各テストを数回実行しました ターゲット システムは 3.4 TB の Gen4 ノードが 1 つ含まれた比較的容量の少ない Avamar バージョン 6 グリッドでした レベル 1( 日次増分 ) バックアップのテスト結果 レベル 1( 差分 / 増分 ) バックアップは 前述のように論理的 ( 効率的 ) な方法と物理的な方法の 2 とおりの方法で測定できます 1 ストリーム 2 ストリーム 4 ストリームを使用したテストを実施しました 2 ストリーム構成と 4 ストリーム構成で 変更率 0% の日次バックアップを数回実行しましたが 約 6 分しかかかりませんでした アクセラレータの CPU 平均使用率は 40~70% でした メモリ平均使用量は最大 3 GB に過ぎず ピーク時でも 7 GB 強でした ストリーム構成の異なる 変更テスト用の各ファイルシステムに容量を追加しました 詳細は次のとおりです ベースライン テスト データセットの容量は TB でした レベル 0 のテストに使用した 5 つのファイルシステムも活用しました 容量テスト用の完全なテスト データセットに 50,000 個未満のファイルを追加しました 各ファイルシステムに追加された容量には 深いディレクトリ構造が含まれており 複数のファイル タイプが混在していました 追加されたデータ タイプは VMDK イメージ オペレーティング システム バイナリ 圧縮されたソフトウェア ファイル PDF ファイル ログ ファイル fsutil で作成されたサイズの大きいフラット ファイルです 複数のデータ タイプが混在することが予想されるお客様の実際の環境を想定して これらのデータ タイプを追加しました ファイルシステムの番号 追加された容量 (%) 追加された容量 (GB) 総容量 (TB) ストリーム数 バックアップ時間 (hh:mm:ss) GB/ 時 1 10% :58: % :85: % :48: % :45: % :41:

15 10% に相当する小さなファイル( サイズ :50 KB ディレクトリの深さ:5 層以内 ) を 同じく 5 つのファイルシステムに追加すると 次のような結果になりました ベースライン容量は TB 320 万ファイルでした 追加率 (%) 追加ファイル数 ( 単位 : 千 ) ファイル総数 ( 単位 : 百万 ) ストリーム数 バックアップ時間 (hh:mm:ss) ファイル数 / 時 ( 単位 : 百万 ) 10% :15: % :08: % :07: % :07: % :09:04 ~ % :11:16 ~4.96 最後のテストの目的は 最大スループットを確認することです そのために 約 1,100 万個以上のファイル (1/2 TB の容量に相当 ) を追加しました 総容量が 2.97 TB 1,440 万ファイルに増えました バックアップ時間は 3 時間 29 分でした スループット速度は最大 310 万ファイル / 時でした ストリームの追加に関して メリットが減少するポイント があることがわかりました このテストに使用したファイルシステムの数が限られていることと この Celerra Data Mover がサポートする NDMP ストリームの数 ( 最大 4 つ ) が原因であることはほぼ間違いありません 構成可能な最大数の 4 つではなく 3 つのストリームをこのテストで使用していたとしても 同じ結果が得られたと考えられます ストリームは ラウンド ロビン方式で使用可能なファイルシステムに結び付けられます つまり 3 つのストリームが 4 つのストリームと同じ働きをしたと考えられるのは 2 つのファイルシステムのバックアップが他のファイルシステムよりもかなり早く完了したからです 各種アプリケーションの数百万ものファイルを格納するために 多くのお客様が NAS システムを使用しているため 1 つのバックアップで対応できる最大ファイル数の制限を把握することが非常に重要でした バックアップおよびストレージの割り当て / プロビジョニングが容易であることを考えると NAS システムはこのタイプのデータを格納するのに最適であると言えます 15

16 結果に基づく推定 控え目な 248 万ファイル / 時という値を使用し 5 時間のバックアップでバックアップ ウィンドウあたり 1,240 万ファイルと仮定します 確認された 310 万ファイル / 時間という値を使用し 5 時間のバックアップでバックアップ ウィンドウあたり 1,550 万ファイルと仮定します 変更率が 10% の環境で 控え目な速度である 248 万ファイル / 時を使用した場合 ( ほとんどの本番システムでは Avamar サーバと NAS システムにラボのシステムにはなかった他の負荷がかかるため ) 総容量 1 億 2,400 万ファイルになります Avamar はすべてのバックアップのインデックスを フル として作成するため これは 効率的な バックアップ スループットです 変更率が 10% の環境で ( 無負荷の NAS システムと Avamar システムで検出された ) 最大速度の 310 万ファイル / 時を使用した場合 5 時間のウィンドウでバックアップできる総容量は 1 億 5,500 万ファイルになります 1 時間あたりの容量 ( 少ないファイル数 ) スキャン速度については 4 つのストリームがアクティブな状態で 1 時間あたり最大 230 GB の新しいデータが見つかりました 5 時間のウィンドウの場合 バックアップ ウィンドウあたり 1.15 TB になります これらの結果の計算については 適切なサイジングに関するガイドライン を参照してください 注 : ファイル数 / 時 の数値は Avamar インタフェースの Activity Monitor のコンソール ログに示されます このログは バックアップ対象の各ファイルシステムに対応するセクションに分けられていることに注意してください ログに含まれる特定のファイルシステム ジョブの開始時刻と終了時刻を関連づけて スループット ( ファイル数 / 時 ) を集約する必要があります Avamar バージョン 4 およびバージョン 5 の NDMP のパフォーマンス期待値に示されている最大 4,000 万ファイルのベスト プラクティスの基となった以前のラボ テストの結果と比べると これらの結果はパフォーマンスが大幅に向上しているように思われます 以前のパフォーマンス測定結果は Avamar NDMP Backup and Recovery: Celerra Data De-duplication vs. Native NDMP に記載されています パフォーマンスと重要な概念のまとめ 容量を増やすとバックアップのパフォーマンスが大幅に向上しますが 1 つまたは複数のファイルシステムの容量を占めているのが複雑なファイル タイプ (VMDK データベース PST その他の非構造化ファイルなど ) である場合 実際にはこの動作が該当しないことがあります また 数百万の inode が含まれた深いディレクトリ構造の場合 バックアップ時間が延びる可能性があります こうした 困難な シナリオをすべてテストできるわけではありません 16

17 Avamar グリッドに存在するストレージ ノードが増えると バックアップの速度が向上する場合がありますが 既存のバックアップ アクティビティによるグリッド リソースの競合が発生して相殺される可能性もあります どのテストでも ( ベースラインまたは日次増分 ) 最大スループットでの NDMP アクセラレータのメモリ平均使用量は 3 GB であり 7 GB を上回ることはありませんでした NDMP アクセラレータが追加のファイルシステムにサービスを提供する追加アカウントで構成されている場合や 5 つ以上の NDMP ストリームを処理できる NAS システムにサービスを提供している場合は メモリ使用量が増える可能性があります 複数のファイル タイプが混在する適度なファイル数の大容量環境の場合 単一ストリームでは 150~164 GB/ 時 4 つのストリームをすべて適切に活用した場合は最大 230 GB/ 時の速度が期待できます 変更率が 10% の環境で 4 つのストリームをすべて利用し バックアップ ウィンドウが 5 時間であるとすると NDMP アクセラレータ 1 台あたりの最大保護容量が 11.5 TB となります これは 効率的なバックアップ です Avamar バージョン 5 および 6 における NDMP クライアント コードの改良により ファイル数の多い環境のバックアップ時間が 3~4 倍向上したと考えられます 以前は ストリームあたり 1,000 万ファイルの制限 ( 最大数の 4 ストリームを使用した場合は 4,000 万ファイル ) がありましたが NDMP アクセラレータ 1 台あたりの 効率的なバックアップ のファイル総数が 1 億 2,400 万 ~1 億 5,500 万個 ( 使用可能なストリームをすべて使用した場合 ) に増えました 注意事項 : 小規模なテストによって NDMP アクセラレータが 1 時間あたり 496 万ファイル処理できることが実証されましたが (4 ストリームの場合 ) この速度は変更率が 10% の小さなデータセット ( ファイル総数が最大 350 万個 ) だけを対象に測定されたものです このデータセットを拡張してファイル総数を約 1,500 万個にすると 集約されたバックアップ速度が 310 万ファイル / 時 (4 ストリームの場合 ) に低下しました これは 変更された inode をスキャンし ダンプ ストリーム用に構築するために Celerra が必要とする準備時間に起因すると考えられます したがって NAS システムは高密度ファイルシステムのバックアップの制限要素になる可能性があります また NAS モデル ( ディスク タイプと RAID タイプ ) は CPU メモリ I/O 処理能力がそれぞれ異なるため 考えられるすべての組み合わせについてスループット動作を定量化することはほぼ不可能です 使用可能な Avamar ストレージ ノード ストリームをジョブが待機していないと仮定して Activity Monitor の [Elapsed Wait] 列で待ち時間が追跡されます 17

18 適切なサイジングに関するガイドライン バックアップ プロセスに適切にサービスを提供するために NAS システムのバックアップと同じくシンプルに 最適な量のリソースを活用する必要があります バックアップは Avamar ソリューションの主要コンポーネントである Avamar サーバ / グリッド Avamar NDMP アクセラレータ NAS システムに影響を及ぼします これらのシステムへの影響を理解することによって 導入する NDMP アクセラレータの最適な数 Avamar の適切な容量 特定の NAS システムのバックアップの予想時間に関するガイダンスが得られます EMC Avamar NDMP アクセラレータをサイジングするときは 次の情報を収集する必要があります データの量 : 容量 ファイルシステム / ボリュームの数 ファイル数 ( または inode 数 ) データのタイプ ( シンプルな部門共有 VMDK イメージ PST ファイル データベースなど ) データの変更率 NAS システムのモデル :CPU メモリ I/O ボードなどのオンボード リソースを示す NAS オペレーティング システムのバージョン NAS システムからローカル / リモート ネットワークへの接続 バックアップ ウィンドウで求められる SLA サイジング例 これらのデータ ポイントを前提として 適切なサイジング モデルを作成できます また Avamar ターゲット サーバ / グリッドに及ぼす影響を予測することもできます 次に例を示します お客様の NAS システム alpha には 4 TB のファイル ベースのデータが格納されている 10 個のファイルシステムに合計 7,400 万個のファイルがあり 大半が非データベースである データは主に 部門共有と NFS プロトコルによって提供される 1 TB のデータベース データで構成される ( アプリケーション レベルの ) 推定変更率は 1 日約 6% デバイスのモデルは Data Mover を 1 つ搭載した EMC Celerra NS-120 オペレーティング システムは DART バージョン つの 1 GbE 集約ポートを介して 2 つのローカル VLAN に接続されている 18

19 オフサイトの DR 施設へのデータのレプリケーションを検討する可能性がある ローカル管理者によると これまでの NDMP バックアップの所要時間は最大 9 時間 NS-120 alpha NAS システムへの影響は CPU 使用率が最大 15% メモリ使用率が 30% だった ここに挙げた項目の中で重要なのは これまでこの alpha NAS システムで NDMP ベースのバックアップが実行されてきたという情報です 代わりに 管理者が NDMP バックアップのテストラン (> /dev/null へのダンプなど ) を実行していれば役立ったと考えられます この追加情報により この NAS システム対して NDMP バックアップに関連するオーバーヘッドがあることがわかります NAS システムは CPU の容量 メモリの容量 バス速度がそれぞれ異なるため EMC Avamar NDMP バックアップが特定の NAS システムに及ぼす影響に関する情報を提供できるのは これまでの NDMP バックアップ アクティビティから得られた経験的データだけです 注 : たとえば お客様が CPU 容量の非常に少ない NAS システムを使用している場合 最小のバックアップ リクエストだけで NDMP バックアップが NAS システムを圧迫する可能性は十分にあります 予想されるスループット速度でバックアップ インフラストラクチャが機能することを求める前に NAS システムが定義済みの出力ポートを介して要求されたブロックの構築と移動を処理できるようにしておくことが必須となります NAS システムに対するオーバーヘッドの一部を軽減するために EMC Avamar はレベル 1 増分ダンプだけを毎日要求します そのため Avamar によって記録された前回のバックアップ以降に変更されたブロックを含むスナップショットの作成による影響しかありません 本質的には これは前回のレベル 1 増分バックアップまたはレベル 0 増分バックアップ以降に変更されたブロックだけをバックアップする差分 / 増分バックアップを実行するのと同様です Avamar は 最初のフル バックアップ ( レベル 0) の後は 毎回レベル 1 増分バックアップを要求し続けます レベル 0 バックアップを再実行する必要はありません Avamar は 前回の既知のバックアップ以降にバックアップする必要があるブロックまたはファイルを特定するために保持されている NAS ベースのスナップショットには依存しません 代わりに 前回の既知の良好なバックアップの記録とそのバックアップに関連するファイルを保持し NDMP コマンド セットによって 該当の日付から現在までの間に送信されたブロックまたはファイルのバックアップだけを要求します このように 該当のリストを提供したり NAS システム管理者によって侵害される可能性のある特定のスナップショットを保持するために NAS システムに依存する必要はありません ダンプ (NetApp) プロセスまたは vbb (EMC) プロセスは スナップショットの作成後にファイルを構築し 定義済みのターゲット (Avamar NDMP アクセラレータ ) に送信する役割を担います 19

20 この例のソリューション 総容量の 25%( 全 4 TB のうち 1 TB) がデータベースであるため これらのファイル (.dbf ファイルなど ) は NAS システムですべて新しいブロックとみなされる可能性があります したがって ブロックの移動と大量のランダムな書き込みによって NAS システムが 1 TB のデータベース データのほぼすべてを識別し Avamar NDMP アクセラレータに送信する可能性がある場合は 3 TB の容量を 一般的な部門ファイル として扱い 残りの 1 TB を 非構造化データ として扱う必要があります ( 詳細については サイジングに関するその他の考慮事項 を参照してください ) 合計 3 TB の 一般的な部門ファイル データが存在する場合 : 毎日の変更率 6% =.06 x 3 TB = 1 日あたり 180 GB の新しい容量 毎日の変更率 6% =.06 x 7,400 万ファイル = 1 日あたり 440 万個の新しいファイル 使用する最大バックアップ時間の算出 : 180 GB/ 日に対して 230 GB/ 時の容量バックアップ速度を使用 = 最大 47 分 440 万ファイル / 日に対して 248 万ファイル / 時のファイル バックアップ速度を使用 = 最大 1.8 時間 算出された最長時間は 1.8 時間だったので 3 TB の部門ファイル データの予想される毎日のバックアップ時間にこの値を使用します また 合計 1 TB の 非構造化 DB データが存在する場合 この容量全体に対して次のようなベースラインの容量スキャン速度を使用する必要があります 1000 GB に対して 190 GB/ 時の容量バックアップ速度を使用 = 5.25 時間 上記の測定基準を前提として 次の手順で最終的な構成を提示できます 20

21 ステップ アクション 1 複数のファイルシステムが存在するので データベース データを格納するファイルシステムのバックアップ時間を部門共有データのバックアップ時間と合わせます 部門共有データ ファイルシステムよりも多くのストリームを使用できる場合は データベース ファイルシステムのバックアップを他のファイルシステムとともに実行できます ただし この例では 10 個のファイルシステムが定義されています 合計時間 = 1.8 時間 時間 = 約 7 時間 ( このバックアップ時間の大半は データベースを格納するファイルシステムに費やされます ) 2 このバックアップ時間は 1 台の NDMP アクセラレータで対応できる 8 時間というバックアップ ウィンドウを超えていません ただし Avamar レプリケーションが必要な場合は バックアップ ウィンドウとレプリケーション ウィンドウの合計時間が 10 時間になるため 1 台の NDMP アクセラレータで対応できる所要時間を超えることになります そのため ここでのソリューションは次のようになります 2a レプリケーションが不要な場合は 1 台の NDMP アクセラレータ 2b レプリケーションが必要な場合は 2 台の NDMP アクセラレータ 3 相互運用性マトリックスに記載されているように この例の DART OS のバージョンはサポートされています 4 NDMP バックアップのオーバーヘッドは これまでのバックアップで経験してきた状況 (CPU 使用率 : 最大 15% メモリ使用率 :30%) を上回ることはないと考えられます 5 NAS システムのスナップショット プロセスの特性を考えると 前述のように 非構造化 DB データ ( および他のタイプ ) 全体が重複除外のために NDMP アクセラレータに送信される可能性があります この場合 バックアップ時間が延びるため 必要な NDMP アクセラレータの数に即座に影響します 6 データ タイプ 重複除外率 保存を考慮する従来の Avamar サイジング手法を使用して 対象となる Avamar システムのサイズを決定する必要があります Avamar グリッド ノードの数または容量を検討する場合 ファイル数は不要です 21

22 これまでに明確にされなかったものは ファイルシステムへの部門データ ( 一般的なファイル データ ) とデータベース データの配布方法です ファイルシステム名から解釈できる可能性もありますが この相互関係についてはお客様に問い合わせる必要があります 7,400 万ファイルの大半を 1 つのファイルシステムに格納している場合など 配布の状況によっては 以前に確認した 124 万ファイル / 時のバックアップ速度に対応する重複除外率が低下する可能性があります 使用可能なファイルシステムに対するストリームの割り当ては 1 対 1 の関係です つまり 1 つのファイルシステムに対して複数のストリームが実行されることはありません 注 : このシステムが DART バージョン 6 以降を使用し 8 GB のオンボード メモリを搭載したシステム (NS-960 など ) であった場合 使用可能なアクティブ ストリームの最大数は 8 つになります ただし NDMP アクセラレータと Avamar サーバのリソース量が限られているため バックアップのスループットが直線的には増加しない可能性があります したがって 以前に割り出した速度を使用して控え目に計画することをお勧めします サイジングに関するその他の考慮事項 特定のデータ タイプをバックアップするときに いくつかの問題が表面化する可能性があります このようなデータ タイプとして データベース ファイル VMDK イメージ ファイル 暗号化または圧縮されたファイル PST メール ファイルなどがあります 発生する問題の原因の 1 つとして ブロックのオフセットを発生させるファイルまたはファイル セット内でのブロックのランダムな書き込みが考えられます ファイルに挿入された新しいブロックによって ファイル内の後続ブロックのオフセットまたは 移動 が発生すると 論理ブロック アドレス (LBA) が変更されます LBA が変更されると NAS システムはこれらのブロックを新しいブロックとして認識し その後 移動されたすべての先行ブロックに加え 新たに書き込まれたブロックも構築します EMC Avamar では ブロックのオフセットによって重複除外の動作が変わることはありません ただし ブロックのオフセットは NAS システムの差分増分ブロック識別プロセスに影響するため ダンプ ストリームで NAS システムから Avamar NDMP アクセラレータに送信されるブロックが増えることになります そのため (Avamar NDMP アクセラレータで ) バックアップ ジョブによって優れた重複除外結果が生成されることに変わりはありませんが バックアップ ジョブの時間が予想よりも長引くことがあります この動作が起こりうる問題であるかどうかを判別するには 以下をチェックします NDMP アクセラレータに送信されたギガバイト数が アプリケーションで見積もられた予想変更率 ( 送信されたバイト数を NAS ボリュームまたはファイルシステムで使用される合計バイト数で除算 ) を上回っている バックアップ ジョブで非常に良好な重複除外率が生成される レベル 1 バックアップのスループット速度がレベル 0 とほぼ等しい 22

23 一例として 大規模なお客様が 多数の部門ファイルシステムとともに PST ファイルシステムのバックアップのスケジュールを引き続き調整しようとしたときに上記の動作が確認されました この事例での問題点は次のとおりです バックアップ完了までの所要時間が 8~10 時間のファイルシステムもあれば 同じ容量で所要時間が 15~30 分のファイルシステムもある 構成は次のとおりです 1 台の Data Mover 上に 8 つのファイルシステムが存在 各ファイルシステムに格納されているのは PST ファイル ( 個人用電子メール フォルダのストレージ ) だけです これらは 1 台の Celerra Data Mover によって提供される CIFS ネットワーク共有に格納されたサイズの大きいユーザー ファイルです 優れたパフォーマンス のファイルシステムは NAS デバイス上でよく見られる標準的なデータを格納するシンプルな部門フォルダです 共有 容量 (GB) Celerra から NDMP アクセラレータに送信されたバイト数 重複除外のために送信されたバイト数 日次増分バックアップの時間 部門 B 11 MM 15 分 PST B 208 MM 9 時間 問題の原因 これらの PST ファイルの特性は バックアップするたびにダンプ ストリーム全体を再ハッシュする必要があることです 増分 ( レベル 1) バックアップでは NAS システムが新しいファイルを完全に認識し Avamar NDMP アクセラレータに送信します これらの PST ファイルの大半は新しいファイルとして完全に認識されるので ファイルシステムのデータが 800 GB の場合 Celerra は他の部門共有の 4 倍のデータを PST ファイルシステムから Avamar NDMP アクセラレータに送信します また NDMP アクセラレータは 他の部門共有の 20 倍のバイト数である PST ファイルシステムのデータをスキャンする必要があります ( スティッキー バイト アルゴリズム ) 確認されたバックアップ時間に大きな差があるのは この 2 つが原因です 基本的に NDMP アクセラレータは これらの PST ファイルシステムの最初のシーディング時間よりも少しだけ速い最大 100 GB/ 時で実行されています (Avamar バージョン 5) これは 変更率が高いという PST ファイルの特性によるものです これらの PST ファイルシステムの重複除外率が引き続き最大 99.5~99.7% であることが確認されているので これが問題であることはほぼ間違いありません ただし これは低速です 23

24 考えられる提案 1. 最適なタイミングを実現するために PST ファイルシステムのスケジューリングを引き続き再調整します 2. 他の部門共有に影響を及ぼさずに PST ファイルシステムへのサービス提供とバックアップを実行できるように 専用の別の Celerra Data Mover に PST ファイルシステムを分離します 3. PST ファイルシステムのバックアップに代替方法 (Data Domain NDMP テープ サーバを備えた EMC NetWorker など ) を使用することを検討します または 多くの企業が PST ファイルをバックアップしていないので お客様のユーザー ベースで バックアップ不要 ポリシーを促進します ボリュームまたはファイルシステムで以前の NDMP ベースのバックアップ方法またはテスト ダンプ バックアップを実行したときに バックアップ対象に ( アプリケーション レベルの推定変更率を大幅に上回る ) 異常に大量のデータが送信されたことによって増分バックアップの速度が大幅に低下した場合は 前述のようにこの動作が問題になっていることを簡単に見分けることができます 今日の多くのNASシステムは ファイルシステムあたり 2 億 5,600 万ファイル以上にまで拡張でき ファイルシステムは 100 TBをはるかに上回るサイズまで拡張できますが バックアップ時にファイルシステム内のすべてのブロックおよび関連するinodeをターゲット デバイスに移動し カタログ化する必要があることを考慮しなければなりません Avamarでは NDMPアクセラレータを使用して このアクティビティがNASシステムに及ぼす影響を最小限に抑えます ただし このようなアクティビティにサービスを提供できるようにNASシステムが設計されている必要があります AvamarのNDMPアクセラレータを使用して バックアップ リソースの消費に起因するオーバーヘッドを最小限に抑えることで 従来の他のレガシー バックアップ ツールよりも NASシステムの拡張性をさらに向上させることができます まとめ 既存の NAS 環境から正確なデータ タイプとデータ量を収集することにより Avamar NDMP アクセラレータと Avamar のストレージ消費量を正確に見積もることができます バックアップ時間とリソース消費量を見積もる際に ベースライン テストや 既存の NAS システムの以前の NDMP バックアップ情報が非常に役立つことがあります NDMP アクセラレータに送信されるデータ量と重複除外率は データ タイプによって大きな影響を受ける可能性があります Avamar バックアップの非常に効率的なスループットにより 従来のバックアップ方法ではサポートできないサイズまで NAS システムのサイズを増やすことができます 24

25 キャパシティ プランニングと拡張管理 Avamar の拡張を計画するときには Enterprise Manager Avamar 管理コンソール MCCLI コマンド セットなど Avamar 内の通常の場所から標準レポートを生成できます また EMC DPA(Data Protection Advisor) を利用して 履歴を目的としたレポート データのマイニング データ ストレージ インフラストラクチャの他の要素とデータ ポイントの相互参照 / 関連づけを行うこともできます NAS システムは 予想以上に管理不可能なほど増大する可能性のある 多数のデータ層のランディング領域になる傾向があります これは 基盤となるファイルシステムまたはボリュームの自動拡張を許可するポリシー クォータを利用していないこと 大量のデータの移行 ( 一元化された NAS システムへのすべての部門データ共有の移動など ) が原因と考えられます 古いファイルを長期的なメディア ストレージに移行するツールを利用して 保存期間を過ぎたデータを管理できます 小さなテスト サンプルを使用したテストでは リソースの絶対的な制限や破断点は見つからなかったため 1 台の NDMP アクセラレータでバックアップできるファイルの最大数と最大容量を把握するには テストの結果から推定する必要があります テストで使用した NDMP アクセラレータで提供されるストリームの最大数によって 使用可能なリソースを上回るほどの過度の負担がユニットにかかることはなかったため これは妥当な方法と言えます Avamar NDMP アクセラレータは 8 つのストリームをサポートできるので 直線推定は正確ではありませんが ある程度は推定できます EMC Celerra/VNX システムと NetApp FAS システムでは いずれも一定レベルのネイティブな重複除外を実行できます 以前に説明したように これらのプロセスは NAS システムに対するオーバーヘッドを発生させます そのため バックアップ スケジュールが NAS システムのネイティブな重複除外スケジュールの妨げにならないようにする必要があります EMC Celerra と EMC VNX の DART OS コードの柔軟性により これまで Celerra データ重複除外によって圧縮されていたファイルの解凍が可能になります つまり NDMP バックアップで 圧縮されたファイルが Avamar NDMP アクセラレータに送信されることはなくなります 圧縮されたファイルでは適切に重複除外が行われないため これは NDMP アクセラレータにとって望ましいことです ただし データが圧縮されていない状態で NDMP アクセラレータに送信されると 最初の ( レベル 0) バックアップのバックアップ速度が低下する場合があります この機能を有効にするには 重複除外済みのファイルを送信前に解凍する dedupe.backupdatathreshold=0 スイッチを設定します このスイッチは ファイルシステムごとに設定する必要があります データはリストア時に再圧縮されます このスイッチの構成例を以下に示します 25

26 Celerra Data Mover または VNX Blade で VNX ファイル重複除外および圧縮用にバックアップ データの閾値を設定するには 次のコマンド構文を使用します $ fs_dedupe -default -set {<movername> -all} -backup_data_threshold <percent> <movername> は Data Mover の名前です <percent> は NDMP の容量削減バックアップを実行するために 重複除外済みファイルが超えてはならないパーセンテージです たとえば 90 に設定すると 物理サイズ ( 圧縮されたファイル + 変更されたブロック ) が論理サイズの 90% を超える重複除外済みファイルは 容量削減形式でのバックアップが試みられずに ファイル データ全体がバックアップされます 物理サイズが論理サイズの 90% 未満の重複除外済みファイルは 容量削減形式でバックアップされます この値を 0 に設定すると 容量削減バックアップが無効になります 値の範囲は 0~200 で デフォルト値は 90% です VNX 動作環境 (DART バージョン 6 の後継 ) の今後の開発には NDMP アクセラレータでの大量のリソース消費を軽減する永続的な増分方法バックアップを提供するための改良が含まれます このため お客様が VNX OS/DART 7 および Avamar NDMP アクセラレータ コードの今後のリリースにアップグレードしたときに ( このホワイト ペーパーで説明するテストには含まれていない ) スループットのパフォーマンスの向上が期待されます Avamar NDMP クライアント コードの今後のリリースでは ネイティブに重複除外されたファイルを処理できるように パフォーマンスとプロセスがさらに強化される予定です 以前の結果を基にした 8 ストリームの場合の推定 テスト中 メモリに過度に負担がかかることはありませんでした テスト サンプルと 4 つのストリームを使用したバックアップで消費されたメモリは 7 GB に過ぎませんでした バックアップ ジョブが完了すると メモリ リソースが迅速に解放されました したがって 36 GB のメモリを搭載したアクセラレータで メモリ不足によるボトルネックが発生することはないはずです 36 GB のアクセラレータ ノードでは この調査で示した数よりも多くのストリームを処理できると考えて問題ないと思われます ただし メモリが過剰に消費されるとパフォーマンスに大きな影響を及ぼし システムがディスクのスワップ領域にメモリ ページをスワップし始めます この状況が発生するとパフォーマンスが大幅に低下します そのため 推奨数を上回る数にストリームを増やした場合や NDMP アクセラレータにアカウントを追加し 追加のストリーム (avtar プロセス ) が発生した場合は メモリを常に監視する必要があります メモリを監視するには NDMP アクセラレータ ユニットで vmstat コマンドを使用します 26

27 このホワイト ペーパーで示すテストでは CPU 使用率はピーク時に 70% に達しました ( 測定の最大値は 100%) したがって あと 30% の処理能力を使用可能であると推測されます ( さらに多くのストリームを追加して )NDMP アクセラレータを拡張した場合 揮発性メモリ リソースよりも前に処理能力が不足する可能性が高くなります 構成の拡張 NDMP アクセラレータは NAS バックアップ システムまたは NAS バックアップ システム セットの構成に直線的に追加できますが アクセラレータ間でデータや構成を転送して相互運用することは一切ありません グローバル重複除外プロセス ( 実行される完全な重複除外プロセスの最終ステップ ) では 重複するセグメント ID を問い合わせるために Avamar ターゲット サーバ / グリッドと対話するので このような相互運用は不要です Avamar グリッドの内部では データ セグメントと関連するハッシュ ID は分離されないため すべてのクライアントのすべてのデータ セグメントが相互に比較されます したがって 複数の NDMP アクセラレータを使用している場合でも アクセラレータ間での通信を必要とせずに優れた重複除外を引き続き実現できます また 同じプラグイン タイプ (Celerra または NetApp) を利用することを前提として 代替アカウント つまり代替の NDMP アクセラレータによってデータをリストアすることもできます NDMP アクセラレータは 高度な構成やクラスタリングを必要とせずに簡単に追加できます NDMP アクセラレータを環境に追加することで 大規模な NAS 環境をサポートできるようになります 継続的な結果と事例については EMC Avamar Backups for Highly Scaled-Out Network Attached Storage (NAS) Environments を参照してください 結論 ラボでのテストとお客様独自の NAS の事例を使用して NDMP アクセラレータのベースライン パフォーマンスの期待値を定義しました これにより 特定の SLA を満たすために必要なソリューションの適切なサイジングが可能になります 調査結果から Avamar NDMP アクセラレータが EMC および NetApp の NAS 環境の効率的なバックアップに最適なソリューションであることがわかりました 一元管理 さまざまなレポート作成メカニズム EMC スタッフの支援により Avamar NDMP アクセラレータを使用し 高パフォーマンス リカバリ性 可用性を兼ね備えた NAS バックアップ ソリューションを将来に向けて確実に拡張できます 27

28 NAS システムのバックアップ用に Avamar NDMP アクセラレータを導入すると 以下によって資本コストと運用コストの削減を実現できます ネットワーク消費を削減できる広範な Avamar 重複除外プロセス NAS システムに対するオーバーヘッドも削減する毎日の高速フル バックアップ 高可用性を実現し 安心感をもたらす RAIN を採用した Avamar ターゲット システムのディスク ベースのグリッド アーキテクチャ 効率的な管理と最適化されたパフォーマンスを実現する ポリシー構成に組み込まれた新しいマルチストリーミング選択 これらの主な機能により SLA の実現能力が強化されます 優れたプロトコル (NDMP) を利用した NAS システム バックアップへの独自の技術的アプローチにこうしたビジネス上のメリットが加わり Avamar NDMP アクセラレータは コスト パフォーマンスと拡張性に優れた業界で実証済みのソリューションとなっています 関連資料 EMC Powerlink で次のドキュメントを入手できます ( アクセス権が必要 ) EMC Avamar 5.0 System Administration Guide EMC Avamar Backups for Highly Scaled-Out Network Attached Storage (NAS) Environments EMC Avamar NDMP Accelerator 5.0 User Guide EMC Avamar for NAS Backups: An Overview and Business Case Avamar NDMP Backup and Recovery: Celerra Data De-duplication vs. Native NDMP, part no. h5963 EMC Avamar 5.0 Operational Best Practices Guide EMC Celerra Network Server Version 5.5 Command Reference Manual Configuring NDMP Backups on Celerra 次のドキュメントも役立ちます NetApp Data ONTAP 7.3 Data Protection Tape Backup and Recovery Guide Data Protection Strategies for Network Appliance Storage Systems 28

29 付録 情報収集を支援するために NetApp FAS と EMC Celerra で利用できる多数の有用なコマンドがあります EMC Celerraで使用可能なキロバイト数を収集します server_2 は バックアップ用にサイジングするData Moverです server_df server_2 EMC Celerraで使用可能なinode数またはファイル数を収集します server_2 は バックアップ用にサイジングするData Moverです server_df server_2 -inode NetAppで使用可能なキロバイト数を収集します df NetAppで使用可能なinode数またはファイル数を収集します df i これらの出力の Used 列だけを収集するよう注意する必要があります また チェックポイント ( スナップショット ) である EMC Celerra ファイルシステムは考慮しないでください そのユニットのコマンドラインで NDMP アクセラレータの追加のパフォーマンス データを収集できます このアプライアンスには 通常の Linux システムまたは UNIX システムと同様にアクセスできます 正確な情報を収集するには 次のコマンドを使用します バックアップ中の NDMP アクセラレータでの CPU とメモリの消費量 : iostat xtc 5 10 vmstat 5 10 top 29

30 User Nice System の各列で消費された CPU を確認できます %idle 列は この 3 つの逆の組み合わせです 前述のコマンドは 5 秒おきに 10 回繰り返し実行することを示しており 次のように予想どおりの出力が生成されます バックアップ中の NDMP アクセラレータでのネットワーク パケット転送とポート使用状況 : netstat -i netstat -pnutl バックアップ中に NDMP アクセラレータでストリームを提供するために実行されているプロセス : pgrep l avtar ps ef grep avtar top 30