Tivoli Storage Manager Performance Tuning...

IBM Tivoli Storage Manager

パフォーマンス・チューニング・ガイド

SC88-9924-00 第 1 刷 (2004.1)

Americas Advanced Technical Support San Jose, CA この版は、現在サポートされているレベルの IBM Tivoli Storage Manager サーバー

およびクライアントに関する補足資料であり、新しい版またはテクニカル・ニュー

スレターで明記されていない限り、新情報として利用できます。チューニング

に関する新の情報については、本書の新版を利用してください。また、IBM のソフトウェア・サポート・サイトでチューニングに関する新のアドバイスを参

照してください。

お願い

本書で紹介する製品をご使用になる前に、『特記事項』に記載されている情報を

お読みください。

© Copyright International Business Machines Corporation 2003. All rights reserved. © Copyright IBM Japan 2004

1

目次 IBM Tivoli Storage Manager.............................................................................................. 1 パフォーマンス・チューニング・ガイド..................................................................... 1 SC88-9924-00 ..................................................................................................................... 1 目次..................................................................................................................................... 2 本書について..................................................................................................................... 4 特記事項............................................................................................................................. 4 特記事項......................................................................................................................... 4 プログラミング・インターフェース情報................................................................. 5 商標................................................................................................................................. 5

第 1 章: TSM チューニングの概要 ................................................................................. 5 TSM パフォーマンスの概要 ....................................................................................... 5

第 2 章: TSM のチューニング・オプション ................................................................ 7 TSM サーバーのチューニングに関する考慮事項 ................................................... 7 チューニング・オプション..................................................................................... 7 BUFPoolsize ............................................................................................................... 8 EXPInterval............................................................................................................... 10 LOGPoolsize............................................................................................................. 10 MAXNUMMP .......................................................................................................... 11 MAXSessions ........................................................................................................... 11 MOVEBatchsize / MOVESizethresh........................................................................ 11 RESTOREINTERVAL............................................................................................. 12 SELFTUNEBUFPOOLsize ...................................................................................... 13 SELFTUNETXNsize ................................................................................................ 14 TAPEIOBUFS .......................................................................................................... 14 TCPNodelay.............................................................................................................. 15 TCPWindowsize ....................................................................................................... 15 TXNGroupmax ......................................................................................................... 16 USELARGEbuffer.................................................................................................... 17

プラットフォーム別の推奨事項............................................................................... 18 OS/390 サーバー ..................................................................................................... 18 AS400 サーバー ...................................................................................................... 21 MS Windows サーバー ........................................................................................... 21 Solaris サーバー ...................................................................................................... 25 AIX サーバー .......................................................................................................... 27 HP-UX サーバー ..................................................................................................... 28

TSM クライアントのチューニング ......................................................................... 30 チューニング・オプション................................................................................... 30 COMPRESSION....................................................................................................... 31

2

COMPRESSALWAYS............................................................................................. 32 COMMRESTARTDURATION / COMMRESTARTINTERVAL.......................... 32 QUIET....................................................................................................................... 33 LARGECOMmbuffers.............................................................................................. 34 MEMORYEFFICIENTBACKUP (旧 SLOWINCREMENTAL)............................ 34 複数セッションのバックアップ/リストア ......................................................... 35 RESOURCEUTILIZATION .................................................................................... 36 表 2. Resource Utilization の設定............................................................................ 38 TAPEPrompt............................................................................................................. 39 TCPBufsize ............................................................................................................... 40 TCPNodelay.............................................................................................................. 40 TCPWindowsize ....................................................................................................... 40 TXNBytelimit ........................................................................................................... 41 パフォーマンスに関する一般考慮事項............................................................... 42

プラットフォーム固有の推奨事項........................................................................... 43 AIX クライアント .................................................................................................. 43 Windows クライアント .......................................................................................... 43 DEC クライアント.................................................................................................. 44 Novell クライアント............................................................................................... 45 SOLARIS クライアント ......................................................................................... 45 コマンド行オプション........................................................................................... 47 TSM AIX 共用メモリーのチューニングに関する考慮事項 ............................. 48

第 3 章 TSM の適化 ................................................................................................... 49 サーバーの適化....................................................................................................... 49 LAN フリー・バックアップ ..................................................................................... 53 TSM ストレージ・エージェントのチューニング ................................................. 54 Domino for S/390 の TDP............................................................................................ 54 外部 TSM チューニングのヒント ............................................................................ 55

第 4 章: ストレージ装置のヒント ................................................................................ 61 IBM LTO ドライブ ..................................................................................................... 61 SSA ディスク .............................................................................................................. 63 SilverNode SCSI スロットの配置 .............................................................................. 64 バス............................................................................................................................... 65

付録 A: TSM アーカイブ機能の使用 ........................................................................... 65 抄録................................................................................................................................... 65 履歴............................................................................................................................... 65 アーカイブ機能の実装............................................................................................... 67 症状............................................................................................................................... 68 推奨アクション........................................................................................................... 69 要約............................................................................................................................... 70

付録 B: ネットワーク・プロトコルのチューニング................................................ 70 TCP/IP のチューニングに関する考慮事項.............................................................. 70

3

通信の概念............................................................................................................... 70 プラットフォーム固有の推奨事項....................................................................... 74

用語集............................................................................................................................... 91 参考資料........................................................................................................................... 95 その他の資料............................................................................................................... 95 IBM LTO 関連資料 ..................................................................................................... 96 その他の TCP/IP パフォーマンス関連資料............................................................. 96 参考 Web サイト ......................................................................................................... 96

本書について本書は、IBM Tivoli Storage Manager でのパフォーマンス・チューニングを支援す

ることを目的としています。本書は、IBM Tivoli Storage Manager 製品資料である

「管理者の手引き」「管理者のための解説書」およびクライアントの「ユーザーズ・ガイド」と併せて使用してください。

特記事項特記事項

本書に含まれる情報は、特定物として現存するままで提供し、すべての明示もしくは黙示の保証責任を負いません。個々の項目は、特定の状況における正確性に

ついて IBM によって検討されていますが、全く同一または同様な結果が得られる

保証はありません。

本書に含まれるパフォーマンス・データは、調整された環境で得られたものであ

り、他の操作環境で得られた結果とは大きく異なる可能性があります。

本書に記載の製品、プログラム、またはサービスが日本においては提供されてい

ない場合があります。日本で利用可能な製品、プログラム、またはサービスにつ

いては、日本アイ・ビー・エムの営業担当員にお尋ねください。本書で IBM プロ

グラムに言及しても、その IBM のみが使用可能であることを意味するものではあ

りません。同等の機能を持つ他のプログラムをこれらの製品の代わりに使用する

ことも可能です。

4

プログラミング・インターフェース情報

本書は、Tivoli Storage Manager の利用を支援することを目的としています。

本書の情報は、IBM Tivoli Storage Manager のプログラミング・インターフェース

として使用されることを意図して記述されたものではありません。

商標

IBM、Tivoli、AIX、MVS/ESA、MVS/XA、OS/2、OS/390、z/OS、OS/400、VM/ESA、

VSE/ESA、eServer、pSeries、zSeries、xSeries、iSeries、S/390、RISC System/6000、RS/6000、SP、PowerPC、AS/400、VTAM、C/370、Database 2、DB2、DB2 Universal Database、RACF は IBM Corporation の商標です。

Pentium は、Intel Corporation の米国およびその他の国における商標です。

Microsoft および Windows は Microsoft Corporation の米国およびその他の国におけ

る商標です。

Java およびすべての Java 関連の商標およびロゴは、Sun Microsystems, Inc. の米国

およびその他の国における商標または登録商標です。

UNIX は、The Open Group の米国およびその他の国における登録商標です。

他の会社名、製品名またはサービス名等はそれぞれ各社の商標です。

第 1 章: TSM チューニングの概要 TSM パフォーマンスの概要

TSM のパフォーマンスは、各種チューニング・パラメーターによる影響を受けま

す。良好なパフォーマンスを実現できるようにこれらの機能をチューニングする

には、インプリメント担当者が知識修得に熱心であり、専門知識を蓄えている必

要があります。TSM では、さまざまなオペレーティング・システム、ネットワー

ク構成、およびストレージ装置がサポートされているので、TSM のチューニング

はかなり複雑になることがあります。このチューニング・ガイドでは、TSM の操

作運用において良好なパフォーマンスを引き出す作業を容易にするヒントを提供

することを目的としています。

5

1 つのプラットフォーム機能のパフォーマンスをチューニングする作業はかなり

複雑ですが、これまでの長年にわたる経験から、この点については一般に十分に

理解されています。ただし、クライアント/サーバー領域の TSM 機能は、さまざ

まなオペレーティング・システムをサポートし、ネットワークを介して機能し、

各種通信プロトコルを受け入れます。したがって、パフォーマンスに影響する要

因が多数存在します。TSM のパフォーマンスに大幅に影響する要因を次に示しま

す。

• 平均クライアント・ファイル・サイズ • 終増分バックアップ以降に変更されたファイル数の割合

(パーセンテージ) • 終増分バックアップ以降に変更されたバイト数の割合 (パーセンテージ) • クライアント・ハードウェア

(CPU、RAM、ディスク・ドライブ、ネットワーク・アダプター) • クライアント・オペレーティング・システムのクライアント・アクティビ

ティー (Tivoli Storage Manager 以外のワークロード) • サーバー・ハードウェア

(CPU、RAM、ディスク・ドライブ、ネットワーク・アダプター) • サーバー・ストレージ・プール装置 (ディスク、磁気テープ、光ディスク) • サーバー・オペレーティング・システム • サーバー・アクティビティー (Tivoli Storage Manager 以外のワークロード) • ネットワーク・ハードウェアおよびネットワーク構成 • ネットワーク使用率 • ネットワークの信頼性 • 通信プロトコル • 通信プロトコルのチューニング • 終出力リポジトリー・タイプ (ディスク、磁気テープ、光ディスク)

このようなさまざまな組み合わせがあるので、すべてのパラメーターの組み合わ

せを本書で説明することは不可能です。本書では、ハードウェアを取り替えずに

制御できるパラメーターについてのみ説明します。

本書は次の 4 つのセクションで編成されています。

1. チューニングの概要 2. TSM チューニング・オプション 3. TSM の適化 4. ストレージ装置のヒント

各セクションでは、初めにトピックの概要を示し、次にパフォーマンスに影響す

る各種パラメーターを解説します。

6

パラメーターごとに、必要に応じて省略時値と良好なパフォーマンスを引き出す

ための推奨値を示します。以降のセクションでは、TCP/IP、NetBIOS、または TSM に固有の専門用語が多数使用されます。NetBIOS と TCP/IP の 2 つの用語集が付録

として収録されています。

第 2 章: TSM のチューニング・オプション TSM サーバーのチューニングに関する考慮事項

この章では、パフォーマンスを大限に引き出すための TSM サーバーおよびク

ライアントのチューニングを中心に説明します。1 番目のセクションでは、すべ

ての TSM サーバーおよびクライアントに適用されるチューニング・パラメーター

について説明し、2 番目のセクションではサーバーおよびクライアントのプラッ

トフォーム固有の推奨事項を示します。3 番目のセクションでは、Windows ジャー

ナル・ベース・バックアップ、LAN フリー・バックアップ、TSM ストレージ・

エージェントのチューニング、および TDP for Domino For S/390 パフォーマンス

修正固有の推奨事項について説明します。

チューニング・オプション

すべての TSM サーバーでチューニング可能なパラメーターを次に示します。こ

れらのパラメーターはすべて、サーバーの dsmserv.opt ファイルで変更することも

できます。また、一部のパラメーターはサーバーの SETOPT コマンドを使用して

変更できます。dsmserv.opt ファイルの変更内容を有効にするには、サーバーを停

止してから再始動する必要があります。

• BUFPoolsize • EXPInterval • LOGPoolsize • MAXNUMMP (クライアント NODE 定義で変更) • MAXSessions • MOVEBatchsize / MOVESizethresh • RESTOREINTERVAL • SELFTUNEBUFPOOLsize • SELFTUNETXNsize • TAPEIOBUFS • TCPNodelay • TCPWindowsize • TXNGroupmax • USELARGEbuffer

7

BUFPoolsize

データベース・バッファー・プールが提供するキャッシュ記憶機構により、デー

タベース・ページを長期にわたってメモリー内に維持できます。データベース・

ページがキャッシュに入っている場合には、サーバーがページを連続して更新す

るときに、外部ストレージへの入出力操作が不要になります。データベース・バッ

ファー・プールによりサーバーのパフォーマンスが向上しますが、データベース・

バッファー・プールには多くのメモリーが必要です。

自己チューニング機能により、サーバーの期限切れ処理ではキャッシュ・ヒット

率に基づいてデータベース・バッファー・プールがリセットされます。期限切れ

処理はデータベースの大部分をトラバースすることから、チューニング・ポイン

トとして選択されました。データベース・キャッシュ・ヒット率統計は、期限切

れ処理の開始前にリセットされ、期限切れ処理の完了後に検査されます。バッ

ファー・プール・サイズの調節は、サーバー・オプション・ファイルの SELFTUNEBUFPOOLSIZE オプション (YES/NO) により制御されます。省略時値

は NO です。バッファー・プール・サイズ初期値をリセットするには、SETOPT BUFPoolsize コマンドを使用します。このコマンドは、サーバー・オプション・

ファイルを更新します。バッファー・プール・サイズの増加率 (%) は、目標値 98 % と実際のバッファー・プール・キャッシュ・ヒット率の差の半分です。プラット

フォーム固有の検査が失敗した場合には、バッファー・プール・キャッシュは増

加されません。

UNIX バッファー・プール・サイズの上限は物理メモリーの 10 % です。

Windows UNIX と同様ですが、メモリー・ロードの上限は 80% です。

MVS 上限は領域サイズの 50 % です。

UNIX および Windows システムで SELFTUNEFBUFPOOLSIZE を使用する際には

注意してください。上限が低いため (10 % または実メモリー)、自己チューニング・

アルゴリズムでは適なサイズを実現できない可能性があります。バッファー・

プール・ヒット率をモニターし、必要に応じて手動で調整します。

データベース・バッファー・プールの適なサイズ設定は、キャッシュ・ヒット

率が 99% 以上になるサイズです。バッファー・プール・キャッシュ・ヒット率が 99% を下回ると、パフォーマンスが大幅に低下します。キャシュ・ヒット率を調

べるには、query db format=detail を使用します。BUFPoolsize パラメーターの値

を増やすと、多くの TSM サーバー機能 (マルチクライアント・バックアップ、ス

トレージ・プール・マイグレーション、ストレージ・プール・バックアップ、期

8

限切れ処理、データの移動など) のパフォーマンスが向上します。キャッシュ・

ヒット率が 99% 未満の場合には、DSMSERV.OPT ファイルの BUFPoolsize パラメー

ターのサイズを増やすか (この変更を有効にするには、サーバーを停止してから

再始動する必要があります)、または SETOPT コマンドを使用します。

ほとんどのサーバーでは、初めに値 32768 を使用することをお勧めします。この

値は 8192 データベース・ページに相当します。キャッシュ・ヒット率に基づいて、

1 MB ずつ増加してください。キャッシュ・ヒット率が 99% を超える場合、適切

な BUFPoolsize に達しています。ただし、このレベルを超えて BUFPoolsize を増

やすと、さらに効果的です。BUFPoolsize を増やすときには、仮想メモリー・シ

ステムへのページングが発生しないように注意してください。システム・メモリー

使用率をモニターし、BUFPoolsize の変更後にページングが増加したかどうかを

確認します。(キャッシュ・ヒット率統計をリセットするには RESET BUFP コマ

ンドを使用します。) データベース・ページはページング・ファイルから読み込

まれるので、ページング実行時には、誤ったバッファー・プール・キャッシュ・

ヒット率統計の情報が生じることになります。

適なサイズは実メモリーの 1/8 から 1/2 であることが判明しています。

AIX でページングを防止するには、『AIX の VMTUNE』を参照してください。

表 1. BUFPOOLSIZE の推奨初期値

AIX、HP、Sun、Windows サーバーの推奨値

システム・メモリー (MB) バッファー・プール・サイズの推奨値 (MB)

バッファー・プール・サイズの推奨値 (KB)

32 2 204848 3 307264 4 409696 9 9216

128 14 14336160 20 20480256 32 32768512 64 65536

1024 128 1310722048 256 262144

9

EXPInterval

TSM サーバーによるインベントリーの期限切れ処理の自動実行間隔を時間単位で

指定します。インベントリーの期限切れ処理では、クライアント・バックアップ

が除去され、サーバーからファイル・コピーがアーカイブされます。

バックアップ・コピー・グループとアーカイブ・コピー・グループは、データ・

ストレージからファイルのコピーを削除するための条件を指定できます。ただし、

ファイルが削除対象になっても、期限切れ処理が実行されるまではこのファイル

は削除されません。期限切れ処理が定期的に実行されない場合には、期限切れク

ライアント・ファイルからストレージ・プール・スペースが再利用されないので、

TSM サーバーに必要なディスク・ストレージ・スペースが増加します。

期限切れ処理は CPU と I/O を集中的に使用します。可能であれば、ほかの TSM プロセスが実行されていないときに期限切れ処理を実行するようにしてください。

このように実行するには、期限切れ処理を 1 日に 1 回実行するようにスケジュー

ルするか、または EXPInterval を 0 に設定してからサーバーで EXPIRE INVENTORY コマンドを使用して期限切れ処理を手動で開始します。省略時値は 24 です。期限

切れ処理は管理スケジュールでもスケジュールできます。

管理スケジュールで DURATION パラメーターを使用している場合には、指定さ

れた時間内に期限切れ処理が実際に完了していることを定期的に確認してくださ

い。

推奨値

EXPInterval 0 (期限切れ処理を実行しない) を設定し、管理スケジュールを使用し

て毎日適切な時点で期限切れ処理を実行します。

LOGPoolsize

回復ログのバッファー・プール・サイズを KB 単位で指定します。大きな回復ロ

グ・バッファー・プールでは、必要なメモリー量が増えるので、回復ログ・トラ

ンザクションがデータベースにコミットされる回数が増加します。新しいトラン

ザクション・レコードは、回復ログへ書き込み可能になるまで、回復ログ・バッ

ファー・プールに維持されます。回復ログ・バッファー・プールのサイズが、サー

バーがレコードを回復ログに強制的に書き込む頻度に影響することがあります。

LOGPoolsize を増やす必要があるかどうかを判別するには、LogPool Percentage Wait の値をモニターします。待機率を確認するには、query log format=detail を使用し

ます。値がゼロよりも大きい場合には、LOGPoolsize の値を増やします。回復ロ

10

グ・バッファー・プールのサイズを増加した場合には、システム・メモリー使用

率を必ずモニターしてください。

推奨値

LOGPoolsize 2048 から 8192

MAXNUMMP

サーバーでのノードの MAXNUMMP 設定により、ノードがサーバー上で使用で

きるマウント・ポイントの大数が指定されます。MAXNUMMP には 0 から 999 を設定できます。ゼロを指定すると、ノードはバックアップまたはアーカイブ操

作のためのマウント・ポイントを獲得できなくなります。ただし、ノードがリス

トア操作またはリトリーブ操作のためのマウント・ポイントを使用することは可

能です。クライアントがデータを保管するストレージ・プールに同時バックアッ

プ用のコピー・ストレージ・プールが定義されている場合、クライアントには追

加マウント・ポイントが必要となることがあります。原則として、順次装置タイ

プのコピー・ストレージ・プールごとにマウント・ポイントを 1 つずつ割り当て

ます。1 次ストレージ・プールのタイプが順次装置タイプである場合には、1 次ス

トレージ・プールのマウント・ポイントも同様に割り当てます。

MAXSessions

TSM サーバーに接続できる同時クライアント・セッションの大数を指定します。

省略時値は 25 クライアント・セッションです。小値は 2 クライアント・セッショ

ンです。大値は使用可能な仮想メモリーまたは通信リソースによってのみ制限

されます。このパラメーターは、TSM サーバーに接続できる同時クライアント・

セッションの大数を指定します。クライアント数を制限すると、サーバーのパ

フォーマンスが向上しますが、クライアントに対する TSM サービスの可用性は

低下します。TSM サーバー・オプション・ファイルでパラメーターを設定するか (TSM を停止してから再始動する必要があります)、または SETOPT コマンドを使

用します。

推奨値

MAXSessions 25 (省略時値)

MOVEBatchsize / MOVESizethresh

このオプションは、同一サーバー・トランザクションでバッチとして移動および

グループ化するファイルの数を指定します。MOVEBatchsize の省略時値は 40、大値は 1000 です。MOVESizethresh の省略時値は 500、大値は 2048 です。

11

MOVEBatchsize オプションと MOVESizethresh オプションを使用すれば、ストレー

ジ・メディア間でのデータ移動操作に関連するサーバー・プロセスのパフォーマ

ンスを調整できます。このようなプロセスには、ストレージ・プール・バックアッ

プとリストア、マイグレーション、レクラメーション、データ移動があります。

これらのオプションはサーバー・オプション・ファイルに指定します。

サーバー・ストレージ・プールのバックアップ/リストア、マイグレーション、レ

クラメーション、またはデータ移動実行時に各サーバー・データベース・トラン

ザクションで移動されるクライアント・ファイル数は、バッチ内のファイルの数

とサイズにより決まります。ファイルの累積サイズが MOVESizethresh を越える

前にバッチのファイル数が、MOVEBatchsize と等しくなる場合には、MOVEBatchsize を使用して、トランザクションで移動またはコピーされたファイルの数を判断で

きます。ファイルの数が MOVEBatchsize に達する前に、移動またはコピー操作の

ためにまとめられた累積サイズが MOVESizethresh を超える場合には、

MOVESizethreshvalue を使用して、トランザクションで移動またはコピーされた

ファイルの数を判断できます。

MOVEBatchsize または MOVESizethresh パラメーターの値を省略時値より大きい

値にすると、サーバーの回復ログに必要なスペースの量が増えます。回復ログに

は、省略時値を使用した場合の回復ログ・サイズの 2 倍以上のスペースを割り振

る必要があります。また、サーバー始動時の初期化に必要な時間が長くなります。

logmode に NORMAL (省略時値) を設定してサーバーを実行している場合、大きな

回復ログ・サイズの影響が現れます。パフォーマンス上の理由でこれらの値を増

やす場合には、初の数回のストレージ・プール・バックアップ/リストア、マイ

グレーション、レクラメーション、またはデータ移動実行時に回復ログの使用率

をモニターし、回復ログ・スペースが十分にあることを確認してください。

サーバー回復ログにスペースを追加するには、DEFINE LOGVOLUME コマンドお

よび EXTEND LOG コマンドを使用します。また、回復ログを拡張するために (DSMFMT または ANRFMT プログラムを使用してフォーマットされている) 追加

ボリュームが使用可能であることも確認します。

推奨値 MOVEBatchsize 1000 MOVESizethresh 2048

RESTOREINTERVAL

リストアは再始動可能であるので、割り込みが発生した場合でもリストア処理を

続行できます。この場合、リストア処理を初からやり直す必要はありません。

これにより、重複する作業またはリストア処理が終了した位置を手動で確認する

12

作業が軽減されます。新しいサーバー・オプション RESTOREINTERVAL は、中

断されたリストア操作を再始動可能な状態で維持する期間を定義します。

RESTOREINTERVAL RESTOREINTERVAL minutes

再始動可能なリストア・セッションが期限切れになるまでにデータベースで維持

される期間を分数単位で指定します。小値は 0、大値は 10080 (1 週間) です。

省略時値は 1440 分 (24 時間) です。この値が 0 に設定されており、リストア操作

が中断または失敗した場合、リストア操作は再始動可能ですが、ただちに期限切

れの対象となります。再始動可能なリストア・セッションは、TSM サーバーのリ

ソースを使用します。これらのセッションを必要以上に長い期間にわたって維持

しないようにしてください。

推奨値

RESTOREINTERVAL (環境に合わせて調整します)

SELFTUNEBUFPOOLsize

バッファー・プール・サイズの自動調整を制御します。Yes または NO に設定し

ます。サーバーでの省略時値は NO です。YES を指定すると、データベース・キャッ

シュ・ヒット率統計が期限切れ処理の開始前にリセットされ、期限切れ処理の完

了後に検査されます。キャシュ・ヒット率が 98% を下回る場合には、バッファー・

プール・サイズが調整されます。バッファー・プール・サイズの増加率は、目標

値 98 % と実際のバッファー・プール・キャッシュ・ヒット率の差の半分です。

プラットフォーム固有の検査が失敗した場合には、バッファー・プール・キャッ

シュは増加されません。

UNIX バッファー・プール・サイズの上限は物理メモリーの 10 % です。

Windows UNIX と同様ですが、メモリー・ロードの上限は 80 % です。

MVS 上限は領域サイズの 50 % です。

