Symantec NetBackup バックアップ計画とパフォーマ … 10...

Symantec NetBackup™ バックアップ計画とパフォーマンスチューニングガイド

UNIX、Windows および Linux

リリース 7.5 とリリース 7.6

Symantec NetBackup™ バックアップ計画とパフォーマンスチューニングガイド

このマニュアルで説明するソフトウェアは、使用許諾契約に基づいて提供され、その内容に同意す

る場合にのみ使用することができます。

マニュアルバージョン: 7.5、7.6

法的通知と登録商標

Copyright © 2014 Symantec Corporation. All rights reserved.

Symantec、Symantec ロゴ、チェックマークロゴは、Symantec Corporation またはその関連会社の、米国およびその他の国における商標または登録商標です。その他の会社名、製品名は各社の登録商標または商標です。

このシマンテック製品には、サードパーティ (「サードパーティプログラム」) の所有物であることを示す必要があるサードパーティソフトウェアが含まれている場合があります。サードパーティプログラム

の一部は、オープンソースまたはフリーソフトウェアライセンスで提供されます。本ソフトウェアに含ま

れる本使用許諾契約は、オープンソースまたはフリーソフトウェアライセンスでお客様が有する権利

または義務を変更しないものとします。サードパーティプログラムについて詳しくは、この文書のサー

ドパーティの商標登録の付属資料、またはこのシマンテック製品に含まれる TRIP ReadMe File を参照してください。

本書に記載する製品は、使用、コピー、頒布、逆コンパイルおよびリバースエンジニアリングを制限

するライセンスに基づいて頒布されています。Symantec Corporation からの書面による許可なく本書を複製することはできません。

Symantec Corporation が提供する技術文書は Symantec Corporation の著作物であり、SymantecCorporation が保有するものです。保証の免責: 技術文書は現状有姿のままで提供され、SymantecCorporation はその正確性や使用について何ら保証いたしません。技術文書またはこれに記載される情報はお客様の責任にてご使用ください。本書には、技術的な誤りやその他不正確な点を含

んでいる可能性があります。Symantec は事前の通知なく本書を変更する権利を留保します。

ライセンス対象ソフトウェアおよび資料は、FAR 12.212 の規定によって商業用コンピュータソフトウェアと見なされ、場合に応じて、FAR 52.227-19 「Commercial Computer Software - RestrictedRights」、DFARS 227.7202 「Rights in Commercial Computer Software or Commercial ComputerSoftware Documentation」、その後継規制の規定により制限された権利の対象となります。米国政府によるライセンス対象ソフトウェアおよび資料の使用、修正、複製のリリース、実演、表示または開

示は、本使用許諾契約の条項に従ってのみ行われるものとします。

弊社製品に関して、当資料で明示的に禁止、あるいは否定されていない利用形態およびシステム

構成などについて、これを包括的かつ暗黙的に保証するものではありません。また、弊社製品が稼

動するシステムの整合性や処理性能に関しても、これを暗黙的に保証するものではありません。

これらの保証がない状況で、弊社製品の導入、稼動、展開した結果として直接的、あるいは間接的

に発生した損害等についてこれが補償されることはありません。製品の導入、稼動、展開にあたって

は、お客様の利用目的に合致することを事前に十分に検証および確認いただく前提で、計画およ

び準備をお願いします。

Symantec Corporation350 Ellis StreetMountain View, CA 94043

http://www.symantec.com

http://www.symantec.com

第 1 部バックアップ計画と設定ガイドライン ................. 10

第 1 章 NetBackup の容量計画 ...................................................... 11

このガイドの目的 ........................................................................... 11免責 ........................................................................................... 12バックアップ要件とボトルネックについて ............................................... 12バックアップ要件を分析する方法 ....................................................... 14バックアップシステムの設計 .............................................................. 16

バックアップに必要なデータ転送速度を計算する方法 ........................ 18テープへのバックアップにかかる時間を計算する方法 ........................ 19通常のディスクストレージへのバックアップにかかる時間の計算方

法 .................................................................................. 22バックアップとディスクストレージの重複排除にかかる時間の計算方

法 .................................................................................. 22必要なテープドライブの数を計算する方法 ...................................... 22ネットワークに必要なデータ転送速度を計算する方法 ........................ 24カタログのサイズを変更する場合の推奨事項 ................................... 25完全バックアップと増分バックアップに必要なメディアを計算する方

法 .................................................................................. 32バックアップを保存するのに必要とされるテープライブラリサイズを計

算する方法 ...................................................................... 33マスターサーバーを設計して設定する方法 ..................................... 34必要とされるマスターサーバーの数を推定する方法 ........................... 36必要とされるメディアサーバーの数を推定する方法 ............................ 38OpsCenter サーバーを設計する方法 ........................................... 39バックアップシステムを設計する方法: 概略 ..................................... 39

NetBackup 容量計画の質問票 ......................................................... 40

第 2 章マスターサーバー設定ガイドライン .................................. 42

ジョブスケジュールを制限する要因 ..................................................... 43負荷分散を改善するジョブの送信 ...................................................... 43NetBackup ジョブの遅延 ................................................................. 43OpsCenter を使用したジョブの監視について ........................................ 47ストレージユニットの選択: パフォーマンスに関する注意事項 ...................... 47

目次

ディスクステージングと NetBackup パフォーマンスについて ...................... 51ファイルシステム容量と NetBackup パフォーマンスについて ..................... 51NetBackup カタログついて .............................................................. 51カタログを管理するためのガイドライン .................................................. 53NetBackup カタログにメタデータを送信するためのバッチサイズの調

整 ........................................................................................ 55カタログアーカイブ ......................................................................... 57イメージデータベースの圧縮 ............................................................. 57サーバーのマージ、分割、移動について .............................................. 58NetBackup ポリシーのパフォーマンスガイドライン ................................... 58vxlogview のパフォーマンスを最適化する方法 ...................................... 59レガシーエラーログフィールド ............................................................ 60

第 3 章メディアサーバー設定ガイドライン ................................... 62

ネットワークと SCSI/FC のバス帯域幅 ................................................. 62利用可能な NetBackup メディアがない場合 ......................................... 63メディアエラーのしきい値について ...................................................... 63media_error_threshold の調整 ......................................................... 64テープの I/O エラーの処理について ................................................... 65Solaris 再起動のない st ドライバの再ロード .......................................... 66NetBackup Media Manager ドライブの選択について ............................. 67

第 4 章メディア設定ガイドライン .................................................... 68

専用および共有のバックアップ環境について ......................................... 68NetBackup メディアプールの提案 ...................................................... 68ディスクとテープ: パフォーマンスに関する注意事項 ................................. 69NetBackup の重複排除に関する情報 ................................................. 71

第 5 章推奨する実施例 ................................................................... 72

ベストプラクティス: NetBackup SAN クライアント ..................................... 72ベストプラクティス: NetBackup AdvancedDisk ...................................... 74ベストプラクティス: NetBackup のためにサポートされているテープドライブ

技術 ..................................................................................... 74ベストプラクティス: NetBackup のテープドライブのクリーニング ................... 74

NetBackup TapeAlert の動作 ..................................................... 76TapeAlert の無効化 ................................................................. 77

ベストプラクティス: NetBackup のデータリカバリ方法 ............................... 77ベストプラクティス: データリカバリ計画に関する提案 ................................ 78ベストプラクティス: NetBackup の命名規則 ........................................... 80ベストプラクティス: NetBackup の複製機能 ........................................... 81ベストプラクティス: NetBackup Sybase データベース .............................. 81

5目次

第 2 部パフォーマンスチューニング .................................. 82

第 6 章パフォーマンス測定 ............................................................. 83

NetBackup のパフォーマンス測定: 概要 .............................................. 83一貫性があるテスト条件のためにシステムの可変要素を制御する方法 .......... 84他のジョブからの影響を受けないパフォーマンステストの実行 ..................... 86NetBackup パフォーマンスの評価について .......................................... 88アクティビティモニターによる NetBackup のパフォーマンスの評価 .............. 89［すべてのログエントリ (All Log Entries)］レポートを使った NetBackup パ

フォーマンスの評価 .................................................................. 90NetBackup の［すべてのログエントリ (All Log Entries)］レポートの表 ............ 90

NetBackup の［すべてのログエントリ（All Log Entries）］レポートに関する追加情報 ................................................................... 92

システムコンポーネントの評価 ........................................................... 93テープやディスク出力に左右されないパフォーマンス測定につい

て .................................................................................. 93bpbkar を使ったディスクパフォーマンス測定 ................................... 94SKIP_DISK_WRITES touch ファイルを使ったディスクパフォーマン

スの測定 ......................................................................... 94iostat ユーティリティを使ったディスクパフォーマンスの測定（UNIX、

Linux） ............................................................................ 96GEN_DATA 指示句を使ったパフォーマンスの測定（UNIX、

Linux） ............................................................................ 97CPU 負荷の監視（UNIX と Linux） ............................................... 97Windows パフォーマンスモニターについて .................................... 97Windows の CPU 負荷の監視 .................................................... 98Windows のメモリ使用の監視 ..................................................... 98Windows のディスク負荷の監視 .................................................. 99

ディスクパフォーマンスの向上 .......................................................... 100

第 7 章 NetBackup のデータ転送パスのチューニング ............. 102

NetBackup のデータ転送パスについて ............................................. 102データ転送パスのチューニングついて ............................................... 103NetBackup のデータ転送パスのチューニングの提案 ............................. 103データ転送パスでの NetBackup クライアントのパフォーマンス .................. 107データ転送パスでの NetBackup ネットワークのパフォーマンス ................. 108

ネットワークインターフェースの設定 ............................................. 108ネットワークの負荷 .................................................................. 109NetBackup メディアサーバーのネットワークバッファサイズの設

定 ................................................................................ 109NetBackup クライアントの通信バッファサイズの設定 ........................ 112

6目次

NOSHM ファイルについて ....................................................... 113ソケット通信（NOSHM ファイル）の使用 ........................................ 114

データ転送パスでの NetBackup サーバーのパフォーマンス .................... 115共有メモリ (データバッファの数とサイズ) について ........................... 115NetBackup の待機カウンタと遅延カウンタについて ......................... 126NetBackup での親と子の遅延値の変更 ....................................... 126NetBackup クライアントとメディアサーバー間の通信について ............. 127複数のコピーがバックアップパフォーマンスに与える影響の推定 .......... 141NetBackup リストアに対するフラグメントサイズの影響 ....................... 142NetBackup のリストアのパフォーマンスに関するその他の問題 ............ 146

データ転送パスでの NetBackup ストレージデバイスのパフォーマンス ........ 149

第 8 章他の NetBackup コンポーネントのチューニング .......... 151

多重化と複数のデータストリームを使う場合 ......................................... 152バックアップとリストアに対する多重化と複数ストリームの影響 .................... 154NetBackup のリソース割り当てを改善する方法 .................................... 154

NetBackup キューに投入済みのジョブへのリソースの割り当ての改善 ................................................................................ 155

NetBackup での予約の共有 ..................................................... 155NetBackup での予約の共有の無効化 ......................................... 156オンデマンドアンロードの無効化 ................................................ 157

暗号化と NetBackup のパフォーマンス .............................................. 157圧縮と NetBackup のパフォーマンス ................................................. 159NetBackup 圧縮を有効にする方法 ................................................... 160NetBackup のパフォーマンスに対する圧縮と暗号化の影響 ..................... 161NetBackup Java のパフォーマンスの改善に関する情報 ......................... 161NetBackup Vault に関する情報 ....................................................... 161Bare Metal Restore での高速リカバリ ............................................... 161多数の小さいファイルをバックアップするときのパフォーマンスを改善する

方法 ................................................................................... 162FlashBackup のパフォーマンスを改善する方法 ................................... 163

FlashBackup と FlashBackup-Windows の読み込みバッファの調整 ................................................................................ 164

NetBackup for VMware のスナップショットマウントポイントボリュームの割り当てサイズの調整 ................................................................ 166

Symantec NetBackup OpsCenter ................................................... 166

第 9 章ディスク I/O パフォーマンスのチューニング .................. 168

NetBackup パフォーマンスとハードウェア階層 ..................................... 168パフォーマンス階層レベル 1 について ......................................... 170パフォーマンス階層レベル 2 について ......................................... 171パフォーマンス階層レベル 3 について ......................................... 172

7目次

パフォーマンス階層レベル 4 について ......................................... 172パフォーマンス階層レベル 5 について ......................................... 174パフォーマンス階層に関する注意事項 ......................................... 174

NetBackup パフォーマンスを向上させるハードウェアの例 ....................... 175NetBackup パフォーマンスを向上させるために I/O 操作を調整する方

法 ...................................................................................... 176

第 10 章 UNIX と Linux の OS 関連のチューニング要件 ............ 179

ファイル記述子の最小数 ................................................................ 179Solaris 10 のカーネルパラメータについて .......................................... 179

特定の Solaris 10 パラメータの推奨 ............................................ 180HP-UX のメッセージキューと共有メモリのパラメータ ............................... 182HP-UX のカーネルパラメータの変更 ................................................. 183Linux のカーネルパラメータの変更 ................................................... 183

第 11 章 Windows の OS 関連のチューニング要件 .................... 185

NetBackup のための Windows のチューニング ................................... 186Windows の I/O パス .................................................................... 186HBA の固定バインドの使用 ............................................................ 187Windows ソフトウェアに関する推奨事項 ............................................. 187Windows リムーバブル記憶域サービスの無効化 .................................. 188Windows のデバイスドライバの検証の無効化 ...................................... 189Test Unit Ready 要求の無効化 ....................................................... 190Windows 仮想メモリのスワップファイルのサイズ調整 .............................. 190Windows のファイルシステムキャッシュの調整 ..................................... 190最終アクセスのタイムスタンプの無効化 .............................................. 191Windows 8.3 のファイル名の無効化 ................................................. 192TCP KeepAliveTime パラメータの調整 .............................................. 192TCPWindowSize とウィンドウスケーリングの調整 .................................. 193MaxHashTableSize パラメータの値の増加 ......................................... 194NumTcbTablePartitions パラメータの値の変更 .................................... 195MaxUserPort パラメータの増加 ....................................................... 195カーネルスレッド数の増加 .............................................................. 196CPU 親和性の設定 ...................................................................... 197Windows のデータバッファサイズについて ......................................... 198

SGList (分散収集リスト) のレジストリ値 ......................................... 199Windows のデータバッファサイズの調整 ............................................ 199Windows の NetBackup 設定ファイルの要件 ...................................... 200

付録 A 追加のリソース ................................................................... 201

NetBackup のチューニングとパフォーマンスに関する追加のリソース .......... 201

8目次

索引 .................................................................................................................... 202

9目次

バックアップ計画と設定ガイドライン

■ 第1章 NetBackup の容量計画

■ 第2章マスターサーバー設定ガイドライン

■ 第3章メディアサーバー設定ガイドライン

■ 第4章メディア設定ガイドライン

■ 第5章推奨する実施例

1

NetBackup の容量計画

この章では以下の項目について説明しています。

■ このガイドの目的

■ 免責

■ バックアップ要件とボトルネックについて

■ バックアップ要件を分析する方法

■ バックアップシステムの設計

■ NetBackup 容量計画の質問票

このガイドの目的このガイドでは、NetBackup リリース 7.5 と 7.6 について説明します。

Symantec NetBackup は高パフォーマンスのデータ保護アプリケーションです。そのアーキテクチャは大規模かつ複雑な分散型計算環境のために設計されています。

NetBackup はネットワークのバックアップ、リカバリ、アーカイブ、ファイルのマイグレーションサービスのために設定できる拡張可能なストレージサーバー（マスターサーバーとメディ

アサーバー）を提供します。

このマニュアルは NetBackup のパフォーマンスを分析、評価し、調整する管理者を対象としています。このマニュアルは次のような質問に対する指針を提供することを意図しています。NetBackup マスターサーバーはどの程度の規模にする必要があるか。最大のパフォーマンスのためにサーバーをどのように調整できるか。 CPU とディスクまたはテープドライブはいくつ必要か。できるだけ速く実行するためにバックアップをどのように設定するか。リカバリ時間をどのように短縮するか。 NetBackup のデータの処理方法を特徴付けるまたは測定できるどのようなツールがあるか。

1

メモ: パフォーマンスのほとんどの重要な要因はソフトウェアではなくハードウェアに基づきます。ソフトウェアと比較すると、ハードウェアの設定はパフォーマンスに対して約 4 倍の影響をもたらします。このガイドではハードウェア構成の補足情報を提供しますが、ほとんどの部分でデバイスが正しく設定されていると想定されています。

追加の計画とパフォーマンス関連の情報について詳しくは、次のドキュメントを参照して

ください。

■ 仮想化:http://www.symantec.com/docs/TECH127089

■ 重複排除:http://www.symantec.com/docs/TECH77575

■ ストレージライフサイクルポリシー:http://www.symantec.com/docs/TECH73205

■ Media Server Encryption Option（MSEO）:http://www.symantec.com/docs/TECH73132

免責ユーザーが NetBackup、アプリケーション、オペレーティングシステムとハードウェアに精通していることが想定されています。このマニュアルの情報は単に忠告であり、ガイドラインの形で示されています。このガイドに含まれている情報の結果として行われるインストールへの変更は、妥当性と正確さのために前もって確認する必要があります。ここに含まれている情報の一部はある特定のハードウェアまたはオペレーティングシステムアーキテ

クチャにのみ適用されることがあります。

メモ: このマニュアルの情報は変更されることがあります。

バックアップ要件とボトルネックについてバックアップ必要条件を推定するための最初のステップは環境を理解することです。多くのパフォーマンス上の問題の原因はハードウェアまたは環境の問題です。インストールから期待できる最大パフォーマンスの判断において、全体のバックアップデータパスの理

解は重要です。

あらゆるバックアップ環境にボトルネックがあります。ボトルネックを変更しにくいこともありますが、ボトルネックはシステムで得られる最大パフォーマンスを決定します。

たとえば、バックアップ動作が遅い（つまり、スケジュール済みのバックアップ処理時間帯

では完了しません）次のような環境の例を考えてみます。全体のスループットは 1 秒あたり 80 MB です。

12第 1 章 NetBackup の容量計画免責

http://www.symantec.com/docs/TECH127089




何がバックアップを遅くさせているのでしょうか。この場合バックアップパフォーマンスを高めるために NetBackup または環境をどのように設定できるでしょうか。

図 1-1 に、この環境を示します。

図 1-1 NetBackup 専用環境

LAN

NetBackupクライアント

テープライブラリ:4 つの LTO gen 3

NetBackup 専用サーバー4 つの CPU、8 GB の RAM

ギガビットイーサネット

2 Gb のファイバーチャネル

SAN

説明は次のとおりです。4 つの LTO gen 3 のテープドライブに 1 秒あたり 320 MB（メガバイト）の組み合わせスループットがあります。また、サーバーからテープドライブへの 2Gb の SAN 接続に 1 秒あたり 200 MB の理論的スループットがあります。しかし 1 秒あたり 1 Gb の速度を持っている LAN には、1 秒あたり 125 MB の理論的スループットがあります。実際には 1 Gb のスループットは 70% の利用率を超えることはほとんどありません。したがって、NetBackup サーバーへの最もよいデータ配信速度は 1 秒あたり約90 MB になります。

スループットは、次を考慮するとより低いことがあります。

■ TCP/IP のパケットヘッダー

■ TCP ウィンドウサイズの制約

■ ルーターホップ（ACK パケットのパケット遅延は次のデータパケットの送信を遅らせます）

■ ホストの CPU 使用率

■ ファイルシステムオーバーヘッド

■ 他の LAN ユーザーのアクティビティ

13第 1 章 NetBackup の容量計画バックアップ要件とボトルネックについて

■ データベース管理のデーモンとサービス

LAN は設定の中で最も遅い要素であるので、バックアップパフォーマンスを高めるために確認する最初の場所です。

バックアップ要件を分析する方法バックアップ戦略には多くの要因が影響します。それらの要因を分析し、次にサイトの優先度に従ってバックアップの決定を行う必要があります。

インストールする NetBackup 容量を計画するとき、次を確認します。

表 1-1 NetBackup 容量を計画するときの確認事項

処理と注意事項確認事項

バックアップを作成する必要があるすべてのシステムを特定します。バックアップにより多くのリソースを必要とするシステムを特定できるように各システムを個別にリストします。どのコンピュータに付属のディスクドライブ、テープドライブ、ライブラリがあるかを記録し、各ドライブまたはライブラリのモデルの形式を記述

します。 Oracle、DB2、MS-Exchange など、これらのコンピュータでバックアップする必要があるアプリケーションを識別します。さらに、各ホスト名、オペレーティングシステムとバージョン、データベースの種類とバージョン、ネットワークテクノロジー（たとえば、1000BaseT）、場所を記録します。

どのシステムの

バックアップを作

成する必要がある

か。

バックアップするデータ量はどのくらいかを計算します。データベースのための容量を含む、個々の各システムのディスク容量の合計を算入します。ミラー化されたディスク容量を一度だけ追加することを忘れないでください。

すべてのディスクの合計サイズの計算によって、将来の拡張を考慮したシステムを設計できます。今後 6カ月から数年の間にバックアップする必要があるデータ量を推定してみてください。

たとえば、次の範囲を指定するとします。

■ データベースまたは raw パーティションのバックアップを計画するか。データベースをバックアップする場合、データベースエンジン、バージョン番号、バックアップ方式を特

定します。 NetBackup は複数のデータベースエンジンと raw ファイルシステムのバックアップを作成し、オンラインまたはオフラインの間、データベースのバックアップを作成できます。オンラインのデータベースをバックアップするには、特定のデータベースエンジンのための NetBackup データベースエージェントを必要とします。

raw パーティションを使ってデータベースを Snapshot Client でバックアップする場合は、raw パーティションの合計サイズと同じ量のデータをバックアップします。また、バックアップする必要があるデータ量がどのくらいかを把握する場合、最終的な計算にデータベースバックアップのサイズを追加するこ

とを忘れないでください。

■ MS-Exchange または Lotus Notes などの特別なアプリケーションサーバーのバックアップを計画するか。

アプリケーションサーバーをバックアップする場合は、形式とアプリケーションリリース番号を特定しま

す。前述したように、特定のサーバーをバックアップするために NetBackup の特別なエージェントが必要である場合もあります。

バックアップする

データ量はどのく

らいか。

14第 1 章 NetBackup の容量計画バックアップ要件を分析する方法


バックアップの頻度は次の点に直接影響があります。

■ ディスクまたはテープの必要条件

■ データ転送速度の注意事項

■ リストアの機会

バックアップシステムを正しい大きさにするには、バックアップの形式と頻度を決定する必要があります。

日次の増分バックアップと週次の完全バックアップを実行しますか。月次または隔週の完全バックアップを実行しますか。

どのようなバック

アップ形式が必要

でどのくらいの頻

度で実行するか。

各バックアップを完了するために利用可能な時間帯はどのくらいですか。時間帯の長さはバックアップ戦略の複数の項目を決定します。たとえば、大容量サーバーを複数バックアップするにはより長い時間帯が必要な場合もあります。または合成バックアップ、ローカルスナップショット方式、FlashBackup などのNetBackup の拡張機能の使用を考慮できます。

各バックアップの

実行に利用可能

な時間はどのくら

いか。

バックアップ戦略を設計する間に重要な要因はバックアップ期限のポリシーを考慮することです。バックアップが保たれる時間は「保持期間」として知られています。一般的なポリシーでは 1 カ月後に増分バックアップが、6 カ月後に完全バックアップが期限切れになります。このポリシーを使うと、前月からの日次のファイル変更をリストアし、過去 6 カ月の完全バックアップからデータをリストアできます。保持期間の長さは固有の必要条件と事業上の要件、場合によっては法的な要求事項によって決まります。ただし、保持期間の長さは必要なテープの数と NetBackup イメージデータベースのサイズに正比例します。 NetBackupイメージデータベースはすべてのディスクドライブとテープのすべての情報を追跡します。イメージデータベースサイズはバックアップの保持期間と頻度と密接に関係しています。

バックアップをどの

くらいの期間保持

するか。

ディザスタリカバリのオプションとしてオフサイトにテープを送ることを計画する場合は、オフサイトにどの

テープを送るかとオフサイトに残す期間をどのくらいにするかを特定します。すべての完全バックアップまたは選択したいくつかのみを複製することを決定する場合があります。また、ある特定のシステムを複製し、他を除外することを決定する場合もあります。テープがオフサイトに送られるので、オフサイトのストレージからリサイクルされてテープが戻るまでの代替用に新しいテープを購入する必要があります。これを忘れた場合、一番必要なときにテープ切れになることがあります。

バックアップがオ

フサイトに送られる

場合、オフサイト

に残す必要がある

期間はどのくらい

か。

ネットワーク経由でのシステムのバックアップを計画する場合は、ネットワークの種類に注意してください。

次のセクションでは、指定時間にネットワークによって転送できるデータ量を計算する方法を説明します。

p.16 の「バックアップシステムの設計」を参照してください。

バックアップするデータ量とそれらのバックアップの頻度に基づいて、バックアップ用のプライベートネット

ワークをインストールすることを考慮します。

どのようなネット

ワークテクノロジ

か。

バックアップシステムを設計するとき、将来の拡大を計画します。現在のバックアップソリューションが将来の必要条件に対応できるようにシステムの潜在的な拡大を分析します。全体のバックアップソリューションに生じる拡大要因を追加することを忘れないでください。

どのようなシステム

を次の 6 カ月以内に追加する予

定か。

15第 1 章 NetBackup の容量計画バックアップ要件を分析する方法


特定の操作の開始にかかる時間を減らすために、ユーザーに独自のバックアップとリストアを許可します。

ただし、ユーザー主導型操作はより高いサポートコストの発生と柔軟性の消失という結果になる場合もあり

ます。ユーザー主導型操作は一番必要なときにメディアとテープドライブを独占できます。また、ユーザーが新しいバックアップシステムに精通するまでに、より多くのサポートの電話とトレーニングの問題が生じる

場合もあります。バックアップシステムのいくつかの機能へのユーザーアクセスが潜在的なコストに値するかどうかを判断します。

ユーザー主導バッ

クアップまたはリス

トアを許可する

か。

データ形式はテキスト、グラフィック、データベースのどれか。データはどの程度圧縮されているか。何ファイルが含まれるか。データは暗号化されるか（暗号化バックアップは実行がより遅くなることがある点に注意してください）。

p.157 の「暗号化と NetBackup のパフォーマンス」を参照してください。

どのようなデータ

を扱うか。

データはローカルかリモートか。ストレージサブシステムの性質はどうか。正確なデータパスは何か。ストレージサブシステムはどのくらいビジー状態か。

データはどこにあ

るか。

時間の経過とともにハードウェアとソフトウェアのインフラが変わるので、独立したテストバックアップ環境を

作成します。この方法で、変更されたコンポーネントで本番環境が稼働することを確認します。バックアップシステ

ムをどのようにして

テストするか。

バックアップシステムの設計以下の計画と構成の例は標準かつ理想的な計算に基づきます。数値は特定の環境、データ、圧縮率によって異なる可能性があります。

バックアップ必要条件の分析後、バックアップシステムを設計し始めることができます。次の表はバックアップシステムを設計する手順の概略を示したものです。

表 1-2 バックアップシステムを設計する手順

説明処理手順

利用可能な時間内にすべてのデータのバックアップを完了するために

システムが達成する必要がある転送速度を計算します。

p.18 の「バックアップに必要なデータ転送速度を計算する方法」を参照してください。

バックアップに必要なデータ転送速度

の計算

手順 1

要件を満たすテープ技術またはディスク技術を特定します。

p.19 の「テープへのバックアップにかかる時間を計算する方法」を参照してください。

p.22 の「通常のディスクストレージへのバックアップにかかる時間の計算方法」を参照してください。

p.22 の「バックアップとディスクストレージの重複排除にかかる時間の計算方法」を参照してください。

テープまたはディスクへのバックアップ

にかかる時間の計算

手順 2

16第 1 章 NetBackup の容量計画バックアップシステムの設計

説明処理手順

必要なテープドライブ数を特定します。

p.22 の「必要なテープドライブの数を計算する方法」を参照してください。

必要なテープドライブ数の計算手順 3

ネットワーク経由でのバックアップでは、バックアップ処理時間帯内に

バックアップを終えるのに十分な速度でクライアントからメディアサー

バーにデータを移動する必要があります。

p.24 の「ネットワークに必要なデータ転送速度を計算する方法」を参照してください。

ネットワークに必要なデータ転送速度

の計算

手順 4

NetBackup イメージデータベースを格納するために必要なディスク領域を特定します。

p.27 の「NetBackup イメージデータベースのサイズを計算する方法」を参照してください。

NetBackup イメージデータベースサイズの計算

手順 5

NBDB に必要な領域を特定します。

p.30 の「NetBackup リレーショナルデータベース（NBDB）のサイズを計算する方法」を参照してください。

NetBackup リレーショナルデータベース（NBDB）のサイズの計算

手順 6

バックアップを保存して取得するために必要なテープ数を特定します。

p.32 の「完全バックアップと増分バックアップに必要なメディアを計算する方法」を参照してください。

完全バックアップと増分バックアップに

必要なメディアの計算

手順 7

バックアップをすべて保存するために必要なロボットライブラリのテープ

スロット数を特定します。

p.33 の「バックアップを保存するのに必要とされるテープライブラリサイズを計算する方法」を参照してください。

バックアップを保存するのに必要とさ

れるテープライブラリサイズの計算

手順 8

これまでの計算値を使ってマスターサーバーの設計と構成を行いま

す。

p.34 の「マスターサーバーを設計して設定する方法」を参照してください。

マスターサーバーの設計手順 9

マスターサーバーの数を推定するときの注意事項については次のト

ピックを参照してください。

p.36 の「必要とされるマスターサーバーの数を推定する方法」を参照してください。

必要とされるマスターサーバーの数の

推定

手順 10

必要なメディアサーバー数の推定に関するガイドラインについては次

のトピックを参照してください。

p.38 の「必要とされるメディアサーバーの数を推定する方法」を参照してください。

必要とされるメディアサーバーの数の

推定

手順 12


説明処理手順

OpsCenter の情報へのリンクについては次のトピックを参照してください。

p.39 の「OpsCenter サーバーを設計する方法」を参照してください。

OpsCenter サーバーの設計手順 13

次のトピックに概要をまとめてあります。

p.39 の「バックアップシステムを設計する方法: 概略」を参照してください。

これらの手順の概略の確認手順 14

バックアップに必要なデータ転送速度を計算する方法このセクションは、割り当てられた時間帯ですべてのデータのバックアップを完了するた

めにシステムが達成する必要がある転送速度の計算に役立ちます。完全バックアップと増分バックアップの理想的なデータ転送速度を計算するために次の式を使います。

理想的なデータ転送速度 = (バックアップするデータ量)/(バックアップ処理時間帯)

平均して、多くのシステムのデータの日次の変更は 10 から 20% の間です。 (バックアップするデータの量) の 20% の変更を計算します。それから、増分バックアップのバックアップ速度を求めるために (バックアップ処理時間帯) でそれを除算します。

累積増分バックアップを実行する場合は、変更が行われるデータを考慮してください。たとえば、データの同じ 20% が毎日変更された場合、累積増分バックアップは異なる 20%が毎日変更された場合よりも小さくなります。

週次での理想的なデータ転送速度を計算する例を次に示します。

この例では次のように想定します。

■ 完全バックアップの間にバックアップするデータ量 = 500 GB

■ 増分バックアップの間にバックアップするデータ量 = 完全バックアップの 20% 日次バックアップ処理時間帯 = 8 時間

ソリューション 1:

完全バックアップ = 500 GB

理想的なデータ転送速度 = 500 GB/8 時間 = 62.5 GB/時


増分バックアップ = 100 GB

理想的なデータ転送速度 = 100 GB/8 時間 = 12.5 GB/時

週末の理想的な転送速度を計算するには、週末のバックアップ処理時間帯の長さでバッ

クアップが必要なデータの量を除算してください。


テープへのバックアップにかかる時間を計算する方法バックアップのための理想的なデータ転送速度を確認すれば、どのようなテープドライブ

の技術が要件を満たすかを把握できます。バックアップ処理時間帯の長さとバックアップするデータの量を使って、必要なテープドライブの数を計算できます。

表 1-3 に複数のテープドライブ技術のための転送速度をリストします。

表 1-3 テープドライブのデータ転送速度

GB/時、2:1 圧縮、使用率 60%

GB/時、使用率60%

GB/時、圧縮なしMB/秒ドライブ(Drive)

103.6851.8486.424AIT-5

259.2129.621660DLT-S4/S4A

43.221.63610DLT-V4

345.6172.828880LTO-3

518.4259.2432120LTO-4

604.8302.4504140LTO-5

129.664.810830SAIT-1

194.497.216245SAIT-2

155.5277.76129.636SDLT600/600A

432216360100TS1120（3592E05）

691.2345.6576160TS1130（3592E06）

518.4259.2432120T10000A（STK、Sun、Oracle）

518.4259.2432120T10000B（STK、Sun、Oracle）

この表の値は個々の製造元が発行した値と実際の状況で計測された値です。絶対的な値ではありませんが、必要条件の計画に役立ちます。

デバイスの製造元がデバイスの最適速度をリストしていることに留意します。この表の「GB/時、圧縮なし」の列に最適速度がリストされています。実際には、オペレーティングシステ


ム、CPU 負荷、バス構造、データ形式、他のハードウェアとソフトウェアの問題のオーバーヘッドにシステムが対処する必要があるときに、それらの速度を達成することはまれです。

使用率 60% の列は実際のパフォーマンスを予測するための実用的な見積もり値です。

バックアップシステムを設計するとき、データと環境両方の性質を考慮します。多数の小さいファイルを含むバックアップイメージのほうが少数の大きいファイルを含むバックアッ

プイメージよりもテープへの書き込みに時間がかかる可能性があります。実用的な値を見積もるときは、この表の 60% の値を使います。

メモ: テープドライブとは違って、ディスクデバイス（VTL を含む）に最小のストリーム速度はありません。したがって、テープに複製する前にディスクにより遅いバックアップをステージングすることがよい戦略であることがあります。ディスクからのバックアップイメージ

の複製のほうが元の遅いバックアップより速く動作します。

特定のテープドライブを使用してバックアップの長さを計算するには、次の式を使います。

実際のデータ転送速度 = (バックアップするデータ量)/((ドライブの数) * (テープドライブの転送速度))

テープへのバックアップにかかる時間を計算する例を次に示します。


■ 完全バックアップの間にバックアップするデータ量 = 1000 GB（1 TB）

■ 日次バックアップ処理時間帯 = 8 時間

■ 理想的なデータ転送速度 (データ/(バックアップ処理時間帯)) = 1000 GB/8 時間 =125 GB/時


テープドライブ = 1 つのドライブ、LTO-2

テープドライブ転送速度 = 64.8 GB/時（使用率 60%、圧縮なし）または 129.6 GB/時（使用率 60%、2:1 圧縮）

実際のデータ転送速度、圧縮なし = 1000 GB/((1 ドライブ) * (64.8 GB/時)) = 15.43 時間

実際のデータ転送速度、2:1 圧縮 = 1000 GB/((1 ドライブ) * (129.6 GB/時)) = 7.72 時間

64.8 GB/時の場合、LTO-2 のテープドライブでは 1000 GB のバックアップを実行するために約 15.43 時間かかります。通常の状況では、圧縮なしの場合、LTO-2 のテープドライブは 8 時間以内でバックアップを実行できません。しかし、129.6 GB/時（2:1 圧縮）の場合、LTO-2 のテープドライブでは 1000 GB のバックアップが 7.72 時間で完了します。

この例では、圧縮またはより速いテープドライブを使うため、LTO-2のテープドライブがもう 1 つ必要になります。



テープドライブ = 1 つのドライブ、LTO-3


実際のデータ転送速度、圧縮なし = 1000 GB/((1 ドライブ) * (172.8 GB/時)) = 5.79 時間

実際のデータ転送速度、2:1 圧縮 = 1000 GB/((1 ドライブ) * (345.6 GB/時)) = 2.89 時間

LTO-3 のデータ転送速度は 172.8 GB/時または 345.6 GB/時のため、単一のテープドライブで 1000 GB のバックアップを 8 時間以内に十分に完了できます。

テープドライブの転送速度に影響する要因によって、より高いまたは低い転送速度を得

ることは可能です。これらのソリューションの例は期待できるおおよその値です。

暗号化データのバックアップにはより時間がかかることがあることも注意します。

p.157 の「暗号化と NetBackup のパフォーマンス」を参照してください。

より速いテープドライブが常に望ましいわけではない

最も速いテープ技術が常にサイトに最も適切なわけではありません。次のトピックの数値を検討します。


トピックの数値はテープドライブが達成できる最大速度です。しかしテープドライブには最小速度もあり、この速度未満になると非能率的に動作し始めます。この数値は「最小のストリーム速度」として知られており、通常はデバイスのネーティブな（圧縮なしの）速度

のおよそ 40% です。ドライブは、最小のストリーム速度より小さい速度でデータを受信した場合、停止/開始モード（「シューシャイニング」）で動作します。このモードではデータバッファが満たされる速度よりもドライブがデータバッファを空にする速度のほうが速く、

バッファが再びいっぱいになるまで停止する必要があります。バッファが満たされるとドライブが開始して、次のデータブロックを書き込む前にテープの位置を変える必要がありま

す。この停止/開始動作はテープとドライブ両方の損害となり、バックアップがさらに減速するという結果にもなります。したがって、最も速いテープ技術が常に使用に最も適切ではないことがあります。

また、データ圧縮の使用が最小のストリーム速度を上げることに注意してください。データがテープに書き込まれるときに、より多くのハードウェア圧縮が使われれば、テープへ

のストリーム速度がより遅くなります。たとえば、データが 2:1 の圧縮で書き込まれる場合、最小のストリーム速度を上回るために、ドライブのネーティブ速度の 80%（40% ではなく）でデータをドライブにストリーミングする必要があります。


通常のディスクストレージへのバックアップにかかる時間の計算方法ディスクパフォーマンスは予測がより困難です。ディスクパフォーマンスには明確なルー

ルが存在しないためです。バックアップ速度はディスクの種類とディスクレイアウトによって決まります。一般に、バックアップの速度は、バックアップの書き込み先のディスクとディスクコントローラの速度によって決まります。

バックアップとディスクストレージの重複排除にかかる時間の計算方法従来のディスクストレージのバックアップ速度は、ストレージの重複排除を行う場合の速度

と同じではないことがあります。次の文書は、使う重複排除の種類のガイドラインと、重複排除の必要条件を評価する例を示しています。

『NetBackup Deduplication: Additional Usage Information』


必要なテープドライブの数を計算する方法次に式を示します。

ドライブ数 = (バックアップするデータ量)/((バックアップ処理時間帯) * (テープドライブの転送速度))

必要なテープドライブの数を計算する例を次に示します。


■ バックアップするデータ量 = 1000 GB（1 TB）

■ バックアップ処理時間帯 = 8 時間


テープドライブ形式 = LTO-2


ドライブ数、圧縮なし = 1000 GB/((8 時間) * (64.8 GB/時)) = 1.93 = 2 つのドライブ

ドライブ数、2:1 圧縮 = 1000 GB/((8 時間) * (129.6 GB/時)) = 0.96 = 1 つのドライブ




ドライブ数、圧縮なし = 1000 GB/((8 時間) * (172.8 GB/時)) = 0.72 = 1 つのドライブ

ドライブ数、2:1 圧縮 = 1000 GB/((8 時間) * (345.6 GB/時)) = 0.36 = 1 つのドライブ



バックアップを実行するために必要なドライブの数を計算できます。ただし、すべてのドライブにデータストリームを均等に分散するのは困難です。データを分散する場合は、各種のバックアップスケジュール、NetBackup ポリシー、ハードウェア構成を試します。

p.103 の「NetBackup のデータ転送パスのチューニングの提案」を参照してください。

必要なテープデバイスの数を計算するには、ドライブコントローラに接続できるテープデ

バイスの数を計算する必要があります。

コントローラに接続できるドライブの最大数を計算するには、ドライブとコントローラの製造

元の最大転送速度が必要です。計算に最大転送速度を使わないと、コントローラが飽和状態になり予測不能な結果が生じる場合があります。

メモ: 個々のテープドライブのスループットがわかっていてもそれを常に達成できるとは限りません。ドライブコントローラに十分な帯域幅があること確認してください。コントローラの帯域幅でサポートできる数を超えるドライブをコントローラに接続しないでください。

表 1-4 に、複数のドライブコントローラの転送速度を示します。

表 1-4 ドライブコントローラのデータ転送速度

理論的な GB/時理論的な MB/秒ドライブコントローラ

237.666ATA-5（ATA/ATAPI-5）

28880Wide Ultra 2 SCSI

360100iSCSI

3601001 Gb ファイバーチャネル

540150SATA/150

576160Ultra-3 SCSI


1080300SATA/300

1152320Ultra320 SCSI


実際には、転送速度は複数の可変要素の固有のオーバーヘッドのためにより遅いことが

あります。可変要素には、ファイルシステムのレイアウト、システム CPU 負荷とメモリ使用状況などがあります。


ネットワークに必要なデータ転送速度を計算する方法ネットワーク経由でのバックアップでは、バックアップ処理時間帯内にバックアップを終え

るのに十分な速度でクライアントからメディアサーバーにデータを移動する必要がありま

す。表 1-5 に、いくつかの一般的なネットワークテクノロジの標準転送速度を示します。必要なデータ転送速度を計算するには、次の式を使います。

必要なネットワークデータ転送速度 = (バックアップするデータ量)/(バックアップ処理時間帯)

表 1-5 ネットワークデータ転送速度

標準 GB/時理論的な GB/時ネットワークテクノロジ

3645100MB

3604501 GB

3600450010 GB

テープドライブへのネットワーク帯域幅の適合の重要性に関する情報が利用可能です。

p.62 の「ネットワークと SCSI/FC のバス帯域幅」を参照してください。

ネットワークに必要なデータ転送速度を計算する例を次に示します。


■ バックアップするデータ量 = 500 GB

■ バックアップ処理時間帯 = 8 時間

■ 必要なネットワーク転送速度 = 500 GB/8 時間 = 62.5 GB/時

ソリューション 1: ネットワークテクノロジ = 100 MB

標準転送速度 = 36 GB/時

100 MB の単一ネットワークの転送速度は 36 GB/時です。このネットワークは必要な62.5 GB/時のデータ転送速度に対応できません。

この場合、次のような他のオプションを検討する必要があります。

■ より速いネットワーク（1 GB や 10 GB）上でデータのバックアップを作成する

■ 専用テープドライブ（SAN メディアサーバー）に大規模サーバーのバックアップを作成する

■ SAN クライアントを使って SAN 接続でバックアップする

■ メディアサーバーにスナップショットを直接渡すために Snapshot Client を使用してオフホストバックアップを実行する

■ より長い時間帯の間にバックアップを実行する


■ より速い専用ネットワーク経由でバックアップを実行する

ソリューション 2: ネットワークテクノロジ = 1 GB

標準転送速度 = 360 GB/時

表 1-5 に基づくと、1 GB の単一ネットワークの転送速度は 360 GB/時です。このネットワークテクノロジでは余力を持ってバックアップを処理できます。

潜在的なボトルネックの識別に役立つようにネットワークのデータ転送速度を計算します。

複数のネットワークとボトルネックを取り扱うために複数のソリューションが利用可能です。


カタログのサイズを変更する場合の推奨事項背景情報が少しあります。カタログという用語は次のすべてのコンポーネントを示します。

■ イメージデータベース。これにはバックアップされたデータに関する情報が含まれま

す。それはカタログの最も大きい（90% を超える）部分です。

■ リレーショナルデータベースの NetBackup データ

■ NetBackup 構成ファイル。

p.51 の「NetBackup カタログついて」を参照してください。

NetBackup カタログのサイズは保持されるバックアップのファイル数とバックアップのコピー数によって決まります。その結果、カタログが非常に大きくなる可能性があります。ただし、カタログの最終的なサイズを推定する場合 2 つの追加要因を考慮します。許容時間帯にバックアップを作成できるか、それらの実行時間帯内に一般的なハウスキーピ

ング活動を完了できるか、ということです。カタログバックアップを完了するために必要な時間はカタログが占める容量によって決まります。ハウスキーピング活動に必要な時間はカタログのエントリ数によって決まります。他のディスクまたはテープストレージに、より古いカタログデータを移動するのに NetBackup のカタログアーカイブ機能を使うことができることに注目します。アーカイブはディスク上のカタログサイズを減らすことにより、バックアップ時間を減らすことができます。ただし、アーカイブはハウスキーピング活動に必要な時間を減らしません。

シマンテック社はカタログについて次の基準が満たされるように環境を計画することを推

奨しています。

■ オンラインカタログで保持されるデータ量が 2 TB を超えない。カタログのオンライン部分をこの値未満に保つためにアーカイブを使うことができます。

■ カタログエントリの合計数が 10,000,000 イメージを超えない、フラグメント数が100,000,000 を超えない。この数は、オンラインとカタログアーカイブで保持される、すべてのクライアントからの全バックアップの全保持コピーの合計と等しくなります。

カタログのイメージ数を計算するには次のコマンドを使います。

■ UNIX システムの場合:


/usr/openv/netbackup/bin/admincmd/bpimagelist -idonly –d

"01/01/1970 00:00:00" | wc –l

■ Windows システムの場合:install_path¥NetBackup¥bin¥admincmd¥bpimagelist -idonly –d

"01/01/1970 00:00:00" | %SystemDrive%¥Windows¥System32¥find.exe

/C " ID: "

フラグメント数をカウントするには次のコマンドを使います。

■ UNIX システムの場合:/usr/openv/netbackup/bin/admincmd/bpimagelist -l –d "01/01/1970

00:00:00" | grep “FRAG “ | wc –l

■ Windows システムの場合:install_path¥NetBackup¥bin¥admincmd¥bpimagelist -l –d

"01/01/1970 00:00:00" | %SystemDrive%¥Windows¥System32¥find.exe

/C "FRAG "

メモ: FRAGMENT や FRAGILE のような似たようなにワードがフラグメント数としてカウントされないように、FRAG という値の後に必ずスペースを含めてください。

表 1-6 カタログサイズのガイドライン（これらのガイドラインはハード制限ではありません）

ガイドラインを超えた場合の潜在的な結果

ガイドラインに関する注意事項カタログのガイドライン

2 TB を超えた場合は次のような結果になることがあります。

■ カタログのバックアップに非常に時間が

かかることがあります。

■ 増分バックアップを使えばバックアップ

時間は短縮できますが、リストア時間は

長くなります。

■ リカバリのサービスレベル契約（SLA）を作成することを検討してください。ほとんどの場合はレプリケーションで対処でき

ますが、それでもフォールバックとしてカ

タログバックアップが必要です。

アーカイブを使ってカタログのオンライン部分を 2 TB 未満に保ちます。

このガイドラインの根拠はカタログのバックアップ時間と

リカバリ時間に関連しています。

■ カタログバックアップは単純なフラットファイルのバッ

クアップではありません。

■ カタログバックアップは同期チェックポイントに基

づき、作業リストを処理するために余分な時間を

必要とします。

■ カタログバックアップでは NetBackup の他のジョブを同時にアクティブにするためにロックを使い

ます（余分な処理時間が必要になります）。

■ カタログバックアップにはスナップショット機能があり

ません。

オンラインカタログに 2TB を超えるデータを含めない


ガイドラインを超えた場合の潜在的な結果

ガイドラインに関する注意事項カタログのガイドライン

カタログエントリが多すぎると次のような結果

になることがあります。

■ クリーンアップジョブが 24 時間で完了しないほどイメージ数が増えると、次のク

リーンアップジョブがスキップされます。

■ 次のクリーンアップジョブがスキップされ

れば、期限切れメディアの再利用に遅

れが生じます。その結果、より多くのスクラッチメディアが必要になります。

注意: 一般に、クリーンアップジョブが何回か実行されなくても問題ありません。

イメージ数が 2,000,000 から 3,000,000程度であれば深刻な問題にはなりませ

ん。

カタログエントリのガイドラインの根拠は次のとおりです。

■ 12 時間ごとにクリーンアップジョブが実行されます。■ クリーンアップジョブは各イメージメタデータファ

イルの情報を調べます。

■ ジョブが 12 時間で完了しないと、次回の各ジョブの実行が取り消され、実行間隔が 24 時間に延びます。通常、クリーンアップジョブの間隔が24 時間に 1 回でも全体的な運用にはほとんど影響しません。

■ イメージのクリーンアップでは次の処理が行われま

す。

■ カタログから期限切れのイメージが削除されま

す。

■ ディスクストレージデバイスのディスク領域が再利

用されます。

■ TIR 情報が削除され、オプションでカタログファイルが圧縮されます。

■ メディアのクリーンアップでは空きテープの割り当て

が解除され、スクラッチプールに戻されます。

カタログエントリの合計

数が 10,000,000 イメージを超えない、フラ

グメント数が

100,000,000 を超えない

許容されるカタログパフォーマンスの実際の制限がストレージの速度とサーバーの性能

に影響されることに注意します。パフォーマンスはこのセクションで提供されるガイドラインの数値から大幅に異なることがあります。

メモ: カタログがこれらの制限を超えると予想した場合、環境に NetBackup の複数のドメインを配備することを考慮します。

シマンテック社の次のドキュメントにカタログのレイアウトに関するベストプラクティスが記

載されています。


カタログアーカイブについて詳しくは、『NetBackup 管理者ガイド Vol.1』で確認できます。

NetBackup イメージデータベースのサイズを計算する方法バックアップシステムを設計する場合の重要な要因は NetBackup イメージデータベースを保存するために必要なディスク容量がどのくらいかを計算することです。イメージデータベースはバックアップを作成したすべてのファイルを追跡します。



イメージデータベースのサイズは完全バックアップと増分バックアップの次の変数によっ

て決まります。

■ バックアップを作成するファイル数

■ バックアップの頻度と保持期間

NetBackup イメージデータベースのサイズを計算するために 2 つの方式のどちらかを使うことができます。時間の経過とともにデータボリュームが増加するので、いずれの場合も、使用される合計ディスク容量を計算するときに予想される増加量を考慮します。

NetBackup は必要なディスク領域の量を減らすためにイメージデータベースを自動的に圧縮します。リストアが要求されたときは、リストアの実行に必要な期間のみに限定してイメージデータベースを自動的に圧縮解除します。イメージデータベースに必要な容量を減らすためにアーカイブを使うこともできます。カタログの圧縮とアーカイブについてより多くの情報が利用可能です。

『Symantec NetBackup 管理者ガイド Vol. 1』を参照してください。

メモ: NetBackup の TIR（True Image Restore）オプションを選択した場合、イメージデータベースはこのオプションが選択されていないイメージデータベースより大きくなります。

TIR は選択されたいずれかの完全バックアップまたは増分バックアップの時にコンテンツにディレクトリをリストアするために必要な情報を集めます。 NetBackup が増分バックアップのために収集する追加情報は完全バックアップのために収集される情報と同じです。

その結果、増分バックアップは TIR 情報を収集するときにはるかに多くのディスク容量を使います。

方式 1: この方式ではイメージデータベースのサイズを正確に計算できます。これにはオンラインで保持されるファイル数と常に保持されるバックアップ（完全と増分）数などの特

定の詳細を必要とします。

特定のバックアップの GB 単位のサイズを計算するには、次の式を使います。

イメージデータベースサイズ = (132 * すべてのバックアップのファイル数)/1 GB

この方式を使うためには、バックアップで保持される各ファイルのコピーのおおよその数と

典型的なファイルサイズを判断する必要があります。コピー数は通常次のように推定できます。

バックアップで保持される各ファイルのコピー数 = 完全バックアップの数 + 保持される増分バックアップ数の 10%

方式 1 で NetBackup イメージデータベースのサイズを計算する例を次に示します。


■ 1 カ月あたりの完全バックアップの数: 4

■ 完全バックアップの保持期間: 6 カ月


■ 保持される完全バックアップの合計数: 24

■ 1 カ月あたりの増分バックアップの数: 25

■ オンライン保持されるファイル数の合計（完全バックアップのファイル数の合計）:17,500,000

ソリューション:

保持される各ファイルのコピー数:

24 + (25 * 10%) = 26.5

保持される各ファイルの NetBackup イメージデータベースサイズ:

(132 * 26.5 コピー) = 3498 バイト

必要な全体のイメージデータベース容量:

(3498 * 17,500,000 ファイル)/1 GB = 61.2 GB

方式 2: 実働環境内のデータの合計量（すべてのバックアップの合計サイズではない）を小さいパーセント（2% など）で乗算します。 2% は例であることに注意してください。このセクションは環境に適切なパーセントを計算するうえで役立ちます。

メモ: 典型的なファイルサイズ、典型的な保持ポリシー、典型的な増分の変更率を判断することが容易な環境の場合にのみ、小さいパーセントを使ってイメージデータベースサイ

ズを計算できます。場合によっては、この方式を使用して得られるイメージデータベースサイズは最終的なサイズから大幅に異なることがあります。

この方式を使うためには、バックアップで保持される各ファイルのコピーのおおよその数と

典型的なファイルサイズを判断する必要があります。コピー数は通常次のように推定できます。

バックアップで保持される各ファイルのコピー数 = 完全バックアップの数 + 保持される増分バックアップ数の 10%

乗算するパーセントは次のように計算できます。

乗算するパーセンテージ = (132 * バックアップで保持されるファイル数/平均のファイルサイズ) * 100%

次に、イメージデータベースサイズは次のように推定できます。

イメージデータベースサイズ = 使用されるディスク容量の合計 * 乗算するパーセント

方式 2 で NetBackup イメージデータベースのサイズを計算する例を次に示します。


■ 1 カ月あたりの完全バックアップの数: 4

■ 完全バックアップの保持期間: 6 カ月


■ 保持される完全バックアップの合計数: 24

■ 1 カ月あたりの増分バックアップの数: 25

■ 平均ファイルサイズ: 70 KB

■ ドメインのすべてのサーバーで使われるディスク容量の合計: 1.4 TB


保持される各ファイルのコピー数:

24 + (25 * 10%) = 26.5

保持される各ファイルの NetBackup イメージデータベースサイズ:

(132 * 26.5 コピー) = 3498 バイト

乗算するパーセント:

(3498/70000) * 100% = 5%

必要な全体のイメージデータベース容量:

(1,400 GB * 4.5%) = 63 GB

NetBackup リレーショナルデータベース（NBDB）のサイズを計算する方法

デフォルトで、NBDB データベースは NetBackup マスターサーバーに存在します。他の設定も可能です。

p.58 の「サーバーのマージ、分割、移動について」を参照してください。

メモ: NBDB データベースがインストールされる場所によっては、マスターサーバーまたはメディアサーバーのサイズの必要条件を判断するときにこの容量を含める必要がありま

す。

NBDB データベースは、NetBackup カタログの領域を占めます。カタログのコンポーネントについて詳しくは次を参照してください。


NBDB データベースの容量は次の 2 つの場所に必要になります。

UNIX の場合

/usr/openv/db/data

/usr/openv/db/staging

Windows の場合


install_path¥NetBackupDB¥data

install_path¥NetBackupDB¥staging

2 つのそれぞれのディレクトリの NBDB に必要な容量を計算するには、次の式を使います。

160 MB + (2 KB * EMM に設定されるボリューム数) + (BasicDisk 以外のディスクストレージのイメージ数 * 5 KB) + (ディスクボリューム数 * メディアサーバー数 * 5 KB) + (カタログのイメージ数 * 2 KB)

ここで EMM は Enterprise Media Manager、ボリュームは NetBackup（EMM）メディアボリュームです。 160 MB が NBDB データベースに必要とされるデフォルト容量であることに注意します。これにはデバイスとストレージユニットの設定情報に事前に割り当てられた容量を含んでいます。

メモ: NetBackup のインストールの間に、インストールスクリプトは /data ディレクトリに160 MB の空き容量を見つけます。このディレクトリの容量が不十分な場合、インストールは失敗します。 /staging の容量はカタログバックアップの実行時のみ必要になります。

NBDB で必要な /data ディレクトリの容量の一部は NBDB トランザクションログによって占められます。このトランザクションログはカタログバックアップが実行されるときにのみ切り捨てられます（削除されない）。カタログバックアップが定期的に実行されない場合ログは無制限に増加し続けます。

NBDB データベースに必要な容量を計算する例を次に示します。

1000 EMM ボリュームがバックアップされると仮定した場合、カタログに約 1,000,000 個のイメージが含まれているとすると、NBDB データベースに必要とされる/usr/openv/db/data の合計容量は次のとおりです。

160 MB + (2 KB * 1000 ボリューム) + (5 KB * 1000 SharedDisk イメージ) + (5 KB *10 SharedDisk ボリューム * 4 メディアサーバー) + (カタログの 1,000,000 イメージ * 2KB) = 2.1672 GB

同じ容量が /usr/openv/db/staging に必要になります。 NBDB データベースのサイズが増加するため、必要な容量は時間の経過とともに増加することがあります。

メモ: 160 MB の容量が事前に割り当てられます。

NBDB データベースに含まれているファイルとデータベース情報に関する追加の詳細が利用可能です。『Symantec NetBackup 管理者ガイド』を参照してください。


完全バックアップと増分バックアップに必要なメディアを計算する方法バックアップを保存して取得するために必要なテープ数を計算します。

テープの数は次によって決まります。

■ バックアップするデータの量

■ バックアップの頻度

■ 計画された保持期間

■ バックアップを保存するために使われるメディアの容量

時間の経過とともにサイトの作業負荷が増加すると予想される場合、拡張の計画を作成

することによって将来のアップグレードの負担を軽減できます。より多くのクライアントと

サーバーのサポートを展開できるように最初のバックアップ構造を設計します。現在よりも

厳しい要求に対応できるより高速で大容量のコンポーネントに投資します。

次の式を使用してテープ数を計算できます。

テープ数 = (バックアップするデータ量) / (テープ容量)

すべての必要条件に基づいて必要なテープ数を計算するには、上記の式を次のように

展開できます。

テープ数 = ((バックアップするデータ量) * (バックアップ頻度) * (保持期間)) / (テープ容量)

表 1-7 にいくつかの一般的なテープ容量をリストします。

表 1-7 テープ容量

カートリッジサイズ (GB 単位)、2:1 圧縮

カートリッジサイズ (GB 単位)、圧縮なし

カートリッジ形式

800400AIT-5

1600800DLT-S4/S4A

16080DLT-V4

800400LTO-3

1600800LTO-4

30001500LTO-5

1000500SAIT-1

1600800SAIT-2

600300SDLT 600/600A


カートリッジサイズ (GB 単位)、2:1 圧縮

カートリッジサイズ (GB 単位)、圧縮なし

カートリッジ形式

1000500TS1120 (3592E05)

1280640TS1130 (3592E06)

1000500T10000A (STK、Sun、Oracle)

20001000T10000B (STK、Sun、Oracle)

バックアップに必要なテープ数を計算する方法の例を次に示します。

この例では次の予備計算によって数が決まります。

■ 完全バックアップのサイズ = 500 GB * 4 (1 カ月あたり) * 6 カ月 = 12 TB

■ 増分バックアップのサイズ = (500 GB の 20%) * 30 * 1 カ月 = 3 TB

■ 追跡される合計データ = 12 TB + 3 TB = 15 TB



圧縮なしのテープ容量 = 400 GB

圧縮したテープ容量 = 800 GB

圧縮なし:

完全バックアップに必要なテープ = 12 TB/400 GB = 30

増分バックアップに必要なテープ = 3 TB/400 GB = 7.5 ~= 8

必要なテープの合計 = 30 + 8 = 38 テープ

2:1 圧縮:

完全バックアップに必要なテープ = 12 TB/800 GB = 15

増分バックアップに必要なテープ = 3 TB/800 GB = 3.75 ~= 4

必要なテープの合計 = 15 + 4 = 19 テープ

バックアップを保存するのに必要とされるテープライブラリサイズを計算する方法

バックアップをすべて保存するために必要なロボットライブラリのテープスロット数を計算

するには、前のセクションで計算されたバックアップテープ数にカタログバックアップとク

リーニングのためのテープ数を加算します。



式は次のとおりです。

必要なテープスロット = (バックアップに必要とされるテープ数) + (完全バックアップに必要とされるテープ数) + (カタログバックアップに必要とされるテープ数) + (クリーニングテープ数)

この式で求められるのは実用的な値です。とりわけ、十分なスクラッチテープが必要になります。バックアップ保持期間により、一般に最新のバックアップの後に最も古いバックアッ

プが期限切れになります。

注意: カタログバックアップのテープ数は、保持される完全カタログバックアップと増分カタログバックアップの合計です。

次の場合に追加のテープが必要になることがあります。

■ テープを複製するか、または特別な（非バックアップ）用途のために一部のメディアを

予約することを計画した場合、式にそれらのテープを加算します。

■ 今後のデータ拡張のために必要であるテープを追加します。新しいテープドライブが利用可能になったときに有効なアップグレードパスがシステムにあることを確かめま

す。

マスターサーバーを設計して設定する方法マスターサーバーを設計して設定するには、次の操作を実行します。

■ 初回バックアップ必要条件の分析を実行します。

p.14 の「バックアップ要件を分析する方法」を参照してください。

■ 次のトピックのマスターサーバーを設計するまでの手順に含まれる計算を実行します。


次の設計制約がわかっているときマスターサーバーを設計できます。

■ バックアップするデータ量

■ NetBackup カタログサイズ

■ 必要なテープドライブ数

■ 必要なディスクドライブ数

■ 必要なネットワーク数

設計制約があるとき、マスターサーバーを設定するための概要として次の手順を使用し

ます。


マスターサーバーを構成する方法

1 専用サーバーを取得します。

2 バックアップを保存するためにテープドライブとコントローラを追加します。

3 バックアップを保存するためと、OS と NetBackup カタログのためにディスクドライブとコントローラを追加します。

4 ネットワークカードを追加します。

5 メモリを追加します。

6 CPU を追加します。

メモ: 場合によっては、システムすべてをバックアップするようにサーバーを設計するのは実用的でないことがあります。バックアップ処理時間帯内にネットワークでバックアップを作成できない大規模サーバーが 1 つ以上あることがあります。このような場合、SharedStorage Option を使うローカル接続された独自のドライブを使ってそれらのサーバーをバックアップします。このセクションではマスターサーバーを設計する方法を説明しますが、この情報は他のサーバーにドライブとコンポーネントを追加するために使うことができ

ます。

最近のサーバーは NetBackup と正常に連携します。最近のサーバーはいずれも複数のコアを持つ複数の CPU を備えています。利用可能な CPU サイクルと RAM のうちNetBackup で使う割合は必要な処理に基づきます。

次のハードウェアのガイドラインを考慮してください。

■ プロセッサの種類とサーバーアーキテクチャは使う予定のオペレーティングシステム

に応じて最適なものを選んでください。

■ マルチコアのマルチプロセッササーバーのほうがシングルコアのシングルプロセッサ

サーバーよりもパフォーマンスが高くなります。ただし、コアやプロセッサの数が多すぎるとリソースを過剰に消費し、パフォーマンスが低下することがあります。通常は 10コアから 20 コアが最適です。

■ 低速なコアを多数使うよりも少数の高速なコアを使います。

■ サーバーとカタログをサポートするストレージの間に高速な I/O 帯域幅があることを確認してください。

CPU と RAM に関するハードウェアベンダーの推奨事項に必ず従ってください。たとえば、新しい DDR3 RAM は 6 GB 単位でインストールする必要があります。

マスターサーバーを設計するとき、パフォーマンスを最適化するには、専用サーバーから

始めます。さらに、サーバーが他のコンポーネントを処理できることを確認するためにサーバーのハードウェアの製造元に相談します。ほとんどの場合、サーバーは同時にサポートできるハードウェアの数と組み合わせに特定の制限があります。この最後の詳細を見落とすと、最良の計画が損なわれます。


必要とされるマスターサーバーの数を推定する方法いくつのマスターサーバーが必要になるか判断するには、次を考慮します。

■ マスターサーバーは定期的にすべてのメディアサーバーと通信できる必要がありま

す。メディアサーバーが多すぎる場合、マスターサーバーが過負荷になることがあります。

■ 事業関連の要件を考慮します。たとえば、異なるバックアップ処理時間帯を必要とする異なるアプリケーションがインストールにある場合、単一マスターはバックアップを絶

え間なく実行しなければならないことがあります。その結果、カタログのクリーニング、カタログバックアップ、または他の保守アクティビティのリソースは不十分なことがあり

ます。

■ 一般に、マスターサーバーごとのクライアント（別の物理ホスト）の数は NetBackup の重要な要因ではありません。クライアントが実行するバックアップ処理は NetBackupサーバーにほとんど影響がありません。例外はあります。たとえば、すべてのクライアントにデータベース拡張機能がある、またはすべてのクライアントが同時に

ALL_LOCAL_DRIVES バックアップを実行した場合、サーバーパフォーマンスは影響されることがあります。

■ 単一障害点が含まれないように設定を計画します。バックアップ処理の高可用性を確認するために十分な冗長性を提供します。テープドライブまたはメディアを多くすると、マスターサーバーごとに必要とされるメディアサーバーの数が減ることがありま

す。

■ 単一マスターサーバーで 12 時間の期間ごとに約 20,000 より多くのバックアップジョブを実行することを計画しないでください。

このトピックで後述する「拡張性への制限」を参照してください。

■ マスターが処理するメディアサーバーの数を次の表の概算の下限に制限することを

考慮します。

よく管理された NetBackup 環境ではこの表のリストにある数よりも多くのメディアサーバーを処理できることがあります。ただし、少数のより大規模なメディアサーバーではバックアップ操作がより効率的で管理しやすいことがあります。表の各シナリオのマスターサーバーごとのメディアサーバー数の変化は、提出されたジョブの数、多重化、

複数データストリーム、ネットワークキャパシティによって決まります。

表 1-8 マスターサーバーの CPU とメモリの概算

マスターサーバーごとのメディアサーバーの最大数

1 日あたりのジョブの最大数

最小の RAMCPU の数

2020004 GB2

5050008 GB4


マスターサーバーごとのメディアサーバーの最大数

1 日あたりのジョブの最大数

最小の RAMCPU の数

1001000016 GB8

これらの概算は、マスターサーバーがサポートする必要があるメディアサーバーとジョブ

の数に基づいています。この表はガイダンス専用です。テストデータとお客様の経験に基づいています。 RAM の量と CPU の数はサイト固有の他の要因に基づいて増やす必要がある場合もあります。

この表では、CPU は最新式の CPU と定義されます。例としては、x86 システム用の 3GHz CPU、Sun SPARC のような RISC プラットフォームでの同等の CPU があります。

概算を求めるときは次の点に注意してください。

■ CPU の種類NetBackup マスターサーバーには、シマンテック社はシングルマルチコアプロセッサの代わりに複数の別個の CPU の使用を推奨します。マルチコアプロセッサにある個々のコアではマスターサーバーで動作する CPU に負荷がかかる処理をサポートするためのリソースが不足しています。 2 つの物理的なデュアルコアプロセッサ（合計 4 つの CPU）は単一のクアッドコアプロセッサより望ましいです。

■ ジョブの定義

表 1-8 では、ジョブを個々のバックアップストリームとして定義しています。データベースとアプリケーションのバックアップポリシーと ALL_LOCAL_DRIVES 指示句を使うポリシーは、通常複数のバックアップストリーム（したがって複数のジョブ）

を同時に起動します。

■ 拡張性への制限

マスターサーバーのサイズに関係なく、バックアップジョブを起動できる理論上のお

およその最大速度は 1 秒ごとに 1 つです。したがって、ドメインは 12 時間に 43,000を超えるバックアップジョブは実行できません。

メモ: 実際には制限があるため、この理論値を達成できることはまれです。

背景: NetBackup ドメインは単一の NetBackup マスターサーバーの管理下にあるNetBackup メディアサーバーとクライアントコンピュータの数と定義されます。NetBackup ドメインは複数のサイトやデータセンターにまたがることがあります。単一のサイトやデータセンターは複数の NetBackup ドメインで構成される場合があります。 NetBackup ドメイン内の各バックアップジョブは 10 桁の一意の UTC タイムスタンプを含む識別子を受け取ります。各タイムスタンプは必ず一意であるため、利用可能なリソースに関係なく、起動できるバックアップジョブは 1 秒ごとに 1 つだけです。そのため、単一の NetBackup ドメインで 1 日に起動できるバックアップジョブの最大数は 86,400 個です。ほとんどの場合、ハードウェアリソースやインフラの制約により


86,400 個の上限に達することはありません。ドメインが十分なジョブに対応できない場合は、複数の NetBackup ドメインをサポートするように環境を設定することができます。

必要とされるメディアサーバーの数を推定する方法他のシステムをバックアップし、マスターサーバーの負荷を減らすか、または分散するた

めにメディアサーバーを使うことができます。 NetBackup で、ディスクストレージ制御とライブラリのロボット制御はマスターサーバーまたはメディアサーバーにある場合がありま

す。

必要とされるメディアサーバーの数を推定するガイドラインは次のとおりです。

■ 入出力のパフォーマンスは一般に CPU のパフォーマンスより重要です。

■ サーバーを選択するとき、CPU、入出力とメモリの拡張性を考慮します。

■ 必要な CPU 数を考慮します。CPU を推定する一般的なガイドラインは次のとおりです。（Sun Microsystems との）検証により、実用的な見積もり値として NetBackup メディアサーバー上で入出力される 1 MB/秒のデータごとに 5MHz の CPU 性能が必要であることが示されています。オペレーティングシステムと他のアプリケーションも CPUを使うことに留意します。この概算は NetBackup 自身が利用可能な性能の概算です。

例:

10 MB/秒でクライアントをテープにバックアップするシステムは、100 MHz の CPU性能を次のように必要とします。

■ ネットワークから NetBackup サーバーへのデータの移動に 50 MHz。

■ NetBackup サーバーからテープへのデータの移動に 50 MHz。

■ 必要なメモリ量を考慮します。

サーバーが Java GUI を実行する場合、少なくとも 4 GB の RAM を推奨します。NetBackup はローカルバックアップに共有メモリを使います。 NetBackup のバッファ利用率は必要なメモリ量に影響します。

NetBackup が必要とするものに加えて非 NetBackup 処理にメモリが必要なことに留意します。

メディアサーバーはディスク（関連したクライアント上）からストレージ（通常はディスク

かテープ）にデータを移動します。スループットを最大化するためにサーバーのサイズは慎重に決定する必要があります。最大のスループットはサーバーがテープデバイスのストリームを保つときに達成されます。

テープストリームについてより多くの情報が利用可能です。

p.149 の「データ転送パスでの NetBackup ストレージデバイスのパフォーマンス」を参照してください。

メディアサーバーのサイズについて考慮するべき追加の要因は次のとおりです。


■ ディスクストレージのアクセス時間

■ アダプタ（たとえば、SCSI）の速度

■ バス（たとえば、PCI）の速度

■ テープまたはディスクデバイスの速度

■ ネットワークインターフェース（たとえば、100BaseT）の速度

■ システム RAM の容量

■ 他のアプリケーション、ホストが非専用の場合

■ プラットフォームはすべてのネットワークインターフェースを動かし、そしてすべての

テープデバイスのストリームを保つことができる必要があります。

OpsCenter サーバーを設計する方法Symantec OpsCenter は、データ保護環境に関する詳しい情報を提供する Web ベースのソフトウェアアプリケーションです。包括的なレポートを生成することで、データバックアップ操作やアーカイブ操作の有効性をトラッキングできます。 OpsCenter は、NetBackupOperations Manager（NOM）と Veritas Backup Reporter（VBR）の機能を組み合わせたものです。

OpsCenter のインストールの計画と設計については、次のマニュアルを参照してください。

■ 『Symantec NetBackup OpsCenter 管理者ガイド』

■ 『NetBackup OpsCenter 7.6 Performance and Tuning Guide』

■ 『NetBackup 7.0 Additional Operational Notes』:http://www.symantec.com/docs/TECH76770

バックアップシステムを設計する方法: 概略時間帯内に大型システムの完全バックアップと増分バックアップをできるソリューションを

設計します。残ったバックアップは連日に渡って実行することもできます。

最終的にこのシステムでは最初にデザインした設計容量より大きくなることがあります。

次のトピックのガイドラインに従うことによって、戦略を設計し直さずにより多くの容量を将

来追加できます。


適切な設計を行うと、環境と共に拡張可能なバックアップ戦略を作成できます。

バックアップデバイスの数と場所は次のような要因に依存しています。

■ ターゲットシステムのデータの量

■ 利用可能なバックアップとリストアの時間帯



■ 利用可能なネットワークの帯域幅

■ バックアップデバイスの速度

1 つのドライブがバックアップの時間競合を引き起こした場合、別のものを追加して 2 つのドライブの合計レートを利用できます。代償は 2 つ目のドライブがメディアサーバーに余分な CPU、メモリと I/O の負荷を課すことです。

割り当てられた時間帯にバックアップが完了しなければ、バックアップ処理時間帯を増や

すか、または完全バックアップと増分バックアップの頻度を減らします。

もう 1 つのアプローチは、全面的なバックアップパフォーマンスを高速化するためにサイトを再設定することです。そのような変更を行う前に、現在のバックアップパフォーマンスを決定付けるものを推測します。サイトのネットワークとシステム構成をリストするか、または図表で示します。バックアップ設定のすべてのコンポーネントの最大データ転送率に注意し、バックアップ処理時間帯で必要なレートに対してこれらを比較します。このアプローチは最も遅いコンポーネントの特定に役立ち、その結果、ボトルネックの原因を特定

できます。ボトルネックがある可能性がある領域にはネットワーク、テープドライブ、クライアントの OS の負荷とファイルシステムのフラグメンテーションがあります。

NetBackup 容量計画の質問票システムの性質と使用方法を記入するためにこの質問票を使います。このデータはNetBackup クライアントの設定とバックアップ必要条件を判断するうえで役立ちます。

表 1-9 に、この質問票を示します。

表 1-9 バックアップ質問票

説明質問

コンピュータを識別する重複しない名前。各システムのホスト名か重複しない名前。

システム名

システム（たとえば、Sun、HP、IBM、一般的なコンピュータ）を作ったハードウェアベンダー。

ベンダー (Vendor)

例: Sun T5220、HP DL580、Dell PowerEdge 6850。model

例: Solaris 10、HP-UX 11i、Windows 2003 DataCenter。OS のバージョン

部屋、建物、キャンパスによって物理的な位置を識別します。建物または場所

利用できる内部と外部ストレージ容量の合計。合計ストレージ

使われた内部と外部ストレージ容量の合計。バックアップするデータの量が使われるストレージ容量と大幅に異なっていたら、そのこと

に注意してください。

使われたストレージ

40第 1 章 NetBackup の容量計画NetBackup 容量計画の質問票

説明質問

例: Hitachi、EMC、EMC CLARiiON、STK。外部アレイの種類

たとえば、100 MB、Gb、T1。 LAN がスイッチ機能を備えたネットワークであるかどうかを知っておく必要があります。

ネットワーク接続

たとえば、Oracle 8.1.6、SQL Server 7。データベース（DB）

ホットバックアップは、データベースのバックアップを作成する場合

に省略可能なデータベースエージェントを必要とします。

ホットバックアップが必要か

ファイル数と平均ファイルサイズはバックアップのスループットに大

きな影響を及ぼします。

サーバーのファイルのおおよ

その数と平均ファイルサイズ

例: Exchange サーバー、会計システム、ソフトウェア開発者のコードリポジトリ、NetBackup の重要なポリシー。

キーアプリケーション

例: 増分バックアップは月曜日から金曜日の 11 PM から 6 AM に実行されます。完全は日曜日の終日です。この情報は、潜在的なボトルネックとソリューションの設定方法を見つけるのに役立ちます。

バックアップ処理時間帯

(Backup Window)

組織のために次を特定してください。

■ リカバリポイント目標（RPO: Recovery Point Objective）。 RPOは、障害または中断が発生した後でデータをリカバリする必要

のある特定時点です。

■ リカバリの目標時間（RTO: Recovery Time Objective）。 RTOは、障害または中断が発生した後で組織のビジネスプロセスを

リストアするのにかかる時間の目標です。

リカバリの要件（RPO、RTO）

例: 増分バックアップに 2 週間、完全バックアップに 13 週間。この情報はライブラリで必要なスロットの数を変更する方法を判断する

うえで役立ちます。

保持ポリシー

現在バックアップのために使われるメディアの種類。既存のバックアップメディア

認識しておく必要がある特別な状況があるか。オペレーティングシステムの重要なパッチがあるか。 WAN 経由でバックアップをするか。バックアップはファイアウォールを通って移動する必要があるか。

コメント

41第 1 章 NetBackup の容量計画NetBackup 容量計画の質問票

マスターサーバー設定ガイドライン


■ ジョブスケジュールを制限する要因

■ 負荷分散を改善するジョブの送信

■ NetBackup ジョブの遅延

■ OpsCenter を使用したジョブの監視について

■ ストレージユニットの選択: パフォーマンスに関する注意事項

■ ディスクステージングと NetBackup パフォーマンスについて

■ ファイルシステム容量と NetBackup パフォーマンスについて

■ NetBackup カタログついて

■ カタログを管理するためのガイドライン

■ NetBackup カタログにメタデータを送信するためのバッチサイズの調整

■ カタログアーカイブ

■ イメージデータベースの圧縮

■ サーバーのマージ、分割、移動について

■ NetBackup ポリシーのパフォーマンスガイドライン

■ vxlogview のパフォーマンスを最適化する方法

■ レガシーエラーログフィールド

2

ジョブスケジュールを制限する要因多くの要求が NetBackup に同時に送信されると、NetBackup によるメモリの使用が増えます。要求の数がシステムの全体的なパフォーマンスに影響することがあります。このようなパフォーマンス低下は、指定のオペレーティングシステムのメモリ要求の処理方法

に関連があります。それは、NetBackup だけでなく、システムで現在動作するすべてのアプリケーションの機能に影響することがあります。

メモ: UNIX（Java）管理コンソールにおいて、何千ものジョブがある場合、アクティビティモニターは更新しないことがあります。この場合、NetBackup Java コマンド jnbSA で -mxオプションを指定してメモリの設定を変更することが必要な場合があります。『NetBackup管理者ガイド UNIX および Linux Vol.1』の INITIAL_MEMORY、MAX_MEMORY に関するサブセクションを参照してください。この状況はジョブを続行する NetBackup の機能には影響しないことに注意してください。

p.43 の「NetBackup ジョブの遅延」を参照してください。

負荷分散を改善するジョブの送信バックアップ処理時間帯が開始されるとき、シマンテック社はすべてのジョブを同時に開

始するよりも小さいグループでジョブの開始をスケジュール設定することを推奨します。

ジョブの送信を交互にした場合、NetBackup Resource Broker (nbrb) はジョブのリソースをよりすばやく割り当てることができます。

ジョブを最適にスケジュール設定できるかどうかは、多くの要因によって決まります。実験

が必要になることがあります。


NetBackup ジョブの遅延NetBackup ジョブはさまざまな理由で遅延する可能性があります。表 2-1 に、起きる可能性がある遅延の種類を示し、場合によっては可能な解決策を提案します。

43第 2 章マスターサーバー設定ガイドラインジョブスケジュールを制限する要因

表 2-1 NetBackup ジョブの遅延

説明と解決策（ある場合）ジョブの遅延の種類

NetBackup Policy Execution Manager（nbpem）は、バックアップポリシーのスケジュール時間帯が開始したときにバックアップを開始しないことがあります。この遅延は現在の時間に近い開始時間帯にスケジュールを定義するとき、または現在の時間に近い開始時間帯に既存のスケジュールを修正するとき

に起こることがあります。

たとえばバックアップを 6:00 PM に開始するように指定したスケジュールを 5:50 PM に作成したと仮定します。 5:55 PM にポリシー定義が完了します。 6:00 PM にそのポリシーのバックアップジョブが開始されることを予想しますが、開始されません。それどころか、ジョブは開始されるまで数分かかります。

説明は次のとおりです。ポリシーが変更されると NetBackup はポリシー変更イベントを受信してキューに投入しますが、ポリシーの更新間隔の設定に従ってこのイベントを定期的に処理します（ポリシーの更新間隔は［ホストプロパティ（Host Properties）］、［マスターサーバー（Master Server）］、［プロパティ（Properties）］、［グローバル設定（Global Settings）］で設定されます。デフォルトは 10 分です）。バックアップはポリシー定義が 5:55 PM に完了した後、最初に NetBackup がポリシーの変更を処理するまで開始されません。 NetBackup は 6:05 PM まで変更を処理しないことがあります。各ポリシーの変更で、NetBackup は必要な作業を判断し、それに応じて作業リストを更新します。

ジョブの開始の遅延

44第 2 章マスターサーバー設定ガイドラインNetBackup ジョブの遅延


複数のジョブがキューに投入され、一度に 1 つのジョブのみが動作する場合は、アクティビティモニターの［状態の詳細（State Details）］列を使ってジョブがキューに投入されている理由を確認します。

複数のジョブがキューに投入され、一度に 1 つのジョブのみが動作する場合は、ジョブが同時に動作することを可能にするために次の 1 つ以上を設定します。

■ ［ホストプロパティ（Host Properties）］、［マスターサーバー（Master Server）］、［プロパティ（Properties）］、［グローバル属性（Global Attributes）］、［1 クライアントあたりの最大ジョブ数（Maximum jobs per client）］（1 より大きい値である必要があります）。

■ ポリシー属性の［ポリシーごとにジョブ数を制限する（Limit jobs per policy）］（1 より大きい値である必要があります）。

■ スケジュール属性の［メディアの多重化（Media multiplexing）］（1 より大きい値である必要があります）。

メモ: この値を増加するとリストア時間に影響する可能性があることに留意してください。関連項目は下記のリンクから参照してください。

p.143 の「フラグメントサイズは多重化イメージのリストアにどのように影響するか」を参照してください。

p.146 の「NetBackup のリストアのパフォーマンスに関するその他の問題」を参照してください。

■ 次のストレージユニットのプロパティの確認。

■ ストレージユニットで複数のドライブを使えるか（［最大並列書き込みドライブ数（Maximumconcurrent write drives）］）。この値を増加する場合は、このストレージユニットに利用可能なドライブの数以下に値を設定してください。そうでない場合、ストレージユニットへのバックアップが動作している間、リストア処理とバックアップ以外の処理は動作できません。

■ ストレージユニットで多重化が有効か（［ドライブあたりの最大ストリーム数（Maximum streamsper drive）］）。最大 32 のジョブを 1 個のテープに同時に書き込むことができます。

メモ: 4 より大きい値を設定するとリストア速度が低下することがあるので、実際には全体的なパフォーマンスが低下する可能性があります。関連項目は下記のリンクから参照してください。


p.146 の「NetBackup のリストアのパフォーマンスに関するその他の問題」を参照してください。

たとえば複数のドライブがある場合は、単一のストレージユニットに対して複数のジョブを実行できます

（［最大並列書き込みドライブ数（Maximum concurrent write drives）］に 1 より大きい値を設定）。または、［ドライブあたりの最大ストリーム数（Maximum streams per drive）］に 1 より大きい値を設定している場合、単一のドライブに多重化を設定できます。［最大並列書き込みドライブ数（Maximum concurrentwrite drives）］と［ドライブあたりの最大ストリーム数（Maximum streams per drive）］の両方が 1 より大きい場合、複数のドライブに対して複数のストリームを実行できます。これによって、クライアントあたりの

最大ジョブ数が十分に大きくなります。

キューに投入済みの

ジョブの実行の遅延



共有ディスクのジョブは、ディスクボリュームがマウントされるのを待機する必要があるので、アクティブに

なるには一般にテープジョブより遅くなります。テープジョブはリソースが割り当てられるとすぐアクティブになります。

NetBackup ではジョブは次のようにアクティブになります。

■ テープジョブ

NetBackup Job Manager（nbjm）はジョブのために NetBackup Resource Broker（nbrb）にリソースを要求します。 nbrb はリソースを割り当て、そのリソースを nbjm に与えます。 nbjm はジョブをアクティブにします。 nbjm は bptm を開始する bpbrm を開始します。bptm はテープメディアをドライブにマウントします。

■ 共有ディスクのジョブ

NetBackup Job Manager（nbjm）は nbrb にジョブのリソースを要求します。 nbrb はリソースを割り当て、共有ディスクのマウントを開始します。マウントが完了すると、nbrb は nbjm にリソースを与えます。 nbjm はジョブをアクティブにします。

アクティブになるジョ

ブの遅延

次の状況のいずれかにおいて、他のストレージユニットが使用可能でなければジョブは失敗します。

■ ストレージユニットのメディアが構成されていないか、使用できません（期限切れなど）

■ 最大マウント数の設定を超えていました

■ 間違ったプールが選択されました

メディアが利用不能の場合、次を考慮してください。

■ 新しいメディアを追加します

■ または、メディアを使用できるようにするためにメディア設定を変更します（ボリュームプールや最大

マウント数を変更するなど）。

ストレージユニットのメディアが使用可能ではあるがビジー状態の場合、ジョブはキューに登録されます。

NetBackup アクティビティモニターの［状態の詳細（State Details）］の欄に、ジョブがキューに投入された理由（［メディア使用中（media are in use）］など）が表示されます（ジョブの詳細表示でも同じ情報を確認できます。ジョブを右クリックし、［詳細（Details）］を選択します）。メディアが使用中なら、メディアを使わずにジョブは動作します。

利用不能なメディア

によって引き起こさ

れるジョブの遅延



メディアサーバーが利用可能ではない場合、ジョブは NetBackup Job Manager（nbjm）によってキューに登録されることがあります。ジョブは通信のタイムアウトによってキューに登録されるのではなく、メディアサーバーが停止して NetBackup Resource Broker（nbrb）が後で再試行するために要求をキューに登録したことを EMM が認識した場合に登録されます。

他のメディアサーバーが利用可能でなければ、EMM は次の状況でジョブをキューに登録します。

■ メディアサーバーが EMM で構成されていても、サーバーが物理的に削除されたり、電源が入っていなかったり、ネットワークから接続解除されている場合

■ ネットワークが停止している場合

アクティビティモニターは［メディアサーバーがオフラインです（media server is offline）］など、ジョブがキューに登録される理由を表示します。 EMM でメディアサーバーが再びオンラインになったら、ジョブは開始されます。その間他のメディアサーバーが利用可能である場合、ジョブは別のメディアサーバーで動作します。

メディアサーバーが EMM で設定されていない場合、メディアサーバーの物理的な状態に関係なく、EMM はそのメディアサーバーを選択しません。他のメディアサーバーが利用可能でなければ、ジョブは失敗します。

永続的にシステムからメディアサーバーを削除するには、『NetBackup 管理者ガイド Vol.2』のメディアサーバーの廃止に関するセクションを参照してください。

メディアサーバーを

削除した後のジョブ

の遅延

OpsCenter を使用したジョブの監視についてSymantec OpsCenter を使用して NetBackup ジョブのパフォーマンスを監視できます。複数拠点における多数の NetBackup を管理、監視することもできます。

OpsCenter を使用したジョブの監視について詳しくは、『Symantec NetBackupOpsCenter 管理者ガイド』を参照してください。

ストレージユニットの選択: パフォーマンスに関する注意事項

バックアップポリシー、ストレージライフサイクルポリシー、ステージングストレージユニット、

Vault 複製、手動の複製など、NetBackup のさまざまなしくみがストレージデバイスにバックアップイメージを書き込みます。バックアップイメージをストレージに書き込むときに

NetBackup にストレージユニットを選択する方法を指示したり、または NetBackup がストレージユニットを選択するように指示できます。

表 2-2 に、ストレージユニットグループを指定する場合と、NetBackup がグループから選択することを許可する場合 (任意) の利点と欠点を示します。

47第 2 章マスターサーバー設定ガイドラインOpsCenter を使用したジョブの監視について

メモ: ストレージユニットの指定を絞って定義すると、NetBackup はストレージユニットをより速く割り当てることができ、ジョブをすぐに開始できます。

48第 2 章マスターサーバー設定ガイドラインストレージユニットの選択: パフォーマンスに関する注意事項

表 2-2 「任意」を使用する場合と特定のストレージユニットグループを指定する場合のパフォーマンスに関する注意事項

ストレージユニットグループ任意

一般に、「任意」は規模が小さくて単純な環境でのみ使用する

ようにします。

ほとんどのバックアップ操作では、デフォルトで NetBackup がストレージユニットを選択するようになっています (「任意」宛先ストレージ)。「任意」は比較的少数のストレージユニットとメディアサーバーが含まれている小さな設定に適していることがあり

ます。

ただし、次の場合に「任意」は推奨されません。

■ 多くのストレージユニットとメディアサーバーが含まれる設

定。「任意」は推奨されません。

■ ディスク技術を用いる設定 (AdvancedDisk、PureDisk、OpenStorage など)。これらのより新しいディスク技術がある場合、「任意」を指定すると、利用可能な最適なものを選

択するために NetBackup はすべての選択肢を分析します。「任意」は推奨されません。

一般的に、設定に多くのストレージユニット、ディスクプール内

の多くのボリューム、および多くのメディアサーバーが含まれ

ている場合、業務が集中する時間帯に多くのジョブ (バックアップか複製) が要求されると、「任意」によって必要となる詳細分析はジョブの開始を遅らせる可能性があります。そうならない

ようにするには、特定のストレージユニットを指定するか、また

はストレージユニットグループの使用によって NetBackup の検索を狭くします (ストレージユニットとグループがどのように定義されるかによります)。

「任意」の詳細については、『NetBackup 管理者ガイド Vol.1』を参照してください。

さらに、「任意」について次の点に注意します。

■ 「任意」を使用すると、NetBackup は次のセクションに記述されているように優先モードで動作します。NetBackup は最初に定義された順序で最初の利用可能なストレージユ

ニットを選択します。

■ 複数のコピー (インラインコピー) に、バックアップまたは複製のあらゆる方式から「任意」を指定しないでください。複

製の方式には、Vault、ステージングディスクストレージユニット、ライフサイクルポリシー、または管理コンソールやコ

マンドラインを介した手動複製があります。代わりに、特定

のストレージユニットを指定します。


ストレージユニットグループ任意

ほとんどの大規模な環境では、ストレージユニットグループの

使用を推奨します。ストレージユニットグループは NetBackupが特定のストレージユニットを選択するためのリストを含みま

す。これらのストレージユニットのみがジョブの候補となります。

次の方法のいずれかで、ストレージユニットを選択するために

ストレージユニットグループを設定できます。

■ 優先

リストの中で、ビジー状態や停止状態ではない十分なメディ

アを持つ最初のストレージユニットを選択します。

■ フェールオーバー

リストの中で、停止状態ではない十分なメディアを持つ最

初のストレージユニットを選択します。

■ ラウンドロビン

最近最も選択されていないストレージユニットを選択しま

す。

■ メディアサーバーの負荷分散

NetBackup はビジー状態のメディアサーバーにジョブを送信することを避けます。このオプションは BasicDisk ストレージユニットを含んでいるストレージユニットグループに

は利用できません。

NetBackup 管理コンソールで、ストレージユニットグループの新規作成または変更のダイアログボックスを使用できます。

NetBackup はローカルメディアサーバーがアクセスすることができるストレージユニットを優先します。詳しくは、ストレージユ

ニットグループの NetBackup オンラインヘルプと『SymantecNetBackup 管理者ガイド Vol. 1』を参照してください。

メモ: ストレージユニットとストレージユニットグループが絞って定義されていればいるほど、NetBackup はジョブを開始するためのリソースをより速く選択します。

多数のジョブが必要な複雑な環境では、次の選択が適してい

ます。

■ 1 ストレージユニットグループあたりの少数のストレージユニット。

■ 1 ストレージユニットあたりの少数のメディアサーバー。ストレージユニットでは、ドライブが複数のメディアサーバー間

で共有されるときに「任意」メディアサーバーを使用するこ

とを避けます。

■ ディスクプールにおける少数のディスクボリューム。

■ 少数の並列実行ジョブ。たとえば、少数の多重化または各

ストレージユニットの少数のテープドライブ。



ディスクステージングと NetBackup パフォーマンスについて

ディスクステージングはバックアップ速度を上げることができます。詳細については、

『NetBackup 管理者ガイド Vol.1』を参照してください。

ディスクステージングでは、最初にイメージをディスクに作成して、後で別のメディア形式

(ディスクステージングのスケジュールで定められている) にコピーすることができます。最終的なメディア形式は通常テープですが、ディスクであることがあります。この二段式処理

は、長期にわたってテープ型バックアップの利点を維持しながら、ディスク型バックアップ

の利点を一時的に利用します。

ディスクステージングは次の状況で配置します。

■ ソースシステムの読み込み速度が遅い、および

■ バックアップのサイズが小さい。このため、テープをマウント、位置設定、マウント解除

する時間が、バックアップを行う時間よりも非常に長くなる。

ファイルシステム容量と NetBackup パフォーマンスについて

各マスターサーバー、メディアサーバーとクライアントのログ記録やカタログエントリを記録

する十分なファイルシステム容量が NetBackup に必要です。ログ、またはカタログエントリが利用できるファイルシステム容量を使い切った場合、NetBackup は機能を停止します。

弊社としては、次を推奨します。

■ ボリューム管理を通してファイルシステムのサイズを増加できる必要があります。

■ NetBackup のマスターカタログを含んでいるディスクは、ミラー化、または RAID のハードウェアまたはソフトウェア技術で保護されている必要があります。

AdvancedDisk プールとメディアサーバー重複排除ディスクプールの容量が限界に近づくと、NetBackup は並列実行ジョブの数を 1 に制限し始めます。次の TechNote はこれらの状況についての情報を提供します。


NetBackup カタログついてNetBackup のカタログは NetBackup マスターサーバーのディスクに存在します。

51第 2 章マスターサーバー設定ガイドラインディスクステージングと NetBackup パフォーマンスについて


カタログの構成要素は次のとおりです。

イメージデータベースはバックアップされたものについての情報

を含んでいます。それはカタログの最も大きい部分です。イメージデータベース

このデータにはメディアの使用とバックアップ中に使われるボリュー

ムの情報を記述するメディアとボリュームに関するデータが含ま

れています。

リレーショナルデータベースの

NetBackup データ

NetBackup が使うポリシー、スケジュールと他のフラットファイルが含まれています。

NetBackup 設定ファイル

カタログについて詳しくは、『NetBackup 管理者ガイド Vol.1』の、カタログの保守作業およびパフォーマンスの最適化に関する説明を参照してください。

マスターサーバーの NetBackup のカタログは一定時間にわたり増加し、最終的に単一テープには収まらなくなります。

図 2-1 に、マスターサーバーの NetBackup カタログの最初のいくつかのディレクトリレベルのレイアウトを示します。

52第 2 章マスターサーバー設定ガイドラインNetBackup カタログついて

図 2-1 マスターサーバー（UNIX）のディレクトリのレイアウト

/netbackup/db /var

/usr/openv/

/netbackup/vault

Relational database files

Image databaase

License key andauthentication information

Configuration files

/class

server.confdatabases.conf

/var/global

/class_template

/client

/config

/error

/images

/jobs

/media

/vault

/client_1 /client_2

/db/data

NBDB.dbEMM_DATA.dbEMM_INDEX.dbDARS_DATA.dbDARS_INDEX.dbDBM_DATA.dbDBM_INDEX.dbNBDB.logBMRDB.dbBMRDB.logBMR_DATA.dbBMR_INDEX.dbvxdbms.conf

/ss

カタログを管理するためのガイドラインたとえば、次の範囲を指定するとします。

■ カタログのバックアップ

カタログバックアップは、通常のバックアップ処理が行われる間に実行できます。カタログバックアップはポリシーに基づいており、複数のテープをまたぐことができます。

増分バックアップも可能であるため、大きいカタログのカタログバックアップの時間を

大幅に減らすことができます。

53第 2 章マスターサーバー設定ガイドラインカタログを管理するためのガイドライン

メモ: シマンテック社は定期的な完全バックアップを併用する、スケジュールに基づいた増分カタログバックアップを推奨します。

■ カタログを別のファイルシステムに保存

NetBackup のカタログはバックアップ頻度、保持期間、バックアップされたファイルの数によって急激に増加することがあります。 NetBackup カタログデータ自体のファイルシステムでデータを使うと、カタログの増加は他のディスクリソース、ルートファイル

システム、オペレーティングシステムに影響しません。

カタログの移動についての情報が利用できます。

p.57 の「イメージデータベースの圧縮」を参照してください。p.27 の「NetBackup イメージデータベースのサイズを計算する方法」を参照してください。

■ NetBackup リレーショナルデータベースのファイルの場所を変更NetBackup リレーショナルデータベースのファイルの場所は、パフォーマンスを改善するために複数のディレクトリに変更または分割できます。たとえば、トランザクションログファイル（NBDB.log）を物理的に別のドライブに配置することによって、ディスク障害に対する保護が強化され、ログファイルへの書き込み効率が高くなります。

『NetBackup 管理者ガイド Vol.1』の、NetBackup リレーショナルデータベースに関する付録の手順を参照してください。

■ カタログを圧縮するための遅延を設定

このパラメータのデフォルト値は 0 です。これは NetBackup がカタログを圧縮しないことを意味します。カタログのサイズが増加した場合は、このパラメータに 10 から 30日間の値を使うことができます。古いバックアップをリストアすると、NetBackup はパフォーマンスへの影響を最小限にして、必要に応じて自動的にファイルを解凍しま

す。

p.57 の「イメージデータベースの圧縮」を参照してください。

■ メタデータをカタログに送信するためのバッチサイズを調整

この設定は、カタログバックアップのパフォーマンスではなく、全体的なバックアップの

パフォーマンスに影響します。

p.55 の「NetBackup カタログにメタデータを送信するためのバッチサイズの調整」を参照してください。

■ カタログレイアウトのためのベストプラクティスについては、シマンテック社の次のドキュ

メントを参照してください。


54第 2 章マスターサーバー設定ガイドラインカタログを管理するためのガイドライン


NetBackup カタログにメタデータを送信するためのバッチサイズの調整

バックアップ時に NetBackup カタログにメタデータを送信するのに使われるバッチサイズを変更できます。カタログにメタデータを送信するためのカタログバックアップ専用のバッチサイズを変更するための設定は NetBackup 7.1 で追加されたことにも注意してください。

バッチサイズの変更は以下の場合に役立ちます。

■ カタログにファイルを追加するクエリーが完了するのに 10 分以上かかるためにバックアップが失敗する場合。

この場合、バックアップジョブは失敗し、カタログにファイルを追加しようとして失敗し

たことを示すメッセージが bpbrm ログに記録されます。 bpdbm ログにはこのようなメッセージは記載されないことに注意してください。

■ バックアップするフォルダが多数の小さいファイルかサブフォルダを含んでいる場合

のバックアップのパフォーマンスを改善する場合。

55第 2 章マスターサーバー設定ガイドラインNetBackup カタログにメタデータを送信するためのバッチサイズの調整

カタログにメタデータを送信するためのバッチサイズを調整する方法

1 次のファイルを作成します。

FlashBackup-Windows ポリシーの場合（NetBackup for VMware と NetBackupfor Hyper-V を含む）:

/usr/openv/netbackup/FBU_MAX_FILES_PER_ADD

他のすべてのポリシー形式の場合（UNIX 用の FlashBackup を含む）:

/usr/openv/netbackup/MAX_FILES_PER_ADD

2 ファイルに、各バッチでカタログに送信されるメタデータエントリの数の値を入力しま

す。 1 から 100,000 の値を指定できます。

FlashBackup-Windows の場合、バッチごとのエントリ数のデフォルトは 95,000 です（FBU_MAX_FILES_PER_ADD）。他のすべてのポリシー形式の場合、バッチごとのエントリ数のデフォルトは 5,000 です（MAX_FILES_PER_ADD）。

FBU_MAX_FILES_PER_ADD の場合は、デフォルトの 95,000 より小さい数を試してください。数を減らすと、大きすぎるパケットによって引き起こされるタイムアウトを避けることができます。

MAX_FILES_PER_ADD の場合は、デフォルトの 5,000 より大きい数を試してください。数を増やすと、特にメディアサーバーとマスターサーバー間の接続が遅いときにバックアップのパフォーマンスが改善することがあります。

入力した設定は、この変更を行った後に開始されるバックアップのみに影響します。

MAX_FILES_PER_ADD ファイルではカタログバックアップ（ポリシー形式 NBU-Catalog）のためのバッチサイズも設定することに注意してください。 NetBackup 7.1 以降では、他のすべてのポリシー形式とは関係なくカタログバックアップのためのバッチサ

イズを変更するのに CAT_BU_MAX_FILES_PER_ADD ファイルを使うことができます（次の手順を参照）。

56第 2 章マスターサーバー設定ガイドラインNetBackup カタログにメタデータを送信するためのバッチサイズの調整

カタログにメタデータを送信するための NBU-Catalog バックアップ用のバッチサイズを調整する方法（NetBackup 7.1 以降）


/usr/openv/netbackup/CAT_BU_MAX_FILES_PER_ADD

2 ファイルに、カタログバックアップの場合に各バッチでカタログに送信されるメタデー

タエントリの数の値を入力します。 1 から 100,000 の値を指定できます。

デフォルトは最大数です（バッチごとのエントリ数 100,000）。これより小さい数を試してください。

このファイルの設定は NetBackup 7.1 以降のカタログのバックアップにのみ適用されることに注意してください。他のポリシー形式の場合は、前の手順で説明されているように FBU_MAX_FILES_PER_ADD ファイルと MAX_FILES_PER_ADD ファイルを使ってください。

カタログアーカイブカタログバックアップの実行に時間がかかる場合は、カタログアーカイブの使用を検討し

てください。

カタログアーカイブはセカンダリストレージに大きいカタログ .f ファイルを再配置することによって、オンラインカタログデータのサイズを減らします。NetBackup 管理にはスケジュールされた定期的なカタログバックアップが必要ですが、大量のカタログデータがな

ければバックアップはより速くなります。

カタログのアーカイブについて詳しくは、『Symantec NetBackup 管理者ガイド Vol.1』を参照してください。

イメージデータベースの圧縮カタログのイメージデータベース部分が利用可能なディスク領域に対して大きすぎる場

合、次のどちらかを行うことができます。

■ イメージデータベースを圧縮する

■ イメージデータベースを移動する

詳しくは、『NetBackup 管理者ガイド Vol.1』の「イメージカタログの移動」と「イメージカタログの圧縮」を参照してください。


バックアップが成功したかどうかににかかわらず、NetBackup は各バックアップ後にイメージデータベースを圧縮します。圧縮は session_notify スクリプトとイメージデータベースバックアップの実行の直前に起こります。実際のバックアップセッションは圧縮が完了す

るまで延長されます。

57第 2 章マスターサーバー設定ガイドラインカタログアーカイブ

サーバーのマージ、分割、移動についてマスターサーバーはシステムのバックアップ情報をスケジュールし、メンテナンスします。

EMM（Enterprise Media Manager）とデータベースは、構成に含まれるすべてのサーバーの集中型デバイスそしてメディア関連の情報をメンテナンスします。デフォルトでは、EMM サーバーと EMM のデータを含んでいる NetBackup リレーショナルデータベース（NBDB）はマスターサーバーにあります。

注意: サーバーをマージ、分割、変換する手順は複雑であり、最終的な手段と考えてください。 NetBackup データベース操作の詳しい知識が必要になります。これらの手順のサポートについてはご購入先にお問い合わせください。

NetBackup ポリシーのパフォーマンスガイドライン以下のポリシー項目は、パフォーマンスに関係する場合があります。

表 2-3

ガイドラインポリシー項目

たとえば、次の範囲を指定するとします。

■ ファイルリストで過度のワイルドカードを使わない

ワイルドカードが使われるとき、NetBackup はワイルドカードに対してあらゆるファイル名を比較します。その結果、NetBackup のパフォーマンスが低下する可能性があります。インクルードリストまたはエクスクルードリストに /tmp/*（UNIX）または C:¥Temp¥*（Windows）を配置するかわりに /tmp/ またはC:¥Temp を使います。

■ 大きい不要なファイルを除外するためにエクスクルードリストを使う

保存する必要のないファイルにエクスクルードリストを使うことによって、バックアップのサイズを減らしま

す。たとえば、一時ファイルを除外することができます。重要なファイルが誤って除外されないように、エクスクルードリストのエントリに絶対パスを使います。エクスクルードリストへファイルを追加する前に、ファイルが安全に除外できることを、影響があるユーザーと確認します。災害（またはユーザーエラー）があった場合、ファイルをリカバリできないことのほうが余分なデータをバックアップするよりもっとコストがかかり

ます。

すべてのローカルドライブがバックアップされることをポリシーが指定するとき（ALL_LOCAL_DRIVES）、nbpem は親ジョブ（nbgenjob）を開始します。 nbgenjob はクライアントに接続し、bpmount -i を実行してマウントポイントのリストを取得します。それから nbpem は各マウントポイントの自身の重複しないジョブ識別番号でジョブを開始します。次にクライアント bpbkar は各ジョブのストリームを開始します。そこでようやく NetBackup はエクスクルードリストを読み込みます。全体のジョブが除外されるとき、bpbkarはバックアップに 0 ファイル中 0 ファイル送ったこと表明するステータス 0 で終了します。結果のイメージファイルは他の正常なバックアップのイメージと同じように扱われます。イメージのヘッダーファイルで指定されている期限切れの日になると、イメージは通常どおり期限切れになります。

■ ファイルがすでに NetBackup のデータベースエージェントバックアップによってバックアップ済みの場合は、エクスクルードリストを使って、通常のバックアップからファイルを除外する

インクルードリス

トとエクスクルー

ドリスト

58第 2 章マスターサーバー設定ガイドラインサーバーのマージ、分割、移動について

ガイドラインポリシー項目

カタログバックアップ用に、災害の場合にサイトのリカバリに重要となるポリシーを識別してください。カタログバックアップと重要なポリシーの詳細については、『NetBackup 管理者ガイド Vol.1』を参照してください。

p.53 の「カタログを管理するためのガイドライン」を参照してください。

クリティカルポリ

シー

変更されていないファイルをバックアップする頻度を最小化します。また、帯域幅、メディア、その他のリソー

スの消費を最小化します。そうするには、完全バックアップを毎月または 3 カ月ごとに制限し、週単位の累積増分バックアップと日単位の増分バックアップで補います。

スケジュールの

頻度

vxlogview のパフォーマンスを最適化する方法vxlogview コマンドは統合ログ（VxUL）によって作成されるログを表示するために使われます。 vxlogview コマンドでログファイル ID を指定するために -i オプションを使うと、ログメッセージをより速く表示します。

たとえば、

vxlogview -i nbrb -n 0

この例では、-i nbrb は NetBackup Resource Broker プロセス（オリジネータ ID 118）のファイル ID を指定します。 vxlogview は、nbrb によって作成されたログファイルのみを検索します。つまり、ログファイル名にオリジネータ ID 118 を含んでいるファイルのみを検索します。検索しなければならないログファイルを制限することによって、vxlogviewは結果をより速く戻すことができます。

-i オプションは、ファイル名にオリジネータ ID を指定して統合ログファイルを作成するNetBackup プロセスでのみ機能することに注意してください。そのようなプロセスはサービスと呼ばれます。次はそのようなログファイル名の例です。

UNIX の場合:

/usr/openv/logs/51216-118-2201360136-041029-0000000000.log

Windows の場合:

install_path¥logs¥51216-118-2201360136-041029-0000000000.log

-118- は nbrb のオリジネータ ID です。

一般に、NetBackup 管理コンソールのアクティビティモニターの［デーモン（Daemons）］タブ（UNIX）または［サービス（Services）］タブ（Windows）で、NetBackup プロセスはサービスとして表示されます。

重要な注意事項: vxlogview -i オプションで指定したプロセスがサービスでない場合（ファイル名にオリジネータ ID がついたログファイルを書き込みません）、vxlogview は

59第 2 章マスターサーバー設定ガイドラインvxlogview のパフォーマンスを最適化する方法

［ログファイルが見つかりません。（No log files found）］を戻します。その場合、-i の代わりに -o オプションを使います。次に例を示します。

vxlogview -o mds -n 0

この例では、vxlogview は mds（EMM メディアとデバイスの選択コンポーネント）によってログに記録されるメッセージのすべての統合ログファイルを検索します。

より多くの vxlogview の例については、『NetBackup トラブルシューティングガイド』を参照してください。

レガシーエラーログフィールドこの項は次の場所に書き込まれるレガシーログファイルのフィールドについて説明しま

す。

UNIX の場合

/usr/openv/netbackup/db/error

Windows の場合

install_path¥NetBackup¥db¥error

UNIXでは、エラーディレクトリの最新のファイルへのリンクがあります。リンクはdaily_messages.log という名前です。

これらのログの情報が NetBackup の［すべてのログエントリ (All Log Entries)］レポートの基準になります。レガシーログと統合ログ (VxUL) について詳しくは、『NetBackup トラブルシューティングガイド』を参照してください。

エラーログのサンプルメッセージを次に示します。

1021419793 1 2 4 nabob 0 0 0 *NULL* bpjobd TERMINATED bpjobd

表 2-4 はこのメッセージの各種のフィールドを定義します (フィールドは空白によって区切られます)。

表 2-4 daily_messages ログフィールドの意味

値 (Value)定義フィールド(Field)

1021419793 (= 1970 年以来の秒数)このイベントが起きた時間 (ctime)1

1エラーデータベースエントリバージョン2

2メッセージの種類3

60第 2 章マスターサーバー設定ガイドラインレガシーエラーログフィールド

値 (Value)定義フィールド(Field)

4エラーの重大度:

1: 不明 (Unknown)

2: デバッグ (Debug)

4: 情報 (Informational)

8: 警告 (Warning)

16: エラー (Error)

32: 重要 (Critical)

4

nabobエラーが報告されたサーバー5

0ジョブ ID (ログエントリに適切である場合は含まれる)

6

0(省略可能なエントリ)7

0(省略可能なエントリ)8

*NULL*エラーが起きたクライアント (該当する場合)。それ以外は *NULL*

9

bpjobdエラーメッセージを生成した処理10

TERMINATED bpjobdエラーメッセージのテキスト11

表 2-5 はログメッセージの第 3 フィールドであるメッセージの種類の値をリストします。

表 2-5 メッセージの種類

メッセージの種類の定義種類の値

不明 (Unknown)1

全般 (General)2

バックアップ (Backup)4

アーカイブ (Archive)8

取得 (Retrieve)16

セキュリティ (Security)32

バックアップステータス (Backup status)64

メディアデバイス (Media device)128

61第 2 章マスターサーバー設定ガイドラインレガシーエラーログフィールド

メディアサーバー設定ガイドライン


■ ネットワークと SCSI/FC のバス帯域幅

■ 利用可能な NetBackup メディアがない場合

■ メディアエラーのしきい値について

■ media_error_threshold の調整

■ テープの I/O エラーの処理について

■ Solaris 再起動のない st ドライバの再ロード

■ NetBackup Media Manager ドライブの選択について

ネットワークと SCSI/FC のバス帯域幅ファイバーチャネル接続がサポートできるテープドライブの数を設定します。クライアント

からメディアサーバーに転送されるデータの量に留意します。データストリームがテープ

ドライブ容量と一致しそれを維持すると、テープドライブの消耗は大幅に減り効率が高ま

ります。

メモ: インバウンドネットワーク接続と SCSI/FC バス両方に、すべてのテープドライブに配信するのに十分な帯域幅があることを確かめます。

例 :

iSCSI (360 GB/時間)

2 個の LTO gen 3 ドライブ、それぞれおよそ 300 GB/時間 (2:1 圧縮)

3

この例では、テープドライブは iSCSI バスによって提供される速度より速い速度を必要とします。この設定では、1 つのテープドライブのみストリーミングを行います。2 つ目のiSCSI バスを追加するか、または効率的にテープドライブへデータを入れるのに十分な速度の接続へ移動します。

ネットワーク帯域幅について詳しい情報を入手可能です。

p.24 の「ネットワークに必要なデータ転送速度を計算する方法」を参照してください。


利用可能な NetBackup メディアがない場合一部のバックアップエラーは利用可能なメディアがないために発生します。その場合、メ

ディアの状態を調べるために次のスクリプトを実行し、NetBackup の［メディアリスト (MediaList)］レポートを実行します。

UNIX の場合

/usr/openv/netbackup/bin/goodies/available_media

Windows の場合

install_path¥NetBackup¥bin¥goodies¥available_media

NetBackup の［メディアリスト (Media List)］レポートは一部のメディアが凍結され、したがってバックアップに使用できないことを示すことがあります。

再発する I/O エラーは、NetBackup によるメディアの凍結を引き起こすことがあります。『NetBackup トラブルシューティングガイド』はこの問題に対処する方法を説明します。たとえば、NetBackup のエラーコード 96 に関する説明を参照してください。

NetBackup のエラーのしきい値を設定することもできます。

メディアエラーのしきい値について読み込み、書き込み、配置エラーが発生するたびに、NetBackup は時間、メディア ID、エラーの種類、ドライブのインデックスを EMM データベースに記録します。次にNetBackup はそのメディアが過去「n」時間の内に同じエラーが「m」回あったかどうかを参照するためにスキャンします。変数「m」は media_error_threshold として知られているチューニングパラメータです。media_error_threshold のデフォルト値は 2 回のエラーです。変数「n」は time_window パラメータ (デフォルト値は 12 時間) です。

テープボリュームのエラーが media_error_threshold より多い場合、NetBackup は適切な処理を実行します。

63第 3 章メディアサーバー設定ガイドライン利用可能な NetBackup メディアがない場合

表 3-1 テープボリュームエラーの数が media_error_threshold を超えた場合

NetBackup の処理状況

NetBackup は次の処理を行います。

■ ボリュームステータスを FROZEN に設定する■ 異なるボリュームを選択する

■ エラーを記録する

ボリュームがバックアップ用に割り当てら

れていない場合

NetBackup は次の処理を行います。

■ ボリュームを SUSPENDED に設定する■ 現在のバックアップを中止する

■ エラーを記録する

ボリュームが、NetBackup のメディアカタログ内に存在し、バックアップ用に選択

されていた場合

media_error_threshold の調整NetBackup メディアエラーのしきい値を次のように調整できます。

NetBackup メディアエラーのしきい値を調整する方法

◆ メディアサーバーで nbemmcmd コマンドを使います。

UNIX の場合

/usr/openv/netbackup/bin/admincmd/nbemmcmd -changesetting

-time_window unsigned integer -machinename string

-media_error_threshold unsigned integer -drive_error_threshold

unsigned integer

Windows の場合

install_path¥NetBackup¥bin¥admincmd¥nbemmcmd.exe -changesetting

-time_window unsigned integer -machinename string

-media_error_threshold unsigned integer -drive_error_threshold

unsigned integer

たとえば、-drive_error_threshold がデフォルト値の 2 に設定されている場合、ドライブは 12 時間に 3 回のエラーで停止します。-drive_error_threshold が6 に設定されれば、同じ 12 時間に 7 回のエラーでドライブが停止します。

NetBackup はテープボリュームを凍結するか、またはこれらの値が超過するドライブを停止します。nbemmcmd コマンドの詳細については、マニュアルページまたは『NetBackup コマンド』を参照してください。

64第 3 章メディアサーバー設定ガイドラインmedia_error_threshold の調整

テープの I/O エラーの処理について

メモ: このトピックは NetBackup が失敗するバックアップまたはリストアを再試行する回数とはまったく関係ありません。その状況はバックアップの場合はグローバルな設定パラメータ「バックアップ試行」とリストアの場合は bp.conf エントリ RESTORE_RETRIES によって制御されます。

ここで説明するアルゴリズムはテープの I/O エラーによりメディアを凍結するかドライブを停止するかを決定します。

読み込み、書き込み、配置エラーがテープで発生したとき、オペレーティングシステムに

よって返されるエラーはそのエラーがテープまたはドライブのどちらから発生したかは識

別しません。指定の時間枠のすべてのバックアップのエラーを防ぐために、bptm は過去の履歴からテープボリュームまたはドライブの不良を識別しようとします。

そうするには、bptm は次のロジックを使います。

■ I/O エラーが読み込み、書き込み、配置で発生するたびに、bptm は次のファイルにエラーを記録します。

UNIX の場合

/usr/openv/netbackup/db/media/errors

Windows の場合

install_path¥NetBackup¥db¥media¥errors

エラーメッセージはエラーの時間、メディア ID、ドライブのインデックス、エラーの種類を含みます。このファイルのエントリの例は次のとおりです。

07/21/96 04:15:17 A00167 4 WRITE_ERROR

07/26/96 12:37:47 A00168 4 READ_ERROR

■ エントリが作成されるたびに、過去のエントリがスキャンされます。スキャンは同じメディア ID かドライブで過去「n」時間にこの種類のエラーがあったかどうかを判断します。「n」は time_window として知られています。デフォルト時間帯は 12 時間です。time_window エントリの履歴検索の間に、EMM はメディア ID、ドライブ、または両方に一致する過去のエラーを記録します。目的はエラーの原因を判断することです。たとえば、メディア ID で複数のドライブに書き込みエラーが出た場合、テープボリュームが不良の可能性があり、NetBackup はそのボリュームを凍結します。複数のメディア ID で同じドライブに特定のエラーが出た場合、ドライブは「停止」状態になります。同じメディア ID の同じドライブで過去エラーのみ出た場合、EMM はボリュームの不良と仮定しそれを凍結します。

■ 凍結または停止操作は最初のエラーで実行されません。

65第 3 章メディアサーバー設定ガイドラインテープの I/O エラーの処理について

他の 2 つのパラメータ、media_error_threshold と drive_error_threshold に注意してください。両方のパラメータのデフォルトは 2 です。凍結または停止が起こるには、しきい値の数より多いエラーが起きる必要があります。デフォルトでは、同じドライブまたはメディア ID でその時間帯に少なくとも 3 つのエラーが発生する必要があります。

media_error_threshold または drive_error_threshold のどちらかのしきい値が 0 の場合、I/O エラーが最初に発生したときに凍結または停止が発生します。media_error_threshold が最初に確認されるため、値が両方とも 0 の場合、凍結が停止より優先されます。これらの値を 0 に設定することは推奨しません。デフォルト値への変更は、正当な理由がないかぎり推奨しません。明らかな変更の1 つはしきい値ファイルに非常に大きい数を設定することです。そのファイルに大きい数を設定すると、テープの「凍結」またはドライブの「停止」などのしくみが無効にな

り発生しません。

凍結と停止は主にバックアップに役立つように意図されています。読み込みエラーがリストア中に発生した場合、メディアの凍結はほとんど効果がありません。 NetBackupはそれでもリストアを実行するためにテープにアクセスします。リストアについては、不良なドライブの停止が役立つことがあります。

テープのバックアップの調整について詳しくは、次のトピックを参照してください。

p.63 の「メディアエラーのしきい値について」を参照してください。


p.22 の「必要なテープドライブの数を計算する方法」を参照してください。


p.33 の「バックアップを保存するのに必要とされるテープライブラリサイズを計算する方法」を参照してください。

Solaris 再起動のない st ドライバの再ロードdevfsadmd デーモンは Solaris のデバイス管理を拡張します。このデーモンはブート処理の間にカーネルのイベント通知に応じて動的にデバイスを再設定できます。

/usr/sbin にある devfsadm は devfsadmd のコマンド形式です。 devfsadm はdrvconfig（物理デバイスツリー /devices の管理用）と devlinks（/dev の論理デバイスの管理用）を置換します。 devfsadm は /usr/sbin/tapes のような特定の種類のデバイスクラスのコマンドも置換します。

サーバーを再起動しないで、/kernel/drv/st.conf ファイルを変更した後 NetBackupのテープデバイスを作成し直すことができます。

66第 3 章メディアサーバー設定ガイドラインSolaris 再起動のない st ドライバの再ロード

再起動しないで st ドライバを再ロードする方法

1 NetBackup と Media Manager デーモンをオフにします。

2 カーネルで st ドライバのモジュール ID を入手します。

/usr/sbin/modinfo | grep SCSI

モジュール ID は SCSI テープドライバに対応する行の最初のフィールドです。

3 カーネルから st ドライバをアンロードします。

/usr/sbin/modunload -I "module id"

4 次のコマンドのすべてではなく 1 つを実行します。

/usr/sbin/devfsadm -I st

/usr/sbin/devfsadm -c tape

/usr/sbin/devfsadm -C -c tape

未解決の論理リンクが /dev にある場合、最後のコマンドを使ってクリーンアップを実行します。

devfsadm コマンドはテープデバイスの /devices のデバイスノードと /dev のデバイスリンクを作成し直します。

5 st ドライバを再ロードします。

/usr/sbin/modload st

6 NetBackup と Media Manager デーモンを再起動します。

NetBackup Media Manager ドライブの選択についてNetBackup EMM は、使用するストレージユニットを判断するとき、ストレージユニットの選択基準と一致するドライブを選択しようとします。基準は、たとえば、メディアサーバー、

ロボット番号、ロボット形式、または密度であることがあります。

次の点に注意してください。

■ EMM はアンロードされたドライブよりもロードされたドライブを優先します (ロードされたドライブはドライブへのメディアのロードのオーバーヘッドを削除します)。

■ ロードされたドライブが利用可能でない場合、EMM はそのジョブに最適で使用可能なドライブを選択しようとします。

■ 一般に、EMM は共有ドライブよりも非共有ドライブを優先し、最も長い間使用されていないドライブを選択しようとします。

67第 3 章メディアサーバー設定ガイドラインNetBackup Media Manager ドライブの選択について

メディア設定ガイドライン


■ 専用および共有のバックアップ環境について

■ NetBackup メディアプールの提案

■ ディスクとテープ: パフォーマンスに関する注意事項

■ NetBackup の重複排除に関する情報

専用および共有のバックアップ環境についてバックアップ環境は専用にも共有にもできます。


■ 専用 SAN は安全ですが高価です。

■ 共有の環境はより安価ですが、安全を確保するにはより多くの操作が必要です。

■ データベースのある SAN のインストールは RAID 1 のアレイのパフォーマンスを必要とすることがあります。ファイル構造をバックアップするインストールの要件は RAID5 または NAS で満たされることがあります。

NetBackup メディアプールの提案メディアプール (以前はボリュームプールとして知られている) の適切な使用方法は次のとおりです。

■ スクラッチテープを管理するスクラッチプールを設定します。スクラッチプールが存在

すると、EMM はそのプールから利用可能なボリュームがない他のプールにボリュームを移動できます。

■ goodies ディレクトリの available_media スクリプトを使用します。スクリプトにavailable_media レポートを入れることができます。スクリプトはファイルにレポートの

4

出力をリダイレクトし、管理者にファイルを毎日または毎週電子メールで送ります。ス

クリプトは完全、凍結、停止状態などのテープの追跡に役立ちます。スクリプトによっ

て、カスタムレポートを生成するために available_media レポートの出力をフィルタ処理することもできます。

メディアを監視するために、Symantec OpsCenter を使用することもできます。たとえば、OpsCenter は利用可能なメディアの数や、凍結または停止しているメディアの割合 (%) に基づいて警告を発行することができます。

■ クリーニングテープ用に None プールを使用します。

■ 必要とするより多くのプールを作成しないでください。ほとんどの場合、6 つから 8 つのプールのみが必要です。プールにはグローバルなスクラッチプール、カタログバッ

クアッププール、インストールによって作成されるデフォルトプールが含まれます。余

りにも多くのプールが存在する場合はそのプールのライブラリ容量がフラグメント化さ

れます。その結果、ライブラリは部分的に空きがなくなった多くのテープでいっぱいに

なります。

ディスクとテープ: パフォーマンスに関する注意事項今ではディスクは一般的なバックアップメディアです。ディスクに保存されたバックアップ

データは、一般により速いリストアを提供します。

パフォーマンスのためのディスク型ストレージのチューニングとテープ型ストレージのチュー

ニングは類似しています。サイトの最適バッファの設定はその設定に応じて異なることが

あります。すべてのテストを実行することでこれらの設定が特定されます。

多くの増分バックアップがあり、データ変更の割合が小さい場合は、ディスク型ストレージ

が有用である可能性があります。増分コピー内のデータの量がテープに効率的に書き込

むことができる量か不明な場合は、ディスクストレージを検討します。ディスクへデータを

書き込んだ後、テープにイメージをコピーするためにステージングかストレージライフサイ

クルポリシーを使用できます。この処理はより速くバックアップを生成し、テープドライブの

消耗を防ぐことができます。

データセットをディスクかテープにバックアップする場合、次の要因を考慮します。

■ 保持期間が短いか長いか

ディスクは短い保持期間、テープはより長い保持期間に適します。

■ 中間 (ステージング) か長期ストレージかディスクはステージング、テープは長期ストレージに適します。

■ 増分か完全バックアップか

ディスクは少量の増分バックアップに適します。

■ 合成バックアップ

合成完全バックアップはディスクに増分バックアップが保存されるときの方が速くなり

ます。

69第 4 章メディア設定ガイドラインディスクとテープ: パフォーマンスに関する注意事項

■ データリカバリ時間

通常、ディスクからのリストアはテープからより速くなります。

■ 複数ストリームのリストア

テープから複数ストリームのデータのリストアを実行する必要があるかどうかを確認し

ます。その必要がある場合、テープに書き込む前にディスクに複数ストリームのバック

アップをステージングしないでください。

■ バックアップの速度

クライアントのバックアップが遅すぎてテープが動作しない場合は、ディスクにバック

アップを送信します。後で、ステージングまたはライフサイクルポリシーを使用してテー

プにバックアップイメージを移動できます。

■ バックアップのサイズ

バックアップが小さすぎてテープが動作しない場合は、ディスクにバックアップを送信

します。小さいバックアップには、増分バックアップまたは頻繁に実行される小さいデー

タベースログファイルのバックアップなどがあります。ステージングまたはライフサイク

ルポリシーを使用して、後でテープにバックアップイメージを移動できます。

テープではなくディスクへバックアップするいくつかのメリットは次のとおりです。

■ 多重化にする必要がない

ディスクへのバックアップは多重化にする必要がありません。多重化は、テープを効

率的に動作させる安定したデータの流れ (テープストリーム) を作成するため、テープにとって重要です。ただし、テープへの多重化は以降のリストアを減速させます。

テープストリームについてより多くの情報が利用可能です。


■ データへのインスタントアクセス

ほとんどのテープドライブは 2 分近くの「データの処理時間」があります。テープをスロットから移動し、ドライブにロードし、テープの適切な場所を特定する時間が必要で

す。ディスクでのデータの処理に対する実効時間は 0 秒です。30 個のテープから大容量ファイルシステムをリストアする場合、そのリストアに 2 時間ほど追加される可能性があります。ロードと場所の特定にテープあたり 2 分の遅延、巻き戻しとアンロードにテープあたり 2 分の遅延が見込まれます。

■ より少ない完全バックアップ

テープ型システムでは、「データの処理時間」の問題のために完全バックアップを定

期的に行う必要があります。完全バックアップが定期的に行われなければ、リストアは

増分バックアップから過剰な数のテープを必要とすることがあります。その結果、リスト

ア時間が増加し、それにつれて単一テープでリストアが失敗する可能性も増加しま

す。

70第 4 章メディア設定ガイドラインディスクとテープ: パフォーマンスに関する注意事項

NetBackup の重複排除に関する情報次の TechNote は『NetBackup 重複排除ガイド』を補足するものです。 NetBackup の重複排除に関する追加情報へのリンクを含んでいます。追加情報の一部は『NetBackup重複排除ガイド』のセクションの更新を含むことがあります。

『NetBackup Deduplication: Additional Usage Information』:


71第 4 章メディア設定ガイドラインNetBackup の重複排除に関する情報


推奨する実施例


■ ベストプラクティス: NetBackup SAN クライアント

■ ベストプラクティス: NetBackup AdvancedDisk

■ ベストプラクティス: NetBackup のためにサポートされているテープドライブ技術

■ ベストプラクティス: NetBackup のテープドライブのクリーニング

■ ベストプラクティス: NetBackup のデータリカバリ方法

■ ベストプラクティス: データリカバリ計画に関する提案

■ ベストプラクティス: NetBackup の命名規則

■ ベストプラクティス: NetBackup の複製機能

■ ベストプラクティス: NetBackup Sybase データベース

ベストプラクティス: NetBackup SAN クライアントNetBackup SAN クライアントの機能は次の特性を持つコンピュータ向けに設計されています。

■ バックアップに高帯域幅を必要とする重要なデータを含んでいる

■ メディアサーバーへ変換するための候補ではない

SAN クライアントはファイバーチャネルの SAN 上でメディアサーバーに高速バックアップを実行します。 SAN クライアントのバックアップに対応するメディアサーバーはファイバートランスポートのメディアサーバーと呼ばれます。

5

メモ: FlashBackup オプションは SAN クライアントで使うことは避けてください。FlashBackup バックアップのリストアではメディアサーバーからクライアントに対して SANのパスではなく LAN のパスを使います。 LAN では速度的に FlashBackup のバックアップの最大ボリューム（raw パーティション）のリストアを処理できないことがあります。

シマンテック社の TechNote には SAN クライアントのパフォーマンスパラメータとベストプラクティスに関する情報があります。


TechNote の要点は次のとおりです。SAN クライアントの効果的な使い方は適切なハードウェアが適切に設定してあるかどうかに依存します（詳しくは TechNote を参照してください）。

TechNote の要約は次のとおりです。

■ NetBackup がサポートする HBA のリストサポート対象のハードウェアに関する詳しい情報が入手可能です。

NetBackup 7.x のハードウェア互換性リストを参照してください。http://www.symantec.com/docs/TECH76495

■ SAN クライアントとファイバートランスポートのメディアサーバー間でファイバーチャネルの SAN を配備するためのヒント

■ サポート対象のオペレーティングシステムとファイバートランスポートのメディアサー

バーの HBA のリスト。またメディアサーバーのパフォーマンスに影響するチューニングパラメータのリスト。

■ サポート対象のオペレーティングシステムと SAN クライアントのチューニングパラメータの同様のリスト

■ ベストプラクティスとして推奨された構造の説明。

この文書では次のベストプラクティスについて説明しています。

■ 高速ディスクストレージを有効に利用する、または最大のバックアップ速度で SANクライアントを管理するには、SAN クライアントのバックアップのためにファイバートランスポートのメディアサーバーを専用にします。 LAN ベースのバックアップのためにメディアサーバーは共有しません。

■ メディアサーバーのより費用効率の高い使い方としては、ファイバートランスポー

トのメディアサーバーは SAN クライアントと LAN ベースのバックアップの両方で共有することができます。

■ 複数のデータストリームを使って SAN クライアントからファイバートランスポートのメディアサーバーへより高速のデータ転送を行います。複数のデータストリームはファイバートランスポートのメディアサーバー上の複数の HBA ポートと組み合わせることができます。ファイバートランスポートのメディアサーバーへの同時接続の最大数は 32 です。

73第 5 章推奨する実施例ベストプラクティス: NetBackup SAN クライアント



SAN クライアントに関する詳しい情報が入手可能です。

『NetBackup SAN Client and Fibre Transport Troubleshooting Guide』を参照してください。


ネットワークデータ転送速度の関連情報については次を参照してください。

p.18 の「バックアップに必要なデータ転送速度を計算する方法」を参照してください。

ベストプラクティス: NetBackup AdvancedDiskAdvancedDisk を使用すると、NetBackup はメディアサーバーのホストオペレーティングシステムにネーティブなファイルシステムを完全に使用できます。NetBackup はファイルシステムの完全な所有権を引き継ぎ、ホストオペレーティングシステムのストレージサー

バー機能も使います。

AdvancedDisk は特別なハードウェアを必要としません。AdvancedDisk ディスク形式はNetBackup 内でディスクプールとして管理されます。

次のシマンテック社の TechNote では、AdvancedDisk のパフォーマンスに関する注意事項とベストプラクティスについて説明しています。


ベストプラクティス: NetBackup のためにサポートされているテープドライブ技術

最近のテープドライブではオープンシステム市場向けに以前の世代のテープドライブよ

り極めて大きな容量が提供されています。管理者はこれらの高容量で高性能のテープドライブを利用できます。サポート対象のテープドライブとその他のデバイスに関する最新情報については、次のドキュメントを参照してください。

『Symantec NetBackup Enterprise Server and Server 7.x Hardware CompatibilityList』

ベストプラクティス: NetBackup のテープドライブのクリーニング

NetBackup のインストールでは次のテープドライブのクリーニング方式を使うことができます。

■ 間隔を基準としたクリーニング

■ TapeAlert (オンデマンドクリーニング)

74第 5 章推奨する実施例ベストプラクティス: NetBackup AdvancedDisk





■ ロボットクリーニング

これらの方法の使い方について詳しくは『NetBackup 管理者ガイド Vol.2』を参照してください。次に、各方式の簡潔な概略を示します。

表 5-1 に、3 つのテープドライブのクリーニング方式を示します。

表 5-1 テープドライブのクリーニング方式

説明テープドライブのクリーニング方式

NetBackup はドライブが使用された時間数を追跡して間隔を基準としたクリーニングを実行します。この時間が設定可能パラメータに

達すると、NetBackup はクリーニングテープをマウントし、動作させるジョブを作成します。この方式ではドライブが予防的にクリーニン

グされます。

この方式の利点は通常クリーニング待ちの利用不能なドライブがな

いことです。プラットフォームの形式やロボット形式に関する制限事

項はありません。

不利な点はクリーニングが必要以上に実行されることです。間隔を

基準としたクリーニングによってシステム消耗が増し、ドライブへの

書き込みに時間がかかります。また、この方式は調整が困難です。

新しいテープの場合、ドライブのクリーニングはあまり必要ありませ

んが、テープのインベントリ時間が経過するにつれてクリーニングの

必要性が増加します。これにより必要なチューニング管理の量が増

え、したがって誤差の範囲も増えます。

間隔を基準としたクリーニング

TapeAlert (オンデマンドクリーニング) はほとんどのドライブ形式に対して自動検出型クリーニングを可能にします。TapeAlert により、クリーニングが必要になった場合、テープドライブが EMM に通知できるようになります。EMM はその後クリーニングを実行します。この機能を使うには少なくとも 1 つのライブラリスロットにクリーニングテープを設定する必要があります。TapeAlert は、実装が可能な場合、推奨されるクリーニングソリューションです。

一部のファームウェアレベルのある特定のドライブはこの形式の自

動検出型クリーニングをサポートしません。自動検出型クリーニング

がサポートされなければ、間隔を基準としたクリーニングが代用され

ることがあります。このソリューションはベンダーやプラットフォーム

に依存しません。シマンテック社は個別のファームウェアレベルを

テストしていません。TapeAlert 機能がサポートされるかどうかはベンダーが確認することができます。

p.76 の「NetBackup TapeAlert の動作」を参照してください。

p.77 の「TapeAlert の無効化」を参照してください。

TapeAlert (自動検出型クリーニング、またはオンデマンドク

リーニング)

75第 5 章推奨する実施例ベストプラクティス: NetBackup のテープドライブのクリーニング

説明テープドライブのクリーニング方式

ロボットクリーニングはプロアクティブではなく、その他のドライブク

リーニング方式の制限事項もありません。不要なクリーニングがなく

なり、頻度をチューニングする必要はありません。ドライブは保守操

作よりもデータの移動により多くの時間を使うことができます。

NetBackup ロボットライブラリとオペレーティングシステムのベンダーがさまざまな方法でこの形式のクリーニングを実装しているため、ラ

イブラリに基づくクリーニングはほとんどのロボットに対して EMM でサポートされていません。

ロボットクリーニング

NetBackup TapeAlert の動作ドライブをクリーニングする TapeAlert を理解するには、ドライブに対する TapeAlert のインターフェースを理解することが重要です。テープドライブへの TapeAlert のインターフェースでは SCSI バスを使います。このインターフェースは Log Sense ページに基づいており、64 の警告フラグを含んでいます。フラグの設定や消去の条件はデバイスとデバイスベンダーによって決まります。

Log Sense ページの設定には Mode Select ページを使います。TapeAlert のインターフェースの Mode Sense/Select の設定はディスクドライブの SMART 診断標準と互換性があります。

NetBackup は書き込みまたは読み込みのジョブの始めと終わりに TapeAlert の LogSense ページを読み込みます。TapeAlert の 20 番目から 25 番目までのフラグはクリーニング管理のために使われていますが、ドライブベンダーの実装によっては異なってい

ることもあります。NetBackup は TapeAlert の 20 番目のフラグ (Clean Now) と 21 番目のフラグ (Clean Periodic) を使っていつドライブをクリーニングするか判断しています。

NetBackup がバックアップ用のドライブを選択するとき、bptm は状態について Log Senseページを見直します。いずれかのクリーニングフラグが設定されている場合、ジョブの開

始前にドライブがクリーニングされます。バックアップが進行中にクリーニングフラグが設

定された場合、フラグはテープがドライブからマウント解除されるまで読み込まれません。

ジョブがメディアにわたり、最初のテープの使用中にいずれかのクリーニングフラグが設

定された場合、クリーニングライトが点灯し、2 つ目のメディアがマウントされる前にドライブがクリーニングされます。

現在のジョブが、TapeAlert の［Clean Now］や［Clean Periodic］のメッセージにかかわらず、進行中の書き込みを完了することになります。つまり、テープに書き込まれたデー

タが TapeAlert によって損失することがありません。これは残りのメディアに書き込みをする NetBackup のジョブの数に関係なく適用されます。

多数のメディアが TapeAlert を実装したことで凍結するようになった場合は、他のメディアかテープドライブの問題がある可能性があります。

76第 5 章推奨する実施例ベストプラクティス: NetBackup のテープドライブのクリーニング

TapeAlert の無効化次の手順を実行します。

NetBackup で TapeAlert を無効にする方法

◆ NO_TAPEALERT という touch ファイルを次のように作成します。

UNIX の場合:

/usr/openv/volmgr/database/NO_TAPEALERT

Windows の場合:

install_path¥volmgr¥database¥NO_TAPEALERT

ベストプラクティス: NetBackup のデータリカバリ方法データ損失からのリカバリにはリカバリ目標と時間枠をサポートする計画と技術の両方が

関係します。採用する方式や手順は文書化し、定期的にテストしてインストールが災害からリカバリできることを確認します。

表 5-2 は各種のエラーからリカバリするためにどのように NetBackup と他のツールを使うことができるかを説明します。

表 5-2 データリカバリの方式と手順

リカバリの方式と手順リカバリ可能か

業務運営リスク

なしいいえバックアップ前に削除されたファイ

ル

NetBackup の標準的なリストア手順はいバックアップ後に削除されたファイ

ル

NetBackup を使ったデータリカバリはいバックアップクライアントエラー

バックアップイメージの複製: 複数のバックアップのコピーを作成します

はいメディアエラー

ストレージユニットグループ（バックアップ用）

と

FAILOVER_RESTORE_MEDIA_SERVER（テープからのリストア用）を事前設定するこ

とにより、通常、リカバリは自動的に実行され

ます

はいメディアサーバーエラー

77第 5 章推奨する実施例ベストプラクティス: NetBackup のデータリカバリ方法

リカバリの方式と手順リカバリ可能か

業務運営リスク

自動フェールオーバーのためにマスターサー

バーをクラスタに配備します

はいマスターサーバーエラー

NetBackup のデータベースリカバリはいバックアップデータベースの損失

NetBackup がないメディアのリカバリは、多重化されていない場合、GNU tar を使います

はいNetBackup のソフトウェアなし

ボルト処理とオフサイトのメディアストレージはい全面的なサイト災害

追加資料として次の書籍があります。

「The Resilient Enterprise, Recovering Information Services from Disasters」、シマンテック社および産業界著、 Symantec Software Corporation 発行

「Blueprints for High Availability, Designing Resilient Distributed Systems」、EvanMarcus、Hal Stern 共著、 John Wiley and Sons 発行

「Implementing Backup and Recovery: The Readiness Guide for the Enterprise」、David B. Little、David A. Chapa 共著、 Wiley Technology Publishing 発行

ベストプラクティス: データリカバリ計画に関する提案論理エラー、オペレータエラー、またはサイト災害からリカバリするには、よく文書化され、

テストされた計画を持っている必要があります。

ディザスタリカバリについて詳しくは、次のドキュメントを参照してください。

サイトのディザスタリカバリオプションのガイド


『NetBackup トラブルシューティングガイド』

NetBackup 管理者ガイド（Vol. 1 と Vol. 2）

NetBackup 高可用性の環境管理者ガイド

『NetBackup マスターサーバーのクラスタ化管理者ガイド』

『NetBackup クラウド管理者ガイド』

リカバリ計画には、次の準備手段を使います。

■ いつも定時カタログバックアップを使う

『NetBackup トラブルシューティングガイド』の「オンラインバックアップからのカタログリカバリ」を参照してください。

78第 5 章推奨する実施例ベストプラクティス: データリカバリ計画に関する提案


■ ディザスタリカバリ計画を頻繁に見直す

サイト固有のリカバリ手順を見直し、正確かつ最新であることを確認します。また、最新のソフトウェアでコンピュータを再構築するための手順が、NetBackup のマスターサーバーやメディアサーバーなど、複雑なシステムに用意されていることを確認しま

す。

■ テストリカバリを定期的に実行する

代替の場所に各種のシステムのリストアを実行する計画を実行します。この計画にはランダムな本番環境のバックアップを選択することとデータを非本番環境のシステム

にリストアすることを含めます。そしてチェックサムは 1 つまたは多数のリストアされたファイルで行い、実際の本番環境のデータと比較します。このテストの一部として必ずオフサイトストレージを含めてください。エンドユーザーやアプリケーション管理者も、リストアされたデータの整合性を判断するのを支援することができます。

■ NetBackup カタログを使って保護する

次の手順を実行します。

■ NetBackup カタログを 2 個のテープにバックアップします。カタログには NetBackup のリカバリに重要な情報が含まれています。消失すると、リカバリに手動処理で数時間から数日かかる可能性があります。テープ 1 個のコストは緊急時の迅速なリカバリのための追加の保険と考えれば安いものです。

■ 各バックアップの後でカタログをバックアップします。

カタログバックアップの場合、各バックアップセッションの後で増分カタログバック

アップを実行できます。また、ビジーな状態のバックアップ環境ではバックアップセッションが終了することがあまりないため、定時カタログバックアップも使う必要

があります。

突発的なエラーでは、一部のイメージが利用できない場合、イメージのリカバリが

遅れます。バックアップファイルを含むマスターサーバーやドライブがクラッシュする直前に手動でバックアップしてある場合、手動バックアップをインポートして最

新のバージョンのファイルをリカバリする必要があります。

■ カタログバックアップテープの ID を記録します。緊急の場合に迅速に識別できるようにサイト運営ブックまたは別の周知の場所に

カタログテープを記録します。カタログテープが識別されなければ、それらを見つけるためにライブラリのすべてのテープをスキャンすることで時間を浪費する可能

性があります。

vmphyinv ユーティリティを使って、ロボットライブラリのすべてのテープをマウントし、カタログテープを識別することができます。

■ カタログバックアップのラベルの接頭辞を指定します。

緊急時に簡単に NetBackup のカタログデータを識別できます。テープのバーコードに「DB」のような一意の接頭辞でカタログテープをラベル付けするとオペレータはカタログテープをすばやく見つけることができます。

■ 特定のロボットスロットに NetBackup のカタログを保存します。

79第 5 章推奨する実施例ベストプラクティス: データリカバリ計画に関する提案

ロボットの最初または最後のスロットにカタログバックアップテープを保存すると緊

急時にそのテープを識別できます。これにより、手動によるテープ処理が必要な場合、テープの移動も簡単になります。

■ NetBackup のカタログをバックアップ対象のデータと異なるオンラインストレージに配置します。

カタログは本番環境のデータと同じディスクに存在するべきではありません。ディスクドライブが本番環境のデータを失えば、それに存在するカタログデータも失う

場合があり、停止時間が増加します。

■ 定期的に NetBackup のカタログの整合性を確認します。四半期ごとまたは大きな業務や担当者の交代の後などに定期的にテープからカ

タログをリカバリする処理を実地検証します。この NetBackup の不可欠な管理は大災害時に時間を節約します。

ベストプラクティス: NetBackup の命名規則すべての NetBackup マスターサーバーに一貫性をもつ命名規則を使います。名前にはすべて小文字を使います。大文字と小文字に関連する問題は、インストールが UNIXと Windows のマスターサーバーとメディアサーバーで構成されている場合に発生することがあります。

表 5-3

命名のガイドライン名前を付けるオブジェクト

ポリシーに適した命名規則は platform_datatype_server(s) です。

例 1: w2008_filesystems_trundle

このポリシー名ではファイルシステムのバックアップをする単一の Windows2008 サーバーのポリシーが指定されています。

例 2: w2008_sql_servers

このポリシー名では複数の Windows 2008 の SQL Server をバックアップするポリシーが指定されています。このポリシーによって複数のサーバーがバックアップされることがあります。単一のポリシーに含まれる候補となるサーバーは同じオペレーティングシステムを実行し、同じバックアッ

プ必要条件を持っています。単一のポリシー内のサーバーをグループ化するとポリシーの数が減り、NetBackup の管理が簡単になります。

ポリシー

スケジュール名のために一般的なスキームを作成します。一組の推奨スケジュール名は日次、週次、月次です。別の推奨名は増分、累積、完全です。この規則は NetBackup の管理を最小限に保ちます。また、サイトで Vault を使う場合、Vault の実装にあたって役に立ちます。

スケジュール

80第 5 章推奨する実施例ベストプラクティス: NetBackup の命名規則

命名のガイドライン名前を付けるオブジェクト

ストレージユニットに適した命名規則はメディアサーバーとバックアップ対

象のデータの種類に関連させてストレージユニットに名前を付けることで

す。

2 つの例: mercury_filesystems と mercury_databases

「mercury」がメディアサーバーの名前で、「filesystems」と「databases」はバックアップ対象のデータの種類を示しています。

ストレージユニットとス

トレージグループ

ベストプラクティス: NetBackup の複製機能次は NetBackup イメージの複製についての注意事項です。

■ イメージを複製する場合、元のイメージのボリュームプールとは異なるボリュームプー

ルを指定します。（NetBackup 管理コンソールの［複製変数の設定（SetupDuplication Variables）］ダイアログボックスを使います。）

■ 複数の複製ジョブが同時にアクティブである場合（Vault の複製ジョブなど）、各ジョブに異なるストレージユニットかボリュームプールを指定します。異なるインストール先を使うことで複製ジョブ間でのメディア交換を防げることがあります。

■ NetBackup は、複製ジョブを実行してスクリプトを作成するための bpduplicate コマンドを提供します。ただし、バックアップ戦略の一部として複製を実装する場合は、ストレージライフサイクルポリシーまたは Vault オプションを使うことをお勧めします。詳しくは、次の文書を参照してください。

『NetBackup 7.5 Best Practice - Using Storage Lifecycle Policies』

ベストプラクティス: NetBackup Sybase データベース■ データベースのメモリ割り当て

NetBackup は初期に基になるデータベースに 1 GB の RAM を割り当てます。この割り当てでは不十分な場合があり、server.conf の -ch の値を増やすことによって利用可能なシステムメモリの 30% にまで調整することができます。 server.confの場所とその値の意味については、次の記事を参照してください。

「NetBackup server.conf ファイルについて（UNIX/Linux）」

■ Sybase のスレッドSybase に現在割り当てられているスレッドを少しチューニングしても、システムが大きく改善される場合があります。これらの問題を診断して調整するには、次の記事を参照してください。

「NetBackup 7.5/7.6 additional tuning for Sybase to allow thread optimization」

81第 5 章推奨する実施例ベストプラクティス: NetBackup の複製機能

http://www.symantec.com/docs/HOWTO73205

http://www.symantec.com/docs/HOWTO67149


パフォーマンスチューニング

■ 第6章パフォーマンス測定

■ 第7章 NetBackup のデータ転送パスのチューニング

■ 第8章他の NetBackup コンポーネントのチューニング

■ 第9章ディスク I/O パフォーマンスのチューニング

■ 第10章 UNIX と Linux の OS 関連のチューニング要件

■ 第11章 Windows の OS 関連のチューニング要件

■ 付録 A. 追加のリソース

2

パフォーマンス測定


■ NetBackup のパフォーマンス測定: 概要

■ 一貫性があるテスト条件のためにシステムの可変要素を制御する方法

■ 他のジョブからの影響を受けないパフォーマンステストの実行

■ NetBackup パフォーマンスの評価について

■ アクティビティモニターによる NetBackup のパフォーマンスの評価

■ ［すべてのログエントリ (All Log Entries)］レポートを使った NetBackup パフォーマンスの評価

■ NetBackup の［すべてのログエントリ (All Log Entries)］レポートの表

■ システムコンポーネントの評価

■ ディスクパフォーマンスの向上

NetBackup のパフォーマンス測定: 概要NetBackup パフォーマンスは最終的に次の時間で測定します。

■ バックアップ操作を完了するのに必要な時間（通常はバックアップ処理時間帯といい

ます）

■ 重要なリストア操作を完了するために必要な時間

ただし、パフォーマンスを測定し、改善するには実経過時間よりも信頼性が高く、再生可

能なパフォーマンス計測指標が必要です。この章ではこれらの計測指標についてより詳しく説明します。

ここに記述されているように正確な計測指標を確立した後、基準パフォーマンスのベンチ

マークを集計するために NetBackup とシステムコンポーネントの現在のパフォーマンス

6

を測定できます。基準値を使うと、制御された方法で変更を加えることができます。変更ごとにパフォーマンスを測定することによって、NetBackup のパフォーマンスについて各変更の効果を正確に測定できます。

一貫性があるテスト条件のためにシステムの可変要素を制御する方法

信頼性が高いパフォーマンス評価のために、可能なかぎり多くの予測不能な要素を除去

して一貫性のあるバックアップ環境を作成します。一貫性のある環境においてのみ信頼性が高く再生可能なパフォーマンス測定ができます。このトピックでは、NetBackup サーバー、ネットワーク、NetBackup クライアント、またはデータ自体に関連した考慮すべき可変要素について説明します。

表 6-1 テストのために制御するシステムの可変要素

制御のための注意事項可変要素

特定の NetBackup 操作のパフォーマンスを測定するときには、環境から他のすべての NetBackup アクティビティを除去してください。考慮すべきことの 1 つは NetBackup スケジューラによるバックアップジョブの自動スケジュールです。

ポリシーが作成されると、通常は NetBackup スケジューラがバックアップを開始できるように設定されます。NetBackup スケジューラは NetBackup の従来の間隔を基準としたスケジュールに従って、または特定の曜日、日付、その他の時間間隔に従ってバックアップを開始します。この処理はカレンダーを基準としたスケジュールです。バックアップポリシーに設定されている［開始時間帯（Start Window）］は NetBackup スケジューラが間隔またはカレンダーを基準にしたスケジュールを使ってバックアップを開始する時間を指定しま

す。パフォーマンスをテストするためにバックアップを実行するとき、このスケジュールが影響することがあります。特に測定する操作が長時間にわたって実行される場合に、NetBackup スケジューラはバックアップを突然開始することがあります。

p.86 の「他のジョブからの影響を受けないパフォーマンステストの実行」を参照してください。

サーバーの可

変要素

ネットワークパフォーマンスは NetBackup の最適パフォーマンスにとって重要です。無関係なネットワークアクティビティによって結果がゆがめられないように、テストには個別のネットワークを使うことが理想です。

多くの場合、個別のネットワークは利用できません。その場合は、テストの間、NetBackup 以外のアクティビティが最低限におさえられていることを確認してください。もし可能なら、バックアップがアクティブでないときにテストをスケジュールします。ネットワークアクティビティが一時的に集中しただけで、テスト結果がゆがめられることがあります。他のシステムで発生している本番環境のバックアップとネットワークを共有する場合、テスト中にこのアクティビティを考慮する必要があります。

もう 1 つのネットワークの可変要素はホスト名解決です。 NetBackup が正しく稼動するかどうかはホスト名の適時の解決に大きく依存しています。ホスト名解決で遅延が発生する場合は、その遅延を除去してください。そのような遅延の例に、IP アドレスからの着信接続のサーバー名を識別する名前の逆引き参照があります。テスト環境のシステムでのホスト名解決には HOSTS（Windows）または /etc/hosts（UNIX）ファイルを使うことができます。

ネットワークの可

変要素

84第 6 章パフォーマンス測定一貫性があるテスト条件のためにシステムの可変要素を制御する方法


パフォーマンステスト中はクライアントシステムを比較的静止した状態にします。多くのアクティビティ、特にWindows のウイルススキャンなどのディスクに集中するアクティビティは、データ転送率を制限し、テストの結果をゆがめる可能性があります。

テストの間に別の NetBackup サーバー（本番環境のサーバーなど）がクライアントにアクセスできないようにしてください。 NetBackup は 2 つの異なるサーバーに同じクライアントを同時にバックアップすることがあります。進行中のパフォーマンステストの結果に重大な影響を与える場合があります。

異なるファイルシステムは異なるパフォーマンス特性があります。 UNIX NFS または Windows NTFS システムと UNIX VxFS または Windows FAT ファイルシステムのデータスループットを比較することは有効でない場合があります。そのような比較では、ファイルシステム間の相違をパフォーマンステストとその結論で考慮します。

クライアントの可

変要素

85第 6 章パフォーマンス測定一貫性があるテスト条件のためにシステムの可変要素を制御する方法


バックアップしているデータを監視するとパフォーマンステストの再現性が向上します。もし可能なら、同じドライブか論理パーティション（ミラー化されたドライブ以外）にテストに使うデータを移動します。パフォーマンステストを始める前にドライブをデフラグします。リストアのテストでは、十分な空きスペースがある最近デフラグされたディスクドライブまたは空のディスクドライブで開始します。

テープへのバックアップのテストでは、次のように常に空のメディアで各テストを開始します。

■ NetBackup 管理コンソールのカタログノードでメディアの既存のイメージを期限切れにするか、またはbpexpdate コマンドを実行します。

■ もう 1 つのアプローチは NetBackup がバックアップ操作に新しいメディアを選択するように既存のバックアップイメージを含んでいるメディアを凍結する bpmedia コマンドを使うことです。この手順によりパフォーマンステストでのテープの位置設定による影響が減り、テスト間でより一貫性のある結果が得られ

ます。また NetBackup のカタログイメージを含んでいて通常のバックアップでは使われないメディアのマウントとマウント解除の影響も減ります。

テープからのリストアをテストする場合、常にテープの同じバックアップイメージからリストアしてテスト間で一

貫性のある結果を得るようにします。

大きいデータセットは、小さいデータセットよりも信頼性が高く、再生可能なテストが実行されます。小さいデータセットによるパフォーマンステストは NetBackup 操作での起動とシャットダウンのオーバーヘッドによってゆがめられることがあります。これらの可変要素はテスト実行間で一貫性を保ちにくく、したがって一貫性のないテスト結果が生成されることがあります。大きいデータセットは起動とシャットダウンの回数の影響を最小化します。

目的の本番環境のデータ構成に相当するデータセットを設計します。本番環境のデータセットがファイルサーバー上で多くの小さいファイルを含んでいる場合、テスト用のデータセットも多くの小さいファイルを含む

ようにします。代表的なデータセットは本番環境で想定できる NetBackup のパフォーマンスをより正確に予測できます。

データの種類はシステムのボトルネックを明らかにするうえで役に立ちます。圧縮不可能な（ランダム）データで構成されるファイルはより遅い速度でテープドライブを実行させます。データ転送パスの他のコンポーネントが同じ速度を保っている限り、ボトルネックとしてテープドライブを特定できます。一方、ハードウェア圧縮が有効な場合、圧縮性の高いデータで構成されるファイルはテープドライブで高速で処理されます。これにより全体的なスループットがより高くなり、ネットワークがボトルネックであることが明らかになることがありま

す。

NetBackup の多くの値はデータ量を KB と KB/秒で提供します。より正確な結果を得るために、KB を MBに変換する場合や KB/秒を MB/秒に変換する場合は、端数処理した 1000 ではなく 1024 で割ってください。

データの可変要

素

他のジョブからの影響を受けないパフォーマンステストの実行

テストを実行するために次の手順を使います。この手順では NetBackup スケジューラがテストの間に他のバックアップを実行することを回避できます。

86第 6 章パフォーマンス測定他のジョブからの影響を受けないパフォーマンステストの実行

テストを実行する方法

1 パフォーマンステスト専用のポリシーを作成します。

2 スケジュールの［開始時間帯（Start Window）］フィールドを空白のままにします。

このポリシーにより NetBackup スケジューラがそのポリシー用に自動的にバックアップを開始することがなくなります。

3 NetBackup スケジューラがパフォーマンステストに無関係なバックアップジョブを実行しないように、他のバックアップポリシーをすべて非アクティブに設定することを考

慮します。

NetBackup 管理コンソールの［無効化（Deactivate）］コマンドを使えます。バックアップの実行を再度開始する場合は、テストの後でポリシーを再アクティブ化する必

要があります。

4 パフォーマンステストを開始する前に、進行中の NetBackup ジョブがないことをアクティビティモニターで調べます。

5 より多くのログ記録の情報を集めるには、レガシーと統合ログのレベルを高く設定し、

適切なレガシーログのディレクトリを作成します。

デフォルトでは、NetBackup のログ記録は最小のレベルに設定されています。テストとログレベルによっては、より高いログレベルでパフォーマンスが低下することがあ

ることに注意してください。

NetBackup のログ記録の使い方について詳しくは『NetBackup トラブルシューティングガイド』のログに関する章を参照してください。ログ記録のレベルを高く設定するとより多くのディスク容量が消費されることに留意してください。

6 テスト用に作成したポリシーを使って、オンデマンドのバックアップを実行します。

NetBackup 管理コンソールで［処理（Actions）］ > ［手動バックアップ（ManualBackup）］をクリックします。

または、パフォーマンステストを実行するためにユーザー主導バックアップを使うこと

ができます。ただし、［手動バックアップ（Manual Backup）］オプションを推奨します。手動バックアップでは、ポリシーはバックアップジョブのすべての定義を含んでいます。ポリシーはパフォーマンステストで使われるファイルとクライアントを含んでいます。ポリシーからバックアップを手動で実行すれば、バックアップに使われているポリシーを特定できます。このアプローチによって、ポリシーダイアログボックスからの個々のバックアップ設定の変更とテストがより簡単になります。

7 パフォーマンステスト中は、サーバー上に NetBackup 以外のアクティビティがあるかどうかを調べ、減らすか除去します。

8 パフォーマンステスト後、テストで発生した可能性があるリストアジョブのような予想外

のアクティビティについて、NetBackup アクティビティモニターで確認します。

87第 6 章パフォーマンス測定他のジョブからの影響を受けないパフォーマンステストの実行

NetBackup パフォーマンスの評価について次のツールから NetBackup のデータスループットに関する統計を取得できます。

■ NetBackup アクティビティモニター

■ NetBackup の［すべてのログエントリ (All Log Entries)］レポート

測定する NetBackup の操作の種類に応じて場所を選択します。

■ 多重化されていないバックアップ

■ 多重化されたバックアップ

■ リストア

表 6-2 NetBackup のパフォーマンス統計を取得する場所

［すべてのログエントリ (All Log Entries)］レポートアクティビティモニターレポート対象の操作

可可多重化されていない

バックアップ

可

［すべてのログエントリ (All Log Entries)］レポートから全体的な統計を入手します。多重化されたバックアップの個々のバックアップ操作がすべて

完了するまで待ちます。この場合、アクティビティモニターで個々のバッ

クアップ操作に対して表示される統計はその操作にのみ関連します。統

計には、テープドライブに対するデータスループットの合計は反映されま

せん。

不可 (次の欄を参照)多重化されたバック

アップ

可可リストア

これら 2 つのツールの統計は異なる可能性がありますが、これはアクティビティモニターと［すべてのログエントリ (All Log Entries)］レポートの端数の処理方法が異なるためです。指定した種類の操作に対してどちらかのツールを選択し、常にそのツールからのみ

統計を記録するようにします。アクティビティモニターと［すべてのログエントリ (All LogEntries)］レポートの両方ともデータストリームの速度は KB/秒で報告されます。バックアップまたはリストアが繰り返されると、さまざまな要因によって、報告される速度は繰り返され

るたびに異なる可能性があります。要因には、システムリソースの可用性とシステム利用

率が含まれます。報告された速度はデータストリーム処理のパフォーマンスを評価するた

めに使うことができます。

NetBackup のエラーログの統計は実際にテープとのデータの読み書きに使われた時間を示します。統計には、テープのマウントと位置設定の時間は含まれません。NetBackupクライアントの bpbkar ログのデータとエラーログの情報を相互参照してください。(bpbkarログはプロセス全体を通した経過時間を示します。)相互参照すると、どの位の時間がテープの読み書きと無関係な操作に使われたかを確認できます。

88第 6 章パフォーマンス測定NetBackup パフォーマンスの評価について

アクティビティモニターによる NetBackup のパフォーマンスの評価

NetBackup アクティビティモニターでパフォーマンスを評価する方法

1 バックアップまたはリストアジョブを実行します。

2 NetBackup アクティビティモニターを開きます。

3 バックアップまたはリストアが正常に完了したことを確認します。

［状態（Status）］列は 0（ゼロ）になります。

4 ［処理（Actions）］、［詳細（Details）］メニューオプションの順に選択するか、ジョブのエントリをダブルクリックしてジョブのログの詳細を表示します。

5 ［状態の詳細（Detailed Status）］タブを選択します。

6 アクティビティモニターの次のフィールドから NetBackup のパフォーマンス統計を入手します。

これらのフィールドはバックアップまたはリストアジョブが発生した時

間帯を示します。

開始日時（StartTime）/終了日時（EndTime）

このフィールドはジョブが開始してから完了するまでの経過時間の

合計を示します。それは操作の実経過時間の合計の目安として使うことができます。

経過時間 (ElapsedTime)

データスループット率。KB/秒（KB perSecond）

データの量とこの値を比較します。同じような値になるはずですが、バックアップされたデータのために保存された管理情報（メタデータ）

があるため、NetBackup のデータ量が少し大きくなります。

KB (Kilobytes)

たとえば、サイズが 1 MB のファイルを 500 含んでいるディレクトリのプロパティを表示した場合、そのディレクトリのサイズとして 500 MB が表示されます（500 MB は524,288,000 バイト、つまり 512,000 KB です）。 NetBackup のレポートはディレクトリのファイルサイズより 1,255 KB 大きく報告して 513,255 KB を示すことがあります。このレポートは、単層ディレクトリの場合に当てはまります。使われているオペレーティングシステムトラックとディスクの利用可能容量によりサブディレクトリの構造

が分化することがあります。

オペレーティングシステムは、存在するデータの量だけでなく、該当ファイルに割り

当てられている容量を報告している可能性があります。割り当てブロックサイズが 1KB の場合、1 バイトのファイルが 1000 個あると、存在するデータが 1 KB であるにも関わらず、1 MB の合計サイズが報告されます。ファイル数が多くなると、この不一致はより大きくなることがあります。

89第 6 章パフォーマンス測定アクティビティモニターによる NetBackup のパフォーマンスの評価

［すべてのログエントリ (All Log Entries)］レポートを使った NetBackup パフォーマンスの評価

［すべてのログエントリ (All Log Entries)］レポートを使ってパフォーマンスを評価する方法

1 バックアップまたはリストアジョブを実行します。

2 NetBackup 管理コンソールの NetBackup のレポートノードから［すべてのログエントリ (All Log Entries)］レポートを実行します。選択した［日付/時刻範囲 (Date/TimeRange)］がジョブが実行された期間を含んでいることを確かめます。

3 次のようなエントリを検索することによってジョブが正常に完了したことを確認します。

バックアップの場合: 「要求された操作は正常に完了しました (the requestedoperation was successfully completed)」

リストアの場合: 「正常に読み込み (リストア) バックアップ ID (successfully read(restore) backup id)」

4 レポートのメッセージから NetBackup のパフォーマンス統計を入手します。

NetBackup の［すべてのログエントリ (All Log Entries)］レポートの表

表 6-3 に、［すべてのログエントリ (All Log Entries)］レポートのメッセージを示します。

メッセージはマスターサーバーのロケールの設定に従って変わります。

表 6-3 ［すべてのログエントリ (All Log Entries)］レポートのメッセージ

統計エントリ

このエントリの［日付 (Date)］と［時間 (Time)］フィールドはバックアップジョブが開始された時間を表します。

クライアント <name>、ポリシー <name>、スケジュール <name> ストレージユニット<name> のバックアップジョブが開始されました (started backup job forclient <name>, policy <name>,schedule <name> on storageunit <name>)

多重化されたバックアップの場合、このエントリは個々のバックアップジョブのサイ

ズを示します。［日付 (Date)］と［時間 (Time)］フィールドはジョブがストレージデバイスへの書き込みを終了した日時を示します。ストレージデバイスへのデータス

ループット率を含む多重化されたバックアップグループの全体的な統計は後続の

エントリにあります。

バックアップ ID <name>、コピー<number>、<number> KB を正常に書き込みました (successfully wrotebackup id <name>, copy<number>, <number> Kbytes)

90第 6 章パフォーマンス測定［すべてのログエントリ (All Log Entries)］レポートを使った NetBackup パフォーマンスの評価

統計エントリ

多重化されたバックアップでは、このエントリはデータスループット率を含む多重

化されたバックアップグループの全体的な統計を表します。

<number> 個 (<number> 個中) の多重化されたバックアップを正常に書き込みま

した。合計 KB <number> ( KB/秒)(successfully wrote <number>of <number> multiplexedbackups, total Kbytes <number>at Kbytes/sec)

多重化されていないバックアップの場合、このエントリでは多重化されたバックアッ

プの以前の 2 つのエントリの情報が組み合わせられます。単一のエントリでは次の情報が示されます。

■ バックアップジョブのサイズ

■ データスループット率

■ ジョブがストレージデバイスへの書き込みを終了した日時 (［日付 (Date)］と［時間 (Time)］フィールド)。

バックアップ ID <name>、(コピー<number>、フラグメント <number>、<number> KB) を <number> KB/秒で正常に書き込みました (successfullywrote backup id <name>, copy<number>, fragment <number>,<number> Kbytes at <number>Kbytes/sec)

このエントリの［日付 (Date)］と［時間 (Time)］フィールドはバックアップジョブが完了した時間を表します。この値は、前のメッセージの［正常に書き込みました

(successfully wrote)］よりも後に表示されます。NetBackup のイメージ検証などのタスクのジョブ終了時における追加処理の時間が含まれます。

要求された操作は正常に完了しました

(the requested operation wassuccessfully completed)

このエントリの［日付 (Date)］と［時間 (Time)］フィールドはストレージデバイスから読み込むリストアジョブが開始された時間を表します。(エントリの後の部分はディスクからのリストアでは適用されないため表示されないことにご留意ください。)

バックアップ ID <name>、(リストア)、コピー<number>、フラグメント <number> の読み込みを、メディア ID <name> (ドライブインデックス <number> 上) から開始します(begin reading backup id<name>, (restore), copy<number>, fragment <number>from media id <name> on driveindex <number>)

多重化されたリストアの場合、このエントリは個々のリストアジョブのサイズを示しま

す。(一般に、テープからのすべてのリストアは多重化されたリストアです。多重化されていないリストアではユーザーからの追加処理が必要となるためです。)

［日付 (Date)］と［時間 (Time)］フィールドはジョブがストレージデバイスからの読み込みを終了した日時を示します。データスループット率を含む多重化されたリ

ストアグループの全体的な統計は以下の後続のエントリにあります。

バックアップ ID <name>、(コピー<number>、<number> KB) から正常にリストアしました (successfullyrestored from backup id<name>, copy <number>,<number> Kbytes)

91第 6 章パフォーマンス測定NetBackup の［すべてのログエントリ (All Log Entries)］レポートの表

統計エントリ

多重化されたリストアでは、このエントリはデータスループット率を含む多重化され

たリストアグループの全体的な統計を表します。

<number> 要求 (<number> 要求中<name>) を正常にリストアしました。読み込み合計 <number>KB ( <number> KB/秒) (successfully restored<number> of <number> requests<name>, read total of <number>Kbytes at <number> Kbytes/sec)

多重化されていないリストアの場合、このエントリでは多重化されたリストアの以前

の 2 つのエントリの情報が組み合わせられます。単一のエントリでは次の情報が示されます。

■ リストアジョブのサイズ

■ データスループット率

■ ジョブがストレージデバイスからの読み込みを終了した日時 (［日付 (Date)］と［時間 (Time)］フィールド)

一般に、ディスクからのリストアのみが多重化されていないリストアとして処理され

ます。

バックアップ ID メディア <number>、コピー<number>、フラグメント <number> を正常に読み込みました (リストア)。<number>KB (<number> KB/秒)(successfully read (restore)backup id media <number>, copy<number>, fragment <number>,<number> Kbytes at <number>Kbytes/sec)

NetBackup の［すべてのログエントリ（All Log Entries）］レポートに関する追加情報

NetBackup の［すべてのログエントリ（All Log Entries）］レポートには、他の NetBackup操作に対して次の表に示すエントリに類似しているエントリがあります。

p.90 の表 6-3 を参照してください。

たとえば、バックアップイメージの追加コピーを作成するイメージの複製操作のエントリが

あります。これらのエントリは NetBackup のパフォーマンスの分析に役立つことがあります。

テープバックアップの bptm デバッグログファイル（またはディスクバックアップの bpdm ログファイル）には、［すべてのログエントリ（All Log Entries）］レポートにあるエントリが含まれます。このログには、操作についての有用な追加詳細が示されることもあります。 1 つの例として、多重化されたバックアップの中間データスループット率に関するメッセージが

あります。

... intermediate after number successful, number Kbytes at

number Kbytes/sec

このメッセージは多重化されたバックアップグループの一部である個別のバックアップジョ

ブが完了するといつも生成されます。たとえば、3 つの個別のバックアップジョブで構成される多重化されたバックアップグループのデバッグログファイルには 2 行の中間状態のスループット率と最終（全体）スループット率が示されます。

92第 6 章パフォーマンス測定NetBackup の［すべてのログエントリ (All Log Entries)］レポートの表

バックアップ操作の場合、bpbkar デバッグログファイルは操作に関する有用な追加詳細も含んでいます。

NetBackup 操作の間にデバッグログファイルに書き込むと、本番環境では発生しない可能性があるオーバーヘッドが発生することに注意してください。その追加のオーバーヘッドを考慮に入れてください。

すべてのログレポートの情報は次の場所にもあります。

UNIX の場合

/usr/openv/netbackup/db/error

Windows の場合

install_path¥NetBackup¥db¥error

これらのデバッグログファイルを書き込むための NetBackup の設定方法は『NetBackupトラブルシューティングガイド』を参照してください。

システムコンポーネントの評価NetBackup のパフォーマンスの評価に加えて、共通のシステムリソースが十分に供給されていることも確認します。

Windows の場合: NetBackup のパフォーマンスの評価に加えて、共通のシステムリソースが十分に供給されていることも確認します。高水準の情報の場合は、Windows のタスクマネージャーを使うことができます。詳しい情報を表示するには、Windows のパフォーマンスモニターユーティリティを使うことができます。

パフォーマンスモニターについて詳しくは、Microsoft 製品のマニュアルを参照してください。

テープやディスク出力に左右されないパフォーマンス測定についてネットワークコンポーネントとテープコンポーネントに左右されることなく NetBackup の速度についてディスク (読み込み) コンポーネントを測定できます。

利用可能な技術は次のとおりです。

■ bpbkarこの技術の方が簡単です。

■ SKIP_DISK_WRITES touch ファイルこの技術はより限られた状況で役に立つことがあります。

メモ: これらの手順では、マスターサーバーはクライアントです。

93第 6 章パフォーマンス測定システムコンポーネントの評価

bpbkar を使ったディスクパフォーマンス測定bpbkar でディスクパフォーマンスを測定するにはこの手順を使ってください。

bpbkar コマンドを使ってディスク I/O を測定する方法

1 bpbkar ディレクトリがあることを確認してレガシーの bpbkar ログをオンにします。

UNIX の場合

/usr/openv/netbackup/logs/bpbkar

Windows の場合

install_path¥NetBackup¥logs¥bpbkar

2 ログ記録レベルに 1 を設定します。

3 次のように入力します。

UNIX の場合

/usr/openv/netbackup/bin/bpbkar -nocont -dt 0 -nofileinfo

-nokeepalives file system > /dev/null

file system はバックアップされているパスのことです。

Windows の場合

install_path¥NetBackup¥bin¥bpbkar32 -nocont X:¥ > NUL

X:¥ はバックアップされているパスのことです。

4 NetBackup がクライアントディスクからデータを移動するためにかかった時間を調べます。

UNIX の場合: 開始時間は bpbkar ログの最初の PrintFile エントリです。終了時間は［クライアントがバックアップ処理用のデータの送信を完了しました（Clientcompleted sending data for backup）］エントリです。データの量は［合計サイズ（Total Size）］エントリに示されます。

Windows の場合: ［経過時間（Elapsed time）］エントリで bpbkar ログを調べます。

SKIP_DISK_WRITES touch ファイルを使ったディスクパフォーマンスの測定

UNIX または Windows で SKIP_DISK_WRITES の手順が使えます。

SKIP_DISK_WRITES の手順は bpbkar の追加手順として有用です。 bpbkar の手順は、ディスクの読み込みパフォーマンスがボトルネックではないことを示すことがあります。ディスクの読み込みパフォーマンスがボトルネックではない場合、ボトルネックはクライアントの


bpbkar 処理とサーバーの bpdm 処理の間のデータ転送にあります。次のSKIP_DISK_WRITES の手順が役に立つ場合があります。

SKIP_DISK_WRITES の手順が低いパフォーマンスを示した場合、問題がネットワークまたは共有メモリ（十分でないバッファ、または少なすぎるバッファなど）に関係していること

もあります。共有メモリの設定を変更できます。

共有メモリの設定を変更できます。

p.115 の「共有メモリ (データバッファの数とサイズ) について」を参照してください。

警告: 次の手順では、データが消失することがあります。 SKIP_DISK_WRITES touch ファイルは、ディスクのすべてのバックアップデータ書き込み操作を無効にします。本番環境のサーバーでこのファイルをタッチすること推奨されません。このファイルをタッチすると、

データが損失します。このテストの間はアクティブな本番環境のポリシーを無効にします。このテストが完了したら、touch ファイルを削除する必要があります。（手順 7 を参照してください。）

SKIP_DISK_WRITES touch ファイルを使ってディスク I/O を測定する方法

1 イメージのディレクトリパスとして /tmp または他のディレクトリを使って、新しいディスクストレージユニットを作成します。

2 新しいディスクストレージユニットを使うポリシーを作成します。

3 このテストの間はアクティブな本番環境のポリシーを無効にします。

4 次のように入力します。

UNIX の場合:

/usr/openv/netbackup/db/config/SKIP_DISK_WRITES

Windows の場合:

install_path¥Netbackup¥db¥config¥SKIP_DISK_WRITES

このファイルはディスクバックアップのためのすべてのデータ書き込み操作を無効に

しますが、ディスクフラグメントと関連メタデータの作成は維持されます。

5 このポリシーを使ってバックアップを実行します。

NetBackup はディスクへの本当のバックアップと同じようにストレージユニットのディレクトリにファイルを作成します。このイメージファイルは 0 バイトの長さです。


6 長さが 0 のファイルを削除し、リストアできないバックアップの NetBackup カタログを消去するには、次のコマンドを実行します。

UNIX の場合:

/usr/openv/netbackup/bin/admincmd/bpexpdate -backupid backupid -d 0

Windows の場合:

install_path¥Netbackup¥bin¥admincmd¥bpexpdate -backupid backupid -d 0

backupid はストレージユニットのディレクトリにあるファイルの名前です。

7 SKIP_DISK_WRITES ファイルを削除します。

8 この手順で無効化されたポリシーを再アクティブ化します。

iostat ユーティリティを使ったディスクパフォーマンスの測定（UNIX、Linux）iostat ユーティリティを使って、平均待機時間やディスク利用率のようなデバイスの I/Oパフォーマンスを調べることができます。

次のように実行します。

iostat -ktxN 5

ここで、5 は更新間隔を 5 秒に指定します。

次に出力例を示します。

iostat -ktxN 5

Time: 07:39:14 AM

avg-cpu: %user %nice %system %iowait %steal %idle

5.02 0.00 8.84 0.84 0.00 85.30

Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

sda 0.00 .40 0.00 3.80 0.00 48.80 25.68 0.11 29.89 3.37 1.28

sdb 0.00 7.60 0.80 9.40 3.20 69.60 14.27 0.52 50.90 3.53 3.60

sys-r 0.00 0.00 0.00 2.00 0.00 8.00 8.00 0.02 10.80 2.40 0.48

sys-swap 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sys-usr 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

sys-h 0.00 0.00 0.80 27.20 3.20 108.80 8.00 1.33 47.63 1.11 3.12

sdc 0.00 2.60 0.00 3.60 0.00 25.60 14.22 0.01 3.56 0.22 0.08

sdd 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

メモ: この例は Linux システムのものです。他のオペレーティングシステムでは異なるオプションを使う可能性があります。詳しくは iostat のマニュアルページを参照してください。


この例では、sys-xx LVM デバイスは sdb と sdc のディスクで構成されています。

有用なレポート値は次のとおりです。

■ await: 仮想デバイスと物理ディスクの両方における、デバイスの I/O 要求が完了する平均時間（ミリ秒）。一般に、平均待機値が低いとスループットが優れています。

■ %util: I/O 要求がデバイスに送信された CPU 時間の割合。値が 100% に達すると、デバイスの飽和が起きます。割合が低い方が優れています。

GEN_DATA 指示句を使ったパフォーマンスの測定（UNIX、Linux）GEN_DATA 指示句を使って bpbkar とストレージユニット間の I/O 速度をテストできます。詳しくはシマンテック社の次の TechNote を参照してください。


CPU 負荷の監視（UNIX と Linux）CPU 負荷を監視する方法

1 メモリの使用を監視するために vmstat ユーティリティを使います。

2 vmstat の出力にある CPU の us と sy 列を合計し、ユーザータスクとシステムタスクに使われている CPU の合計割合を取得します。

詳しくは vmstat のマニュアルページを参照してください。

vmstat スキャン率は発生したスワッピングアクティビティの量を示します。

メモ: また、sar コマンドはメモリの使用状況に関する見通しを提供します。

Windows パフォーマンスモニターについてパフォーマンスモニターはオブジェクト、カウンタ、インスタンスに関する情報で編成され

ます。

オブジェクトはプロセッサや物理ディスクなどのシステムリソースのカテゴリです。オブジェクトのプロパティはカウンタです。［Processor］オブジェクト用のカウンタには［%ProcessorTime］（デフォルトカウンタ）と［Interrupts/sec］が含まれます。重複カウンタはインスタンスによって処理されます。たとえば、複数 CPU システムの特定の CPU の［%ProcessorTime］を監視する場合、［Processor］オブジェクトを選択します。その後、そのオブジェクトの［%Processor Time］カウンタを選択してから、そのカウンタに特定の CPU インスタンスを選択します。

パフォーマンスモニターでは、リアルタイム形式でデータを表示したり将来の分析用にロ

グでデータを集めたりすることができます。評価対象の特定のコンポーネントは CPU 負荷、メモリ使用、ディスク負荷を含んでいます。



メモ: 結果をゆがめる可能性がある負荷を減らすために、テストホストの監視にはリモートホストを使ってください。

Windows の CPU 負荷の監視要求されたタスクをシステムが問題なく達成できるかどうかを判断するには、次の手順を

使用します。

Windows の CPU 負荷を監視する方法

1 Windows パフォーマンスモニターを起動します。

手順については、Microsoft 社のマニュアルを参照してください。

2 CPU の負荷を判断するには、［Processor］オブジェクトの［% Processor Time］カウンタを監視します。

［%Processor Time］では、一般に 0% から 80% の値が安全です。80% から 90%の値はシステムの負荷が高いことを示します。一貫して値が 90% を超える場合は、CPU がボトルネックであることを示します。

一時的に値が 100% に近くなる場合は正常で、必ずしもボトルネックになっていることを示しません。ただし、100% に近い負荷が続く場合は、システムをチューニングして処理の負荷を減らすか、高速プロセッサにアップグレードすることを検討して

ください。

3 プロセッサを待機しているアクティブなプロセスの数を判断するには、［System］オブジェクトの［Process Queue Length］カウンタを監視します。

2 つを越える［Processor Queue Lengths］が継続的にある場合は非常に多くのスレッドが実行待ちになっていることを示します。正しく［Processor Queue Length］カウンタを監視するには、パフォーマンスモニターがスレッド関連カウンタを追跡して

いる必要があります。キューの長さが常に 0 の場合は、0 以外の値が表示されることを確認します。

［Processor Queue Length］のデフォルトの単位が 1 でないことがあります。データの読み方が正しいことを確認してください。たとえば、デフォルトの単位が 10x の場合、40 は 4 つの処理が待機中であることを意味します。

Windows のメモリ使用の監視メモリはバックアップ操作のパフォーマンスを高める重要なリソースです。


Windows のメモリ使用を監視する方法

1 Windows パフォーマンスモニターを起動します。

手順については、Microsoft 社のマニュアルを参照してください。

2 メモリの使用状況を検査するには、次の情報を表示します。

［Committed Bytes］は予約とは反対にコミットされた仮想メモリのサイズを表します。コミットされたメモリは利用可能な

ディスクストレージを持っているか、またはディスクストレージ

を要求することがないほど大きなメインメモリを持っている必

要があります。［Committed Bytes］の数値が物理メモリの量に近づくか超えるかするとページスワッピングの問題が発

生します。

Committed Bytes

［Page Faults/sec］はプロセッサのページフォルトの件数です。処理がメインメモリの作業セットにない仮想メモリのペー

ジを参照するとページフォルトが発生します。高いページ

フォルト率はメモリが不十分なことを示している場合がありま

す。

Page Faults/sec

Windows のディスク負荷の監視パフォーマンスモニターでディスクのパフォーマンスを監視するためにディスクパフォー

マンスカウンタを使うには、そのカウンタを有効にする必要があることがあります。Windowsではデフォルトでシステムのディスクパフォーマンスカウンタが有効になっていないことが

あります。

ディスクパフォーマンスカウンタについての詳細を入手する方法

◆ 次を入力します。

diskperf -help

カウンタを有効にしてディスク監視を有効にする方法

1 次を入力します。

diskperf -y

2 システムを再ブートします。


カウンタを無効にしてディスク監視をキャンセルする方法

1 次を入力します。

diskperf -n

2 システムを再ブートします。

ディスクパフォーマンスを監視する方法

1 ［PhysicalDisk］オブジェクトの［%Disk Time］カウンタを使用します。

選択したディスクドライブが読み込みまたは書き込みの要求を処理している経過時

間の割合を追跡します。

2 ［Avg. Disk Queue Length］カウンタを監視して 1 秒を越えて継続する 1 より大きな値に注意を払います。

1 秒を越える 1 より大きな値は複数の処理が要求に対してディスクのサービス待ちになっていることを示します。

p.94 の「SKIP_DISK_WRITES touch ファイルを使ったディスクパフォーマンスの測定」を参照してください。

ディスクパフォーマンスの向上ディスクパフォーマンスを高めるために次の技術を使うことができます。

■ ディスクパフォーマンスの測定については、次のトピックを参照してください。

p.94 の「SKIP_DISK_WRITES touch ファイルを使ったディスクパフォーマンスの測定」を参照してください。

■ データのフラグメンテーションレベルを調べます。

極度にフラグメント化されたディスクではスループットレベルが制限されます。ディスクをデフラグするためにディスク保守ユーティリティを使います。

■ パフォーマンスを改善するために、システムにディスクを追加することを検討します。

複数の処理がデータを同時にログに記録しようとする場合は、複数の物理ディスク間

でデータを分割します。

■ データ転送が圧縮ディスクを含んでいるかどうか判断します。

Windows のドライブ圧縮ではディスクの読み込みまたは書き込み操作にオーバーヘッドが追加されるため、NetBackup のパフォーマンスに悪影響を及ぼします。ディスクに空きがない状態を避けるために必要なときのみ Windows 圧縮を使います。

■ RAID（Redundant Array of Independent Disks）を使ったシステムに変換することを検討します。

費用がかかりますが、RAID デバイスでは高いスループットとより高い信頼性（RAIDのレベルに依存）が提供されます。

100第 6 章パフォーマンス測定ディスクパフォーマンスの向上

■ ディスクの駆動に使われるコントローラ技術の種類を判断します。

異なるシステムを使うと結果がよくなる場合があります。

p.23 の表 1-4 を参照してください。

101第 6 章パフォーマンス測定ディスクパフォーマンスの向上

NetBackup のデータ転送パスのチューニング


■ NetBackup のデータ転送パスについて

■ データ転送パスのチューニングついて

■ NetBackup のデータ転送パスのチューニングの提案

■ データ転送パスでの NetBackup クライアントのパフォーマンス

■ データ転送パスでの NetBackup ネットワークのパフォーマンス

■ データ転送パスでの NetBackup サーバーのパフォーマンス

■ データ転送パスでの NetBackup ストレージデバイスのパフォーマンス

NetBackup のデータ転送パスについてNetBackup の全体的なパフォーマンスを制限しているのは、バックアップシステムで最も遅いコンポーネントです。たとえば、速いテープドライブを過負荷なサーバーと組み合わせると、低いパフォーマンスがもたらされます。速いテープドライブを遅いネットワーク上で使った場合も、低いパフォーマンスがもたらされます。

バックアップシステムはデータ転送パスと呼ばれます。通常、パスはディスク上のデータから開始し、テープまたはディスク上のバックアップコピーで終了します。

この章では、NetBackup の標準データ転送パスを NetBackup クライアント、ネットワーク、NetBackup サーバー、ストレージデバイスの 4 つのコンポーネントに細分します。

この章では、テストの観点から見た NetBackup のパフォーマンスの評価と改善について説明します。システム全体のパフォーマンスの可変要素の影響を理解するために可変要素を隔離する方法を説明します。またそれらの可変要素に関して NetBackup パフォー

7

マンスを最適化する方法を説明します。本番環境のシステムでは、すべての可変要素を最適化することはできない場合があります。

メモ: データベースバックアップの必要条件は、ファイルシステムバックアップの条件と同じではないことがあります。特に注記がないかぎり、この章の情報はファイルシステムバックアップに適用されます。

データ転送パスのチューニングついてこの章には、NetBackup を最適化する方法に関する情報が含まれます。この章では、特定のシステムのチューニングに関するアドバイスは記載していません。 NetBackup インストールの最適なチューニングについては、ご購入先に問い合わせてください。

特定のチューニング手順を試す前に、次を考慮してください。

■ システムが NetBackup の推奨された最小必要条件を満たすことを確認します。これらの必要条件について詳しくは『NetBackup インストールガイド』と『NetBackupリリースノート』を参照してください。

■ NetBackup の最新のソフトウェアパッチをインストールしていることを確認します。

■ ハードウェアを調べます。

多くのパフォーマンス上の問題は、ハードウェアまたは他の環境に依存する問題を調

べる必要があります。環境で得られる最大パフォーマンスを判断するためには全体のデータ転送パスを理解する必要があります。多くの場合、低いパフォーマンスは不十分な計画の結果ですが、これは転送パスのコンポーネントに対する期待が非現実

的であることが原因になっています。

NetBackup のデータ転送パスのチューニングの提案すべてのバックアップシステムに改善の余地があります。バックアップインフラから最適なパフォーマンスを得るのは難しくありませんが、処理に影響する可能性のある多くの要因

を注意深く検討する必要があります。最初のステップは、バックアップデータパスにある各ハードウェア、ソフトウェア、ネットワーキングコンポーネントを正確に評価することです。

多くのパフォーマンスの問題は、NetBackup のパラメータの変更を試行する前に解決されます。

NetBackup ソフトウェアでは、パフォーマンスの問題の隔離と設定変更の影響の評価に役立つリソースが数多く提供されています。ただし、NetBackup の設定パラメータの変更後に、バックアップとリストア両方のプロセスを完全にテストすることが不可欠です。

このトピックでは、バックアップシステムのパフォーマンスを改善し、ボトルネックを避ける

ための実用的なアイデアを示します。

バックグラウンドの詳細は NetBackup の次のマニュアルを参照してください。

103第 7 章 NetBackup のデータ転送パスのチューニングデータ転送パスのチューニングついて

『NetBackup 管理者ガイド』(Vol. 1 および Vol. 2)

『NetBackup トラブルシューティングガイド』

表 7-1 NetBackup のデータパスのチューニングの提案

説明チューニングの提案

多重化は複数のクライアントから単一のテープドライブまたは複数のテープドライブに複数の

データストリームを書き込みます。多重化は、低速なクライアント、複数の低速ネットワーク、多くの小さいバックアップ（増分バックアップなど）のバックアップパフォーマンスを改善できます。

多重化によって、デバイスが利用可能になるのを各ジョブが待機する時間が短くなります。それによりストレージデバイスの転送速度が最大限に利用されます。


多重化の使用について詳しくは『NetBackup 管理者ガイド Vol.2』も参照してください。

多重化を使用する

ストライプ化したディスクのセットは、すべてのドライブからデータを同時に取得し、ディスクドラ

イブとテープドライブ間のデータ転送を高速化します。

複数のドライブにディスクボ

リュームをストライプ化する

すべての増分バックアップを毎日同時刻に行うように設定できます。また複数の日にわたる完全バックアップの実行時刻をずらすことができます。大型システムを週末にバックアップする一方で、より小規模なシステムを週全体に分散できます。完全バックアップを増分バックアップより先に開始できます。完全バックアップが増分バックアップより前に終わることがあるため、すべてまたはほとんどのバックアップ処理時間帯を増分バックアップのために使うことができます。

バックアップ処理時間帯を最

大限に使う

SAN クライアントは、LAN 上ではなく SAN の接続上でメディアサーバーにバックアップされるクライアントです。 SAN クライアントの技術は、大容量のデータファイルをディスクから迅速に読み込み、SAN 上でストリーム送信できる大きいデータベースとアプリケーションサーバー用です。 SAN クライアントは、ディスクの読み込み速度が比較的遅いファイルサーバーには適していません。

p.72 の「ベストプラクティス: NetBackup SAN クライアント」を参照してください。

大容量のクライアントを SANクライアントまたは SAN メディアサーバーに変換する

バックアップ時間を減らし、エンタープライズネットワーク上のネットワークトラフィックを減らすか、

または除去するために 1 つ以上のネットワークをバックアップ専用にします。さらに、より速い技術に変換し、エンタープライズネットワークのパフォーマンスに影響を与えないでシステムを

いつでもバックアップできます。このアプローチはユーザーがバックアップの実行中のシステム負荷を気にしないことを想定しています。

バックアップ時間とネットワー

クトラフィックを減らすために

専用のプライベートネットワー

クを使う

多くの大容量のサーバーが同じネットワークでバックアップする場合は、そのうちのいくつかを

メディアサーバーに変換するか、またはプライベートのバックアップネットワークに接続します。

どちらかを行うと、バックアップ時間が短縮され、他のバックアップのネットワークトラフィックが削

減されます。

1 つのネットワークへのサーバーの集中を避ける

バックアップサーバー用に、バックアップのみの専用システムを使用します。バックアップに無関係な複数のアプリケーションも実行するサーバーを使うと、パフォーマンスと保守時間帯に深

刻な影響を与えることがあります。

専用のバックアップサーバー

を使ってバックアップを行う

104第 7 章 NetBackup のデータ転送パスのチューニングNetBackup のデータ転送パスのチューニングの提案


NetBackup カタログをバックアップする必要があることを忘れないでください。 NetBackup カタログリカバリを容易にするために、マスターサーバーはスタンドアロンまたはロボットライブラリ

内部の専用テープドライブにアクセスする必要があります。

カタログのバックアップ作成に

関する必要条件を考慮する

バックアップ時間を減らすために複数のドライブを使うことができます。複数のドライブに負荷を分散させるために、ストリームか NetBackup ポリシーを再設定する必要がある場合もあります。

バックアップ負荷を均等にす

る

帯域幅の制限を使うと、ネットワーク上の 1 つ以上の NetBackup クライアントが消費するネットワーク帯域幅を制限できます。帯域幅の設定は、［ホストプロパティ（Host Properties）］ > ［マスターサーバー（Master Servers）］の［プロパティ（Properties）］に表示されます。実際の制限は、バックアップ接続のクライアント側で発生します。この機能はバックアップ時にのみ帯域

幅を制限します。リストアには影響しません。

バックアップが始まると、NetBackup は帯域幅制限の設定を読み込んでから、適切な帯域幅の値を判断してクライアントに渡します。サブネット上のアクティブなバックアップ数が増減すると、NetBackup はそのサブネットでの帯域幅の制限を動的に調整します。他のバックアップが開始されると、NetBackup サーバーは、サブネット上で稼働している他の NetBackup クライアントに帯域幅の設定値を小さくするように指示します。同様に、クライアントの数が減少すると、

1 つのクライアントに割り当てられる帯域幅が増加します。帯域幅の値の変更は、バックアップの停止および開始時ではなく、定期的に行われます。この機能によって、帯域幅の値の変更

数を減らすことができます。

帯域幅の制限を考慮する



NetBackup はサーバー、クライアント、ポリシー、デバイス間で負荷を分散する方法を提供します。これらの設定が相互に関連する可能性があることに注意してください。1 つの問題を補正すると、別の問題が引き起こされることがあります。最もよいアプローチは、問題が予想されない場合や問題が起きない場合は、デフォルトを使うことです。

次の 1 つ以上を試みます。

■ サーバーのバックアップ負荷を調整します。

サーバーがバックアップする 1 つ以上のポリシーについて、［ポリシーごとにジョブ数を制限する（Limit jobs per policy）］属性を変更します。たとえば、［ポリシーごとにジョブ数を制限する（Limit jobs per policy）］の値を減らし、特定のサブネットワーク上のサーバーの負荷を減少させることができます。他のサーバーのストレージユニットを使うためにポリシーかスケジュールを再設定します。 1 つ以上のクライアントで帯域幅制限を使います。

■ 特定の期間中のみサーバーのバックアップ負荷を調整します。

（メディアサーバーを使う場合）負荷を処理できるサーバーのストレージユニットを使うように

スケジュールを再設定します。

■ クライアントのバックアップ負荷を調整します。

グローバル属性の［1 クライアントあたりの最大ジョブ数 (Maximum jobs per client)］を変更します。［1 クライアントあたりの最大ジョブ数（Maximum jobs per client）］の値を増やすと、任意の 1 つのクライアントが同時に処理できるジョブ数が増えるため、負荷が増加します。

■ クライアントのバックアップにかかる時間を削減します。

クライアントが並列して実行できるジョブの数を増やすか、または多重化を使用します。クラ

イアントをバックアップするポリシーについてサーバーが同時に実行できるジョブ数を増や

します。

■ ポリシーに優先度を指定します。

他のポリシーと比較して優先するポリシーの［ポリシーごとにジョブ数を制限する（Limit jobsper policy）］属性値を増やします。または、ポリシーの優先度を高くします。

■ 高速ネットワークと低速ネットワーク間の負荷を調整します。

より高速なネットワーク上のポリシーとクライアントについて、［ポリシーごとにジョブ数を制限

する（Limit jobs per policy）］と［1 クライアントあたりの最大ジョブ数（Maximum jobs perclient）］の値を増やします。より低速なネットワークについては、これらの値を減らします。もう 1 つのソリューションは、帯域幅制限を使うことです。

■ 1 つ以上のクライアントが生成するバックアップ負荷を制限します。帯域幅制限を使って、クライアントが使う帯域幅を減らします。

■ デバイスの使用を最大化します。

多重化を使用します。また、サーバー、クライアント、ネットワークのパフォーマンスの問題を

引き起こさない範囲で、ストレージユニット、ポリシー、クライアントあたりの並列実行ジョブ数

をできるだけ多くします。

■ バックアップがデバイスを占有しないようにします。

NetBackup が各ポリシーについて同時に使うことができるデバイス数、またはストレージあたりのドライブ数を制限します。もう 1 つのアプローチは、Media Manager 管理からいくつかのデバイスを除外することです。

負荷分散を試みる


p.107 の「データ転送パスでの NetBackup クライアントのパフォーマンス」を参照してください。

p.108 の「データ転送パスでの NetBackup ネットワークのパフォーマンス」を参照してください。

p.115 の「データ転送パスでの NetBackup サーバーのパフォーマンス」を参照してください。


データ転送パスでの NetBackup クライアントのパフォーマンス

多くの要因が NetBackup のデータ転送パスの NetBackup クライアントコンポーネントに影響を与えます。 NetBackup パフォーマンスを改善する可能性のある変更を識別するには、次を考慮します。

表 7-2 NetBackup のデータ転送パスのクライアントコンポーネントに影響を与える要因

注意事項要因

フラグメンテーションはディスクからのデータ転送速度に深刻な影響を与えます。フラグメンテーションはディスク管理ユーティリティソフトウェアを使って修復できます。

ディスクフラグメンテーション

パフォーマンスを改善するためにシステムにディスクを追加します。

複数の処理がデータを同時にログに記録しようとする場合は、複数の物理ディスク間でデータ

を分割します。

ディスクの数 (Number ofdisks)

RAID（Redundant Array of Inexpensive Disks）に基づくシステムに変換します。一般に RAIDデバイスではより高いスループットと信頼性（RAID のレベルに依存）が提供されます。

ディスクアレイ

バックアップのために高帯域幅を必要とする重要なデータについては、SAN クライアント機能を検討します。

詳しくは次に挙げるドキュメントを参照してください。

■ 『NetBackup SAN クライアントおよびファイバートランスポートガイド』■ 『SAN Client Deployment, Best Practices and Performance Metrics』（TechNote）


SAN クライアント

異なるシステムを使うと結果がよくなる場合があります。ディスクの駆動に使われるコ

ントローラ技術の種類

107第 7 章 NetBackup のデータ転送パスのチューニングデータ転送パスでの NetBackup クライアントのパフォーマンス


注意事項要因

ウイルススキャンは NetBackup クライアント、特に、大規模な Windows ファイルサーバーなどのシステムのパフォーマンスに深刻な影響を与えることがあります。バックアップまたはリストア時にウイルススキャンを無効にすることを考慮します。

ウイルススキャン

bpstart_notify.bat スクリプトと bpend_notify.bat スクリプトは、実行中のアプリケーションを停止してデータのバックアップを作成する場合など、特定の状況で非常に役立ちます。

ただし、バックアップの開始時または終了時の不必要に長い遅延を避けるために、これらのス

クリプトは注意して作成する必要があります。スクリプトがバックアップに不可欠なタスクを実行しない場合は、それらを削除します。

NetBackup 通知スクリプト

バックアップされるデータが NetBackup のインストールと同じ物理ディスクにある場合は、パフォーマンスに悪影響を及ぼすことがあります。NetBackup のデバッグログファイルが生成される場合には、特にその傾向が強くなります。ログが使われる場合、低下の程度は、ログの詳細設定に大きく影響されます。もし可能なら、ディスクドライブの競合を避けるために別の物理ディスクに NetBackup をインストールします。

NetBackup ソフトウェアの場所

データのバックアップより前にスナップショットを取得する場合は、スナップショットの取得に必要

な時間がパフォーマンスに影響することがあります。

スナップショット（ハードウェア

またはソフトウェア）

Job Tracker がクライアントで動作する場合は、バックアップ前に、バックアップするデータの量が NetBackup によって概算されます。この概算時に NetBackup サーバーにデータは書き込まれないので、この概算の収集は起動時間とデータスループット率に影響します。

メモ: Job Tracker はデフォルトでは無効になっています。 Job Tracker を起動すると、ユーザーがログアウトするまで動作します。

データ収集プロセスに時間がかかりすぎる場合は、NetBackup Client Job Tracker の実行は避けてください。

NetBackup Client JobTracker

NetBackup クライアントコマンド bpbkar（UNIX）または bpbkar32（Windows）を使って、バックアップデータを NetBackup クライアントが読み込む速度を判断できます。パフォーマンスのボトルネックになるデータ読み込み速度を除去できる場合があります。

p.93 の「テープやディスク出力に左右されないパフォーマンス測定について」を参照してください。

NetBackup クライアントソフトウェアの理論上のパフォーマ

ンスの判断

データ転送パスでの NetBackup ネットワークのパフォーマンス

NetBackup の全体的なパフォーマンスを改善するには、次のネットワークコンポーネントと要因を考慮します。

ネットワークインターフェースの設定ネットワーク接続が正しくインストールされ、設定されていることを確かめます。

108第 7 章 NetBackup のデータ転送パスのチューニングデータ転送パスでの NetBackup ネットワークのパフォーマンス


■ NetBackup サーバーとクライアントのネットワークインターフェースカード（NIC）は、全二重に設定する必要があります。自動認識または自動ネゴシエーションは使いません。

■ 各ネットワークケーブルの両端（NIC カードとスイッチ）の速度とモードは同一に設定する必要があります。（NIC とスイッチは両方とも全二重である必要があります。）そうしないと、リンクのダウン、Excessive Collision または Late Collision、エラーが生じます。

■ 自動ネゴシエーションが使われている場合は、接続の両端が同じモードと速度に設

定されていることを確認してください。

■ NIC とスイッチに加えて、すべてのルーターを全二重に設定する必要があります。

■ 自動認識を使うと、ネットワークの問題とパフォーマンス上の問題が発生することがあ

ります。

■ NIC の設定を判断し変更する方法については、オペレーティングシステムのマニュアルを参照してください。

ネットワークの負荷リモートバックアップのパフォーマンスを評価するには、次を考慮します。

■ ネットワークトラフィックの量

■ ネットワークトラフィックが高い時間の長さ

高いネットワークトラフィックが断続的に頻繁に発生すると、データスループット率が低下

することがあります。ただし、ネットワークトラフィックが高い状態が続く場合、ネットワーク

がボトルネックである可能性があります。ネットワークトラフィックが低いときにバックアップ

をスケジュールすることを試みてください。ネットワークに負荷がかかっている場合は、バッ

クアップとリストアのトラフィック専用に二次ネットワークを実装することもできます。

注意: ネットワークを確認するには、FTP を使用して大容量のファイル (50 MB 以上) をメディアサーバーからクライアントに転送した後、再びサーバーに転送してください。それ

ぞれの操作にかかる時間を計ってください。ファイルをどちらかの方向に移動するとき、も

う一方の方向に移動するときよりも極端に時間がかかる場合は、ネットワークに問題があ

ります。

NetBackup メディアサーバーのネットワークバッファサイズの設定NetBackup メディアサーバーには、ネットワークバッファ領域のサイズを調整するために使うことができるチューニングパラメータがあります。オペレーティングシステムは bptmの子プロセスとクライアントプロセスの間の接続にこのバッファ領域を使います。このバッファ領域にネットワークから受信したデータ（バックアップ）またはネットワークに書き込ん

だデータ（リストア）がキャッシュされます。パラメータで NetBackup がネットワークバッ


ファ領域に使う値を設定しますが、オペレーティングシステムで変更が許可されないこと

があります。

NetBackup メディアサーバーの設定で、ネットワークバッファ領域のデフォルト以外のサイズを使うようにオペレーティングシステムに要求することができます。 NET_BUFFER_SZtouch ファイルがあれば、bptm はオペレーティングシステムにサイズを調整するように要求します。オペレーティングシステムで変更が許可されるかどうかは、オペレーティングシステムのリビジョンと現在の TCP のチューニングで決まります。

各種のプラットフォームの bptm ログの例を次に示します。これらの例は、使用されたサイズと NetBackup から要求された以前のサイズが bptm でどのように記録されるかを示したものです。

たとえば、

Solaris 10

setting receive network buffer to 65536 bytes

receive network buffer is 64240 bytes

AIX 5.3


HP-UX 11.00

setting receive network buffer to 131072 bytes


Windows の場合

このパラメータのデフォルト値は、NetBackup のデータバッファサイズから次の式を使って導出されます。

バックアップジョブの場合: (<data_buffer_size> * 4) + 1024

リストアジョブの場合: (<data_buffer_size> * 2) + 1024

テープの場合:

NetBackup のデータバッファサイズのデフォルト値は 65536 バイトなので、この式の結果として、デフォルトの NetBackup ネットワークバッファサイズは、バックアップの場合に263168 バイト、リストアの場合に 132096 バイトになります。

ディスクの場合:

NetBackup のデータバッファサイズのデフォルト値は 262144 バイトなので、この式の結果として、デフォルトの NetBackup ネットワークバッファサイズは、バックアップの場合に1049600 バイト、リストアの場合に 525312 バイトになります。


ネットワークのバッファサイズを設定する方法


UNIX の場合

/usr/openv/netbackup/NET_BUFFER_SZ

/usr/openv/netbackup/NET_BUFFER_SZ_REST

Windows の場合

install_path¥NetBackup¥NET_BUFFER_SZ

install_path¥NetBackup¥NET_BUFFER_SZ_REST

2 バッファファイルについて次の点に注意してください。

これらのファイルには、バイト単位でネットワークバッファサイズを指定する単一の整

数が含まれます。各ファイルの値がオペレーティングシステムで許容される最小値と最大値の範囲に収まっていないと、確立された接続が不安定になる可能性があり

ます。たとえば、64 KB のネットワークバッファサイズを使うには、ファイルに 65536が含まれます。ファイルに整数 0（ゼロ）が含まれている場合は、ネットワークバッファサイズのデフォルト値が使われます。バッファファイルについての詳細な情報があります。


NET_BUFFER_SZ ファイルがあり、NET_BUFFER_SZ_REST ファイルがない場合は、NET_BUFFER_SZ で、バックアップとリストアのネットワークバッファサイズを指定します。

NET_BUFFER_SZ_REST ファイルがある場合は、そのコンテンツでリストアのネットワークバッファサイズを指定します。

ファイルが両方ともあれば、NET_BUFFER_SZ ファイルでバックアップのネットワークバッファサイズを指定します。 NET_BUFFER_SZ_REST ファイルでリストアのネットワークバッファサイズを指定します。

メディアサーバーのローカルバックアップまたはリストアジョブはネットワーク上でデー

タを送信しないので、このパラメータはそれらの操作に影響しません。このパラメータは、ネットワークで読み書きする NetBackup メディアサーバープロセス、具体的には bptm または bpdm プロセスでのみ使われます。 NetBackup の他のプロセスはこのパラメータを使いません。

他のパラメータに関連するネットワークバッファサイズ

ネットワークバッファサイズのパラメータは、クライアント上の通信バッファサイズパラメータ

に対応するメディアサーバー上のパラメータです。NetBackup が正しく機能するために、ネットワークバッファサイズがすべての NetBackup システムで同じである必要はありませ



ん。ただし、メディアサーバーのネットワークバッファサイズがクライアントの通信バッファ

サイズと同じ場合、ネットワークスループットが改善することがあります。

同様に、ネットワークバッファサイズは NetBackup のデータバッファサイズと直接関係はありません。


2 つのバッファは個別に調整できるパラメータです。ただし、ネットワークバッファサイズをデータバッファより大幅に大きい値に設定すると、多くの NetBackup インストール環境で最大のパフォーマンスが実現されます。

合成完全バックアップのための AIX のネットワークバッファサイズの増加

AIX の合成完全バックアップの実行速度が遅い場合は、NET_BUFFER_SZ ネットワークバッファを 262144 (256 KB) に増やします。

AIX のネットワークバッファサイズを増加する方法


/usr/openv/netbackup/NET_BUFFER_SZ

2 32032 から 262144 にデフォルト設定を変更するには、ファイルに数字 262144 を入力します。

このファイルの書式は決まっていません。バイトサイズのみを含めてください。

$ cat /usr/openv/netbackup/NET_BUFFER_SZ

262144

$

この値を変更すると、メディアサーバー上のバックアップ操作とリストア操作に影響す

ることがあります。バックアップとリストアをテストして、変更がパフォーマンスに悪影響

を与えないことを確認してください。

NetBackup クライアントの通信バッファサイズの設定NetBackup クライアントには、ネットワーク通信バッファのサイズを調整するチューニングパラメータがあります。このバッファは、バックアップのネットワークについてのデータを書き込みます。

このクライアントパラメータは、メディアサーバーのネットワークバッファサイズパラメータに

対応するパラメータです。 NetBackup が正しく機能するために、ネットワークバッファサイズがすべての NetBackup システムで同じである必要はありません。ただし、メディアサーバーのネットワークバッファサイズがクライアントの通信バッファサイズと同じなら、パ

フォーマンスが改善することがあります。


UNIX クライアントの通信バッファサイズパラメータを設定する方法

◆ /usr/openv/netbackup/NET_BUFFER_SZ ファイルを作成します。

メディアサーバーの場合と同じように、通信バッファサイズを指定する単一の整数を

ファイルに含めてください。通常、クライアントの NET_BUFFER_SZ ファイル内の値がメディアサーバーの NET_BUFFER_SZ ファイル内の値と一致するときの方が、パフォーマンスがよくなります。各ファイルの値がオペレーティングシステムで許容される最小値と最大値の範囲に収まっていないと、確立された接続が不安定になる可能性

があります。バッファファイルについての詳細な情報があります。


NET_BUFFER_SZ_REST ファイルは、クライアントでは使われません。 NET_BUFFER_SZファイルの値はバックアップとリストアの両方に使われます。

Windows クライアントの通信バッファサイズパラメータを設定する方法

1 NetBackup 管理コンソールの［ホストプロパティ（Host Properties）］で、［クライアント（Clients）］を展開し、パラメータを変更するクライアントの［クライアントプロパティ（Client Properties）］ > ［Windows クライアント（Windows Client）］ > ［クライアントの設定（Client Settings）］ダイアログボックスを開きます。

2 ［通信バッファ（Communications buffer）］フィールドに、新しい値を入力します。

このパラメータは KB 単位の数値で指定します。デフォルトの値は 32 です。バックアップ操作のために、追加の KB が内部的に加算されます。したがって、バックアップのデフォルトのネットワークバッファサイズは 33792 バイトです。一部の NetBackupインストール環境では、このデフォルト値では小さすぎることがあります。 128 という値はこれらのインストール環境でパフォーマンスを改善します。

メディアサーバーのローカルバックアップジョブはネットワーク上でデータを送信しな

いので、このパラメータはそれらのローカル操作に影響しません。 NetBackup のbpbkar32 プロセスのみがこのパラメータを使います。マスターサーバー、メディアサーバー、クライアント上の他の NetBackup プロセスでは使われません。

3 NetBackup のバッファ設定を変更した場合は、新しい設定でリストアのパフォーマンスをテストします。

NOSHM ファイルについてバックアップが実行されるたびに、NetBackup は NOSHM ファイルの存在を調べます。設定を有効にするためにサービスを停止して開始する必要はありません。 NOSHM を使うのは、たとえば、NetBackup サーバーが、大量の共有メモリを使う Oracle などの別のアプリケーションをホストするときです。

NOSHM は、共有メモリの問題を解決するときの回避策として、また問題の原因が共有メモリであることを検証するために使用できるため、テストでも役立ちます。



メモ: NOSHM はクライアントのホストがメディアサーバーのときだけ操作に影響します。

NOSHM は、ローカルバックアップをリモートバックアップであるかのように強制的に実行します。ローカルバックアップは直接接続されたストレージユニットがあるクライアントのバックアップです。例として、マスターサーバーまたはメディアサーバーであるクライアントがあります。リモートバックアップは、クライアントからマスターサーバーまたはメディアサーバーのストレージユニットにネットワーク接続を介してデータを渡します。

ローカルバックアップには、通常、ディスクから読み込んで共有メモリに書き込む 1 つ以上のプロセス（たとえば、bpbkar）があります。ローカルバックアップには、共有メモリから読み込んでテープに書き込む bptm プロセスもあります。リモートバックアップには、ソケット接続から bpbkar に読み込んで共有メモリに書き込む 1 つ以上の bptm（子）プロセスがあります。リモートバックアップには、共有メモリから読み込んでテープに書き込む bptm（親）プロセスもあります。 NOSHM は、クライアントとメディアサーバーが同じシステムにあるときでも、リモートバックアップモデルを強制的に実行します。

NOSHM を使わないローカルバックアップでは、共有メモリは bptm と bpbkar の間で使われます。バックアップがリモートかローカルか、また、NOSHM が存在するかどうかにかかわらず、共有メモリは常に bptm（親）と bptm（子）の間で使われます。

メモ: NOSHM は、bptm がテープまたはディスクに書き込まれるデータをバッファ処理するために使う共有メモリには影響しません。 bptm はローカルまたはその他のバックアップに共有メモリを使います。

ソケット通信（NOSHM ファイル）の使用マスターサーバーまたはメディアサーバーが自身のバックアップを作成するときに、

NetBackup は共有メモリを使ってバックアップのスピードをあげます。この場合に、NetBackup はプロセス間でのデータの転送にソケット通信ではなく共有メモリを使います。ただし、バックアップ時に共有メモリを使えない、または使うことが望ましくない場合があります。この場合、バックアップデータの交換に共有メモリではなくソケット通信を使うことができます。


ソケット通信を使う方法

◆ 次のファイルにタッチします。

UNIX の場合

/usr/openv/netbackup/NOSHM

Windows の場合

install_path¥NetBackup¥NOSHM

「ファイルにタッチする」とは、ファイルの変更時刻とアクセス時刻を変更することを意

味します。ファイル名に拡張子は含めないでください。

データ転送パスでの NetBackup サーバーのパフォーマンス

NetBackup サーバーのパフォーマンスを改善するには、データ転送パスに関する次の要因を考慮します。

■ p.115 の「共有メモリ (データバッファの数とサイズ) について」を参照してください。

■ p.126 の「NetBackup での親と子の遅延値の変更」を参照してください。

■ p.126 の「NetBackup の待機カウンタと遅延カウンタについて」を参照してください。

■ p.142 の「NetBackup リストアに対するフラグメントサイズの影響」を参照してください。

■ p.146 の「NetBackup のリストアのパフォーマンスに関するその他の問題」を参照してください。

共有メモリ (データバッファの数とサイズ) についてNetBackup メディアサーバーはネットワークとテープドライブまたはディスクドライブ間のデータをバッファ処理するために共有メモリを使います。(または、NetBackup メディアサーバーとクライアントが同じシステム上に存在する場合、ディスクとテープ間のデータを

バッファ処理します。)共有データバッファの数とサイズは、NetBackup メディアサーバーで設定できます。

NetBackup が共有メモリを最大限に活用するように、テープとディスクのバッファの数とサイズを変更できます。異なるバッファサイズを使用すると、高性能テープドライブのス

ループットが向上することがあります。変更を行うことで、他の種類のドライブのスループッ

トが改善されることもあります。

バッファ設定はメディアサーバーでのみ使用するものなので、純粋なマスターサーバー

やクライアントでは使わないでください。

115第 7 章 NetBackup のデータ転送パスのチューニングデータ転送パスでの NetBackup サーバーのパフォーマンス

メモ: リストアでは、リストアするイメージをバックアップするときに使ったバッファサイズと同じバッファサイズを使います。

共有データバッファのデフォルト数

表 7-3 に、さまざまな NetBackup 操作向けの共有データバッファのデフォルト数を示します。

表 7-3 共有データバッファのデフォルト数

共有データバッファの数

Windows の場合

共有データバッファの数

UNIX の場合

NetBackup 操作

3030多重化されていないバックアッ

プ

1212多重化されたバックアップ

3030非多重化プロトコルを使うリスト

ア

1212多重化プロトコルを使うリストア

3030検証

3030インポート

3030複製

3030NDMP バックアップ

共有データバッファのデフォルトのサイズ

さまざまな NetBackup 操作向けの共有データバッファのデフォルトサイズを表 7-4 に示します。

表 7-4 共有データバッファのデフォルトのサイズ

共有データバッファのサイズ

Windows の場合


UNIX の場合

NetBackup 操作

64 K (テープ)、256 K (ディスク)

64 K (テープ)、256 K (ディスク)

多重化されていないバックアッ

プ

64 K (テープ)、256 K (ディスク)

64 K (テープ)、256 K (ディスク)

多重化されたバックアップ



Windows の場合


UNIX の場合

NetBackup 操作

バックアップに使われたのと同

じサイズ

バックアップに使われたのと同

じサイズ

リストア、検証、インポート

読み込み側: バックアップに使われたのと同じサイズ

書き込み側: 64 K (テープ)、256 K (ディスク)

読み込み側: バックアップに使われたのと同じサイズ

書き込み側: 64 K (テープ)、256 K (ディスク)

複製

64 K (テープ)、256 K (ディスク)

64 K (テープ)、256 K (ディスク)

NDMP バックアップ

Windows では、それぞれの共有データバッファに対して単一のテープ I/O 操作が実行されます。したがって、このサイズはテープデバイスまたはオペレーティングシステムの最

大ブロックサイズを超えないようにする必要があります。Windows システムでは、場合によっては顧客はより大きい値を問題なく使っていることがありますが、一般に最大ブロック

サイズは 64 K です。このため、「テープブロックサイズ」と「共有データバッファサイズ」という用語はこの文脈では同義です。

NetBackup で必要な共有メモリ量次の式を使って、NetBackup で必要な共有メモリ量を計算できます。

必要な共有メモリ = (number_data_buffers * size_data_buffers) * number_tape_drives* max_multiplexing_setting

たとえば、共有データバッファの数が 16、共有データバッファのサイズが 64 KB であると仮定します。また 2 つのテープドライブがあり、最大多重化設定が 4 であると仮定します。前述の式に従うと、NetBackup には次のように 8 MB の共有メモリが必要です。

(16 * 65536) * 2 * 4 = 8 MB

これらの設定を変更する場合は注意してください。

p.125 の「共有メモリに対して行われた変更のテスト」を参照してください。

共有データバッファの数を変更する方法

メディアサーバーに次のファイルを作成することで、共有データバッファの数を変更でき

ます。ファイルには、共有データバッファの整数を入力します。

p.118 の「データバッファの数のファイルに関する注意事項」を参照してください。

■ UNIX の場合テープの場合:


/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS

/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS_RESTORE

NUMBER_DATA_BUFFERS によって指定する値は、次の NUMBER_DATA_BUFFERS_xxxxファイルのいずれも存在しなければすべてのバックアップ形式の共有メモリバッファの

数を決定します。


/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS_DISK

複数コピー（インラインコピー）の場合:

/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS_MULTCOPY

FT メディアサーバーの場合:

/usr/openv/netbackup/db/config/NUMBER_DATA_BUFFERS_FT

■ Windows の場合テープの場合:

install_path¥NetBackup¥db¥config¥NUMBER_DATA_BUFFERS

install_path¥NetBackup¥db¥config¥NUMBER_DATA_BUFFERS_RESTORE

NUMBER_DATA_BUFFERS によって指定する値は、次の NUMBER_DATA_BUFFERS_xxxxファイルのいずれも存在しなければすべてのバックアップ形式の共有メモリバッファの

数を決定します。


install_path¥NetBackup¥db¥config¥NUMBER_DATA_BUFFERS_DISK


install_path¥NetBackup¥db¥config¥NUMBER_DATA_BUFFERS_MULTCOPY

FT メディアサーバーの場合:注意: FT メディアサーバーは Windows でまだサポートされていません。


データバッファの数のファイルに関する注意事項


■ 各種のデータバッファの数のファイルは、NetBackup が使う共有データバッファの数を指定する単一の整数を含む必要があります。


■ NUMBER_DATA_BUFFERS ファイルがある場合は、そのコンテンツを使って、多重化されたバックアップと多重化されていないバックアップに使う共有データバッファの数が

決定されます。

■ 次の NUMBER_DATA_BUFFERS ファイルは特定のバックアップ形式のバッファ設定を可能にします。

■ NUMBER_DATA_BUFFERS_DISK

■ NUMBER_DATA_BUFFERS_MULTCOPY

■ NUMBER_DATA_BUFFERS_FT

これらのファイルで指定する値は NetBackup のデフォルトの数かNUMBER_DATA_BUFFERS で指定する値を上書きします。たとえば、NUMBER_DATA_BUFFERS_DISK では、テープではなくディスクにバックアップするときに別の値が考慮されます。 NUMBER_DATA_BUFFERS が存在し、NUMBER_DATA_BUFFERS_DISK が存在しない場合は、NUMBER_DATA_BUFFERS がテープとディスクのバックアップに適用されます。両方のファイルが存在する場合は、NUMBER_DATA_BUFFERS がテープバックアップに適用され、NUMBER_DATA_BUFFERS_DISK がディスクバックアップに適用されます。NUMBER_DATA_BUFFERS_DISK のみが存在する場合は、ディスクバックアップのみに適用されます。

■ NUMBER_DATA_BUFFERS ファイルは、リモート NDMP バックアップにも適用されますが、ローカル NDMP バックアップまたは NDMP の 3-Way バックアップには適用されません。

p.123 の「共有メモリと NetBackup for NDMP に関する注意事項」を参照してください。

■ NUMBER_DATA_BUFFERS_RESTORE ファイルは、ディスクからではなくテープからのリストアでのみ使われます。 NUMBER_DATA_BUFFERS_RESTORE ファイルがある場合は、そのコンテンツによって、テープからの多重化リストア用の共有データバッファの数が

決定されます。

■ 新しいバッファの値を使うために、NetBackup デーモンを再起動する必要はありません。新しいジョブが開始するたびに、bptm が設定ファイルを調べて、動作を調整します。

■ NUMBER_DATA_BUFFERS_FT を設定するための推奨事項については、次のトピックを参照してください。

p.125 の「SAN クライアントと FT メディアサーバーのデータバッファの推奨数」を参照してください。


共有データバッファのサイズを変更する方法

メディアサーバーに次のファイルを作成することで、共有データバッファのサイズを変更

できます。ファイルには、バイト単位で共有データバッファの整数のサイズを入力します。整数は、1024 の倍数でなければなりません（32 KB の倍数を推奨します）。

p.121 の「データバッファのサイズのファイルに関する注意事項」を参照してください。

■ UNIX の場合テープの場合:

/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS

SIZE_DATA_BUFFERS によって指定する値は、次のSIZE_DATA_BUFFERS_xxxx ファイルのいずれも存在しなければすべてのバックアップ形式の共有メモリバッファのサイズを決定します。

テープ（NDMP ストレージユニット）の場合:

/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS_NDMP


/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS_DISK

SIZE_DATA_BUFFERS_DISK ファイルは、ディスクバックアップを作成する NDMP にも影響を与えます。


/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS_MULTCOPY

FT メディアサーバーの場合:

/usr/openv/netbackup/db/config/SIZE_DATA_BUFFERS_FT

■ Windows の場合テープの場合:

install_path¥NetBackup¥db¥config¥SIZE_DATA_BUFFERS

SIZE_DATA_BUFFERS によって指定する値は、次のSIZE_DATA_BUFFERS_xxxx ファイルのいずれも存在しなければすべてのバックアップ形式の共有メモリバッファのサイズを決定します。

テープ（NDMP ストレージユニット）の場合:

install_path¥NetBackup¥db¥config¥SIZE_DATA_BUFFERS_NDMP


install_path¥NetBackup¥db¥config¥SIZE_DATA_BUFFERS_DISK


SIZE_DATA_BUFFERS_DISK ファイルは、ディスクバックアップを作成する NDMP にも影響を与えます。


install_path¥NetBackup¥db¥config¥SIZE_DATA_BUFFERS_MULTCOPY

FT メディアサーバーの場合:注意: FT メディアサーバーは Windows でまだサポートされていません。


データバッファのサイズのファイルに関する注意事項


■ 各種のデータバッファのサイズのファイルは、各共有データバッファのサイズをバイト

単位で指定する単一の整数を含んでいます。整数は、1024 の倍数でなければなりません (32 KB の倍数を推奨します)。p.122 の「共有データバッファのサイズの値」を参照してください。

■ SIZE_DATA_BUFFERS ファイルがある場合は、そのコンテンツを使用して、多重化されたバックアップと多重化されていないバックアップに使う共有データバッファのサイ

ズが決定されます。

■ 他の SIZE_DATA_BUFFERS ファイル (SIZE_DATA_BUFFERS_DISK、SIZE_DATA_BUFFERS_MULTCOPY、SIZE_DATA_BUFFERS_FT) は特定のバックアップ形式のバッファ設定を可能にします。これらのファイルで指定する値は NetBackupのデフォルトのサイズか SIZE_DATA_BUFFERS で指定する値を上書きします。たとえば、SIZE_DATA_BUFFERS_DISK では、テープではなくディスクにバックアップするときに別の値が考慮されます。SIZE_DATA_BUFFERS が存在し、SIZE_DATA_BUFFERS_DISK が存在しない場合は、SIZE_DATA_BUFFERS がすべてのバックアップに適用されます。両方のファイルが存在する場合は、

SIZE_DATA_BUFFERS がテープバックアップに適用され、SIZE_DATA_BUFFERS_DISKがディスクバックアップに適用されます。SIZE_DATA_BUFFERS_DISK のみが存在する場合は、ディスクバックアップのみに適用されます。

■ SIZE_DATA_BUFFERS_DISK ファイルは、ディスクバックアップを作成する NDMP にも影響を与えます。

■ 共有データバッファのサイズを変更した場合は、バックアップとリストアのテストを実行

します。NetBackup メディアサーバーが同じオペレーティングシステムで実行されていない場合は、リストア操作に関係する可能性のある各メディアサーバーでリストアを

テストします。UNIX メディアサーバーが 256 KB の共有データバッファでテープにバックアップを書き込めば、Windows メディアサーバーはそのテープを読み込めないことがあります。


警告: データ損失を回避するために、バックアップ操作同様、リストアをテストしてください。


共有データバッファのサイズの値

表 7-5 に、各種の SIZE_DATA_BUFFERS ファイルの適切な値をリストします。整数は 1つのテープまたはディスクバッファのサイズをバイト単位で表します。たとえば、64 KB の共有データバッファサイズを使う場合、ファイルに整数 65536 が含まれます。

これらの値は、1024 の倍数です。 1024 の倍数ではない値を入力すると、1024 の最も近い倍数まで切り捨てられます。たとえば、262656 の値を入力すると、262144 の値が使われます。

パラメータ値を使うために、NetBackup デーモンを再起動する必要はありません。新しいジョブが開始するたびに、bptm が設定ファイルを調べて、動作を調整します。

バッファパラメータのサイズを変更する前と後で、bptm デバッグログを調べて、バッファの使用状況を分析します。 bptm ログはテープとディスク両方のバックアップに適用されることに注意してください。

表 7-5 SIZE_DATA_BUFFERS_xxxx ファイルのバイトの値

バイト単位の SIZE_DATA_BUFFER の値データバッファあたりの KB 数

3276832

6553664

9830496

131072128

163840160

196608192

229376224

262144256

重要: データバッファサイズはテープI/Oのサイズと等しいサイズです。したがって、SIZE_DATA_BUFFERS の値はテープドライブまたはオペレーティングシステムでサポートされる最大のテープ I/O のサイズを超過しないようにしてください。この値は通常 256KB または 128 KB です。最大値について詳しくはオペレーティングシステムとハードウェアのマニュアルを調べてください。合計システムリソースとネットワーク全体を考慮に入れます。 LAN ネットワークの MTU （Maximum Transmission Unitの略で最大伝送単位の


意味）も変更することが必要な場合があります。 NetBackup には NET_BUFFER_SZ とSIZE_DATA_BUFFERS の値をバイト単位で指定します。 32K の場合は、32768 (32 x1024) を使います。

メモ: 一部の Windows テープデバイスは、65536 （64 KB）を超えるブロックサイズで書き込むことができません。一部の Windows メディアサーバーは、SIZE_DATA_BUFFERSが 65536 に設定された UNIX メディアサーバー上のバックアップを読み込むことができません。 Windows メディアサーバーは、65536 を超える SIZE_DATA_BUFFERS で書き込まれたイメージをメディアからインポートまたはまたはリストアできません。

メモ: リストア用の共有データバッファのサイズは、バックアップが書き込まれたときに使っていた共有データバッファのサイズによって決まります。リストアは SIZE_DATA_BUFFERSファイルを使いません。

共有メモリと NetBackup for NDMP に関する注意事項次の表では、NetBackup for NDMP で使う共有メモリについて説明します。

表 7-6 に、NDMP のバックアップの種類による NUMBER_DATA_BUFFERS の影響を示します。

表 7-6 NetBackup for NDMP とデータバッファの数

共有メモリの使用NDMP バックアップのタイプ

NetBackup は共有メモリを使いません (データバッファなし)。NUMBER_DATA_BUFFERS の影響はありません。

ローカル NDMP バックアップまたは 3-Way バックアップ

NetBackup は共有メモリを使います。NUMBER_DATA_BUFFERSを使ってメモリバッファの数を変更できます。

リモート NDMP バックアップ

表 7-7 に、NDMP のバックアップの種類による SIZE_DATA_BUFFERS_NDMP の影響を示します。

表 7-7 NetBackup for NDMP とデータバッファのサイズ


NetBackup は共有メモリを使いません (データバッファなし)。SIZE_DATA_BUFFERS_NDMP を使って、テープに書き込まれるレコードのサイズを変更できます。

NDMP ディスクバックアップのレコードサイズを変更するにはSIZE_DATA_BUFFERS_DISK を使います。

ローカル NDMP バックアップまたは 3-Way バックアップ



NetBackup は共有メモリを使います。SIZE_DATA_BUFFERS_NDMP を使って、メモリバッファのサイズとテープに書き込まれるレコードのサイズを変更できます。

NDMP ディスクバックアップのバッファサイズとレコードサイズを変更するには SIZE_DATA_BUFFERS_DISK を使います。

リモート NDMP バックアップ

次に、NDMP の 3-Way バックアップとリモート NDMP バックアップについて簡潔に説明します。

■ NDMP の 3-Way バックアップでは、バックアップは別の NAS のファイラ上の NDMPストレージユニットに書き込まれます。

■ リモート NDMP バックアップでは、バックアップは NetBackup メディアのマネージャタイプのストレージデバイスに書き込まれます。

これらのバックアップタイプに関する詳細情報が利用可能です。

『NetBackup for NDMP 管理者ガイド』を参照してください。

推奨される共有メモリ設定

テープへのバックアップでは SIZE_DATA_BUFFERS の設定は、通常は 256 KB に増やされ、NUMBER_DATA_BUFFERS は 16 に増やされます。16 x 256 KB のデータバッファを使うように NetBackup を設定するには、SIZE_DATA_BUFFERS に 262144 (256 x 1024)を、NUMBER_DATA_BUFFERS に 16 を指定します。

データバッファのサイズと数を増やすと、限られたシステムリソースである共有メモリの使

用量が増えます。各テープドライブに使われる共有メモリの合計量は次のとおりです。

(number_data_buffers * size_data_buffers) * number_tape_drives *max_multiplexing_setting

それぞれ多重化の設定が 4 で 256 KB のバッファが 16 個ある 2 つのテープドライブでは、共有メモリの合計使用量は次のとおりです。

(16 * 262144) * 2 * 4 = 32768 KB (32 MB)

多量のメモリを割り当てる場合は、NetBackup に対して十分な量の共有メモリを提供できるように、カーネルに追加の調整が必要なことがあります。

p.179 の「Solaris 10 のカーネルパラメータについて」を参照してください。

メモ: AIX は動的メモリ割り当てを使うので、AIX メディアサーバーでは共有メモリを調整する必要はありません。


変更するたびにパフォーマンスの変化を監視しながら、注意深く変更してください。たと

えば、テープバッファサイズを増やすと、一部のバックアップの実行が遅くなることがあり

ます。また、リストアで問題が起きるケースも発生しています。変更後に、確認のテストの

一環として必ずリストアを含めてください。

SAN クライアントと FT メディアサーバーのデータバッファの推奨数SAN クライアントのファイバートランスポートの場合、データバッファの有効な合計数は多重化されていないバックアップに指定されるバッファ数のおよそ 2 倍です。理由は、指定された数のバッファが SAN クライアントと FT メディアサーバーにあるためです。

メモ: 通常は、SAN クライアントのファイバートランスポートのデフォルト (16) より大幅に多い数にメモリバッファを増やしても、パフォーマンスは改善されません。そのように増やす

と、通常はクライアント側またはサーバー側のバッファの大半が空になります。

共有メモリに対して行われた変更のテスト

変更後に、次のテストが正常に完了することを検証することが極めて重要です。

共有メモリに対して行われた変更をテストする方法

1 バックアップを実行します。

2 バックアップからデータをリストアします。

3 SIZE_DATA_BUFFERS_xxxx と NUMBER_DATA_BUFFERS_xxxx ファイルへの変更の前に作成されたバックアップからデータをリストアします。

4 データバッファのサイズまたは数を変更する前後に、bptm デバッグログファイルのバッファ使用状況情報を検査します。

ログ内の値がバッファ設定と一致する必要があります。関連する bptm ログエントリは次のようになります。

12:02:55 [28551] <2> io_init: using 65536 data buffer size

12:02:55 [28551] <2> io_init: CINDEX 0, sched bytes for

monitoring = 200

12:02:55 [28551] <2> io_init: using 8 data buffers

または

15:26:01 [21544] <2> mpx_setup_restore_shm: using 12 data

buffers, buffer size is 65536

これらの設定を変更するときは、システムリソースの合計とネットワーク全体を考慮に

入れます。ローカルエリアネットワーク (LAN) の最大伝送単位 (MTU) も変更が必要な場合があります。


NetBackup の待機カウンタと遅延カウンタについてバックアップまたはリストア操作時に、NetBackup メディアサーバーは、クライアントディスクまたはネットワークとの対話プロセスからストレージデバイス（テープまたはディスク）との

通信プロセスを分離するために、1 組の共有データバッファを使います。待機カウンタと遅延カウンタを使って、NetBackup メディアサーバーが待機する頻度の高いプロセス（データ生産側またはデータ消費側）を判断できます。

データ生産側プロセスとデータ消費側プロセス間のバランスをうまくとることは、NetBackupのデータ転送パスの NetBackup サーバーコンポーネントからのパフォーマンスを最適化するための重要な要因です。

図 7-1 は生産側と消費側の関係を示します。

図 7-1 リモートクライアントバックアップ時の生産側と消費側の関係

NetBackupメディアサーバー

bptm(子プロセス)

bptm(親プロセス)

共有バッファ

生産側消費側

ネットワーク

NetBackup クライアント

テープまたはディスク

NetBackup での親と子の遅延値の変更処理の親と子の遅延値を修正できます。


親と子の遅延値を変更する方法


UNIX の場合

/usr/openv/netbackup/db/config/PARENT_DELAY

/usr/openv/netbackup/db/config/CHILD_DELAY

Windows の場合

install_path¥NetBackup¥db¥config¥PARENT_DELAY

install_path¥NetBackup¥db¥config¥CHILD_DELAY

これらのファイルには、ファイルの名前に相当する、遅延に使う値をミリ秒単位で指

定した単一の整数が含まれます。

2 たとえば、50 ミリ秒の親の遅延の場合は PARENT_DELAY ファイルに 50 を入力します。

p.126 の「NetBackup の待機カウンタと遅延カウンタについて」を参照してください。

NetBackup クライアントとメディアサーバー間の通信についてNetBackup クライアントとメディアサーバー間の通信プロセスは次によって変わります。

■ 操作がバックアップであるかリストアであるか

■ 操作にローカルクライアントとリモートクライアントのどちらが関係するか


表 7-8 バックアップとリストア時の NetBackup 通信

バックアップとリストア時の通信プロセスクライアントの形式(ローカルまたはリモート)

NetBackup メディアサーバーと NetBackup クライアントが同じシステムに属するときには、NetBackupクライアントはローカルクライアントと呼ばれます。

■ ローカルクライアントのバックアップ

ローカルクライアントでは、bpbkar (UNIX) または bpbkar32 (Windows) プロセスが、バックアップ時にディスクからデータを読み込み、共有バッファに配置します。bptm プロセスは共有バッファからデータを読み込み、テープまたはディスクに書き込みます。

■ ローカルクライアントのリストア

ローカルクライアントのリストア時に、bptm プロセスは、テープまたはディスクからデータを読み込み、共有バッファに配置します。tar (UNIX) または tar32 (Windows) プロセスは、共有バッファからデータを読み込み、ディスクに書き込みます。

メモ: バックアップまたはリストアするデータによっては、bpbkar と bptm の代わりに、他のプロセスを使えることがあります。

p.128 の「NetBackup のクライアント/サーバー通信で使われるプロセス」を参照してください。

ローカルクライアント

NetBackup メディアサーバーと NetBackup クライアントが 2 つの異なるシステムに属するときには、NetBackup クライアントはリモートクライアントと呼ばれます。

■ リモートクライアントのバックアップ

リモートクライアント上の bpbkar (UNIX) または bpbkar32 (Windows) プロセスは、ディスクからデータを読み込み、ネットワークに書き込みます。続いて、メディアサーバー上の子 bptm プロセスが、ネットワークからデータを受信し、共有バッファに配置します。メディアサーバー上の親

bptm プロセスは、共有バッファからデータを読み込み、テープまたはディスクに書き込みます。■ リモートクライアントのリストア

リモートクライアントのリストア時に、親 bptm プロセスは、テープまたはディスクからデータを読み込み、共有バッファに配置します。子 bptm プロセスは共有バッファからデータを読み込み、ネットワークに書き込みます。リモートクライアント上の tar (UNIX) または tar32 (Windows) プロセスは、ネットワークからデータを受信し、ディスクに書き込みます。

メモ: バックアップまたはリストアするデータによっては、bpbkar と bptm の代わりに、他のプロセスを使えることがあります。


リモートクライアント

NetBackup のクライアント/サーバー通信で使われるプロセスこの項では、NetBackup のクライアント/サーバー通信に関する詳細を記録するログについて説明します。関連トピックに記述されているように、これらのログを使って待機カウンタと遅延カウンタによって NetBackup のクライアント/サーバー通信を調整することができます。


表 7-9 NetBackup のクライアント/サーバー通信で使われるログ

バックアップ形式ログディレクトリ

Standard、MS-Windows、FlashBackup、FlashBackup-Windows、Enterprise Vault、Lotus Notes、Domino、SharePoint、DB2 スナップショットバックアップ、Oracle RMAN PROXY/スナップショットバックアップ、RMAN を使わない Oracle Block Incremental バックアップ、MS-SQL-Server スナップショットバックアップ

UNIX のログ:


Windows のログ:

install_path¥Veritas¥NetBackup¥logs¥bpbkar

DB2 のストリームベースのバックアップ。

bpdb2 ディレクトリは DB2 ユーザー（root ユーザーに限らない）によって書き込み可能である必要があります。

UNIX のログ:

/usr/openv/netbackup/logs/bpdb2

Windows のログ:

install_path¥Veritas¥NetBackup¥logs¥bpdb2

Oracle RMAN のストリームベースのバックアップ。

dbclient ディレクトリは Oracle ユーザー（root ユーザーに限らない）によって書き込み可能である必要があります。

UNIX のログ:

/usr/openv/netbackup/logs/dbclient

Windows のログ:

install_path¥Veritas¥NetBackup¥logs¥dbclient

MS-SQL-Server のストリームベースのバックアップ（UNIX またはLinux ではサポートされません）。

Windows のログ:

install_path¥Veritas¥NetBackup¥logs¥dbclient

DataStore/XBSA のストリームベースのバックアップ。

exten_client ディレクトリはバックアップ操作かリストア操作を実行するアプリケーションによって書き込み可能である必要があります。

UNIX のログ:

/usr/openv/netbackup/logs/exten_client

Windows のログ:

install_path¥Veritas¥NetBackup¥logs¥exten_client

Informix のストリームベースのバックアップ。

infxbsa ディレクトリは Informix ユーザーによって書き込み可能である必要があります（Windows ではサポートされていません）。

UNIX のログ:

/usr/openv/netbackup/logs/infxbsa

Sybase のストリームベースのバックアップ。

sybackup ディレクトリはバックアップ操作かリストア操作を実行するアプリケーションによって書き込み可能である必要があります。

UNIX のログ:

/usr/openv/netbackup/logs/sybackup

Windows のログ:

install_path¥Veritas¥NetBackup¥logs¥sybackup


バックアップとリストア時のプロセスの役割

プロセスは、共有データバッファを使おうとするときに、まず次のバッファの準備ができて

いることを検証します。データ生産側には空のバッファが必要ですが、データ消費側にはフルバッファが必要です。

次の表では、NetBackup プロセスをログディレクトリの名前で表しています。

表 7-10 データ生産側とデータ消費側の役割

データ消費側

（ログディレクトリの名前）

データ生産側

（ログディレクトリの名前）

操作

bptmbpbkar、bpdb2、dbclient、exten_client、infxbsa、sybackup

ローカルバックアップ

bptm（親）bptm（子）リモートバックアップ

tar（UNIX）または tar32（Windows）、bpdb2、dbclient、exten_client、infxbsa、sybackup

bptmローカルリストア

bptm（子）bptm（親）リモートリストア

データ消費側は、フルバッファがなければ、フルバッファを待機する必要があったことを

示すために待機カウンタと遅延カウンタを 1 つ増やします。遅延の後に、データ消費側はフルバッファを再び調べます。フルバッファがまだ利用可能でない場合、データ消費側は再び遅延が必要だったことを示すために、遅延カウンタを 1 つ増やします。データ消費側は、フルバッファが利用可能になるまで、遅延とフルバッファチェックのステップを

繰り返します。

このシーケンスは次のアルゴリズムに要約されます。

while (Buffer_IS_Not_Full) {

++Wait_Counter;

while (Buffer_Is_Not_Full) {

++Delay_Counter;

delay (DELAY_DURATION);

}

}

データ生産側は、空きバッファがなければ、空きバッファを待機する必要があったことを

示すために待機カウンタと遅延カウンタを 1 つ増やします。遅延の後に、データ生産側は空きバッファを再び調べます。空きバッファがまだ利用可能でない場合、データ生産側は再び遅延が必要だったことを示すために、遅延カウンタを 1 つ増やします。データ


生産側は、空きバッファが利用可能になるまで、遅延と空きバッファチェックのステップを

繰り返します。

データ生産側のアルゴリズムの構造も同様です。

while (Buffer_Is_Not_Empty) {

++Wait_Counter;

while (Buffer_Is_Not_Empty) {

++Delay_Counter;

delay (DELAY_DURATION);

}

}

待機カウンタ値と遅延カウンタ値の分析は、生産側と消費側のどちらのプロセスが頻繁に

待機する必要があったか、また、待機した時間の長さを示します。

待機カウンタと遅延カウンタの関係は次のとおり 4 つあります。

表 7-11 待機カウンタと遅延カウンタの関係

説明関係

データ生産側が、データ消費側よりも大幅に大きい待機カウンタ値と遅

延カウンタ値を持ちます。データ消費側は、データ生産側をビジー状態に保つのに十分な速度で受信データを処理できません。

データ消費側のパフォーマンスを改善する手段を調査します。バックアップの場合は、データバッファサイズが、使われているテープまたは

ディスクドライブに適しているかどうかを調べます。この場合に、それでもデータ消費側が大幅に大きい値を持つ場合は、共有データバッファ

の数を増やして、パフォーマンスの改善を試みます。

データ生産側 >> データ消費側

データ生産側とデータ消費側が非常によく似た待機カウンタ値と遅延

カウンタ値を持ちますが、それらは比較的大きい値です。この状況は、データ生産側とデータ消費側が同じ共有データバッファの使用を定期

的に試行することを示している可能性があります。共有データバッファの数を増やして、パフォーマンスの改善を試みてください。

p.132 の「待機カウンタ値と遅延カウンタ値の確認」を参照してください。

データ生産側 = データ消費側（大きい値）

データ生産側とデータ消費側が非常によく似た待機カウンタ値と遅延

カウンタ値を持ちますが、それらは比較的小さい値です。この状況はデータ生産側とデータ消費側間のバランスがよいことを示します。

NetBackup のデータ転送パスの NetBackup サーバーコンポーネントから優れたパフォーマンスがもたらされます。

データ生産側 = データ消費側（小さい値）


説明関係

データ生産側が、データ消費側よりも大幅に小さい待機カウンタ値と遅

延カウンタ値を持ちます。データ生産側は、データ消費側をビジー状態に保つのに十分な速度でデータを送信できません。

データ生産側のパフォーマンスを改善する方法を調査します。リストア操作の場合は、データバッファサイズが、テープまたはディスクドライブ

に適しているかどうかを調べます。この場合に、それでもデータ生産側が比較的大きい値を持つ場合は、共有データバッファの数を増やして、

パフォーマンスの改善を試みます。

p.117 の「共有データバッファの数を変更する方法」を参照してください。

データ生産側 << データ消費側

一番の問題は、値の関係とサイズです。大きい値と小さい値の判断に関する情報は、以下のページにあります。これらの値の関係は、分析の開始点にすぎません。 NetBackupのデータ転送パス内部のボトルネックの原因を明確に識別するには、追加の調査作業が

必要な場合があります。

待機カウンタ値と遅延カウンタ値の確認

待機カウンタ値と遅延カウンタ値は、NetBackup メディアサーバーのデバッグログファイルを作成すると表示されます。

メモ: デバッグログファイルによってオーバーヘッドが追加され、NetBackup の全体的なパフォーマンスにわずかに影響が及びます。この影響は、高い詳細レベル設定ではより

顕著になります。通常、本番システムではデバッグログを有効にして実行する必要はあり

ません。


ローカルクライアントバックアップの待機カウンタ値と遅延カウンタ値を確認する方法

1 メディアサーバーに適切なログディレクトリを作成することで、デバッグログをアクティ

ブにします。

UNIX の場合

例 :


/usr/openv/netbackup/logs/bptm

Windows の場合

install_path¥NetBackup¥logs¥bpbkar

install_path¥NetBackup¥logs¥bptm

次の項では、データベース拡張機能によって bpbkar の代わりに使えるプロセスのログディレクトリを示しています。



3 データ生産側プロセスのログを参照してください。

行は次のようになり、バックアップの完了時刻に対応するタイムスタンプが示されま

す。

bpbkar ログからの例:

... waited 224 times for empty buffer, delayed 254 times

この例では、待機カウンタ値は 224 で、遅延カウンタ値は 254 です。

4 データ消費側プロセスのログを参照します。

行は次のようになり、バックアップの完了時刻に対応するタイムスタンプが示されま

す。

... waited for full buffer 1 times, delayed 22 times



リモートクライアントバックアップの待機カウンタ値と遅延カウンタ値を確認する方法

1 メディアサーバーに次のディレクトリを作成することで、デバッグログをアクティブにし

ます。

UNIX の場合


Windows の場合



3 次の場所にある bptm プロセスのログを参照します。

UNIX の場合


Windows の場合

install_path¥NetBackup¥Logs¥bptm

データ生産側 (bptm の子) に関連付けられている遅延は、次のように表示されます。

... waited for empty buffer 22 times, delayed 151 times, ...


データ消費側 (bptm の親) に関連付けられている遅延は、次のように表示されます。




ローカルクライアントリストアの待機カウンタ値と遅延カウンタ値を確認する方法

1 NetBackup メディアサーバーに次の 2 つのディレクトリを作成することで、ログをアクティブにします。

UNIX の場合


/usr/openv/netbackup/logs/tar

Windows の場合


install_path¥NetBackup¥logs¥tar

次の項では、データベース拡張機能によって tar の代わりに使えるプロセスのログディレクトリを示しています。


2 リストアを実行します。

3 tar ログディレクトリにあるデータ消費側 (tar か tar32) のログを参照します。

行は次のようになり、リストアの完了時刻に対応するタイムスタンプが示されます。



4 bptm ログディレクトリにあるデータ生産側 (bptm) のログを参照します。

行は次のようになり、リストアの完了時刻に対応するタイムスタンプが示されます。

... waited for empty buffer 1 times, delayed 68 times



リモートクライアントリストアの待機カウンタ値と遅延カウンタ値を確認する方法

1 メディアサーバーに次のディレクトリを作成することで、デバッグログをアクティブにし

ます。

UNIX の場合


Windows の場合


2 リストアを実行します。

3 bptm ログディレクトリで bptm のログを参照します。

データ消費側 (bptm の子) に関連付けられている遅延は、次のように表示されます。



データ生産側 (bptm の親) に関連付けられている遅延は、次のように表示されます。

... waited for empty buffer 95 times, delayed 513 times


ログファイルの作成に関する注意事項

複数のテストを実行するときには、現在のログファイルの名前を変更できます。ファイルの

名前を変更すると NetBackup が新しいログファイルを作成するため、間違った値のセットが誤って読み込まれることを防止できます。

デバッグログファイルを削除しても、NetBackup はデバッグログの生成を停止しません。ディレクトリ全体を削除する必要があります。たとえば、bptm によるログの記録を停止するには、bptm サブディレクトリを削除する必要があります。NetBackup は、ディレクトリが検出されると、指定された詳細設定でデバッグログを自動的に生成します。

バックアップやリストアが無関係な操作を含む多重化 (MPX) グループの一部になっている場合、bptm ログファイルの処理には注意が必要です。このような場合、bptm 親プロセスは起動時に一度ログファイルを開き、オペレーティングシステムからファイル記述子を

受信します。親プロセスと子プロセスは、MPX グループに追加されている現在 (および以降) のジョブがすべて完了するまで、ファイル記述子への書き込みを行います。MPXグループがまだアクティブであるときにログファイルの名前変更や削除を行うと、予期しな

い結果が生じることがあります。

ログファイルの名前が変更されると、ファイル記述子は名前が変更されたファイルに対し

て開いたままになります。次のテストジョブが同じ MPX グループに追加されると、名前が


変更されたログファイルに新しいログエントリが記録されます。ログファイルが削除された

場合、ファイルはディレクトリに存在しなくなりますが、ファイル記述子は開いたままになり

ます。次のテストジョブが同じ MPX グループに追加されると、開いているファイルに新しいログエントリが書き込まれます。ユーザーは開いているファイルにアクセスすることはで

きません。

この動作は複数の日にわたり実行される MPX グループにも該当します。2 日前にアクティブになった MPX グループにテストジョブが追加されると、ログエントリは 2 日前に作成されたログに記録されます。bptm ログディレクトリが 2 日前に存在していなかった場合、バックアップを処理する bptm プロセスはログエントリを生成しません。

bptm ログディレクトリが 2 日前に存在していなかった場合は、次のどちらかを実行します。

■ MPX グループの完了を待ってからテストジョブを開始します。

■ バックアップ用のストレージユニット、ボリュームプール、または保持期間のいずれか

を変更します。まだ使われていないドライブとメディアにジョブが割り当てられ、新しい

bptm 親プロセスが開始されます。

bptm ログで報告されるチューニングパラメータについてbptm のデバッグログファイルを使って、次のチューニングパラメータが希望値に正常に設定されていることを検証できます。これらのパラメータ、待機カウンタ値、遅延カウンタ

値を使って、問題を分析できます。

これらの追加値には次が含まれています。

各共有データバッファのサイズは、次のような行で確認できます。

... io_init:using 65536 data buffer size

データバッファのサイズ

共有データバッファの数は、次のような行で確認できます。

... io_init:using 16 data buffers

データバッファの数

親と子の遅延の期間に使われている値は、次のような行で確認

できます。

... io_init:child delay = 10, parent delay = 15 (milliseconds)

親/子遅延値


メディアサーバーのネットワークバッファサイズの値はデバッグロ

グファイルの次のような行に表示されます。最初の行は

NET_BUFFER_SZ touch ファイルが存在することを示します。また、bptm がネットワークバッファ領域の設定をオペレーティングシステムのデフォルト値から変更しようとしたことを示します。(この最初の行は存在しない場合があります。)2 つ目の行は常に存在し、オペレーティングシステムが現在のバックアップやリストア

に対して使っている値を示します。この 2 つの値が異なる場合、オペレーティングシステムはデフォルト値の変更を許可しなかっ

たことになります。NET_BUFFER_SZ ファイルを削除する必要があります。

bptm の子プロセスは、リモートバックアップの間に、受信ネットワークバッファを読み込みます。

...setting receive network buffer to 263168 bytes…receive network buffer is 49640 bytes

bptm の子プロセスは、リモートリストアの間に、ネットワークバッファに書き込みます。

...setting send network buffer to 131072 bytes…send network buffer is 131072 bytes

p.109 の「NetBackup メディアサーバーのネットワークバッファサイズの設定」を参照してください。

NetBackup メディアサーバーのネットワークバッファサイズ

待機カウンタ値と遅延カウンタ値の使用例

5 MB/秒を基準にする 30 分のデータ転送があるローカルバックアップを分析すると仮定します。バックアップでは、合計 9,000 MB のデータが転送されます。ローカルバックアップが関係するため、bptm はデータ消費側になります。データプロシージャはバックアップするデータの形式によって決まります。


p.130 の「バックアップとリストア時のプロセスの役割」を参照してください。

適切なデータプロシージャプロセスと消費側プロセス (bptm) の待機値と遅延値を、次のように確認します。

p.132 の「待機カウンタ値と遅延カウンタ値の確認」を参照してください。

この例では、次の値を使います。


表 7-12 待機と遅延の例

遅延待機プロセス

58,03329,364bpbkar (UNIX)

bpbkar32 (Windows)

10595bptm

これらの値は、bpbkar (または bpbkar32) が、共有バッファから十分な速さでデータを移動できない bptm プロセスによって待機を強制されていることを明らかにします。

次に、親または子の該当する方の遅延値に遅延カウンタ値を乗算することで、遅延によ

る時間損失を判断できます。

この例では、bpbkar (または bpbkar32) プロセスは子遅延値を使い、bptm プロセスは親遅延値を使います。(これらの値のデフォルトは、子の遅延については 10 ミリ秒、親の遅延については 15 ミリ秒です。)

これらの遅延による時間損失の量を判断するには、次の等式を使用できます。

表 7-13 遅延の例

遅延プロセス

58,033 遅延 x 0.010 秒 = 580.33 秒 = 9 分 40 秒bpbkar (UNIX)

bpbkar32 (Windows)

105 x 0.015 秒 = 1.6 秒bptm

bpbkar (または bpbkar32) の遅延が大幅かどうか判断するためにこれらの式を使用します。この例では、遅延が取り除かれた場合の転送時間は次のようになります。

30 分の元の転送時間 - 9 分 40 秒 = 20 分 20 秒 (1,220 秒)

1,220 秒の転送時間の場合、スループット値は次のようになります。

9,000 MB / 1,220 秒 = 7.38 MB/秒

5 MB/秒から 7.38 MB/秒というのは大幅な増加です。この増加によって、テープやディスクパフォーマンスをどのように改善できるか調査する必要があります。

遅延の数は、移動されたデータ量のコンテキストで解釈する必要があります。移動される

データの量が増加すると、カウンタ値の重要度のしきい値も増加します。

再び、転送される合計 9,000 MB のデータの場合に、64 KB バッファを仮定します。

次の等式を使って、転送されるバッファの合計数を判断できます。

9,000 x 1,024 = 9,216,000 KBKB 数


9,216,000 / 64 = 144,000バッファ数

待機カウンタ値は、バッファの合計数の割合として表現できます。

29,364 / 144,000 = 20.39%bpbkar (UNIX) またはbpbkar32 (Windows)

95 / 144,000 = 0.07%bptm

bpbkar (または bpbkar32) で空き共有データバッファを必要としたケースの 20% では、bptm はまだ共有データバッファを空けていません。このサイズの値は深刻な問題を示します。データ消費側 (bptm) がなぜ遅れるかに関して調査する必要があります。

それに対して、bptm で生じた遅延は、転送されるデータ量に対してわずかです。

遅延カウンタと待機カウンタを比率として表示することもできます。

= 58,033 遅延 / 29,364 待機

= 1.98

bpbkar (UNIX)

bpbkar32 (Windows)

この例では、bpbkar (または bpbkar32) は、発生した待機条件ごとに平均 2 回遅延せざるを得ませんでした。この比率が大きければ、正しい状態の共有データバッファを余り

に頻繁に調べることを避けるために、親か子の遅延を増やします。

p.126 の「NetBackup での親と子の遅延値の変更」を参照してください。

逆にこの比率が 1 に近ければ、該当する遅延値を減らして調べる頻度を増やします。これによってデータスループットのパフォーマンスが向上することがあります。親と子の遅延

値は、ほとんどの NetBackup インストール環境で、まれにしか変更されないことに留意してください。

前に示した情報は、検討が必要なほど待機カウンタと遅延カウンタの値が大きいかどうか

を判断する方法を説明しています。

メモ: 待機カウンタと遅延カウンタは、データ転送のサイズに関係します。1 MB のデータしか移動されていないときには、1,000 という値は大きすぎる可能性があります。GB 単位のデータが移動されているときには、同じ値が適切に調整されたシステムを実現すること

もあります。最終的な分析で、これらのカウンタがパフォーマンスにどのように影響するか

判断する必要があります。

待機カウンタ値と遅延カウンタ値で明らかになった問題

次を調べることによって問題を解決できます。

■ bptm 読み込み待機


bptm デバッグログに次のようなメッセージが含まれます。

...waited for full buffer 1681 times, delayed 12296 times

最初の数値は、bptm がフルバッファを待機した回数です。つまり、bptm 書き込み操作がソースからのデータを待機した回数です。待機カウンタがパフォーマンス上の問

題を示せば、バッファ数の変更は役に立ちません。

p.132 の「待機カウンタ値と遅延カウンタ値の確認」を参照してください。多重化は役立つ場合があります。

■ bptm 書き込み待機bptm デバッグログに次のようなメッセージが含まれます。

...waited for empty buffer 1883 times, delayed 14645 times

最初の数値は、bptm が空きバッファを待機した回数です。これは、テープまたはディスクにデータを書き込める速度よりも速いソースからのデータが bptm で検出された回数です。待機カウンタがパフォーマンス上の問題を示したら、多重化因数を減らし

ます。

p.132 の「待機カウンタ値と遅延カウンタ値の確認」を参照してください。より多くのバッファは役立つ場合があります。

■ bptm 遅延bptm デバッグログに次のようなメッセージが含まれます。

...waited for empty buffer 1883 times, delayed 14645 times

2 つ目の数値は、bptm が利用可能なバッファを待機した回数です。遅延カウンタがパフォーマンス上の問題を示せば、調査します。各遅延間隔は 30 マイクロ秒です。

複数のコピーがバックアップパフォーマンスに与える影響の推定［スケジュールの属性（Schedule attributes）］の［コピーを複数作成する（Multiple copies）］オプションは、bptm バッファが受信したデータのストリームを 1 つ取り出して、そのデータを 2 つ以上のコピー先に順次書き込みます（NetBackupの前のリリースでは、このオプションはインラインコピー、インラインテープコピー、ITC と呼ばれていました）。複数のデバイスに書き込む時間は、1 つのデバイスに書き込むために必要な時間にデバイス数を乗算した値と同じです。したがって、全体的な書き込み速度は、1 つのデバイスの書き込み速度をデバイス数で除算した値です。

バックアップデバイスの書き込み速度は、通常はソースデータの読み込み速度よりも高速

です。したがって、複数のコピーに切り替えても、必ずしもバックアップ速度が低下するとはかぎりません。重要な数値は、バックアップデバイスの書き込み速度です。これは、デバイスのネーティブ速度をデバイスハードウェア圧縮の圧縮率で乗算した値です。テープバックアップでは、この圧縮率は、1 つのテープに保持されるデータ量（NetBackup に


よって報告されます）を参照することで概算できます。そのデータ量とカートリッジの非圧縮容量を比較します。

たとえば、

LTO gen 3 カートリッジに 400 GB の非圧縮容量があります。 LTO gen 3 ドライブのネーティブ書き込み容量は 80 MB/秒です。フルカートリッジに 600 GB が含まれている場合、圧縮率は 600/400 または 1.5:1 です。したがって、ドライブの書き込み速度は、1.5* 80 = 120 MB/秒です。

2 つの LTO gen 3 ドライブへの複数のコピーが有効な場合は、全体的な書き込み速度は 120/2 = 60 MB/秒です。

バックアップが通常 45 MB/秒で実行される場合（ソースデータの読み込み速度が 45MB/秒の場合）は、複数のコピーはバックアップ速度には影響しません。バックアップが通常 90 MB/秒で実行される場合は、複数のコピーを使うとバックアップの速度が 60 MB/秒に低下します。パフォーマンスの制限は、読み込み操作から書き込み操作に移ります。

NetBackup リストアに対するフラグメントサイズの影響フラグメントサイズは、非多重化イメージと多重化イメージの NetBackup リストアに影響する可能性があります。

フラグメントサイズは、テープマーカーが配置される場所と使われるテープマーカーの数

に影響します（デフォルトのフラグメントサイズは、テープストレージユニットの場合が 1TB、ディスクの場合が 512 GB です）。一般に、フラグメントサイズが大きいほどバックアップが高速ですが、少数の個別ファイルをリカバリするときはリストア速度が低下するこ

とがあります。

［ストレージユニット（Storage Unit）］ダイアログボックスの［フラグメントサイズの縮小（Reduce fragment size to）］設定は、イメージの最大フラグメントサイズを制限します。フラグメントのサイズを制限することで、リストア時の最大読み込みサイズが最小化され、

リストア時間が短縮されます。フラグメントサイズは、ディレクトリまたはファイルシステム全体ではなく少数の個別ファイルをリストアするときに特に重要です。

多くのサイトでは、およそ 10 GB のフラグメントサイズで、バックアップとリストア両方について良好なパフォーマンスが得られます。

フラグメントサイズでは、次の点を考慮します。

■ フラグメントサイズが大きいほど、通常はバックアップパフォーマンスが向上し、多量の

データをバックアップするときには特にその傾向が強くなります。より小さいフラグメントでは大きいバックアップが減速することがあります。新しいフラグメントが作成されるたびに、バックアップストリームが割り込まれます。

■ より大きいフラグメントサイズは、多量のデータをリストアするときのパフォーマンスを低

下させません。ただし、少数の個別ファイルをリストアするときは、フラグメントが大きいとリストアが減速することがあります。


■ より大きいフラグメントサイズは、非多重化バックアップからリストアするときのパフォー

マンスを低下させません。多重化バックアップの場合は、フラグメントが大きいとリストアが減速することあります。多重化バックアップでは、複数のイメージからのブロックを単一フラグメントに混在させることができます。リストア中に、NetBackup は最も近いフラグメントに位置設定し、そこからデータの読み込みを開始し、目的のファイルに

到達するまで読み続けます。多重化バックアップをより小さいフラグメントに分割すると、リストアのパフォーマンスを改善できます。

■ リストア時に、より新しく、より高速なデバイスが、大きいフラグメントを適切に処理でき

ます。低速なデバイスで、高速検索ブロック位置設定を使わない場合は特に、フラグメントサイズが小さいと、個々のファイルが高速にリストアされます（場合によっては、SCSI 高速テープ位置設定はリストアのパフォーマンスを改善できます）。

より小さいフラグメントを作成する理由が特にないかぎり、フラグメントサイズが大きいほど、

全体的なパフォーマンスが向上する可能性があります。より小さいフラグメントを作成する理由には、少数の個別ファイルをリストアする、多重化バックアップからリストアする、古

い機器からリストアするなどがあります。

フラグメントサイズの非多重化イメージのリストアへの影響

bptm は、リストアする最初のファイルを含むメディアフラグメントと実際のテープブロックに位置設定します。高速検索が利用可能な場合は、bptm はそれを使って位置設定します。高速検索が利用可能でない場合、bptm は MTFSF/MTFSR （前方スペースファイルマーク/前方スペースレコード）を使って位置設定を行います。

最初のファイルがリストアされます。

その後、リストアする以降のすべてのファイルについて、bptm は現在の位置との相対でそのファイルがどこにあるか判断します。 bptm が間にあるすべてのデータを読み込むよりも、その場所に位置設定する方が速い場合があります（高速検索が利用可能な場合）。

その場合、bptm は間にあるすべてのデータを読み込む代わりに位置設定を使って次のファイルに達します。

高速検索が利用可能でない場合、bptm は MTFSR （前方スペースレコード）で位置設定するのと同じぐらい高速にデータを読み込むことができます。

したがって、高速検索が利用可能でない場合は、非多重化リストアのフラグメントサイズ

が問題になります。小さいフラグメントでは、リストアが読み込む無関係なデータは少なくなります。ストレージユニットの最大フラグメントサイズは、NetBackup 管理コンソールの［ストレージユニット（Storage Unit）］ダイアログボックス（［フラグメントサイズの縮小（Reducefragment size to）］）で設定できます。

フラグメントサイズは多重化イメージのリストアにどのように影響するか

bptm は、リストアする最初のファイルを含むメディアフラグメントに位置設定します。高速検索が利用できる場合は、bptm はそれを使って位置設定します。高速検索が利用でき


ない場合は、bptm は位置設定に MTFSF（前方スペースファイルマーク）を使います。リストアでは、多重化イメージがランダムに書き込まれるため、最初のファイルを含むブロッ

クに移動するために位置設定を「微調整」することはできません。リストアで読み込みが開始されると、多重化グループに含まれる他のバックアップイメージのデータが廃棄され、

リストアされているイメージに関連するデータが保存されます。バックアップ時に多重化の設定と混合イメージの数の値が高かった場合、リストアでは、実際にリストアするデータ

よりも多くのデータを読み込んで破棄する必要があることがあります。

最初のファイルがリストアされます。

それ以降、ロジックは、1 つの例外を除き、非多重化リストアの場合と同じです。現在位置と次のファイル位置が同じフラグメントにあれば、リストアは位置設定を使うことができま

せん。最初のファイルに達するために位置設定を「微調整」できないのと同じ理由で、位置設定を使用できません。

次のファイル位置が後続のフラグメント（または異なるメディア）にあれば、リストアは位置

設定を使ってそのフラグメントに達します。リストアは中間にあるすべてのデータを読み込むわけではありません。

従って、より小さい多重化フラグメントは有利である可能性があります。最適なフラグメントサイズは、サイトのデータと状況によって決まります。複数 GB のイメージの場合は、1GB 以下にフラグメントを保つことが最良であることがあります。フラグメントサイズを制限するストレージユニット属性はフラグメントのデータの合計量に基づいています。 1 つのクライアントのデータの合計量に基づいていません。

多重化イメージが書き込まれるとき、クライアントバックアップストリームの開始か終了のた

びに、結果として新しいフラグメントが作成されます。新しいフラグメントは、チェックポイント再起動が有効になっているバックアップのチェックポイントが出現したときにも作成さ

れます。したがって、すべてのフラグメントが最大フラグメントサイズであるとはかぎりません。メディアの終わり（EOM）も新しいフラグメントの原因になります。

いくつかの例で、小さいフラグメントの方がリストアに役立つ場合と役立たない場合を示し

ます。

例 1:

多重化されたテープに 4 つのストリームをバックアップしたいと仮定します。各ストリームは単一の 1 GB のファイルです。 1 TB のデフォルトの最大フラグメントサイズが指定されています。結果として生じるバックアップイメージは、論理的には次のようになります。「TM」はフラグメントの開始を示すテープマーク、つまりファイルマークを示します。

TM <4 GB データ> TM

1 GB のファイルの 1 つをリストアするために、リストアは TM に位置設定します。それから 1 GB のファイルを取得するために 4 GB をすべて読み込まなければなりません。

最大フラグメントサイズを 1 GB に設定した場合:

TM <1 GB データ> TM <1 GB データ> TM <1 GB データ> TM <1 GB データ> TM


リストアされる 1 GB のファイルを引き出すためにリストアは依然として 4 つのフラグメントすべてを読み込む必要があるため、このサイズは役に立ちません。

例 2:

この例は例 1 と同じですが、4 つのストリームが 1 GB の /home または C:¥ をバックアップすると仮定します。最大フラグメントサイズ（［フラグメントサイズの縮小（Reducefragment size）］）がデフォルトの 1 TB に設定されている場合（また、すべてのストリームが同じようなパフォーマンスであると想定した場合）は、やはり最終的に次のようになりま

す。

TM <4 GB データ> TM

次がリストアされます。

/home/file1

または

C:¥file1

/home/file2

または

C:¥file2

ストリームの 1 つから、NetBackup はすべてのデータをリストアするのに必要な 4 GB を読み込む必要があります。しかし、［フラグメントサイズの縮小（Reduce fragment size）］を 1 GB に設定した場合は、イメージは次のようになります。

TM <1 GB データ> TM <1 GB データ> TM <1 GB データ> TM <1 GB データ> TM

この場合、home/file1 または C:¥file1 は第 2 フラグメントで開始します。 bptm は、home/file1 または C:¥file1 のリストアを開始する第 2 フラグメントに位置設定します。（今のところ 1 GB の読み込みが節約されました。） /home/file1 の終了後、/home/file2または C:¥file2 が第 3 または第 4 フラグメントにある場合は、リストアでは読み込みを開始する前にそのフラグメントの先頭に位置設定できます。

これらの例は、データが何であるか、何がリストアされるか、データがイメージ内のどこに

あるかに応じて、フラグメンテーションがリストアに役に立つかどうかを示しています。例2 では、1 GB から 0.5 GB（512 MB）にフラグメントサイズを減らすと、少量のイメージをリストアするときに、リストアが読み込む代わりにスキップすることで見つけられる可能性が

高くなります。

フラグメンテーションとチェックポイント再開

ポリシーの［チェックポイントから再開 (Checkpoint Restart)］機能が有効になっている場合、NetBackup は各チェックポイントで新しいフラグメントを作成します。［チェックポイントの間隔 (Take checkpoints every)］設定に従ってフラグメントを作成します。［チェック


ポイントから再開 (Checkpoint Restart)］について詳しくは『NetBackup 管理者ガイドVol.1』を参照してください。

NetBackup のリストアのパフォーマンスに関するその他の問題フラグメントサイズに関連するリストアのパフォーマンスの問題については次のトピックで

説明しています。

p.142 の「NetBackup リストアに対するフラグメントサイズの影響」を参照してください。

表 7-14 に、リストアのパフォーマンスに関するその他の問題を示します。

表 7-14 NetBackup のリストアのパフォーマンスに影響する問題

コメントリストアの問題

NetBackup のカタログが存在するディスクサブシステムは、NetBackup の全体的なパフォーマンスに大きい影響を与えます。リストアのパフォーマンスを改善するには、高速に読み込むようにこのサブシステムを設定します。 NetBackup のバイナリカタログの形式は、拡張性が高く高速なカタログアクセスを可能にします。

NetBackup カタログのパフォーマンス

このパラメータは、リストア時に多重化されたテープを位置設定する一方で、他の NetBackup プロセスをビジー状態に保つのに役立ちます。この値を増やすと、NetBackup のバッファが物理的な RAM に占める量が増えます。このパラメータは、多重化リストアにのみ適用されます。


NUMBER_DATA_BUFFERS_RESTOREの設定

『NetBackup 管理者ガイド Vol.1』のカタログのインデックス付けによるバックアップへの高速アクセスに関する項を参照してください。

インデックスのパフォーマン

スの問題



混在環境（UNIX と Windows）でリストアのパフォーマンス上の問題が発生した場合は、TCP 待機間隔パラメータ tcp_deferred_ack_interval の値を減らすことを検討します。このパラメータを変更するには root 権限が必要です。

tcp_deferred_ack_interval の現在の値は、次のコマンドを実行して入手できます（この例は Solaris 用です）。

/usr/sbin/ndd -get /dev/tcp tcp_deferred_ack_interval

tcp_deferred_ack_interval の値は、次のコマンドを実行して変更できます。

/usr/sbin/ndd -set /dev/tcp tcp_deferred_ack_interval value

value は、システムのパフォーマンスを最大にする数値です。これはシステムによって異なる可能性があるため、この方法には試行錯誤が必要な場合があります。推奨される開始値は 20 です。 500 ミリ秒を超える値は TCP/IP を破壊することがあるため、どのような場合でも 500 ミリ秒を超える値は使わないでください。

次のディレクトリの下のスクリプトで、値を永続的にシステムの最適値に設定できます。

/etc/rc2.d

これで、システムの起動時に実行されます。

混在環境のリストアのパ

フォーマンス

多重化が高すぎると、不必要なテープ検索が発生することがあります。理想的な設定は、ドライブのストリーム送信に必要な最小値です。

高すぎる多重化設定



NetBackup は MPX_RESTORE_DELAY オプションによって単一の多重化されたテープから複数のリストアを同時に実行できます。このオプションは、同じテープ上の多重化イメージのセットにあるファイルまたは raw パーティションをリストアする追加要求をサーバーが待機する時間を秒単位で指定します。この期間内に受信したリストア要求は同時に実行されます。デフォルトでは、遅延は 30 秒です。

このオプションは、大きいデータベースのバックアップからの複数のストライプが同じテープに一

緒に多重化されている場合に役立つことがあります。 MPX_RESTORE_DELAY オプションが変更された場合に、変更を反映するために NetBackup プロセスを停止して再起動する必要はありません。

マスターサーバー上の要求デーモン（bprd）は、多重化リストア要求の最初のストリームを受信すると、MPX_RESTORE_DELAY タイマーをトリガします。タイマーは設定された時間のカウントを開始します。 bprd は全体的なジョブを開始する前に、同じクライアントからの関連する多重化ジョブを監視し、待機します。別の関連付けられたストリームがタイムアウト期間内に受信された場合は、そのストリームが全体のジョブに追加され、タイマーが MPX_RESTORE_DELAY 期間にリセットされます。 bprd が追加ストリームを受信することなくタイムアウトに達したら、タイムアウト時間帯は終了します。すべての関連付けられたリストア要求は bptm に送信されます。テープはマウントされます。関連付けられたリストア要求を受信した場合は、現在「使用中」のテープがアイドル状態に戻るまでキューに登録されます。

MPX_RESTORE_DELAY が十分に高く設定されていないと、NetBackup はリストアに必要なすべてのヘッダー情報を収集するために、テープを複数回マウントし、読み込むことが必要な場合が

あります。テープの 1 回の読み込みで、NetBackup が多重化されたテープを読み込み、すべての必要なヘッダー情報を収集すると、理想的です。 1 回の読み込みはリストアの時間を最小化します。

p.148 の「多重化されたデータベースバックアップ (Oracle) からのリストアの例」を参照してください。

多重化データベースバック

アップからのリストア

多重化されたデータベースバックアップ (Oracle) からのリストアの例

MPX_RESTORE_DELAY が bp.conf ファイルに設定されていないため、値が 30 秒のデフォルト値であると仮定します。また、4 つのチャネルまたは 4 つのストリームを使ってバックアップされた Oracle RMAN のバックアップからリストアを開始すると仮定します。また、リストアするために同じ数のチャネルを使います。

RMAN は NetBackup に特定のデータ要求を渡して、リストアの開始と完了に必要な情報を NetBackup に指示します。最初の要求は、29 秒後に NetBackup によって受信され、MPX_RESTORE_DELAY タイマーがリセットされる原因になります。次の要求は 22秒後に NetBackup によって受信され、再びタイマーがリセットされます。3 つ目の要求は 25 秒後に受信され、タイマーの 3 回目のリセットが行われます。しかし 4 つ目の要求は 3 つ目の 31 秒後に受信されます。4 つ目の要求はリストア遅延間隔内に受信されなかったので、NetBackup は 4 つのリストアのうち 3 つを開始します。テープから 1 回読み込む代わりに、NetBackup は以前の 3 つの要求が完了するまで 4 つ目のリストア要


求をキューに登録します。多重化イメージすべてが同じテープにあることに注意してくだ

さい。NetBackup は、4 つ目のリストア要求の多重化イメージを収集するために、テープ全体を再びマウントし、巻き戻し、読み込みます。

NetBackup がテープを 2 回読み込むことに加えて、RMAN は、リストアを開始する前に必要なすべてのヘッダー情報の受信を待機します。

MPX_RESTORE_DELAY が 30 秒より長ければ、NetBackup はリストア遅延時間帯内に 4 つのリストア要求をすべて受信できます。テープの 1 回の読み込みですべての必要なヘッダー情報が収集されます。Oracle はこの 1 回のテープ読み込みの後でリストアを開始して、リストアパフォーマンスを向上できます。

MPX_RESTORE_DELAY は、余りに高く設定されるとパフォーマンスを低下させることがあるため、慎重に設定します。MPX_RESTORE_DELAY が 1800 秒に設定されていると仮定します。関連付けられた最後のリストア要求が到着すると、NetBackup は以前の要求で行ったのと同じように要求遅延タイマーをリセットします。NetBackup はリストアを開始する前に、1800 秒の間隔全体を待機する必要があります。

したがって、MPX_RESTORE_DELAY の値は、高すぎず低すぎない値に設定するようにしてください。

データ転送パスでの NetBackup ストレージデバイスのパフォーマンス

このセクションでは、NetBackup のデータ転送パスのストレージデバイス機能を確認します。これらの領域を変更すると、NetBackup のパフォーマンスが向上することがあります。

データストリームがテープドライブ容量と一致し、維持されている場合は、テープドライブ

の消耗が大幅に低減し、効率が向上します。ほとんどのテープドライブのスループットはディスクドライブよりも低速です。ドライブ数とドライブごとのスループットを SCSI/FC 接続の速度に一致させて、ハードウェアベンダーの推奨事項に従ってください。

次の要因はテープドライブに影響します。

■ メディアの配置

バックアップまたはリストアが実行されるときに、ストレージデバイスはデータが読み書

きヘッド上にくるようにテープを配置する必要があります。配置には長時間かかることがあります。複数のイメージを含んでいるメディアでパフォーマンス分析を行うときは、データ転送の開始前に生じるタイムラグを考慮します。

■ SCSI バスの割り当てテープドライブを別の SCSI バスに接続します。たとえば、8 台のテープドライブがある場合、最低 4 つの SCSI カードを使い、各カードに 2 台までのドライブを接続します。

■ テープストリーミング

149第 7 章 NetBackup のデータ転送パスのチューニングデータ転送パスでの NetBackup ストレージデバイスのパフォーマンス

テープデバイスが最も効率的な速度で使われている場合、データをテープへ「ストリー

ミング」しています。テープデバイスがストリーミングを実行している場合は、メディアの停止と再起動が必要なことはまれです。代わりに、メディアはテープドライブ内で常に回転しています。テープデバイスが最も効率的な速度で使われていない場合、メディアは絶え間なく開始、停止し、回転が中断されることがあります。この動作はテープストリーミングの反対で、通常はデータスループットが悪化する原因になります。

■ データ圧縮

ほとんどのテープデバイスでは、テープデバイス内部で何らかの形式のデータ圧縮

がサポートされます。テープデバイスがハードウェアデータ圧縮をサポートする場合、圧縮可能なデータ（テキストファイルなど）は圧縮不可能なデータよりも高いデータス

ループット率をもたらします。

テープデバイスには、通常 2 つのパフォーマンス速度があります。それは最大スループットと公称スループットです。最大スループットは、ハードウェア圧縮がドライブで有効になっているときに圧縮可能なデータをテープドライブに書き込める速度に基づい

ています。公称スループットは、圧縮不可能なデータで達成可能な速度を示します。

メモ: NetBackup はテープドライブのデータ圧縮を設定できません。 OS とテープドライブで提供される手順に従います。

一般に、テープドライブのデータ圧縮はクライアント（ソフトウェア）圧縮よりも推奨され

ます。クライアント圧縮はリモートクライアントのバックアップでネットワーク上で伝送されるデータの量を減らすのに適していることがあります。

p.159 の「圧縮と NetBackup のパフォーマンス」を参照してください。

150第 7 章 NetBackup のデータ転送パスのチューニングデータ転送パスでの NetBackup ストレージデバイスのパフォーマンス

他の NetBackup コンポーネントのチューニング


■ 多重化と複数のデータストリームを使う場合

■ バックアップとリストアに対する多重化と複数ストリームの影響

■ NetBackup のリソース割り当てを改善する方法

■ 暗号化と NetBackup のパフォーマンス

■ 圧縮と NetBackup のパフォーマンス

■ NetBackup 圧縮を有効にする方法

■ NetBackup のパフォーマンスに対する圧縮と暗号化の影響

■ NetBackup Java のパフォーマンスの改善に関する情報

■ NetBackup Vault に関する情報

■ Bare Metal Restore での高速リカバリ

■ 多数の小さいファイルをバックアップするときのパフォーマンスを改善する方法

■ FlashBackup のパフォーマンスを改善する方法

■ NetBackup for VMware のスナップショットマウントポイントボリュームの割り当てサイズの調整

■ Symantec NetBackup OpsCenter

8

多重化と複数のデータストリームを使う場合複数のデータストリームは大容量のバックアップの時間を短縮することができます。この時間の短縮は、バックアップするデータを最初に複数のストリームに分割することによっ

て実現されます。その後、ストリームを同時に処理するために多重化、複数のドライブ、この 2 つの組み合わせを使います。さらに、クライアントの各物理デバイスが別のデータストリームによってバックアップされるようにバックアップを設定できます。バックアップ時間を短縮するために、各データストリームは他のデバイスからのストリームと同時に動作し

ます。

メモ: 最良のパフォーマンスを得るために、1 つのデータストリームだけを使用してクライアントの各物理デバイスをバックアップします。単一の物理デバイスからの複数の並列実行

ストリームはそのデバイスをバックアップする時間に悪影響を与える可能性があります。ド

ライブヘッドがそれぞれのストリームのファイルを含んでいるトラックの間で前後に動く必

要があるためです。

リストア速度が最も重要であるか、またはテープドライブが遅い場合、データベースバック

アップで多重化は推奨されません。

ネットワークを介したバックアップは、ネットワークの帯域幅が非常に広くないかぎり、スト

リームの機能を無効化する可能性があります。通常、単一クライアントで単一の 100BaseTネットワーク接続を飽和させるのに十分なデータを送信できます。ギガビットネットワークは、いくつかのクライアントのネットワークストリーミングをサポートする容量を備えていま

す。単一のストリームより複数のストリームの方がクライアントのリソースを多く使います。シマンテック社は、クライアントが複数のデータストリームを処理できることと、ユーザーが

高速のデータ転送に影響されないことを確かめるためにテストすることを推奨します。

多重化と複数のデータストリームは、すべてのテープドライブのストリーミングを可能にす

る強力なツールになります。 NetBackup では両方とも同時に使うことができます。 2 つの概念を次のように区別するように注意してください。

多重化は単一のテープドライブに複数のデータストリームを書き込みます。

図 8-1 は多重化を示しています。

図 8-1 多重化の図

サーバークライアント

テープへのバックアップ

152第 8 章他の NetBackup コンポーネントのチューニング多重化と複数のデータストリームを使う場合

複数のデータストリーム機能は、多重化が使われないかぎり、複数のデータストリームを

それぞれのテープドライブ自体に書き込みます。

図 8-2 は複数のデータストリームを示しています。

図 8-2 複数のデータストリームの図

サーバー

テープへのバックアップ

多重化について、次を考慮してください。

■ さまざまな多重化因数で試して、ストリームに最小限必要な因数を見つけます。

書き込みがドライブの最大帯域幅を満たすのに十分である設定を見つけます。その

設定が最適な多重化因数となります。読み込みストリームのそれぞれから 5 MB/秒を取得する場合は、DLT7000 への最大スループット（つまり、10 MB/秒）を取得するために 2 の多重化因数を使います。

■ 増分バックアップには、より高い多重化因数を使います。

■ ローカルバックアップには、より低い多重化因数を使います。

■ (複製で［多重化を維持する（Preserve Multiplexing）］が指定されていないかぎり）非多重化されている場合、多重化されたテープの複製に時間がかかることが予想され

ます。［多重化を維持する（Preserve Multiplexing）］を指定しないと、ソーステープの複数の読み込みパスを作成する必要があるため複製に時間がかかることがありま

す。ただし、［多重化を維持する（Preserve Multiplexing）］を使うと、リストアの時間に影響することがあります（次の箇条書きを参照してください）。

■ 多重化バックアップを複製するときは、それを非多重化します。

バックアップを複製するときにそのバックアップを非多重化することによって、リカバリ

の時間は大幅に短縮されます。

複数のデータストリームについて、次を考慮してください。

■ 単一のマウントポイントで複数のデータストリームを使わないでください。

複数のデータストリーム機能は複数のデバイスからデータを同時にストリーム化する

機能を利用します。複数のデバイスからストリーム化すると、RAID 環境の単一または複数のスピンドルで先読み（Read Ahead）を利用してバックアップを実行できます。

153第 8 章他の NetBackup コンポーネントのチューニング多重化と複数のデータストリームを使う場合

単一のマウントポイントから複数のデータストリームを使うと、ヘッドスラッシングが助長

され、パフォーマンスの低下につながることがあります。ミラー化されている場合（RAID0）のみ、単一のマウントポイントに対して複数ストリームのバックアップを行います。ただし、パフォーマンスの低下につながる可能性が高くなります。

バックアップとリストアに対する多重化と複数ストリームの影響


■ 多重化

効果的に多重化を使うには、リストア時間に対する多重化の影響を理解する必要が

あります。多重化によって遅いネットワーク上で多数のクライアントをバックアップする時間が短縮されることがありますが、リカバリ時間が犠牲になります。多重化されたテープからリストアするにはすべての非適用データを除外する必要があります。この処理によって、リストア時間が長くなります。リカバリが必要な場合、非多重化によりリストア処理の遅延が発生します。NetBackup では、リストアを実現するためにテープを検索する必要があるためです。

多重化がリストアのパフォーマンスに与える影響を判断するためにリストアをテストして

ください。また、多重化するときに最大フラグメントサイズを小さくすることで、パフォーマンスが向上することがあります。

p.142 の「NetBackup リストアに対するフラグメントサイズの影響」を参照してください。

新しい環境を最初に設定するときは、多重化因数を低い値で維持します。ドライブまたはシステムの種類によっては、4 以下の多重化因数はリストアの速度に大きく影響しません。バックアップが割り当てられた時間内に終わらない場合、時間帯に合わせて多重化を増加できます。ただし、多重化因数を増やすと、多重化クライアントの数が増加するにつれて効果は減少します。最適な多重化因数とは単一のテープドライブに対してバッファをいっぱいに保つために必要とされるクライアントの数です。

複数ストリームは実行せず、多重化因数を 4 に設定します。この環境でベンチマークを実行します。その後、値の変更を開始し、バックアップとリストア両方のウィンドウパラメータを一致させます。

■ 複数データストリーム

NEW_STREAM 指示句は、ディスクサブシステムが十分にされなかったり、過剰に利用されることがないようストリームを微調整するために有用です。

NetBackup のリソース割り当てを改善する方法次の調節は NetBackup のリソース割り当てを改善するために実行できます。

154第 8 章他の NetBackup コンポーネントのチューニングバックアップとリストアに対する多重化と複数ストリームの影響

p.155 の「NetBackup キューに投入済みのジョブへのリソースの割り当ての改善」を参照してください。

p.155 の「NetBackup での予約の共有」を参照してください。

p.156 の「NetBackup での予約の共有の無効化」を参照してください。

p.157 の「オンデマンドアンロードの無効化」を参照してください。

NetBackup キューに投入済みのジョブへのリソースの割り当ての改善特定の状況では、nbrb でドライブを待機中のジョブを処理するために長時間かかることがあります。この遅延は、多くのジョブがリソースのためにキューに投入され、それらのジョブが nbrb で新しいジョブ用に解放されたリソースを再利用できるよりも早く完了すると発生することがあります。

この状況で nbrb のパフォーマンスを改善するためには、次のドキュメントを参照してください。

NetBackup 内でのリソース割り当てについては次を参照してください。


また、NetBackup の次のトレーニングモジュールが役に立つ場合があります。

顧客およびパートナー向けリソース割り当てトレーニング（モジュール 1）




NetBackup での予約の共有パフォーマンスを改善するため、NetBackup は予約を共有できるようにしました。NetBackup はデフォルトで予約を共有します。予約の共有を使用すると、複数のジョブは同じメディアを予約できます。ただし、一度に 1 個のジョブのみメディアを使用できます。つまり、2 番目のジョブは最初のジョブが終了するまで待つ必要はありません。2 番目のジョブは最初のジョブが使用した後すぐにメディアにアクセスできます。

予約の共有を有効にする方法

◆ 次のファイルを作成します。

UNIX の場合

/usr/openv/netbackup/db/config/RB_USE_SHARED_RESERVATIONS

Windows の場合

install_path¥Veritas¥NetBackup¥db¥config¥RB_USE_SHARED_RESERVATIONS

155第 8 章他の NetBackup コンポーネントのチューニングNetBackup のリソース割り当てを改善する方法


http://www.brainshark.com/symantec/vu?pi=zGuzB8ntZz3BSfz0&

http://www.brainshark.com/symantec/vu?pi=zGQzOgFNNz3BSfz0&intk=609121994

http://www.brainshark.com/symantec/vu?pi=zHizHaZuoz3BSfz0&

http://www.brainshark.com/symantec/vu?pi=zEqz430k6z3BSfz0&

NetBackup での予約の共有の無効化NetBackup では予約の共有がデフォルトで有効になっています。

p.155 の「NetBackup での予約の共有」を参照してください。

ほとんどの場合、予約を共有するとパフォーマンスが向上します。

ただし、次のような場合は、予約の共有を無効にすると有用なことがあります。

■ 多くの複製ジョブが (ストレージライフサイクルポリシー、Vault、または bpduplicate を使って) 動作している

■ 多くの読み込みメディアが異なる複製ジョブ間で共有されている

このような場合は予約を取得できないので、予約の共有なしで 1 つのジョブが実行され、同じメディアを必要とする他のジョブはキューに投入されます。予約の共有を使うと、ジョ

ブを同時に開始できます。ただし、限られた一組のリソース (メディアとドライブのペアまたはディスクドライブ) では、各ジョブがリソースを要求すると、異なるジョブ間でリソースが交互に使用されることがあります。

たとえば、次の条件を想定します。

2 つの複製ジョブ、ジョブ 1 とジョブ 2 がバックアップイメージを複製しています。ジョブ1 はイメージ 1 から 5 を複製し、ジョブ 2 はイメージ 6 から 9 を複製しています。これらのイメージは次のメディアにあります。

表 8-1 ジョブ 1 と 2 によって必要なメディア

ジョブ 2 によって使われるメディアジョブ 1 によって使われるメディア

イメージ 6 はメディア A2 にあります。









この例では、ジョブは両方ともメディア A2 へのアクセスを必要とします。予約の共有なしで、ジョブ 1 が予約を最初に取得すると、メディア A2 を予約する必要があるためジョブ2 は開始できません。A2 はジョブ 1 によってすでに予約されています。予約の共有を使うと、ジョブは両方とも同時に開始できます。

ただし、少数のドライブのみが書き込みに利用可能であると想定します。また、ジョブ 1が最初に始まり、イメージ 1 の複製を開始すると想定します。その後、イメージ 6 を複製するためにメディア A2 を使ってジョブ 2 が始まります。メディア A2 は、ジョブ 1 で使われたり、ジョブ 2 で使われたり、事実上 2 つのジョブ間で交互に使用されます。その結果、両方のジョブの全体的なパフォーマンスが低下することがあります。

次の手順を実行して予約の共有を無効にできます。

156第 8 章他の NetBackup コンポーネントのチューニングNetBackup のリソース割り当てを改善する方法

予約の共有を無効にする方法


UNIX の場合

/usr/openv/netbackup/db/config/RB_DO_NOT_USE_SHARED_RESERVATIONS

Windows の場合

install_path¥Veritas¥NetBackup¥db¥config¥RB_DO_NOT_USE_SHARED

_RESERVATIONS

オンデマンドアンロードの無効化NetBackup EMM サービスは、メディアアンロードの遅延の期限が切れていない場合でもリソースブローカー (nbrb) にドライブのアンロードを要求することがあります。この要求をオンデマンドアンロードと呼びます。ドライブをアンロードしないと要求のリソースを割り

当てられない場合、EMM は nbrb にドライブのアンロードを要求することがあります。

一連の小さい関連バックアップジョブ (NetBackup の複数のデータベースエージェントのジョブなど) がスケジュールされるとき、オンデマンドアンロードを無効にすることが有用なことがあります。

オンデマンドアンロードを無効にする方法


UNIX の場合

/usr/openv/netbackup/db/config/RB_DISABLE_REAL_UNLOADS_ON_DEMAND

Windows の場合

install_path¥Veritas¥NetBackup¥db¥config¥RB_DISABLE_REAL_UNLOADS_ON

_DEMAND

暗号化と NetBackup のパフォーマンスバックアップの実行時、バックアップ環境に応じて次のいずれかの方法で暗号化を実行

できます。

■ NetBackup クライアントで暗号化を実行します。

■ NetBackup メディアサーバーで暗号化を実行します。

■ テープドライブで NetBackup キーマネジメントサービスと連携して暗号化を実行します。テープドライブに組み込みの暗号化機能が必要です。

157第 8 章他の NetBackup コンポーネントのチューニング暗号化と NetBackup のパフォーマンス

表 8-2 に各テクノロジによるパフォーマンスへの影響を示します。

表 8-2 暗号化オプションと NetBackup のパフォーマンス

パフォーマンスに関する注意事項暗号化オプション

NetBackup クライアントでデータ暗号化（圧縮）を実行できます（ポリシーの［属性（Attributes）］タブの暗号化と圧縮のオプションを使います）。クライアントでの暗号化は、暗号化（それ以外のバックアップ処理も含む）を実行するための十分な CPU リソースがクライアントにあれば有効なオプションになります。

NetBackup クライアントでの暗号化を使うとバックアップが遅くなる場合があることに注意してください。どのくらい遅いかはバックアップパスのスロットルポイントによって決まります。ネットワークが問題である場合、暗号化はパフォーマンスを妨げません。ネットワークが問題でない場合、暗号化はバックアップを減速することがあります。

複数の CPU を搭載するクライアントでの暗号化バックアップの複数ストリームの場合、CPU の数より1 個少ないストリームを定義するようにします。たとえばクライアントが 4 個の CPU を持っている場合、バックアップで 3 個以下のストリームを定義します。このアプローチは CPU の競合を最小化できます。

p.161 の「NetBackup のパフォーマンスに対する圧縮と暗号化の影響」を参照してください。

クライアントでの暗号化

（NetBackup ポリシーの属性タブの［暗号化

（Encryption）］オプション）

NetBackup メディアサーバーで MSEO（Media Server Encryption Option）を使ってデータ暗号化（圧縮）を実行できます。


■ ほとんどの場合、追加のテープを使わなくて済むようにデータを暗号化する前に圧縮します。

MSEO でデータの圧縮と暗号化の両方を実行できます。■ MSEO で圧縮を行うと、テープドライブのストリームを保つためにメディアサーバーで処理する必要があるデータの量が増加します。

■ 暗号化を必要とするバックアップデータの量が限られている場合、通常は MSEO が最も効果的です。

■ 暗号化するデータの量が多いほどメディアサーバーの CPU 負荷が高くなります。 MSEO でデータを暗号化する前に圧縮も行うと、さらに多くの CPU が必要になります。たとえば、Solaris メディアサーバーを使って 100 MB/秒でデータの圧縮と暗号化を行う場合、MSEO の処理に約 8.7GHz の CPU が追加で必要になります。

MSEO のパフォーマンスについて詳しくは、「A guide to best practices when using the NetBackupMedia Server Encryption Option」を参照してください。


Media ServerEncryption Option(MSEO)

テープドライブによる暗号化はバックアップのパフォーマンスにほとんど影響しません。このオプションを使うには NetBackup キーマネジメントサービス（KMS）が必要です。

注意: NetBackup 7.1 から、KMS のキーグループの数が 100 に増加しました。

NetBackup キーマネジメントサービス

（KMS）によるテープドライブでの暗号化

158第 8 章他の NetBackup コンポーネントのチューニング暗号化と NetBackup のパフォーマンス


圧縮と NetBackup のパフォーマンスNetBackup は次の 2 種類の圧縮をサポートします。

■ クライアント圧縮（NetBackup ポリシーで設定される）

■ テープドライブ圧縮（デバイスハードウェアによって処理される）

圧縮の種類を選択するときは次を考慮します。

■ データ圧縮の使用はデータ自体の圧縮性に基づいて決定してください。

次に降順で示す圧縮性のレベルに注意してください。

■ 平文

通常は最も圧縮性の高い種類のデータです。

■ 実行可能コード

多少圧縮できますが、平文ほどは圧縮できません。

■ すでに圧縮されたデータ

多くの場合、それ以上の圧縮はできません。

■ 暗号化データ

圧縮されるとサイズが大きくなることがあります。

p.161 の「NetBackup のパフォーマンスに対する圧縮と暗号化の影響」を参照してください。

■ ほとんどの場合クライアント圧縮よりテープドライブの圧縮が好まれます。圧縮ではCPU に負荷がかかり、テープドライブには、圧縮を実行するハードウェアが組み込まれています。

■ テープ圧縮とクライアント圧縮を両方使うことは避けてください。

すでに圧縮されたデータを圧縮するとバックアップデータの量が増加します。

■ まれなケースのみクライアント（ソフトウェア）圧縮を使うことに利点があります。

それらのケースは通常は次の性質を含みます。

■ クライアントデータが高圧縮性。

■ クライアントに豊富な CPU リソースがある。

■ クライアントとサーバー間のネットワークを介して送信されるデータを最小化する

必要がある。

ただしそれ以外の場合は NetBackup のクライアント圧縮はオフにし、ハードウェアで圧縮を処理してください。

■ クライアント圧縮により、ネットワーク上で送信されるデータの量は削減されますが、ク

ライアントの CPU 使用率は増加します。

■ UNIX では、NetBackup クライアント設定の MEGABYTES_OF_MEMORY がクライアントのパフォーマンスに役立つことがあります。

159第 8 章他の NetBackup コンポーネントのチューニング圧縮と NetBackup のパフォーマンス

このオプションは圧縮のために利用可能なメモリの容量を設定します。

すでに圧縮されたファイルは圧縮しないでください。データを 2 回圧縮した場合は、NetBackup の構成オプション COMPRESS_SUFFIX を参照してください。特定のサフィックスを含むファイルを圧縮から除外するためにこのオプションを使うことができま

す。 bpsetconfig でこの設定を編集します。『Symantec NetBackup 管理者ガイド Vol. 2』を参照してください。

NetBackup 圧縮を有効にする方法表 8-3 NetBackup 圧縮を有効にする方法に関するヒント

有効にする方法圧縮の種類

NetBackup の［ポリシー属性（Policy Attributes）］ウィンドウで圧縮オプションを選択します。

クライアント圧縮

オペレーティングシステムとテープドライブの種類によってテープド

ライブ圧縮を有効にするかどうかが決まります。テープ圧縮を有効にする方法についてはオペレーティングシステムとドライブのベン

ダーまたはそれらのマニュアルを参照してください。

ヒント: UNIX デバイスのアドレス指定では、これらのオプションは高い頻度でデバイス名の一部になります。単一のテープドライブに複数の名前があり、名前にそれぞれ異なる機能が組み込まれていま

す（メジャーデバイス番号とマイナーデバイス番号によって複数の名前が利用可能になります）。 Solaris で /dev/rmt/2cbn とアドレス指定した場合、ドライブ 2 ハードウェア圧縮、非巻き戻しオプションを取得します。 /dev/rmt/2n とアドレス指定した場合、その機能は非圧縮で非巻き戻しオプションとなります。デバイス名の選択でデバイス動作が決まります。

メディアサーバーが UNIX である場合、ディスクストレージユニットにバックアップするときは圧縮されません。この場合の圧縮オプションはクライアント圧縮に制限されます。ディスクストレージユニットが付いているメディアサーバーが Windows であり、ディスクストレージユニットで使われるディレクトリが圧縮されている場合、すべての

アプリケーションによるそのディレクトリへのすべてのファイルの書き

込みと同様に、ディスクへの書き込みに対しても圧縮が使われるこ

とに注意してください。

テープドライブ圧縮

160第 8 章他の NetBackup コンポーネントのチューニングNetBackup 圧縮を有効にする方法

NetBackup のパフォーマンスに対する圧縮と暗号化の影響

暗号化と圧縮両方でポリシーが有効になった場合、クライアントは最初にバックアップデー

タを圧縮しそれを暗号化します。データは暗号化されるとき、ランダム化され、圧縮できなくなります。したがって、データ圧縮はあらゆるデータの暗号化前に実行する必要があります。

メモ: バックアップのために NetBackup に提供されたデータがすでに暗号化または圧縮されている場合、NetBackup の圧縮または暗号化を使うと逆効果になり、不必要にリソースを消費することがあります。

NetBackup Java のパフォーマンスの改善に関する情報パフォーマンスの改善について詳しくは、『Symantec NetBackup 管理者ガイド Vol. 1UNIX および Linux』で、次の項を参照してください。

■ 「NetBackup-Java 管理コンソールの使用」

■ 「NetBackup-Java のパフォーマンスの向上について」

『NetBackup リリースノート』にも NetBackup Java パフォーマンスに関する情報が記載されている可能性があります。

NetBackup Vault に関する情報NetBackup Vault のチューニングに関する情報を参照できます。

『NetBackup Vault 管理者ガイド』のベストプラクティスに関する章を参照してください。

Bare Metal Restore での高速リカバリBare Metal Restore (BMR) はシステム全体 (オペレーティングシステムとアプリケーションを含む) をリカバリするための簡略化、自動化された方式を提供します。BMR は迅速でエラーのないリカバリを確実にするためにリストア処理を自動化します。この処理は 1つの Bare Metal Restore コマンドとシステムブートを必要とします。BMR は整合性と一貫性を保証し、UNIX と Windows システムの両方でサポートされます。

メモ: BMR は True Image Restore オプションを必要とします。このオプションはNetBackup カタログのサイズと関係があります。

161第 8 章他の NetBackup コンポーネントのチューニングNetBackup のパフォーマンスに対する圧縮と暗号化の影響

p.27 の「NetBackup イメージデータベースのサイズを計算する方法」を参照してください。

多数の小さいファイルをバックアップするときのパフォーマンスを改善する方法

NetBackup は単一の大きいファイルより多くの小さいファイルをバックアップする方に時間がかかることがあります。

表 8-4 多数の小さいファイルをバックアップするときのパフォーマンスを改善する方法

注意事項次を実行します。

FlashBackup は NetBackup Snapshot Client の機能です。 FlashBackup については『NetBackup Snapshot Client 管理者ガイド』を参照してください。

p.163 の「FlashBackup のパフォーマンスを改善する方法」を参照してください。

FlashBackup（またはFlashBackup-Windows）ポリシー形式を使います。

スキャンをオフにすると、パフォーマンスが倍増することがあります。Windows: ウイルススキャンをオフにします。

FlashBackup とは異なり、この種類のバックアップでは個々のファイルのリストアは実行できません。

（Snapshot Client のFlashSnap 方式などで）スナップショットミラーを作成し rawパーティションとしてバックアッ

プします。

NetBackup のログ記録機能はバックアップとリカバリの処理のパフォーマンスに影響する可能性があります。ログ記録は通常 NetBackup の問題をトラブルシューティングするために一時的に有効になります。ログ記録の量と詳細レベルはパフォーマンスに影響する可能性があります。

ログ記録をオフにするか減らし

ます。

p.109 の「NetBackup メディアサーバーのネットワークバッファサイズの設定」を参照してください。

p.112 の「NetBackup クライアントの通信バッファサイズの設定」を参照してください。

メディアサーバーのネットワーク

バッファサイズがクライアントの

通信バッファサイズと同じである

か確認します。

p.55 の「NetBackup カタログにメタデータを送信するためのバッチサイズの調整」を参照してください。

メタデータをカタログに送信す

るためのバッチサイズを調整

新しいリリースが発表された場

合は NIC ドライバをアップグレードします。

162第 8 章他の NetBackup コンポーネントのチューニング多数の小さいファイルをバックアップするときのパフォーマンスを改善する方法

注意事項次を実行します。

Windows のクライアントで次の bpbkar スループットテストを実行します。

C:¥Veritas¥Netbackup¥bin¥bpbkar32 -nocont > NUL 2>

たとえば、

C:¥Veritas¥Netbackup¥bin¥bpbkar32 -nocont c:¥ > NUL 2> temp.f

UNIX のクライアントで次の bpbkar スループットテストを実行します。

/usr/openv/netbackup/bin/bpbkar -nocont -dt 0 -nofileinfo-nokeepalives file system > /dev/null

file system はバックアップされているパスのことです。

たとえば、

/usr/openv/netbackup/bin/bpbkar -nocont -dt 0 -nofileinfo-nokeepalives file system > /dev/null

bpbkar スループットテストの実行

最初に Windows サーバーを設定するとき、共有ファイルのアクセスに対して TCP/IP のスループットを最適化します。

TCP/IP スループットの最適化

Windows ではフォアグラウンドパフォーマンスよりバックグラウ

ンドパフォーマンスを高めます。

p.107 の「データ転送パスでの NetBackup クライアントのパフォーマンス」を参照してください。

クライアントがシステムサーバー

である場合、NetBackup ClientJob Tracker をオフにします。

定期的に全サーバーの OS のパッチ報告を見直します。 TCP/IP 機能に影響する、パケットのシーケンス外配信の訂正などのパッチをインストールします。

適切なパッチのインストール

FlashBackup のパフォーマンスを改善する方法NetBackup FlashBackup のパフォーマンスは次のように調整できます。

163第 8 章他の NetBackup コンポーネントのチューニングFlashBackup のパフォーマンスを改善する方法

表 8-5 FlashBackup のパフォーマンスを改善するためのヒント

備考ヒント

nbu_snap などのコピーオンライト方式で FlashBackup 機能を使用する場合は、別のハードディスクドライブにスナップショットキャッシュデバイスを割り当てます。別のハードディスクドライブによって、ディス

クの競合とヘッドスラッシングが発生する可能性が減ります。

FlashBackup の設定について詳しくは『NetBackup Snapshot Client 管理者ガイド』を参照してください。

スナップショット

キャッシュデバイスを

別のハードディスクド

ライブに割り当てま

す

ストレージユニットの書き込み速度が速い場合、FlashBackup の raw パーティションのバックアップの間にクライアントディスクの読み込みがボトルネックになることがあります。デフォルトでは、FlashBackup(UNIX 上) は完全バックアップで 128 KB の固定バッファ、増分で 32 KB のバッファを使用して rawパーティションを読み込みます。デフォルトでは、FlashBackup-Windows は完全バックアップと増分で32 KB の固定バッファを使用して raw パーティションを読み込みます。

ほとんどの場合、デフォルトの読み込みバッファサイズで FlashBackup はストレージユニットの書き込み速度を上回ることができます。クライアントデータを読み込むときに I/O の待機の数を最小化するために、FlashBackup の読み込みバッファサイズを調整できます。このバッファを調整すると、NetBackupはディスクドライバに応じて I/O の待機ごとに 1 MB までの連続デバイスブロックを読み込むことができます。読み込みバッファサイズは完全バックアップと増分バックアップで個別に調整できます。

一般に、より大きいバッファがより速い raw パーティションのバックアップを可能にします (ただし次の注意を参照してください)。VxVM のストライプボリュームの場合、読み込みバッファを複数のストライプブロックサイズとして設定できます。複数のディスクから同時にデータを読み込んで、raw パーティションのバックアップの速度を速くすることができます。

メモ: 増分バックアップの読み込みバッファのサイズを変更することはより速いバックアップにつながることもありますが、場合によってはバックアップが遅くなることもあります。最適な設定を達成するには実験

が必要であることがあります。

サイズ調整をした結果は次の要因によって決まります。

■ 読み込まれるデータの場所

■ 読み込みバッファのサイズに関連して読み込まれるデータのサイズ

■ ストレージデバイスと I/O スタックの読み込みの性質

p.164 の「FlashBackup と FlashBackup-Windows の読み込みバッファの調整」を参照してください。

FlashBackup の読み込みバッファを調

整します

p.55 の「NetBackup カタログにメタデータを送信するためのバッチサイズの調整」を参照してください。バッチサイズを調整

してメタデータをカタ

ログに送信します。

FlashBackup と FlashBackup-Windows の読み込みバッファの調整次の手順を使用して、FlashBackup と FlashBackup-Windows の raw パーティションバックアップの読み込みバッファを調整します。


UNIX と Linux のクライアントの FlashBackup の読み込みバッファを調整する方法

1 各クライアントで次の touch ファイルを作成します。

/usr/openv/netbackup/FBU_READBLKS

2 FBU_READBLKS ファイルに値を次のとおり入力します。

ファイルの 1 行目で、完全バックアップまたは増分バックアップ (あるいはこの両方)の読み込みバッファサイズの整数値をブロック単位で入力します。デフォルトは完全

バックアップで 256 ブロック (131072 バイト、または 128 KB)、増分バックアップで64 ブロック (32768 バイト、または 32 KB) です。ブロックサイズは (KB サイズ×2)、または (バイト数/512) と等しくなります。

両方の値を変更するには、スペースで区切ります。

例:

512 128

このエントリは完全バックアップの読み込みバッファを 256 KB、増分の読み込みバッファを 64 KB に設定します。

ファイルの 2 行目を使用してテープの記録の書き込みサイズもブロック数で設定できます。デフォルトは読み込みバッファと同じサイズです。2 行目の最初のエントリは完全バックアップの書き込みバッファサイズを設定します。2 つ目の値は増分バックアップの書き込みバッファサイズを設定します。読み込みバッファサイズとテープの

記録の書き込みサイズを同じ値に設定するには、ファイル全体を次のように読み込

みます。

512 128

512 128

Windows クライアントの FlashBackup-Windows の読み込みバッファを調整する方法

1 ［ホストプロパティ (Host Properties)］、［クライアント (Clients)］の順にクリックし、クライアントを右クリックして［プロパティ (Properties)］を選択します。

［Windows クライアント (Windows Client)］、［クライアントの設定 (Client Settings)］の順にクリックします。

2 ［Raw パーティション読み込みバッファサイズ (Raw partition read buffer size)］で、読み込みバッファのサイズを指定します。

デフォルトの 32 KB より大きい読み込みバッファサイズではバックアップ速度が速くなることがあります。結果はシステムごとに異なるため、実験が必要になることがあり

ます。最初は 1024 に設定することをお勧めします。



■ この設定は FlashBackup-Windows ポリシー (NetBackup for VMware を含む) のみでなく raw パーティションのバックアップにも適用されます。

■ この設定は完全バックアップと増分バックアップに適用されます。

NetBackup for VMware のスナップショットマウントポイントボリュームの割り当てサイズの調整

VCB バックアップの場合: 仮想マシンの完全バックアップの速度を速くするには、VMwareバックアッププロキシサーバーでスナップショットマウントポイントとして使われるボリューム

のファイルシステム割り当てサイズの増加を試みてください。割り当てサイズをたとえば 64KB のように大きくすると、バックアップ速度が速くなることがあります。結果はシステムごとに異なる可能性があるため、実験が必要になることがあります。

メモ: NetBackup 7.x は (VCB の代わりに) VMware vStorage API を使ってほとんどのVMware 環境をバックアップします。VCB が必要になるのは次の VMware 環境のみになります。VirtualCenter サーバーが存在しない場合は 3.5 より前のバージョンの ESXServer、その他の場合は 2.5 より前のバージョンの VirtualCenter サーバー。

NetBackup for VMware の別のチューニングの提案については、次を参照してください。

p.164 の「FlashBackup と FlashBackup-Windows の読み込みバッファの調整」を参照してください。

次のマニュアルには NetBackup for VMware に関する情報が記載されています。

■ VCB を使用する場合のスナップショットマウントポイントと VMware バックアッププロキシサーバーについて詳しくは、7.1 の『NetBackup for VMware 管理者ガイド』を参照してください。

■ 仮想環境の NetBackup サポートに関する最新情報は、次を参照してください。http://www.symantec.com/docs/TECH127089

Symantec NetBackup OpsCenterパフォーマンス向上のための Symantec NetBackup OpsCenter のチューニングについては、次のマニュアルを参照してください。

■ 『Symantec NetBackup OpsCenter 7.5 管理者ガイド』http://www.symantec.com/docs/DOC5042

■ 『Symantec NetBackup OpsCenter 7.6 Performance and Tuning Guide』http://www.symantec.com/docs/DOC7416

■ 『Symantec NetBackup OpsCenter 7.6 管理者ガイド』

166第 8 章他の NetBackup コンポーネントのチューニングNetBackup for VMware のスナップショットマウントポイントボリュームの割り当てサイズの調整


http://www.symantec.com/docs/DOC5042



167第 8 章他の NetBackup コンポーネントのチューニングSymantec NetBackup OpsCenter


ディスク I/O パフォーマンスのチューニング


■ NetBackup パフォーマンスとハードウェア階層

■ NetBackup パフォーマンスを向上させるハードウェアの例

■ NetBackup パフォーマンスを向上させるために I/O 操作を調整する方法

NetBackup パフォーマンスとハードウェア階層NetBackup パフォーマンスの重要な要因は、ソフトウェアに基づきません。重要な要因はハードウェアの選択と設定です。ハードウェアは、パフォーマンスの決定についてソフ

トウェアの約 4 倍の影響をもたらします。

図 9-1 に、パフォーマンスに影響する主要なハードウェア要素と、それらの間の相互接続 (レベル) を示します。図は、2 つのディスクアレイと単一の非ディスクデバイス (テープ、イーサネット接続など) を示しています。

9

図 9-1 パフォーマンス階層図

レベル 1

レベル 4

レベル 3

レベル 5

レベル 2

アレイ 1

テープ、イーサネットまたは別の

非ディスクデバイス

シェルフ

ドライブ

シェルフ

ドライブ

アレイ 2

シェルフ

ドライブ

シェルフ

ドライブ

ファイバーチャネル


PCIカード 1

PCIカード3

PCIカード 2

PCI ブリッジ PCI ブリッジ

ホストメモリ

PCI バス PCI バスPCI バス

RAIDコントローラ

RAIDコントローラ

シェルフアダプタシェルフアダプタシェルフアダプタシェルフアダプタ

パフォーマンス階層レベルについては、この章の次の項で説明します。

一般に、ディスクとの間でやりとりされるすべてのデータは、ホストメモリを通過する必要が

あります。

図 9-2 はデータがメディアサーバー内でたどるパスを示す破線を含んでいます。

169第 9 章ディスク I/O パフォーマンスのチューニングNetBackup パフォーマンスとハードウェア階層

図 9-2 アレイへの NetBackup メディアサーバーのデータストリーム

レベル 1

レベル 4

レベル 3

レベル 5

レベル 2

アレイ 2

シェルフ

ドライブ


PCI カード

PCI ブリッジ

ホスト

PCI バス

シェルフ

メモリ

RAID コントローラ

ホストメモリ内を移動するデータ

テープ、イーサネットまたは別の

非ディスク

データは右端のイーサネット PCI カードを通って上に移動します。カードは、PCI バスを介し、PCI ブリッジを通してホストメモリにデータを送信します。続いて、NetBackup が適切な場所にこのデータを書き込みます。ディスクの例では、データは 1 つ以上の PCI ブリッジを経由します。それから、1 つ以上の PCI バス、1 つ以上の PCI カード、1 つ以上のファイバーチャネルなどを通過します。

複数の PCI カードを通してデータを送信すると、データが大きいチャンクに分割され、帯域幅が増加します。また、チャンクのグループが複数の宛先に同時に送信されます。た

とえば、1 MB の書き込みは、2 つの異なるアレイに同時に移動する 2 つのチャンクに分割できます。各アレイへのパスが x 帯域幅の場合は、総帯域幅は約 2x になります。

パフォーマンス階層図の各レベルは、データが流れる遷移を表します。これらの遷移に

は帯域幅制限があります。

各レベル間には、パフォーマンスに影響する可能性のある要素もあります。

パフォーマンス階層レベル 1 についてレベル 1 は典型的なディスクアレイ内の相互接続です。レベル 1 は各ディスクシェルフのアダプタに個々のディスクドライブを接続します。シェルフは、ラックに配置される物理

的なエンティティです。シェルフには、通常およそ 15 のディスクドライブが含まれています。ファイバーチャネルドライブを使う場合は、レベル 1 の相互接続は 1 つまたは 2 つのファイバーチャネルアービトレーテッドループ (FC-AL) です。シリアル ATA (SATA) ドライブが使われているときは、レベル 1 の相互接続は SATA インターフェースです。

図 9-3 はパフォーマンス階層レベル 1 を示します。


図 9-3 パフォーマンス階層レベル 1

レベル 1テープ、

イーサネットまたは別の非ディスクデバイス

シェルフ

ドライブ

シェルフアダプタシェルフ

ドライブ

シェルフ

ドライブ

シェルフ

ドライブ

シェルフアダプタシェルフアダプタシェルフアダプタ

レベル 1 の帯域幅の潜在性は、使われている技術によって決まります。

FC-AL では、アービトレーテッドループは 1 Gb または 2 Gb のファイバーチャネルにすることができます。アービトレーテッドループは、共有アクセストポロジーであるため、ルー

プの 2 つのエンティティのみが一度に通信できます。たとえば、1 つのディスクドライブとシェルフアダプタが通信できます。したがって、単一ディスクドライブがデータ転送の 2Gb のバーストに対応できる場合でも、帯域幅は集約されません。つまり、複数のドライブがシェルフアダプタと同時に通信することはできないため、個々のドライブの帯域幅の倍

数になります

パフォーマンス階層レベル 2 についてレベル 2 は、ディスクシェルフの外部の相互接続です。アレイ RAID コントローラに 1 つ以上のシェルフが接続されます。シェルフ内のドライブがファイバーチャネル以外 (たとえば SATA など) の場合でも、この相互接続は通常 FC-AL です。この共有アクセストポロジーでは、ある特定の時点で 1 ペアのエンドポイントのみが通信できます。



レベル 2

アレイ 1 アレイ 2

RAID コントローラRAID コントローラテープ、

イーサネットまたは別の非ディスクデバイスシェルフシェルフシェルフシェルフ

シェルフシェルフシェルフシェルフ

大きいディスクアレイには、複数の内部 FC-AL があります。シェルフは RAID コントローラとすべてのシェルフ間に 2 つのパスがあるように 2 つの FC-AL をサポートすることもできるため、冗長性と負荷分散が提供されます。


パフォーマンス階層レベル 3 についてレベル 3 は、ディスクアレイとホストの外部の相互接続です。



レベル 3

アレイアレイ


ホスト


この図は、アレイとホスト間の 1 つのポイントツーポイント接続を示しています。実環境では通常 SAN ファブリックが (1つ以上のファイバーチャネルスイッチとともに) 含まれています。論理的な結果は同じで、どちらもアレイとホスト間のデータパスです。

これらのパスがアービトレーテッドループでないとき (たとえば、ファブリックファイバーチャネルの場合)、共有アクセストポロジーの制限はありません。つまり、2 つのアレイがファイバーチャネルスイッチに接続され、ホストがスイッチへの単一のファイバーチャネル接続

を備えていることがあります。この場合、アレイは同時に通信できます (スイッチがホストのファイバーチャネル接続との調整を行います)。ただし、ホストはまだ単一のファイバーチャネル接続に制限されるので、この配置では帯域幅は集約されません。

ファイバーチャネルは一般に 1 Gb または 2 Gb です (アービトレーテッドループとファブリックトポロジーの両方)。より速い速度が利用可能です。プロトコルオーバーヘッドを考慮したときの一般的な経験則では、Gb レートを 10 で除算すると、MB/秒単位の概算帯域幅を求めることができます。したがって、1 Gb のファイバーチャネルは理論上およそ 100MB/秒を達成できます。2 Gb のファイバーチャネルは理論上およそ 200 MB/秒を達成できます。

また、ファイバーチャネルは、指定のインターフェースが複数の接続速度をサポートでき

るという点で、従来の LAN に似ています。つまり、2 Gb のファイバーチャネルポートは 1Gb のみをサポートするデバイスにも接続できます。

パフォーマンス階層レベル 4 についてレベル 4 は、PCI カードを接続するためのホスト内部の相互接続です。




レベル 4PCI

カード 1PCIカード3

PCIカード 2

PCI ブリッジ PCI ブリッジPCI バス PCI バス PCI バス

典型的なホストは 2 つ以上の PCI バスをサポートし、各バスが 1 枚以上の PCI カードをサポートします。バスには、2 つのエンドポイントのみが同時に通信できるという点で、FC-AL に似たトポロジーがあります。つまり、PCI バスに 4 枚のカードがある場合は、特定の瞬間にホストと通信できるのは、それらのうちの 1 枚のみです。複数のデータパスが同時に通信でき、総帯域幅が増加するように複数の PCI バスが実装されます。

PCI バスには、帯域幅の潜在性に関連する 2 つの主要要素があります。それは、32 ビットまたは 64 ビットのバスの幅と、バスのクロックまたはサイクル時間 (MHz 単位) です。

一般に、32 ビットバスはクロックあたり 4 バイトを転送でき、64 ビットバスはクロックあたり8 バイトを転送できます。ほとんどの最新の PCI バスは、64 ビットカードと 32 ビットカードの両方をサポートします。

PCI バスは次のクロックレートで利用可能です。

■ 33 MHz

■ 66 MHz

■ 100 MHz (PCI-X とも呼ばれる)

■ 133 MHz (PCI-X とも呼ばれる)

PCI カードにも、さまざまなクロックレート機能があります。

後方互換性は非常に一般的です。たとえば、100 MHz のレートのバスでは、100、66、33 MHz のカードがサポートされます。

同様に、64 ビットバスでは、32 ビットカードと 64 ビットカードの両方がサポートされます。

PCI バスは混在することもできます。たとえば、100 MHz 64 ビットのバスでは、これらの値以下のクロックと幅の任意の組み合わせをサポートできます。

メモ: 共有アクセストポロジーでは、低速なカードが同じバス上の他の高速なカードのパフォーマンスを低下させることがあります。バスは転送ごとに正しいクロックと幅に調整す

るからです。ある時点ではカード #2 に対して 100 MHz 64 ビットの転送が実行され、別の時点ではカード #3 に対して 33 MHz 32 ビットで実行されます。カード #3 への転送の方が低速であるため、完了までの時間が長くなります。失われる時間は、カード #2 との間のより高速なデータ移動に使えたはずのものです。PCI バスは単方向です。1 方向で転送しているときは、他のカードからであっても、他の方向にデータを移動できません。


実世界の帯域幅は、一般に、理論的な最大値 (クロック * 幅) のおよそ 80% です。次に、期待できる帯域幅の概算見積もりを示します。

64 ビット/33 MHz = およそ 200 MB/秒




パフォーマンス階層レベル 5 についてレベル 5 は、ホスト内部の PCI ブリッジとメモリ間の相互接続です。この帯域幅がパフォーマンスの制限要因であることはまれです。



レベル 5

ホストメモリ


パフォーマンス階層に関する注意事項次のとおり、相互接続レベル間のハードウェアコンポーネントも、帯域幅に影響を与える

ことがあります。

■ ドライブには、シークと回転の遅延のための、順次アクセス帯域幅と平均待ち時間が

あります。

ドライブは、ディスクへの順次 I/O を行うときにパフォーマンスが最大になります。不連続 I/O では、ディスクヘッドが強制移動されます (つまり、シークと回転の遅延が発生します)。この動きは、転送されるデータの量に比べて巨大なオーバーヘッドです。不連続 I/O が多いほど低速になります。同時に複数のストリームの読み込みや書き込みを行うと、順次 I/O の短いバーストが、その間に生じるシークと回転の遅延と組み合わされます。この状況により、全体的な

スループットが大幅に低下します。異なる種類のドライブではシークと回転遅延の仕

様が異なります。従って、ドライブの種類は低下の程度に大きく影響します。

このようなドライブとして、最善のものから順にファイバーチャネル、SCSI、SATA があり、SATA ドライブでは通常ファイバーチャネルの 2 倍の遅延が生じます。ただし、SATA ドライブの順次パフォーマンスは、ファイバーチャネルドライブの約 80% です。

■ RAID コントローラには、さまざまなサイズのキャッシュメモリがあります。コントローラでは RAID-5 のパリティ計算も行われます。より高機能なコントローラでは、ハードウェ


アでこの計算 (「XOR」と呼びます) が行われるため、高速になります。ハードウェアで計算が支援されない場合は、コントローラプロセッサで実行する必要がありますが、通

常コントローラプロセッサのパフォーマンスは高くありません。

■ PCI カードは、ポートの速度または PCI バスへのクロックレートによって制限されることがあります。

■ PCI ブリッジは、どのような PCI バスが接続されている場合でも、それを処理するようにサイズ設定されるため、通常は問題になりません。

メモリは、システムに集中的な非 I/O アクティビティがある場合に制限になる場合があります。

パフォーマンス階層図に、ホストプロセッサの CPU がないことに注意してください。

p.169 の図 9-1 を参照してください。

CPU のパフォーマンスはすべてのパフォーマンスに影響しますが、I/O レベルでは非常にわずかな処理しか行われないため、最新システムでは I/O 集中型作業負荷のボトルネックになりません。CPU は、読み込み操作と書き込み操作を実行する必要がありますが、それらの操作は帯域幅の多くを占めません。古いギガビットイーサネットカードが関係

するときは例外です。CPU がネットワーク転送のオーバーヘッドをより多く処理する必要があるからです。

NetBackup パフォーマンスを向上させるハードウェアの例

これらの例はユーザーサイトに対する推奨としては意図されていません。例は NetBackupパフォーマンスに影響を与える可能性のあるさまざまなハードウェア要因を示しています。

例 1

一般的なハードウェア設定は、1 枚の PCI カードにデュアル 2 Gb ファイバーチャネルポートを持ちます。

このような場合、次の文は真です。

■ 潜在的な帯域幅は、およそ 400 MB/秒です。

■ パフォーマンスを最大にするために、カードは少なくとも 66 MHz の PCI スロットに差し込む必要があります。

■ そのバスの他のカードでデータを同時に転送する必要はありません。その 1 枚のカードで PCI バスが飽和します。

■ 同じバスの 2 枚のカード (合計 4 ポート) は、バスとカードが 133 MHz でないかぎり800 MB/秒に集約されません。

例 2

次の例では、ある時点での集約機能に関する帯域幅の潜在性のピラミッドを示します。

175第 9 章ディスク I/O パフォーマンスのチューニングNetBackup パフォーマンスを向上させるハードウェアの例

次のハードウェアがあることを仮定します。

■ 66 MHz クアッド 1 Gb イーサネットが 1 つ

■ 66 MHz 2 Gb ファイバーチャネルが 4 つ

■ 1 Gb ファイバーチャネルポートを持つディスクアレイが 4 つ

■ Sun V880 サーバー (2x 33 MHz PCI バスと 1x 66 MHz PCI バス) が 1 つ

この場合、次は制約がスループットを制限しないようにハードウェアをアセンブルする 1つの方法です。

■ クアッド 1 Gb イーサネットカードは、66 MHz でおよそ 400 MB/秒のスループットを達成できます。

■ 少なくとも 66 MHz バスが必要です。33 MHz バスを使うとスループットがおよそ 200MB/秒に制限されます。

■ 66 MHz バスは完全に飽和します。大量の I/O を必要とする他のカードをそのバスに同時に配置しないでください。

ディスクアレイには 1 Gb のファイバーチャネルポートしかないので、ファイバーチャネルカードはそれぞれ 1 Gb に低下します。


■ したがって、各カードはおよそ 100 MB/秒で移動できます。4 枚のカードがあれば、合計はおよそ 400 MB/秒です。

■ ただし、400 MB/秒をサポートできる単一の PCI バスがありません。66 MHz バスはイーサネットカードによってすでに使われています。

■ 2 つの 33 MHz バスはそれぞれおよそ 200 MB/秒をサポートできます。したがって、2 つのバスそれぞれに 2 枚のファイバーチャネルカードを配置できます。

この設定によって、バックアップまたはリストアではおよそ 400 MB/秒で移動できます。このような設定を実環境で使った結果は、およそ 350 MB/秒になります。

NetBackup パフォーマンスを向上させるために I/O 操作を調整する方法

個々の I/O 操作のサイズは、移動されるデータ量に比べてオーバーヘッドが比較的低くなるように調整する必要があります。NetBackup では、バルク転送操作 (バックアップなど) の I/O のサイズは比較的大きくする必要があります。

I/O 操作の最適なサイズは多くの要因によって決まり、ハードウェアの設定によって大きく異なります。

図 9-8 はパフォーマンス階層図の変形です。

176第 9 章ディスク I/O パフォーマンスのチューニングNetBackup パフォーマンスを向上させるために I/O 操作を調整する方法

図 9-8 アレイごとに単一のシェルフがある階層例

レベル 1

レベル 4

レベル 3

レベル 5

レベル 2

アレイ 1

テープ、イーサネットまたは別の非ディスクデバイス

アレイ 2

シェルフ

ドライブ



PCIカード 1

PCIカード3

PCIカード 2


ホストメモリ

PCI バス PCI バス


シェルフアダプタシェルフ

ドライブ


シェルフアダプタ

PCI バス


■ 各アレイに単一のシェルフがあります。

■ ディスクアレイ内の各シェルフは、8+1 の RAID 5 グループを使うので、9 つのドライブがあります。つまり、8 つのデータディスク + 1 つのパリティディスクです。アレイ内の RAID コントローラは、これらのドライブに対して I/O を実行するときに、ストライプユニットサイズを使います。ストライプユニットサイズが 64 KB であるとわかっていることを仮定します。このストライプユニットサイズは完全なストライプ (8 + 1) を書き込むときに各ドライブに 64 KB を書き込みむことを意味します。非パリティデータの量は、8 * 64 KB、つまり 512 KB です。したがって、アレイの内部では、最適な I/O サイズは 512 KB です。このサイズは、レベル 3 を通過してホストPCI カードに到達するには、I/O を 512 KB で実行する必要があることを意味します。

■ 図では、2 つの別々の PCI バスにある 2 つの別々の RAID アレイを示しています。両方で同時に I/O 転送を実行する必要があります。それぞれが 512 KB で最適な場合は、同時に使われる 2 つのアレイは 1 MB で最適に動作します。


2 つの独立したアレイが 1 つの論理デバイスのように見えるようにするために、ソフトウェア RAID-0 を実装できます。RAID-0 はパリティのないプレーンなストライプです。パリティはドライブエラーから保護し、この設定にはアレイ内部のドライブを保護する

RAID-5 パリティがすでにあります。ソフトウェア RAID-0 は 512 KB のストライプユニットサイズ (各ユニットの I/O サイズ)のために設定されます。それはまた 2 のストライプ幅 (アレイごとに 1) のために設定されます。

1 MB はボリューム (ホストの RAID-0 エンティティ) に最適な I/O サイズです。1MBのサイズは I/O スタックの残り全体に使われます。

■ 可能な場合には、ボリュームにマウントされるファイルシステムに 1 MB の I/O サイズを設定します。

ファイルシステムに対して I/O を実行するアプリケーションも、1 MB の I/O サイズを使います。

NetBackup では、I/O サイズは次の設定 touch ファイルで設定されます。

.../db/config/SIZE_DATA_BUFFERS_DISK.

p.120 の「共有データバッファのサイズを変更する方法」を参照してください。


UNIX と Linux の OS 関連のチューニング要件


■ ファイル記述子の最小数

■ Solaris 10 のカーネルパラメータについて

■ HP-UX のメッセージキューと共有メモリのパラメータ

■ HP-UX のカーネルパラメータの変更

■ Linux のカーネルパラメータの変更

ファイル記述子の最小数NetBackup を効率的に実行できるように、シマンテック社では UNIX と Linux システムのファイル記述子の制限 (ソフトリミット) を 8000 以上に設定することをお勧めします。

『NetBackup 7.5 インストールガイド UNIX および Linux』で UNIX システムと Linux システムのファイル記述子の制限に関する項を参照してください。


Solaris 10 のカーネルパラメータについてSolaris 10 では、すべての System V IPC 機能は自動的に設定されるか、またはリソース管理によって制御できます。共有できる機能はメモリ、メッセージキュー、セマフォです。これらの機能は NetBackup のパフォーマンスに影響する可能性があります。

10


メモ: これらの機能に対する変更は同じ機能を使う他のアプリケーションに影響することがあります。大幅な変更は、パフォーマンスに影響する場合があります。通常、最もよいアプローチは小さな変更を行い結果を監視することです。

これらのシステムリソースのチューニングの情報については、Sun Microsystems 社の『System Administration Guide: Solaris Containers-Resource Management andSolaris Zones』の第 6 章「Resource Controls (Overview)」を参照してください。

Solaris のパラメータの補足について詳しくは、次の場所で入手可能な『Solaris TunableParameters Reference Manual』を参照してください。

http://docs.sun.com/app/docs/doc/819-2724?q=Solaris+Tunable+Parameters

『Solaris Tunable Parameters Reference Manual』の次のセクションが特に役立ちます。

■ Solaris 10 リリースの Solaris システムチューニングの最新情報

■ System V のメッセージキュー

■ System V のセマフォ

■ System V の共有メモリ

特定の Solaris 10 パラメータの推奨NetBackup のパフォーマンスを向上させるために、シマンテック社は Solaris 10 について次を推薦します。

表 10-1 Solaris 10 の推奨事項

説明Solaris 10 の推奨事項

次の設定を使います。

set shmsys:shminfo_shmmax = システムメモリの 2 分の 1

shmmax の設定の変更

シマンテック社は tcp_fusion を無効にすることを推奨します。tcp_fusion が有効になっていると、NetBackup のパフォーマンスは低下し bptm などの処理は断続的に停止することがあります。

p.181 の「tcp_fusion の無効化」を参照してください。

tcp_fusion の無効化

180第 10 章 UNIX と Linux の OS 関連のチューニング要件Solaris 10 のカーネルパラメータについて

http://docs.sun.com/app/docs/doc/819-2724?q=Solaris+Tunable+Parameters

説明Solaris 10 の推奨事項

次のパラメータは Solaris 10 では廃止されています。これらのパラメータは Solaris の /etc/system ファイルに含まれている可能性があり、デフォルトのリソース管理値を初期化す

るために使われます。しかし Sun Microsystems 社ではSolaris 10 での使用を推奨していません。

semsys:seminfo_semmnssemsys:seminfo_semvmxsemsys:seminfo_semmnusemsys:seminfo_semaemsemsys:seminfo_semume

Solaris 10 で廃止されたパラメータに関する注意

tcp_fusion の無効化NetBackup パフォーマンスを向上させるため、tcp_fusion を無効にするには、次の方法のいずれかを使用します。

最初の手順はシステムの再起動を必要としません。ただし、次の再起動で tcp_fusion が再び有効になることに注意してください。システムが再起動されるたびにこれらの手順を

実行する必要があります。

2 つ目の手順はより簡単ですが、システムの再起動が必要です。

注意: この手順を慎重に実行しないと、システムの処理が中断される可能性があります。

モジュラーデバッガ (mdb) を使用する方法

1 バックアップまたはリストアのジョブがアクティブでないとき、次のコマンドを実行しま

す。

echo 'do_tcp_fusion/W 0' | mdb -kw

2 NetBackup の処理を再起動する必要があります。次を入力します。

cd /usr/openv/netbackup/bin/goodies

./netbackup stop

./netbackup start

181第 10 章 UNIX と Linux の OS 関連のチューニング要件Solaris 10 のカーネルパラメータについて

/etc/system ファイルを使用する方法

1 /etc/system ファイルに次の行を追加します。

set ip:do_tcp_fusion = 0

2 変更を反映するためにシステムを再起動します。

HP-UX のメッセージキューと共有メモリのパラメータメッセージキューと共有メモリを処理するカーネルパラメータは HP-UX システムで動作するようにマッピングできます。これらのパラメータは NetBackup のパフォーマンスに影響する可能性があります。

表 10-2 に、HP のカーネルチューニングパラメータ設定のリストを示します。

表 10-2 HP-UX のカーネルチューニングパラメータ

最小値名前 (Name)

1mesg

514msgmap

8192msgmax

65536msgmnb

8msgssz

8192msgseg

512msgtql

256msgmni

1sema

semmni+2semmap

300semmni

300semmns

300semmnu

64semume

32767semvmx

1shmem

182第 10 章 UNIX と Linux の OS 関連のチューニング要件HP-UX のメッセージキューと共有メモリのパラメータ

最小値名前 (Name)

300shmmni

120shmseg

次に示されている式を使って shmmax を計算してください。

p.124 の「推奨される共有メモリ設定」を参照してください。

次のことにも注意してください。

shmmax = NetBackup の共有メモリの割り当て =（SIZE_DATA_BUFFERS * NUMBER_DATA_BUFFERS） * ドライブの数 * ドライブごとの MPX

shmmax

HP-UX のカーネルパラメータの変更HP のカーネルパラメータを変更するには、System Administration Manager (SAM) を使うことができます。

HP-UX のカーネルパラメータを変更する方法

1 SAM で［Kernel Configuration］>［Configurable Parameters］を選択します。

2 変更するパラメータを検索して、[Actions]>[Modify Configurable Parameter]を選択します。

3 新しい値を入力します。

変更するすべてのパラメータに対してこれらの手順を繰り返します。

4 すべての値が変更されたら、[Actions]>[Process New Kernel]を選択します。

警告によって、値を所定の位置に移動するために再起動が必要であることが示され

ます。

5 再起動後、正しい値が設定されていることを確認するために sysdef コマンドを使用できます。

注意: カーネルへの変更では、新しいカーネルを所定の位置に移動するために再起動が必要です。システムを再起動できない場合はパラメータに変更を加えないで

ください。パラメータに変更を加えても、変更は保存されません。

Linux のカーネルパラメータの変更Linux のパフォーマンスのチューニングに多くの設定を利用できます。

183第 10 章 UNIX と Linux の OS 関連のチューニング要件HP-UX のカーネルパラメータの変更

特定の設定と例については次のシマンテック社 TechNote を参照してください。


184第 10 章 UNIX と Linux の OS 関連のチューニング要件Linux のカーネルパラメータの変更


Windows の OS 関連のチューニング要件


■ NetBackup のための Windows のチューニング

■ Windows の I/O パス

■ HBA の固定バインドの使用

■ Windows ソフトウェアに関する推奨事項

■ Windows リムーバブル記憶域サービスの無効化

■ Windows のデバイスドライバの検証の無効化

■ Test Unit Ready 要求の無効化

■ Windows 仮想メモリのスワップファイルのサイズ調整

■ Windows のファイルシステムキャッシュの調整

■ 最終アクセスのタイムスタンプの無効化

■ Windows 8.3 のファイル名の無効化

■ TCP KeepAliveTime パラメータの調整

■ TCPWindowSize とウィンドウスケーリングの調整

■ MaxHashTableSize パラメータの値の増加

■ NumTcbTablePartitions パラメータの値の変更

■ MaxUserPort パラメータの増加

11

■ カーネルスレッド数の増加

■ CPU 親和性の設定

■ Windows のデータバッファサイズについて

■ Windows のデータバッファサイズの調整

■ Windows の NetBackup 設定ファイルの要件

NetBackup のための Windows のチューニングWindows には NetBackup のパフォーマンスに影響を与える可能性のあるチューニングパラメータがあります。一部のデフォルト値は I/O 負荷が高い場合に適していません。

I/O パスはバックアップ効率のための重要事項です。インフラに負荷をかけることを避け、バックアップ処理時間帯を最低限に保つために、データの移動方法を最適化する必要

があります。また、データの効率的なリストア方法、つまりテープとディスクからの高速 I/Oの必要性も重要です。

次のサイトは Windows システムのチューニングに関する追加情報を提供します。この情報は NetBackup のチューニングで役立ちます。

Windows Server 2003 のパフォーマンスチューニングガイドライン

Windows Server 2008、2008 R2、2012 のパフォーマンスチューニングガイドライン

Windows の I/O パスNetBackup では、サーバーのバックプレーンのスループットが最大限に向上するようにI/O パスを設計する必要があります。通常、データ I/O はネットワークインターフェースを通って CPU に入り、テープドライブかディスクに進みます。

着信トラフィックでは複数のネットワークインターフェースを使います。そのため、IEEE802.3ad リンク集約を許可するようにネットワークスイッチを設定する必要がありません。スイッチで着信パケットを分散して帯域幅を十分に活用できるようにします。

一般に、ホスト型のチーミングではフェールオーバーとアウトバウンドトラフィックの負荷分

散のみがサポートされます。 NetBackup では、アウトバウンドトラフィックの負荷分散が役立つことはほとんどありません。ただし、メディアサーバー間のデータを Vault 処理する場合、または PureDisk、NetApp、Data Domain のようなネットワークベースのディスクプールアプライアンスの場合は除きます。

SAN 接続のための HBA に関しては、ディスクとテープの I/O を分割する必要があります。テープ I/O は同期的であるため、ディスク I/O が著しく低下する可能性があります。また、複数の HBA ポートを使ってトラフィックをテープドライブに分散してください。たとえば、4 Gb HBA ポートは 4 つまでの LTO3 ドライブに対応できます。しかし実際には、

186第 11 章 Windows の OS 関連のチューニング要件NetBackup のための Windows のチューニング

https://docs.google.com/viewer?a=v&q=cache:w-FslisWr98J:download.microsoft.com/download/2/8/0/2800a518-7ac6-4aac-bd85-74d2c52e1ec6/tuning.doc+Performance+Tuning+Guidelines+for+Windows+Server+2003&hl=en&gl=us&pid=bl&srcid=ADGEESgJdB9BB3BzaiAPb1UBcxaz56ph6FdmJQqwbPnUhgyHoKTXBCM6STlmYlhwAuGD_L64pko5fRb-iePzKWRExBYhLdEx1wLhAZAi250ITy046XoP8JLFwlja6e8TGSpoCmnjM0Zs&sig=AHIEtbS9Nj5Vn0zznK8ShpLx_dmds06lPw

http://msdn.microsoft.com/en-us/windows/hardware/gg463392.aspx

I/O 割り込み処理やその他のハードウェアとカーネルの制約が原因で、ポートごとに最大2 つのドライブの方が適切に機能します。もし可能なら、複数のシングルポート HBA をサーバーの利用可能な I/O スロットに分散します。通常、この構成ではバックプレーン、CPU、メモリの I/O の分散が改善します。

HBA の固定バインドの使用Windows カーネルの問題を避けるには、各 HBA を固定バインドで構成します。パスが消えてから再度有効になった場合、またはサーバーが再起動された場合は、カーネルに

よって新しい内部パス名が割り当てられます。その結果、NetBackup で使われるパスが機能しなくなります。 NetBackup のデバイスモニターに［パスが不明です（MISSING PATH）］というメッセージが表示されます。

HBA のベンダーは HBA の設定を構成するための独自のツールを用意しています。固定バインドの構成時には、ベンダーのマニュアルを参照してください。

Windows ソフトウェアに関する推奨事項表 11-1 に、NetBackup のパフォーマンスを改善できる Windows ソフトウェアに関する推奨事項を示します。

表 11-1 NetBackup のパフォーマンスを改善するためのソフトウェアに関する推奨事項

注意事項推奨事項

すべての適用可能な更新プログ

ラムを使って Windows 2003 をバージョン R2 に更新する。

ソフトウェアはそれぞれのベンダーが提供する最新の推奨バー

ジョンを使ってください。

ディスクまたはテープドライブを

SAN 接続する場合に SAN 接続のための追加のソフトウェアをイン

ストールする。

187第 11 章 Windows の OS 関連のチューニング要件HBA の固定バインドの使用

注意事項推奨事項

ウイルス対策アプリケーションは NetBackup がバックアップするすべてのファイルをスキャンするため、クライアント CPU に負荷がかかります。その結果、バックアップ速度が遅くなる可能性があります。 Windows のウイルス対策ソフトウェアを無効にすることを考慮してください。

代替として、ウイルス対策のスキャンを有効にしたまま、回避す

ることができます。

■ バックアップ、アーカイブおよびリストアインターフェースの

［NetBackup クライアントのプロパティ（NetBackup ClientProperties）］ダイアログボックスの［一般（General）］タブで、［アーカイブビットに基づいて、増分バックアップを実行

する（Perform incrementals based on archive bit）］のチェックボックスのチェックマークをはずします。

■ NetBackup のプロセスとディレクトリを除外するようにウイルス対策ソフトウェアを設定します。

シマンテック社の次の TechNote で、ウイルス対策ソフトウェアで NetBackup のディレクトリとプロセスを除外する方法を説明しています。

http://www.symantec.com/docs/TECH152328http://www.symantec.com/docs/TECH56658

NetBackup が動作しているときはWindows のウイルス対策ソフトウェアを無効にするか、または再

設定する。

Windows リムーバブル記憶域サービスの無効化多くのサービスは Windows サーバーで自動的に開始されます。そのまま安全に開始できるものもありますが、リムーバブル記憶域サービスは常に無効にする必要があります。

このサービスは NetBackup のデバイス管理と干渉します（このトピックの手順を参照してください）。

リムーバブル記憶域サービスが無効になった後、システムイベントビューアのログに DCOMエラーが記録されることがあります。次の TechNote でこのエラーの回避策を説明しています。


注意: NetBackup サーバーをバックアップするとき、bpbkar プロセスはリムーバブル記憶域サービスが動作していないのでエラーをログに記録します。この問題を修正するには、バックアップから <system_drive>:¥WINDOWS¥system32¥ntmsdata ディレクトリを除外します。次の TechNote でディレクトリを除外する方法を説明しています。


188第 11 章 Windows の OS 関連のチューニング要件Windows リムーバブル記憶域サービスの無効化





リムーバブル記憶域サービスを無効にする方法

1 ［スタート］、［管理ツール］、［サービス］の順にクリックします。

2 リムーバブル記憶域サービスをダブルクリックしてプロパティを開きます。

3 サービスが実行中の場合は、［停止］をクリックしてサービスを停止します。

4 ［スタートアップの種類］を［無効］に変更し、［OK］をクリックします。

Windows のデバイスドライバの検証の無効化ネットワークアダプタと HBA ではサポートされている最新のデバイスドライバとファームウェアの組み合わせを使ってください。ほとんどのディスクドライブはほぼ最適なデフォルト設定で提供されています。

デフォルトでは、Windows 2003 と 2008 はデバイスドライバをランダムにテストします。そのテスト機能を無効にすることによってパフォーマンスを改善できます。無効にしないと、カーネルはドライバを繰り返しテストして不必要な時間を使います。

デバイスドライバのテストを無効にするには、次のレジストリパラメータを使います。レジストリパラメータは Windows 2003 と 2008 に適用されます。このマニュアルの作成時点では、この機能の無効化が Windows 2008 R2 で必要かどうかは不明です。

表 11-2 デバイスドライバのテストを無効にするパラメータ: Windows 2003 と2008

推奨値Windows のレジストリパラメータ（DWORD）

1HKLM¥SYSTEM¥CurrentControlSet¥Control¥Session Manager¥MemoryManagement¥DontVerifyRandomDrivers

Windows のデバイスドライバの検証を無効にする方法

1 Windows サーバーで、［スタート］、［ファイル名を指定して実行］の順にクリックし、regedit と入力します。

2 念のために、現在のレジストリのバックアップを作成します (［ファイル］>［エクスポート］)。

3 HKLM¥SYSTEM¥CurrentControlSet¥Control¥Session Manager¥MemoryManagement に移動し、DontVerifyRandomDrivers という DWORD を作成します。

4 新しい DWORD を右クリックし、［修正］を選択して、値として 1 を入力します。

5 ［OK］をクリックします。

6 レジストリエディタを終了し、システムを終了して再起動します。

189第 11 章 Windows の OS 関連のチューニング要件Windows のデバイスドライバの検証の無効化

Test Unit Ready 要求の無効化複数のメディアサーバー間で共有されるテープドライブが構成された SAN 上にテープライブラリがある場合は、テープデバイスドライバの Test Unit Ready（TUR）機能を無効にします。手順については、次の Microsoft 社の記事を参照してください。

Windows Server 2003 はストレージエリアネットワーク上のテープデバイスに対してバックアップジョブを実行できません。

http://support.microsoft.com/kb/842411

TUR 要求は、テープドライブのために Shared Storage Option（SSO）を使うときにNetBackup に影響します。 SSO と TUR を使うと、Windows メディアサーバーがドライブに SCSI コマンドを送信して、準備ができているかどうかを調べる可能性があります。SSO 構成では、別のホストがテープドライブを必要とする場合があり、別のサーバーから送信される SCSI コマンドは干渉します。その結果、バックアップ操作とリストア操作で、パフォーマンスの低下やさらにはエラーなどの問題が発生します。

Windows 仮想メモリのスワップファイルのサイズ調整NetBackup をインストールする前に、Windows 仮想メモリのスワップファイルのサイズを正しく調整することが重要です。一般に、スワップファイルのサイズは物理メモリの少なくとも 2 倍にすることをお勧めします。スワップファイルはそのサイズに事前設定し、自動的に拡張されないようにする必要があります。

スワップファイルが自動的に拡張される場合、メモリの I/O 操作は拒否され、NetBackupでジョブの失敗（通常は状態 81）が報告されます。このエラーにより、メディアサーバーのバックアップジョブは事実上中止されます。 Windows では、スワップファイルのサイズを事前に調整することでしかこの問題は回避できません。

Windows のファイルシステムキャッシュの調整Windows 2003 はデフォルトでファイルサービス向けに最適化されています。Windowsはメモリでファイルシステムキャッシュを優先します。データを直接テープ、NAS デバイス、その他の OpenStorage デバイスに送信しているメディアサーバーでは、表 11-3 に示すパラメータを使用してカーネルを最適化した方がよい場合があります。

メモ: ベーシックまたはエンタープライズ形式のディスクストレージユニットを使用するメディアサーバーは、デフォルト設定を使用した方がよい場合があります。

次のレジストリ変数を使用してファイルシステムキャッシュをチューニングできます。

190第 11 章 Windows の OS 関連のチューニング要件Test Unit Ready 要求の無効化

http://support.microsoft.com/kb/842411

表 11-3 Windows のファイルシステムキャッシュを調整するレジストリパラメータ

備考推奨値Windows のレジストリパラメータ (DWORD)

デフォルトは 3 で、ファイル共有とネットワークアプリケーションの両

方のスループットを最大にします。

3HKLM¥System¥CurrentControlSet¥Services¥LanmanServer¥Parameters¥Size

LargeSystemCache 変数を 0 に設定してファイルシステムキャッ

シュを最小にし、ネットワークアプ

リケーションでより多くのメモリを使

用できるようにします。

8 GB 以上などの大量のメモリを持つサーバーでは、これらの両方

の設定を変更しなくてよい場合が

あります。

0HKLM¥System¥CurrentControlSet¥Control¥Session Manager¥Memory Management¥LargeSystemCache

レジストリ値を変更する方法の手順については、次の項を参照してください (レジストリパス、パラメータ名、値については、適切なものに置き換えてください)。

p.189 の「Windows のデバイスドライバの検証の無効化」を参照してください。

最終アクセスのタイムスタンプの無効化NTFS ファイルシステムでは個々のファイルやディレクトリに最後にアクセスした時刻が記録されます。最後にアクセスした時刻を記録すると、追加の I/O 操作が発生します。カタログデータベースには数千から数百万のファイルが含まれているため、カーネルが各ファ

イルのアクセスを更新するとオーバーヘッドが増大します。

一部の監査ポリシーは最終アクセス情報を必要としません。最終アクセス情報を無効に

すると、NetBackup マスターサーバーでよい効果を得られます。

表 11-4 最終アクセスのタイムスタンプを無効にするパラメータ

推奨値Windows のレジストリパラメータ (DWORD)

1

(最終アクセスのタイムスタンプを無

効にします。)

HKLM¥SYSTEM¥CurrentControlSet¥Control¥FileSystem¥NTFSDisableLastAccessUpdate


191第 11 章 Windows の OS 関連のチューニング要件最終アクセスのタイムスタンプの無効化


Windows 8.3 のファイル名の無効化NTFS ファイルシステムは、古いオペレーティングシステムとの互換性を保つためにすべてのファイルの短縮名を保持します。この設定は NetBackup マスターサーバーには必要ありません。無効にすることによって、ファイルの作成ごとの I/O 操作の数を減らします。

メモ: 8.3 のファイル名を無効にしたら、マスターサーバーで 16 ビットアプリケーションが実行されていないことを確認します。

表 11-5 8.3 形式のファイル名を無効にするパラメータ


1HKLM¥SYSTEM¥CurrentControlSet¥Control¥FileSystem¥NTFSDisable8dot3NameCreation

レジストリ値を変更する方法については、次のトピックを参照してください（適切なレジスト

リパス、パラメータ名、値を代入してください）。


TCP KeepAliveTime パラメータの調整いくつかの TCP パラメータをチューニングして NetBackup の一般的な I/O により適切に対応することができます。通常、Windows サーバーの I/O パターンは、継続的なデータ転送ではなく I/O の短いバーストです。

特定の状況で、メディアサーバーへの接続が中止されたことが NetBackup マスターサーバーで検出されるまでに、遅延が起きることがあります。たとえば、バックアップ時にメディアサーバーが停止した場合、メディアサーバーが利用できなくなったことがマスターサー

バーで検出されるまでに、遅延が起きることがあります。最初は NetBackup マスターサーバーに問題があるように見えるかもしれませんが、この遅延は KeepAliveTime というTCP/IP 構成パラメータが原因です。デフォルトでは、このパラメータは 7,200,000 ミリ秒（2 時間）に設定されています。値を 900,000 ミリ秒（15 分）に減らしてください。

この遅延によって、メディアサーバーへの接続が切断された後も、メディアサーバー上で

NetBackup ジョブが実行中であるように見えます。その結果、現在のバックアップジョブが失敗して NetBackup の再試行処理が開始されるまでに、望ましくない遅延が発生します。

I/O パスがファイアウォールを含んでいる場合は、タイムアウトの遅延を短くすることも必要になる場合があります。ファイアウォールは、安全なネットワークで、または DMZ や信頼

192第 11 章 Windows の OS 関連のチューニング要件Windows 8.3 のファイル名の無効化

できないネットワークに配置されているサーバーをバックアップするときによく使われます。

ファイアウォールは通常、トラフィックが一定の時間起きなければセッションをドロップしま

す。 NetBackup が適切に応答せず、ジョブは失敗します。この問題は通常、増分バックアップ時にクライアントがメディアサーバーにデータを送るのに長時間かかる可能性が

あるときに起きます。この問題を解決するには、KeepAliveTime をファイアウォールのタイムアウトより低い値に設定します。

表 11-6 KeepAliveTime のパラメータ


0xDBBA0

（= 900,000 ミリ秒、つまり 15 分）

HKLM¥SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters¥KeepAliveTime

TCP KeepAliveTime の遅延を減らす方法

1 Windows サーバーで、［スタート］、［ファイル名を指定して実行］の順にクリックし、regedit と入力します。

2 念のために、現在のレジストリのバックアップを作成します (［ファイル］>［エクスポート］)。

3 HKLM¥SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters¥ に移動し、KeepAliveTime という DWORD を作成します。

4 新しい DWORD を右クリックし、［修正］を選択して、値として 1 を入力します。



TCPWindowSize とウィンドウスケーリングの調整TCPWindowSize パラメータは可能なかぎり最大の TCP 受信ウィンドウを決定します。Windows 2003 では、ギガビットネットワークインターフェースの TCPWindowSize パラメータは最大値の 65535 に設定する必要があります。

メモ: Windows 2008 と 2008 R2 では、このパラメータは廃止されており、カーネルによって無視されます。

表 11-7 Windows 2003: TCPWindowSize を調整するパラメータ

推奨値（10 進数）

Windows 2003 のレジストリパラメータ（DWORD）

65535HKLM¥SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters¥TcpWindowSize

193第 11 章 Windows の OS 関連のチューニング要件TCPWindowSize とウィンドウスケーリングの調整

TCPWindowSize 変数は 1 GB の値まで増やすことができます。この変数を設定してシステムを再起動すると、TCP/IP スタックは大きいウィンドウをサポートするようになります。

Windows 2003 では、TCP ウィンドウスケーリングで 64 KB より大きい TCP 受信ウィンドウを許可することも役立ちます。 TCP ウィンドウスケーリングの調整が必要ないこともあります。試行錯誤を重ねて、次のパラメータで I/O のスループットが改善されるかどうかを判断してください。

表 11-8 Windows 2003: TCP ウィンドウスケーリングを調整するパラメータ

推奨値Windows 2003 のレジストリパラメータ（DWORD）

1HKEY_LOCAL_MACHINE¥System¥CurrentControlSet¥Services¥Tcpip¥Parameters¥Tcp1323Opts

メモ: TCPWindowSize と同様に、Tcp1323Opts は Windows 2008 と 2008 R2 では非推奨です。

レジストリ値を変更する方法については、次のトピックを参照してください（適切なレジスト

リパス、パラメータ名、値を代入してください）。


MaxHashTableSize パラメータの値の増加MaxHashTableSize 変数を高い値に設定すると役立つ場合があります。高い値を使用すると、ディスクへの高い多重化、ディスクへの多数の同時セッションなど、多くの接続が

同時に発生するメディアサーバーで役立つことがあります。デフォルトは 128 * CPU2 です。最大値は 65535 (DWORD) です。

メモ: Windows 2008 と 2008 R2: このパラメータは廃止されていてカーネルによって無視されます。

表 11-9 Windows 2003: MaxHashTableSize パラメータ

推奨値 (10 進数)

Windows 2003 のレジストリパラメータ (DWORD)

65535HKEY_LOCAL_MACHINE¥System¥CurrentControlSet¥Services¥Tcpip¥Parameters¥MaxHashTableSize



194第 11 章 Windows の OS 関連のチューニング要件MaxHashTableSize パラメータの値の増加

NumTcbTablePartitions パラメータの値の変更この変数はデフォルトで CPU2 で計算されます。この設定は 8 個以上の CPU を搭載するサーバーには適さない場合があります。ほとんどの大規模サーバーでは CPU 数の 4倍の値を使用する方がよい効果が得られます。

メモ: Windows 2008 と 2008 R2: このパラメータは廃止されていてカーネルによって無視されます。

表 11-10 Windows 2003: NumTcbTablePartitions パラメータ



16HKLM¥SYSTEM¥CurrentControlSet¥Services¥Tcpip¥Parameters¥NumTcbTablePartitions



MaxUserPort パラメータの増加IP アドレスあたりのポートのデフォルト値はわずか 5000 です。大規模な NetBackup ドメインでは、マスターサーバー、メディアサーバー、クライアント間で必要となるすべての

接続に対し、5000 個のポートでは足りない場合があります。一般に、この値を増やすとよい効果を得られるのは、マスターサーバーとメディアサーバーのみになります。クライアン

トが Web サーバーやデータベースサーバーの役割を果たしている場合などは、クライアントでもよい効果を得られることがあります。

Windows 2003 は IP アドレスあたり 65534 までの同時ポートをサポートします。MaxUserPort パラメータはデフォルトで存在しないため、手動で作成する必要があります。最初の 1024 個のポートは予約されているため、最大値に設定することはあまり意味がありません。ホストで 60000 を超える接続が同時に発生する場合、別の問題が存在する可能性があります。たとえば、CPU とディスクのボトルネックです。ただし、60000 の値を使用すれば十分対応可能です。

表 11-11 Windows 2003: MaxUserPort パラメータ



60000HKEY_LOCAL_MACHINE¥System¥CurrentControlSet¥Services¥Tcpip¥Parameters¥MaxUserPort

195第 11 章 Windows の OS 関連のチューニング要件NumTcbTablePartitions パラメータの値の変更



Windows 2008 と 2008 R2 では使用可能なポートを増やす手順が異なります。netshコマンドを使用して開始ポートと範囲を設定してください。デフォルトで、開始ポートは

49152、終了ポートは 65535 で、これにより使用可能な動的ポートが 16383 個提供されます。NetBackup 環境が非常に大規模である場合は、範囲を大きくする必要がある場合があります。60000 の接続を可能にするには、次のコマンドを入力します。

netsh int ipv4 set dynamicport tcp start=10000 num=50000

netsh int ipv4 set dynamicport udp start=10000 num=50000

netsh int ipv6 set dynamicport tcp start=10000 num=50000

netsh int ipv6 set dynamicport udp start=10000 num=50000

UDP ポートは TCP と同じ範囲を持つように設定されますが、NetBackup は UDP ポートを使用しません。

カーネルスレッド数の増加Windows ではデフォルトで多数の同時スレッドに対応するようにカーネルを最適化していません。OS が起動されると、カーネルは実行中のプロセスに必要な作業を行うカーネルワーカースレッドに構造体を割り当てます。たとえば、ドライバ I/O、カーネル自体、その他の内部コンポーネントです。

NetBackup はマスターサーバーとメディアサーバーに非常に高い負荷をかけます。個々の実行中のジョブ向けにサーバーで多数のプロセスを開始します。およそ 300 のクライアントを持つドメインに存在するマスターサーバーは、Windows がデフォルトで作成するすべてのカーネルスレッドを必要とする場合があります。

場合によっては、長時間かけてバックアップジョブを分散し、デフォルト値を超えないス

レッドで対応することができます。ただし、実行できない場合もあります。代わりに、カーネ

ルスレッドを最大数まで増やすことにより、カーネルが可能な限り多くのプロセスを処理す

るようにできます。

次の Windows パラメータを使用します。

■ DefaultNumberofWorkerThreads

■ AdditionalDelayedWorkerThreads

■ AdditionalCriticalWorkerThreads

表 11-12 に、これらのパラメータを示します。

3 つの変数はすべて DWORD 形式を使用します。AdditionalDelayedWorkerThreads変数と AdditionalCriticalWorkerThreads 変数はすでに存在している必要があります。

196第 11 章 Windows の OS 関連のチューニング要件カーネルスレッド数の増加

表 11-12 カーネルスレッドパラメータ (DWORD)

説明推奨値 (10進数)

Windows のレジストリパラメータ (DWORD)

カーネル内の各作業キューに割り当てられた

スレッドの数を制御します。

RpcXdr¥Parameters¥DefaultNumberofWorkerThreads のパスと変数を作成する必要がある場合があり

ます。

メモ: スレッドを多く割り当てすぎると、適量を超えるシステムリソースが使用される場合が

あります。

64HKLM¥SYSTEM¥CurrentControlSet¥Services¥RpcXdr¥Parameters¥DefaultNumberofWorkerThreads

リアルタイムまたは時間重視ではない作業に

使用します。このスレッドのメモリページは、

キューに配置されている間、CPU キャッシュとメモリからスワップアウトされる場合がありま

す。

16HKLM¥SYSTEM¥CurrentControlSet¥Control¥ SessionManager¥Executive¥AdditionalDelayedWorkerThreads

メモリページを CPU キャッシュやメモリに維持する必要のある、優先度が高い時間重視

のプロセスに使用します。

16HKLM¥SYSTEM¥CurrentControlSet¥Control¥ SessionManager¥Executive¥AdditionalCriticalWorkerThreads



CPU 親和性の設定多くの CPU を搭載するメディアサーバーでは、ネットワーク I/O に特定の CPU を割り当ててテープ I/O またはディスク I/O に他の CPU を割り当てることによって、I/O のスループットを改善できます。このような割り当ては CPU（またはプロセッサ）親和性と呼ばれます。

CPU 親和性によって、OS スレッドスケジューラは不必要なコンテキストの切り替えを避けるようになります。代わりに、さまざまな I/O スレッドがそれぞれの CPU に置かれます。コンテキストの切り替えとメモリページフォルトは、NetBackup のような I/O 負荷の高いアプリケーションでは非常に負荷がかかります。

CPU 親和性は、Windows 2003 Resource Kit Tools の割り込みアフィニティフィルターツール（intfiltr.exe）によって設定できます。

197第 11 章 Windows の OS 関連のチューニング要件CPU 親和性の設定

注意: このツールを使う場合は十分に注意してください。

intfiltr.exe ツールは物理コンソールから使います。

intfiltr.exe ツールでは、システムに存在するさまざまなデバイスを選択できます。ネットワークデバイスを選択し、割り込みフィルタに追加します。

サービスの中断またはシステムクラッシュを避けるために、フィルタに追加する前に［変更

時にデバイスを再起動しない（Don't Restart Device when Making Changes）］を選択しなければならないことがあります。

デバイスがフィルタに追加されたら、［割り込みアフィニティのマスク（Interrupt AffinityMask）］ボックスの［マスクの設定（Set Mask）］ボタンをクリックして CPU マスキングを設定できます。

メモ: 一部のデバイスは親和性の設定を行うと動作しないことがあります。再起動が必要になる場合があります。再起動後にデバイスが動作しない場合は、フィルタを削除してください。その場合、そのデバイスでは CPU 親和性を使うことができません。

Windows 2008 では、intfiltr.exe ツールは割り込みアフィニティポリシー（IntPolicy）ツールに置き換えられています。詳しくは次の Microsoft 社の文書を参照してください。

割り込みアフィニティポリシーツール

http://msdn.microsoft.com/en-us/windows/hardware/gg463378

Windows 2008 R2 では、NUMA（Non-Uniform Memory Access ）アーキテクチャによってリソースをより的確に制御できます。高いパフォーマンスを要求するアプリケーションは、スレッドが複数のコアに分散されるか、または CPU で管理されるように設計されています。一般に、局所性の原則によって CPU で行われるコンテキストの切り替えは少なくなります。

Windows のデータバッファサイズについてWindows のデータバッファのサイズの限度は 1024 KB です。このサイズは、オペレーティングシステムのページの倍数（1 ページ = 4 KB）で計算されます。したがって、最大は 0 から 255（16 進値では 0xFF）までの 256 OS ページです。これより大きい値を設定すると、デフォルトで 64 KB に設定されます。これは分散収集リストのデフォルトのサイズです。

最大使用可能ブロックサイズはテープドライバや OS ではなく HBA （Host Bus Adapter）のミニポートドライバに依存します。たとえば、QLogic QLA2200 カードの Readme には次が含まれます。

* MaximumSGList

198第 11 章 Windows の OS 関連のチューニング要件Windows のデータバッファサイズについて

http://msdn.microsoft.com/en-us/windows/hardware/gg463378

Windows は非常に大きな SCSI I/O 転送を実行するために拡張された分散収集リストサポートを含みます。 Windows はそれぞれ 4096 バイトの分散収集セグメントを 256個までサポートし、1048576 バイトまでの転送を可能にします。

メモ: OEMSETUP.INF ファイルは 65 個の分散収集セグメントをサポートするために自動的にレジストリを更新するように更新されました。通常、追加の変更は必要ありません。この設定で全体的なパフォーマンスが最適になります。

SGList (分散収集リスト) のレジストリ値SGList のレジストリパラメータは 1 回の DMA 転送で分散または収集できる (つまり、読み込みまたは書き込みができる) ページ数を設定します。QLA2200 では、パラメータMaximumSGList を 0xFF (または 256 KB の場合は 0x40) に設定し、それからNetBackup で 256 KB バッファサイズを設定できます。このレジストリ値を修正するときには十分に注意してください。特定のカードでサポートされる最大値を確認するには、ま

ず SCSI またはファイバーチャネルカードのベンダーに連絡してください。

他の HBA (特にファイバーチャネルカード) でも同じようにできます。

ドライババージョン 1.16 を使用する JNI ファイバーカードのデフォルトは 0x80 (512 KB、つまり 128 ページ) です。Emulex LP8000 のデフォルトは 0x81 (513 KB、つまり 129ページ) です。

このアプローチが機能するには、HBA 自体の SCSI ミニポートドライバをインストールする必要があります。そうしないと、古い SCSI カードのようなレガシーカードの転送は 64KB に制限されます。

レガシーカードでデフォルトの Microsoft ミニポートドライバを使用しない限り、Windowsの組み込み制限は 1024 KB です。制限事項は HBA ドライバとそれらに接続する物理デバイスの制限と関連します。

たとえば、Quantum DLT7000 ドライブは 128 KB バッファ、StorageTek 9840 ドライブは 256 KB バッファが最適です。これらの値が極端に増加すると、損傷が発生する可能性があります。HBA かテープドライブまたは中間のデバイス (ファイバーブリッジ、スイッチなど) が損傷する可能性があります。

Windows のデータバッファサイズの調整Windows のデータバッファサイズを次の通り調整できます。

199第 11 章 Windows の OS 関連のチューニング要件Windows のデータバッファサイズの調整

Windows のデータバッファサイズを変更する方法

1 ［スタート］ > ［ファイル名を指定して実行］をクリックし、REGEDT32 プログラムを開きます。

2 ［HKEY_LOCAL_MACHINE］を選択し、次のようにツリー構造をたどって HBA ドライバに進みます。

［HKEY_LOCAL_MACHINE］ > ［SYSTEM］ > ［CurrentControlSet］ > ［Services］>［HBA_driver］> ［Parameters］ > ［Device］

QLogic の場合、HBA_driver は Ql2200 です。

3 SGList パラメータを調整します。

次の手順を実行します。

■ ［MaximumSGList: REG_DWORD: 0x21］をダブルクリックします。

■ 16 から 255 （16 進法では 0x10 から 0xFF）までの値を入力します。255 （0xFF）の値で最大 1 MB の転送サイズを有効にします。値を 255 より高く設定するとデフォルトの 64 KB の転送に戻ります。デフォルト値は 33 （0x21）です。

このパラメータについて詳しくは次を参照してください。

p.199 の「SGList (分散収集リスト) のレジストリ値」を参照してください。



Windows の NetBackup 設定ファイルの要件Windows の NetBackup 設定ファイルについて、次の要件に注意してください。

■ Windows で NetBackup の設定ファイルを作成する場合、ファイル名は NetBackupが予測するファイル名と一致する必要があります。

ファイル名に .txt などの拡張子を含めないようにしてください（UNIX システムでは、このようなファイルは touch ファイルと呼ばれます）。バックアップの期限切れを防ぐために NOexpire ファイルを作成した場合、ファイルの名前が NOexpire.txt であると、そのファイルは機能しません。

■ 設定ファイルでは、ANSI などのサポート対象のエンコードの種類を使う必要があります。 Unicode エンコードはサポートされません。ファイルが Unicode の場合は、機能しません。

エンコードの種類を調べるには、現在のエンコードを表示するメモ帳などのツールを

使ってファイルを開きます。［ファイル］ > ［名前を付けて保存］を選択し、［文字コード］フィールドのオプションを調べます。 ANSI エンコードは正しく機能します。

200第 11 章 Windows の OS 関連のチューニング要件Windows の NetBackup 設定ファイルの要件

追加のリソース

この付録では以下の項目について説明しています。

■ NetBackup のチューニングとパフォーマンスに関する追加のリソース

NetBackup のチューニングとパフォーマンスに関する追加のリソース

チューニングとパフォーマンスに関する追加のディスカッションやリソースについては、次

のシマンテック社の Web サイトを参照してください。

■ Symantec NetBackup のリリースノート、管理者ガイド、インストールガイド、トラブルシューティングガイド、スタートガイド、ソリューションガイド

http://www.symantec.com/docs/DOC5332サポートされるすべての NetBackup リリースの最新製品マニュアルをダウンロードし、サポート技術情報で詳細を検索できます。

■ Symantec Connecthttp://www.symantec.com/connect/backup-and-recovery特定の問題を検索し、シマンテック社のサポート担当者やお客様とのトピックに関す

るディスカッションに参加できます。

■ Vision User Conference Communityhttp://www.symantec.com/connect/visionシマンテック社の Vision User Conference のプレゼンテーション、ビデオ、ブログ、ディスカッションを参照できます。

A


http://www.symantec.com/connect/backup-and-recovery

http://www.symantec.com/connect/vision

記号1 クライアントあたりの最大ジョブ数 (Maximum jobs per

client) 45［1 クライアントあたりの最大ジョブ数（Maximum Jobs Per

Client）］属性 106

AAdvancedDisk 74ALL_LOCAL_DRIVES 36、58ANSI エンコード 200ATA 23available_media スクリプト 63、69available_media レポート 69［Avg. Disk Queue Length］カウンタ 100

BBare Metal Restore (BMR) 161bp.conf ファイル 65bpbkar 108、128、133bpbkar32 108、128bpbkar ログ 93～94bpdm ログ 92bpend_notify.bat 108bpmount -i 58bprd 43bpsetconfig 160bpstart_notify.bat 108bptm 128、133、137、141、143bptm ログ 65、92

CCHILD_DELAY ファイル 127Client Job Tracker 163Committed Bytes 99COMPRESS_SUFFIX オプション 160CPU 97

パフォーマンス 175負荷

監視 97

Ddaily_messages ログ 60DB2 リストア 148devfsadmd デーモン 66devlinks 66diskperf コマンド 99［Disk Queue Length］カウンタ 100［Disk Time］カウンタ 100drive_error_threshold 64、66drvconfig 66

EEMM 47、58、63、68、75

ドライブの選択 67

FFBU_READBLKS 165FC-AL 170、173FlashBackup 162、164FlashBackup の読み込みバッファ 165FT メディアサーバー

共有メモリ 118、120～121バッファの推奨数 125

GGb ファイバーチャネル 23globDB 30goodies ディレクトリ 69

II/O 操作

調整 176iostat ユーティリティ 96iSCSI 23iSCSI バス 63

JJava インターフェース 38、161Job Tracker 108

索引

Llogs 65、162Log Sense ページ 76ltidevs 30

MMaximumSGList 198、200media

エラーのしきい値 63～64カタログ 64プール 68利用不可 63

mediaDB 30media_error_threshold 64、66Media Server Encryption Option (MSEO) 158MEGABYTES_OF_MEMORY 159Mode Select ページ 76Mode Sense 76modload コマンド 67MPX_RESTORE_DELAY オプション 148MSEO 158MTFSF/MTFSR 143

Nnamespace.chksum 30NBDB.log 54NBDB データベース

6.0 以前のデータベースから導出される 30必要な容量の計算 30

NBDB トランザクションログ 31nbemmcmd コマンド 64nbjm とジョブの遅延 47nbpem とジョブの遅延 44nbu_snap 164ndd 147NetBackup

カタログ 146ジョブスケジュール 43スケジューラ 84リストア 142

NetBackup Client Job Tracker 163NetBackup Java コンソール 161NetBackup Vault 161NetBackup リレーショナルデータベース 58NetBackup リレーショナルデータベースのファイル 54NET_BUFFER_SZ 111～113、123NET_BUFFER_SZ_REST 111NEW_STREAM 指示句 154

NOexpire touch ファイル 200NOM

「OpsCenter」を参照 39None プール 69NOSHM ファイル 114NO_TAPEALERT touch ファイル 77NUMBER_DATA_BUFFERS 117、124～125、183NUMBER_DATA_BUFFERS_DISK 118NUMBER_DATA_BUFFERS_FT 118、125NUMBER_DATA_BUFFERS_MULTCOPY 118NUMBER_DATA_BUFFERS_RESTORE 119、146

OOEMSETUP.INF ファイル 199OpsCenter

サーバーの設計 39ジョブの監視 47メディアの監視 69

Oracle 148リストア 148

PPARENT_DELAY ファイル 127PCI カード 170、175PCI バス 170、173PCI ブリッジ 170、174～175［PhysicalDisk］オブジェクト 100poolDB 30［Process Queue Length］ 98

RRAID 100、107

コントローラ 171、175raw パーティションのバックアップ 164REGEDT32 200RMAN 149robotic_def 30ruleDB 30

SSAN クライアント 72、104、107

バッファの推奨数 125SAN ファブリック 172SAN メディアサーバー 104sar コマンド 97SATA 23SCSI/FC 接続 149SCSI バス 63

203索引

SGList 199SGList パラメータ 198、200SIZE_DATA_BUFFERS 123～125、183SIZE_DATA_BUFFERS_DISK 120SIZE_DATA_BUFFERS_FT 120～121SIZE_DATA_BUFFERS_MULTCOPY 120～121SKIP_DISK_WRITES 95SMART 診断標準 76Snapshot Client 162SSOhosts 30storage_units データベース 30stunit_groups 30System Administration Manager (SAM) 183

TTapeAlert 75TapeAlert の無効化 77tar 130tar32 130TCP/IP 163tcp_deferred_ack_interval 147touch ファイル

エンコード 200True Image Restore オプション 161

UUltra320 SCSI 23Ultra-3 SCSI 23Unicode エンコード 200

VVault 161Vision オンライン 201vmstat 97volDB 30vxlogview 59

ファイル ID 59vxlogview のファイル ID 59VxVM のストライプボリューム 164

WWide Ultra 2 SCSI 23Windows パフォーマンスモニター 93

あアーカイブビット 188［アクティビティモニター (Activity Monitor)］ 89

アクティビティモニターの［状態の詳細（State Details）］ 45圧縮 100、159

暗号化 161カタログ 54、57テープ対クライアント 159有効にする方法 160

アービトレーテッドループ 171アルファベット順

ストレージユニット 49アレイ 107アレイ RAID コントローラ 171暗号化

KMS 158MSEO 158圧縮 161クライアントでの暗号化 158複数ストリーム 158

イーサネット接続 168イメージデータベース

圧縮 57インクルードリスト 58インデックスのパフォーマンス 146インラインコピー。「複数コピー」を参照ウイルススキャン 108、162ウイルス対策ソフトウェア 188エクスクルードリスト 58エラーのしきい値 63エラーログ 65、88エンコード

ファイル 200親/子遅延値 126オンデマンドのテープクリーニング

「TapeAlert」を参照 75

か開始時間帯 84階層

ディスク 168カウンタ 126

Windows のパフォーマンス 97値の判断 132アルゴリズム 130待機と遅延 126

カスタムレポート利用可能なメディア 69

カタログ 146アーカイブ 57圧縮 54、57大きいバックアップ 57

204索引

管理 53バックアップ

ガイドライン 53バックアップが終了しない 57バックアップの必要条件 105

カタログのアーカイブ 57間隔を基準としたテープクリーニング 75監視

データの可変要素 86完全バックアップ 69完全バックアップでのテープとディスク 70管理

カタログ 53ログ 59～60

キーマネージメントサービス (Key Management Service:KMS) 158

キャッシュデバイス (スナップショット) 164キューに投入されたジョブ 45～46キューへ投入されたジョブ 45～46共通のシステムリソース 93共有アクセストポロジー 171、173共有データバッファ 115

数の変更 117サイズの変更 120デフォルト数 116デフォルトサイズ 116

共有メモリ 114～115推奨される設定 124テスト 125パラメータ

HP-UX 182必要な量 117

クライアント圧縮 159可変要素 85パフォーマンスのチューニング 107

クリティカルポリシー 58クリーニング

テープ 69テープドライブ 74ロボット 76

クロックまたはサイクル時間 173計算

NBDB データベースに必要な容量 30共有メモリ 117実際の必要なデータ転送速度 18ネットワーク転送速度 24バックアップの長さ 20必要なテープ数 32

必要なロボットテープスロット数 33公称スループット率 150構成ガイドライン 58合成バックアップ 112高速検索 143子遅延値 126コピーオンライトスナップショット 164コントローラ 101コンポーネントの評価 93、97

さサイクル時間 173最大スループット率 150最大伝送単位 (MTU) 125最大フラグメントサイズ 142最大並列書き込みドライブ数 (Maximum concurrent write

drives) 45再ブートのない st ドライバの再ロード 67作業セット

メモリ 99サーバー

EMM からのマスターの分割 58可変要素 84チューニング 115データパス 169

サーバー内のデータパス 169シェルフ 170しきい値

エラー調整 64

メディアエラー 63システムの可変要素

制御 84システムリソース 93自動認識 109自動ネゴシエーション 109手動バックアップのコマンド 87詳細レベル 162［状態の詳細（Detailed Status）］タブ 89ジョブ

スケジュール 43制限の要因 43

遅延 46～47シリアル ATA (SATA) 170推奨する実施例 74、77、80スイッチ 172スクラッチプール 68スケジュール 43、84

制限の要因 43

205索引

遅延 44スケジュールの名前付け

推奨する実施例 80ステージング

ディスク 51、69ストライピング

ブロックサイズ 164ストライプ化

ディスク上のボリューム 104ストライプボリューム (VxVM) 164ストリーミング（テープドライブ） 149ストリーム (テープドライブ) 70ストレージデバイスのパフォーマンス 149ストレージユニット 47、106

グループ 47命名規則 81利用不可 46

［ストレージユニット（Storage Unit）］ダイアログボックス 142

ストレージユニットのグループ 47ストレージユニットの使用順序 49スナップショット 108スナップショットキャッシュデバイス 164［すべてのログエントリ (All Log Entries)］レポート 88、

90、92スループット 88設計

マスターサーバー 34設定ファイル（Windows） 200全二重 109前方スペースファイルマーク 143専用のバックアップサーバー 104専用のプライベートネットワーク 104増分バックアップ 69、104、153測定

NetBackup のパフォーマンス 84ディスクの読み込み速度 93、95

ソケット通信 114

ソフトウェア圧縮 (クライアント) 159チューニング 176

た帯域幅 174帯域幅の制限 105待機/遅延カウンタ 126～127、132

問題の解決 140問題の分析 137

リモートクライアントバックアップ 134リモートクライアントリストア 136ローカルクライアントバックアップ 133ローカルクライアントリストア 135

多重化 70、104影響 154スケジュール 45高すぎる設定 147使う場合 152

多重化イメージリストア 143

多重化されたバックアップデータベースバックアップ 148フラグメントサイズ 143

小さいファイルバックアップ 162

「チェックポイントから再開」機能 146チェックポイント設定の取得 146遅延 174

値親または子 126

ジョブの開始 44バッファ 126

中断されたボリューム 64チューニング

FlashBackup の読み込みバッファ 164クライアントのパフォーマンス 107サーバーパフォーマンス 115推奨事項 103ソフトウェア 176データ転送パス

概要 102デバイスのパフォーマンス 149ネットワークパフォーマンス 108バッファサイズ 110、112リストアのパフォーマンス 142、147

チューニングパラメータbptm ログ 137

調整エラーのしきい値 64ネットワーク通信バッファ 110バックアップ負荷 106読み込みバッファサイズ 164

通信バッファ 112～113プロセス 127

通信バッファサイズパラメータ 112通知スクリプト 108ディザスタリカバリ 77～78

206索引

ディスク空きがない 100ステージング 51速度

測定 93追加 107テープとの比較 69パフォーマンスの向上 100負荷

監視 99ディスク型ストレージ 69ディスク速度

測定 95ディスクパフォーマンスの向上 100テスト条件 84データ圧縮 150データ消費側 131データストリームとテープの効率 149データスループット 85

統計 88データ生産側 131データ転送速度

テープドライブ 20ドライブコントローラ 22必要 18

データ転送の速度 18データ転送パス 86、102

基本的なチューニング 103データの可変要素 86データの処理時間 70データのリカバリ

計画 77～78データバッファ

概要 115サイズ 110

データベース6.0 以前のデータベースリスト 30バックアップ 152リストア 148

データリカバリ計画 77～78

デバイス再設定 66名前 160

デバイスの再設定 66テープ

空きがない凍結。「中断」を参照

圧縮 159

クリーニング 69、75効率 149ストリーミング 149ストリーム 70ディスクとの比較 69配置エラー 65バックアップに必要なテープ数 32バッファ 115ブロックサイズ 117

テープ型ストレージ 69テープドライブ 149

技術 74クリーニング 74転送速度 20ネットワーク接続ごとの数 62必要な技術 19

テープドライブの消耗 149テープの接続性 63テープライブラリ

必要なテープスロット数 33転送速度

テープドライブ 20ドライブコントローラ 22ネットワーク 24バックアップ 18必要 18

凍結されたボリューム 64統合ログ

表示 59トポロジー (ハードウェア) 173ドライブ

ネットワーク接続ごとの数 62ドライブあたりの最大ストリーム数 (Maximum streams per

drive) 45ドライブコントローラ 22ドライブの選択

EMM 67ドライブの停止 64～65トランザクションログ (transaction log) 31トランザクションログファイル 54

なネットワーク

インターフェースカード（NIC） 109可変要素 84接続 108帯域幅の制限 105チューニング 108チューニングとサーバー 104

207索引

通信バッファ 112テープドライブ 62転送速度 24トラフィック 109バッファサイズ 110パフォーマンス 84負荷 109プライベート

専用 104ネットワークのトラフィック 109ネットワークバッファサイズパラメータ 112、138

は配置エラー 65パケット 163パケットのシーケンス外配信 163バス 63バックアップ

大きいカタログ 57カタログ 58環境

専用または共有 68時間帯 104ディスクまたはテープ 69デバイスの占有 106負荷の均等化 105負荷の調整 106ユーザー主導 87

バックアップコンポーネント間での負荷の均等化 106バックアップ試行パラメータ 65パッチ 163バッファ 110

FlashBackup 164Windows バッファの変更 200数の変更 117共有 115サイズの変更 120待機と遅延 126テスト 125テープ 115デフォルト数 116デフォルトサイズ 116ネットワーク通信用 112

ハードウェアコンポーネントとパフォーマンス 174設定の例 175パフォーマンスに影響する要素 168パフォーマンスの考慮事項 174

パフォーマンスCPU 175戦略と注意事項 103「チューニング」も参照 103ハードウェアの問題 174

パフォーマンスの向上「チューニング」を参照 103

パフォーマンスの評価NetBackup クライアント 107NetBackup サーバー 115アクティビティモニター 89暗号化 158概要 84［すべてのログエントリ (All Log Entries)］レポート 90ネットワーク 84、108

パフォーマンス評価 84CPU の監視 98アクティビティモニター 89監視メモリの使用 97～98システムコンポーネント 93、97［すべてのログエントリ (All Log Entries)］レポート 90ディスク負荷の監視 99

非多重化 104非多重化リストア 143非巻き戻しオプション 160ファイバーチャネル 170、172

アービトレーテッドループ 170ファイル

Windows の構成 200多数の小さいバックアップ 162

ファイルエンコード 200ファイルシステム容量 51ファイルリストのワイルドカード 58フェールオーバー

ストレージユニットグループ 50負荷

監視 98均等化 105～106

負荷の分散 106複数コピー 141

共有メモリ 118、120～121複数ストリーム

NEW_STREAM 指示句 154使う場合 152

複数の小さいファイルバックアップ 162

複数のドライブストレージユニット 45

不十分なメモリ 99

208索引

フラグメンテーション 107レベル 100

フラグメントサイズ 142～144選択の注意事項 142

［フラグメントサイズの縮小 (Reduce fragment size to)］設定 142

フラグメントサイズの制限 142プールの規定 68プロセッサ時間 97分散収集リスト 199ページフォルト 99ベストプラクティス 74保持期間 (retention period) 69ホスト名解決 84ホストメモリ 169ボトルネック 86、109ポリシー

ガイドライン 58重要 58命名規則 80

［ポリシーごとにジョブ数を制限する (Limit jobs perpolicy)］属性 45、106

ポリシーの更新間隔 44ボリューム

中断 64凍結 64プール 68

まマスターサーバー

数の判断 36設計 34分割 58

マスターサーバーの分割 58マスターサーバーのマージ 58無効化（Deactivate）コマンド 87命名規則 80

ストレージユニット 81ポリシー 80

メッセージキューパラメータHP-UX 182

メディア配置 149

メディアエラーのデータベース 30メディアサーバー

サイズの決定の要因 38必要な数 38マスターがサポートする数 36利用不可 47

メディアの多重化の設定 45メディアの凍結 63～65メディアマネージャ

ドライブの選択 67メディアレポートリスト 63メモ帳

ファイルエンコードの確認 200メモリ 169、174～175

監視使用 97～98共有 115必要な量 117不十分 99

やユーザー主導バックアップ 87要因

ジョブスケジュール 43ディスクまたはテープの選択 69

読み込みバッファサイズFlashBackup 164調整 164

読み込みバッファのサイズ変更 (FlashBackup) 164より大きいバッファ (FlashBackup) 164

らライブラリに基づくテープクリーニング 76リカバリ時間 70リストア

混在環境 147多重化イメージ 143データベース 148ネットワーク 147パフォーマンス 146非多重化イメージ 143

リストアの RESTORE_RETRIES 65利用可能なメディアなし 63リンクダウン 109累積増分バックアップ 18ルーター 109レガシーログ 60レジストリ (registry) 199レポート 92

media 69すべてのログエントリ (All Log Entries) 90

ローカルバックアップ 153ログ 87～88、132

管理 59～60表示 59

209索引

ログの表示 59ロボット

クリーニング 76

210索引

Symantec NetBackup バックアップ計画とパフォーマ … 10...

Documents

Transcript of Symantec NetBackup バックアップ計画とパフォーマ … 10...

Symantec NetBackup バッ クアップ計画とパフォーマ … 10...

Documents

Transcript of Symantec NetBackup バッ クアップ計画とパフォーマ … 10...

Symantec NetBackup バックアップ計画とパフォーマ … 10...

Transcript of Symantec NetBackup バックアップ計画とパフォーマ … 10...