Embed Size (px)
Citation preview
EMC® NetWorker®バージョン 8.2
パフォーマンス 適化計画ガイド302-000-697
REV 01
Copyright © 2000-2014 EMC Corporation. All rights reserved.（不許複製・禁無断転載）
6 月, 2014 発行
EMC Corporation は、この資料に記載される情報が、発行日時点で正確であるとみなしています。この情報は予告なく変更されることがあります。
この資料に記載される情報は、「現状有姿」の条件で提供されています。EMC Corporation は、この資料に記載される情報に関する、どのような内容についても表明保証条項を設けず、特に、商品性や特定の目的に対する適応性に対する黙示の保証はいたしません。
EMC²、EMC、および EMC ロゴは、米国およびその他の国における EMC Corporation の登録商標または商標です。他のすべての名称ならびに製品についての商標は、それぞれの所有者の商標または登録商標です。
ご使用の製品に関する規制等についての 新情報は、EMC オンライン サポート（https://support.emc.com）を参照してください。
EMC ジャパン株式会社〒 151-0053 東京都渋谷区代々木 2-1-1新宿マインズタワーhttp://japan.emc.comお問い合わせはhttp://japan.emc.com/contact
2 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
5
7
9
概要 13
概要..............................................................................................................14NetWorker のデータ フロー............................................................................ 14
NetWorker 環境のサイズ設定 17
期待される内容............................................................................................. 18バックアップ環境のパフォーマンス達成目標の決定.......................... 18バックアップ ウィンドウの決定...........................................................18必要なバックアップ達成目標の決定................................................. 18
システム コンポーネント................................................................................. 19システム...........................................................................................19メモリ要件........................................................................................ 20システム バス要件............................................................................22
ストレージに関する考慮事項......................................................................... 23ストレージの IOPS 要件.................................................................... 24NetWorker サーバおよびストレージ ノード ディスクへの書き込みレーテンシー.............................................................................................. 25ストレージ パフォーマンスの推奨事項...............................................26
バックアップ操作の要件................................................................................ 27NetWorker カーネル パラメータの要件.............................................. 28並列セーブ ストリームの考慮事項.................................................... 28内部保守タスクの要件..................................................................... 32ネットワーク......................................................................................35ターゲット デバイス...........................................................................36コンポーネントの 70%ルール............................................................36
NetWorker 環境のコンポーネント................................................................... 37データゾーン.................................................................................... 37NetWorker 管理コンソール............................................................... 37コンソール データベース................................................................... 38NetWorker サーバー.........................................................................39NetWorker ストレージ・ノード.............................................................41NetWorker クライアント..................................................................... 41NetWorker データベース...................................................................42オプションの NetWorker アプリケーション モジュール.........................42仮想環境......................................................................................... 42NetWorker 重複排除ノード................................................................43
リカバリ パフォーマンスの要因...................................................................... 43接続およびボトルネック................................................................................. 43
NetWorker データベースのボトルネック.............................................48
図
表
序文
第 1 章
第 2 章
目次
EMC NetWorker 8.2 パフォーマンス 適化計画ガイド 3
チューニング設定 51
NetWorker の並列化の 適化.......................................................................52サーバの並列処理........................................................................... 52クライアントの並列化........................................................................52グループの並行化............................................................................52多重化............................................................................................. 53
ファイル システムの密度................................................................................53ディスクの 適化.......................................................................................... 54デバイスのパフォーマンスのチューニング方法...............................................54
入出力の転送速度...........................................................................54組み込みの圧縮機能....................................................................... 54ドライブのストリーミング....................................................................54デバイスの負荷を均等にする........................................................... 55ディスク ドライブのフラグメント化.......................................................55
ネットワーク デバイス.....................................................................................55ファイバ チャネル レーテンシー.........................................................56DataDomain.....................................................................................57ATFD デバイスのターゲット セッション数と 大セッション数................58仮想デバイス ドライブと物理デバイス ドライブの数........................... 60
ネットワークの 適化.................................................................................... 60高度な構成の 適化........................................................................60オペレーティング システムの TCP スタックの 適化...........................60高度なチューニング..........................................................................61ネットワーク レーテンシー................................................................. 61Ethernet の二重化........................................................................... 62ファイアウォール（FireWall）...............................................................63ジャンボ フレーム............................................................................. 63輻輳通知......................................................................................... 63TCP バッファ..................................................................................... 64TCP バックログのバッファ サイズを増やす......................................... 65NetWorker ソケット バッファ サイズ....................................................65IRQ バランシングおよび CPU の親和性............................................. 65割り込み緩和................................................................................... 66TCP オフロード..................................................................................66名前解決......................................................................................... 68
パフォーマンス テスト 69
現象の特定...................................................................................................70パフォーマンスの監視................................................................................... 70一般的な FTP テストを使用したボトルネックの特定......................................... 71DD を使用したセットアップ パフォーマンスのテスト......................................... 71bigasm および uasm を使用したディスク パフォーマンス テスト...................... 71
bigasm ディレクティブ....................................................................... 72uasm ディレクティブ..........................................................................72
第 3 章
第 4 章
目次
4 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
NetWorker のバックアップ データ フロー......................................................................... 14NetWorker のリカバリ データ フロー................................................................................15NetWorker データゾーン コンポーネント.......................................................................... 37ネットワーク デバイスのボトルネック...............................................................................44更新されたネットワーク.................................................................................................. 45更新されたクライアント...................................................................................................46専用 SAN.......................................................................................................................47RAID アレイ.................................................................................................................... 48NetWorker サーバの書き込みスループットの低下.......................................................... 49ファイルとスループット....................................................................................................53ファイバ チャネル レーテンシーがデータ スループットに及ぼすインパクト........................ 571 秒あたり 10/100 MB のネットワーク レーテンシー....................................................... 621 ギガバイトのネットワーク レーテンシー........................................................................ 62
12345678910111213
図
EMC NetWorker 8.2 パフォーマンス 適化計画ガイド 5
図
6 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
改訂履歴......................................................................................................................... 9NetWorker サーバの必要 小メモリ...............................................................................20バスの仕様 ...................................................................................................................23ディスクへの書き込みレーテンシーの結果および推奨事項 ............................................25PSS における NetWorker 8.1.x および 8.2 のサポート.....................................................29NetWorker サーバー操作に必要な IOPS ........................................................................33ディスク ドライブの IOPS 値 ........................................................................................... 35LTO-4 テープ ドライブのブロックサイズの効果 ................................................................57
12345678
表
EMC NetWorker 8.2 パフォーマンス 適化計画ガイド 7
表
8 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
はじめに
製品ラインを改善するための努力の一環として、EMC ではソフトウェアおよびハードウェアのリビジョンを定期的にリリースしています。 そのため、このドキュメントで説明されている機能の中には、現在お使いのソフトウェアまたはハードウェアのバージョンによっては、サポートされていないものもあります。 製品のリリース ノートには、製品の機能に関する 新情報が掲載されています。
製品が正常に機能しない、またはこのマニュアルの説明どおりに動作しない場合には、EMC のテクニカル サポート プロフェッショナルにお問い合わせください。
このマニュアルには、発行時点で正確だった情報が記載されています。 EMC オンライン サポート（http://japan.emc.com/support-training/support/online-support.htm）にアクセスし
て、このマニュアルの 新バージョンを使用していることを確認してください。
目的
このドキュメントでは、ConGroup（EMC コンシステンシ グループ）の構成および使用方法について説明します。
対象読者
このドキュメントは、ホスト システム管理者、システム プログラマ、または ConGroup の管理に携わるオペレータを対象にしています。
改訂履歴
次の表に、このドキュメントの改訂履歴を示します。
表 1 改訂履歴
リビジョン 日付 説明
01 2014 年 6 月 18 日 EMC NetWorker 8.2 のこのドキュメントの 初のリリース。
関連ドキュメント
次に示す EMC 関連の資料に補足情報が記載されています。
u 「EMC NetWorker 管理ガイド」
NetWorker ソフトウェアの構成および使用方法が記載されています。
u 「EMC NetWorker Avamar デバイス統合ガイド」
NetWorker 環境で Avamar デバイスを使用する計画および構成に関する情報が記載されています。
u 「EMC NetWorker クラスター インストール ガイド」
クラスター サーバーとクライアント上で NetWorker ソフトウェアをインストールおよび管理する方法に関する情報が記載されています。
u 「EMC NetWorker Updating from a Previous Release Guide」NetWorker ソフトウェアを以前にインストールされたリリースから更新する方法について説明します。
u 「EMC NetWorker リリース・ノート」
新の NetWorker ソフトウェアの新機能と変更内容、修正された問題、既知の制限、環境とシステム要件に関する情報が記載されています。
u 「EMC NetWorker Command Reference Guide」NetWorker のコマンドおよびオプションに関する参照情報が記載されています。
EMC NetWorker 8.2 パフォーマンス 適化計画ガイド 9
u 「EMC NetWorker Installation Guide」すべてのサポート プラットフォームのクライアント、コンソール、サーバーの NetWorkerソフトウェアをインストールまたは更新する手順を説明しています。
u 「EMC NetWorker クローン作成統合ガイド」
NetWorker、NMM、NMDA のクローン作成機能を使用する場合の計画、手順、および構成情報を含みます。
u 「EMC NetWorker Data Domain 重複排除デバイス統合ガイド 」NetWorker 環境での Data Domain デバイスを使用したデータ重複バックアップおよび保存の計画および構成に関する情報が記載されています。
u 「EMC NetWorker 災害復旧ガイド」
災害発生時に NetWorker サーバ、ストレージ ノード、クライアントを復旧するための準備に関する情報が記載されています。
u 「EMC NetWorker エラー メッセージ ガイド」
一般的な NetWorker エラー メッセージに関する情報が記載されています。
u 「EMC NetWorker Licensing Guide」NetWorker 製品および機能のライセンスに関する情報が記載されています。
u 「EMC NetWorker 管理コンソール オンライン ヘルプ」
NetWorker 管理コンソールと NetWorker の［管理］ウィンドウで日常の管理タスクを実行する方法を説明しています。 ヘルプを表示するには、メイン メニューで［ヘルプ］をクリックします。
u 「EMC NetWorker User オンライン ヘルプ」
NetWorker User プログラムは、Windows クライアント インタフェースです。 ネットワーク経由でファイルのバックアップ、リカバリ、アーカイブ、リトリーブを行うためにサーバに接続する Windows クライアント インタフェースである NetWorker User プログラムの使用方法について説明します。
u 「EMC NetWorker Online Software Compatibility Guide」EMC 情報保護ソフトウェアの各バージョンでサポートされているクライアンント、サーバー、ストレージのオペレーティング システムの一覧が記載されています。 「OnlineSoftware Compatibility Guide」は、EMC オンライン サポート サイト（http://support.emc.com）で入手できます。 ［製品ごとのサポート］ページで、［製品の検索］を使用して NetWorker を検索し、［インストール、ライセンス、構成］リンクを選択します。
u 「EMC NetWorker セキュリティ構成ガイド」
NetWorker で使用可能なセキュリティ構成の概要、安全な展開、物理的なセキュリティ管理など、製品の安全な運用を確実にするために必要な事項の概要について説明します。
u 「 EMC NetWorker NAS デバイス向けスナップショット管理統合ガイド」
NAS デバイスのレプリケーション技術を使用して作成された本番データのスナップショット コピーをカタログ化して管理する機能について説明しています。
u 「NetWorker VMware リリース統合ガイド」
統合された NetWorker 環境内で VMware および VADP（vStorage API for DataProtection）を計画および構成する方法を説明しています。
u 「EMC NetWorker SolVe Desktop（旧称 NPG（NetWorker Procedure Generator））」EMC NPG（NetWorker SolVe Desktop）は、顧客、サポート、およびフィールドによって実行される高需要タスクの正確なユーザー主導ステップを生成するために使用するスタンドアロン Windows アプリケーションです。 NPG では、各プロシージャはユーザーが選択できるプロンプトに基づいて作成および生成されます。 生成されたプロシージャにより次の操作が行われます。
l NetWorker 製品ガイドの も重要な部分の抜き出し
l 専門的なアドバイスの 1 つのドキュメントへの結合
はじめに
10 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
l 標準化された形式でのコンテンツの提供
EMC NetWorker SolVe Desktop にアクセスするには、以下にログオンしてください。 http://support.emc.com
このサイトのご利用には有効なサービス契約が必要です。
u テクニカル ノート/ホワイト ペーパーテクニカル ノートとホワイト ペーパーには、重要なビジネス上の問題や要件に適用される製品の詳細な技術的観点が記載されています。 テクニカル ノートとホワイト ペーパーの種類には、テクノロジーおよびビジネスの考慮事項、応用テクノロジー、詳細な論評、およびベスト プラクティスの計画が含まれます。
このマニュアルで使用される特記事項の表記規則
EMC では、特別な注意を要する事項に次の表記法を使用します。
負傷に関連しない作業を示します。
重要ではあるが、危険ではない情報を表します。
表記規則
本書では、以下の表記規則を使用します。
［太字］ ウィンドウ名、ダイアログ ボックス、ボタン、フィールド、タブ名、キー名、メ
ニュー パスなど（ユーザーが選択またはクリックする）インタフェース要素
の名前に使用されます。
「斜体」 本文内で参照される出版物の完全なタイトルに使用されます。
Monospace 次の場合に使用されます。
l システム コード
l エラー メッセージやスクリプトなどのシステム出力
l パス名、ファイル名、プロンプト、構文
l コマンドおよびオプション
［モノスペース斜体］ 変数に使用します。
モノスペース太字 ユーザー入力に使用します。
［ ］ オプション値
| 縦棒は、選択肢を示し、「または」を意味する
{ } 中括弧内は、ユーザーが指定する必要のある内容を示す（例：x、y、z）
... 省略記号は例の中で省略した重要でない情報を示す
サポート
EMC のサポート情報、製品情報、ライセンス情報は、次の場所で入手できます。
製品情報
ドキュメント、リリース ノート、ソフトウェア アップデートや、EMC 製品の詳細については、EMC オンライン サポート（https://support.emc.com）を参照してください。
テクニカル サポート
EMC オンライン サポートにアクセスして、［サービス センター］をクリックします。 EMC テクニカル サポートへの問い合わせ方法がいくつか表示されます。 サービス リクエストを開始す
はじめに
EMC NetWorker 8.2 パフォーマンス 適化計画ガイド 11
るには、有効なサポート契約が必要です。 有効なサポート契約の入手方法の詳細や、アカウントに関する質問については、EMC 販売担当者にお問い合わせください。
オンライン・コミュニティ
ピアの連絡先、対話、製品サポートおよびソリューションのコンテンツについては、EMC コミュニティ ネットワーク（https://community.emc.com）にアクセスしてください。 すべてのEMC 製品について、対話形式により、カスタマー、パートナー、認定専門資格保持者とオンラインで対話します。
ご意見
マニュアルの精度、構成および品質を向上するため、お客様のご意見をお待ちしております。 本書についてのご意見を [email protected] にお送りください。
はじめに
12 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
第 1 章
概要
u 概要......................................................................................................................14u NetWorker のデータ フロー.................................................................................... 14
概要 13
概要NetWorker ソフトウェアはネットワーク ストレージ管理アプリケーションで、データゾーン全体にわたる大量の複雑なデータの高速バックアップおよびリカバリ操作に 適化されています。 このガイドでは、無停止のパフォーマンス チューニング オプションについて説明します。 一部の物理デバイスでは期待するパフォーマンスが実現されないことがありますが、物理コンポーネントをよりパフォーマンスの高いデバイスに置き換えると、別のコンポーネントがボトル ネックになることがあります。 このマニュアルでは、既存環境のシステム停止を小限に抑えて NetWorker パフォーマンスのチューニングを行う方法について説明します。同じハードウェア セットでより良いパフォーマンスを達成するように機能の精査を試行します。また、次の内容について管理者を支援します。
u データ転送基盤の理解
u 必要条件を判断する
u ボトルネックの特定
u NetWorker パフォーマンスの 適化およびチューニング
NetWorker のデータ フロー次の図に、EMC® NetWorker データゾーンにあるコンポーネントのバックアップおよびリカバリ データ フローを図示します。
次の図は簡略化された図であり、すべてのプロセス間通信が示されているわけではありません。 その他にも多くのバックアップ データ フローおよびリカバリ データ フローの構成が可能です。
図 1 NetWorker のバックアップ データ フロー
概要
14 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
図 2 NetWorker のリカバリ データ フロー
概要
NetWorker のデータ フロー 15
概要
16 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
第 2 章
NetWorker 環境のサイズ設定
この章では、バックアップおよびシステム要件を決定する 善の方法について説明します。初のステップは、環境を理解することです。 パフォーマンスの問題は、多くの場合、ハード
ウェアまたは環境上の問題に起因します。 全体的なバックアップ データ フローを理解することは、NetWorker ソフトウェアで期待される 適なパフォーマンスを確認するために重要です。
u 期待される内容..................................................................................................... 18u システム コンポーネント......................................................................................... 19u ストレージに関する考慮事項................................................................................. 23u バックアップ操作の要件........................................................................................ 27u NetWorker 環境のコンポーネント........................................................................... 37u リカバリ パフォーマンスの要因...............................................................................43u 接続およびボトルネック......................................................................................... 43
NetWorker 環境のサイズ設定 17
期待される内容各クライアントの RTO（目標復旧時間）に基づいて環境のバックアップ パフォーマンス達成目標と必要なバックアップ構成を決定できます。
バックアップ環境のパフォーマンス達成目標の決定
使用される環境とデバイスに留意しながら、パフォーマンスの達成目標を特定することが重要です。
バックアップ環境のサイズ設定に関する考慮事項は、次のとおりです。
u NetWorker サーバ、ストレージ ノード、およびクライアントを含むバックアップ環境のパフォーマンス達成目標を設定する前に、ネットワークおよびストレージ インフラストラクチャの情報を確認します。
u 各クライアントの RTO を確認して設定します。
u 各 NetWorker クライアントのバックアップ ウィンドウを特定します。
u フル バックアップおよび増分バックアップ中に各クライアントでバックアップされるデータ量をリストアップします。
u 各クライアントのデータ増加率を特定します。
u クライアントのブラウズ ポリシー要件と保存ポリシー要件を特定します。ボトルネックの特定と達成目標の定義には、次のような方法が役立ちます。
u 図の作成
u すべてのシステム、ネットワーク、およびターゲット デバイス コンポーネントのリストアップ
u データ パスのリストアップ
u 各クライアントのデータ パスにあるボトルネック コンポーネントのマーキング
NetWorker 環境の潜在的なボトルネックの例については、接続およびボトルネック（43 ページ）を参照してください。
バックアップ ウィンドウの決定
各 NetWorker クライアントで許容できるダウンタイムを知っておくことは、非常に重要です。これによって RTO（Recovery Time Objective：目標復旧時間）が決定されます。 各NetWorker クライアントの RTO を確認して文書化して、各クライアントのバックアップ ウィンドウを特定します。
手順
1. 各 NetWorker クライアントの利用可能なバックアップ ウィンドウを確認します。
2. フル バックアップまたは増分バックアップでクライアントからバックアップされる必要のあるデータ量をリストアップします。
3. 各 NetWorker クライアントの毎日/毎週/毎月の平均データ増加量をリストアップします。
必要なバックアップ達成目標の決定
許容できるダウンタイムが限られている場合は、フル バックアップおよび複数の増分バックアップからバックアップ イメージを構成できないことがあります。 フル バックアップがさらに頻繁に必要になる可能性があり、これによってバックアップ ウィンドウが長くなります。 また、ネットワーク帯域幅の要件も増加します。
環境に必要なバックアップ構成の達成目標を決定する方法は、次のとおりです。
NetWorker 環境のサイズ設定
18 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
u 既存のバックアップ ポリシーを検証し、そのポリシーが各クライアントの RTO を満たすことを確認します。
u 収集した情報に基づいて各 NetWorker クライアントのバックアップ ウィンドウを評価します。
u 次のパラメータに基づいて個々の NetWorker クライアント グループの編成を決定します。
l バックアップ・ウィンドウ
l ビジネスの重要度
l 物理的な場所
l 保存ポリシー
u 各クライアント用に作成されたバックアップで RTO を満たすことができることを確認します。許容できるダウンタイム/バックアップ ウィンドウが短いほど、バックアップにコストがかかります。
システム コンポーネントすべてのバックアップ環境には、ボトルネックがあります。 ボトルネックが短時間であるとしても、そのボトルネックによってシステムで実現可能な 大スループットが決定されます。バックアップおよびリストア操作の速度の上限は、バックアップ チェーンで も低速なコンポーネントの速度となります。
パフォーマンス問題は、多くの場合、データゾーンのハードウェア デバイスに起因します。このガイドでは、ハードウェア デバイスが適切にインストールおよび構成されていることを前提としています。
このセクションでは、要件の特定方法について説明します。 次に例を挙げます。
u 移動する必要のあるデータ量
u バックアップ ウィンドウ
u 必要なデバイス数
u 必要な CPU 数
バックアップ ネットワーク上のデバイスは、4 つのコンポーネント タイプにグループ化できます。 グループは、デバイスの使用方法と使用場所に基づきます。 一般的なバックアップ ネットワークには、次の 4 つのコンポーネントがあります。
u システム
u ストレージ
u ネットワーク
u ターゲット デバイス
システム
複数のコンポーネントがシステム構成のパフォーマンスに影響します。
u CPU
u メモリ
u システム バス（利用可能な 大 I/O 帯域幅によって決定されます）
CPU 要件
1 MB のデータをソース デバイスからターゲット デバイスに移動するために 5 MHz が必要な場合、必要な CPU の 適な数を特定します。 たとえば、1 秒あたり 100 MB の速度でロ
NetWorker 環境のサイズ設定
システム コンポーネント 19
ーカル テープ ドライブにバックアップする NetWorker サーバまたはストレージ ノードには、1GHz の CPU 能力が必要です。
u ネットワークから NetWorker サーバまたはストレージ ノードにデータを移動するには、500 MHz が必要です。
u NetWorker サーバまたはストレージ ノードからバックアップ ターゲット デバイスにデータを移動するには、500 MHz が必要です。
あるタイプの CPU で 1 GHz を別のベンダーの CPU の 1 GHz と直接比較することはでき
ません。
システムの CPU 負荷は、数多くの付加的な要因によって影響を受けます。 次に例を挙げます。
u CPU 能力の不足は、必ずしも CPU の負荷が高いことで直接的に発生するわけではなく、他のシステム コンポーネント構成の副次的な影響である可能性もあります。
u 推進要因：パフォーマンスが異なるため、さまざまなベンダーのドライバを調べます。 同じオペレーティング システム上のドライバは、同じスループットを達成するものの、CPU 使用率に大きな違いがあります。
u ディスク ドライブのパフォーマンス：
l /nsr に 400 個以上のクライアントがあるバックアップ サーバでは、頻繁に使用されるディスク ドライブで CPU 使用率が 60%以上になることがよくあります。 使用率の低いディスク アレイの/nsr にある同じバックアップ サーバでは、CPU 使用率が 15%以下になります。
l UNIX および Windows において、特権モードで CPU 時間が多くかかる場合や、CPU負荷の割合がユーザー時間よりもシステム時間で高い場合は、一般的に、NetWorker プロセスが I/O の完了を待機していることを示します。 NetWorker プロセスが I/O を待機している場合、ボトルネックは CPU ではなく、NetWorker サーバのホストに使用されるストレージです。
l Windows では、遅延プロシージャ コールに多くの時間がかかる場合は、たいてい、デバイス ドライバに問題があることを示します。
u 次の分類に従って、CPU 使用率を監視します。
l ユーザー モード
l システム モード
u ハードウェア コンポーネントの割り込みによって、システムの CPU 使用率が高くなり、パフォーマンスが低下します。 デバイスの割り込み数が 1 秒あたり 10,000 回を超える場合は、デバイスを確認します。
メモリ要件
バックアップ オペレーションでメモリがボトルネックにならないように、 小メモリ要件を満たすことが重要です。
次の表は、NetWorker サーバーの 小メモリ要件を示しています。
表 2 NetWorker サーバの必要 小メモリ
クライアントの数 必要 小メモリ
50 個未満 4 GB
NetWorker 環境のサイズ設定
20 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
表 2 NetWorker サーバの必要 小メモリ （続き）
クライアントの数 必要 小メモリ
51～150 個 8 GB
150 個以上 16（GB）
1024 並列処理値
次の構成と類似したセーブ グループに対するパフォーマンスの観察に基づくと、 小必須メモリは Linux で 1 GB、Solaris で 600～700 MB、Windows で 250～300 MB となります：
u 25 クライアント
u クライアントの並列処理 = 8
u 32 個の AFTD デバイスを使用した 5 個のリモート ストレージ ノード
u デフォルト デバイス ターゲット セッション数（4）
u デフォルト デバイス 大セッション数（32）
サーバの並列処理数の値を大きくすると、インデックスおよびメディア データベース上の
NetWorker サーバ IOPS に影響します。
ページファイルまたはスワップ使用量の監視
メモリ ページングはバックアップ環境のパフォーマンス低下を引き起こすため、専用バックアップ･サーバでは行わないでください。
Windows 2003 に関する考慮事項
Windows 2003 サーバーに固有の以下の推奨事項があります。
u デフォルトでは、Windows 2003 32 ビット サーバは、カーネル モード プロセスとアプリケーション モード プロセスの両方に 2 GB のメモリを割り当てます。 パフォーマンスを向上するには、NetWorker ソフトウェアに追加のメモリを割り当てます。 詳細については、Microsoft サポート技術情報の記事（283037）を参照してください。
u ページングが必要な場合は、Windows サーバにインストールされている物理 RAM の1.5 倍の 大ページファイル サイズをお勧めします。 詳細については、Microsoft サポート技術情報の記事（2267427）を参照してください。
DFA（ダイレクト ファイル アクセス）の Client Direct 属性
Client Direct 属性を使用することによって DFA を有効にするときに考慮すべき多数の条件があります。
次に、Client Direct 属性を使用することによって DFA を有効にする場合の考慮事項を示します。
u クライアント上の CPU の能力が、改善された DFA-DD のパフォーマンス能力を利用するのに十分なことを確認します。 ほとんどの場合、Client Direct によってバックアップ パフォーマンスが大幅に向上されます。 DFA-DD バックアップでは、各コンカレント セッションのために CPU 負荷が約 2～10%多く必要になります。
u DFA-DD を使用する各セーブ セッションには、 大 70 MB のメモリが必要です。 10 個の DFA ストリームが実行されている場合、すべての DFA セッションについてクライアント上で必要なメモリは 700 MB です。
NetWorker 環境のサイズ設定
メモリ要件 21
u DFA-AFTD へのセーブ セッションでは、Boost を使用する DFA-DD に実行されるバックアップに比べて少ないメモリおよび CPU サイクルが使用されます。 DFA-AFTD を使用するセーブ セッションでは、mmd を使用する従来の保存に比べてわずかに多くのメモリおよび CPU サイクルが使用されます。
システム バス要件
HBA/NIC の配置は重要ですが、内部バスがオペレーティング システムの も重要なコンポーネントであると考えられます。 内部バスによって、CPU、メモリ、ディスク、およびネットワークなどの内部コンピュータ コンポーネント間の通信が実現されます。
バスのパフォーマンス基準
バスのパフォーマンスは、以下のようないくつかの要因によって決まります。
u バスのタイプ
u データ幅
u クロック レート
u マザーボード
システム バスの考慮事項
バスのパフォーマンスに影響する注意すべき考慮事項があります。
u より高速なバスを使用しても、パフォーマンスが向上されるとは限りません。
u よりハイ エンドのシステムでは、複数のバスを使用してパフォーマンスを向上します。
u バスは、多くの場合、システムの主なボトルネックです。
システム バスに関する推奨事項
I/O ボトルネックが発生する可能性を軽減するため、サーバとストレージ ノードの両方にPCIeXpress を使用することをお勧めします。
旧タイプのバスや、旧タイプのバス向けに 適化された高速コンポーネントは、データ転送
中に過剰な割り込みを生成して CPU スパイクを発生させるため、使用しないでください。
PCI-X および PCIeXpress に関する考慮事項
PCI-X バスと PCIeXpress バスに特に影響する考慮事項があります。
u PCI-X は、半二重の双方向 64 ビット パラレル バスです。
u PCI-X バスの速度は、バスで も遅いデバイスに制限される可能性があります。カードの配置に注意してください。
u PCIeXpress は、8/10 エンコーディングを使用する全二重の双方向シリアル バスです。
u PCIeXpress バスの速度は、デバイスごとに決定されます。
u 高速 HBA/NIC を遅いバスに接続しないでください。常に、バス要件を考慮してください。サイレント パケット ドロップが PCI-X 1.0 10GbE NIC で発生する可能性があり、バス要件を満たすことができません。
u 高速ストレージを遅い HBA/NIC に接続するハードウェアでは、全体的なパフォーマンスが遅くなります。
コンポーネントの理想的なパフォーマンス レベルの詳細については、コンポーネントの 70%ルール（36 ページ）を参照してください。
NetWorker 環境のサイズ設定
22 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
バスの速度要件
必要なバス速度はファイバー チャネルのサイズに基づいています。
u 4 Gb のファイバ チャネルでは、425 MB/秒が必要です。
u 8 Gb のファイバ チャネルでは、850 MB/秒が必要です。
u 10 GB のファイバ チャネルでは、1,250 MB/秒が必要です。
バスの仕様
バスの仕様は、バスのタイプ、MHz、および 1 秒あたりの MB に基づいています。
特定のバスの仕様を次の表に示します。
表 3 バスの仕様
バスのタイプ MHz MB/秒
PCI（32 ビット版） 33 133
PCI（64 ビット版） 33 266
PCI（32 ビット版） 66 266
PCI（64 ビット版） 66 533
PCI（64 ビット版） 100 800
PCI-X 1.0 133 1,067
PCI-X 2.0 266 2,134
PCI-X 2.0 533 4,268
PCIeXpress 1.0 x 1 250
PCIeXpress 1.0 x 2 500
PCIeXpress 1.0 x 4 1,000
PCIeXpress 1.0 x 8 2,000
PCIeXpress 1.0 x 16 4,000
PCIeXpress 1.0 x 32 8,000
PCIeXpress 2.0 x 8 4,000
PCIeXpress 2.0 x 16 8,000
PCIeXpress 2.0 x 32 16,000
ストレージに関する考慮事項ストレージ構成のパフォーマンスに影響するコンポーネントがあります。
u ストレージ接続：
l ローカル、SAN に接続、NAS に接続
l ストレージ スナップショットの使用使用されるスナップショット テクノロジーのタイプによって、読み取りパフォーマンスが決定されます。
NetWorker 環境のサイズ設定
ストレージに関する考慮事項 23
u ストレージ レプリケーション：一部のレプリケーション テクノロジーによって大量のレーテンシーが書き込みアクセスに追加され、ストレージ アクセスが遅くなります。
u ストレージ タイプ：
l SATA（シリアル ATA）コンピュータ バスは、ハード ディスク デバイスや光学ドライブなどのストレージ デバイスにホスト バス アダプタを接続するためのストレージインタフェースです。
l FC（ファイバ チャネル）は、ギガビット速度のネットワーク テクノロジーです。ストレージ ネットワークに主に使用されます。
l フラッシュは、不揮発性コンピュータ ストレージです。一般的なストレージやコンピュータとその他のデジタル製品間のデータ転送に使用されます。
u ストレージの I/O 転送速度：ストレージの I/O 転送速度は、さまざまな RAID レベルの影響を受けます。バックアップサーバに 適な RAID レベルは、RAID1 または RAID5 です。ディスクへのバックアップには、RAID3 を使用する必要があります。
u スケジュールされた I/O：ターゲット システムが特定の時刻に I/O 集中型のタスクを実行するようにスケジュールされている場合、異なる時刻で実行するようにバックアップをスケジュールします。
u I/O データ：
l raw データ アクセスを使用すると、パフォーマンスは 高レベルとなりますが、保存されるデータは今後のアクセスのために論理的にソートされません。
l 数多くのファイルがあるファイル システムでは、ファイル システムで追加の処理が必要となるため、パフォーマンスが低下します。
u 圧縮：データがディスク、オペレーティング システム、またはアプリケーション上で圧縮される場合、バックアップする前にデータの圧縮が解除されます。 CPU ではファイルを再圧縮する時間が必要になるため、ディスク速度は悪影響を受けます。
ストレージの IOPS 要件
NetWorker データのホストに使用されるファイル システム（/nsr）は、基本となるオペレーティング システムのオペレーティング システム ベンダーによってサポートされるネイティブなファイル システムであり、かつ Posix に完全準拠する必要があります。
このセクションに示すストレージ・パフォーマンス要件（IOPS：1 秒あたりの I/O 動作数）が満たされないと、NetWorker サーバのパフォーマンスが低下し、しばらく応答しないことがあります。
ストレージのパフォーマンスが所定の IOPS 要件の 50%以下に低下する場合：
u NetWorker サーバのパフォーマンスの信頼性が低下する可能性があります。
u NetWorker サーバが長期間応答しなくなる可能性があります。
u バックアップ ジョブが失敗する可能性があります。ストレージのパフォーマンスに関する NetWorker サーバ要件は、次の項目によって決定されます。
u NetWorker データゾーンの監視
u バックアップ ジョブ
u 保守タスク
u レポート作成タスク
u 手動タスク
NetWorker 環境のサイズ設定
24 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
NetWorker サーバおよびストレージ ノード ディスクへの書き込みレーテンシー
NetWorker サーバーおよびストレージ ノードの書き込みレーテンシーに関する要件の決定は重要です。 NetWorker サーバ上の/nsr およびストレージ ノードの書き込みレーテンシーは、/nsr をホストするストレージにとって、全体的な帯域幅よりも重要です。 これは、NetWorker では内部データベース アクセスに非常に数多くの小さなランダム I/O を使用するためです。
次の表に、NetWorker バックアップ操作中のディスクへの書き込みレーテンシーのパフォーマンスに対する影響を示します。
表 4 ディスクへの書き込みレーテンシーの結果および推奨事項
ディスクへの書き込みレーテンシー（単位：ミリ秒）
パフォーマンスへの影響 推奨
25 ミリ秒以下 l バックアップ パフォーマンスは安定
l 適なバックアップ速度
Yes
50 ミリ秒 l バックアップ パフォーマンスが遅い（NetWorker サーバによってデ
ータベース更新が強制的にスロットリングされます）
l NMC 更新の遅延および失敗
いいえ
100 ミリ秒 保存グループやセッションの失敗 いいえ
150～200 ミリ秒 l NetWorker デーモンの開始の遅延
l バックアップ パフォーマンスが不安定
l 書き込み操作用ボリュームの準備が未完了
l プロセス間通信が不安定
いいえ
同期レプリケーション テクノロジーまたはレーテンシーに悪影響を及ぼすその他のテクノロ
ジーは使用しないでください。
サーバおよびストレージ ノード ディスクの推奨設定
NetWorker サーバーおよびストレージ ノード ディスクのパフォーマンスを 適化するための推奨事項を検討することが重要です。
u 負荷の増大が予想される NetWorker サーバ（バックアップ中に発生する並列セッション数が 100 セッションを超える）では、NetWorker データベースをホストするために高速ディスク デバイスを専用にします。
u NetWorker サーバ用に構成されたディスク ストレージでは、RAID-10 を使用します。u サーバの並列化に伴う並列セッション数が 400 を超える大規模な NetWorker サーバで
は、NetWorker サーバによって使用されるファイル システムを分割します。 たとえば、/nsr フォルダを 1 つのマウントから次の複数のマウント ポイントに分割します。/nsr
/nsr/res
/nsr/index
/nsr/mm
NetWorker 環境のサイズ設定
NetWorker サーバおよびストレージ ノード ディスクへの書き込みレーテンシー 25
u NetWorker サーバの NDMP バックアップでは、/nsr/tmp フォルダに別々の場所を使用して、大容量の一時ファイルの処理に対応します。
u すべてのマウント ポイントが物理的に同じ場所にあっても、オペレーティング システムを使用して並列ファイル システム I/O を処理します。 オペレーティング システムによって、NetWorker ソフトウェアよりも効率的に並列ファイル システム I/O が処理されます。
u AFTD のディスク ストレージに RAID-3 を使用します。
u アンチウイルス ソフトウェアでは、NetWorker データベースのスキャンを無効化します。アンチウイルス ソフトウェアが/nsr フォルダをスキャンできると、ファイルのオープン/クローズのリクエストが頻繁に発生することによって、パフォーマンスの低下、タイムアウト、または NetWorker データベースの破損が発生する可能性があります。 アンチウイルスの除外リストに、AFTD（高度なファイル タイプ デバイス）に使用される NetWorker ストレージ ノードの場所も含める必要があります。ファイル アクセス中の場所がすべて含まれている場合は、以前にアクセスしたファイルのスキャンをスキップするかどうかの除外リストに関係なく、特定の場所のアンチウイルス スキャンを無効にしても効果がないことがあります。 特定ベンダーに問い合わせて、更新されたバージョンのアンチウイルス ソフトウェアを入手してください。
u ファイル キャッシュでは、アグレッシブなファイル システム キャッシュによってコミットの問題が発生することがあります。
l NetWorker サーバ： すべての NetWorker データベースが影響を受ける可能性があります（nsr\res、nsr\index、nsr\mm）。
l NetWorker ストレージ ノード： AFTD（高度なファイル タイプ デバイス）を使用して構成されている場合。遅延した書き込み操作を無効化し、代わりにドライバのフラッシュ コマンドおよびライトスルー コマンドを使用します。
u NetWorker ではコミットされた I/O を使用するため、NetWorker サーバでは、通常のサーバ アプリケーションの場合よりも、ディスク レーテンシーの考慮が重要になります。NetWorker の内部データベースへの各書き込みは、次の書き込みが試行される前に確認およびフラッシュされる必要があります。 これは、内部データベースの潜在的なデータ損失を回避するためです。 ストレージがレプリケートまたはミラーされている場合の/nsr に関する考慮事項は、次のとおりです。
l 余分なレイヤーが I/O スループットに追加されて NetWorker の予期しない動作が発生するため、ソフトウェア ベースのレプリケーションは使用しないでください。
l ハードウェア ベースのレプリケーションでは、書き込み操作にレーテンシーが追加されないため、非同期レプリケーションが適切な方法になります。
l 長距離リンクまたは保証されていないレーテンシーによるリンクを経由する同期レプリケーションは使用しないでください。
l SAN では、ローカル レプリケーションが 12 km に制限されており、それより長い距離には特別な処理が必要です。
l レーテンシーが保証されていないため、同期レプリケーションに TCP ネットワークは使用しないでください。
l 各ハードウェア コンポーネントによってレーテンシーが追加されるため、ホップ数を考慮します。
ストレージ パフォーマンスの推奨事項
同じ物理ストレージ サブシステムの動作が、構成に応じて異なる場合があります。 たとえば、1 個の NetWorker マウント ポイント（/nsr）を複数のマウント ポイントに分割すると、オペレーティング システムでファイル システム ハンドラを並列化することによってパフォーマンスを大幅に向上できます。
NetWorker ソフトウェアでは直接 I/O を使用しませんが、システム障害の発生時にデータ損失を回避するために、データがディスク上にフラッシュされることを保証するために、書き込
NetWorker 環境のサイズ設定
26 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
み操作を実行するたびに同期要求を発行します（別名「コミットされた書き込み I/O」として知られます）。 したがって、オペレーティング システムでの書き込みキャッシュが 低限になるか、まったく影響がなくなります。 ただし、ハードウェアベースのライトバック キャッシュによって、NetWorker サーバのパフォーマンスを大幅に向上できます。
（プロセス自体に応じて、かつプロセスが構成可能であるかどうかに応じて）プロセスを単一スレッドまたはマルチスレッドとすることができますが、データ保護を 適にするために I/Oは常にブロック I/O（MMDB、RAP）となります。 例外は indexDB で、この場合は各クライアントが独自の I/O ストリームを持っています。
NetWorker サーバのメタデータ ストレージに関する一般的な推奨事項は、NetWorker データベース タイプに応じてグループ化されます。
u RAP データベースはファイル ベースで、フル ファイル読み取り処理を使用し、平均のI/O は 1 KB を上回ります。
u MMDB は固定ブロック長が 32KB のブロック ベースで、読み取り処理が多く、書き込み処理が少なくなります。
u RAP、MMDB およびインデックス データベースに対する NetWorker サーバ更新における I/O ボトルネックを回避するために、フラッシュ ドライブ上のデータベースごとに、別々のマウント ポイントを設定します。
u 主として、indexDB はシーケンシャル書き込み処理に基づいており、ブロック長は固定されず、読み取り処理が少なくなります。 indexDB には、SAS や SATA ベースのストレージなどの下位ストレージ階層で十分です。
u 一時的な NetWorker フォルダ（/nsr/tmp）は、NDMP バックアップ用のインデックス マージ操作中に多用されます。 一時的なフォルダは、FC ドライブなどの上位ストレージ階層に存在する必要があります。
I/O パターンの考慮事項
構成とメタデータのデータベースにアクセスするための NetWorker の I/O パターンは、データベースおよびその用途に応じて異なります。 ただし、一般には次の特定の要素が含まれます。
u 通常のバックアップ操作： 80%の書き込み/20%の読み取り
u クロスチェック操作： 20%の書き込み/80%の読み取り
u レポート作成操作： 100%読み取りこれに基づき、毎日のクロスチェックをプライマリ バックアップ ウィンドウの外で実行する必要があります。 また、本番バックアップ ウィンドウでの NetWorker メタデータ データベースに対する過剰な負荷を回避するために、レポート作成情報を提供する外部ソリューションを構成する必要があります。
I/O ブロック長もデータベースおよび使用例によって異なりますが、一般に 8KB の要求に丸められます。
NetWorker データゾーンの監視推奨事項
ストレージは、NetWorker サーバに対して 小で 30 回の IOPS を実現する必要があります。 この数は、NetWorker サーバの負荷が増加すると大きくなります。
バックアップ操作の要件NetWorker ソフトウェアの作業負荷において、バックアップ操作の開始および実行に関する要件が 大の部分となります。
u 負荷に応じて、IOPS 要件に NetWorker サーバの 大コンカレント セッションを追加し、この数値を 3 で割ります。
NetWorker 環境のサイズ設定
バックアップ操作の要件 27
NetWorker サーバーの 大並列化数は 1024 であるため、 大許容負荷は1024/3=340 IOPS です。
u NetWorker ソフトウェアでインデックス バックアップとブートストラップ バックアップの両方を同時に実行する必要がある場合、IOPS 要件が増加します。 この場合、次の項目を追加します。
l 小規模サーバでは 50 IOPS
l 中規模サーバでは 150 IOPS
l 大規模サーバーでは 400 IOPS小規模、中規模、および大規模な NetWorker サーバーのガイドラインについては、手動 NetWorker サーバー タスクの要件（33 ページ）を参照してください。
ブートストラップ バックアップを通常のバックアップ操作と同時に実行する場合にのみ、IOPS を追加します。 NetWorker サーバがアイドル状態のときにブートストラップバックアップが実行されるように構成されている場合、IOPS 要件は増加しません。
u 大量のジョブが同時に開始されるように NetWorker ソフトウェアが構成されている場合、IOPS 要件が増加します。負荷のスパイクに対応するには、開始される並列セッションそれぞれに 1 IOPS を追加します。
クライアントの並列化が 4（デフォルト）の場合、グループにつき 40 個以上のクライアントを開始することはお勧め［しません］。結果として、グループの起動中に 160 IOPS になります。
多数のクライアントを同時に開始すると、I/O システムが枯渇する可能性があります。
u それぞれのボリューム リクエストによって、数秒間で約 200 IOPS の短い I/O バーストが発生します。少量のボリュームを実行している環境では、影響は 小限になります。 ただし、マウント リクエストが頻繁に発生する環境では、NetWorker サーバに大きな負荷がかかります。 この場合、高アクティビティ（1 時間あたり 50 回以上のマウント リクエスト）のために 100 IOPS を追加します。 過剰な負荷を回避するには、より少ない数の大容量ボリュームを使用します。
u NDMP バックアップでは、インデックスの後処理のために余分な負荷がかかります。1,000 万個以上のファイルがある大規模な NDMP 環境のバックアップでは、120 IOPSが追加されます。
NetWorker カーネル パラメータの要件
負荷の高い NetWorker サーバ用に別個の起動スクリプトを作成するために、NetWorker サービスを開始する前に、次の環境変数を有効化します：
u tcp_backlog_queue： オペレーティング システムに応じて、適切なカーネル パラメータを起動スクリプトに追加します
u 開いているファイル記述子： 開いているファイル記述子のパラメータを、負荷の高いNetWorker サーバで必要な 小値の 8,192 に変更します
NetWorker ストレージ ノードおよびクライアントでは、デフォルトの起動スクリプトを使用しま
す。 tcp_backlog_queue、および開いているファイル記述子のパラメータは、ストレージ ノードおよびクライアントでは必要ありません。
並列セーブ ストリームの考慮事項
NetWorker 8.1 以降では、並列セーブ ストリーム（PSS）機能により、複数の並列セーブ ストリームが 1 個以上の宛先バックアップ デバイスに各クライアント リソース セーブセット エン
NetWorker 環境のサイズ設定
28 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
トリーをバックアップすることができます。 セーブセット エントリーはセーブポイントとも呼ばれます。これは通常、UNIX のファイル システム マウント ディレクトリまたは Windows のボリューム ドライブ文字です。 PSS バックアップとそれに続く復旧で、大幅なパラレル パフォーマンスの向上が可能です。
以下の表に、PSS でサポートされる項目を示します。
表 5 PSS における NetWorker 8.1.x および 8.2 のサポート
NetWorker リリース
オペレーティング システム
サポートされるセーブ セット
サポートされるバックアップのタイプ
仮想および非仮想シンセティック フル
チェックポイントの再開
8.1、8.1 SP1 UNIX、Linux ALL、個々のセーブ ポイン
ト
スケジュール いいえ いいえ
8.2 UNIX、Linux、Windows
ALL、Disaster_Recovery、重複排除、および CSV ボ
リューム（Windows のみ）
を含む個々のセーブ ポイ
ント
スケジュール Yes いいえ
PSS 対応 UNIX クライアント リソースの並列化値がリソースのセーブ ポイント数より大きい場合、スケジュール設定されたバックアップ保存グループ プロセスによって、並列化はセーブ ポイント間で分割され、すべてのセーブ ポイントの PSS 保存プロセスはほぼ同時に開始されます。 ただし、これは、以下の制限内で実行されます。
u NetWorker サーバー
u グループの並列化制御
u メディア デバイス セッションの可用性
クライアント リソースの PSS 並列化値は、セーブ ポイントの数の 2 倍以上に設定することをお勧めします。
PSS セーブ ポイントごとのストリームの数はバックアップの前にクライアントの並列化の値から決定され、バックアップ全体を通じて固定のままになります。 これは、1～4（ 大）の値です。1 は、バックアップするファイルを判別するためにセーブ ポイントのファイル システムを走査する別個の PSS プロセスを持つ単一のストリームを示します。 データをストリーミングして、ファイル システムを走査するプロセスを分離すると、パフォーマンスが向上することがあります。 また、PSS セーブ ポイントのバックアップ中に実行される保存プロセスの数は、ダイレクタとファイル システムの両方の走査プロセスのために 2 個の追加の保存プロセスが割り当てられているセーブ ストリーム プロセスの数と等しくなります。
各 PSS セーブ ポイントのデフォルトの 大ストリーム数である 4 は、1～8 の値に変更することができます。そのためには、UNIX と Windows の両方で、NSR_SG_PSS_MAX_SP_SPLIT=<値 1～8>環境変数を設定します。 この環境変数を設定した後で、NetWorker サービスを再起動して変更を有効にします。 デフォルトの 大値を増やすと、高速なディスクを備えたクライアントのパフォーマンスに影響する可能性があります。
クライアントの並列化がセーブ ポイントの数より少ない場合、一部のセーブ ポイントのバックアップは、単一のストリームのみを使用して PSS モードで実行されます。 その他のセーブポイントはデフォルトのモード（非 PSS）で実行されます。 そのため、PSS を一貫して使用するには、クライアントの並列化をセーブ ポイントの数の 2 倍以上に設定します。 これにより、セーブ ポイントごとに複数のストリームが確保されます。
PSS を活用する必要がある大きい高速なファイル システムは、クライアントのその他のセーブ ポイントとは別個にスケジュール設定された新しい別の PSS 対応クライアント リソースに配置することをお勧めします。 別のスケジュール設定を行うには、実行時間が異なる 2 個の異なるセーブ グループを使用しますが、クライアント ディスクの並列読み取りの競合を回
NetWorker 環境のサイズ設定
並列セーブ ストリームの考慮事項 29
避する場合は、同じセーブ グループを使用できます。 また、キーワード「All」を使用して単一のクライアント リソースで PSS を有効にする場合は、注意が必要です。 通常、「All」は、同じインストール ディスクに存在する複数の小さいオペレーティング ファイル システムを含めるよう拡張します。 これらのファイル システムは通常 PSS を活用せず、代わりに重要なPSS マルチ ストリーミング リソースを浪費します。
2 番目の例に基づいて、「/sp1」セーブセット レコードはマスターと呼ばれ、そのセーブセット時間が参照操作と時間ベースのリストア操作に使用されます。 これは、「*mbsdependents」属性を使用して 2 個の関連するレコード（依存物）を参照します。 この属性は、依存物の移植可能な長い形式のセーブセット ID をリストします。 各依存物は、セーブセット名と保存時間の関連づけによってそのマスターを間接的に参照します。 そのマスターは、次に長い保存時間と、プレフィックスのないセーブセット名を持つセーブセット レコードです。 また、各マスター レコードには、セーブセット時間が も早い依存物を参照する「*mbsanchor save set time」属性があります。
PSS は、セーブ ポイント/sp1 を複数のサブディレクトリ「/sp1/subdirA」、「/sp1/subdirB」などに手動で分割して、各サブディレクトリを別個にクライアント リソース内に入れる際に改善されます。 PSS は、これを行う必要性をなくし、手動によるアプローチで使用されるディレクトリ レベルではなく、ファイル レベルでよりよいロード バランシングの 適化を自動的に実行します。 PSS によって、メディア セーブセット レコード名（たとえば、「/sp1」、「<1>/sp1」、「<2>/sp1」）に対応する仮想サブディレクトリが作成されます。
時間ベースのリカバリとセーブ グループのクローン作成の両方が、セーブ ポイント PSS バックアップの複数の物理セーブセットを自動的に統合します。 依存する複数の物理セーブセットが非表示のままになります。 ただし、セーブセット ベースの recovery、scanner、nsrmm、nsrclone -S 手動コマンド ラインの使用では自動的な統合は行われません。 -S コマンド オプションでは、マスターおよび依存物の両方の PSS セーブセット ID をコマンド ラインで指定する必要があります。 ただし、-S オプションが PSS で必要になることはまれです。
次の PSS クライアント構成設定を変更する場合、次のセーブ ポイントの増分バックアップのためにセーブ ストリームの数が変更になることがあります。
u セーブ ポイントの数
u 並列化の値
NetWorker は、セーブ ストリームの数の差を自動的に検出して、それに応じてバックアップをレベル［フル］にリセットします。 これによって、PSS セーブ ポイントのバックアップごとに同じ数のメディア データベース セーブセットを持つ新しいバックアップ シーケンス<full, incr,incr, …>が開始されます。
これは、レベル 10 とも呼ばれる増分ではなく、ノン フル レベル番号 1～9 に適用されます。
前回のバックアップ以降変更されたファイル数が 0 から数ファイルのセーブ ポイントの PSS増分バックアップは、1 つ以上の空のメディア データベース セーブセット（実際のサイズは 4バイト）になりますが、これは想定の範囲内です。
例 1以下に、次のバックアップ要件と制約がある、PSS 対応クライアントのパフォーマンス構成の代替案について説明しています。
u 2 つのセーブポイント/sp200GB および/sp2000GB
u 100 GB/時でバックアップできるセーブ ストリーム
u クライアントの並列化は 4 に設定されています（ディスク IO の競合を避けるため、コンカレント ストリームの 大数は 4）
以下に、これらの要件と制約に基づく具体的な構成の代替案を、全体的なバックアップ時間は時間単位で示します。
NetWorker 環境のサイズ設定
30 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
u 両方のセーブポイントにそれぞれの 1 つのストリームがある非 PSS クライアント リソース： 20 時間
u 同じセーブ グループに対して、2 つのストリームの/sp200GB と 2 つのストリームの/sp2000GB がある 1 つの PSS クライアント リソース： 10 時間
u 1 つのストリームの/sp200GB がある非 PSS クライアント リソース、および同じクライアント ホストと同じセーブ グループに対して 3 つのストリームの/sp2000GB がある PSSクライアント リソース： 6.7 時間
u 4 つのストリームの/sp200GB がある 1 つの PSS クライアント リソースと同じクライアントとシーケンシャルにスケジュール設定された別のセーブ グループに対して 4 つのストリームの/sp2000GB がある もう 1 つの PSS クライアント リソース： 総計 5.5 時間
例 2クライアントの並列化を 8 に設定して、3 個のセーブ ポイント/sp1、/sp2、/sp3 をキーワード「ALL for UNIX」によって明示的にリストするか拡張すると、セーブ ポイント バックアップごとの PSS ストリームの数はそれぞれ 3、3、2 になります。 mminfo メディア データベース セーブセット レコードの数も、それぞれ 3、3、2 です。 特定のセーブ ポイント/sp1 では、mminfoおよび NMC セーブセットの照会結果ではそれぞれ「/sp1」、「<1>/sp1」、「<2>/sp1」という名前の 3 個のセーブセット レコードが表示されます。 これらの関連するレコードには、相互に近い一意の保存時刻があります。 「/sp1」レコードは常に、 後に開始されるため、 後の保存時刻（つまり、 大保存時刻）を持ちます。 これによって、セーブ ポイント/sp1 全体の時間ベースのリカバリ統合が自動的に機能します。
例 3PSS Windows セーブ ポイントのバックアップの場合、セーブ ポイントあたりのストリーム数は、次の 2 つのシナリオで推定されます。
u クライアントの並列化=5、セーブ ポイント数=2 のセーブ ポイントあたりのクライアントの並列化は、 初のセーブ ポイントの PSS ストリーム数が 3 で、2 番目のストリーム数は2 です。セーブセット［ALL］で、2 つのボリュームを使用し、クライアントの並列化=5 の場合、各ボリューム（セーブ ポイント）が 2 つのストリームを取得します。
u クライアントの並列化=4 を使用すると、すべてのセーブ ポイントに 2 つのセーブ ストリームが与えられます。 両方の Disaster_Recovery ボリューム、C:\および D:\にも 2 つ
のストリームが与えられます。セーブセット［ALL］の場合、Disaster_Recovery セーブセットが単一のセーブ ポイントとみなされます。 この例では、システムには C:\、D:\、および E:\,があり、C:\、およ
び D:\は、Disaster_Recovery セーブセットを構成する重要なボリュームです。
セーブ操作は、セーブ ポイントを開始する方法を制御し、ストリームの総数がクライアントの並列化の値である 4 を超えることはありません。
コマンド ラインの例
次に挙げる UNIX セーブ ポイントの例「/sp1」の PSS バックアップ後のコマンド ラインの例を検討します（Windows も類似しています）。
u /sp1 のスケジュール設定されたバックアップ後に統合されたジョブ ログ ファイル情報を表示するには、次を入力します。
# tail /nsr/logs/sg/<save group name>/<job#>…parallel save streams partial completed savetime=1374016342parallel save streams partial completed savetime=1374016339parallel save streams partial completed savetime=1374016345parallel save streams summary test.xyx.com: /sp1 level=full, 311 MB00:00:08 455 filesparallel save streams summary savetime=1374016345
NetWorker 環境のサイズ設定
並列セーブ ストリームの考慮事項 31
u すべての/sp1 full/incr バックアップのマスター セーブセットのみをリストするには、次を入力します。
# mminfo -ocntR -N "/sp1"-r "［client,name］,level,nsavetime,savetime(25),ssid,ssid(53),totalsize,n files,attrs"
u 参照時間ベースのセーブ ポイント復旧のために、「<i>/sp1」を「/sp1」セーブセットと自動的に統合するには、次の手順を実行します。
# recover [-t <now or earlier_master_ss_time] [-d reloc_dir] [-a] /sp1
PSS パフォーマンス向上機能からメリットを得るための考慮事項と推奨事項を次に示します：
u PSS 機能は、クライアントの並列化に基づいて PSS のセーブセットを複数のストリームに分割することによりバックアップ パフォーマンスを向上させます。 セーブセット内のディレクトリとファイルのサイズを極めて均等に分散することで、PSS のパフォーマンス メリットが追加されます。
u コンカレント読み取りストリームからの総スループットが十分に高速なストレージに存在する大きいセーブセットでは、PSS によって大幅に実行パフォーマンスが向上します。PSS を使用する場合は、ディスクの読み取りレーテンシーが高い低速ストレージの使用は避けます。
u PSS によって単一のセーブ ポイントが複数のセーブ ストリームに分割されるため、書き込みの競合またはターゲット デバイスのキューイングを回避するために、ターゲット デバイスが十分に高速であることを確認します。
u ターゲット デバイスが Data Domain の場合は、PSS によって DDR での 大セッション数の上限が飽和されないことを確認します。 各 Boost デバイスでは、 大 60 の同時NetWorker セッションが許可されます。
内部保守タスクの要件
保守タスクを完了するための要件によって、NetWorker ソフトウェアに大きな負荷がかかることがあります。
u 毎日行われるインデックスおよびメディア データベースの整合性チェックによって、小規模な環境では 40 IOPS、1,000 個以上のクライアントで構成されている大規模な環境では 大 200 IOPS が追加されます。
u バックアップ時間と保存時間が非常に長い（1 年以上）環境では、内部データベース大規模な増大が発生するため、 大 100～200 IOPS の要件が追加されます
u パージ操作では、1 日あたりのバックアップ ジョブが 大 1,000 個の小規模な環境に30 IOPS、中規模な環境に 100 IOPS、1 日あたりのジョブが 50,000 個の高負荷な大規模環境には 大 200 IOPS が使用されます。
レポート タスクの要件
NMC サーバ、DPA、カスタム レポート、または監視スクリプトなどの監視ツールは、NetWorker サーバに余分な負荷をかけます。
手順
u NMC サーバー 1 台につき、100 IOPS が追加されます。
u DPA のレポート作成では、250 IOPS が追加されます。
結果
カスタム レポートまたは監視スクリプトは、設計に応じて大きな負荷をかける可能性があります。 たとえば、NetWorker のインデックスおよびメディア データベースで継続的にレポート作成を行うと、 大 500 IOPS が追加される可能性があります。
NetWorker 環境のサイズ設定
32 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
手動 NetWorker サーバタスクの要件
NetWorker サーバの手動タスクによって、余分な負荷がかかる可能性があります。
u バックアップ サーバのオブジェクトを列挙する必要がある各リカバリ セッションによって、NetWorker サーバに余分な負荷がかかります。たとえば、10,000 個のバックアップ ジョブをすべて列挙するために、NetWorker サーバは 大 500 IOPS を必要とする可能性があります。
u スパイク、および無関係のオペレーティング システムの作業負荷では、計算上の IOPSの合計数が 30%増加します。
u 多くの場合、単一のディスク パフォーマンスでは大規模な NetWorker サーバには不十分です。 次の表は、単一のディスク パフォーマンスに関する詳細を示します。 より多くの IOPS を達成するには、並列アクセスのために複数のディスクを組み合わせます。 標準的なディスクの 高のパフォーマンスは、RAID 0+1 で達成されます。ただし、 新のストレージ アレイは、NetWorker サーバのランダムな作業負荷に対する RAID 5 アクセス向けに 適化されていることがよくあります。 ハードウェアベースのライトバック キャッシュでは、NetWorker サーバのパフォーマンスを大幅に向上できます。 NetWorker サーバーの IOPS 要件のガイドラインについては、次の表を参照してください。
表 6 NetWorker サーバー操作に必要な IOPS
操作のタイプ 小規模なNetWorker 環境（1）
中規模なNetWorker 環境（2）（33 ページ）
大規模なNetWorker 環境（3）（33 ページ）
コンカレント・バックアップ 30 80 170
ブートストラップ バックアップ 50 150 400
バックアップ グループの起動 50 150 250
ボリューム管理 0 0 100
大容量の NDMP バックアップ 100 100 200
標準的な毎日の保守タスク 40 75 100
大きな内部データベースの保守 0 100 200
パージ操作 50 150 300
NMC レポート作成 50 75 100
DPA レポート作成 50 100 250
リカバリ 30 200 500
（1）小規模な NetWorker サーバー環境とは、クライアントが 100 個未満か、コンカレント バックアップ セッションが 100 個ある環境です。
（2）中規模な NetWorker サーバー環境とは、クライアントが 100～400 個あるか、コンカレント バックアップ セッションが 250 個ある環境です。
（3）大規模な NetWorker サーバー環境とは、クライアントが 400 個以上あるか、コンカレント バックアップ セッションが 500 個の環境です。
IOPS に関する考慮事項
IOPS 値には、次のような考慮事項および推奨事項があります。
u NetWorker ソフトウェアではデータゾーンあたりのクライアント数は制限されませんが、大で 1,000 クライアントにすることを推奨します。これは、大規模なデータゾーンは管
NetWorker 環境のサイズ設定
内部保守タスクの要件 33
理が複雑になるため、および、NetWorker サーバのハードウェア要件が増加するためです。
NetWorker サーバの I/O 負荷が増加するほど、ストレージ レイヤーのサービス タイム
も増加します。 サービス タイムが必要な値を超えると、NetWorker サーバのパフォーマ
ンスと信頼性に直接影響します。 大サービス タイムの要件に関する情報について
は、NetWorker サーバおよびストレージ ノード ディスクへの書き込みレーテンシー（25ページ）を参照してください。
u NetWorker サーバによってデータ移動そのものが実行されます（バックアップ デバイスが NetWorker ストレージ ノードではなくサーバにある場合）。バックアップ パフォーマンスは直接影響を受けます。例 3：（34 ページ）、および例 4：（34 ページ）は、前にリストした要件に基づいています。
小規模から中規模の NetWorker データゾーン：
u 適化： 次の特性を持つ 200 個のクライアントの並列実行：
l 1 日あたり 大 1,000 個のバックアップ ジョブがある 100 個のジョブ。
l バックアップが徐々に拡張。
l 外部レポートなし。
l 重複する保守タスクなし。
u 必要 小 IOPS： 200、推奨 IOPS： 400
u 非 適化： 作業負荷は同じですが、次の条件があります。
l 大半のバックアップ ジョブが同時に開始
l 本番バックアップがブートストラップ ジョブおよび保守ジョブと重複
l 追加レポートあり
l 必要 小 IOPS： 800、推奨 IOPS：1,000大規模な NetWorker データベース：
u 適化： 次の特性を持つ 1,000 個のクライアントの並列実行：
l 1 日あたり 大 50,000 個のバックアップ ジョブがある 500 個のジョブ。
l バックアップが徐々に拡張。
l ディスクまたは大容量のテープ ボリュームへのバックアップを使用するバックアップ。
l 外部レポートなし。
l 重複する保守タスクなし。
u 必要 小 IOPS： 800、推奨 IOPS： 1,000
u 非 適化： 作業負荷は同じですが、次の条件があります。
l 大半のバックアップ ジョブが同時に開始
l 多数の小さなボリュームを使用
l 本番バックアップがブートストラップ ジョブおよび保守ジョブと重複
l 追加レポートあり
u 必要 小 IOPS： 2,000、推奨 IOPS： 2,500この例では、NetWorker 構成の違いによって、NetWorker サーバに 大 250%の余分な負荷がかかる可能性があることがわかります。 また、サイズ設定への影響として、適
NetWorker 環境のサイズ設定
34 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
切に 適化された大規模な環境は、 適化されていない中規模な環境よりも適切に動作することがわかります。
ディスク ドライブ テクノロジーの IOPS 値
ディスク ドライブのタイプは、ランダムな小さいブロックと連続した大きなブロックの IOPS 値を決定します。
次の表に、ディスク ドライブ タイプとそれに対応する IOPS 値を示します。
表 7 ディスク ドライブの IOPS 値
ディスク ドライブのタイプ デバイス 1 台あたりの値
エンタープライズ フラッシュ
ドライブ（EFD）2,500 IO/秒（ランダムな小さいブロック IO または 100 MB/秒の連続
した大きなブロックの場合）
ファイバ チャネル ドライブ
（FC ドライブ（15K RPM））
180 IO/秒（ランダムな小さいブロック IO または 12 MB/秒の連続した
大きなブロックの場合）
FC ドライブ（10K RPM） 140 IO/秒（ランダムな小さいブロック IO または 10 MB/秒の連続した
大きなブロックの場合）
SATA2 または LCFC（7,200RPM）
80 IO/秒（ランダムな小さいブロック IO または 8 MB/秒の連続した大
きなブロックの場合）
SATA ドライブ（7,200 RPM） 60 IO/秒（ランダムな小さいブロック IO または 7 MB/秒の連続した大
きなブロックの場合）
PATA ドライブ（5,400 RPM） 40 IO/秒（ランダムな小さいブロック IO または 7 MB/秒の連続した大
きなブロックの場合）
ファイル履歴の処理
NDMP によるファイル履歴の処理は、バックアップ中ではなく、バックアップ操作の 後に行われます。 これにより、アイドル時間が長くなります。
実際のファイル履歴の処理時間は、データセットのファイル数に関係なく直線状です。 ただし、処理時間は、次のようなその他のストレージ システム要因に左右されます。
u RAID タイプ
u 構成されるディスク数
u キャッシュ サイズ
u /nsr/index and /nsr/tmp をホストするためのファイル システムのタイプ
期待される結果は、1,000 万ファイルあたり 20 分です。
ファイル履歴の処理によって、バックアップ サーバに対して大量の I/O 負荷が発生し、処理中の 1 秒あたり 100～120 の I/O 動作によって IOPS 要件が増加します。 小IOPS 要件が満たされないと、ファイル履歴の処理が大幅に遅くなる可能性があります。
ネットワーク
次の複数のコンポーネントがネットワーク構成パフォーマンスに影響します。
u IP ネットワーク：インターネット プロトコルをサポートするデバイスで構成されたコンピュータ ネットワーク。ネットワーク通信の送信元と宛先を決定します。
NetWorker 環境のサイズ設定
ネットワーク 35
u ストレージ ネットワーク：テープ、ディスク、ファイル システムなどの物理ストレージがあるシステム。
u ネットワークの速度：ネットワーク経由のデータ転送速度。
u ネットワーク帯域幅：コンピュータ ネットワークの 大スループット。
u ネットワーク パス：ネットワーク内のデータ転送に使用される通信パス。
u ネットワーク コンカレント ロード。ネットワーク内にデータが配置されるポイント。 終的に帯域幅を 大化します。
u ネットワーク レーテンシー：ネットワーク内のソース デバイスとターゲット デバイス間でのデータ転送の遅延時間。
ターゲット デバイス
ストレージ タイプと接続には、ターゲット デバイス構成のパフォーマンスに影響するタイプのコンポーネントがあります。
u ストレージ タイプ：
l raw ディスクとディスク アプライアンス：
– raw ディスク ファイル システム レベルの下位にある未処理のバイナリ レベルでのハード ディスク アクセス。
– ディスク アプライアンス： サーバ、ストレージ ノード、およびソフトウェアのシステム。
l 物理テープと仮想テープ ライブラリ：
– VTL には、テープ ライブラリまたはテープ ドライバとしてストレージ コンポーネント（通常はハード ディスク ストレージ）があります。これらは、NetWorker ソフトウェアとともにストレージ メディアとして使用されます。
– 物理テープは、リムーバブル ストレージ メディアの種類です。一般的に、メディアとして磁気テープを含む、ボリュームまたはカートリッジと見なされます。
u 接続性：
l ローカル、SAN 接続：LAN または WAN から切り離されたコンピュータ ネットワーク。ディスク アレイやテープ ライブラリなどの共有ストレージ デバイスをサーバに接続するように設計されています。
l IP 接続：ストレージ デバイスには、独自の一意の IP アドレスがあります。
コンポーネントの 70%ルール
理論上の環境に基づいたメーカーのスループット仕様とパフォーマンス仕様は、実際のバックアップ環境ではほとんど達成されないか、達成できません。 コンポーネントの定格能力の70%を超えないことがベスト プラクティスです。
コンポーネント：
u CPU
u ディスク
u ネットワーク
u 内部バス
NetWorker 環境のサイズ設定
36 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
u メモリ
u ファイバ・チャネル
70%の使用率閾値を超えると、パフォーマンスと応答時間が大幅に低下します。
物理テープ ドライブおよびソリッド ステート ディスクだけがこのルールの例外で、できる限り100%に近づけて使用する必要があります。 テープ ドライブもソリッド ステート ディスクも、多用してもパフォーマンスは低下しません。
NetWorker 環境のコンポーネントNetWorker データゾーンは、複数のコンポーネントで構成されます。 次の図に、NetWorker環境での主要コンポーネントを示します。 NetWorker 環境を構成するコンポーネントおよびテクノロジーは、次のとおりです。
図 3 NetWorker データゾーン コンポーネント
データゾーン
データゾーンは、1 つの NetWorker サーバーとそのクライアント コンピューターで構成されます。 バックアップ要件が増加すると、余分なデータゾーンが追加される可能性があります。
NetWorker データゾーンあたり 1,500 個のクライアントまたは 3,000 個までのクライアント
インスタンスにすることをお勧めします。 この数は、平均的な NetWorker サーバを示すもの
で、ハード リミットではありません。
NetWorker 管理コンソール
NMC（NetWorker 管理コンソール）は、バックアップ サーバの管理に使用され、バックアップレポート機能を提供します。
NMC は、多くの場合、バックアップ サーバで実行され、バックアップ サーバに大きな負荷をかけます。 大規模な環境では、別々のコンピュータに NMC をインストールすることをお勧めします。 1 つの NMC サーバを使用して、複数のバックアップ サーバを管理できます。
NetWorker 環境のサイズ設定
NetWorker 環境のコンポーネント 37
NMC パフォーマンスを決定するコンポーネント
一部のコンポーネントが NMC のパフォーマンスを決定します。
u バックアップ サーバへの TCP ネットワーク 接続： NMC と NW サーバ間のすべての通信は TCP 経由で行われ、高速かつ低レーテンシーのネットワーク接続が必要です。
u メモリ： 大規模な環境でのデータベース タスクはメモリを大量に消費するため、NMC サーバに十分なメモリが搭載されていることを確認します。
u CPU NMC サーバが複数のユーザーに使用される場合、各ユーザーに十分な CPU タイム スライスを提供できるだけの十分な CPU 能力があることを確認します。
NMC サーバの 小システム要件
メモリ、利用可能なディスク領域、JRE および Web Start は、NMC サーバーに特有の 小要件を満たす必要があります。
u メモリ：1 GHz 以上のプロセッサと 512 MB の RAM が必要です。 レポートを実行するには、さらに 512 MB の RAM を追加します。
u 利用可能なディスク領域：デュアル コア 2 GHz のプロセッサと 2 GB の RAM。複数ユーザーを使用する大規模ななコンソール データベース用ディスク領域のバッファが備えられています。
u JRE および Web Start：55 MB。NetWorker 監視対象サーバの数が増加するほど、プロセッサ容量も増加します。
l サーバが 50 台の場合： デュアル 1 GHz のプロセッサ、2 GB 以上の RAM
l サーバが 100 台の場合： デュアル 1 GHz のプロセッサ、4 GB 以上の RAM
l サーバが 200 台の場合： クワッド 1 GHz のプロセッサ、8 GB 以上の RAM
コンソール データベース
式を使用して、コンソール データベースのサイズと必要な容量を見積ります。
NetWorker Management Console データベースのサイズを見積もる際の式
コンソール サーバーは、社内の NetWorker サーバーからデータを収集し、そのローカル コンソール データベースにデータを保存します。
デフォルトで、データベースは空き領域が 大のローカル ファイル システムにインストールされます。 これらの情報が統合されて処理され、トレンド解析、容量計画、問題検出に役立つレポートが生成されます。 レポートの詳細については、「NetWorker 管理者ガイド」を参照してください。
収集されたデータを保存するには、コンソール データベースに十分なディスク領域を割り当てます。 以下のようないくつかの要素によって、必要なディスク容量は異なります。
u 監視されてレポートが生成される NetWorker サーバーの数
u 各サーバによって実行されるセーブ グループの数
u セーブ グループが実行される頻度
u レポートのデータが保存される期間（データの保存ポリシー）
NetWorker 環境のサイズ設定
38 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
必要なディスク容量は保存される履歴データの量と直接関係があるので、この要件は
0.5GB～数 GB の範囲で大きく異なります。 ハードウェア要件を計画する場合は、このこ
とを念頭に置いてください。
コンソール データベースの情報に必要な容量を見積もる際の式
データのタイプごとに必要な容量およびすべてのデータに必要な容量の合計を見積もるために使用する、既存の式があります。
セーブセット メディア データベース
セーブセット メディア データベースに必要な容量を見積もるには、1 週間のセーブセット量に次の数を掛け合わせます。
u コンソールによって監視される NetWorker サーバーの数
u セーブセット出力ポリシーで定義されている週の数これにより、セーブセットを正常に実行するために要した時間が求められます。 バックアップされたファイルの数、およびオペレーション中に保存されたデータの量も示されます。
セーブセット出力
セーブセット メディア データベースに必要な容量を見積もるには、1 週間の出力メッセージ数に次の数を掛け合わせます。
u コンソールによって監視される NetWorker サーバーの数
u セーブセット出力の保存ポリシーこれにより、実行が試みられたグループおよびセーブセットの数と、その成否が示されます。
セーブ グループ完了データ
セーブセット メディア データベースに必要な容量を見積もるには、1 週間のセーブグループ量に次の数を掛け合わせます。
u コンソールによって監視される NetWorker サーバーの数
u 完了データの保存ポリシーで定義されている週の数この結果を基に、バックアップの問題をトラブルシューティングできます。
NetWorker サーバー
NetWorker サーバーは、データゾーン内の NetWorker クライアント コンピューターにデータのバックアップおよびリカバリのサービスを提供します。 NetWorker サーバはストレージ ノードとしても機能し、複数のリモート ストレージ ノードを制御できます。
インデックスとメディア管理の操作は、NetWorker サーバの主要な処理です。
u セーブセットに属するファイルは、クライアント ファイル インデックスによってトラッキングされます。 各クライアントにクライアント ファイル インデックスが 1 つあります。
u メディア データベースによって、次のものがトラッキングされます。
l ボリューム名
l 物理メディア上の各セーブセット フラグメントの場所（ファイル番号/ファイル レコード）
l ボリューム上のセーブセットのバックアップ日付
NetWorker 環境のサイズ設定
NetWorker サーバー 39
l 各セーブ セットのファイル システム
u クライアント ファイル インデックスとは異なり、サーバごとのメディア データベースは 1つだけです。
u クライアント ファイル インデックスとメディア データベースは、時間の経過とともに非常に大きくなり、バックアップ パフォーマンスに悪影響を及ぼす場合があります。
u NetWorker サーバはすべてのバックアップ操作のスケジュールとキューイング、リアルタイム バックアップのトラッキング、関連するアクティビティおよびすべての NMC 通信のリストアを行います。 この情報は jobsdb データベースに制限された時間保存され、リアルタイム操作の場合、バックアップ サーバに も重要なパフォーマンス インパクトを与えます。
このデータベースに格納されたデータは、リストア操作には必要ありません。
バックアップ サーバのパフォーマンスを決定するコンポーネント
nsrmmdbd では、数千単位のセーブセットを単一の操作で処理する場合に、CPU に負荷がかかる操作が使用されます。 したがって、大きなセーブセットを使用したクローン作成操作およびすべての NetWorker のメンテナンス アクティビティを、プライマリ バックアップ ウィンドウの外で実行する必要があります。
次のようなコンポーネントによって、NetWorker サーバのバックアップ パフォーマンスが決定されます。
u NetWorker サーバの 64 ビット システムを使用します。
u NetWorker サーバの現在のハードウェアを使用します。 たとえば、現在のバージョンのNetWorker サーバ ソフトウェアは、10 年以上前に作られたハードウェア上では適切に動作しません。
u 数多くのカレント バックアップ/クローン/リカバリ ストリームなどによって高い負荷が発生するときに、NetWorker 上で、システム リソースを大量に消費する次の操作を 小化します。
l nsrim
l nsrck
u NetWorker サーバのホストに使用されるディスク（/nsr）：通常、NetWorker サーバの作業負荷は、数多くの小さな I/O 動作から成ります。 ピーク帯域幅があるにもかかわらず、高レーテンシーのディスクのパフォーマンスが低いのはこのような理由によります。 大規模な環境にあるバックアップ サーバでは、レーテンシー レートが高いことが、 も一般的なボトルネックとなります。
u ソフトウェア レイヤーを追加すると、ストレージ レーテンシーが増加するため、追加しないようにします。 たとえば、アンチウイルス ソフトウェアは、NetWorker データベース（/nsr）を除外リストに入れて構成する必要があります。
u レプリケーション テクノロジーを使用すると、大幅にストレージ レーテンシーが増加するため、慎重に計画して使用します。
u 大規模なサーバがすべての内部データベース タスクを完了するのに十分な CPU 能力があることを確認します。
u 少数の高パフォーマンス CPU を使用するシステムは、多数の低パフォーマンス CPU を使用するシステムよりもパフォーマンスが高いため、使用する CPU は少なくします。
u 数多くの高パフォーマンス テープ ドライブまたは AFTD デバイスを、バックアップ サーバに直接接続しないでください。
u すべての内部データベース タスクを完了するのに十分なメモリがサーバ上にあることを確認します。
NetWorker 環境のサイズ設定
40 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
u ストレージ ノードとして機能する必要があるクライアントについては、可能な場合は、バックアップ サーバにデータを直接保存することによって、専用ストレージ ノードにバックアップの負荷を移します。
大規模な環境では、ストレージ ノードを処理することによって、システム負荷が大きくな
ります。 エンタープライズ環境では、バックアップ サーバで内部データベース（インデッ
クスおよびブートストラップ）のみをバックアップする必要があります。
NetWorker ストレージ・ノード
NetWorker ストレージ ノードを使用すると、バックアップまたはリカバリ操作に関連する大量のデータ移動の負担を NetWorker サーバーから軽減することによってパフォーマンスを改善できます。 NetWorker ストレージ ノードには、ローカル クライアントからのデータ転送、またはネットワーク クライアントからターゲット デバイスへのデータ転送を管理するために、高I/O 帯域幅が必要です。
ストレージ ノードのパフォーマンスを決定するコンポーネント
一部のコンポーネントは、次のようにストレージ ノードのパフォーマンスを決定します。
u バックアップの保存に使用されるターゲット デバイスのパフォーマンス。
u システムへの接続。 たとえば、TCP ネットワークのバックアップに使用されるストレージノードは、クライアントからデータを受信することができるのと同じ速度でのみデータを保存できます。
u I/O 帯域幅: 各ストレージ ノードによって利用可能なシステム帯域幅が使用されるため、十分な I/O 帯域幅があることを確認します。 そのため、すべてのデバイスのバックアップ パフォーマンスは、システムそのものの I/O 帯域幅によって制限されます。
u CPU 大量のデータを送受信するのに十分な CPU があることを確認します。
u ステージングおよびバックアップ操作が ATA または SATA ドライブを使用する VTL または AFTD ソリューションと重複しないようにしてください。 アレイのパフォーマンスに関係なく、ATA テクノロジーを使用すると、並列読み取りおよび書き込みストリームでパフォーマンスが大幅に低下します。
NetWorker クライアント
NetWorker クライアント コンピューターは、自身のデータをバックアップする必要のあるコンピューターです。 NetWorker コンソール サーバー、NetWorker サーバー、および NetWorkerストレージ ノードも NetWorker クライアントです。
NetWorker クライアントでは、ミッション クリティカルなデータを保持しており、リソースを大量に消費します。 NetWorker クライアント上のアプリケーションによって、CPU、ネットワーク、および I/O リソースが主に使用されます。 クライアントで実行される読み取り操作にのみ、追加処理は必要ありません。
クライアント速度は、ポイント イン タイムの特定クライアント バックアップのすべてのアクティブ インスタンスによって決定されます。
NetWorker クライアントのパフォーマンスを決定するコンポーネント
次のようなコンポーネントによって、NetWorker クライアントのパフォーマンスが決定されます。
u クライアント バックアップは、リソースを大量に消費する操作であり、プライマリ アプリケーションのパフォーマンスに影響を及ぼします。 アプリケーション向けにシステムのサイズを設定するときは、バックアップおよび関連する帯域幅の要件を考慮してください。 ま
NetWorker 環境のサイズ設定
NetWorker ストレージ・ノード 41
た、クライアント アプリケーションでは大量の CPU および I/O リソースが使用されるため、バックアップも遅くなります。NetWorker クライアントに十分なリソースがない場合は、バックアップ パフォーマンスとアプリケーション パフォーマンスの両方に悪影響があります。
u 数百万単位のファイルがある NetWorker クライアント。 ほとんどのバックアップ アプリケーションはファイル ベース ソリューションのため、ファイル システムによって作成されたすべてのファイルの処理に多くの時間がかかります。 このことは、NetWorker クライアントのバックアップ パフォーマンスに悪影響を及ぼします。 次に例を挙げます。
l 両方とも 100 GB のセーブセットを生じますが、20 KB のファイル 500 万個のフル バックアップにかかる時間は、200 KB のファイル 50 万個のバックアップよりも長くなります。
l 変更されるデータの全体的な量が同じ場合、100 MB のファイル 1,000 個で 50 個のファイルを変更する増分/差分バックアップにかかる時間は、1 MB のファイル 10万個で 50 個のファイルを変更する場合よりも短くなります。
u 暗号化および圧縮は、NetWorker クライアント上のリソースを大量に消費する操作であり、バックアップ パフォーマンスに大きな影響を及ぼす場合があります。
u バックアップ データは、ターゲット ストレージに転送され、バックアップ サーバで処理される必要があります。
l クライアント/ストレージ ノードのパフォーマンス：
– ローカル ストレージ ノード： 共有メモリを使用し、追加のオーバーヘッドは必要ありません。
– リモート ストレージ ノード： 受信パフォーマンスはネットワーク コンポーネントによって制限されます。
l クライアント/バックアップ サーバの負荷：バックアップ サーバのサイズがかなり小さく設定されなければ、通常はクライアントバックアップ パフォーマンスは遅くなりません。
NetWorker データベース
NetWorker データベースのサイズは複数の要因で決定されます。
それらの要因は、NetWorker データベースのボトルネック（48 ページ）で参照できます。
オプションの NetWorker アプリケーション モジュール
NetWorker アプリケーション モジュールは、特定のオンライン バックアップ タスクに使用されます。
アプリケーション バックアップのパフォーマンスを向上させるには、追加でアプリケーション側のチューニングを行う必要がある場合があります。 詳細については、該当するNetWorker モジュールのマニュアルを参照してください。
仮想環境
NetWorker クライアントは、従来のバックアップまたは VADP のいずれかの仮想マシン向けに作成できます。
さらに、NetWorker ソフトウェアは自動的に仮想環境およびこれらの環境への変更を定期的にまたはオンデマンドで検出して、これらの環境をグラフィカルに表示します。
NetWorker 環境のサイズ設定
42 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
NetWorker 重複排除ノード
NetWorker 重複排除ノードとは、重複排除したバックアップ データを保存する EMCAvamar®サーバーです。
重複排除ノードへの 初のバックアップは、フル バックアップにする必要があります。 それ以降のバックアップでは、Avamar インフラストラクチャによって、ソースで重複するデータ セグメントが識別され、変更を含むファイル全体ではなく、一意のセグメントのみがバックアップされます。 これにより、バックアップの実行に要する時間、および NetWorker 管理コンソールのバックアップで使用するネットワーク帯域幅とストレージ領域の両方が削減されます。
リカバリ パフォーマンスの要因リカバリ パフォーマンスは、ネットワーク トラフィック、ボトルネック、大容量ファイル、その他の要因によって低下する場合があります。
リカバリ パフォーマンスについて、次のような考慮事項があります。
u ファイルベースのリカバリ パフォーマンスは、バックアップ サーバ、特にクライアント ファイル インデックスのパフォーマンスに影響されます。 クライアント ファイル インデックスに関する情報については、NetWorker サーバー（39 ページ）を参照してください。
u も速く効率的にデータをリカバリする方法は、セーブセット リカバリを使用して同時に複数のリカバリ コマンドを実行することです。 たとえば、3 つのセーブセット リカバリ操作を使用すると、指定されたプロセス数、ボリューム、およびセーブセット レイアウトに
大限可能な並列化が実現されます。
u 同じテープから複数のリカバリ操作が同時に実行される場合は、すべてのリカバリ リクエストの準備が整うまで、テープのマウントと開始は行われません。 すべてのリクエストの準備が整う前にテープが使用されると、テープは複数回読み取られ、リカバリ パフォーマンスが低下します。
u テープへのバックアップをマルチプレクシングすると、リカバリ パフォーマンスが低下します。
接続およびボトルネックバックアップ環境は、システム、ストレージ、ネットワーク、およびターゲット デバイス コンポーネントのさまざまなデバイスで構成されています。それぞれに対応するさまざまなベンダーのモデルが数百あります。
接続に関するパフォーマンスに影響する要因は、次のとおりです。
u コンポーネントはスタンドアロン デバイスとして適切に動作できますが、チェーン上の他のデバイスと適切に連動することによって、 適な構成が実現されます。
u チェーン上のコンポーネントは相互に通信できないと、役立ちません。
u バックアップは大量のデータを使用する操作であり、大量のデータが生成される可能性があります。 ビジネス ニーズを満たすために、 適な速度でデータを転送する必要があります。
u チェーン内で も遅いコンポーネントが、ボトルネックと見なされます。次の図のネットワークでは、コンポーネントと同じ量のデータを集約して送信することはできません。 このため、ネットワークがボトルネックとなり、バックアップ プロセス全体の速度が低下します。 ハブ、スイッチ、NIC など、チェーン上にあるすべての個々のネットワーク デバイスは、ボトルネックとなって操作全体の速度低下の原因となる可能性があります。
NetWorker 環境のサイズ設定
NetWorker 重複排除ノード 43
図 4 ネットワーク デバイスのボトルネック
次の図に示すように、ネットワークを 100 baseT ネットワークから GigE ネットワークにアップグレードすると、ボトルネックは別のデバイスに移動します。 ホストは、ここでは利用可能なネットワーク帯域幅を使用するのに十分な速さでデータを収集できません。 システムのボトルネックは、CPU、メモリ、またはその他のリソースの不足に起因する可能性があります。
NetWorker 環境のサイズ設定
44 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
図 5 更新されたネットワーク
次の図に示すように、ボトルネックを除去するために NetWorker クライアントをより大規模なシステムにアップグレードします。 システムが改善され、ネットワーク帯域幅が増加したことによって、ボトルネックがターゲット デバイスになりました。 テープ デバイスのパフォーマンスは、多くの場合、他のコンポーネントよりも低くなります。 テープ デバイスのパフォーマンスは、次のような要因によって制限されます。
u SCSI の帯域幅が限られている
u テープ ドライブの 大パフォーマンスに達しているファイバ チャネル ベースのドライブなど、より高パフォーマンスのテープ デバイスを導入することによって、ターゲット デバイスのパフォーマンスを向上します。 また、SAN 環境を使用することによっても、パフォーマンスを大幅に向上できます。
NetWorker 環境のサイズ設定
接続およびボトルネック 45
図 6 更新されたクライアント
次の図に示すように、パフォーマンスがより高い、SAN 上のテープ デバイスによって、ボトルネックが除去されます。 現在、ボトルネック デバイスはストレージ デバイスです。ローカル ボリュームは 適な速度で実行されていますが、利用可能なシステム、ネットワーク、およびターゲット デバイス リソースを使用することはできません。 ストレージのパフォーマンスを向上させるには、データ ボリュームを高パフォーマンスの外部 RAID アレイに移動します。
NetWorker 環境のサイズ設定
46 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
図 7 専用 SAN
ローカル ボリュームは 適な速度で実行されていますが、利用可能なシステム、ネットワーク、およびターゲット デバイス リソースを使用することはできません。 ストレージのパフォーマンスを向上させるには、データ ボリュームを高パフォーマンスの外部 RAID アレイに移動します。
次の図に示すように、外部 RAID アレイによってシステム パフォーマンスが向上しています。 RAID アレイはチェーン内の他のコンポーネントとほぼ同様に動作し、パフォーマンスの達成目標を満たしています。 ボトルネックは常にありますが、すべてのデバイスがチェーン内の他のデバイスとほぼ同じレベルで動作しているため、ボトルネック デバイスの影響は限られます。
NetWorker 環境のサイズ設定
接続およびボトルネック 47
図 8 RAID アレイ
このセクションでは、パフォーマンスを向上するためにすべてのコンポーネントをアップグレ
ードする必要があると示唆するものではなく、ボトルネックの概念を説明するために、デバイ
スが、チェーン内の他のデバイスと同等の速度で動作することの重要性を強調しています。
NetWorker データベースのボトルネック
NetWorker データベースのサイズを決定する複数の要因があります。
u NetWorker リソース データベース/nsr/res または［networker install dir］/res： 構成されるリソースの数。
u NetWorker ジョブのデータベース（nsr/res/jobsdb）： バックアップ、リストア、クローン作成などのジョブの数に、保存用に設定された日数を乗算した数。 大規模な環境では100,000 レコードを超えることがあり、パフォーマンスの主なボトルネックの 1 つです。全体的なサイズは重要ではありません。
u NetWorker メディア データベース（nsr/mm）： 保存中のセーブセットの数およびラベル付けされたボリュームの数。 大規模な環境では、これは数ギガバイトのデータになることがあります。
u NetWorker クライアント ファイル インデックス データベース（nsr/index）： インデックスが付けられたファイルの数およびブラウズ ポリシー内のファイルの数。 通常はこれが大の NetWorker データベースです。 ストレージのサイズ設定には、次の計算式を使用します。インデックス カタログ サイズ= {[(F+1)*N] + [(I+1) * (DFCR*N)]} * [(1+G)*C]
この場合、
F = 4（4 週間に設定された全参照期間）
NetWorker 環境のサイズ設定
48 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
N = 1,000,000（この例の 100 万ファイル）
I = 24（増分バックアップの 4 週間の参照期間 - フル バックアップ）
DFCR = 3%（標準ユーザー ファイル データの毎日のファイル変更率）
G = 25%（推定年間増加率（%））
C = 160 バイト（ファイルあたりのバイトの定数）
次に例を挙げます。
{[(4+1)*1,000,000] + [(24+1) * (3%*1,000,000)]} * [(1+.25)*160]
{5,000,000 + [25 * 30,000)} * [1.25 * 160]
5,750,000 * 200 バイト= 1,150,000,000 バイト= 1150 MB
インデックス データベースは複数の場所に分割できます。場所はクライアント単位で決
定されます。
次の図に、NetWorker メディア データベースがあるディスクのパフォーマンスがボトルネックの場合の、全体的なパフォーマンスの低下を示します。 右側の図のグラフは正味のデータの書き込みスループット（セーブセット+インデックス+ブートストラップ）を示し、左側のグラフはセーブセットの書き込みスループットです。
図 9 NetWorker サーバの書き込みスループットの低下
NetWorker 環境のサイズ設定
NetWorker データベースのボトルネック 49
NetWorker 環境のサイズ設定
50 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
第 3 章
チューニング設定
NetWorker ソフトウェアには、バックアップ環境の調整およびバックアップおよびリストア パフォーマンスの 適化に使用できるさまざまな 適化機能があります。
u NetWorker の並列化の 適化...............................................................................52u ファイル システムの密度........................................................................................53u ディスクの 適化.................................................................................................. 54u デバイスのパフォーマンスのチューニング方法.......................................................54u ネットワーク デバイス.............................................................................................55u ネットワークの 適化............................................................................................ 60
チューニング設定 51
NetWorker の並列化の 適化適なパフォーマンスを確保するためにサーバー、グループ、およびクライアントの並列化
に関する一般的なベスト プラクティスに従います。
サーバの並列処理
サーバの並列化属性では、サーバが同時に受け入れるセーブ ストリームの数を制御します。 サーバが受け入れることのできるセーブ ストリームの数が多いほど、デバイスやクライアント ディスクの実行が速くなります。 クライアント ディスクは、パフォーマンスまたは接続の上限で実行できます。
サーバの並列化は、バックアップ ジョブの起動の制御には使用されませんが、バックアップサーバが受け入れるセッションの 終的な制限として使用されます。 サーバの並列化の値は、バックアップ サーバ自体を過負荷にせずに、できるだけ高く設定する必要があります。
クライアントの並列化
クライアントの並行化の設定が NetWorker サーバーに対して低すぎると、多くの場合、バックアップの遅延が発生するため、適切なクライアントの並行化の値は重要です。
クライアントの並列化の値は、次のように設定するのが 適です。
u 通常のクライアントでは、セーブセット数とスループットのバランスが 適になるように、使用する並行化の設定はできるだけ低くします。
u バックアップ サーバでは、インデックス バックアップが遅延しないように、クライアントの並行化の値をできるだけ高く設定します。 これによって、グループが適切に実行されます。NetWorker クライアントのパフォーマンスを 適化するには、クライアントの並行化を排除して 1 に削減し、クライアントのハードウェア構成とデータ構成に基づいて並行化を増やすのが 適です。
インデックス バックアップがグループの完了を妨げないように NetWorker サーバで並行化が十分に行われることが重要です。
NetWorker サーバを示すクライアントの並行化の値は、次のように設定します。
u 並行化を 1 に設定しないでください。
u 小規模な環境（サーバが 30 台未満）では、並行化を 8 以上に設定します。
u 中規模な環境（サーバが 31～100 台）では、並行化を 12 以上に設定します。
u 大規模な環境（サーバが 100 台以上）では、並行化を 16 以上に設定します。これらの推奨事項は、バックアップ サーバが専用バックアップ サーバであることを前提としています。 バックアップ サーバは、 適なパフォーマンスを実現するために常に専用サーバである必要があります。
グループの並行化
グループの並行化の適切な値により、オペレーティング システムの 適なパフォーマンスが確保されます。
グループの並列化の値は、次の用に設定するのが 適です。
u グループの並列化が適用される、50 クライアントまでのセーブ グループを作成します。50 クライアントを超える大規模なセーブ グループでは、数多くのオペレーティング システム プロセスが同時に開始されるため、一時的にオペレーティング システムのリソースが不足する可能性があります。
チューニング設定
52 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
u セーブ グループの開始時刻を少しずつずらして、オペレーティング システムの負荷を軽減します。 たとえば、200 個のクライアントがあるセーブ グループ 1 つよりも、5 分間隔で開始する 50 個のクライアントがあるセーブ グループ 4 つのほうが適切です。
多重化
ターゲット セッション属性によって、デバイスに書き込む同時セーブ ストリームのターゲット数が設定されます。 この値は上限ではないため、デバイスがターゲット セッション属性の指定値より多くのセッションを受信することがあります。 ターゲット セッションに指定するセッション数が多いほど、多くのセーブセットが同じボリュームにマルチプレクシング（またはインターリーブ）されます。
デバイスのターゲット セッションの補足情報については、ATFD デバイスのターゲット セッション数と 大セッション数（58 ページ）を参照してください。
システムのマルチプレクシングが適切かどうかを判定するには、パフォーマンス テストと評価を実行します。 マルチプレクシングの使用を評価するときは、次のガイドラインに従います。
u 各デバイスの 大速度を調べます。 bigasm ディレクティブ（72 ページ）で説明されている bigasm テストを使用します。
u クライアントの各ディスクのバックアップ速度を調べます。 uasm ディレクティブ（72 ページ）で説明されている uasm テストを使用します。バックアップに関与するすべてのディスクのバックアップ速度の合計が、デバイスの大速度より大きい場合は、サーバの並列化を増やさないようにします。 この場合、マルチプレクシングするセーブ グループを多くすると、バックアップのパフォーマンスが改善されず、リカバリのパフォーマンスが低下することがあります。
ファイル システムの密度ファイル システムの密度は、バックアップ スループットに直接影響します。
特に、数多くの小さいファイルがある場合は、ファイル システムの密度に応じて NetWorkerセーブ操作にかなりの時間がかかります。 高密度のファイル システムでの NetWorker パフォーマンスは、ディスク レーテンシー、ファイル システム タイプ、およびセーブセット内のファイル数に影響されます。 次の図に、ファイル システムの密度がバックアップ スループットに及ぼす影響のレベルを示します。
図 10 ファイルとスループット
チューニング設定
多重化 53
ディスクの 適化NetWorker リリース 8.0 では、標準的なファイル システムのバックアップ中における、クライアントからのデータの読み取りパフォーマンスを 適化する新機能が採用されています。
NetWorker 7.6 以前ではクライアントからファイルを読み取る際に固定の 64 KB ブロックを使用しますが、NetWorker 8.0 ではインテリジェントなアルゴリズムを使用し、クライアント システムの現在の読み取りパフォーマンスに基づいて 64 KB から 8 MB の範囲で 適なブロック サイズを選択します。 実際のデータ転送時にこのブロック サイズの選択が行われ、バックアップ プロセスにオーバーヘッドが追加されません。また、場合によってはディスクの読み取りパフォーマンスが大幅に向上します。
読み取りブロック サイズは、バックアップに使用されるデバイス ブロック サイズとは無関係
で、変更されません。
この機能は、残りのバックアップ プロセスに対して透過的で、構成を追加する必要はありません。
NSR_READ_SIZE 環境変数を希望の値に設定すると、動的ブロック サイズを上書きできます。 たとえば、NSR_READ_SIZE=65536 に設定すると、NetWorker ソフトウェアは読み取りプロセス中に 64 KB のブロック サイズを使用するようになります。
デバイスのパフォーマンスのチューニング方法デバイスの特定領域の処理によりパフォーマンスを改善できます。
入出力の転送速度
I/O レートは、データをデバイスに書き込む速度です。 デバイスの転送速度は、デバイスとメディアの規格によって異なり、毎秒 500 KB～200 MB の範囲になります。
デバイスのデフォルトのブロック サイズとバッファ サイズが、デバイスの転送速度に影響します。 I/O の制約が NetWorker サーバーのパフォーマンスに支障をきたす場合は、転送速度が高速なデバイスにアップグレードしてください。
組み込みの圧縮機能
デバイスの実効スループットを向上するには、デバイスの圧縮機能をオンにします。
一部のデバイスには、ハードウェアによる圧縮機能が組み込まれています。 バックアップデータを圧縮できる程度に応じて、データの実効スループットが 1.5:1～3:1 の割合で改善されます。
ドライブのストリーミング
ほとんどのデバイスでは、ピークのパフォーマンスを達成するために、 大の持続的スループットでドライブのストリーミングを実行します。
ドライブのストリーミングを実行しない場合は、ドライブを停止し、バッファがいっぱいになるまで待機するか、またはメディアの位置を調整してから書き込みを再開する必要があります。 これは、デバイスによっては、ドライブのサイクル時間が遅れる原因になります。
チューニング設定
54 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
デバイスの負荷を均等にする
デバイスあたりのターゲット セッションおよび 大セッションを調整して、同時セッションによるデータ負荷がデバイス間で均等に分散されるようにします。
このパラメーターに指定した 小値より多くのセーブ セッションが確立されると、NetWorkerサーバーは、セーブ セッションを別のデバイスに割り当てようとします。 デバイスのターゲット セッションおよび 大セッションの詳細については、ATFD デバイスのターゲット セッション数と 大セッション数（58 ページ）を参照してください。
ディスク ドライブのフラグメント化
Windows クライアント上のファイル システムがフラグメント化されていると、フラグメンテーションの量によってパフォーマンスが大幅に低下する場合があります。 パフォーマンスの低下を避けるためにディスクのデフラグメンテーションを行います。
手順
1. NetWorker を使用しないコピーまたは FTP 操作を使用して、ディスクのフラグメンテーションに問題がないかどうかを判断し、クライアント上のファイル システムのパフォーマンスを確認します。
2. クライアント上で［ディスク デフラグ ツール］ツールを実行して、ディスクのパフォーマンス効率が向上するように、データを統合します。
a. クリックして［ディスク デフラグ ツール］を開きます。
b. ［現在のステータス］の下で、デフラグメンテーションするディスクを選択します。
c. ［ディスクの分析］をクリックして、フラグメンテーションに問題がないか確認します。管理者パスワードの入力や確認を求められた場合は、パスワードを入力するか、確認を行います。
d. Windows でディスクの分析が終了したら、［前回の実行］列でディスクのフラグメンテーション率を確認します。 数値が 10%以下の場合は、ディスクをデフラグメンテーションします。
e. ［ディスクのデフラグ］をクリックします。 管理者パスワードの入力や確認を求められた場合は、パスワードを入力するか、確認を行います。
デフラグメンテーションの完了には数分から数時間かかることがあります。ハード ディスクのサイズとフラグメンテーションの程度によって異なります。 デフラグメンテーション プロセス中もコンピュータを使用できます。
ネットワーク デバイスリモート クライアント、ルーター、ネットワーク ケーブル、およびネットワーク インターフェイスカードからバックアップされたデータは、バックアップおよびリカバリ操作に影響する場合があります。
このセクションでは、ネットワーク ハードウェアに関連するパフォーマンス変数をリストし、ネットワークの基本的なチューニングをいくつか示します。 次の項目で、特定のネットワークの問題について説明します。
u ネットワーク I/O の帯域幅：ネットワーク経由の 大データ転送速度は、ネットワーク プロトコルのオーバーヘッドのため、メーカーの仕様に近い値を示すことはほとんどありません。
チューニング設定
デバイスの負荷を均等にする 55
次のステートメントは、ネットワーク帯域幅を扱う際に考慮する必要があるシステムのサ
イズ設定全体に関するものです。
接続されている各テープ ドライブ（物理 VTL または AFTD）は、利用可能な I/O 帯域幅を使用し、データを処理する必要があるため CPU も消費します。
u ネットワーク パス：ルータ、ブリッジ、ハブなどのネットワーク コンポーネントは、オーバーヘッド帯域幅の一部を消費します。このため、ネットワークのスループットのパフォーマンスが低下します。
u ネットワークの負荷：
l 各 IP によって大量の CPU リソースが使用されるため、NetWorker サーバに多数の高速 NIC を直接接続しないでください。 たとえば、1 GB の NIC 4 つを備えた中規模のシステムでは、バックアップ中に TCP データの処理に 50%以上のリソースを使用します。
l NetWorker サーバーに使用できる帯域幅は、他のネットワーク トラフィックによって制限され、バックアップのパフォーマンスが低下します。 ネットワークの負荷が飽和に達すると、データ パケットの衝突によって、さらにパフォーマンスが低下します。
l nsrmmdbd では、数千単位のセーブセットを単一の操作で処理する場合に、CPU に負荷がかかる操作が使用されます。 したがって、大きなセーブセットを使用したクローン作成操作および NetWorker のメンテナンス アクティビティを、プライマリ バックアップ ウィンドウの外で実行する必要があります。
ファイバ チャネル レーテンシー
リンク レーテンシーの影響を軽減するには、NetWorker ボリュームのブロック長を大きくします。
ボリュームのブロック長を大きくすると、往復の ACK を頻繁に必要とすることなく、データがデバイスに送られます。
低レーテンシー リンクでは、ブロック長を大きくしても効果はありません。
高レーテンシー リンクでは、ローカル リンクと同じレベルのパフォーマンスは得［られません］
が、大きな効果が見込めます。
データの遅い原因がレーテンシーの場合は、広帯域幅で直接的にパフォーマンスは向上し
ません。
次の表に、15 KM 8 Gb DWDM リンク経由でローカルに接続された LTO-4 物理テープ ドライブのさまざまなブロック サイズ例を示します。
チューニング設定
56 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
表 8 LTO-4 テープ ドライブのブロックサイズの効果
ブロックサイズ ローカルのバックアップ パフォーマンス
リモートのバックアップ パフォーマンス
64K 173 MB/秒 60 MB/秒
128 KB 173 MB/秒 95 MB/秒
256 KB 173 MB/秒 125 MB/秒
512 KB 173 MB/秒 130 MB/秒
1,024 KB 173 MB/秒 130 MB/秒
次の図に、遅延が 0.001～2.0 ミリ秒に設定されている場合に NetWorker バックアップ スループットが 100%から 0%に低下する図を示します。
図 11 ファイバ チャネル レーテンシーがデータ スループットに及ぼすインパクト
DataDomainDataDomain ストレージへのバックアップは、複数のテクノロジーを使用することによって構成できます。
u NetWorker 8.1 以降では、ファイバ チャネル経由の DDBoost がサポートされます。 この機能では、SAN インフラストラクチャのブースト プロトコルのメリットを活用しています。この機能により、次のメリットがもたらされます。
l クライアント ダイレクトを使用した DFC（ファイバ チャネル経由の DDBoost）バックアップは、DD VTL を使用したバックアップと比較して 20～25%高速です。
l 次回以降のフル バックアップは、初回のフル バックアップよりも 3 倍高速です。
l DFC 経由のリカバリは、DD VTL を使用したリカバリよりも 2.5 倍高速です。
u VTL へのバックアップ：NetWorker デバイスはテープ デバイスとして構成され、ファイバ チャネル経由でデータ転送が行われます。
VTL の 適化に関する情報については、仮想デバイス ドライブと物理デバイス ドライブの数（60 ページ）を参照してください。
チューニング設定
DataDomain 57
u CIFS または NFS 経由の AFTD へのバックアップ：
l ネットワーク全体のスループットは、ネットワーク構成に依存する CIFS および NFS のパフォーマンスによって変わります。CIFS または NFS 経由の AFTD へのバックアップに関するベスト プラクティスについては、ネットワークの 適化（60 ページ）を参照してください。
l 基本となる転送が非効率だと、バックアップ パフォーマンスがリンク速度の 70～80%に制限されます。 適なパフォーマンスを実現するには、NetWorker リリース7.5 サービス パック 2 以降が必要です。
u NetWorker 8.0 で採用されている DFA（ダイレクト ファイル アクセス）を有効化するための Client Direct 属性：
l Boost を使用した DD（Data Domain）への Client Direct は、CIFS/NFS を使用したDFA-AFTD よりも優れたパフォーマンスを実現します。
l Client Direct が有効なバックアップ パフォーマンス（DFA-DD/DFA-AFTD）は、mmd を使用した従来のバックアップよりも 20～60%高速です。
l 1 台のデバイスへのストリーム数の増加に伴い、DFA は mmd よりも多くのバックアップ ストリームを処理します。
u ネイティブ デバイス タイプを使用した DataDomain へのバックアップ：
l NetWorker 7.6 サービス パック 1 には、TCP/IP リンク経由での Data Domain ストレージへのネイティブな通信に特化して設計された新しいデバイス タイプが用意されています。
l ネットワークを適切に 適化することによって、このプロトコルは 10 Gb/秒の速度でもリンク速度の 大 95%を使用することが可能で、現在 も効率的なネットワークトランスポートとなっています。
l NetWorker 7.6.1 では、NetWorker で構成された各 DataDomain デバイスによって、並列バックアップ ストリームの 大数が 10 に制限されています。 より高い並列化が必要である場合は、NetWorker サーバ エディションによって定義された制限まで、より多くのデバイスを構成します。
l NetWorker 7.6.2 以降では、デバイスあたりのセッション数が 60 に制限されています。DataDomain ストレージへのバックアップに使用される方法に関係なく、総合的なバックアップ パフォーマンスは特定の DataDomain モデルの 大受信レートによって制限されます。
u 各デバイスの合計ストリームが 10 に設定されている NetWorker DataDomain-OST デバイスに必要な 小メモリは、約 160 MB です。 BOOST の各 OST ストリームでは、追加で 16 MB のメモリが使用されます。
u DDBoost では、短時間の非クライアントの重複排除バックアップと比較して、バックアップ操作中に 2～40%余分に CPU 時間が使用されます。 ただし、DDBoost へのバックアップの全体的な CPU 負荷は、CIFS/NFS を使用する mmd ベースの従来のバックアップよりも少なくなります。
ATFD デバイスのターゲット セッション数と 大セッション数
サポート対象の各オペレーティング システムには、AFTD（高度なファイル タイプ デバイス）デバイスに関する NetWorker ソフトウェアの 適なターゲット セッション数と 大セッション数の設定があります。 NetWorker バージョン 7.6 以前、および 7.6 Service Pack 1 以降のソフトウェアを対象とした詳細な説明が含まれます。
チューニング設定
58 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
NetWorker 7.6 以前のソフトウェア
AFTD のターゲット セッション（4）および 大セッション（512）に関する現在の NetWorker 7.6以前のデフォルト設定は、AFTD パフォーマンスにとって 適ではありません。
NetWorker 7.6 以前の AFTD パフォーマンスを 適化するには、デフォルト値を次のように変更します。
u デバイスのターゲット セッションを 4 から 1 に設定します。
u ディスク スラッシングを避けるためにデバイスの 大セッションを 512 から 32 に設定します。
NetWorker 7.6 サービス パック 1 以降
AFTD のターゲット セッション数と 大デバイス セッション数のデフォルトとして、AFTD のパフォーマンスに 適な値が設定されるようになりました。
u デバイスのターゲット セッション数は 1。
u ディスク スラッシングを避けるためにデバイスの 大セッション数は 32。デバイスのターゲットおよび 大セッションの属性は、必要に応じて変更し、環境に合った値を反映することができます。
NetWorker 8.0 以降のソフトウェア
NSR ストレージ ノード属性の動的 nsrmmd 属性は、デフォルトで、nsrmmd プロセスの動的プロビジョニングに対してオフになっています。 動的 nsrmmd 属性をオンにすると、動的nsrmmd プロビジョニングが有効になります。
NetWorker 8.1 における AFTD および DD Boost デバイスの動的 nsrmmd 機能は、デフォル
トで有効です。 以前の NetWorker バージョンでは、この属性はデフォルトで無効でした。
動的 nsrmmd 属性が有効で、デバイスに対するセッション数がターゲット セッション数を超えている場合、動作の目に見える変化として同じデバイスに複数の nsrmmd プロセスが現われます。 どちらが少なくても、 大 nsrmmd カウントまたは 大セッション値に達するまでこの状態は続きます。
ディスクへのバックアップをオンにするには、［構成］タブを選択し、必要に応じて次の属性を設定します。
u ターゲット セッションとは、別の利用可能なデバイスを使用する前にデバイスが処理するセッションの数です。 適なパフォーマンスを実現するには、低い値に設定する必要があります。 デフォルト値は 4（FTD/AFTD）および 6（DD Boost デバイス）で、60 より大きい値を設定することはできません。
u 大セッションにはデフォルト値 32（FTD/AFTD）および 60（DD Boost デバイス）があり、ほとんどの場合、この値で 適なパフォーマンスが実現されます。 n の値は、60 より大きい値に設定することはできません。
u 大 nsrmmd カウントは高度な設定です。ストレージ･ノードを同時に実行できるバックアップ･プロセス数を制限することによって、データ･スループットを増やすために使用できます。 ターゲットまたは 大セッションが変更されると、MS/TS + 4 の計算式で 大nsrmmd カウントが自動的に調整されます。デフォルト値は、12（FTD/AFTD）および 14（DD Boost デバイス）です。
チューニング設定
ATFD デバイスのターゲット セッション数と 大セッション数 59
セッション属性と 大 nsrmmd カウントの両方を同時に変更することはお勧めしませ
ん。 この値を変更する必要がある場合は、まずセッション属性を変更して適用してか
ら、 大 nsrmmd カウントを更新します。
仮想デバイス ドライブと物理デバイス ドライブの数
LTO に保存される仮想デバイスの数は、LTO のタイプと計画された物理デバイスの数により異なります。
以下は、ファイバ チャネル ポートの 70%の使用率に基づいています。
u LTO-3 の場合： 2 台の物理デバイスごとに 3 台の仮想デバイスが計画されます。
u LTO-4 の場合： 各物理デバイスに 3 台の仮想デバイスが計画されます。同じポート上にある各テープ ドライブのパフォーマンスは、接続されたデバイス数に応じて低下します。 次に例を挙げます。
u 初の仮想デバイスが 1 秒あたり 150 MB の制限に達した場合。
u 2 台目の仮想ドライブは、1 秒あたり 100 MB を超えません。
u 3 台目の仮想ドライブは、1 秒あたり 70 MB を超えません。
ネットワークの 適化適なパフォーマンスを確保するためにネットワークの次のコンポーネントを調整します。
高度な構成の 適化
デフォルトの TCP オペレーティング システム パラメータは、従来のネットワーク インフラストラクチャとの互換性を 大限に広げることを目的として調整されており、パフォーマンスの大化は考慮されていません。 したがって、何らかの構成が必要です。
付録 B： 「NetWorker リリース 8.1（以降）管理ガイド」の「ファイアウォール サポート」には、マルチホーム システムやトランクなどの高度な構成オプションの説明が記載されています。
オペレーティング システムの TCP スタックの 適化
オペレーティング システムの TCP スタックを 適化するための一般的で環境の能力にかなうルールがあります。
すべての用途についてオペレーティング システムの TCP スタックを 適化するための共通ルールは、次のとおりです。
u ソフトウェアのフロー制御を無効にします。
u TCP のバッファ サイズを増やします。
u TCP のキューの深さを増やします。
u 10 GB の NIC に PCIeXpress を使用します。 その他の I/O アーキテクチャには、十分な帯域幅がありません。PCIeXpress の詳細については、PCI-X および PCIeXpress に関する考慮事項（22 ページ）を参照してください。
環境の能力に依存するルールは、次のとおりです。
u 一部のオペレーティング システムには、TCP スタックの内部的な自動チューニングがあります。 これによって、非異機種混在環境にメリットがもたらされます。 ただし、異機種混在環境または経路選択型環境では、TCP 自動チューニングは無効です。
チューニング設定
60 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
u 可能な場合はジャンボ フレームを有効にします。 ジャンボ フレームの詳細については、ジャンボ フレーム（63 ページ）を参照してください。
データ パスにある［すべて］のネットワーク コンポーネントがジャンボ フレームに対応し
ている必要があります。 そうでない場合は、ジャンボ フレームを有効にしないでくださ
い。
u TCP ハードウェアのオフロードは、適切に機能していれば有益です。 ただし、CRC の不一致の原因になる可能性があります。 有効な場合は、エラーがないか監視してください。
u TCP ウィンドウの拡張は、チェーン内のすべてのネットワーク機器によってサポートされている場合は有益です。
u TCP 輻輳通知は、異機種混在環境で問題の原因になる可能性があります。 単一オペレーティング システム環境でのみ有効にしてください。
高度なチューニング
高速 NIC の IRQ 処理は非常に高価ですが、特定の CPU コアを選択することによってパフォーマンスを向上できます。 特定の推奨事項は、CPU アーキテクチャによって異なります。
期待される NIC スループット値
高速 NIC は、一般的な NIC より大幅に効率的です。
共通の NIC スループット値の範囲は、次のとおりです。
u 100 Mb リンク= 6～8 MB/秒
u 1 Gb リンク= 45～65 MB/秒
u 10 Gb リンク= 150～350 Mb/秒値を 適化すると、高速リンクのスループットを以下まで増加させることができます。
u 100 Mb リンク= 12 MB/秒
u 1 Gb リンク= 110 MB/秒
u 10 Gb リンク= 1100 MB/秒10 Gb の Ethernet リンクの理論上の 大スループットは、1 方向あたり 1.164 GB/秒です。これは、ビットをバイトに変換し、 小 Ethernet、IP、および TCP オーバーヘッドを除いて計算された値です。
ネットワーク レーテンシー
ネットワーク TCP レーテンシーが増加すると、利用可能なリンク帯域幅に関係なく、スループット全体に悪影響を及ぼします。 ネットワーク ホスト間の距離が長くなったりホップ数が増えるほど、全体的なスループットが低下する可能性があります。
ネットワーク レーテンシーは、帯域幅の利用効率に大きな影響を及ぼします。
次の図に、同じネットワーク リンク上でレーテンシーの異なるバックアップ スループットの例を示します。
次の例では、 適化されていない TCP 設定が使用されています。
チューニング設定
高度なチューニング 61
図 12 1 秒あたり 10/100 MB のネットワーク レーテンシー
図 13 1 ギガバイトのネットワーク レーテンシー
Ethernet の二重化
半二重モードで実行されるネットワーク リンクでは、NetWorker トラフィック フロー パフォーマンスが低下します。
たとえば、100 Mb の半二重リンクでは、バックアップ パフォーマンスが 1 秒あたり 1 MB より低くなります。
ほとんどのオペレーティング システムの二重化のデフォルト構成設定は、IEEE802.3 で推奨されているように自動検知されます。ただし、オート ネゴシエーションでは、次の条件を満たしている必要があります。
u 適切なケーブル接続
u 互換性のある NIC アダプタ
u 互換性のあるスイッチ
オート ネゴシエーションでは、リンクが半二重として実行される可能性があります。
チューニング設定
62 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
オート ネゴシエーションによる問題を回避するには、NIC で全二重に設定します。 全二重の設定は、リンクの両側に適用する必要があります。 リンクの片方のみを全二重にすると、リンクのもう片方でオート ネゴシエーションが失敗します。
ファイアウォール（FireWall）ハードウェア ファイアウォールの I/O パスにレイヤーを追加すると、ネットワーク レーテンシーが増加して全体的な帯域幅の使用が減少します。
大量のパケットを処理することによってかなりのオーバーヘッドが発生するため、バックアップ サーバでソフトウェア ファイアウォールを使用しないことをお勧めします。
ファイアウォールの構成と影響の詳細については、「付録 B： ファイアウォール サポート」（「NetWorker リリース 8.1（以降）管理ガイド」）を参照してください。
ジャンボ フレーム
対応可能な環境では、ジャンボ フレームを使用することをお勧めします。 データ パスにあるソース、コンピュータ、およびすべての機器がジャンボ フレームに対応している場合は、MTU を 9 KB に増やします。
次の例は、Linux および Solaris オペレーティング システム向けです。
u Linux： ifconfig eth0 mtu 9000 up
u Solaris： 次のコマンドを使用して nxge デバイス用にジャンボ フレームを構成します。
ndd -set /dev/nxge<［#］> accept-jumbo 1
<［#］>には、ドライバのインスタンス番号を代入します。
デバイスのインスタンス番号を特定するには、nxge /etc /path_to_inst コマンドを実行し
ます。
輻輳通知
輻輳通知アルゴリズムを無効にする方法は、オペレーティング システムにより異なります。
u Windows 2008 R2 のみ：
1. オプションの輻輳通知アルゴリズムを無効にします。
C:\> netsh interface tcp set global ecncapability=disabled
手順
1. 高度な TCP アルゴリズムは、Windows に大きなメリットをもたらします。 ただし、ネットワーク変換の両側がネゴシエーションに対応していない場合は、高度な TCP アルゴリズムを無効にします。
結果
C:\> netsh interface tcp set global congestionprovider=ctcpu Linux：
1. 非標準アルゴリズムがないか確認します。
cat /proc/sys/net/ipv4/tcp_available_congestion_control2. ECN を無効にします。
echo 0 >/proc/sys/net/ipv4/tcp_ecnu Solaris：
チューニング設定
ファイアウォール（FireWall） 63
TCP Fusion が存在する場合は無効にします。
set ip:do_tcp_fusion = 0x0
TCP バッファ
受信 TCP パケットのレートがシステムで処理できるレートよりも高い場合、オペレーティングシステムでいくつかのパケットがドロップされます。 これにより、NetWorker が不明な状態になり、バックアップ操作の信頼性が低下します。 高速のインターフェイスを備えたNetWorker サーバーまたはストレージ ノード システムの場合、ドロップした TCP パケットのシステム TCP 統計を監視することが重要です。これは、一般的に netstat -s コマンドを使用して実行します。 TCP パケットのドロップを回避するには、TCP バッファー サイズを増やします。 オペレーティング システムによっては、このパラメーターは、バッファー サイズ、キューサイズ、ハッシュ サイズ、バックログまたは接続の深さと呼ばれます。
高速ネットワーク インタフェースでは、TCP 送受信バッファのサイズを増やします。
u Linux：Linux で TCP バッファーの設定を変更するには、次の手順を実行します。
1. 次のパラメーターを/etc/sysctl.conf ファイルに追加し、/sbin/sysctl -p コマン
ドを実行します。
net.core.rmem_default = 262144net.core.wmem_default = 262144net.core.rmem_max = 16777216net.core.wmem_max = 16777216net.ipv4.tcp_rmem = 8192 524288 16777216net.ipv4.tcp_wmem = 8192 524288 16777216
2. RPC の推奨値を設定します。
sunrpc.tcp_slot_table_entries = 643. もう 1 つは、動的な TCP ウィンドウの拡張を有効にする方法です。 これには、データ
パス内の機器に互換性が必要です。
sysctl -w net.ipv4.tcp_window_scaling=1u Solaris：
tcp_max_buf 10485760tcp_cwnd_max 10485760tcp_recv_hiwat 65536tcp_xmit_hiwat 65536
u AIX値が推奨値よりも小さい場合は、/etc/rc.net のパラメータ値を変更します。 システムによって受信ソケット キューのカーネルでバッファされるバイト数は、次のとおりです。
no -o tcp_recvspace=524288
アプリケーションによって送信コールでブロックされる前にカーネルでバッファされるバイト数は、次のとおりです。
no -o tcp_sendspace=524288u Windows：
l デフォルトでは、Windows オペレーティング システムで維持されるバッファ サイズは十分にあります。
l レジストリ エントリーを設定します。
AdditionalCriticalWorkerThreads: DWORD=10l NIC ドライバによってドライバレベルで複数のバッファまたはキューが作成される場
合は、ドライバ レベルで有効にします。 たとえば、Intel 10 Gb NIC ドライバでは、RSSキューがデフォルトで 2 に設定されていて、 適なパフォーマンスを実現するための推奨値は 16 です。
チューニング設定
64 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
l Windows 2008 サーバでは、TCP スタックの自動調整方法が採用されています。LAN 上のサーバまたはデータゾーンにあるルータやスイッチなどのネットワーク デバイスによって TCP ウィンドウの拡張がサポートされていない場合は、バックアップが失敗する可能性があります。 バックアップの失敗を回避し、NetWorker の動作を
適化するには、Windows 2008 サーバに Microsoft Hotfix KB958015 を適用し、自動チューニング レベル値を高制限に設定します。
1. 現在の TCP 設定を確認します。
C:\> netsh interface tcp show global2. 必要に応じて、Windows の TCP 受信側の拡張自動チューニング レベルを制限
します。
C:\> netsh interface tcp set global autotuninglevel=highlyrestricted
hotfix KB958015 が適用されていない場合は、自動チューニング レベルを高制限で
はなく無効に設定する必要があります。
TCP バックログのバッファ サイズを増やす
TCP バックログのバッファ サイズを増やすには、接続バックログ キューを許可される 大値に設定します。
net.ipv4.tcp_max_syn_backlog = 8192net.core.netdev_max_backlog = 8192
net.core.somaxconn 値のデフォルトは 128 です。リクエストのバースト（突発的増加）をサポートするには、この値を大幅に増やします。 たとえば、1024 件のリクエストのバーストをサポートするには、次のように net.core.somaxconn を 1024 に設定します。
net.core.somaxconn = 1024
NetWorker ソケット バッファ サイズ
適化する適切な NetWorker ソケット バッファ サイズを決定することが重要です。
NetWorker 7.6.x 以前の大きな TCP 送受信ウィンドウを使用するように設定するには、NetWorker の起動スクリプトに以下を含めます。
NSR_SOCK_BUF_SIZE=65536export NSR_SOCK_BUF_SIZEu 1 GB ネットワークの 適な TCP ソケット バッファは、64 KB です。
u 10 GB ネットワークの 適な TCP ソケット バッファは、256 KB です。 NetWorker の起動スクリプトに以下を含めます。
NSR_SOCK_BUF_SIZE=262144
NetWorker 8.0 以降では、NetWorker ソケット バッファ サイズを設定する必要はありま
せん。 ソフトウェアに実装されており、256 KB のソケット バッファ サイズを使用するよう
に設定されています。
IRQ バランシングおよび CPU の親和性
複数の 1 Gb インタフェースまたは 1 つの 10 Gb インタフェースのいずれかを使用する高速ネットワーク インタフェースは、無効化された IRQ バランシングと特定の CPU コア処理のバインドから利益を得ています。
チューニング設定
TCP バックログのバッファ サイズを増やす 65
一般的なルールとしては、物理 CPU 1 つにつき 1 つのみのコアで NIC の割り込みを処理す
る必要があります。 CPU よりも NIC が多い場合にのみ、CPU 1 つあたりに複数のコアを使
用します。 ただし、送受信は常に例外なく同じ CPU によって処理される必要があります。
次の例は、Linux および Solaris オペレーティング システム向けです。
u Linux：
1. IRQ バランシングを無効にして、CPU の親和性を手動で設定します。
service irqbalance stopchkconfig irqbalance off
2. eth0 インタフェースの CPU の親和性を調整します。
grep eth0 /proc/interrupts3. 大値から 小値までの親和性を調整します。 次に例を挙げます。
echo 80 > /proc/irq/177/smp_affinityecho 40 > /proc/irq/166/smp_affinity
SMP の親和性は、IO-APIC が有効なデバイス ドライバに対してのみ機能します。cat /proc/interrupts を使用するか、デバイスのマニュアルを参照して、デバイスのIO-APIC 機能を確認します。
u Solaris：CPU 1 つにつきコアを 1 つのみ割り込ませます。 たとえば、CPU が 4 つで CPU につきコアが 4 つあるシステムでは、次のコマンドを使用します。
psradm -i 1-3 5-7 9-11 13-15
その他のチューニングは、システム アーキテクチャによって異なります。
T1/T2 CPU を搭載した Solaris システムの適切な設定例を示します。
ddi_msix_alloc_limit 8tcp_squeue_wput 1ip_soft_rings_cnt 64ip_squeue_fanout 1
一部の NIC ドライバでは、ピーク時の CPU 使用を削減するために意図的に割り込み速度が制限されています。 ただし、これによって実現可能な 大スループットも制限されます。 NIC ドライバが「割り込み緩和」に設定されている場合は、 適なネットワーク スループットを実現するために割り込み緩和を無効にしてください。
割り込み緩和
Windows では、10 GB ネットワークの場合、ネットワーク パフォーマンスを向上するために、ネットワーク アダプタの割り込み緩和を無効にすることをお勧めします。
TCP オフロード
低レベルで TCP パケットを処理できる NIC を搭載したシステムでは、全体的な帯域幅の使用率を高め、システムの CPU 負荷を軽減するために、オペレーティング システムで TCP オフロードを有効にします。
チューニング設定
66 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
オフロード機能を売りにしているすべての NIC が、規格に完全準拠しているわけではありま
せん。
u Windows 2008 サーバでは、次のコマンドを使用して TCP オフロードを有効にします。C:\> netsh interface tcp set global chimney=enabled
u Windows 2008 R2 サーバでは、追加プロパティとともに次のコマンドを使用して TCP オ
フロードを有効にします。C:\> netsh interface tcp set global dca=enabledC:\> netsh interface tcp set global netdma=enabled
u 問題が発生する古い NIC カードの TCP オフロードを無効にします。発生する問題とは、
以下と同様のバックアップ セッションの停止、RPC エラー、または CRC（接続リセット）エ
ラーによる失敗などです。Connection reset by peer
TCP のオフロードは、適切に機能していれば有益です。 ただし、CRC の不一致の原因になる可能性があります。 有効な場合は、エラーがないか監視してください。
チューニング設定
TCP オフロード 67
名前解決
NetWorker サーバはオペレーティング･システムの名前解決機能に大きく依存している
DNS サーバでは、パフォーマンスの問題を防ぐために DNS サーバに低レーテンシーのアクセスを設定します。次のいずれかを構成します。
u ローカル DNS キャッシュまたは
u メイン DNS サーバからのゾーン転送を使用する権限のないローカル DNS サーバ
ローカル ホスト名のチェックで DNS ルックアップが行われないように、システム上の各 IP アドレスに割り当てられたサーバ名およびホスト名がホスト ファイルで定義されていることを確認します。
チューニング設定
68 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
第 4 章
パフォーマンス テスト
この章では、NetWorker プログラムに含まれている bigasm や uasm などの利用可能なツールを使用して、ボトルネックをテストして理解する方法について説明します。
u 現象の特定........................................................................................................... 70u パフォーマンスの監視........................................................................................... 70u 一般的な FTP テストを使用したボトルネックの特定................................................. 71u DD を使用したセットアップ パフォーマンスのテスト................................................. 71u bigasm および uasm を使用したディスク パフォーマンス テスト.............................. 71
パフォーマンス テスト 69
現象の特定バックアップ パフォーマンス低下の理由を特定するための考慮事項が数多くあります。
次のような質問を使用して、パフォーマンス低下の原因を特定します。
u バックアップ期間全体でパフォーマンスは一貫していますか?
u バックアップが異なる時間に開始された場合、適切に実行されていますか?
u クライアントのすべてのセーブセットでパフォーマンスは一貫していますか?
u 特定のストレージ ノードを使用し、システム構成が類似するすべてのクライアントでパフォーマンスは一貫していますか?
u サブネットが同じでシステム構成が類似するすべてのクライアントでパフォーマンスは一貫していますか?
u システム構成およびアプリケーションが類似するすべてのクライアントでパフォーマンスは一貫していますか?
さまざまなパラメータを使用してクライアントがどのように実行されるのかを観察します。 バックアップ速度のばらつきは、ソフトウェアまたはファームウェアに問題があることを示す場合があります。
各 NetWorker クライアントに、次の質問を尋ねます。
u バックアップ期間全体でパフォーマンスは一貫していますか?
u バックアップが異なる時間に開始された場合、パフォーマンスに変化はありますか?
u 特定のストレージ ノードを使用するすべてのクライアントでパフォーマンスは一貫していますか?
u クライアントのすべてのセーブセットでパフォーマンスは一貫していますか?
u サブネットが同じすべてのクライアントでパフォーマンスは一貫していますか?
u オペレーティング システム、サービス パック、アプリケーションが類似するすべてのクライアントでパフォーマンスは一貫していますか?
u 保存中にバックアップ パフォーマンスは向上しますか?低下しますか?
これらの質問および類似の質問は、特定のパフォーマンス問題の確認に役立ちます。
パフォーマンスの監視ネイティブなパフォーマンス監視ツールを使用して、I/O、ディスク、CPU、およびネットワークのパフォーマンスを監視することができます。
次のような監視ツールをパフォーマンスの監視に使用できます。
u Windows： Perfmon
u UNIX： iostat、vmstat、または netstat コマンド
Windows： Perfmon
バックアップの前後または 中の異常なアクティビティによって、デバイスが過剰なリソースを使用していることを特定できます。 これらのツールを使用して一定期間のパフォーマンスを観察することによって、NetWorker を含む各アプリケーションで消費されるリソースが明確に特定されます。 その他のアプリケーションがネットワークを過剰に使用しているためにバックアップが遅いことがわかった場合は、バックアップ スケジュールを変更することによって修正できます。
多くの場合、CPU の能力不足ではなく、CPU 使用率の高さが外部 I/O 待機の原因になります。 これは、内部 SYSTEM とユーザー領域の CPU 使用率が高いことによって示されます。
パフォーマンス テスト
70 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
Windows では、遅延プロシージャ コールに多くの時間がかかる場合、たいていはデバイスドライバに問題があることを示します。
一般的な FTP テストを使用したボトルネックの特定NetWorker コンポーネントを使用せずに、一般的な FTP テストを使用してネットワークまたはテープ ドライバー内にボトルネックがあるかどうかを確認することができます。
手順
1. NetWorker クライアントで大きなデータ ファイルを作成し、FTP を使用してストレージ ノードに送信します。
2. ファイル転送にかかった時間を書き留めます。
3. 手順 2 で書き留めた時間を現在のバックアップ パフォーマンスと比較します。
a. FTP がバックアップよりもかなり速く実行されている場合、ボトルネックはテープ デバイスにある可能性があります。
b. FTP が同じくらいの速度で実行されている場合、ボトルネックはネットワークにある可能性があります。
4. アクティブ FTP 転送とパッシブ FTP 転送の使用による結果を比較します。 NetWorker バックアップ パフォーマンスは、基礎となるネットワークの能力と NetWorker ソフトウェアで使用されるネットワーク パケットに大きく影響されます。
結果
転送速度に大きな差がある場合、または一方の FTP 転送にスパイクがある場合、TCP パケットの再組み立てを行っているネットワーク コンポーネントが存在する可能性があります。これにより、物理コンポーネントがすべて全二重であってもリンクが半二重モードで実行されます。
DD を使用したセットアップ パフォーマンスのテストNetWorker コンポーネントを使用せずに一般的な DD テストを使用して、デバイス スループットとメーカー推奨スループットを比較することができます。
手順
1. ストレージ ノードで大きなデータ ファイルを作成し、DD を使用してターゲット デバイスに送信します。
date; dd if=/tmp/5GBfile of=/dev/rmt/0cbn bs= 1MB; date2. ファイル転送にかかった時間を書き留めて、現在のテープ パフォーマンスと比較しま
す。
bigasm および uasm を使用したディスク パフォーマンス テストbigasm および uasm ディレクティブは、パフォーマンスの検証に使用される NetWorker ベースのテストです。
パフォーマンス テスト
一般的な FTP テストを使用したボトルネックの特定 71
bigasm ディレクティブ
bigasm ディレクティブによって、特定のサイズに設定されたファイルが生成され、ネットワークまたは SCSI 接続経由でそのファイルが転送されます。 ファイルは、テープまたはその他のターゲット デバイスに書き込まれます。
bigasm ディレクティブによって、メモリにバイト ストリームが作成され、ディスク アクセスを排除したターゲット デバイスに保存されます。 これにより、ディスク アクセスを無視して、NetWorker クライアント、ネットワーク、およびテープ デバイスの速度をテストできます。
bigasm ディレクティブを作成して、非常に大きなセーブセットを生成します。
bigasm ディレクティブによって、ディスク アクセスを無視して、クライアント、ネットワーク、およびテープのパフォーマンスがテストされます。
uasm ディレクティブ
uasm ディレクティブによって、 大速度でディスクから読み取られ、ディスク ベースのボトルネックが特定されます。
次に例を挙げます。
uasm –s filename > NULuasm ディレクティブによって、ディスクの読み取り速度がテストされ、null デバイスにデータを書き込むことによってディスクベースのボトルネックを特定されます。
パフォーマンス テスト
72 EMC NetWorker 8.2 パフォーマンス 適化計画ガイド