UNIX および Windows システムで SELFTUNEFBUFPOOLSIZE を使用する際には

注意してください。上限が低いため (10 % または実メモリー)、自己チューニング・

アルゴリズムでは適なサイズを実現できない可能性があります。バッファー・

プール・ヒット率をモニターし、必要に応じて手動で調整します。

13

十分な物理メモリーが必要です。十分な物理メモリーがないと、ページングが増

加します。自己チューニング・プロセスにより、適切な値に達するまでバッファー・

プール・サイズが段階的に増加されます。表 1 を参照して、初期サイズを設定し (BUFPOOLSIZE オプション)、サーバー始動時に必ず適切なバッファー・プール・

サイズを獲得できるようにしてください。

推奨値 SELFTUNEBUFpoolsize Yes

SELFTUNETXNsize

TSM が TXNGROUPMAX、MOVEBATCHSIZE、および MOVESIZETHRESH サー

バー・オプションの値を自動的に変更できるかどうかを指定します。TSM はクラ

イアント・サーバー・スループットを適化するために TXNGROUPMAX オプショ

ンを設定し、サーバー・スループットを適化するために MOVEBATCHSIZE オプションと MOVESIZETHRESH オプションに大値を設定します。デフォルトは NO です。

このパラメーターはサーバー移動データ・タイプ機能に影響します。

注: トランザクション・サイズが大きいほど、Normal モードで実行中に使用する TSM 回復ログのスペースも大きくなります。Roll Forward モードでのログ・スペース

の不足を防止するため、DEFINE SPACETRIGGER コマンドを使用してログ・ス

ペース・トリガーを作成することをお勧めします。

推奨値 SELFTUNETXNsize Yes

TAPEIOBUFS

BSAM オーバーラップ I/O バッファリング方式を使用するための新しいサーバー・

オプションがあります。

TAPEIOBUFS number of buffers

number of buffers には、1 から 9 の数値を指定します。1 を指定すると、Tivoli Storage Manager は 3539 磁気テープ・メディアに対してオーバーラップ I/O を使用しませ

ん。2 以上の数値を指定すると、Tivoli Storage Manager は前述の式に基づいてバッ

ファーを割り振ります。

14

このオプションを使用すると、3590 磁気テープ・メディアでは I/O スループット

が向上しますが、アドレス・スペース用に割り当てる必要があるメモリーの量が

増加します。適なスループットの例として、UNIX システム・サービス・ソケッ

トおよびギガビット・イーサネットではこのオプションに 9 を設定することが挙

げられます。

推奨値

TAPEIOBUFS 1 (省略時値)

注: このオプションは、OS/390 バージョン 2 リリース 10 以上または z/OS で稼働

するサーバーの 3590 装置タイプの装置クラスには適用されません。

TCPNodelay

オペレーティング・システムの TCPNodelay パラメーターを指定します。Yes または No のどちらかに設定します。

• バッファリングにより、ネットワーク使用率が向上します。 • バッファリングでは遅延が必要となります。これは、セッションのスルー

プットに大きく影響します。

TCPNodelay オプションが Yes に設定されている場合、 MTU サイズよりも少ない

データ・パケットをただちに送信できます。省略時値はプラットフォームによっ

て異なります。

推奨値 TCPNodelay Yes

注: このオプションは TSM クライアントでも有効です。

TCPWindowsize

TCPWindowsize オプションは、TCP/IP 接続で一度に送信状態にできる受信データ

の量を KB 単位で指定します。肯定応答と TCP 受信ウィンドウ更新を受信するま

で、送信ホストはこの値を超えるデータを送信できません。各 TCP パケットには、

接続のアドバタイズされた TCP 受信ウィンドウが含まれています。

ウィンドウが大きいと、送信者が継続的にデータを送信できます。これは、特に

待ち時間が長い高速ネットワークで効果的です。バックアップ・パフォーマンス

を引き上げるには、TSM サーバーの TCP 受信ウィンドウ・サイズを増やすこと

15

を認識しておくことが重要です。リストア操作のパフォーマンスを向上するには、

クライアントの TCP 受信ウィンドウ・サイズを増やします。

TCPWindowsize オプションは、オペレーティング・システムの TCP 送信および受

信スペースを指定変更します。例えば AIX では、これらのパラメーターは tcp_sendspace と tcp_recvspace であり、「no」オプションとして設定されています。

TSM では省略時値が 32KB、大値が 2048KB です。TCPWindowsize 0 を指定す

ると、TSM はオペレーティング・システムの省略時値を使用します。TSM の適な設定は、その他のアプリケーションの適な設定と同一ではない可能性があ

るため、これはお勧めできません。

TCPWindowsize オプションは、MVS サーバーを除くすべてのサーバーとすべての

クライアントの TCP スライディング・ウィンドウのサイズを指定します。ウィン

ドウのサイズが大きいと、通信パフォーマンスは向上しますが、使用メモリー量

が増加します。この場合、肯定応答を受信者から取得する前に、複数のフレーム

を送信できます。送信遅延が長引く場合には、TCPWindowsize を増やすとスルー

プットが向上することがあります。

AIX では、64K-1 よりも大きいウィンドウ・サイズにするには、rfc1323 を on に設定する必要があります。

推奨値 1

TCPWindowsize 64 (Windows は 63)

推奨値 2 (高速スイッチを備えた SP2 環境)

TCPWindowsize 128 から 640

推奨値 3 (ジャンボ・フレーム (9000 MTU) を備えたギガビット・イーサネット)TCPWindowsize 128

注: このオプションは TSM クライアントでも有効です。ジャンボ・フレーム・ギ

ガビット・イーサネットには 128 を使用します。

TXNGroupmax

コミット・ポイント間で 1 つのグループとして転送するファイルの数を指定しま

す。このパラメーターを使用する場合は、TXNBytelimit クライアント・オプショ

ンも併せて使用します。省略時値は 40、大値は 65000 です。個別のクライアン

ト・ノードでこのオプションの値を指定変更するには、REGISTER NODE コマン

ドまたは UPDATE NODE コマンドの TXNGROUPMAX パラメーターを使用しま

す。

16

TXNGroupmax オプションは、クライアントの TXNBytelimit オプションと併せて

使用します (『TXNBytelimit』を参照)。このオプションは、1 つのトランザクショ

ンのファイル数を増やすことで、サーバー・トランザクションの数を減らします。

したがって、データベース・コミットによるバックアップまたはリストアの実行

時のオーバーヘッドの量が減ります。

• トランザクション当たりのファイル数を増やすと、サーバーでの回復ログ

の所要量が増加します。ログとログ・プール・スペースを調べ、十分なス

ペースがあることを確認します。 • トランザクション当たりのファイル数を増やすと、再試行実行時に再送信

するデータの量が増加します。これはパフォーマンスに悪影響を及ぼす可

能性があります。

このパラメーターを変更する利点は、構成とワークロードの特性によって異なり

ます。特に、ワークロードに小さなファイルが多数ある場合には、ディスク・ス

トレージ・プール・バックアップよりも磁気テープ・ストレージ・プール・バッ

クアップの方がこのパラメーターによる効果が大きくなります。

トランザクションのサイズを設定するときには、静的、共有静的、または共有動

的を使用したバックアップの実行時の圧縮またはファイル変更が原因で、多数の

再送信操作を実行する必要がある場合には小さなサイズを設定することを検討し

てください。これは、静的または共有に適用されます。これは、バックアップ中

に変更されたファイルをクライアントが認識し、このファイルを送信しないこと

に決定した場合でも、そのトランザクションのほかのファイルを再送信する必要

があるためです。

開発時のテストでは、4096 よりも大きい設定値では効果がないことが判明しています。サーバー・

オプション・ファイルで TXNGroup を 256 に設定します。一部のクライアントに小さなファイル

があり、これらのファイルを直接磁気テープ・ストレージ・プールにバックアップする場合には、

これらのクライアントに限り TXNGroupmax を大きい値 ( 大 4096) に設定することを検討して

ください。

推奨値

サーバー・オプション・ファイルで TXNGroupmax 256 を指定します。クライア

ントに小さいファイルがあり、磁気テープに直接これらのファイルをバックアッ

プする場合にのみ、これよりも大きな値 ( 大 4096)を設定します。

USELARGEbuffer

USELARGEbuffer サーバー・オプションは省略時設定です。このオプションは、

通信入出力バッファーおよび装置入出力バッファーを増加します。クライアント/サーバー通信バッファーとディスク装置入出力バッファーの両方が 32 KB から 256

17

KB に増加されています。クライアント・セッション (バックアップ・セッション

など) でのデータ送信時には、通信入出力バッファーが使用されます。ディスク・

ストレージ・プールからのデータの読み取りまたはディスク・ストレージ・プー

ルへのデータの書き込み時には、ディスク入出力バッファーが使用されます。

開発時のテストでは、USELARGEbuffer YES を設定した状態で AIX ディスク先読

みの量を増加した場合に、適な AIX TSM サーバー・パフォーマンスを実現で

きました。『AIX の VMTUNE』を参照してください。

USELARGEbuffer 機能を使用可能にした場合に、データ送信操作と CPU 使用率の

大幅な向上が確認されました。バッファー・サイズを増やすと、この機能を使用

可能にしない状況に比べ、クライアント/サーバー通信入出力およびディスク入出

力がより効率的に実行されます。読み取りと書き込みにかかる時間が短くなり、

サーバー・リソースをより効率的に使用できます。CPU 使用率を減らすと、同時

に処理できるクライアントの数が増加し、全体的なシステム・パフォーマンスが

向上します。これらの利点は、サーバー集合を使用することで補完されます。集

合では、サーバー・レベルで小さい論理クライアント・ファイルがこれらのクラ

イアント・ファイル数よりも少ない数の大きな物理ファイルにまとめられます。

大きいファイルでは、大きなバッファーをより効率的に活用できます。

推奨値 USELARGEbuffer Yes

プラットフォーム別の推奨事項

OS/390 サーバー

パフォーマンスに関する推奨事項

ご使用の環境で Tivoli Storage Manager のパフォーマンスを適化する際に役立つ

推奨事項を次に示します。

• TSM サーバー・データベースとストレージ・プール・ボリュームを、も

高速な I/O ディスク (ESS など) に配置します。また、I/O 接続を小限に

抑えるため、十分な数の物理ファイルを用意してください。 • Tivoli Storage Manager サーバーを開始するための領域サイズとして 256MB

(REGION=256M) をお勧めします。ただし、サーバーのワークロードに応

じてこの値を増減できます。ご使用のシステムで適な値を判断するには、

サーバー動作をモニターし、モニター結果に基づいて領域サイズを設定し

ます。

18

指定された領域が小さすぎる場合には、サーバー・パフォーマンスに大き

く影響する可能性があります。これは特に、高サーバー・アクティビティー

の実行時に顕著です。例えば、オペレーティング・システムの GETMAIN および FREEMAIN 処理は、Tivoli Storage Manager などのトランザクション指

向アプリケーションに大きな影響を及ぼします。GETMAIN および FREEMAIN 呼び出しを除外または小限に抑えるため、サーバーは独自の

方法で保管条件に対応します。サーバーが GETMAIN および FREEMAIN プロシージャーの呼び出しを防止する機能は、ワークロードの領域サイズが

適切であることに高く依存しています。

領域サイズを増加する場合、適切なパフォーマンスが得られるか、または

これ以上ストレージを追加しても明らかにパフォーマンスが向上しなくな

る時点まで、128MB ずつ増加してください。この時点に達したら、領域サ

イズの増分を小さくし (32 MB など)、ワークロードに適な領域なサイズ

を判断できます。一定の期間または高アクティビティーの実行期間にわた

り、パフォーマンスをモニターすることが重要です。

領域サイズ 0M (REGION=0M) の使用はお勧めしません。0M を指定すると、

サーバー・パフォーマンスが著しく低下します。

• トランザクション・サイズを大化するには、TSM サーバー・オプション txngroupmax 256 と TSM クライアント・オプション txnbytelimit 25600 を使

用します。トランザクション・サイズを大きくすると、TSM サーバー・ファ

イル集合のサイズが増加します。ファイル集合により、多くのサーバー・

データ移動機能およびインベントリー機能 (ストレージ・プール・マイグ

レーション、ストレージ・プール・バックアップ、インベントリー期限切

れ処理など) のスループットが向上します。磁気テープに直接バックアッ

プする場合にトランザクション・サイズを大きくすると、磁気テープ・バッ

ファー・フラッシュの回数が減少し、スループットが向上します。 • 大きなファイルのスループットとサーバー効率を引き上げるには、TSM サー

バー・オプション uselargebuffers yes を使用します。 • AIX TSM クライアントで largecommbuffers を使用して適なパフォーマン

スを得るには、 TSM クライアント・オプション largecommbuffers yes を使

用します。vmtune -R256 -f120 -F376 を使用して大きなファイルに対する良

好なディスク先読みを実現するには、JFS を調整します。 • クライアントでのバックアップに複数のファイル・スペース (ディレクト

リー、ファイル・システム) を使用し、これらのファイル・スペースが複

数の物理ディスクにまたがっている場合には、クライアント・オプション

の Resource Utilization に省略時値以外の値を設定できます。dsm.sys ファイ

ルの Resource Utilization オプション (RESOURCEUTIL nn) には 5 以上の値

を設定することをお勧めします。開発時のテストでは、RESOURCEUTIL 10

19

と MVS サーバー・オプション FIXIOBUF 16 を指定すると、良のスルー

プットを得られることが判明しました。ただし、TSM 環境を適な状態で

利用するには、Resource Utilization オプションを使用する前に、TSM サー

バーの負荷、ネットワーク帯域幅、クライアント CPU および I/O 構成を評

価する必要があります。 • 高速クライアントと高負荷のネットワークまたはサーバーを使用する場合

に TSM のバックアップおよびリストアのパフォーマンスを大限に引き

出すには、TSM クライアント圧縮を使用します。低速クライアントと低負

荷ネットワークまたはサーバーを使用する場合に TSM のバックアップお

よびリストアのパフォーマンスを大限に引き出すには、TSM クライアン

ト圧縮を使用しないでください。ただし、クライアント圧縮を使用しない

と、ストレージ所要量が増加します。 • OSA/E GbE アダプターを使用してz/OS または OS/390プロセッサーを LAN

に接続している場合は: TCP/IP (CS OS/390) プロファイル・データ・セット Gateway スタンザ; Packet-size 9000 TCPCONFIG スタンザ; TCPSENDBFRSIZE 262144 および TCPRCVBFRSIZE 262144 - AIX TSM クライアント・オプション、TCPWindowsize 256 - AIX ギガビット・イーサネッ

ト; 送受信ジャンボ・フレーム YES ソフトウェア送信キュー・サイズ 1024 この装置の大 IP パケット・サイズ 9000 - AIX no オプション; rfc1323=1 sb_max=1048578 thewall=524340

• OSA/E FENET アダプターを使用して z/OS または OS/390 プロセッサーを

LAN に接続している場合は: TCP/IP (CS OS/390) プロファイル・データ・

セット Gateway スタンザ; Packet-size 1500 TCPCONFIG スタンザ; TCPSENDBFRSIZE 65535 および TCPRCVBFRSIZE 65535 - AIX TSM クラ

イアント・オプション; TCPWindowsize 64 - AIX no オプション: rfc1323=1 sb_max=131072 thewall=131072

• TCP/IP プロファイル・データ・セット、GATEWAY ステートメント: ジャ

ンボ・イーサネット・フレームのパケット・サイズとして 9000 バイトを使

用するか、または標準イーサネット・フレームのパケット・サイズとして 1500 バイトを使用します。

TSM OS/390 サーバーには、複数の CP を利用できる機能があります。この機能を

使用可能にするには、サーバー・オプション・ファイルに MPTHREADING YES を記述します。この場合、MPTHREADING の省略時値は OFF です。このオプショ

ンを使用するのは、複数の同時サーバー・プロセス (レクラメーション、マイグ

レーションなど) を強制的に実行する場合に限られています。その後、注意して CPU 使用率をモニターします。

dsmserv.opt 推奨オプション

MPTHreading Yes

20

USELARGEBuffer Yes BUFPoolsize 32768 LOGPoolsize 1024 TXNGroupmax 256 MOVEBatchsize 1000 MOVESizethresh 2048

AS400 サーバー


BUFPoolsize (表 1 を参照) LOGPoolsize 512 TXNGroupmax 256 MOVEBatchsize 1000 MOVESizethresh 2048 TCPWindowsize 64 USELARGEBuffer Yes TCPNODELAY Yes

MS Windows サーバー


Tivoli Storage Manager server for Windows では、各種内部コードの変更に合わせて

パフォーマンスが適化されています。マルチプロセッサー (SMP) マシン上で活

動状態のサーバー・スレッドが複数ある場合に、パフォーマンスが大に向上し

ます。ユーザーはこれらの変更を意識しません。また、これらの変更では追加チュー

ニング作業は不要です。Tivoli Storage Manager の主要なパフォーマンス拡張は、

バックアップ中にサーバーとの複数のセッションを使用できるようになったこと

です。これを実現するには、クライアントの RESOURceutilization number オプショ

ンを使用します。このオプションの number は、TSM サーバーおよびクライアン

トが処理中に使用できるリソースのレベルを指定します。

多くの場合、良の方法は TSM サーバーにより使用されるディスクで NTFS ファ

イル・システムを使用する方法です。これらのディスクには、TSM 回復ログ、TSM データベース、および TSM ストレージ・プール・ボリュームが含まれています。

21

一般にこれらのディスクで NTFS を使用する場合と FAT を使用する場合のTSM 機能のパフォーマンスに差はありませんが、NTFS には次のような利点があります。

大きなディスク・パーティションのサポート優れたデータ回復優れたファイル・セキュリティー NTFS での TSM ストレージ・プール・ボリュームのフォーマットは

FAT よりも高速である。

TSM クライアントで NTFS を使用する場合、小さなファイル・ワークロードでは FAT に比べパフォーマンスが低下する点に注意してください。これは、バックアッ

プ中にセキュリティー情報を検査し、リストア中に NTFS ファイル・システム回

復機能の影響を検査する必要があるためです。

NTFS ファイル圧縮を使用するとパフォーマンスが低下する可能性がある

ため、TSM サーバーが使用するディスク・ボリュームでは NTFS ファイル

圧縮を使用しないでください。

Windows の実メモリー使用率に関して Tivoli Storage Manager for Windows サーバーのパフォーマンスを大限に引き出すには、「ネットワーク・ア

プリケーションのスループットを大化する (Maximize Throughput for Network Applications)」サーバー・プロパティー設定を使用します。この設

定では、キャッシュ・マネージャーからのファイル・システム・キャッシュ

に対する要求よりも、メモリーに対するアプリケーション要求が優先され

ます。この設定は、メモリー制約があるシステムのパフォーマンスにも

効果的です。 Tivoli Storage Manager の多数のクライアントのバックアップとリストア処

理で適なパフォーマンスを実現するには、Tivoli Storage Manager クライ

アント圧縮の使用を検討してください。クライアントでデータを圧縮する

と、ネットワークと Tivoli Storage Manager サーバーでの要求が減ります。

サーバーのデータ量を減らすことで、このデータを移動するとき (ストレー

ジ・プール・マイグレーションやストレージ・プール・バックアップなど) のパフォーマンスが向上します。ただし、クライアント圧縮では各クライ

アントのパフォーマンスが大幅に低下するので、も低速のクライアント・

システムではデータ量を削減する方が効果的です。

Windows NT DPC 分散の適化

Tivoli Storage Manager サーバーとしてマルチプロセッサー・サーバーを使用する

場合、これらのプロセッサー間で適な方法で DPC を分散することにより、バッ

クアップのパフォーマンスが向上します。データ・パケットの着信時にネットワー

ク・アダプターからの割り込みが発生すると、据え置きプロセス呼び出し (DPC) が

22

生じます。一部のマルチプロセッサー・サーバーでは、使用率がも低いプロセッ

サーにアダプター割り込みが動的に分散されます。このハードウェア機能は、多

数のネットワーク要求を処理するシステムでプロセッサーのボトルネックと低ネッ

トワーク・パフォーマンスを防止するために役立ちます。この機能は対称割り込

み分散とも呼ばれ、スケーリングを向上し、複数のプロセッサーに十分な容量が

ある場合に特定の 1 つのプロセッサーがボトルネックになることを防止すること

を目的としています。この機能は Pentium 系列プロセッサー向け Windows NT 4.0 ハードウェア抽象化層 (HAL) 上で使用できます。また、Windows 2000 でもサポー

トされています。省略時解釈では、Windows NT 4.0 は対称割り込み分散を使用せ

ず、ネットワーク・アダプターに関連付けられている DPC アクティビティーを関

連するプロセッサーに割り当てます。各ネットワーク・アダプターは、も大き

な番号のプロセッサーから順に 1 つのプロセッサーに関連付けられています。プ

ロセッサーの使用率が高く (パフォーマンス・モニター・プロセッサー: % プロセッ

サー時間 > 95%)、かつその時間の半分以上が DPC の処理に費やされている (プロ

セッサー: % DPC 時間 > 50%) 場合には、この DPC アクティビティーをプロセッ

サー間で平衡化することで、パフォーマンスを引き上げることができます。

このためには、以下のレジストリー・キーにあるレジストリー項目 ProcessorAffinityMask を調整します。

HKEY_LOCAL_MACHINE System CurrentControlSet Services NDIS Parameters

警告レジストリーを誤って編集すると、場合によっては重大なエラーが発生し、

オペレーティング・システムを再インストールしなければならないことがありま

す。問題が発生した場合にレジストリーをリストアできるように、レジストリー

を変更する前にレジストリーの内容をバックアップしておくことをお勧めします。

ProcessorAffinityMask の省略時値は x'ffffffff' です。複数のプロセッサー間でネッ

トワーク DPC アクティビティーを平衡化するには、ProcessorAffinityMask を x'0' に設定してシステムをリブートします。

バックアップ/リストア操作とアーカイブ/リトリーブ操作の実行時のネットワー

ク・スループットを向上させるには、TSM サーバー/クライアント・オプション TCPwindowsize を使用します。

Windows NT 3.5、3.51、および 4.0 でサポートされている大 TCP 受信ウィンド

ウは 65535 (64K - 1) バイトです。要求されている大きなウィンドウ・サイズを結

果として戻す TSM tcpwindowsize 値を使用すると、実際には省略時 Windows NT 受信ウィンドウが生成されますが、これは予期されていたウィンドウ・サイズより

も大幅に小さい可能性があります。したがって、前述の環境では TSM tcpwindowsize オプションに値 63 より大きい値を設定することはお勧めできません。Windows 2000/XP では、大きな TCP 受信ウィンドウ・サイズをサポートする機能 (RFC1323) を備えたホストと通信する場合に、大きな TCP 受信ウィンドウ・サイズを提供す

23

ることができます。このような環境では、Windows 2000/XP または UNIX システ

ムとのみ通信する Windows 2000/XP システムで TSM tcpwindowsize に 63 より大き

い値を設定すると効果的です。Windows 95 では tcpwindowsize に 64 を設定できま

す。

ネットワーク・アダプターで使用可能なバッファーのサイズよりもウィンドウ・

サイズが大きいと、アダプターで失われたパケットを頻繁に再送信する必要があ

るため、スループットが 10 倍以上低下することがあります。ほとんどのアダプター

では使用可能なメモリー量が増加していますが、ハードウェア能力を超える場合

のマイナス・リスクは非常に大きく、かつパフォーマンスの改善率はほとんどの

場合 20 %程度に限られており、大でも 50 %である点に注意してください。開

発時のテストでは、測定可能な実質的パフォーマンス向上は確認できませんでし

た。この原因の 1 つとして、イーサネットが低遅延ネットワークであることが挙

げられます。TR および FDDI は高遅延であるため (トークンへのアクセスを待機

する必要があるため)、TR および FDDI ではイーサネットよりもパフォーマンス

改善率が高い可能性があります。tcpwindowsize を増加した場合、MVS のすべて

の通信先がこの増加による利点を享受できる可能性があります。

ローカル・クライアントを使用する場合に Tivoli Storage Manager のバックアップ

およびリストア操作の適なパフォーマンスを実現するには、名前付きパイプに

よる通信方式を使用します。Windows では、「ネットワークプロパティ」ボック

スで、NetBEUI プロトコルをワークステーション・サービスのプロトコル・バイ

ンディング・リストの 1 番目のプロトコルとして移動します。

TSM クライアント/サーバーに関する各種注意事項

• アンチウィルス・ソフトウェアは、バックアップ・パフォーマンスに悪影

響を及ぼす可能性があります。 • 未使用のサービスは使用不可にするか、またはインストールしないでおき

ます。 • 未使用のネットワーク・プロトコルは使用不可にするか、またはインストー

ルしないでおきます。 • バックグラウンド・アプリケーション・パフォーマンスを優先します。 • スクリーン・セーバーを使用しないようにします。 • ページング・ファイルがフラグメント化されていないことを確認します。 • 装置ドライバー、特に新しいハードウェアの装置ドライバーとして、常に

新の装置ドライバーを使用します。


BUFPoolsize (表 1 を参照)

24

LOGPoolsize 512 TXNGroupmax 256 MOVEBatchsize 1000 MOVESizethresh 2048 TCPWindowsize 63 USELARGEBuffer Yes

Solaris サーバー


Solaris 環境で TSM のパフォーマンスを適化する際に役立つ推奨事項を次に示

します。

• Soralis プラットフォームのサーバー・データベース、回復ログ、およびディ

スク・ストレージ・プール・ボリュームにはロー区画を使用します。お客

様の実際の経験と開発時のテストの測定結果から、Solaris では UFS または Veritas ファイル・システム・ボリュームよりもロー論理ボリュームの方が

クライアント・バックアップ/リストアのスループットとサーバー管理プロ

セス・パフォーマンスが高いことが判明しています。 • UFS ファイル・システム・ボリュームを使用する場合には、forcedirectio フ

ラグを使用してこれらのファイル・システムをマウントします。forcedirectio を使用してファイル・システムをマウントしている場合には、ユーザー・

アドレス・スペースとディスクの間でデータが直接転送されます。

noforcedirectio を使用してファイル・システムをマウントしている場合には、

ユーザー・アドレス・スペースとディスク間でのデータ転送時に、データ

がカーネル・アドレス・スペースにバッファリングされます。forcedirectio は、大きな順次データの転送でのみ効果的なパフォーマンス・オプション

です。省略時値は noforcedirectio です。 • TSM バージョン 3.7 サーバー・ファイル集合のサイズを大にするには、

dsmserv.opt で TSM サーバー・オプション TXNGroupmax 256 を使用し、

dsm.sys で TSM クライアント・オプション TXNBytelimit 25600 を使用しま

す。ファイル集合により、多くのサーバー・データ移動機能およびインベ

ントリー機能 (ストレージ・プール・マイグレーション、ストレージ・プー

ル・バックアップ、ファイル・スペース/ボリュームの削除、インベントリー

期限切れ処理など) のスループットが向上します。 • TSM サーバー・データベース、回復ログ、およびディスク・ストレージ・

プール・ボリューム間のディスク I/O 接続を防ぐには、データベース、回

復ログ、ディスク・ストレージ・プールそれぞれに個別の物理ディスクを

使用する必要があります。

25

• TSM クライアント・オプション LargeCommbuffers yes を自動的に使用しな

いでください。Solaris の TSM クライアントでは、このオプションの省略

時値は NO です。場合によっては、クライアントでこのオプションの適切

な値を判断するためにテストが必要な場合があります。特定のクライアン

ト・ワークロード・テスト (LargeCommbuffers NO を使用するテストなど) ではスループットが向上することがあります。このオプションの適切な設定

値を決定するときには、ディスク・ファイル・フラグメント化の量、オペ

レーティング・システムにより実行されるファイル先読みの量、クライア

ント・ファイルの平均サイズ、クライアントの物理メモリーのサイズ、お

よびディスク・ドライブの種類と速度に関する問題を考慮する必要があり

ます。Solaris 2.5 および 2.6 には、ファイル先読みの量を調整するためのチュー

ニング・パラメーターはありません。 • Tivoli Storage Manager サーバー・データベース・ボリュームは、も高速

なディスクに配置します。データベース・ボリュームが接続しているディ

スク・アダプターに対して書き込みキャッシュがある場合、特にデータベー

ス・ボリュームがミラーリングされている場合には、データベース・パフォー

マンスを大限に引き出すため、このキャッシュを使用可能にします。 • Tivoli Storage Manager サーバー・データベース・バッファー・プールのサ

イズを、表 24 に示すインストールされているシステム・メモリーの合計サ

イズに基づいて調整します。 • Tivoli Storage Manager の多数のクライアントのバックアップとリストア処







システムではデータ量を削減する方が効果的です。


BUFPoolsize (表 1 を参照) LOGPoolsize 512 TXNGroupmax 256 MOVEBatchsize 1000 MOVESizethresh 2048 TCPWindowsize 64 USELARGEBuffer Yes

26

TCPNODELAY Yes

AIX サーバー




• AIX プラットフォームのサーバー・データベース、回復ログ、およびディ

スク・ストレージ・プール・ボリュームにはロー区画を使用します。お客

様の実際の経験と開発時テストでの測定結果では、ロー論理ボリュームの

方がクライアント・バックアップ/リストア・スループットとサーバー管理

プロセス・パフォーマンスが高いことが判明しています。 • トランザクション・サイズを大化するには、Tivoli Storage Manager サー

バー・オプション txngroupmax 256 と Tivoli Storage Manager クライアント・

オプション txnbytelimit 25600 を使用します。トランザクション・サイズを

大きくすると、Tivoli Storage Manager サーバー・ファイル集合のサイズが

増加します。ファイル集合により、多くのサーバー・データ移動およびイ

ンベントリー機能 (ストレージ・プール・マイグレーション、ストレージ・

プール・バックアップ、インベントリー期限切れ処理など) のスループッ

トを向上します。磁気テープに直接バックアップする場合にトランザクショ

ン・サイズを大きくすると、テープ・バッファー・フラッシュの回数が減

少し、スループットが向上します。 • 大きなファイルのスループットとサーバー効率を引き上げるには、Tivoli

Storage Manager サーバー・オプション uselargebuffers yes (省略時値) を使用

します。 • Tivoli Storage Manager の多数のクライアントのバックアップとリストア処







システムではデータ量を削減する方が効果的です。 • 新世代 SP ノードを導入している場合には、SP クライアントと SP AIX サー

バーの両方に対し、128K の TCPW を使用することをお勧めします。特に

これは、SP マシンに ATM カードを装着している場合にお勧めします。よ

り新しい高速 SP マシン (および高速 HPS) でも、128K の TCPW が適切で

しょう。

27

• TSM サーバー・データベース、回復ログ、およびディスク・ストレージ・



使用することが重要です。 • Tivoli Storage Manager サーバー・データベース・ボリュームは、も高速

なディスクに配置します。ディスク・アダプターの書き込みキャッシュが

あり、このアダプターに接続されているディスクにデータベース・ボリュー

ムのみが格納されている (ストレージ・プール・ボリュームは格納されて

いない) 場合には、データベース・パフォーマンスを大限に引き出すた

めに、この書き込みキャッシュを使用可能にします。 • Tivoli Storage Manager サーバー・データベース・バッファー・プールのサ

イズを、表 1 に示すインストールされているシステム・メモリーの合計サ

イズに基づいて調整します。


BUFPoolsize (表 1 を参照) LOGPoolsize 512 TXNGroupmax 256 MOVEBatchsize 1000 MOVESizethresh 2048 TCPWindowsize 64 (SP ノードの場合は前述の推奨事項も参照) USELARGEBuffer Yes TCPNODELAY Yes

HP-UX サーバー




• HP-UX TSM サーバーではディスク・ストレージ・プールにロー区画を使

用します。開発時に行われた測定では、HP-UX で VXFS ボリュームを使用

した場合に比べ、ロー区画ボリュームの方がバックアップ/リストア操作の

スループットが高かったため、ロー区画を推奨します。ただし、TSM デー

タベースと回復ログ・ボリュームのデータの整合性と回復可能性を維持す

るため、TSM データベースと回復ログ・ボリュームをファイル・システム

上で割り振る必要があります。

28

• トランザクション・サイズを大化するには、Tivoli Storage Manager サー










Storage Manager サーバー・オプション uselargebuffers yes を使用します。 • I/O 競合を小限に抑えるため、サーバーに十分な個別の物理ディスクを

割り振ります。 • Tivoli Storage Manager サーバー・データベース・ボリュームは、も高速

なディスクに配置します。データベース・ボリュームが接続しているディ

スク・アダプターに対して書き込みキャッシュがある場合には、データベー

ス・パフォーマンスを大限に引き出すため、このキャッシュを使用可能

にします。 • Tivoli Storage Manager サーバーのデータベース・バッファー・プールのサ

イズを適切な値に調整します。Tivoli Storage Manager データベース・バッ

ファー・プールは、データベース・ページのキャッシュとして機能するの

で、ページが必要な場合には、そのページがすでにバッファー・プールに

格納されています。このため、I/O が防止されます。大規模な Tivoli Storage Manager サーバー・ワークロードの確立後に、データベース・バッファー・

プール・サイズをチューニングするには、Tivoli Storage Manager サーバー

の query db コマンドを実行して得られるキャシュ・ヒット率値を使用して

ください。オペレーティング・システムのページング統計 (iostat、vmstat、sam を使用) を監視し、メモリー所要量の増加が原因で過剰なページングが

発生していないことを確認します。 • Tivoli Storage Manager の多数のクライアントのバックアップとリストア処







システムではデータ量を削減する方が効果的です。 • TSM サーバー・データベース、回復ログ、およびディスク・ストレージ・


29


使用する必要があります。


BUFPoolsize (表 1 を参照) LOGPoolsize 512 TXNGroupmax 256 MOVEBatchsize 1000 MOVESizethresh 2048 TCPWindowsize 64 USELARGEBuffer Yes TCPNODELAY Yes

TSM クライアントのチューニング

この章では、TSM の使用時にパフォーマンスを大限に引き出すための TSM クライアントのチューニングを中心に説明します。1 番目のセクションでは、すべ

ての TSM クライアントに適用可能なチューニング・パラメーターを説明します。

2 番目のセクションでは、クライアントのパフォーマンスに関する一般的な考慮

事項を説明します。次に、プラットフォーム固有の推奨事項を説明します。4 番目のセクションでは、クライアント・コマンド行でのみ使用できる新バージョン

の 2 つのオプションを説明します。

チューニング・オプション

使用可能なすべてのリリースの TSM クライアントでチューニング可能なパラメー

ターを次に示します。

• COMPRESSION • COMPRESSALWAYS • COMMRESTARTDURATION / COMMRESTARTINTERVAL • QUIET • LARGECOMmbuffers • MEMORYEFFICIENTBACKUP (旧 SLOWINCREMENTAL) • 複数セッション・リストア • RESOURCEUTILIZATION • TAPEPrompt • TCPBuffsize • TCPNodelay

30

• TCPWindowsize • TXNBytelimit

注: UNIX クライアントの場合は TSM クライアント・オプションを DSM.OPT ファ

イルまたは DSM.SYS ファイルに記述します。

COMPRESSION

TSM クライアントで圧縮が使用可能であるかどうかを指定します。省略時値は No です。

Tivoli Storage Manager の多数のクライアントのバックアップとリストア処理で

適なパフォーマンスを実現するには、Tivoli Storage Manager クライアント圧縮の

使用を検討してください。クライアントでデータを圧縮すると、ネットワークと Tivoli Storage Manager サーバーでの要求が減ります。サーバーのデータ量を減ら

すことで、このデータを移動するとき (ストレージ・プール・マイグレーション

やストレージ・プール・バックアップなど) のパフォーマンスが向上します。た

だし、クライアント圧縮では各クライアントのパフォーマンスが大幅に低下する

ので、も低速のクライアント・システムではデータ量を削減する方が効果的で

す。

単一の高速クライアント、高速ネットワーク、および高速サーバーでパフォーマ

ンスを大限に引き出すには、圧縮をオフにします。

TSM 圧縮の使用に代わる方法として、次の 2 通りの方法があります。

• バックアップ先が磁気テープであり、磁気テープ装置が独自の圧縮をサポー

トしている場合には、磁気テープ装置の圧縮を使用します (該当するガイ

ドラインについては、『磁気テープ装置: 圧縮』を参照)。 • クライアントにファイル圧縮サポートが組み込まれている場合には、TSM

圧縮を使用しないでください。このようなクライアントで TSM 圧縮を実

行しても、サーバーにバックアップされるデータの量は減りません。ファ

イル圧縮機能が組み込まれているプラットフォームは NetWare と Windows です。

失敗した圧縮が原因で再試行が多数実行される場合には、圧縮によりパフォーマ

ンスが大幅に低下する可能性があります。圧縮ファイルが元のサイズよりも大き

いと、圧縮は失敗します。TSM クライアントがこれを検出すると、圧縮処理が停

止され、トランザクションが失敗し、圧縮解除されたトランザクション全体が再

送信されます。これは、圧縮に適していないファイル・タイプの場合、またはファ

イルがすでに圧縮されている場合 (zip ファイル、tar ファイルなど) に発生します。

31

圧縮をオフにしなかった場合には、以下の 2 通りの方法で、圧縮が原因で生じる

再試行を削減または除外することができます。

• COMPRESSALWAYS オプション (下記を参照) を使用します。このオプショ

ンは、圧縮が原因で生じる再試行を除去します。 • クライアント・オプション・ファイルで EXCLUDE.COMPRESSION オプショ

ンを使用します。このオプションは、特定のファイルまたはファイル・セッ

トに対して圧縮を使用不可にします。クライアント出力 (dsmsched.log) を参照し、圧縮が再施行される原因であるファイルを見つけ、これらのファ

イル・タイプをフィルタリングします。

推奨値

COMPression No (単一の高速クライアント、高速ネットワーク、高速サーバー)

COMPression Yes (複数のクライアント、低速ネットワーク、低速サーバー)

COMPRESSALWAYS

compressalways オプションは、圧縮中にオブジェクトのサイズが大きくなった場

合に圧縮を続行するか、または圧縮を解除した状態でオブジェクトを再送信する

かどうかを指定します。このオプションは、圧縮オプションとともに使用します。

compressalways オプションは、アーカイブ・コマンド、増分コマンド、および選

択コマンドとともに使用します。注: このオプションはサーバーでも定義できま

す。compressalways yes (省略時値) を指定すると、ファイルのサイズが増加した後

でも、ファイルの圧縮が続行されます。ファイルのサイズが増加した場合に圧縮

を停止し、圧縮解除した状態でファイルを再送信するには、compressalways No を指定します。このオプションが圧縮を制御するのは、クライアント・ノードが選

択肢を決定することを管理者が指定した場合だけです。

再試行による影響を低減するには、compressalways yes を使用します。

推奨値 COMPRESSAlways Yes

COMMRESTARTDURATION / COMMRESTARTINTERVAL

ネットワーク接続割り込みに対するクライアントの耐久性が強化されています。 2 つの新しいオプション COMMRESTARTDURATION と COMMRESTARTINTERVAL は、ウィンドウの再始動時間と再始動から次の再始

動までの間隔を制御します。この機能拡張は大量のネットワーク輻輳や頻繁な割

32

り込みが発生する環境で役立ちます。また、この機能拡張によりエラー状態での

割り込みが減るため、多数のクライアントの管理が容易になります。エラー状態

の検出、訂正、およびエラー状態が発生した結果の再始動にかかる時間を検討す

ることで、パフォーマンスがある程度まで向上します。

注: commrestartduration 値が経過する前にクライアントがサーバーに再接続する場

合は、イベントの始動ウィンドウの期間が経過していても、スケジュールされて

いるイベントが続行されます。

構文 COMMRESTARTDURATION minutes COMMRESTARTINTERVAL seconds minutes

通信障害の発生後にクライアントがサーバーへの再接続を試行できる大

期間を分単位で指定します。値の範囲はゼロから 9999 です。省略時値は 60 です。

seconds 通信障害の発生後にクライアントがサーバーへの再接続を待機する大期

間を秒単位で指定します。値の範囲はゼロから 65535 です。省略時値は 15 です。

推奨値

COMMRESTARTDURATION (環境に合わせて調整します)

COMMRESTARTINTERVAL (環境に合わせて調整します)

QUIET

QUIET オプションを指定します。省略時値は VERBOSE です。

QUIET オプションを指定すると、TSM バックアップ中にメッセージが画面に表

示されなくなります。省略時解釈では、バックアップする各ファイルの情報が表

示されます。これを防ぐには、QUIET オプションを使用します。ただし、メッセー

ジと概要情報はログ・ファイルに書き込まれます。

QUIET オプションを使用する上での主な 2 つの利点を次に示します。

• 磁気テープへのバックアップでは、初のデータ・トランザクション・グ

ループが常に再送信されます。これを防ぐには、QUIET オプションを使用

してクライアントでの再送信を減らします。 • クライアント・スケジューラーを使用して TSM バックアップをスケジュー

ルする場合には、QUIET オプションを使用するとスケジュール・ログへの

33

ディスク I/O オーバーヘッドが大幅に低下し、TSM スループットが向上し

ます。

推奨値 Quiet

LARGECOMmbuffers

• LARGECOMmbuffers オプションは、クライアントとサーバーの間で大量デー

タを転送するときに、クライアントが使用するバッファーを増加できるか

どうかを指定します。クライアントによるディスクのデータの読み取りま

たは書き込みのためにディスク I/O バッファーを 32KB から 256KB に増や

す場合に、このオプションを使用します。バッファーの大サイズは 1MB です。このクライアント・オプションはこれまでは USELARGEbuffer とい

う名前でしたが、サーバー・オプションとの混同を避けるため、

LARGECOMmbuffers に変更されました。 • このオプションの効果を取り入れるには、ファイル・システムの先読み操

作を調整する必要があります。 • ほとんどのプラットフォームでは、先読み操作を調整することはできませ

ん。 • 開発時のテストでは、LARGECOMmbuffers YES を設定した状態で AIX ディ

スク先読みの量を増加した場合に、適な AIX TSM クライアント・パフォー

マンスを実現できました。(『AIX の VMUNE』を参照してください。) • メモリーが少ない状態でワークステーションが稼働している場合には、こ

のオプションを使用不可にできます。 • LAN フリー操作では LARGECOMmbuffers YES を使用しないでください。

推奨値

LARGECOMmbuffers Yes (AIX のみ)

LARGECOMmbuffers No (AIX を除くすべてのプラットフォームと LAN フリーを

備えたすべてのプラットフォーム)

MEMORYEFFICIENTBACKUP (旧 SLOWINCREMENTAL)

TSM クライアントで MEMORYEFFICIENTBACKUP オプションを使用可能にする

かどうかを指定します。省略時値は No です。

MEMORYEFFICIENTBACKUP オプションを指定すると、TSM はディレクトリー

を一度に 1 つずつバックアップします。省略時解釈では、TSM は一度にすべての

ディレクトリーをバックアップします。この省略時オプションは、メモリーを集

34

中的に使用します。メモリー容量が限られており、大きなファイル・システムを

備えたクライアントでメモリー使用量を節約するには、

MEMORYEFFICIENTBACKUP をオンにします。

大きなファイル・システムの増分バックアップを実行すると、TSM クライアント

が多量のメモリーを必要とします。通常、ファイル当たりのインベントリー・デー

タを約 300 バイトとする規則を使用します。これにより、100 万ファイルが格納

されているファイル・システムでは、バックアップする必要のあるファイルを判

別するためのサーバー・インベントリー・データを維持するために必要な仮想メ

モリーは 300 MB となります。このメモリー所要量を減らすには、TSM クライア

ント・オプション MemoryEfficientBackup Yes を使用します。ただし、このオプショ

ンを使用すると、増分バックアップの経過時間に大きく影響します。次にいくつ

かの代替方法を示します。

• ファイル・システムを区画に分割し、各区画を順次処理します。

virtualmountpoint オプションを使用します (UNIX のみ)。 • 包含/除外リストを使用して必要なファイルのみをバックアップします。 • 複数のファイル・システムを使用します。 • ジャーナル・ベース・バックアップを使用します (Windows のみ)。

推奨値 MEMORYEFFICIENTBACKUP No

複数セッションのバックアップ/リストア

IBM Tivoli Storage Manager 5.1 で導入された複数セッション・リストア機能により、

バックアップ・アーカイブ・クライアントが照会なしリストア操作のマルチリス

トア・セッションを実行できるので、リストア処理の速度が向上します。これは

複数バックアップ・セッション・サポートに似ています。サポートされているク

ライアント・プラットフォーム、照会なしの概念についての詳細は、「Tivoli Storage Manager バックアップ/アーカイブ・クライアントインストールとユーザーのガイ

ド」を参照してください。

複数セッション・リストア機能は、サーバーで使用可能なマウント・ポイントを

使用します。リストアするデータが複数の磁気テープにあり、十分なマウント・

ポイントが使用可能であり、リストア操作に照会なしリストア・プロトコルが使

用される場合には、複数セッションを使用してデータをリストアできます。使用

可能なマウント・ポイントが十分にない場合には、サーバーではなくクライアン

トが ANS1312E メッセージを発行します。

35

リストア実行中に使用されるセッションの数は、使用可能なマウント数、サーバー

でのクライアント・ノードの MAXNUMMP 設定、およびクライアント・オプショ

ン・ファイルの RESOURceutlization パラメーター設定によって決まります。複数

セッション・リストアを実行するとセッション数が増加するので、dsmserv.opt ファ

イルの MAXSessions パラメーターには適切な設定値を使用してください。詳しく

は、『Resourceutilization』を参照してください。

複数セッション・リストアに関する考慮事項を次に示します。

• ディスク・ストレージ・プールからのリストア実行時には 1 つのセッショ

ンだけが使用されます。 • コマンド行では一度に 1 つのファイル・システムだけをリストアできます。

ただし、1 つのファイル・システムに対して複数セッションを使用できま

す。 • 小さなクライアントでも、多数のテープ・マウントまたは位置を必要とす

るリストア操作のスループットが向上します。 • 連結ノードからリストアする場合には特に、テープ・カートリッジの競合

に注意してください。

複数セッション・バックアップに関する考慮事項を次に示します。

• 1 つのセッションでのみ増分バックアップの属性が比較されます。変更デー

タの量が少ない単一ファイル・システムでは、増分バックアップのスルー

プットは向上しません。 • データ転送セッションにはファイル・システム親和性がないので、各セッ

ションで複数のファイル・システムからファイルが送信される可能性があ

ります。これはワークロード・バランシングにとって適切です。ただし、

ファイル・スペースによって連結されているテープ・ストレージ・プール

に直接バックアップする場合にはこれは適切ではありません。この場合、

複数セッション・クライアントを使用してファイル・スペースによって連

結されているテープ・ストレージ・プールに直接バックアップせずに、複

数のコマンド (1 つのファイル・スペースに 1 つのコマンド) を使用してく

ださい。 • トランザクション・キューに十分なエントリーがない場合には、複数セッ

ションを開始できません。

RESOURCEUTILIZATION

Resourceutilization は、TSM クライアントおよびサーバーが処理中に使用できるリ

ソースのレベル (並行セッションの数など) を調整するためのクライアント・オプ

ションです。1 回の TSM バックアップ/リストア・コマンドまたはアーカイブ/リトリーブ・コマンド呼び出しで、自動的に複数のセッションが作成されます。

36

複数セッション機能は自動的に開始され、エンド・ユーザーに認識されませんが、

ユーザーがこの機能をカスタマイズするためのパラメーターがいくつかあります。

RESOURCEUTILIZATION オプションを使用して複数セッション機能を調整する

方法があります。このオプションは、Tivoli Storage Manager クライアントの複数

セッション作成機能を強化または制限します。バックアップまたはアーカイブの

場合、RESOURCEUTILIZATION はクライアントにより作成されるセッション数

を直接指定しません。ただし、この設定は Tivoli StorageManager サーバーとクラ

イアントがバックアップまたはアーカイブ実行中に使用できるリソースのレベル

を指定します。値が大きいほど、必要に応じてクライアントが開始できるセッショ

ンの数が多くなります。パラメーターの範囲は 1 から 10 です。このオプションを

設定しない場合 (省略時) には、サーバーへの 2 つのセッションが作成されます。

resourceutilization の省略時レベルでは、サーバーとのセッションを 2 つまで作成

できます。このうち 1 つのセッションはサーバーへの照会用、もう 1 つのセッショ

ンはファイル・データ送信用です。Resourceutilization=5 を指定すると、サーバー

とのセッションを 4 つ (照会用セッション 2 つとデータ送信用セッション 2 つ) まで使用できます。resourceutilization=10 を指定すると、サーバーとのセッションを 8 つ (照会用セッション 4 つとデータ送信用セッション 4 つ) まで使用できます。

Resourseutilization と作成されるセッションの大数との関係は内部アルゴリズム

の一部であり、変更される可能性があります。Resourceutilization 値と作成される

セッションの大数の関係を次の表に示します。プロデューサー・セッションは

クライアント・システムをスキャンし、適格なファイルを検索します。残りのセッ

ションはコンシューマー・セッションであり、データ転送に使用されます。この

しきい値はセッションの新規作成にかかる時間に影響します。

37

表 2. Resource Utilization の設定

RU 値

大セッション数

固有のプロデューサー・

セッション数しきい値 (秒)

1 1 0 45 2 2 1 45 3 3 1 45 4 3 1 30 5 4 2 30 6 4 2 20 7 5 2 20 8 6 2 20 9 7 3 20 10 8 4 10

省略時値 (0) 2 1 30

Resourceutilization レベルを引き上げることで実現するバックアップ・スループッ

トの改善率は、クライアント・ノードによって異なります。複数セッションのス

ループットに影響する要因には、クライアント・ストレージ・サブシステムの構

成 (物理ディスクでのファイル・システムのレイアウト)、クライアントの複数セッ

ション起動能力 (十分な CPU、メモリー)、サーバーの複数クライアント・セッショ

ン処理能力 (CPU、メモリー、ストレージ・プール・ボリューム数)、および増大

するトラフィックに対応可能な十分なネットワーク帯域幅などがあります。

MAXSESSIONS パラメーターは、Tivoli Manager サーバーに接続する同時実行ク

ライアント・セッションの大数を制御します。クライアントの並列セッション

の合計数は、サーバーに接続できる大セッション数として扱われます。このた

め、サーバー・オプション・ファイルの MAXSESSIONS パラメーター値を増やす

かどうかを検討する必要があります。

Resourceutilization オプションを使用して、磁気テープへの直接バックアップに複

数クライアント/サーバー・セッションを使用可能にした場合には、クライアント・

ノードの大許容マウント・ポイント数を示すパラメーター MAXNUMMP をサー

バーで更新する必要があります (Update Node コマンドを使用)。

TSM クライアントで複数のディスク (RAID 0 または RAID 5) にわたってファイル・

システムが分散している場合、または複数の大きなファイル・システムがある場

合には、TSM クライアント・オプション Resourceutilization の値を 5 または 10 に設定することをお勧めします。これにより、バックアップまたはアーカイブ実行

38

中のサーバーとの複数セッションが可能になり、場合によってはスループットが

大幅に向上します。1 つの大きなファイル・システムで変更データのパーセンテー

ジが小さい場合には、このファイル・システムの増分バックアップが向上する見

込みはありません。磁気テープに直接バックアップする場合には、ノード更新コ

マンドを使用して、クライアント・ノードの大許容マウント・ポイントを示す

パラメーターである MAXNUMMP もサーバーで更新する必要があります。

リストアが要求される場合、省略時解釈では、要求されたデータが格納されてい

る磁気テープの数、使用可能な磁気テープ装置の数、およびノードで有効なマウ

ント・ポイントの大数に基づいて、大 2 つのセッションが使用されます。

RESOURceutilization パラメーターの省略時値は 1、大値は 10 です。

例えば、リストア対象データが 5 つのテープ・ボリュームに格納されており、リ

ストアの要求元ノードのマウント・ポイントの大数が 5 であり、

RESOURceutilization が 3 に設定されている場合には、リストア操作には 3 つのセッ

ションが使用されます。RESOURceutilization 設定を 5 に増やすと、リストア操作

に 5 つのセッションが使用されます。許可されているリストア・セッション数と RESOURceutilization 設定の間には 1 対 1 (1:1) の関係があります。

Resourceutilization の値

• 3.7 以降のサーバーに接続する場合にのみ、2 よりも大きい値を使用できま

す。 • root 以外の UNIX のセッションは 1 セッションに制限されています。

推奨値

RESOURceutilization 1 (ワークステーション)、5 (小規模サーバー)、 10 (大規模サーバー)

TAPEPrompt

ユーザーに対してテープ・マウント指示を表示するかどうかを指定します。

TAPEPrompt オプションは、バックアップ、アーカイブ、リストア、またはリト

リーブ操作時に TSM がテープのマウントが完了するまで待機するか、またはユー

ザーに対して選択肢を選ぶよう指示を表示するかどうかを指定します。

推奨値 TAPEPrompt No

39

TCPBufsize

TCPBuffsize オプションは、内部 TCP 通信バッファーのサイズを指定します。こ

れは、クライアント・ノードとサーバーとの間のデータ転送に使用されます。バッ

ファーのサイズを大きくすると、通信パフォーマンスは向上しますが、メモリー

所要量が増加します。

バッファーのサイズを KB 単位で指定します。省略時値は 31KB、大値は 512KB です。

推奨値 TCPBufsize 32

TCPNodelay

オペレーティング・システムの TCPNodelay パラメーターを Yes または No のどち

らに設定するかを指定します。サーバーでの省略時値は Yes です。

TCPNodelay オプションが Yes に設定されている場合、 MTU サイズよりも小さい

データ・パケットをただちに送信できます。

推奨値 TCPNodelay Yes

注: このオプションは TSM サーバーでも有効です。

TCPWindowsize

このオプションは TCP スライディング・ウィンドウのサイズを KB 単位で指定し

ます。TCPWindowsize オプションは、オペレーティング・システムの TCP 送信ス

ペースおよび受信スペースを指定変更します。例えば AIX では、これらのパラメー

ターは tcp_sendspace と tcp_recvspace であり、"no" オプションとして設定されて

います。TCPWindowsize 0 を指定すると、TSM はオペレーティング・システムの

省略時値を使用します。TSM の適な設定が、その他のアプリケーションの適

な設定と同じではない可能性があるため、これはお勧めできません。省略時値は 32KB、大値は 2048KB です。TCPWindowsize オプションは、すべてのクライア

ントと MVS サーバーを除くすべてのサーバーの TCP スライディング・ウィンド

ウのサイズを指定します。ウィンドウのサイズが大きいと、通信パフォーマンス

は向上しますが、メモリー使用量が増加します。この場合、肯定応答を受信側か

ら取得する前に、複数のフレームを送信できます。送信遅延が長引く場合には、

TCPWindowsize を増やすとスループットが向上することがあります。

40

推奨値 1 TCPWindowsize 64 TCPWindowsize 63 (Windows)

推奨値 2 (高速スイッチを備えた SP2 環境)

TCPWindowsize 128 から 640

注: このオプションは TSM サーバーでも有効です。

TXNBytelimit

txnbytelimit オプションは、クライアント・プログラムがトランザクションをサー

バーに送信する前にバッファーに入れることができるデータの量を KB 単位で指

定します。値の範囲は 300 から 2097152 (2 GB) です。省略時値は 2048 です。注: このオプションは、自己チューニング時に必要に応じてサーバーにより定義および

調整されます。トランザクションとは、クライアントとサーバーの間で交換され

る作業単位です。クライアント・プログラムは、データをサーバー・ストレージ

にコミットする前にクライアントとサーバーの間で複数のファイルまたはディレ

クトリーを送信できるので、トランザクションには複数のファイルまたはディレ

クトリーを含めることができます。これはトランザクション・グループと呼ばれ

ます。このオプションでは、サーバーがデータと変更内容をサーバー・データベー

スにコミットする前にクライアントとサーバーの間で送信されるデータの量を制

御できます。つまりクライアントが処理を実行する速度を変更制御できます。送

信データ量は、バックアップ実行時にファイルをバッチとしてまとめる場合、ま

たはリストア・プロシージャーの実行中にサーバーからファイルを受信する場合

に適用されます。サーバー管理者は、txngroupmax オプションを使用して、グルー

プ・トランザクションに含めるファイルまたはディレクトリーの数を制御できま

す (『TXNGroupmax』を参照)。トランザクションの実際のサイズは、制限値より

も小さいことがあります。この値に達すると、トランザクション・データ量の制

限に達していない場合でも、クライアントはファイルをサーバーに送信します。

このパラメーターを設定する場合に考慮すべき事項がいくつかあります。

• トランザクションあたりのデータの量を増加すると、サーバーでの回復ロ

グの所要量が増加します。ログとログ・プール・スペースを調べ、十分な

スペースがあることを確認します。また、ログが大きくなると、サーバー

の始動時間が長くなる可能性がある点にも注意してください。 • トランザクションあたりのデータの量を増加すると、再試行時に再送信す

るデータの量が増加することがあります。これはパフォーマンスに悪影響

を及ぼす可能性があります。

41

• このパラメーターを変更する利点は、構成とワークロードの特性によって

異なります。特に、ワークロードに小さなファイルが多数ある場合には、

このパラメーターの効果は、ディスク・ストレージ・プール・バックアッ

プよりも磁気テープ・ストレージ・プール・バックアップの方が大きくな

ります。

静的、共有静的、または共有動的を使用したバックアップ時のファイル変更が原

因で、多数の再送信操作を実行する必要がある場合には、トランザクションのサ

イズを設定するときに小さなサイズを設定することを検討してください。これは、

静的または共有に適用されます。これは、バックアップ中に変更されたファイル

をクライアントが認識し、このファイルを送信しないことに決定した場合でも、

そのトランザクションのほかのファイルを再送信する必要があるためです。TSM および LTO または DLT を使用してパフォーマンスを拡張するには、TXNBytelimit に大値 2097152 を設定し、サーバー側で TXNGroupmax に 256 を設定します。

また、小さなファイル・ワークロードの場合、お客様が初にデータをディスク・

ストレージ・プールにステージングしてから、LTO にマイグレーションすること

をお勧めします。

推奨事項 (V4) TXNBytelimit 25600 TXNBytelimit 2097152 (LTO または DLT 使用時)

パフォーマンスに関する一般考慮事項

バックアップ/リストアのパフォーマンス: マルチクライアントのバックアップ/リストア

同一ワークステーション上に 2 つ以上のクライアントがあると、バックアップ/リストアのスループットが向上します。これは、大きなファイル・システムが複

数のディスクに分散しているワークステーションにとって有利です。ファイル・

スペースごとにバックアップ/リストアを実行することを検討する場合があります。

ただし、複数のバックアップ/リストアを実行する場合のトレードオフは、メモリー

使用率と CPU 使用率が上昇することです。

ネットワーク・トラフィック: クライアントからのデータ・フローの削減

包含/除外リストを使用して、不要なバックアップを除去します。仮想マウント・

ポイントを使用して、バックアップする必要のあるデータの量を制限することも

できます。

42

オーバーヘッド: クライアント処理

-FROMNODE オプションを使用すると、すべてのクライアントで追加オーバーヘッ

ドが生じます。

プラットフォーム固有の推奨事項

AIX クライアント

dsmsys.opt 推奨オプション

tcpwindowsize 64 (SP2 128-640) tcpbufsize 32 largecommbuffers yes (TSM 4.2 クライアントの場合は下の注を参照) txnbytelimit 25600 RESOURCEUtilization (環境に合わせて調整します)

Windows クライアント

チューニングのヒント

• TSM クライアントで NTFS を使用する場合、小さなファイル・ワークロー

ドでは FAT に比べパフォーマンスが低下する点に注意してください。これ

は、バックアップ中にセキュリティー情報を検査し、リストア中に NTFS ファ

イル・システム回復機能の影響を検査する必要があるためです。 • TSM サーバーが使用するディスク・ボリュームでは NTFS ファイル圧縮を

使用しないでください。これは、NTFS ファイル圧縮を使用するとパフォー

マンスが低下する可能性があるためです。 • ローカル・クライアントを使用する場合に TSM のバックアップおよびリ

ストア操作の適なパフォーマンスを実現するには、名前付きパイプによ

る通信方式を使用します。 • TSM の多数のクライアントのバックアップとリストア処理で適なパフォー

マンスを実現するには、TSM クライアント圧縮の使用を検討してください。

クライアントでデータを圧縮すると、ネットワークと TSM サーバーでの

要求が減ります。サーバーのデータ量を減らすことで、このデータを移動

するとき (ストレージ・プール・マイグレーションやストレージ・プール・

バックアップなど) のパフォーマンスが向上します。ただし、クライアン

ト圧縮では各クライアントのパフォーマンスが大幅に低下するので、も

低速のクライアント・システムではデータ量を削減する方が効果的です。

43

• アンチウィルス・ソフトウェアは、バックアップ・パフォーマンスに悪影

響を及ぼす可能性があります。

dsm.opt 推奨オプション

tcpwindowsize 63 tcpbufsize 32 largecommbuffers no txnbytelimit 25600 RESOURceutilization (環境に合わせて調整します)

Windows ジャーナル・ベース・バックアップ

この説明は Windows クライアントを対象としています。現在のファイルの状態を TSM データベースと相互参照するのではなく、変更ジャーナルで変更済みとして

示されているファイルをバックアップします。変更されたファイル/ディレクトリー

をリアルタイムで判断する機能を使用し、ファイル・システム・スキャンと属性

比較を防止します。従来の増分方式に比べ大幅に高速ですが、パフォーマンス向

上の程度は変更データの量によって異なります。また、必要とするメモリーとディ

スクの使用量が少なくなります。 Tivoli Journal Engine Service をインストールする必要があります。このサービスは、

ファイル変更についてファイル・システムのアクティビティーをモニターします。

ファイル・システムのパフォーマンスへの影響はごくわずかです。(Netbench テス

ト実行時は約 5 %でした。) これは、頻繁に変更されないファイルが多い大きなファイル・システムで特に効

果的です。ジャーナル・オプションは tsmjbbd.ini に指定されています。省略時値でも適切に

機能しますが、モニター対象ファイル・システムを追加します。

DEC クライアント

DEC ULTRIX でパフォーマンスにも大きく影響するパラメーターは大伝送単

位 (MTU) です。イーサネット LAN の場合、MTU の大値は 1500 です。

44

• 大伝送単位

MTU サイズ値を変更するには、ifconfig コマンドを使用します。アダプターの受

信バッファー・サイズに大きな値を設定できる場合には、ワークステーションの MTU サイズを増やすことをお勧めします。前述したように、小さな MTU のネットワー

クを介してフレームを送信する場合には、ルーターによるパケットの分解と宛先

でのパケットの組み立てでオーバーヘッドが生じるため、MTU サイズを増やすと

パフォーマンスが低下する可能性があります。

Novell クライアント

PROCESSORutilization

TSM が CPU を制御する時間を 1/100 秒単位で指定します。省略時値は 1 です。

小値は 0、大値はありません。

このパラメーターを 1 未満の値に設定すると、パフォーマンスに悪影響を及ぼす

可能性があります。この値を増やすと、CPU に対する TSM の優先順位が上がり、

ほかのプロセスの優先順位が下がります。PROCESSORutilization に 20 よりも大

きい値を設定すると、ほかのスケジュールされているプロセスまたは NetWare リクエスターがファイル・サーバーにアクセスできなくなります。

推奨値

PROCESSORutilization 1 から 20


tcpwindowsize 64 tcpbufsize 32 largecommbuffers no txnbytelimit 25600

SOLARIS クライアント

SunOS では、TCP/IP ソフトウェア・パラメーターを変更するには、リリース・カー

ネル・ビルド・ディレクトリー (一般に /usr/sys) の min inetinet/in_proto.c ファイル

を編集します。パラメーターの変更後には、カーネルを再ビルドする必要があり

ます。パフォーマンスに影響するパラメーターを次に示します。

45

tcp_default_mss TCP の省略時大セグメント・サイズ (MSS) をバイト単位で指定します。

宛先が同一ネットワーク上にある場合には、MSS はネットワークの大伝

送ユニット (MTU) のサイズに基づきます。フラグメント化を防ぐには、控

えめな値である 512 を使用します。イーサネットまたはトークンリングの

パフォーマンスを向上するには、512 よりも大きな MSS 値を使用すること

をお勧めします。(例えば、設定値として 1024、1500、2048、または 4096 を使用できます。) イーサネット LAN の大 MTU 値は 1500 です。

tcp_sendspace ユーザーが TCP ソケット・バッファーに送信できる大バイト数を指定し

ます。この値を超すと、ブロックされます。特定のソケットの省略時値を

変更するには、SO_SNDBUF ioctl を使用します。省略時値は 4096 です。推奨値

このパラメーターには 16KB または 32KB を設定します。 tcp_recvspace

リモート TCP が TCP ソケット・バッファーに送信できる大バイト数を

指定します。この値を超すと、ブロックされます。特定のソケットの省略

時値を変更するには、SO_RCVBUF ioctl を使用します。省略時値は 4096 です。

推奨値

このパラメーターには 16KB または 32KB を設定します。

DSM.SYS ファイルの TSM オプション

TSM でのバックアップおよびリストア機能のパフォーマンスに効果的なパラメー

ターを次に示します。


tcpwindowsize 32 tcpbufsize 32 largecommbuffers no txnbytelimit 25600

注: fddi および高速イーサネットの場合はクライアント tcpw に 32K を設定します。

ギガビット・イーサネットの場合は 64K を使用します。

TCP バッファー tcp_xmit_hiwat および tcp_recv_hiwat は、tcpwindowsize に一致し

ている必要があります。

46

TSM クライアント・オプション LargeCommbuffers yes を自動的に使用しないでく

ださい。Solaris の TSM クライアントでは、このオプションの省略時値は NO です。場合によっては、クライアントでこのオプションの適切な値を判断するため

にテストが必要な場合があります。特定のクライアント・ワークロード・テスト (LargeCommbuffers NO を使用するテストなど) ではスループットが向上すること

があります。このオプションの適切な設定値を決定するときには、ディスク・ファ

イルのフラグメントの量、オペレーティング・システムにより実行されるファイ

ル先読みの量、クライアント・ファイルの平均サイズ、クライアントの物理メモ

リーのサイズ、およびディスク・ドライブの種類と速度に関する問題を考慮する

必要があります。Solaris 2.5 および 2.6 には、ファイル先読みの量を調整するため

のチューニング・パラメーターはありません。

コマンド行オプション

コマンド行で実行する特定のコマンドにのみ使用できる一連のオプションがあり

ます。コマンドにオプションを指定するときには、常にオプションの前にダッシュ (-) を入力してください。次の 2 つのコマンド行オプションを使用すると、TSM パフォーマンスが向上することがあります。

• IFNEWER • INCRBYDATE

また、コマンド行インターフェースは GUI よりも一般的に高速であり、必要なオー

バーヘッドが少ない点に注意してください。

IFNEWER

このオプションは、リストア・コマンドと組み合わせて使用します。サーバー日

付がローカル・ファイルの日付よりも新しい場合にのみ、ファイルをリストアし

ます。ネットワークを介して送受信する必要のあるデータの量が少ない場合には、

このオプションを使用すると、ネットワーク使用率が低下する可能性があります。

INCRBYDATE

定期的な増分バックアップでは、サーバーがファイル・システム内のすべてのファ

イルの属性を読み取り、この情報をクライアントに渡します。次にクライアント

はサーバー・リストと現在のファイル・システムのリストを比較します。この比

較処理には長い時間がかかることがあります。これは特に、NetWare、OS/2、DOS、Macintosh および Windows クライアントで顕著です。一般にこれらのクライアン

トでは、メモリーが限られています。

47

日付による増分バックアップでは、サーバーは後にバックアップが正常に実行

された日付のみを渡します。TSM サーバーの活動ファイルをすべて照会する必要

はありません。このため、時間を大幅に節約できます。ただし、属性だけが変更

されているファイルをバックアップする場合にも定期的な増分が必要です。例え

ば、ファイル・システムの新しいファイルの作成日が終バックアップ実行日よ

りも古いとします。クライアント側ではこのファイルはすでにバックアップされ

ているものと認識されるので、今後指定される INCRBYDATE ではこのファイル

はバックアップされません。

TSM AIX 共用メモリーのチューニングに関する考慮事項

多くのお客様が、AIX クライアントとサーバーを同一プロセッサー上でローカル

に実行しなければならないという要件を抱えています。現在、ほとんどのお客様

は通信プロトコルとして TCP/IP を使用しています。クライアントをサーバーと

同じシステムで実行する場合には、共用メモリー・プロトコルを使用する必要が

あります。共用メモリー・プロトコルは、システム・リソースを効率的に使用し

ます。AIX サーバーの dsmserv.opt と AIX クライアントの dsm.sys に指定する必要

のあるパラメーターを次に示します。

COMMMethod COMMMethod protocol protocol

TSM クライアントとサーバー間の通信方式を指定します。クライアントと

サーバーが同一システム上にある場合は、共用メモリー・プロトコルを使

用します。このオプションは、TSM AIX v2.1.0.6/v2.1.5.6 以上および TSM AIX クライアント (v 2.1.0.3 以上) でのみ使用できます。TSM AIX v2.1.5.6 以上

は、AIX v.4.1.4 のみに適用されます。推奨値

COMMMethod shrmem

SHMPort SHMPort address address

TSM サーバーが共用メモリー通信接続を受け入れる TCP/ IP ポートのアド

レスを指定します。このオプションは、TSM AIX サーバー v2.1.0.6/v2.1.5.6 以上および TSM AIX クライアント (v 2.1.0.3 以上) でのみ使用できます。

TSM AIX v2.1.5.6 以上は、AIX v.4.1.4 のみに適用されます。推奨値

SHMport 1510

48

第 3 章 TSM の適化サーバーの適化

• データベース・パフォーマンス • ディスクの使用 • バックアップ・パフォーマンス: バックアップ・バージョンの数 • 災害時回復:

インポート/エクスポートとストレージ・プールのバックアップ/リストア • キャッシュ付きディスク・ストレージ・プール • マイグレーション: マイグレーション・プロセス数のチューニング • マイグレーション: マイグレーションしきい値のチューニング • 磁気テープ装置: コロケーション • TSM HSM チューニングに関する考慮事項 • 問題判別: サーバー活動記録ログおよびその他のシステム・ログ • サーバー・アクティビティー:

TSM セッションおよびプロセスのスケジュール

データベース・パフォーマンス

データベース・ミラーリングでは信頼性が向上しますが、パフォーマンスが低下

します (特に並列ミラーリングの場合)。データベース書き込みアクティビティー

による影響を小限に抑えるには、不揮発書き込みキャッシュ機能を備えたディ

スク・サブシステム (ESS 2105、SSA Fast/write cache (AIX)、ServerRAID (Intel) など) を使用します。書き込みキャッシュを備えたディスク (またはディスク・アダ

プター) を使用すると、(並列ミラーリング時) のデータベース書き込みアクティビ

ティーのパフォーマンスが 2 倍以上向上します。データベース・ディスクで大き

な帯域幅が残っている可能性がある場合でも、これは該当します。

ディスクの使用

サーバーの構成 - ディスク: I/O 競合を小限に抑えるため、可能な限り多くの個

別物理ディスクを使用します。物理ディスクあたり 1 つの TSM ボリューム ( 大

でも 2 つ) を構成します。回復ログ、データベース、ディスク・ストレージ・プー

ルにはそれぞれ個別のボリュームを使用します。TSM ボリュームは物理ディスク

の外径に配置します。これにより、順次スループットが増加し、シーク・タイム

が短くなります。AIX システムでロー論理ボリュームを使用すると、CPU 消費量

が減りますが、ストレージ・プール・マイグレーション中の処理速度が低下する

可能性があります (先読み機能がないため)。

49

物理ディスク (JBOD) または RAID アレイの選択: 同等のパフォーマンスを実現す

る場合、RAID で必要な物理ディスクの数は (JBOD よりも) 多くなります。RAID5 アレイでの書き込み操作のデメリットを考慮してください。バックアップ/アーカ

イブ時には書き込みスループットが重要となります。TSM 回復ログおよびデータ

ベースのミラーリングは、ハードウェア冗長性よりも回復力が優れています。

サーバーの構成 - ディスク書き込みキャッシュ: TSM データベース・ボリューム (ランダム I/O) を備えたすべての RAID5 アレイおよび物理ディスクには、ディスク・

サブシステム/アダプター書き込みキャッシュを使用します。TSM ストレージ・

プール・ボリューム (順次 I/O) を備えた物理ディスクに対してはディスク・サブ

システム/アダプター書き込みキャッシュを使用しないでください。

TSM サーバー・データベース: 複数の物理ディスクを使用します。すべてのボリュー

ムでデータベース・サイズを均等に分割します。シーク・タイムを小に抑える

ため、ディスクの外径にボリュームを配置します。不揮発性書き込みキャッシュ

を備えたディスク・サブシステム (ESS 2105、SSA 7133、ServeRAID) を使用しま

す。適なデータベース・バッファープール・サイズを使用します。mirrorwrite db parallel を使用し、ミラーリングした書き込みのオーバーヘッドを削減するために

データベース・ページのシャドーイングを使用します。複数の回復ログ、データ

ベース・ボリュームを使用します。

バックアップ・パフォーマンス: バックアップ・バージョンの数

可能であれば、バックアップ・ファイルのバージョンの数を実際に必要な数に制

限します。1 つのオブジェクトのバージョンが複数ある場合には、ファイル・バッ

クアップのパフォーマンスが低下します。バージョン数を制御するには、DEFINE COPYGROUP コマンドを使用して VEREXISTS パラメーターを変更するか、また

は UPDATE COPYGROUP コマンドを使用します。省略時のバックアップ・バー

ジョンの数は 2 です。

災害時回復: インポート/エクスポートとストレージ・プールのバックアップ/リストア

TSM サーバーには、災害時回復に備えてストレージ・プールをバックアップおよ

びリストアする機能が組み込まれています。多くのお客様は、災害時回復時にイ

ンポート/エクスポートを使用します。災害回復時には、インポート/エクスポー

トよりもストレージ・プールのバックアップ/回復の方がパフォーマンスが優れて

います。

50

キャッシュ付きディスク・ストレージ・プール

キャッシュ付きディスク・ストレージ・プールを使用すると、テープ・マウント

が防止されるので、回復処理のパフォーマンスが向上します。この効果は、近

バックアップされたファイルをリストアするときに現れます。ディスク・プール

に 1 日分のデータを格納できる十分な大きさがある場合、キャッシュは適切なオ

プションです。DEFINE STGPOOL コマンドを使用して CACHE オプションを変更

し、キャッシュを使用可能にするか、または DEFINE STGPOOL コマンドを使用

します。ただし「Cache Disk Storage Pool (キャッシュ・ディスク・ストレージ・

プール)」が「YES」に設定されている場合に TSM データベースが増大すると、

データベースがフラグメント化され、サーバー応答に影響を及ぼす可能性があり

ます。この状態が疑われる場合には、ディスク・ストレージ・プールのキャッシュ

をオフにすることをお勧めします。キャッシュ・ファイルを消去するには、次の

手順で操作します。

• query stgpool <disk stgpoolname> f=d (admin client) を実行します。 • UPDate STGpool を使用してキャッシュをオフにします。 • STGpool=parm を指定せずに MOVe Data <stgpool_vol_name> を実行します。

同一ストレージ・プール内の別のボリュームにファイルが移動され、キャ

シュ・ファイルが削除されます。

マイグレーション: マイグレーション・プロセス数のチューニング

ディスク・ストレージ・プールから磁気テープ・ストレージ・プールへファイル

をマイグレーションするマイグレーション・プロセスの数を制御するには、DEFINE STGPOOL コマンドを使用し、MIGPROCESS パラメーターを変更します。ディス

クから磁気テープへデータをマイグレーションするときに複数の磁気テープ装置

が使用可能な場合には、複数のプロセスを使用できます。各マイグレーション・

プロセスはそれぞれ異なるクライアント・ノードのデータを処理するので、場合

によっては、これによりディスク・ストレージ・ボリュームの内容の消去にかか

る時間が向上します。MIGPROCESS オプションには 1 から 999 の範囲 (1 と 999 を含む) の整数を指定できますが、使用可能な磁気テープ装置の数を超えてはなり

ません。省略時値は 1 です。マイグレーション・プロセスの数を変更するには、

UPDATE STGPOOL コマンドも使用できます。

マイグレーション: マイグレーションしきい値のチューニング

マイグレーションしきい値を調整するには、DEFINE STGPOOL コマンドを使用

し、HIGHMIG および LOWMIG パラメーターを変更します。マイグレーションし

きい値をチューニングすると、パフォーマンスが向上することがあります。しき

い値が高すぎると、マイグレーションの遅延が発生します。これが原因で AD SM ディスク・ストレージ・ボリュームが満杯になることがあります。この場合、ク

51

ライアントがデータをこのディスク・ストレージ・ボリュームに送信しようとす

ると、満杯状況が示されるので、クライアントはストレージ階層内の次のレベル

のボリュームにアクセスしようとします。テープ・ボリュームの場合には、マイ

グレーション・プロセスがすでにこのボリュームを使用中である可能性がありま

す。すでに使用中の場合、クライアント・セッションはマイグレーション・プロ

セスによりテープ・メディアが解放されるまで待機します。次に、クライアント

がアイドルになります。この場合、マイグレーションが早期に開始されるように

するため、マイグレーションしきい値を低くするか、または TSM ディスク・ス

トレージ・プールに割り振るディスク・スペースを増やす必要があります。マイ

グレーションしきい値を変更するには、UPDATE STGPOOL コマンドも使用でき

ます。

ネットワーク・トラフィック: サーバーへのネットワーク・トラフィックの削減

TSM サーバーには、開始するクライアント・セッションの数を制限できる各種 SET コマンドがあります。これらのコマンドを次に示します。

• SET QUERYSCHEDPERIOD は、スケジュールされている作業を取得する

ためにクライアントがサーバーにコンタクトできる頻度を設定します (ポー

リング・モード)。これはクライアント設定を指定変更します。 • SET MAXCMDRETRIES は、クライアント・スケジュール・コマンドの再

試行回数に対するグローバル制限を設定します。これはクライアント設定

を指定変更します。 • SET RETRYPERIOD は、サーバーとのコンタクトが失敗した後でスケジュー

ラーを再試行するときの再試行間隔を分数単位で指定します。これはクラ

イアント設定を指定変更します。

磁気テープ装置: コロケーション

コロケーションを使用すると、大量データのリストア時のパフォーマンスが大幅

に向上します。これは、必要なデータを見つけるために検索するテープの数が少

なくなるためです。また、ほかのクライアントとのメディア競合が発生する可能

性も低下します。このトレードオフは、必要な磁気テープの数が増えることです。

連結を使用可能にするには、DEFINE STGPOOL コマンドを使用して COLLOCATE オプションを変更するか、または UPDATE STGPOOL コマンドを使用します。ス

トレージ・プールの省略時値はコロケーションなしです。

TSM HSM チューニングに関する考慮事項

HSM を使用して選択されているファイルをマイグレーションおよび再呼び出しす

ることができます。ただし、ファイルを手動で保管、およびアクセスする方法は、

処理するファイルの数が少ない場合にのみ行ってください。ワイルドカードを指

52

定して DSMMIGRATE コマンドを呼び出し、小さなファイルをグループ化した場

合など、ファイルが非常に小さい場合には HSM マイグレーションのパフォーマ

ンスが大幅に低下します。これは、トランザクション境界でファイルをグループ

化するアーカイブ、リトリーブ、回復、およびバックアップ処理とは異なり、HSM は一度に 1 つのファイルを処理するためです。HSM マイグレーション/再呼び出

しを使用する場合には、ファイルごとに 1 つのトランザクションが実行されます。

サーバーに小さなファイルのグループを保管するには、アーカイブまたはバック

アップを使用する方が適切です。

小さなファイルのグループをサーバーにマイグレーションする必要がある場合に

は、磁気テープではなくディスクにマイグレーションする方がパフォーマンスが

優れています。HSM によりファイルをディスクにマイグレーションした後には、

ストレージ・プール・マイグレーションを使用してファイルを磁気テープに移動

できます。

問題判別: サーバー活動記録ログおよびその他のシステム・ログ

パフォーマンス上の問題が多数発生する場合には、異常なシステム状態が原因で

ある可能性があります。このような問題の原因を判別するには、TSM サーバー活

動記録ログ、クライアント・エラー・ファイル、またはオペレーティング・シス

テムの適切なシステム・ログを調べます。

サーバー・アクティビティー: TSM セッションおよびプロセスのスケジュール

すべてのクライアント・バックアップが同時に開始されると、TSM スループット

が低下する可能性があります。も適切な対策は同時バックアップを防止するこ

とです。また、スケジュールのランダム化機能を使用して一定の期間にわたって TSM クライアントのバックアップを分散する方法も適切です。バックアップを適切に

スケジュールすることで、サーバーのパフォーマンスが向上することがあります。

可能であれば、クライアント・バックアップが活動化状態でない時期に、期限切

れ処理、ストレージ・プール・バックアップ、データ移動、エクスポート/インポー

トなどのサーバー・プロセスをスケジュールします。

LAN フリー・バックアップ

• SAN を使用して磁気テープまたはディスクへのバックアップ/リストアが

実行されます。 • LAN を介してメタデータがサーバーへ送信されます。 • データ処理から TSM サーバーが解放されるので、スケーラビリティーが

向上します。

53

• LAN バックアップ/リストアよりも処理が高速となる可能性があります。 • 大きなファイル・ワークロード、データベース (TDP) で効果的です。 • 小さなファイル・ワークロードでは、データ移動以外にもボトルネックが

あります。 • クライアント側で TSM ストレージ・エージェントが必要です。 • ディスクを使用した LAN フリー操作を行うには、Tivoli SANergy を実装す

る必要があります。 • 磁気テープ装置への十分なデータパスがあることを確認します。 • 多数 (21 以上の) dsmc コマンドをスクリプトに組み込むときには、使用し

ないでください。 • テープ・マウントが原因で、dsmc start/stop のオーバーヘッドが高くなりま

す。 • ファイル・リストをバックアップする場合には、新しいファイル・リスト

機能を使用してください。

TSM ストレージ・エージェントのチューニング

• TSM ストレージ・エージェントには固有の構成ファイル dsmsta.opt があり

ます。このファイルに記述されているオプションの多くは、サーバーの dsmserv.opt と同じです。

• 一部のオプションには、dsmsta setstorageserver コマンドを使用します。 • 一般には、サーバーの推奨設定値と同じ設定を使用します。 • ストレージ・エージェントと TSM サーバーで TCPNODELAY が YES (省略

時値) に設定されていることを確認します。 • LAN フリー・クライアントのすべてのプラットフォームでは、

LARGECOMmbuffers を NO に設定します。

注: TSM サーバーと同じマシンにストレージ・エージェントをインストー

ルすることはできません。

Domino for S/390 の TDP

Lotus Domino Database (NSF) の TDP (TSM) バックアップ実行時のパフォーマンス

上の問題。 Domino、Domino for S390 および HFS の TDP でのパフォーマンス上の問題は、

DFSMS HFS HIPER APAR OW51210 および OW51732 とその対応 PTF で指摘およ

び解決されています。対応 PTF がシステムにインストールされていることを確認

してください。

54

外部 TSM チューニングのヒント

• ネットワーク • AIX の VMTUNE • JFS とロー論理ボリューム • スループットの見積もり • その他の環境でのスループットの見積もり • 磁気テープ装置のチューニングのヒント

ネットワーク

• バックアップ用に専用ネットワーク (LAN または SAN) を使用します。 • 常に新の装置ドライバーを使用します。 • イーサネットの速度および全二重の設定: 特定のスイッチのすべての接続

で、これらの設定が同一であることを確認してください。 • ギガビット・イーサネット・ジャンボ・フレーム (9000 バイト): クライア

ント、サーバー、およびスイッチでサポートされている場合にのみ使用可

能です。一部のギガビット・イーサネット・ハードウェアではジャンボ・

フレームがサポートされていません。ジャンボ・フレームを使用すると、

スループットが向上し、ホスト CPU 使用率が低下します。

AIX の VMTUNE

RISC System/6000 仮想アドレス・スペースは、仮想メモリー・マネージャー (VMM) により管理されます。VMM を管理するには、AIX コマンド VMTUNE を使用し

ます。

• vmtune コマンドを使用して、AIX 仮想メモリー・システムを調整します。 • これは bos.adt.samples ファイル・セット内にあります。 • vmtune のオプションを表示するには、オプションを指定せずに vmtune コ

マンドを使用します。 • オプションを変更するには、該当するオプション/値を指定します。 • vmtune パラメーターの変更内容は、リブート後まで維持されません。

(設定は次回のリブートまで有効であるので、/etc/inittab に入れます。これ

により AIX 先読みオプションが変更されるので、これが原因でほかのアプ

リケーションのパフォーマンスが低下しないことを確認します。) • vmtune コマンドは以下の位置にあります。

AIX 4.x: /usr/samples/kernel/vmtune

55

AIX: 先読み (vmtune maxpgahead)

• AIX では、順次ファイル読み取りが発生することを検出すると、アプリケー

ションがデータを要求していない場合でも先読みが実行されます。 • JFS ファイル・システムの順次読み取りパフォーマンスが向上します。 • TSM クライアント: 大きなファイルのバックアップ時のスループットが向

上します。 • TSM サーバー: ストレージ・プール・マイグレーションのスループットが

向上します。 • maxpgahead を大値に設定することをお勧めします (-R256)。 • 先読みパラメーター (-R) を変更する場合には、先読みデータを格納できる

十分な空きメモリーを確保するため、maxfree パラメーター (-F) も変更す

る必要があります。 • 次の公式に従ってください。minfree+maxpgahead<=maxfree • ロー論理ボリュームの場合、先読みパフォーマンスは向上しません。 • TSM サーバーで RLV を使用すると、CPU 消費量が減りますが、ストレー

ジ・プール・マイグレーション中の処理速度が低下する可能性があります (先読み機能がないため)。

推奨値

-R256 ( 大値)

AIX ファイル・キャッシュ (vmtune Minperm/Maxperm)

• AIX によりファイル・システム・キャッシュ用に維持されるメモリーの量

を決定します。 • AIX は、ファイル・システム・データをキャッシュに入れることができる

ように、アプリケーション (TSM など) のメモリーをページアウトします。

これによりデータベース・バッファー・プールのページングが発生し、こ

れが原因でデータベース・パフォーマンスが低下することがあります。 • データベース・バッファー・プールのページングが原因で、データベース・

キャッシュ・ヒット統計上、過度に効率良く見えることがあります。 • TSM サーバーでは、ファイル・システム・キャッシュによる大きな効果は

得られません。 • maxperm の値を小さくすると、AIX が維持できるアプリケーション・メモ

リーの量が増加します。 • TSM サーバーの仮想メモリー・ページングを停止するには、

minperm/maxperm パラメーターを変更します。例外: RAM の制約があるシ

ステム。例外: データベース・バッファープールのサイズが大きすぎる場

合 (適切な設定については、前述の BUFPOOLSIZE のチューニングに関す

るセクションを参照してください)。

56

• ファイル・システムのキャッシュ用に (省略時値の 80%ではなく) 大 50% (-P50) を確保しておくことをお勧めします。効果がない場合には、この値

を低くします (リアルタイムで変更します)。maxperm が minperm に近づい

ている場合には、minperm の値も低くすることを検討してください。vmstat で進行状況を監視します。ページアウトがゼロに近づくと、ページインも

低下します。

クライアントとサーバーが同一プロセッサー上にある場合は、vmtune パラ

メーターを vmtune-R 256 -F376 -c 1 と設定してください。

JFS とロー論理ボリューム

TSM サーバーでディスク・ストレージ・ボリュームとして RLV を使用している

場合には、JFS を使用している場合よりもパフォーマンスが優れていることがあ

ります。RLV が使用されている場合、サーバーは AIX VMM システムを使用しま

せん。このため、各ディスク I/O の CPU 使用率が低下します。一方、サーバー・

ディスク・ボリュームからの読み取り時には、RLV は先読みメカニズムを使用し

ません。この結果、ディスクから磁気テープへのサーバー移動操作とリストア操

作のパフォーマンスが低下することがあります。

一般に、TSM 回復ログまたは TSM データベースが RLV にある場合には、パフォー

マンスが向上しました。

JFS の代わりに RLV を使用する際に留意すべき警告事項を次に示します。

• TSM を使用するロー論理ボリュームをミラーリングする場合には AIX を使用しないでください。代わりに TSM ミラーリング機能を使用してくだ

さい。AIX によりディスクの制御ブロックに追加される情報は、TSM の制

御情報を上書きします。 • SMIT を使用して RLV のサイズを変更しないでください。EXTend DB およ

び EXTend LOG コマンドについては、IBM Tivoli Storage Manager for AIX の管理者に関するマニュアルを参照してください。

• TSM 管理者は、同一の RLV を使用する可能性のある複数の TSM サーバー・

コード・インスタンスを開始しないように注意してください。AIX では、

RLV を使用するときにロックが施行されません。TSM はこれを修正する

ため、/tmp ディレクトリーのファイルを使用してロックを実装します。/tmp ディレクトリーのファイルをクリーンアップするプログラムを実行すると、

これらのロックが削除される可能性があります。例えば、Skulker プログラ

ムは使用しないでください。

Solaris direct I/O を使用し、AIX direct I/O は使用しないでください。

57

スループットの見積もり

開発時のパフォーマンス試験でテストされたファイル・サイズと異なる平均ファ

イル・サイズのワークロードに対するスループットを容易に見積もることができ

ます。ただし、開発時の評価報告書にある環境の 1 つに TSM 環境全体が準拠し

ている必要があります。

まず評価報告書で、特定の要件に一致する TSM 機能と環境の表を見つけます。

次に、見積もり対象のクライアント・ワークロードの平均ファイル・サイズを判

別します。次に示す式では、この値は EstFileSize です。また、単位は KB です。

次のいずれかの規則を適用します。

1. 平均ファイル・サイズが 256 MB を超える場合、256 MB ワークロードのス

ループット (KB/秒または GB/時) を使用します。 2. 平均ファイル・サイズが 1 KB 未満の場合、1 KB ワークロードに対して KB/

秒単位のスループットを使用します。特定の時間内に処理可能なファイル

数によってスループットが効果的に制限されます。次に示す式に従い、見

積もりファイル・サイズのスループットを KB/秒単位で計算します。

Throughput(KB/sec) = 1KBThroughput(KB/sec) * EstFileSize(KB)

次に示す式に従い、KB/秒を GB/時に換算します。

Throughput(GB/hr) = Throughput(KB/sec) * 3600 / 1048576

3. 平均ファイル・サイズが 1 KB よりも大きく 256 MB 未満の場合には、推定

ポイントにも近い表内の 2 つの既知の測定ポイントを使用してスループッ

トを計算します。

A. 該当する機能と環境の表から、次の値を確認します。

LowerFileSize - 下限測定ポイントの平均ファイル・サイズ (KB) LowerThroughput - 下限測定ポイントのスループット (KB/秒) UpperFileSize - 上限測定ポイントの平均ファイル・サイズ (KB) UpperThroughput - 上限測定ポイントのスループット (KB/秒)

B. 以下の式に従い、スループットを KB/秒単位で計算します。

A = log(UpperThroughput(KB/sec)/LowerThroughput(KB/sec)) B = log(EstFileSize(KB)/LowerFileSize(KB)) C = log(UpperFileSize(KB)/LowerFileSize(KB))

58

D = log(LowerThroughput(KB/sec)) Throughput(KB/sec)= 10 ** ((A * B / C) + D)

上記の式の log はすべて常用対数 10 を示します。

その他の環境でのスループットの見積もり

直接テストしていない環境のスループットの測定は、やや複雑であることがあり

ます。ただし、以下の点に注意してください。

• ネットワーク経由のスループットは、定格容量の約 80%の飽和率に達する

ことが見込まれます。効率は、実際に到達可能な大スループット率のパー

センテージを示します。したがって、特定のネットワークで達成可能な

大スループットは次のようになります。

ネットワーク Mb/秒 MB/秒 GB/秒効率 (%)

イーサネット 10 1.0 5.7 40

トークンリング 16 1.6 5.7 80

イーサネット 100 10.0 17.6 40

FDDI 100 10 35.2 80 ATM 155 15.5 34.1 50 SPSwitch 120 264 50 T3 45 4.48 15.8 80 T1 1.54 .16 .56 80 ギガビット・イーサネット

1GB 100 tbd 80

• ネットワークが飽和状態でない場合には、小さなファイル・ワークロード

のバックアップとリストアのスループットは、基本的にネットワーク・タ

イプには依存しません。また、介在するルーターまたはスイッチが原因で

発生する伝搬遅延が過度ではありません。

磁気テープ装置のチューニングのヒント

次の条件に対応できる十分な磁気テープ装置を構成します。

• ピーク・バックアップ・ウィンドウ実行中の任意の時点で磁気テープに直接バッ

クアップされる TSM クライアント・セッションの大数。

59

• バックアップ・ウィンドウ実行中に実行されるその他の機能 (ストレージ・プー

ル・マイグレーション、ストレージ・プール・バックアップ、レクラメーション) のために磁気テープ装置を追加します。

磁気テープ装置のクリーニング:

• 磁気テープ装置のパフォーマンスを大限に引き出すため、製造元の仕様に従っ

て磁気テープ装置をクリーニングすることが重要です。磁気テープ装置をクリー

ニングしないと、磁気テープ装置読み取り/書き込みエラー、ドライブ障害、およ

び一般的な低パフォーマンスの原因となります。

磁気テープ装置の圧縮:

• テープ圧縮を使用可能にするには、DEFINE DEVCLASS コマンドを使用して FORMAT パラメーターを変更します。多くの場合、磁気テープ装置で圧縮を使用

可能にすると、TSM スループットが向上します。磁気テープ装置で圧縮を使用可

能にするには、磁気テープ装置で適切な記録形式を設定します。DEFINE DEVCLASS コマンドの FORMAT オプションにより、順次アクセス・メディアへ

のデータ書き込み時の記録形式が指定されます。省略時値は DRIVE です。これ

は、ボリュームがマウントされている順次アクセス・ドライブでサポート可能な

も圧縮率が高い形式を TSM が選択することを指定します。通常、これにより

テープ制御装置が圧縮を実行できます。

警告

同じライブラリー内で装置が混合して使用されている場合は、DRIVE 値は指定

しないでください。例えば、ライブラリー内のほかのドライブよりも高い記録形

式をサポートしているドライブがある場合には、FORMAT=DRIVE オプションを

指定しないでください。詳しくは、該当する「Tivoli Storage Manager 管理者の手

引き」を参照してください。

クライアントで圧縮を使用しないが、データが圧縮可能な場合には、テープ制御

装置で圧縮を使用すると、システム・スループットが向上します。特定の磁気テー

プ装置についての詳細は、該当する「Tivoli Storage Manager 管理者の手引き」を

参照してください。クライアントでデータを圧縮する場合には、磁気テープ装置

では圧縮を使用しないことをお勧めします。この場合、磁気テープ・メディアで

大 10 から 12 %のテープ容量が失われることがあります。

60

第 4 章: ストレージ装置のヒント IBM LTO ドライブ

磁気テープ装置での転送速度の持続に影響を及ぼす要素には、次のものがありま

す。

• ネイティブ転送速度 • 圧縮率 • ブロック・サイズ • ファイル・サイズ • サーバー接続機構 • サーバー接続 HBA タイプ • ディスク転送速度 • ネットワーク帯域幅 • サーバー使用率 • スタート/ストップ時のパフォーマンス • アプリケーション制御ファイル・アクティビティー • バス帯域幅 • メディアの品質

転送速度を持続するには、上記の要素による実際の影響を考慮してください。

パフォーマンスの考慮事項

IBM LTO Ultrium 磁気テープ装置のネイティブ・データ・ストリーミング速度は

大 15MB/秒、2:1 圧縮時で大 30MB/秒です。ストリーミング速度とは、磁気

テープ装置が読み取り/書き込みを実行できる速度であり、スタート/ストップ操

作は含まれません。ほとんどの場合、磁気テープ使用時にはスタート/ストップ操

作が生じるため、ドライブ稼働時の持続速度が低下します。

例えば、磁気テープ装置への書き込みでは、磁気テープ装置のバッファーにデー

タがある場合、データが磁気テープに実際に書き込まれる前に、ドライブは制御

をアプリケーションに戻します。この操作モードでは、すべての磁気テープ装置

のパフォーマンスが大幅に向上します。ただし、ドライブのバッファーは揮発性

バッファーです。アプリケーションでデータが必ず磁気テープに書き込まれるよ

うにする必要がある場合には、アプリケーションはバッファーをフラッシュする

必要があります。バッファーをフラッシュすると、磁気テープ装置がバックヒッ

チ (スタート/ストップ) します。TSM パラメーター TXNBytelimit と TXNGroupmax

61

により、このバッファー・フラッシュ・コマンドを TSM が実行する頻度を制御

できます。

磁気テープ装置への書き込みでは、ネットワーク帯域幅を考慮する必要がありま

す。例えば、100BaseT イーサネットの持続可能速度は 5 から 6 MB/秒です。した

がって、これよりも高速な速度で LTO (およびあらゆる磁気テープ装置) へバック

アップすることはできません。


TSM で LTO/ULTRIUM ドライブを使用するときには、パフォーマンスを拡張す

るため次の設定を使用することが重要です。

TSM サーバー:

• TXNGroupmax 256 • MOVESizethresh 2048 • MOVEBatchsize 1000

TSM クライアント:

• TXNBytelimit 2097152

TSM クライアントのファイルの平均サイズが 100KB 未満の場合には、後で磁気

テープにマイグレーションできるようにこれらのクライアントをディスク・スト

レージ・プールにバックアップしておくことをお勧めします。これにより、磁気

テープへのデータ移動の効率性が向上します。

IBM 3580 LTO ドライブを使用する場合には、ドライブ・マイクロコードが新

レベルであることを確認してください。LTO ドライブ・マイクロコードの新リ

リースの確認手順とこれらの新リリースのインストール方法については、「IBM Ultrium Device Drivers Installation and Users Guide」を参照してください。このマニュ

アルは次の URL にあります。

• Ftp://ftp.software.ibm.com/storage/devdrvr/

参照資料

• 「Using IBM LTO Ultrium with Open Systems」 (SG24-6502-00 IBM Redbook Redpiece)

• 「Implementing IBM LTO Tape in Linux and Windows」(SG24-6268 IBM Redbook)

• 「Designing an IBM Storage Area Network」(SG24-5758)

62

• 「Planning and Implementing an IBM SAN」(SG24-6116) • 「IBM SAN Survival Guide」(SG24-6143) • 「Using Tivoli Storage Manager in a SAN Environment」(SG24-6132) • 「The IBM LTO Ultrium Tape Libraries Guide」(SG24-5946)

その他の資料

詳細な情報が収録されている関連資料を次に示します。

• 「TotalStorage UltraScalable テープ・ライブラリー 3584 計画およびオペレー

ター・ガイド」(GA88-6972) • 「TotalStorage Ultrium Scalable テープ・ライブラリー 3583 セットアップお

よびオペレーター・ガイド」(GA88-6957) • 「3581 Ultrium テープ・オートローダーセットアップ、オペレーターおよ

びサービス・ガイド」(GA88-6958) • 「3580 Ultrium テープ・ドライブセットアップ、オペレーターおよびサー

ビス・ガイド」(GA88-6959) • 「IBM Ultrium デバイス・ドライバーインストールおよびユーザーズ・ガ

イド」(GA88-8698) • 「SAN データ・ゲートウェイ・モジュールセットアップ、オペレーター、

およびサービス・ガイド」(GA88-8224) • 「Tivoli Storage Manager for AIX SAN 管理システムストレージ・エージェ

ントユーザーズ・ガイド」(GC88-9007) • 「Tivoli Storage Manager for Sun Solaris SAN 管理システムストレージ・エー

ジェントユーザーズ・ガイド」(GC88-9008)

SSA ディスク

キャッシュ付き SSA コントローラーにより、RAID-5 はキャッシュ機構がないシ

ステムよりも魅力的です。ただし、書き込み時にパフォーマンスの面でデメリッ

トがあります。TSM DB が関与する書き込みのサイズについて、キャッシュ付き

コントローラーはキャッシュのないコントローラーの 2 倍程度のパフォーマンス

を実現します。キャッシュ付きコントローラーは約 5 から 10 MB/秒を実現します

が、これは RAID-5 以外の構成の約 50% です。

この書き込みのデメリットが発生する原因は、RAID-5 では書き込み要求あたり 4 回の I/O が必要であることにあります (非 RAID-5/ミラーリング環境では書き込み

要求あたり 1 回の I/O です)。

現時点では、TSM パフォーマンス測定と SSA に関連する推奨事項はありません。

パフォーマンスとコスト/ディスク・スペースとのトレードオフを考慮してくださ

い。ここでは、TSM DB I/O がどの程度重要であるかが課題となります。TSM DB

63

I/O は非常に重要であり、RAID-5 を検討するのが妥当であるという意見がありま

す。終的には、スループットのボトルネックを特定することになります。多く

の場合、ディスク I/O サブシステムがボトルネックであることが判明します。こ

の場合、RAID-5 は適切ではありません。

SilverNode SCSI スロットの配置

H50 での SCSI アダプターの配置がかなり重要であることが判明しています。適または優れたパフォーマンスを実現するためのスロットの配置 (PCI ベースの

システム) に関する資料「PCI Adapter Placement Reference」(SA38-0538-04) を入手できる RS/6000 ホーム・ページ URL は、 http://www.rs6000.ibm.com/ resource/hardware_docs/ です。

332MHz SMP Node (Silver) は F50(Wildcat) および H50(Silver) システムに類似して

いますが、この資料では、332MHz SMP Node (Silver) については特に説明してい

ません。

332MHz SMP Node (Silver ノード) のフィールド・テストでは、ワイド・ノード拡

張シャシーで I6、I7、I8 のラベルが付いているスロットからイーサネット・カー

ドを取り外しました (I5 もこれら 3 つのスロットと同じ PCI コントローラー上に

あります)。これらのスロットに対応する AIX ロケーション・コードを次に示し

ます。

• I5 (2F-00 から 2F-07) • I6 (2F-08 から 2F-0F) • I7 (2F-10 から 2F-17) • I8 (2F-18 から 2F-1F)

332MHz SMP Node の発表レター (ALET 198-086) に、アダプターに関するいくつ

かの規則が記載されています (ALET の PDF コピーを入手するにはここをクリッ

クしてください)。FC 6215 アダプターは、終 4 スロット、PCI SSA Multi-Initiator/RAID EL Adapter には接続できないものとしてリストされています。

要約:

r/spoolsize を調べるには、コマンド lsattr -E -l css0 を使用します。

r/spoolsize をリセットするには、/usr/lpp/ssp/css ディレクトリーから次のコマンド

を使用します。

• chgcss -l css0 -a rpoolsize=in_bytes • chgcss -l css0 -a spoolsize=in_bytes

64

r/spoolsize が 4M 未満の場合は 4M に設定してください。

注: chgcss の変更内容を有効にするには、ノードをリブートする必要があります。

バス

• 複数の PCI バスが装備されているマシンでは、複数のバスに高スループッ

ト・アダプターを分散します。例えば、ディスクへのバックアップを多数

実行する場合には、同じ PCI バスにネットワーク・カードとディスク・ア

ダプターを接続しないようにすることがあります。 • 理論上のバスの制限は、単なる理論に過ぎません。ほとんどの場合、この

制限に近い値に設定できる必要があります。 • 原則として、SCSI バスあたりの磁気テープ装置数を 1 から 2 にすることが

も適切です。

付録 A: TSM アーカイブ機能の使用抄録 ADSM バージョン 1 以降、Tivoli Storage Manager (TSM) にはアーカイブ機能が組

み込まれています。ただし、現行の TSM バージョン 4 にいたるまで、このアー

カイブ機能には機能変更が加えられました。アーカイブ機能は、一定の保管期間

において非活動状態のデータを保管するための強力な機能です。一部の TSM ユー

ザーは、アーカイブ機能を使用するときにパフォーマンスが十分でなかったり、

機能性が低いことに不満を感じていました。この付録では、これまでのアーカイ

ブ機能の変更点を概説し、TSM アーカイブを使用する TSM ユーザーを対象にし

た実装時のヒントを紹介します。

履歴

TSM クライアントの主な 2 つの機能は、バックアップ/リストアとアーカイブ/リトリーブです。バックアップ/リストアの設計上の目的は、データ損失からデータ

を保護することです。バックアップ/リストア機能には、フル・システム・リスト

アのための活動データ・セットの管理およびバージョン管理などがあります。アー

カイブ/リトリーブの設計上の目的は、一定の保管期間にわたって非活動状態のデー

タを保管することです。これは、個別のファイルまたはファイル・グループであ

ることがあります。アーカイブでは、システム全体の大規模なアーカイブも実行

できます。ADSM バージョン 1 およびバージョン 2 では、アーカイブはファイル

のみを対象としており、ディレクトリーはアーカイブ対象外でした。ADSM バー

65

ジョン 1 では、リトリーブ時に必要に応じてディレクトリーが再構築されました

が、再構築処理では省略時プロパティーが使用されました。アーカイブでは、アー

カイブされるファイルに「記述 (Description)」を割り当てることができましたが、

「記述 (Description)」は重要ではなく、省略時の「記述 (Description)」はヌル・ス

トリングでした。

ADSM バージョン 3.1 でアーカイブ機能に大幅な変更が加えられました。ADSM クライアントのグラフィカル・ユーザー・インターフェース (GUI) に、1) すべての

記述、2) 記述内のすべてのファイル・システム、3) ファイル・システム内のすべ

てのディレクトリー、および 4) ファイル・システム内のすべてのファイルを表示

するネスト表示機能が導入されました。これにより、アーカイブ記述が重要にな

りました。この時点で記述は「アーカイブ・パッケージ (Archive Package)」とい

う名前に変更されました。また、省略時の記述は日時スタンプに変更されました。

TSM データベースのパフォーマンスを拡大するため、記述による索引付けのため

の新しい内部テーブルが追加されました。TSM クライアントが初めてバージョン 3.1 GUI インターフェースを使用してアーカイブを実行するときに、この新しい

テーブルにデータが挿入されました。このプロセスは「アーカイブ変換」と呼ば

れました。全体的な機能性をさらに拡張するため、ディレクトリーのアーカイブ

機能が追加されました。ディレクトリー内のすべてのアーカイブ・ファイル・エ

ントリーの有効期限が切れる前にそのディレクトリーの期限が切れないようにす

るため、原則としても長い保管期間の管理クラスがディレクトリーに割り当て

られました。これらの変更内容は、実質的には TSM クライアント・コマンド行

インターフェース (CLI) に対するものでもありました。

ADSM バージョン 3.1 でのこれらの変更により、必要とされていたアーカイブ機

能が実現しましたが、同時に特定の状況では問題も生じました。クライアントが

同じファイル・セットを繰り返しアーカイブするか、または CLI を繰り返し呼び

出すコマンド・ファイル主導型アーカイブを使用すると、TSM データベースが急

激に増大し、アーカイブ・ディレクトリーが多数複製されることがありました。

また、も長い保管期間の管理クラスがディレクトリーに割り当てられることか

ら、問題はさらに複雑になりました。保管期間が NO LIMIT のアーカイブ・コピー・

グループが使用可能な場合に、ディレクトリー・アーカイブの有効期間が永続的

に切れないことがありました。

バージョン 3.1.0.7 レベルでは、一意のディレクトリーだけをアーカイブするため

にクライアント・コードが追加されました。ファイルのアーカイブ処理で、初

にクライアントがサーバーを照会し、ディレクトリー・アーカイブが存在するか

どうかを確認しました (記述は一意のディレクトリー ID に含まれていました)。また、省略時の記述からタイム･スタンプが除去されました。このコード・レベルで

は TSM サーバーにさまざまな変更が行われました。余分なディレクトリー・アー

カイブをクリーン・アップするためのユーティリティーが開発されました。イン

66

ベントリーの期限切れ処理が変更され、ディレクトリーの期限が切れる前に、アー

カイブ・ディレクトリーが参照されているかどうかを確認するようになりました。

これにより、ディレクトリー内のファイルの期限が切れる前にそのディレクトリー

の期限が切れることがなくなったので、ディレクトリー・アーカイブにはも短

い保管期間の管理クラスが割り当てられるようになりました。しかしながら、バー

ジョン 3.1.0.7 より前のディレクトリー・アーカイブにはタイム・スタンプが含ま

れていたため、これらのユーティリティーは無効でした。また、ほかの変更が原

因で、アーカイブとインベントリーの有効期限処理にかかる時間が長くなりまし

た (これは特に、すでに多数のディレクトリー・アーカイブがある場合に顕著で

した)。

バージョン 4.2.1 における変更により、クライアントがサーバーに対してディレク

トリーを照会し、このディレクトリーが存在している場合にはそのアーカイブ日

付を、このディレクトリーを後に参照したアーカイブ・ファイルのアーカイブ

日付に変更するようになりました。これにより、ディレクトリーが有効期限切れ

になる時期が延長され、インベントリーの有効期限切れ処理時の「参照状態」テ

ストの数が減りました。同じ記述 (Description) を持つファイルのアーカイブが多

数ある場合に検索時間を短縮するための新しい内部テーブルが TSM データベー

スに追加されました。TSM 管理者が TSM データベースで新しい内部テーブルを

使用できるようにノードを変換する時期を制御するための新機能、CONVERT ARCHIVE が追加されました。またこのレベルでは、新しいクライアント・オプ

ション「-v2archive」が追加されました。このオプションを指定すると、ディレク

トリーのアーカイブが防止されます。つまり、実質的にバージョン 2 の機能に戻

りました。これらの機能は、TSM バージョン 3.7.4 レベルに組み込まれました。

アーカイブ機能の実装

アーカイブ機能を実装するには、初に業務上の問題を解決するためにアーカイ

ブ機能が適しているかどうかを判断します。定期的なアーカイブも含め、一連の

業務関連ファイルをアーカイブしておくことが適切です。また、重大な変更を行

う前に、アーカイブ機能を使用して一連のファイルまたはディレクトリーの「ス

ナップショット」を作成しておくことも可能です。避けるべきいくつかのアーカ

イブ操作を次に示します。

• 特定時点での回復方針を実装する。これは通常、大規模アーカイブを頻繁

に実行することを意味します。このようなアーカイブを行うと、TSM デー

タベースが多数のディレクトリー・エントリーとファイル・エントリーで

いっぱいになり、前述した問題が悪化する傾向にあります。アーカイブの

要件は、TSM クライアント・バックアップ機能または TSM サーバー生成

バックアップ・セットで対応できることがよくあります。

67

• テープ交換方針の代わりに使用する。場合によっては、TSM で特定のテー

プを定期的かつ予期されているとおりにオフサイトで回転させ、事前に定

義されている時点でオンサイトに戻すというテープ管理方針を導入する必

要があります。これは TSM の通常の操作モードではありませんが、さま

ざまな方法で実現できます。アーカイブ機能を使用してテープ回転を行う

と、TSM データベースに余剰なディレクトリー・エントリーとファイル・

エントリーが作成される問題が発生する可能性があります。より効率的な

方法として、クライアントのバックアップ機能と一連のストレージ・プー

ルを使用する方法があります。ラウンドロビン方式でストレージ・プール

に直接バックアップされます。オフサイト・ロケーションからテープ・ボ

リュームを回復する時点で、ストレージ・プールからすべてのボリューム

が削除されます。

可能な場合には必ず、アーカイブの代わりにバックアップ・セットを使用してく

ださい。バックアップ・セットでは前述のような問題は発生せず、また TSM デー

タベースへの影響も小さくなります。各バックアップ・セットは TSM データベー

スに 1 つのエントリーのみを作成します。バックアップ・セットが適切でない場

合には、ファイルとディレクトリーをアーカイブする前に、これらのファイルと

ディレクトリーを集合にまとめる方法 (PKZIP、tar など) があります。

症状

アーカイブが原因で発生した問題を示す症状の一部を次に示します。

• アーカイブまたはリトリーブのスループットが低い: アーカイブされる重

複ディレクトリー・エントリーが増えるほどアーカイブのパフォーマンス

が低下するか、時間の経過に伴いアーカイブ・スループットが低下するか、

またはアーカイブの進行に伴い、徐々にアーカイブ・スループットが低下

します。場合によっては、アーカイブ・スループットが著しく低下し、アー

カイブが停止しているように見えることがあります。初にその他のチュー

ニング変数をすべて調べ、パラメーターを変更することで解決できる問題

でないことを確認します。「TSM パフォーマンス・チューニング・ガイド」

を参照してください。この資料を入手できる URL は http://www.tivoli.com/support/public/Prodman/public_manuals/storage_mgr /v3pubs/pfguide.htm です。

• TSM サーバーのインベントリーの期限切れ処理にかかる時間: 処理する必

要のある重複アーカイブ・ディレクトリーが増加するため、インベントリー

の有効期限が延長されることがあります。また、有効期限が切れたディレ

クトリー・アーカイブごとに、インベントリーの期限切れ処理で従属ファ

イルを調べる必要があります。多数の重複アーカイブ・ディレクトリーが

存在する場合に、これが原因で問題が悪化する傾向にあります。

68

• TSM データベースの過剰な増大: アーカイブ・ディレクトリーごとに、TSM データベース内に 1 つのエントリーが必要となるため、TSM データベース

のサイズが増加します。TSM データベースの増大の原因となる可能性のあ

るその他の要因 (新規クライアント、管理クラスの保管期間またはバージョ

ン管理の変更、既存のクライアントからの大幅な増大など) について考慮

してください。

推奨アクション

前述した症状が発生しており、過剰なアーカイブ・ディレクトリーと何らかの関

連があると考えられる場合の良の対処は、IBM/Tivoli ソフトウェア・サポート・

センターまで連絡することです。サポート・センターは、サービス・ユーティリ

ティーを使用してシステムを調査し、必要に応じて修正処置を実施する作業を支

援します。次のコマンドを実行するよう指示されます。

Q OCC TYPE=ARCHIVE

CLEANUP ARCHDIR SHOWSTATS

CLEANUP ARCHDIR 出力に示される重複値は、パスおよびディレクトリー名に

よる重複にのみ基づいています。この出力では、大量の重複 (数十万単位) または

ディレクトリー対ファイルの比率が高いものを探します。これらの情報は、問題

を示している可能性があります。

注: IBM または Tivoli サポート・コーディネーターの指示がない限り、CLEANUP ARCHDIR ユーティリティーは使用しないでください。

過剰なディレクトリー・アーカイブの問題が発生していると判断される場合には、

次のいずれか 1 つまたは複数の解決手順を実行するよう指示されます。

• TSM サーバーをバージョン 4.1.2 またはそれ以上にアップグレードします。

このレベルでは、過剰なディレクトリー・アーカイブの問題に対処する新

しいオプションとユーティリティーが導入されています。 • CLEANUP ARCHDIR を使用して、不要なディレクトリー・アーカイブの

一部または大部分を除去します。現在の状態に至った状況と時期によって

は、このユーティリティーが有効でない場合があります。 • 変換したノードを元に戻してから、ノードを変換します。これにより、ノー

ドが強制的に TSM データベースの新しいテーブル構造を使用するように

なります。この新しい構造は、従来よりも効率性に優れています。 • アーカイブ作成時に –V2ARCHIVE オプションを使用します。このオプショ

ンは、アーカイブ・プロセスをバージョン 2 の機能に戻します。つまり、

ディレクトリーがアーカイブされなくなります。リトリーブ時には、TSM

69

は必要に応じて、省略時プロパティーを使用してディレクトリーを作成し

ます。このオプションは、ファイルをアーカイブできる余裕がある場合に

のみ使用してください。 • アーカイブ記述にはブランク (非ヌル) 文字ストリングを使用します。これ

により、同じパスおよびディレクトリー名を持つ一意のアーカイブが過剰

に作成されることを防止できます。

注: ITSM 5.2.2 では CLEANUP ARCHDIR コマンドが UPDATE ARCHIVE コマンド

に変更されました。

要約

アーカイブ機能は、これまでのさまざまな製品バージョンおよびリリースにわたっ

て変更されてきました。これらの変更を理解しておくと、問題診断時に役立ちま

す。

過剰なディレクトリー・アーカイブの徴候は次のとおりです。アーカイブまたは

リトリーブ実行にかかる時間が長くなる。インベントリーの期限切れ処理にかか

る時間が長くなる。TSM データベースが急速に増大する。

アーカイブの問題が発生している場合には、バックアップ・セットなどの代替方

法を使用してください。

過剰なディレクトリー・アーカイブの問題が発生していると考えられる場合には、

IBM または Tivoli ソフトウェア・サポートに連絡し、助言を求めてください。

付録 B: ネットワーク・プロトコルのチューニング TCP/IP のチューニングに関する考慮事項

通信の概念

この章では、TSM のパフォーマンスを大限に引き出すための TCP/IP プロトコ

ルのチューニングを中心に説明します。TCP/IP に関連する基礎概念を簡単に説明

してから、チューニングのさまざまな面を説明します。

70

TCP/IP を調整する場合に、パフォーマンスを大に引き出すには、次の主要領域

に影響するパラメーターを変更します。

• データ転送ブロック・サイズ • ウィンドウ値 • 接続の可用性

システム・リソースを必要とするタスクを次に示します。

• 通信接続を使用可能な状態に維持する。 • 送信側でユーザー・データが認知されるまで、ユーザー・データを維持す

る。 • 通信層を管理する。

リソースには、メモリー、CPU、通信アダプター、リンク使用率などがあります。

またリソースには、さまざまな通信層の実装に関する制限が関連します。リソー

スのオーバーコミット状態を引き起こす 2 つの主な要素が、データ・サイズとフ

ロー制御です。リソースがオーバーコミット状態になると、システム・パフォー

マンスが低下します。

TCP/IP プロトコルおよび TCP/IP 機能

TCP/IP プロトコルと TCP/IP 機能は、その機能グループ (ネットワーク層、インター

ネットワーク層、トランスポート層、およびアプリケーション層) 別に分類でき

ます。機能グループと各グループに関連するプロトコルを表 2 に示します。

表 2： TCP/IP 機能グループ

グループプロトコルと機能

ネットワーク層トークンリングイーサネットその他

インターネットワーク層

インターネット・プロトコル (IP) インターネット制御メッセージ・プロトコル (ICMP) アドレス解決プロトコル (ARP)

トランスポート層 Transmission Control Protocol (TCP) ユーザー・データグラム・プロトコル (UDP)

アプリケーション層 Telnet ファイル転送プロトコル (FTP) リモート・プロシージャー・コール (RPC) ソケット・インターフェース

71

グループプロトコルと機能

その他

プロトコル機能

プロトコル機能は、次のように分類されます。

• 確実な配信 • メッセージの組み立てと分解 • 接続制御 • フロー制御 • エラー処理

確実な配信

確実な配信サービスでは、あるマシンから送信されたデータ・ストリームを、デー

タの重複や損失がない状態で別のマシンへ配信することが保証されます。信頼性

のあるプロトコルは、再送信肯定応答と呼ばれる手法を使用しています。この手

法では、受信側が送信元と通信し、データ受信後に肯定応答を送信します。

パケットの組み立てと分解

通信プロトコルの各層が、何らかの組み立て機能または分解機能を実行します。

送信元ノードと宛先ノードが同じ物理ネットワーク上になく、かつこれらのネッ

トワーク上の大伝送単位 (MTU) が一致していない場合には、TCP/IP ソフトウェ

アがネットワーク間を移動するパケットをフラグメント化する必要があります。

受信ステーションの TCP/IP ソフトウェアが、フラグメントを再度組み立てます。

組み立て/分解にはさまざまな長所があります。

• 通信ネットワークで受け入れられるデータ・ブロックのサイズが限定され

ているため、大きなブロックの場合はブロックを分割する必要があります。

例えば、イーサネット LAN の MTU サイズは 1500 バイトですが、トーク

ンリング LAN の MTU サイズは 16000 バイトです。 • 小さなブロックではエラー処理の効率が向上します。 • 共有送信機能により、アクセスの公平性が向上し、遅延が短くなります。

例えば、回線速度が遅い場合に大きなブロックの送信を許可すると、回線

が占有される結果になります。

72

組み立て/分解の短所を次に示します。

• データ伝送単位ごとに一定量のオーバーヘッドが必要です。したがってブ

ロックが小さくなるほど、オーバーヘッドのパーセンテージが大きくなり

ます。 • 均等な量のユーザー・データを送信するには、送信側と受信側の両方で処

理する必要のあるブロックの数が増えます。また、これには時間がかかる

ことがあります。

フロー制御

フロー制御は、送信側システムにより送信されるデータの量または速度を制限す

る機能で、受信側システムが提供します。これは、トラフィックを規制し、受信

側システム・リソースの超過を防ぐことを目的としています。

エラー制御

データおよび制御情報の損失を防ぐために、エラー制御が必要です。ほとんどの

手法にはエラー検出と再送信が関連しています。

スライディング・ウィンドウ

フロー制御とエラー制御の両方の面で通信チャネルを効率的に使用する必要があ

ることから、スライディング・ウィンドウの概念が誕生しました。信頼性を実現

するため、送信元はパケットを送信後、肯定応答を受信するまで待機してから次

のパケットを送信します。スライディング・ウィンドウ・プロトコルにより、送

信元は肯定応答を待たずに複数のパケットを送信できます。この機能の長所を次

に示します。

• 双方向の同時通信が可能です。 • 特に大規模伝送遅延が生じる場合に、ネットワーク帯域幅をより効率的に

使用できます。 • 逆トラフィック・データによるトラフィック・フロー (結合処理と呼ばれ

ます)。この逆トラフィックは、挿入される肯定応答に関連している場合と

そうでない場合があります。 • 時間の経過に伴ない変化する可変ウィンドウ・サイズ。各肯定応答は、受

信済みオクテット数を示し、ウィンドウ・アドバタイズメントを含んでい

ます。ウィンドウ・アドバタイズメントにより、受信側で受け入れ可能な

追加データのオクテット数、つまり受信側の現在のバッファー・サイズが

示されます。ウィンドウ・サイズが縮小されると、これに応じて送信側は

そのウィンドウのサイズを縮小します。可変ウィンドウ・サイズを使用す

る利点は、フロー制御と確実な転送にあります。

73

クライアントが引き続きウィンドウ・サイズを縮小する場合、クライアントがロー

ドを処理できない状況にあります。したがって、ウィンドウ・サイズを増加して

も、パフォーマンスは向上しません。

TCPWindowsize (TSM オプション)

TCPBuffsize (TSM オプション)

TCPNodelay (TSM オプション)

プラットフォーム固有の推奨事項

AIX サーバーおよびクライアント

AIX によるサーバーでの大スループットを実現するため、AIX ですべてのパフォー

マンス制約を小限に抑えることが重要です。このためには、AIX でネットワー

ク・オプション・パラメーターをチューニングします。

TSM はネットワークで TCP/IP 通信プロトコルを使用します。スループットを

大限に引き出すように TCP プロトコルを調整することが重要です。このためには、

TCP/IP プロトコルの動作とシステム全般を制御するネットワーク・パラメーター

を変更する必要があります。

AIX では、TCP/IP 通信プロトコルを使用するアプリケーションは、TCP ソケット

を開いてデータをこのソケットに書き込みます。データはユーザー・スペースか

ら、カーネル・スペース内の tcp_sendspace というソケット送信バッファーにコピー

されます。受信バッファーは tcp_recvspace と呼ばれています。送信バッファーと

受信バッファーは、mbufs と呼ばれる小さなバッファーで構成されています。

mbuf は、mbuf クラスターまたは単純にクラスターと呼ばれる固定メモリーを使

用するカーネル・バッファーであり、256 バイトと 4096 バイトの 2 種類のサイズ

があります。大ソケット・バッファー・サイズ制限は、sb_max kernel 変数によ

り決定します。mbuf は主に着信または発信ネットワーク・トラフィックのデータ

の格納に使用されるので、ネットワーク・パフォーマンスに効果をもたらすよう

に mbuf を構成する必要があります。常に mbuf を効率的に割り振るようにするた

め、小数の mbuf バッファーが常にフリー・バッファー・プールに維持されま

す。mbuf の小数は lowmbuf オプションにより決定し、クラスターの小数は lowclust オプションにより決定します。mb_cl_hiwat オプションは、クラスター・

プールに格納できるフリー・バッファーの大数を制御します。

thewall ネットワーク・オプションは、仮想メモリー・マネージャー (VMM) から mbuf 管理ルーチンに割り振ることができる大 RAM を制御します。mbuf の詳細情報

74

を取得するには、netstat -m を使用します。パケット伝送中にエラーが発生したか

どうかを確認するには、netstat - I tr0 コマンドを使用します。

0 よりも大きい番号の場合、オーバーフローが発生しています。装置ドライバー

層では、データが含まれている mbuf チェーンが送信キューに入れられ、アダプ

ターに対して送信操作開始がシグナル通知されます。受信側では、アダプターが

パケットを受信し、ドライバー管理受信キューにこのパケットが入れられます。

アダプターの送信キュー・サイズおよび受信キュー・サイズを構成するには、System Management Interface Tool (SMIT) を使用します。

装置ドライバー層では、送信キューと受信キューの両方を構成できます。これら

のキューがオーバーランする可能性があります。これを確認するには、netstat -v コマンドを使用します。このコマンドは、大送信キュー数と大受信キュー数を

表示します。

表 3: 送信アダプター・キューの設定

バス・タイプキュー設定

PCI 256 マイクロチャネル 512-2048

表 4: MTU および MSS 設定

ネットワーク・タイプ MTU MSS (RFC1323 0)

MSS (RFC1323 1)

FDDI 4352 4312 4300 トークンリング 4096 4056 4044

イーサネット 1500 1460 1448

もう 1 つの重要な要素が MTU です。同じタイプのネットワークのシステムでス

ループットを大限に引き出すには、大きな MTU を使用することをお勧めしま

す。複数ネットワーク環境では、大きな MTU のネットワークから小さな MTU のネットワークにデータが移動すると、(小さな MTU のネットワークへ送信できる

ようにするため) IP 層はパケットを小さなパケットにフラグメント化する必要が

あります。この処理では、フラグメント化パケットを再度組み立てるために受信

システムの CPU 時間が費やされます。データがリモート・ネットワークに移動す

る場合、AIX の TCP は省略時解釈で大セグメント・サイズ (MSS) 512 バイトを

使用します。この控えめな値は、すべての IP ルーターが 576 バイト以上の MTU をサポートしているという要件に基づいています。省略時の MSS を指定変更する

には、次の 3 通りの方法があります。

75

1. 特定のリモート・ネットワークへの静的経路を指定し、route コマンドの -mtu オプションを使用してそのネットワークの MTU を指定します。この方法

の短所を次に示します。 o 動的経路指定では機能しません。 o リモート・ネットワーク数が増えると、これは現実的な方法でなく

なります。 o 省略時 MSS よりも大きい値をネゴシーエションするため、両側で

経路を設定する必要があります。 2. no コマンドの tcp_mssdflt オプションを使用して、MSS の省略時値を変更

します。この変更はシステム全体に適用されます。複数の MTU が設定さ

れている複数ネットワーク環境では、MSS 省略時値を指定変更する値とし

て、(指定されたすべての MTU の) 小 MTU 値から 40 を差し引いた値を

指定する必要があります。大きな省略時 MTU が設定されている環境では、

この方法にはネットワークごとに MSS を設定しなくてよいという利点が

あります。この機能の短所を次に示します。 o 宛先がリモート・ネットワークにあり、介在するネットワークの MTU

が不明な場合に省略時値を増やすと、IP ルーターがフラグメント化

されることがあります。 o tcp_mssdflt パラメーターには、宛先ホストと同じ値を設定する必要

があります。 3. サブネットを設定し、no コマンドの subnetsarelocal オプションを設定しま

す。サブネットを設定することで、複数の物理ネットワークが 1 つのネッ

トワーク番号を共用できるようになります。subnetsarelocal オプションは、

システム全体でサブネットをローカル・ネットワークまたはリモート・ネッ

トワークのどちらとして解釈するかを指定します。subnetsarelocal=1 (省略

時値) を指定すると、サブネット 1 のホスト A はサブネット 2 のホスト B が同じ物理ネットワーク上に存在するものと解釈します。この結果、ホスト A とホスト B は相互に接続するときに、同じネットワーク上にあるものと想

定して MSS をネゴシエーションします。

この方法の長所を次に示します。

o 静的バインディングが不要であり、MSS が自動的にネゴシエーショ

ンされます。 o TCP MSS ネゴシエーションを使用不可または指定変更することはな

いので、隣接するサブネット間での MTU のわずかな差を適切に処

理できます。

この方法の短所を次に示します。

76

o MTU が大きい 2 つのネットワークが、MTU が小さいネットワーク

を介して接続されている場合に、IP ルーターによるフラグメント化

が発生する可能性があります。 o 送信元ネットワークと宛先ネットワークの両方がサブネットをロー

カルとして認識する必要があります。

詳しくは、「AIX Performance Tuning Guide」(SC23-2356) を参照してください。

推奨値

高速スイッチを備えた SP2 環境では 64KB の MTU を使用してください。

AIX - no (ネットワーク・オプション)

ネットワーク・オプション・パラメーターを構成するには、no コマンドを使用し

ます。

• 現在の設定を表示するには、no -a を使用します。 • TCP ウィンドウ・サイズが 64 よりも大きい場合には、rfc1323 を 1 に設定

します。 • entstat、fddistat、または atmstat にゼロ以外の「No mbuf errors」がある場合

には、thewall が使用されます。 • thewall には 131072 以上の値を設定し、sb_max to には 1310720 以上の値を

設定することをお勧めします。 o AIX の新しいバージョンでは、省略時値が高くなっています (低下

していません)。 • no の設定はリブート後には無効になるので、/etc/inittab に追加してくださ

い。次のように変更することをお勧めします。 o no -o rfc1323=1 o no -o thewall=131072 o no -o sb_max=1310720

このセクションで説明したパラメーターの推奨値を次に示します。

ネットワーク・オプション lowclust = 200 lowmbuf = 400 thewall = 131072 mb_cl_hiwat = 1200 sb_max = 1310720 rfc1323 = 1

注: lowmbuf、lowclust および mb_cl_hiwat オプションは AIX v3.2.x にのみ該当し、

AIX v4.1.x には該当しません。AIX v4.1.x では、sb_max に 1310720 を設定すると、

TCP/IP アプリケーションの実行時にエラー・メッセージが表示されるます。この

ため、sb_max には 757760 を設定してください。

77

MVS サーバーと IBM TCP/IP for MVS

このセクションでは、IBM TCP/IP for MVS 向けに TCP/IP アドレス・スペースを

構成する方法について説明します。TCP/IP アドレス・スペースの初期化中に、シ

ステム操作パラメーターおよび構成パラメーターが構成データ・セットから読み

取られます。プログラムがデータ・セット job_name.node_name.TCPIP を検索しま

す。このノードは、VMCF 初期化レコードに指定されているシステムのノード名

です。VMCF は、IEFSSNxx メンバーの行により定義されているサブシステムで

す。このメンバーにより、VMCF アドレス・スペースが作成および初期化されま

す。このデータ・セットが見つからない場合には、プログラムは以下のデータ・

セットのうち、初に検出されたものを使用します。

• tcpip.node_name.TCPIP • job_name.PROFILE.TCPI • tcpip.PROFILE.TCPIP

ここでは、システム・パフォーマンス全体に影響する構成パラメーターについて

のみ説明します。ユーザーの環境に応じてさまざまな自由プール・サイズを構成

できます。これらのサイズについて、以降で説明します。開発時のテスト環境で

は、特に明記されている場合を除き、省略時値を使用しました。これらの設定値

が推奨値です。ただし、システムの容量要件によっては、これらの値を変更する

必要がある場合があります。

TCPIP.DATA TCPIP.DATA には、hostname、domainorigin、nsinteraddr (ネーム・サーバー) などが含まれています。TCPIP.DATA の内容は、前のリリースの TCP/IP for MVS と同じです。サンプル TCPIP.DATA については、「OS/390 Secureway Communications Server IP Configuration」(SC31-8513) または製品に付属のサ

ンプルを参照してください。重要な推奨事項として、すべてのネーム・サー

バー照会の完全なトレースを防ぐため、「TRACE RESOLVER」ステート

メントをコメント化しておくことがあります。このトレースはデバッグの

目的でのみ使用してください。 PROFILE.TCPIP

TCPIP スタックの初期化中に、PROFILE.TCPIP 構成データ・セットからス

タックの構成パラメーターが読み取られます。このファイルで使用されて

いるパラメーターについての詳細は、「OS/390 Secureway Communications Server IP Configuration」(SC31-8513) を参照してください。

PROFILE.TCPIP には TCP バッファー・サイズ、LAN コントローラー定義、

サーバー・ポート、ホーム IP アドレス、ゲートウェイ・ステートメント、

Telnet が使用する VTAM LU などの情報が記述されています。

78

CS OS/390 V2R5 以降のリリースでは、TCP/IP バッファー・プールと制御

ブロックの定義が PROFILE.TCPIP から削除され、TCP/IP が単純化されま

した。つまり、PROFILE.TCPIP の TCP/IP バッファーのチューニングは不

要です。バッファーは Communication Storage Manager (CSM) により動的に

割り振られます。

TCP SEND/RECV BUFFER SIZES --------------------------------

send/recv バッファーのサイズが PROFILE に指定されていないと、send/recv バッ

ファーには省略時値の 16K が使用され、TCP ウィンドウ・サイズには省略時値 32K が使用されます。send/recv バッファーのサイズが指定されている場合には、send/recv バッファー・サイズにはこの指定値が使用され、TCP ウィンドウ・サイズは、TCP recv バッファー・サイズの 2 倍の値 ( 大 65535 までの値) に設定されます。

注: V2R7 では RFC 1323 が使用可能です。RFC 1323 は 64K-1 TCP ウィンドウ・サ

イズよりも大きいサイズをサポートしています。お客様が TCPCONFIG ステート

メントの send/recv バッファー・サイズを指定できます。

TCPCONFIG TCPSENDBFRSIZE 64K TCPRCVBUFRSIZE 64K TCPSENDBFRSIZE 256K (OS/390 server using Jumbo Frame TCPRCVBUFRSIZE 256K Gigabit Ethernet)

TCPSENDBFRSIZE 64K-128K (OS/390 server using ATM) TCPRCVBUFRSIZE 64K-128K

ソケット・アプリケーションが特定のソケットのこれらの値を指定変更するには、

次に示す setsockopt 呼び出しをアプリケーション内で使用します。

• setsockopt(SO_SNDBUF) • setsockopt(SO_RCVBUF)

FTP サーバーおよびクライアントに関する重要な注意事項: FTP サーバーおよび

クライアント・アプリケーションは、省略時設定を指定変更し、TCP ウィンドウ・

サイズとして 64K-1、send/recv バッファーのサイズとして 180K バイトを使用し

ます。FTP サーバーおよびクライアントの TCPCONFIG ステートメントを特に変

更する必要はありません。

OS/390 では TCP/IP の DATABUFFERPOOLSIZE は使用せず、代わりに新しいパ

ラメーター TCPSENDBFRSIZE と TCPRCVBUFRSIZE を設定する必要があります。

また、クライアントの TCPWIndowsize を設定する必要があります。

79

GATEWAY ステートメント

GATEWAY ステートメントは、指定されたネットワークまたはホストへのデータ

グラムの経路指定方法を示します。

GATEWAY GATEWAYnetwork first_hop link_name max_packet_size subnet_mask subnet_value9.0.0 = PCN1 4000 0.255.255.0 0.113.1.0

パフォーマンスに影響する GATEWAY ステートメントのパラメーター、

max_packet_size について詳しく説明します。その他のパラメーターについては簡

単に説明します。

network ドット 10 進形式で表されるネットワークのインターネット・アドレス。

host 4 つのオクテットとして指定されるホスト・アドレス。

first_hop メッセージがネットワーク上の宛先に直接 (またはホストに直接) 経路指定

されることを暗示するか (=)、またはゲートウェイあるいはルーターのイン

ターネット・アドレスを指定します。 link_name

指定されたネットワークへパケットを送信するときに経由するリンクの名

前。リンク名は LINK ステートメントで定義されます。 max_packet_size

ネットワークまたはホストの大伝送単位 (バイト単位)。省略時値は 576 バイトです。

subnet_mask ドット 10 進形式のビット・マスク。サブネット・フィールドを構成するホ

スト・フィールドのビットを示します。 subnet_value

サブネット・フィールドの値。ドット 10 進形式で表現されます。

大伝送単位のサイズに関する考慮事項:

• TCP/IP for MVS が処理できる大パケット・サイズは、ラージ・エンベロー

プ・サイズです。一部のネットワークでは、パケット・サイズがこれより

も小さい値に制限されています。 • 情報は個別のパケットに入れられ、TCP 接続を介して転送されます。各パ

ケットには、TCP ヘッダーと IP ヘッダーが含まれています。ヘッダーのサ

イズは、含まれているユーザー情報から独立しているので、送信するパケッ

トが大きくなるほど、プロトコル・ヘッダーにより使用される相対帯域幅

80

が少なくなります。また、TCP ソフトウェアはパケット・サイズに関係な

く、パケットごとに一定の CPU 時間を消費するので、送信パケットが大き

いほど、消費される CPU 時間は少なくなります。 • 中間ゲートウェイにより、大きなパケットがフラグメント化されることが

あります。この場合、各フラグメントに固有のヘッダーが含まれています。

パケットのフラグメント化と再組み立ては、帯域幅と CPU を多量に消費し

ます。したがって、ゲートウェイを介してほかのネットワークに送信され

るパケットでは、中間ゲートウェイとネットワークが大きなパケットを受

け入れることが判明している場合を除いては、省略時サイズを使用してく

ださい。

GATEWAY の PACKET SIZE と BSDROUTINGPARMS

ワード DEFAULTSIZE を使用する代わりに、パケット・サイズを明示的に指定し

ていることを確認します。ワード DEFAULTSIZE は、TCPIP が省略時値 576 バイ

トを提供するように要求しますが、ご使用の構成ではこの指定が適でない場合

があります。

指定したネットワークのパケット・サイズとして DEFAULTSIZE を使用する代わ

りに、以下のサイズを使用することをお勧めします。

• 1492 バイト (イーサネット 802.3) • 1500 バイト (イーサネット・バージョン 2 IEEE) • 1500、2000、または 4000 バイト (トークンリング、ご使用の環境で可能で

あれば、これよりも大きい値を使用します) • 4000 または 2000 バイト (FDDI) (ご使用の環境で可能であれば、これより

も大きな値を使用します) • 65527 バイト (CTC) • 4096 バイト (CLAW)

例:

GATEWAY ; Packet Subnet Subnet ; Network First hop Driver size mask value 9 9.67.118.43 FDDI1 4000 255.255.255.0 9.67.115.0 DEFAULTNET 9.67.115.1 FDDI1 4000 0

動的経路指定を使用する場合は次のようになります。

BSDROUTINGPARMS TRUE ; Subnet Subnet ; Driver Packet size metric mask value

81

FDDI1 4000 0 255.255.255.0 9.67.115.0 ENDBSDROUTINGPARMS

BSDROUTINGPARMS ステートメントの true/false オプションに注意してください。

FALSE を指定すると、2 ホップ以上離れている宛先に送信されるすべての IP パケッ

トでは、インターフェースのパケットサイズではなく、省略時パケット・サイズ

の 576 バイトが使用されます。TRUE を指定すると、インターフェースを介して

送信されるすべての IP パケットでは、宛先までの距離が 1 ホップ以上あるかどう

かに関係なく、インターフェースのパケット・サイズが使用されます。

推奨値

MTU = 4000 (途中でフラグメント化が発生しない場合 (TR)) MTU = 1500 (途中でフラグメント化が発生しない場合 (EN))

TCP/IP および OS/390 UNIX システム・サービス・パフォーマンスのチューニング

• クライアント/サーバー TCP ウィンドウ・サイズに、大許容値を設定し

ます。推奨事項: MVS の TCP ウィンドウ・サイズに大許容値を設定する

ため、TCPRCVBUFRSIZE に 32K 以上の値を設定します。また、クライア

ント・ワークステーションで可能な場合には、クライアント・ウィンドウ・

サイズとして 65535 を設定します。インストール先システムの記憶域に制

約がある場合には、TCPRCVBUFRSIZE の省略時値 16K を使用します。 • クライアントとサーバーの MTU/パケット・サイズが等しいことを確認し

ます。『PROFILE.TCPIP』に示されている推奨事項に従います。 • 適なパフォーマンスを引き出すには、TCP/IP とその他のすべてのトレー

スをオフにします。トレース・アクティビティーでは余分な処理オーバー

ヘッドが生じます。 • 「OS/390 UNIX システム・サービス計画」(SC88-6618) または以下の URL

の OS/390 UNIX システム・サービスのチューニング・ガイドラインに従い

ます。 http://www.s390.ibm.com/oe/bpxa1tun.html

• 領域サイズとディスパッチング優先順位: TCPIP スタック・アドレス・ス

ペースと稼働中のタスク (FTP サーバー、SMTP/NJE サーバー、Web サー

バー、TSM サーバーなど) に対して領域サイズ 0K または 0M を設定する

ことを強くお勧めします。

ご使用の環境で可能であれば、TCPIP および VTAM のディスパッチング優

先順位を同等に設定し、サーバーの優先順位を TCPIP および VTAM より

多少低くしておきます。

82

その他の稼働中のタスク (FTP、TSM など) については、TCPIP タスクより

も多少低く設定します。

ワーク・ロード・マネージャーを使用する場合には、インストール先シス

テムでサービス・ポリシーのパフォーマンス目標を定義するときに、前述

の推奨事項に従ってください。サービス・ポリシーは ISPF アプリケーショ

ンで定義されます。サービス・ポリシーにより、すべてのタイプの MVS 管理処理の目標が設定されます。

• TCP/IP V3R2 を使用する場合には、「TCP/IP プログラムパフォーマンス・

チューニング・ガイド」(SC88-7941) を参照してください。このチューニン

グ・ガイドでは、その他の TCP/IP プラットフォーム (AIX、OS/2、DOS、および VM) のチューニング手順も説明しています。

• この APAR に記載されている適切な推奨事項に従って、PROFILE.TCPIP、TCPIP.DATA、および FTP.DATA ファイルを更新します。

• ご使用の OS/390 UNIX システムで必要な OS/390 UNIX システム・サービ

スのユーザー、プロセス、プロパティー、ソケット、およびスレッドの数

を見積もります。SYS1.PARMLIB の BPXPRMxx メンバーを更新します。 • 適なパフォーマンスを引き出すため、OS/390 UNIX ユーザー HFS データ・

セットを分散する DASD ボリュームを増やします。 • RMF またはシステム・コマンド (DISPLAY ACTIVE、DISPLAY OMVS な

ど) あるいはこの両方を使用して OS/390 UNIX リソースをモニターします。

MVS サーバーと Interlink TCP/IP for MVS

このセクションでは、適な TSM クライアント/サーバー・パフォーマンスを引

き出すための Interlink SNS/TCPAccess の構成方法について説明します。

SNS/TCPaccess は、MVS で稼働するインターネット・プロトコル向けの通信サブ

システムです。

SNS/TCPaccess は、複数のタスク・グループを備えた許可サブシステムとして実

装されています。アプリケーション制御プロトコル (ACP) タスク・グループは、

インターネット・アプリケーション・プロトコルおよびネットワーク・ハードウェ

アとのインターフェースをサポートしています。アプリケーション・プログラム・

インターフェース (API) タスク・グループは、ACP トランスポート・プロトコル・

プロバイダーとその他のアドレス・スペース内のトランスポート・プロトコル・

ユーザーとの間のインターフェースをとります。その他のタスク・グループは、

システム全体を構築するときに必要です。ただしこの 2 つのタスク・グループは TSM クライアント/サーバーのパフォーマンスにも大きく影響するため、このセクショ

ンではこの 2 つのタスク・グループについてのみ説明します。

83

SNS/TCPaccess PARM データ・セットには、タスク・グループごとに構成パラメー

ター定義メンバーがあります。ACP パラメーターは ACPCFGxxmember で定義さ

れます。API パラメーターは APICFGyymember で定義されます。xx と yy の値は、

SNS/TCPaccess CMND データ・セットの始動コマンド定義メンバーから判別され

ます。

ACP 構成

TSM クライアント/サーバーのパフォーマンスにとって重要な ACP 構成ステート

メントは、NETWORK ステートメントと TIB ステートメントです。システム全

体を構築するには、その他のステートメントも必要です。

NETWORK ステートメント

NETWORK ステートメントは、SNS/TCPaccess を実行する MVS ホストとネット

ワークの間のインターフェースを記述します。NETWORK ステートメントの完全

な構文を次に示します。

NETWORK ステートメントの構文 NETWORK HOST(internet_address) LNID(name1 [name2 ...]) [SUBNET(mask) ] [NAME(name) ] [MTU(number) ] [MSSOPT(NEVER | SUBNET | NET| ALWAYS) ] [MSSDEF(number) ] [FWD | NOFWD ] [ARPTABLE(name) ] [LOOP |NOLOOP ]

TSM クライアント/サーバーのパフォーマンスにとって重要なパラメーターを次

に示します。

MTU(number) ネットワーク・ヘッダーを除いたローカル・ネットワークの大伝送単位 (MTU) のサイズを指定します。

MSSDEF(number) TCP 接続先から MSS オプションを受信しない場合に送信される省略時

大伝送単位 (MTU) のサイズを指定します。ローカル・ネットワークの MTU 以下の値を指定してください。標準の仕様では 512 バイトです。これは、

不明なネットワークとゲートウェイのトラフィックに便利です。NETWORK ステートメントにより定義されるネットワークでこれよりも大きなサイズ

をサポートできる場合には、MSSDEF にそのサイズを設定します。 MSSOPT(NEVER | SUBNET | NET | ALWAYS)

TCP 大セグメント・サイズ (MSS) オプションの送信時期を指定します。

TCP/IP 標準では、受信側で 512 バイト以上のパケットを処理できることを

送信側が確認していない場合には、512 バイト以上のパケットを送信して

84

はならないことが定められています。MSS オプションは、接続先に対して

制限値を通知します。MSSOPT(ALWAYS) を指定することをお勧めします。

大伝送単位のサイズに関する考慮事項:

• 情報は個別のパケットに入れられ、TCP 接続を介して転送されます。各パ

ケットには、TCP ヘッダーと IP ヘッダーが含まれています。ヘッダーのサ

イズは、含まれているユーザー情報から独立しているので、送信するパケッ

トが大きくなるほど、プロトコル・ヘッダーにより使用される相対帯域幅

が少なくなります。また、TCP ソフトウェアはパケット・サイズに関係な

く、パケットごとに一定の CPU 時間を消費するので、送信パケットが大き

いほど、消費される CPU 時間は少なくなります。 • ただし、中間ゲートウェイにより大きなパケットがフラグメント化される

ことがあります。パケットのフラグメント化と再組み立ては、帯域幅と CPU を多量に消費します。したがって、ゲートウェイを介してほかのネットワー

クに送信されるパケットには、中間ゲートウェイとネットワークが大きな

パケットを受け入れることが判明している場合を除いては、省略時サイズ

を使用してください。

推奨値

MTU = 4000 (途中でフラグメント化が発生しない場合 (TR)) MTU = 1500 (途中でフラグメント化が発生しない場合 (EN))

トランスポート・サービス情報ブロック (TIB) ステートメント

トランスポート・サービス情報ブロック (TIB) ステートメントは、TCP または UDP トランスポート・サービス・パラメーター値を指定します。ほとんどの場合、TCP と UDP の両方の構成に省略時 TIB ステートメントを組み込む必要があります。

TIB ステートメントの完全な構文を次に示します。

TIB ステートメントの構文 TIB PROTOCOL(TCP | UDP) [MAXQLSTN(listen) ] [MAXQSEND(send)] [MAXQRECV(receive) ] [MAXLSEND(send) ] [MAXLRECV(receive) ] [DEFQSEND(send)] [DEFQRECV(receive) ] [DEFLSEND(send) ] [DEFLRECV(receive) ] [MAXLTSND(send)] [MAXLTRCV(receive) ] [TADDRUSE (n1 [:m1] [n2 [:m2]] ... ) ] [TADDRASSIGN(n1[:m1] [n2 [:m2]] ... ) ]

85

TSM クライアント/サーバーのパフォーマンスにとって重要なパラメーターを次

に示します。これらのパラメーターは TCP TIB ステートメントに指定します。

MAXQSEND(send) 各エンドポイントの未解決 API TSEND 要求または TSENDTO 要求の大

数を指定します。リストア操作またはリトリーブ操作の実行中に、TSM はこの大数または 8 のいずれか低い数の要求を使用できます。この値を小

さい数に制限すると、TSM および SNS/TCPaccess アドレス・スペースのク

ライアント・セッション仮想記憶域所要量が減りますが、リストアまたは

リトリーブ操作のスループットも低下します。このパラメーターは、TSM バックアップまたはアーカイブ操作のスループット、またはこれらの操作

のためのクライアント・セッション仮想記憶域所要量には影響しません。 MAXLSEND(send)

各エンドポイントのすべての未解決 API TSEND 要求または TSENDTO 要求の大バイト数を指定します。

MAXLTSND(send) 1 つの TSEND 要求または TSENDTO 要求で送信できる大バイト数を指

定します。 MAXLTRCV(receive)

1 つの TRECV 要求または TRECVFR 要求で受信できる大バイト数を指

定します。 TADDRUSE( n1 [:m1] [n2 [:m2]] ... )

API アプリケーションが使用できるポート番号の範囲を指定します。この

ステートメントには TSM サーバーのポート番号を記述する必要がありま

す。推奨される TIB の例

TIB PROTOCOL(TCP) MAXQSEND(8) MAXLSEND(256000) MAXLTSND(32000) MAXLTRCV(32000) TADDRUSE(1:4095) TADDRASGN(4096:8191)

API 構成

API 構成 POOLDEF ステートメントは、アプリケーション・プログラム・インター

フェースを実行し、API の使用を制限するために必要な制御ブロックのプールを

定義します。

POOLDEF ステートメント

POOLDEF ステートメントの完全な構文を次に示します。

POOLDEF ステートメントの構文 POOLDEF NAME(polonium) INITIAL(poolside) MINIMUM(poolside)

86

EXPAND(amount) NAME(polonium)

定義するプールの名前を指定します。次の各プールに対し 1 つの POOLDEF ステートメントを入力する必要があります。

TPCB トランスポート・プロバイダーごとに 1 つのエレメント。

ARCB API を使用するアドレス・スペースごとに 1 つのエレメント。

TSQB API を使用するタスク (TCB) ごとに 1 つのエレメント。

TUCB

実行される AOPEN マクロごとに 1 つのエレメント。 EPCB

オープンしているエンドポイントごとに 1 つのエレメント。 SRE

API に対するサービス要求ごとに 1 つのエレメント。 CBUF

循環バッファーごとに 1 つのエレメント。すなわち、エンドポイントごと

に 2 つのエレメント (送信用に 1 つ、受信用に 1 つ)。 INITIAL(poolside)

プールに対し取得するプール・エレメントの初期数を指定します。 MINIMUM(poolside)

縮小を実行する場合にプールに残しておくプール・エレメントの小数を

指定します。 EXPAND(amount)

プールを拡張する必要があるときに取得するエレメントの数を指定します。

開発時のテスト環境では省略時値を使用しましたが、システムの容量要件によっ

ては、これらの値を変更する必要がある場合があります。POOL コマンドを使用

してプール使用率をモニターし、何らかの兆候が示される場合には調整すること

をお勧めします。

NetWare クライアント

NetWare キャッシュのチューニング

SERVMAN ユーティリティーを使用して調整可能であり、TSM で良好な結果をも

たらすことが判明している NetWare 4.0 のパラメーターを次に示します。

87

表 4: NetWare キャッシュ・チューニング・パラメーター

NetWare パラメーター省略時値範囲推奨値 MAXIMUM NUMBER OF INTERNAL DIRECTORY HANDLES

100 40 から 1000 1000

DIRECTORY CACHE ALLOCATION WAIT TIME

2.2 0.5 から 120 0.5

MAXIMUM PHYSICAL receive PACKET SIZE (TR)

tba tba 4202

MAXIMUM PHYSICAL receive PACKET SIZE (EN)

tba tba 1442

MINIMUM DIRECTORY CACHE BUFFERS

tba tba 2000

MAXIMUM DIRECTORY CACHE BUFFERS

100 20 から 20000 4000

MAXIMUM CONCURRENT DISK CACHE WRITES

tba tba 1000

MAXIMUM CONCURRENT DIRECTORY CACHE WRITES

tba tba 25

MINIMUM PACKET receive BUFFERS

tba tba 100

MTU

MTU を適切なサイズに調整する必要があります。複数ネットワーク環境では、大

きな MTU のネットワークから小さな MTU のネットワークへ転送されるデータの

場合、IP 層でパケットが小さなパケットにフラグメント化される必要があります。

このため、フラグメント・パケットを再度組み立てるために受信システムの CPU 時間が消費されます。

MTU サイズを構成するには、STARTUP.NCF (NetWare V3.x) または AUTOEXEC.NCF ファイル (NetWare V4.x) を次のように編集します。

TcpMSSinternetlimit

データがリモート・ネットワークまたは別のサブセットに移動する場合、 TCPIP. NLM は、MTU サイズを大セグメント・サイズ (MSS) の省略時値 536 バイトに設定します。TcpMSSinternetlimit パラメーターを使用して、省略時値を指

定変更し、大きな MTU を設定することができます。TCP/IP v3.0 を備えた NetWare

88

v4.x では、SYS:¥ETC¥TCPIP.CFG で TcpMSSinternetlimit をオフに設定すると、

TCPIP. NLM が STARTUP.NCF ファイルに指定された MTU 値 ( 大物理受信パ

ケット・サイズ) を使用します。また、TcpMSSinternetlimit パラメーターでは大文

字と小文字が区別される点にも注意してください。このパラメーターを正しく指

定しないと、NetWare により tcpip.cfg ファイルからこのパラメーターが自動的に

削除されます。

TCPIP.CFG TcpMSSinternetlimit off

NetWare v3.x では、Novell パッチ TCP31A.EXE (TCP/IP v2.75 向け) でも同じオプションが提供されます。

Solaris サーバーおよびクライアント


• クライアントでのバックアップに複数のファイル・スペース (ディレクトリー、

ファイル・システム) を使用し、これらのファイル・スペースが複数の物理ディ

スクにまたがっている場合には、クライアント・オプションの ResourceUtilization に省略時値以外の値を設定できます。dsm.sys ファイルの ResourceUtilization オプ

ションには値 5 を設定することをお勧めします。ただし、TSM 環境を適な状態

で利用するには、ResourceUtilization オプションを使用する前に、TSM サーバー

の負荷、ネットワーク帯域幅、クライアント・マシンの CPU および I/O 構成を検

討する必要があります。 • FDDI および高速 (100mbit) イーサネット・ネットワーク環境の Solaris クライア

ントには、クライアントの dsm.sys ファイルで設定されている TcpWindowsize 32K を使用することをお勧めします。 • ギガビット・イーサネット・ネットワーク環境では TcpWindowsize 64K 以上を

使用することをお勧めします。特定のネットワーク環境で適な TcpWindowsize 値を確認する方法として、毎回異なる TcpWindowsize 設定を使用して TTCP プログ

ラムを何回か実行する方法があります。TSM サーバーとクライアントに適な Tcpwindowsize を選択する際に、TTCP により報告されるロー・ネットワーク・ス

ループット番号を参考にすることができます。TTCP はフリーウェアであるので、

多数の SUN フリーウェア Web サイトからダウンロードできます。Solaris では、

TCP xmit バッファーおよび recv バッファーの省略時値は 8K です。TCP バッ

ファー・オーバーランの問題を防ぐため、tcp_xmit_hiwat と tcp_recv_hiwat の省略

時値を TcpWindowsize の値に変更する必要があります。この 2 つの TCP バッファー

の値を変更するには、Solaris コマンドの「ndd -set」を使用します。

89

HP-UX サーバーおよびクライアント




• HP-UX TSM サーバーではディスク・ストレージ・プールにロー・パーティ

ションを使用します。開発時のテストで行われた測定では、HP-UX で VXFS ボリュームを使用した場合に比べ、ロー・パーティション・ボリュームの

方がバックアップ/リストア操作のスループットが高かったため、ロー・パー

ティションを推奨します。ただし、TSM データベースと回復ログ・ボリュー

ムのデータの整合性と回復可能性を維持するため、TSM データベースと回

復ログ・ボリュームをファイル・システム上で割り振る必要があります。 • トランザクション・サイズを大化するには、Tivoli Storage Manager サー










Storage Manager サーバー・オプション uselargebuffers yes を使用します。こ

れが Tivoli Storage Manager 3.7 の省略時値です。 • largecommbuffers クライアント・オプションを自動的に yes に設定しないで

ください。SUN Solaris TSM クライアントと HP-UX TSM クライアントでは、

largecommbuffers を yes に設定しても、スループットが向上しないことがあ

ります。したがって、ご使用の環境で適切な値を確認するため、dsm.sys ファ

イルでこのオプションに yes または no を設定してみてください。 • I/O 競合を小限に抑えるため、サーバーに十分な個別の物理ディスクを

割り振ります。 • 大量の Tivoli Storage Manager サーバー・データベース・アクティビティー

(クライアントでの多数の小さなファイルのワークロードのバックアップと

リストアなど) を実行する Tivoli Sotrage Manager 機能と、インベントリー

機能 (インベントリーの期限切れ処理やファイル・スペースの削除など) の適なパフォーマンスを引き出すには、次の手順を行います。1) Tivoli Storage

Manager サーバー・データベース・ボリュームを、も高速なディスクに

配置します。データベース・ボリュームが接続しているディスク・アダプ

90

ターに書き込みキャッシュがある場合には、データベース・パフォーマン

スを大限に引き出すため、このキャッシュを使用可能にします。2) Tivoli Storage Manager サーバーのデータベース・バッファー・プールのサイズを

適切な値に調整します。Tivoli Storage Manager データベース・バッファー・

プールはデータベース・ページのキャッシュとして機能するので、ページ

が必要な場合には、そのページがすでにバッファー・プールに格納されて

います。このため、I/O が防止されます。

用語集インターネット・アドレス (TCP/IP) (Internet address (TCP/IP)) - インターネット

の各ノードを識別する固有の 32 ビット・アドレス。インターネット・アドレスは、

ネットワーク番号とローカル・アドレスで構成される。インターネット・アドレ

スはドット 10 進形式で表現され、ネットワーク経由でパケットの経路を指定する

ために使用される。

ウィンドウ (APPC) (Window (APPC)) - 送信済みであることをマシンが記憶して

いるデータ・フレームの数量またはカウント。

ウィンドウ・サイズ (TCP/IP) (Window size (TCP/IP)) - 特定の時点で肯定応答が

ないパケットの数。例えば、ウィンドウ・サイズ 8 のスライディング・ウィンド

ウ・プロトコルでは、送信側が肯定応答を受信するまでに 8 つのパケットを送信

できる。

会話 (APPC) (Conversation (APPC)) - 2 つの TP 間で実際に行われるデータ交換。

会話は、セッションを実行 (受信) する TP 間リンクである。

ギガバイト (Gigabyte) - 本書では、ギガバイト (GB) は 1,073,741,824 バイト (2 の

30 乗) である。

キロバイト (Kilobyte) - 本書では、キロバイト (KB) は 1024 (2 の 10 乗) である。

クライアント (TCP/IP) (Client (TCP/IP)) - ネットワーク上のサービスを要求する

コンピューターまたはプロセス。サーバーは、クライアントからのサービス要求

に応答するコンピューターまたはプロセスである。

経過時間 (Elapsed time) - 全経過時間は、TSM 活動記録ログから実行される機能

の時間を差し引いて算出される。したがって、クライアントのバックアップおよ

びリストアの接続時間は含まれない。

91

肯定応答 (Acknowledgment) - あるマシンから別のマシンへ送信されるデータ受信

確認メッセージ。

サーバー効率 (Server Efficiency) - クライアントの合計ワークロードを TSM サー

バーの合計 CPU 時間で割り、CPU 秒あたりの KB で表した値。ローカル TMS クライアントで測定する場合には、クライアントとサーバーの両方の CPU 時間が含

まれる。この値は、異なるテストやワークロードの実行時の CPU 効率を比較する

ときに使用できる。

サーバー CPU 時間 (Server CPU Time) - TSM サーバーの合計 CPU 時間を合計ワー

クロード (論理 MB 単位) で割り、MB あたりの CPU 秒で表した値。ローカル TMS クライアントで測定する場合には、クライアントとサーバーの両方の CPU 時間が

含まれる。

サーバー CPU 使用率 (Server CPU Utilization) - TSM サーバーの合計 CPU 時間を

経過時間で割り、パーセンテージで表した値。ローカル TMS クライアントで測

定する場合には、クライアントとサーバーの両方の CPU 時間が含まれる。マルチ

プロセッサー・マシンでは、全プロセッサーの平均である。

サーバー ITR (Server ITR) - 処理されたワークロード・ファイルの内部スループッ

ト率 (ITR) を TSM サーバーの CPU 時間で割り、CPU 秒あたりのファイル数で表

した値。ローカル TMS クライアントで測定する場合には、クライアントとサー

バーの両方の CPU 時間が含まれる。

大伝送単位 (TCP/IP) (Maximum Transmission Unit (TCP/IP)) - 各パケット交換テクノロジーでは、 1 つの物理フレーム内に伝送できるデータ量

に固定の上限を設けている。この上限を大伝送単位という。

スループット (Throughput) - 本書では、スループットはバックアップまたはリス

トアされたデータの合計バイト数を経過時間で割った値である。合計バイト数に

は通信プロトコルと TSM オーバーヘッドは含まれない。これは、クライアント

画面に表示されるスループット速度とは異なる点に注意すること。クライアント

画面に表示されるスループット速度は、瞬間データ転送速度であり、クライアン

トまたはサーバーの処理や、通信待機時間による遅延を含まない。スループット

はキロバイト/秒で報告される。このキロバイトは 1024 バイトである。ネットワー

ク・デバイスおよびネットワーク・プロトコルは、秒あたりの K ビットまたは M ビットで示されることがある点に注意する (16 M ビットのトークンリングなど)。例えば、16 M ビットは 2 MB と等価である。

スループット比 (Throughput Ratio): - テーブル列の見出しに「Throughput Ratio」または「Thru Ratio」と示されている。これは、2 つのパフォーマンス測定値の相

対スループットを比較する。特定の記述について、テーブル内の各グループの 1 番

92

目の列が基準として使用される。以降の行のスループットは、次の式を使用して

基準と比較される。スループット比 = 100 x (スループット測定値 / 基準スループット)

も一般的な例として、複数のクライアントを追加した場合のスループットのス

ケーリング方法がある。スループット比が高くなるほど、スケーリングが向上す

る。反対にスループット比が低くなるほど、スケーリングも低下する。100 に近

い数値では、ほとんど変化しない。この測定値は、異なる環境を比較するときに

簡単な比較手段として使用できる。これには次のようなものがある。

• 追加クライアント • 追加 CPU (SMP システム) • さまざまなレベルのサーバー・コード

セグメント (TCP/IP) (Segment (TCP/IP)) - TCP はデータ・ストリームをオクテッ

トまたはバイトのシーケンスとして認識し、送信のためにこのシーケンスをセグ

メントに分割する。各セグメントは 1 つの IP データグラムに入れられてインター

ネット上を移動する。

データ・リンク制御 (DLC)(APPC) (Data Link Control (DLC)(APPC)) - 物理的に接

続されたマシン間でのデータ送信に使用される通信リンク・プロトコル。ユーザー・

データは DLC フレーム内で送信される。SNA ネットワークで一般に使用される DLC には、トークンリング、イーサネット、SDLC プロトコルなどがある。

トランザクション・プログラム (TP)(APPC) (Transaction Program (TP)(APPC)) - アプリケーション・プログラムがほかのアプリケーション・プログラムと通信する

ときに使用される論理ネットワーク名。

パケット (TCP/IP) (Packet (TCP/IP)) - ホストとそのネットワーク間の 1 つのトラ

ンザクションのデータからなるブロックまたは単位。通常、パケットにはネット

ワーク・ヘッダー、1 つ以上の高位プロトコル・ヘッダー、およびデータ・ブロッ

クが含まれている。パケットは、インターネットワーク層でデータを送受信する

ための交換媒体である。

ペーシング (APPC) (Pacing (APPC)) - SNA 内のデータ・フローを制御するための

メカニズム。ペーシングにより、大規模で高速なマシンと、小規模で性能が低い

マシンとの通信が可能になる。ペーシングは単一方向で行われる。つまり、マシ

ンでは受信ウィンドウとは別個に送信ウィンドウを持つことができる。

ポート (TCP/IP) (Port (TCP/IP)) -アプリケーション間通信のエンド・ポイント。

この接続は一般に論理接続を指す。TCP/IP はプロトコル・ポート番号を使用して、

マシン内の終宛先を識別する。

93

メガバイト (Megabyte) - 本書では、メガバイト (MB) は 1,048,576 バイト (2の20 乗) である。

要求/応答単位 (RU) (APPC) (Request/Response Unit (RU) (APPC)) - ユーザーおよ

びネットワーク制御データを搬送する SNA パケットの単位。パケットはマシン

間でユーザー・アプリケーション・データを搬送するために使用され、そのサイ

ズは大幅に異なる。

論理装置 (APPC) (Logical Unit :LU (APPC)) - TP が SNA ネットワークへのアクセ

スを取得するために使用するソケット。LU は、トランザクション・プログラム

の verb を受け入れ、実行する SNA ソフトウェアである。LU は TP に代わってネッ

トワークを管理し、データ経路指定を処理する。TP は LU を介して SNA へのア

クセスを獲得する。

物理装置 (PU) (Physical Unit (PU)) (APPC) - SNA ノードですべての LU の代わり

に物理ネットワーク・リソースを管理するプログラム。例えば、PU はノードと

隣接ノードとの接続を管理する。PU は LU の代わりに物理データ・リンクを管理

し、LU はノード間のセッションまたは必要な論理処理を管理する。

CPU 使用率 (CPU Utilization) - CPU 使用率は、システム CPU 時間合計を経過時

間で割って算出する。

CPU 秒あたりの KB (KB per CPU second): - 単一 CPU による CPU 使用時間 1 秒あたりのデータ (キロバイト) 転送効率を比較する数値。この数値は次の式により

算出される。 CPU 秒当たりの KB = (スループット (kb/秒) x 100) / (CPU 数 x % サーバー CPU 使用率)

数値が大きいほど、データ転送時の CPU 使用効率が高い。この数値を使用して、

異なるワークロードでの CPU の効率を比較したり、特定のパフォーマンス評価で

異なる CPU タイプを比較したりできる。SMP システムの場合、この測定基準が

単一 CPU の効率性に適用されることを理解しておくことが重要である。SMP システム内で連携する複数の CPU の全体的な効率性を見積もるには、「CPU 秒あ

たりの KB」に使用可能な CPU の数をかける。

ITR- 作業単位で測定される内部スループット率 (CPU 時間単位あたりの処理ファ

イル数など)。

MAXDATARCV (NetBIOS) - バイト単位で示される大受信データ・サイズ。こ

れは、このノードがセッションで受信できるフレームのユーザー・データの大

サイズである。

94

MAXIN (NetBIOS) - 肯定応答の送信前に受信した NetBIOS メッセージ・パケット

の数。

MAXOUT (NetBIOS) - 肯定応答の受信条件となる送信 NetBIOS メッセージ・パ

ケットの数。

MTU (TCP/IP) - 大伝送単位。セグメント・サイズの TCP 上限を定義するネッ

トワーク・パラメーター。

NETBIOSTIMEOUT (NetBIOS) - NetBIOS 送信または受信がタイムアウトになる

までの経過秒数。DSM.OPT に記述されている。

NETBIOSBUFFERSIZE (NetBIOS) - NetBIOS 通信バッファーのサイズ (KB 単位)。DSM.OPT に記述されている。

PACKETS (NetBIOS) - NetBIOS プロトコルが NetBIOS メッセージから DLC フレー

ムを構築するために使用できる I フレーム・パケット記述子の数。

PIGGYBACKACKS (NetBIOS) - 着信データに結合されている肯定応答を NetBIOS が送受信するかどうかを指定する。

SNA セッション (APPC) (SNA session (APPC))- SNA ネットワーク上の 2 つの LU の論理接続。

参考資料その他の資料

詳細な情報が収録されている関連資料を次に示します。

• 「Tivoli Storage Manager Version 4.2:Technical Guide」(SG24-6277) • 「Tivoli Storage Manager Version 5.1: Technical Guide」(SG24-6554-00) • 「Using Tivoli Storage Manager in a SAN Environment」(SG24-6132) • 「A Practical Guide to Tivoli SANergy」(SG24-6146) • 「TotalStorage UltraScalable テープ・ライブラリー 3584 およびオペレーター・

ガイド」(GA88-6972) • 「Total Storage Ultrium Scalable テープ・ライブラリー 3583 セットアップおよび

オペレーター・ガイド」(GA88-6957) • 「3581 Ultrium テープ・オートローダーセットアップ、オペレーターおよびサー

ビス・ガイド」(GA88-6958)

95

• 「3580 Ultrium テープ・ドライブセットアップ、オペレーターおよびサービス・

ガイド」(GA88-6959 ) • 「IBM Ultrium デバイス・ドライバーインストールおよびユーザーズ・ガイド」(GA88-8698) • 「SAN データ・ゲートウェイ・モジュールセットアップ、オペレーター、およ

びサービス・ガイド」(GA88-8224) • 「Tivoli Storage Manager for AIX SAN 管理システムストレージ・エージェントユー

ザーズ・ガイド」(GC88-9007) • 「Tivoli Storage Manager for Sun Solaris SAN 管理システムストレージ・エージェ

ントユーザーズ・ガイド」(GC88-9008)

IBM LTO 関連資料

• 「Using IBM LTO Ultrium with Open Systems」(SG24-6502-00 IBM Redbook Redpiece) • 「Implementing IBM LTO Tape in Linux and Windows」(SG24-6268 IBM Redbook) • 「Designing an IBM Storage Area Network」(SG24-5758) • 「Planning and Implementing an IBM SAN」(SG24-6116) • 「IBM SAN Survival Guide」(SG24-6143) • 「Using Tivoli Storage Manager in a SAN Environment」(SG24-6132) • 「The IBM LTO Ultrium Tape Libraries Guide」(SG24-5946)

その他の TCP/IP パフォーマンス関連資料

• Douglas E. Comer、「Internetworking with TCP/IP, Vol. I: Principles, Protocols,and Architecture」 Prentice-Hall, 1991. ISBN 0-13-468505-9. • 「AIX Version 3.2 for RISC System/6000 Performance Monitoring and Tuning Guide」 (IBM 資料 SC23-2365-01) • http://www.rs6000.ibm.com/support/sp/perf/ • 「Networking and Systems Management Services and Support」 (IBM 資料 GG66-3243-00) • 「TCP/IP Version 1.2.1 for OS/2 (Refresh): TCPLAPS」 (IBM 資料 SC31-7026) • 「TCP/IP Version 2 Release 2.1 for DOS User's Guide」 (IBM 資料 SC31-6153-03) • 「TCP/IP Version 2 Release 2.1 for MVS: User's Guide」 (IBM 資料 SC31-6088-02) • 「TCP/IP Version 2 Release 2.1 for OS/2 User's Guide」 (IBM 資料 SC31-6076-03)

参考 Web サイト

• TSM ホーム・ページ: http://www-3.ibm.com/software/tivoli/products/index/storage-mgr/

• IBM Redbooks: www.redbooks.ibm.com

96

http://www-3.ibm.com/software/tivoli/products/index/storage-mgr/

• Tivoli Storage Manager 製品技術サポート http://www-3.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

97

http://www-3.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

http://www-3.ibm.com/software/sysmgmt/products/support/IBMTivoliStorageManager.html

Tivoli Storage Manager Performance Tuning...

Documents

Transcript of Tivoli Storage Manager Performance Tuning...