Cisco Network Registrar ユーザー ガイド 7.0
サーバとデータベースの保守
サーバとデータベースの保守
発行日;2012/01/07 | ドキュメントご利用ガイド | ダウンロード ; この章pdf , ドキュメント全体pdf (PDF - 9MB) | フィードバック

目次

サーバとデータベースの保守

サーバの管理

繰り返しタスクのスケジューリング

サーバ イベントのロギング

ログの検索

ロギングの形式と設定

ログ ファイル

変更ログとタスク

サーバのステータスの監視とレポート

サーバの状態

安定度の表示

統計の表示

DNS の統計

DHCP の統計

TFTP の統計

IP アドレス使用状況の表示

関連サーバの表示

固定イベントを使用するリモート サーバの監視

DNS ゾーン分散サーバ

DHCP フェールオーバー サーバ

リースの表示

データ整合性ルールの実行

サーバのトラブルシューティング

迅速なトラブルシューティング処置

cnr.conf ファイルの修正

サーバ障害のトラブルシューティング

TFTP サーバのトラブルシューティングと最適化

TFTP サーバ アクティビティのトレース

TFTP メッセージのロギングの最適化

TFTP ファイル キャッシュのイネーブル化

Solaris と Linux のトラブルシューティング ツール

TAC ツールの使用

サーバとデータベースの保守

この章では、ローカルサーバとリージョナル サーバのオペレーションを管理および制御する方法について説明します。

サーバの管理

ccm-admin ロールの server-management サブロールを割り当てられている場合は、次のように Network Registrar サーバを管理できます。

起動 :データベースをロードしてサーバを起動します。

停止 :サーバを停止します。

リロード :サーバを停止して再起動します(ダイナミック アップデートごとに、サーバをリロードする必要はありません。詳細については、 第28章「DNS アップデートの設定」 を参照してください)。

統計の確認「統計の表示」を参照してください。

ログの表示「ログの検索」を参照してください。

インターフェイスの管理 :サーバ インターフェイスの管理方法については、それぞれのプロトコルのページを参照してください。

サーバの起動と停止については、特に補足説明することはありません。サーバをリロードする場合、Network Registrar は、サーバを停止し、設定データをロードして、サーバを再起動するという 3 つの動作を実行します。サーバはリロードされた後にのみ、設定に対する変更内容を使用します。


) DNS サーバ、DHCP サーバ、および SNMP サーバは、リブート時に起動されるのがデフォルトでイネーブルになっています。TFTP サーバは、リブート時に起動されるのがデフォルトでイネーブルになっていません。この設定を変更するには、CLI で [server] type enable または
disable start-on-reboot
を使用します。


ローカル Basic または Advanced およびリージョナル Web UI

プロトコル サーバを管理するには、状況に応じて次の操作を実行します。

ローカル クラスタ管理者またはリージョナル クラスタ管理者 Servers をクリックして、Manage Servers ページを開きます(ローカル クラスタの例については、図7-1を参照してください)。

図7-1 Manage Servers ページ(ローカル Basic)

 

ローカル クラスタとリージョナル クラスタでは、Web UI からサーバ管理にアクセスする方法は同じです。ただし、利用可能な機能が異なります。リージョナル管理者の場合、リージョナル CCM サーバ、サーバ エージェント、および Router Interface Configuration(RIC)サーバの状態と安定度を確認できます。ただし、それらの停止、起動、リロードを行ったり、それらについての統計、ログ、またはインターフェイスを表示したりすることはできません。

ローカル クラスタでは、DHCP、DNS、TFTP、および SNMP の各サーバを管理できます。

サーバの統計を表示するには、Statistics アイコン( )をクリックします(「統計の表示」を参照)。

サーバのログ メッセージを表示するには、View Log カラムで Log アイコン( )をクリックします(「サーバ イベントのロギング」を参照)。

サーバを起動するには、Start アイコン( )をクリックします。

サーバを停止するには、Stop アイコン( )をクリックします。

サーバをリロードするには、Reload アイコン( )をクリックします。

ローカル クラスタ DNS 管理者 DNS をクリックしてから DNS Server をクリックし、Manage DNS Server ページを開きます(図7-2 を参照)。

図7-2 Manage DNS Server ページ(ローカル Basic)

 

Statistics( )、Log( )、Start( )、Stop( )、Reload( )の各機能を実行できるほか、Commands カラムで Run アイコン( )をクリックして DNS Server Commands ページを開くことにより、その他の機能も実行できます(図7-3を参照)。

Expert モードでは、DNS サーバから CCM サーバを同期することができます。 Sync CCM Server from DNS Server をクリックして、Sync CCM Server from DNS Server ページを開きます。このページで同期する変更セットを確認してから Run をクリックし、 Return をクリックします。

図7-3 DNS Server Commands ページ(ローカル Basic)

 

サーバ コマンドには、次のような機能があります。

キャッシュのフラッシュ 「DNS キャッシュのフラッシュ」を参照):Run アイコン( )をクリックします。特定の時刻よりも古いキャッシュをフラッシュする場合は、Flush cache older than の横の Time フィードに時刻を入力し、Run アイコンをクリックします。これは、CLI の dns flushCache に相当します。

すべてのゾーン転送の強制 「ゾーン転送のイネーブル化」を参照):Run アイコン( )をクリックします。これは、CLI の dns forceXfer secondary に相当します。

すべてのゾーン転送の清掃 「ダイナミック レコードの清掃」を参照):Run アイコン( )をクリックします。これは、CLI の dns scavenge に相当します。

非権限リソース レコード セットの削除 「キャッシュ レコードの削除」を参照):RR セットの名前を Name フィールドに入力し、Run アイコン( )をクリックします。オプションとして、非権限 RR セットを特定のタイプまたはデータに基づいて削除する場合は、その値を Type フィールドまたは Data フィールドに入力します。これは、CLI の dns removeCachedRR name type data に相当します。

ローカル クラスタ DHCP 管理者 DHCP をクリックしてから DHCP Server をクリックし、Manage DHCP Server ページを開きます。Statistics( )、Log( )、Start( )、Stop( )、Reload( )の各機能を実行できるほか、Commands カラムで Run アイコン( )をクリックして DHCP Server Commands ページを開くことにより、その他の機能も実行できます(図7-4 を参照)。

図7-4 DHCP Server Commands ページ(ローカル Basic)

 

このページは、共通の制限 ID によって関連付けられた複数のクライアントを検出する Get Leases with Limitation ID 機能を提供します(「オプション 82 制限の管理」を参照)。少なくとも現在アクティブなリースの IP アドレスを IP Address フィールドに入力し、Run アイコン( )をクリックします。制限 ID 自体を nn : nn : nn の形式で、または文字列( " nnnn " )として入力することもでき、その場合、IP アドレスは検索対象のネットワークになります。この機能は、CLI の dhcp limitationList ipaddress limitation-id show に相当します。

CLI コマンド

CLI の場合(リージョナル クラスタでは CCM サーバの管理のみ可能):

サーバを起動するには、 server type start (または単に type start 、たとえば dhcp start )を使用します。

サーバを停止するには、 server type stop (または単に type stop 、たとえば dhcp stop )を使用します。サーバを停止する場合は、まず、 save コマンドを使用してサーバを保存することをお勧めします。

サーバをリロードするには、 server type reload (または単に type reload 、たとえば、 dhcp reload )を使用します。Network Registrar は選択されたサーバを停止し、設定データをロードしたあと、サーバを再起動します。

サーバのアトリビュートを設定または表示するには、[ server ] type set attribute = value または [ server ] type show を使用します。次に例を示します。

nrcmd> ccm set ipaddr=192.168.50.10
 

繰り返しタスクのスケジューリング

ローカル クラスタの Web UI で Basic および Advanced ユーザ モードで操作している場合、さまざまな繰り返しタスクをスケジュール設定できます。次のタスクが可能です。

DHCP サーバのリロード

DNS サーバのリロード

DHCP フェールオーバー サーバ ペアの同期

ステージ スコープ編集モードの場合は、メイン DHCP サーバをリロードします。

フェールオーバー構成をバックアップ DHCP サーバに同期します。

ステージ スコープ編集モードの場合は、バックアップ DHCP サーバをリロードします。

ハイ アベイラビリティ(HA)DNS サーバ ペアの同期

ステージ スコープ編集モードの場合は、メイン DNS サーバをリロードします。

HA DNS 構成をバックアップ DNS サーバに同期します。

ステージ スコープ編集モードの場合は、バックアップ DNS サーバをリロードします。

ゾーン分散マップの同期

ステージ スコープ編集モードの場合は、メイン DNS サーバをリロードします。

ステージ スコープ編集モードの場合は、バックアップ HA DNS サーバをリロードします。

ゾーン分散マップを同期します。

ステージ スコープ編集モードの場合は、セカンダリ DNS サーバ(複数の場合あり)をリロードします。

ローカル Basic または Advanced Web UI

このような繰り返し発生するサーバ タスクを設定するには、次の操作を実行します。


ステップ 1 Servers をクリックしてから Scheduler をクリックし、List Scheduled Tasks ページを開きます。

ステップ 2 Add Task をクリックして、Add Scheduled Task ページを開きます(図7-5 を参照)。

図7-5 Add Scheduled Task ページ(ローカル Basic)

 

ステップ 3 該当するフィールドに値を入力します。

a. スケジュール設定するタスクの名前。識別可能なものであれば、どのようなテキスト文字列でもかまいません。

b. タスクの説明。

c. ドロップダウン リストからタスクのタイプを選択します。

dhcp-reload :DHCP サーバのリロード

dns-reload :DNS サーバのリロード

sync-dhcp-pair :DHCP フェールオーバー サーバ ペアの同期

sync-dns-pair :HA DNS フェールオーバー サーバ ペアの同期

sync-zd-map :ゾーン分散マップの同期

sync-dns-update-map :DNS 更新マップの同期

d. Advanced モードでは、タスクのイネーブルまたはディセーブルを選択します(どちらのモードでもプリセット値はイネーブルです)。

e. スケジュール設定するタスクを実行する間隔を、60m や 4w2d のように指定します。

f. スケジュールのオフセットまたはタスクを実行する一定の時刻を、深夜 0 時を基準にして 1 時間単位で指定します。スケジュール設定する間隔は 24h 未満に設定し、オフセットは間隔よりも小さく設定する必要があります。たとえば、 scheduled-interval を 4h に、 scheduled-offset を 2 に設定すると、タスクは、午前 2 時、午前 6 時、午前 10 時、午後 2 時、午後 6 時、および午後 10 時に実行されます。

g. DHCP フェールオーバー ペア、HA DNS ペア、ゾーン分散マップを同期する場合は、タスクに関連付けられたオブジェクト ID も指定できます。

ステップ 4 Add New Task をクリックします。

ステップ 5 List Scheduled Tasks ページでタスク名をクリックすると、最新の状態またはタスク実行時に発生したエラーの最新のリスト(エラーが発生した場合)が、Edit Scheduled Task ページの Task Status セクションに表示されます。タスクをすぐに実行する場合は、 Run Now をクリックします。


 

サーバ イベントのロギング

Network Registrar を起動すると、Network Registrar システム アクティビティのロギングが自動的に開始されます。Network Registrar は、デフォルトで、すべてのログを次の場所に保持します。

Windows install-path \logs

Solaris および Linux install-path /logs(これらのログを表示するには、 tail -f コマンドを使用します)


ヒント Windows Event Viewer が満杯にならないようにする場合、および Network Registrar が動作しないようにする場合は、Event Log Settings の Overwrite Events as Needed ボックスをオンにします。イベントが満杯になった場合は、イベントをファイルに保存したうえで、Event Log からイベントをクリアします。


ローカル Basic または Advanced およびリージョナル Web UI

Web UI でサーバ ロギングを行うには、Manage Servers ページを開き(「サーバの管理」を参照)、対象サーバの View Log カラムで Log アイコン( )をクリックします。Log for Server ページが開きます。最新のログから順に表示されます。以前のログを参照するには、ページ上部または下部の左矢印をクリックします。

ログの検索

Web UI では、アクティビティ ログ ファイルおよび起動ログ ファイルの中からエントリを簡単に検索できます。正規表現の文字列エントリを使用して、特定のメッセージ テキスト、ログ メッセージ ID、およびメッセージ タイムスタンプを検出できます。Manage Servers ページの View Log カラムまたは View Startup カラムで Log アイコン( )をクリックすると、Log for Server ページが開きます。ページの上部または下部にある Search アイコン( )の横のテキスト フィールドに、検索文字列を正規表現シンタックスで入力します。たとえば、 name? と入力すると、ログ ファイルの中から文字列「name」の出現場所を検索できます。

Search アイコン( )をクリックすると、Log Search Result ページが別のブラウザ ウィンドウで開きます(図7-6の例を参照)。このページには、ログ ファイル、一致のあった行番号、およびログ番号が表示されます。

図7-6 Log Search Result ページ(ローカル)

 

ログ メッセージの名前をクリックすると、メッセージ テキストの全文を示した Log for Server ページが開きます。表とテキストの表示を切り替えるには、Log アイコン( )をクリックします。ブラウザ ウィンドウを閉じるには、Log Search Result ページの Close をクリックします。

ロギングの形式と設定

サーバ ログ エントリには、次のようなカテゴリがあります。

Activity :サーバのアクティビティのロギングです。

Info :起動やシャットダウンなどサーバの標準オペレーションのロギングです。

Warning :要求の処理中に発生する無効なパケット、ユーザの通信不良、またはスクリプトのエラーなどの警告のロギングです。

Error :メモリの不足、リソースの取得が不可能、設定のエラーなど、サーバの正常な動作を妨げるイベントのロギングです。


警告およびエラーは、Windows の Event Viewer に送られます(P.7-7の「ヒント」を参照)。各サーバ モジュールのログ メッセージについては、install-path/docs/msgid/MessageIdIndex.html ファイルを参照してください。


ローカル Basic または Advanced およびリージョナル Web UI

ロギングするイベントを変更できます。たとえば、ローカル クラスタの DNS および DHCP サーバのロギングを設定するには、次の操作を行います。

DNS DNS をクリックしてから DNS Server をクリックし、Manage DNS Server ページを開きます。サーバの名前をクリックして、Edit DNS Server ページを開きます。Logging attributes セクションを展開し、ログの設定を表示します。必要に応じてこれらの設定に変更を加え、 Modify Server をクリックしてから、サーバをリロードします(DNS サーバのパフォーマンスを最大に高めるためのログ設定については、表17-2を参照してください)。

DHCP DHCP をクリックしてから DHCP Server をクリックし、Manage DHCP Server ページを開きます。サーバの名前をクリックして、Edit DHCP Server ページを開きます。Logging セクションを展開し、ログの設定を表示します。必要に応じてこれらの設定に変更を加え、 Modify Server をクリックしてから、サーバをリロードします(DHCP サーバのパフォーマンスを最大に高めるためのログ設定については、表23-2を参照してください)。

CLI コマンド

各サーバに対してそれぞれ dns set log-settings dhcp set log-settings 、および tftp set log-settings を使用します。

ログ ファイル

表7-1 では、 install-path /logs ディレクトリにある Network Registrar のログ ファイルについて説明します。

 

表7-1 .../logs ディレクトリのログ ファイル

コンポーネント
/logs ディレクトリのファイル
ローカル/
リージョナル
ログ

インストール

install_cnr_log

両方

インストール プロセス

アップグレード

mcdupgrade_log

両方

アップグレード プロセス

サーバ エージェント

agent_server_1_log

両方

サーバ エージェントの起動と停止

ポート チェック

checkports_log

両方

ネットワーク ポート

DNS サーバ

name_dns_1_log

ローカル

DNS アクティビティ

DHCP サーバ

name_dhcp_1_log

ローカル

DHCP アクティビティ

TFTP サーバ

file_tftp_1_log
file_tftp_1_trace

ローカル

TFTP アクティビティ

SNMP サーバ

cnrsnmp_log

ローカル

SNMP アクティビティ

RIC サーバ

ric_server_log

両方

RIC サーバ アクティビティ

CCM データベース

config_ccm_1_log

両方

CCM の設定、起動、および停止

Web UI

cnrwebui_log

両方

Web UI の状態

Tomcat/Web UI(cnrwebui サブディレクトリ内)

catalina_log. date .txt
jsui_log. date .txt
localhost_access_log. date .txt

両方

Tomcat サーバおよび Web UI の CCM データベース(新しいファイルが毎日作成されるため、定期的に古いログ ファイルをアーカイブする)

各コンポーネントにはログ ファイルをいくつか生成でき、それぞれの最大サイズは 1 MB に事前設定されています。最初のログ ファイル名には _log というサフィックスが付きます。このファイルが最大サイズに達すると、名前の末尾に .01 というバージョン拡張子が付き、バージョン拡張子のない新しいログ ファイルが作成されます。新しいファイルが作成されるたびに、バージョン拡張子が 1 ずつインクリメントされます。ファイル数が設定された最大数に達すると、最も古いファイルが削除され、次に古いファイルがその名前を引き継ぎます。通常、最大数は、DNS、DHCP、および TFTP サーバに対して 4 つです。


) ユーザ コマンドの中には、クラスタとの間に別の接続があるために、サーバ エージェント ログの User authentication エントリが作成できるコマンドもあります。これらを他のユーザによるシステム セキュリティ違反と解釈しないでください。


CLI コマンド

DNS、DHCP、および TFTP サーバに対して設定されている最大数を確認するには、CLI の [ server ] type serverLogs show を使用します。これを使用すると、これらのプロトコル サーバ ログ ファイルの最大数( nlogs )とサイズ( logsize )が表示されます。これらのパラメータを調整するには、[ server ] type serverLogs set nlogs= value[ server ] type serverLogs set logsize= value を使用します。その他のログ ファイルについてこれらの最大値を調整することはできません。

変更ログとタスク

Web UI では、実行した設定の変更ログとタスクを表示できます。

ローカル Advanced およびリージョナル Web UI

Administration Change Log の順にクリックしてから、 CCM Tasks または MCD Tasks をクリックします。変更ログとタスクを表示するには、ccm-admin ロールまたは regional-admin ロールの database サブロールを割り当てられている必要があります。

View Change Log ページ(図7-7を参照)に、すべての変更ログが DBSN 名順にソートされて表示されます。リストの最後を表示するには、ページ左下の右矢印をクリックします。変更ログ エントリの DBSN 番号をクリックすると、そのエントリの View Change Set ページが開きます。

図7-7 View Change Log ページ(ローカル Advanced)

 

List CCM Tasks ページにすべての CCM タスクが表示されます。

List MCD Tasks ページにはすべての MCD タスクが表示されます。

View Change Log ページでは、リストをフィルタにかけ、手動でトリムし、ファイルに保存できます。リストをフィルタにかける場合、次の基準を使用できます。

開始日および終了日

変更を開始した管理者

設定オブジェクト クラス

特定のオブジェクト

オブジェクト ID(形式は OID-00:00:00:00:00:00:00:00)

サーバ

Filter List または Clear Filter をクリックします(セッションに残っているフィルタをクリアするため)。変更ログのトリムを開始するには、トリムを行う前に、どれくらい日数が経ったレコードを取得するかを設定するために、「older than」フィールドに日数値を設定し、Delete アイコン( )をクリックします。

変更ログ エントリをカンマ区切り値(CSV)ファイルに保管するには、Save アイコン( )をクリックします。

変更ログにタスクが関連付けられている場合は、そのタスクが View Change Set ページに表示されます。タスク名をクリックすると、そのタスクの View CCM Task ページまたは View MCD Task ページを開くことができます。

サーバのステータスの監視とレポート

サーバのステータスを監視する場合は、次の項目を確認します。

状態

安定度

統計

ログ メッセージ

アドレス使用状況

関連サーバ(DNS および DHCP)

リース(DHCP)

サーバの状態

すべての Network Registrar プロトコル サーバ(DNS、DHCP、SNMP、および TFTP)は、次の各状態からなるステート マシンを経由します。

ロード済み :サーバ エージェントがサーバを起動した後の最初のステップ(過渡的)。

初期化済み :サーバが停止しているか、サーバを設定できません。

未設定 :設定に失敗したため、サーバが動作可能ではありません(過渡的)。

停止中 :サーバは管理上の理由で停止したか、動作していません(過渡的)。

動作中 :サーバは正常に動作しています。

2 つの状態、「初期化済み」と「動作中」は重要です。サーバは各状態を非常に速く変遷するので、他の状態は実質的に可視でないからです。通常、サーバ エージェントはサーバを起動するとき、サーバに起動するよう指示します。サーバ プロセスが起動し、状態を「ロード済み」に設定してから、「動作中」に移行します。サーバを停止した場合、サーバは状態を「初期化済み」へ移行し、再起動すると、再び「動作中」に移行します。何らかの理由でサーバを設定できない場合は、停止した場合と同様に、サーバは「初期化済み」に戻ります。

「終了中」という状態もあり、サーバはプロセスが終了しようとしているとき、非常に短い時間だけ、この状態になります。ユーザ インターフェイスがサーバを「ディセーブル」と見なす場合もありますが、これは非常にまれに、サーバ プロセスがまったく存在しない(サーバ エージェントがサーバ プロセスを開始しないよう指示された)ときにのみ発生します。

安定度の表示

サーバの安定度に関して、どの程度良好に動作しているかを表示できます。次の項目はサーバの安定度を低下させる可能性があるので、これらのステータスを定期的に監視する必要があります。項目は次のとおりです。

サーバ エージェント(ローカル クラスタとリージョナル クラスタ)

CCM サーバ(ローカル クラスタとリージョナル クラスタ)

DNS サーバ(ローカル クラスタ):

設定エラー

メモリ

ディスク領域の使用状況

ルート サーバへアクセスできない

DHCP サーバ(ローカル クラスタ):

設定エラー

メモリ

ディスク領域の使用状況

パケット キャッシュの低下

指定されたパケット リミットにオプションが適合しない

使用可能なリースがない

TFTP サーバ(ローカル クラスタ):

メモリ

ソケットの読み取りまたは書き込みエラー

過負荷しきい値の超過と要求パケットのドロップ

RIC サーバ(リージョナル クラスタ)


ヒント 安定度の値は 10(最高安定度)~ 0(サーバが稼働していない)です。安定度の値が低下している場合は、そのサーバのログ ファイルを確認してください。

Solaris または Linux では、cnr_status コマンド(install-path/usrbin/ ディレクトリ内)を実行すると、ローカル クラスタ サーバが動作しているかどうかを確認できます。『Installation Guide for Cisco Network Registrar』を参照してください。


ローカル Basic または Advanced およびリージョナル Web UI

Administration をクリックしてから Servers をクリックします。Manage Servers ページで、各サーバの状態と安定度を確認します(DHCP サーバの例については、図7-1を参照してください)。

CLI コマンド

[ server ] type getHealth を使用します。数字の 10 は安定度が最高レベルであることを示し、0 はサーバが動作していないことを示します。

統計の表示

サーバの統計を表示するには、サーバが動作している必要があります。

ローカル Basic または Advanced およびリージョナル Web UI

Manage Servers ページに移動し、Statistics カラムの Statistics アイコン( )をクリックします(使用可能な場合)。Server Statistics ページで、ポップアップ ヘルプを表示するには、アトリビュートの名前をクリックします。

DHCP と DNS の統計は、それぞれ 2 つの統計グループに分割されます。最初のグループは、合計統計用で、2 番目のグループはサンプリング統計用です。合計統計は、時間の経過とともに蓄積されます。サンプリング統計は、設定可能なサンプリング間隔中に発生します。これら 2 つのカテゴリの名前は、サーバごと、およびユーザ インターフェイスごとに異なり、 表7-2 に示されています。

 

表7-2 サーバ統計のカテゴリ

サーバ
ユーザ
インターフェイス
総統計(コマンド)
サンプリング統計(コマンド)

DHCP

Web UI

Total Statistics

Activity Summary

CLI

前回の DHCP サーバ プロセスを開始してからの Total Counters
dhcp getStats

前回のサンプリング間隔以降の Sampled カウンタ
dhcp getStats sample

DNS

Web UI

Total Statistics

Sample Statistics

CLI

前回のサーバ プロセスを開始してからの Total Counters
dns get Stats

前回のサンプリング間隔以降の Sampled カウンタ
dns getStats sample

サンプリング カウンタを設定するには、サーバの collect-sample-counters アトリビュートをアクティブにするか、activity-summary と呼ばれる log-settings アトリビュート値をアクティブにする必要があります。各サーバのサンプリング間隔の log-settings 値を設定することもできます(この値は 5 分にプリセットされています)。 collect-sample-counters アトリビュートは、DNS サーバの場合は true に、DHCP サーバの場合は false にプリセットされています。たとえば、サンプリング カウンタをイネーブルにして DHCP の間隔を設定するには、DHCP サーバの次のアトリビュートを設定します。

collect-sample-counters をイネーブルにする( dhcp enable collect-sample-counters

log-settings を activity-summary に設定する( dhcp set log-settings=activity-summary

activity-summary-interval を 5m に設定する( dhcp set activity-summary-interval=5m

CLI コマンド

CLI で [ server ] type getStats を使用した場合、統計は中カッコの中に符号化され、その後に一連の数字が続きます。この数字については、表7-3(DNS)、表7-4(DHCP)、および表7-5(TFTP)に説明があります。 server type getStats all コマンドは、さらに冗長性があり、統計情報を 1 行に 1 つずつ示します。追加の sample キーワードを使用すると、サンプリング統計だけが表示されます。

カウンタと統計の総計をリセットするには、 dhcp resetStats または dns resetStats を使用します。

DNS の統計

DNS サーバ統計は、Web UI で DNS Server Statistics ページに表示されます。各統計名をクリックすると、説明が表示されます。

CLI の dns getStats コマンドには、次のオプションがあります。

dns getStats [performance | query | errors | security | maxcounters | ha | ipv6 | all] [total | sample]
 

最もよく使用されるコマンドは、 dns getStats all です。オプションなしの dns getStats は、次の形式による 1 行のポジショナル値で統計を返します(値の読み方については 表7-3 を参照)。

nrcmd> dns getStats
100 Ok
{1} 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
 

 

表7-3 DNS の統計

統計
説明

{1}

id

実装 ID(リリースとビルドの情報)。

2

config-recurs

再帰サービス:(1)使用可能、(2)制限、(3)使用不可。

3

config-up-time

前回のサーバの起動以後に経過した時間(秒単位)。

4

config-reset-time

前回のサーバのリセット(再起動)以後に経過した時間(秒単位)。

5

config-reset

いずれかのネームサーバの状態を再初期化するためのステータスまたはアクション:(2)リセット アクションを使用した場合、持続しているネームサーバの状態が再初期化されます。以下は、読み取り専用ステータスです。(1)other(サーバは不明の状態)、(2)initializing、または(3)running。

6

counter-auth-ans

信頼できる回答が行われたクエリーの数。

7

counter-auth-no-names

authoritative no such name 」という応答を返したクエリーの数。

8

counter-auth-no-data-resps

authoritative no such data 」(空の回答)という応答を返したクエリーの数。

9

counter-non-auth-datas

信頼できない(キャッシュを使用して)回答が行われたクエリーの数。

10

counter-non-auth-no-datas

データを伴わず、信頼できない回答が行われたクエリーの数。

11

counter-referrals

他のサーバへ転送されたクエリーの数。

12

counter-errors

エラー(RCODE 値が 0 と 3 のどちらでもない)で回答した応答の数。

13

counter-rel-names

ラベルが 1 つのみの名前(相対名)に関して受信された要求の数。

14

counter-req-refusals

拒否されたクエリーの数

15

counter-req-unparses

解析不可能な要求の数。

16

counter-other-errors

他のエラーによって打ち切られた要求の数。

17

total-zones

設定されているゾーンの合計数。

DHCP の統計

DHCP サーバ統計は、Web UI で DHCP Server Statistics ページに表示されます。各統計名をクリックすると、説明が表示されます。

CLI の dhcp getStats コマンドには、次のオプションがあります。

dhcp getStats [[all | server [,] failover [,] dhcpv6] [total | sample]
 

最もよく使用されるコマンドは、 dhcp getStats all です。オプションなしの dhcp getStats は、次の形式による 1 行のポジショナル値で統計を返します(値の読み方については 表7-4 を参照)。

nrcmd> dhcp getStats
100 Ok
{1} 2 3 4 5 6 7 8
 

 

表7-4 DHCP の統計

統計
説明

{1}

start-time-str

前回のサーバ リロード日時(テキスト文字列)。

2

total-discovers

受信された DISCOVER パケットの数。

3

total-requests

受信された REQUEST パケットの数。

4

total-releases

受信された RELEASED パケットの数。

5

total-offers

送信された OFFER パケットの数。

6

total-acks

送信された確認応答(ACK)パケットの数。

7

total-naks

送信された否定応答(NAK)パケットの数。

8

total-declines

受信された DECLINE パケットの数。

TFTP の統計

TFTP サーバ統計は、Web UI で TFTP Server Statistics ページに表示されます。各統計名をクリックすると、説明が表示されます。 表7-5 は、汎用 tftp getStats コマンドへの出力としてエンコードされた TFTP 統計を示します。次の形式です。

nrcmd> tftp getStats
100 Ok
{1} 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29
 

 

表7-5 TFTP の統計

アトリビュート
説明

{1}

id

実装 ID(リリースとビルドの情報)。

2

server-state

サーバの状態(up または down)。

3

server-time-since-start

前回の起動以後の動作時間。

4

server-time-since-reset

前回のリセット以後の動作時間。

5

total-packets-in-pool

プール内のパケット数。

6

total-packets-in-use

サーバが使用しているパケットの数。

7

total-packets-received

前回の起動以後またはリロード以後の受信パケットの数。

8

total-packets-sent

前回の起動以後またはリロード以後の送信パケットの数。

9

total-packets-drained

前回の起動以後またはリロード以後に廃棄された読み取りパケットの数。

10

total-packets-dropped

前回の起動以後またはリロード以後にドロップされたパケットの数。

11

total-packets-malformed

前回の起動以後またはリロード以後に受信された形式誤りパケットの数。

12

total-read-requests

前回の起動以後またはリロード以後の読み取りパケットの数。

13

total-read-requests-completed

前回の起動以後またはリロード以後に完了した読み取りパケットの数。

14

total-read-requests-refused

前回の起動以後またはリロード以後に拒否された読み取りパケットの数。

15

total-read-requests-ignored

前回の起動以後またはリロード以後に無視された読み取りパケットの数。

16

total-read-requests-timed-out

前回の起動以後またはリロード以後にタイムアウトした読み取りパケットの数。

17

total-write-requests

前回の起動以後またはリロード以後に読み取られた書き込み要求パケットの数。

18

total-write-requests-completed

前回の起動以後またはリロード以後に完了した書き込み要求の数。

19

total-write-requests-refused

前回の起動以後またはリロード以後に拒否された書き込み要求の数。

20

total-write-requests-ignored

前回の起動以後またはリロード以後に無視された書き込み要求の数。

21

total-write-requests-timed-out

前回の起動以後またはリロード以後にタイムアウトした書き込み要求の数。

22

total-docsis-requests

前回の起動以後またはリロード以後に受信された DOCSIS 要求の数。

23

total-docsis-requests-completed

前回の起動以後またはリロード以後に完了した DOCSIS 要求の数。

24

total-docsis-requests-refused

前回の起動以後またはリロード以後に拒否された DOCSIS 要求の数。

25

total-docsis-requests-ignored

前回の起動以後またはリロード以後に無視された DOCSIS 要求の数。

26

total-docsis-requests-timed-out

前回の起動以後またはリロード以後にタイムアウトした DOCSIS 要求の数。

27

read-requests-per-second

1 秒あたりの読み取り要求の数。

28

write-requests-per-second

1 秒あたりの書き込み要求の数。

29

docsis-requests-per-second

1 秒あたりの DOCSIS 要求の数。

IP アドレス使用状況の表示

IP アドレス使用状況を表示すると、クライアントにどのようにアドレスが割り当てられているかを確認できます。

ローカル Advanced およびリージョナル Web UI

IP アドレス使用状況を確認する場合、リージョナル クラスタで、ローカル クラスタまたはリージョナル クラスタのアドレス空間を参照するか、サブネットの使用状況レポートまたはリース履歴レポートを生成することができます。これらの機能は、どちらの Web UI でも Address Space をクリックすると使用できます。ただし、ローカル クラスタまたはリージョナル クラスタのアドレス空間特権を持っている必要があります。

現在のアドレス空間の使用状況を判別するには、統合されたアドレス空間、アドレス ブロック、およびサブネットの Current Usage カラムで View アイコン( )をクリックします(「アドレス ブロック、サブネット、およびスコープのアドレス使用状況の表示」を参照)。また、リース履歴を照会することにより、最新の IP アドレス使用状況を取得することもできます(「リースの照会」を参照)。後者の場合、リージョナル CCM サーバは該当する DHCP サーバを直接参照します。このサブネットからサーバへのマッピングを保証するには、リージョナル アドレス空間の表示を更新する必要があります。更新することにより、関連するローカル クラスタとの一貫性が保たれます。そのためには、複製アドレス空間を取得するか、サブネットを解放して DHCP サーバへ適用します(「サブネットの解放」を参照)。また、特定の DHCP サーバが動作中であることを確認します。

CLI コマンド

report コマンドを使用すると、IP アドレス使用状況レポートを生成できます。このコマンドのシンタックスは次のとおりです。

report [column-separator=string | dhcpv4 | dhcp-only | dhcpv6 | file=outputfile | vpn=name
 

column-separator は、レポートのカラムを区切る文字列を指定します(プリセット値は空白文字)。2 つ以上の空白文字を指定する場合は、指定する文字の前にエスケープ文字のバックスラッシュ( \ )を置き、引用符で囲みます。DHCPv4 アドレスまたは DHCPv6 アドレスも指定できます( dhcp-only dhcpv4 と同じです)。VPN を指定しないと、現在の VPN でのアドレスのみが返されます。

関連サーバの表示

Network Registrar は、DNS ゾーン分散内または DHCP フェールオーバー構成内のサーバ間の関係を表示します。Web UI では、さまざまなページで Related Servers アイコン( )をクリックすると、関連するサーバのページを表示できます。関連するサーバのディスプレイを使用して、設定に問題のあるサーバや到達不能なサーバを診断および監視できます。

固定イベントを使用するリモート サーバの監視

DNS および LDAP に関連するサーバのアップデートを要求するクライアントにサービスを提供するため、DHCP サーバは、関連するサーバが一時的に利用できない場合に、固定イベント アルゴリズムを使用して関連サーバへのアップデートを行います。また、このアルゴリズムは、設定に問題のある DNS サーバまたはオフラインの DNS サーバが、利用可能なアップデート リソースをすべて消費するのを防止します。

起動時に、DHCP サーバは、固定イベントを必要とするコンフィギュレーション内の関連サーバの数を計算します。事前に設定された Maximum Pending Events アトリビュート(40,000 にプリセットされた in-memory イベントの数を指定する Expert モード アトリビュート)をサーバの数で割り、各リモート サーバに対して許可されたイベントの数の限度を取得します。この計算は、関連する DNS サーバおよび LDAP サーバを網羅するものです(DHCP フェールオーバーではイベント用の固定ストレージは使用されません)。DHCP サーバはこの計算を使用してログ メッセージを発行し、 表7-6 で示されているアクションを実行します。この表は、DHCP サーバ 1 台と、それぞれイベントが 10,000 に制限された 4 台の関連 DNS サーバが配置された場合を想定したものです。

 

表7-6 固定イベント アルゴリズム

固定イベント
DHCP サーバのアクション

計算されたサーバごとの限度(Maximum Pending Events 値を関連サーバの総数で割った値)の 50%。たとえば、保留中イベント最大数が 40,000、関連サーバ 1 台あたりイベント数が 5,000 です。

限界を超過している間、次のように 2 分ごとに INFO ログ メッセージが発行されます。

The queue of events for the name remote server at address has x events, and has reached the info limit of y /2 events out of an upper limit of y events per remote server. The remote server may be misconfigured, inoperative, or unreachable.
 

計算されたサーバごとの限界に到達(100%)し、かつ Maximum Pending Events 値の 50% 未満。たとえば、各関連サーバのイベント数が 10,000、保留中イベント最大数の合計が 10,000 未満です。

限界を超過している間、次のように 2 分ごとに WARNING ログ メッセージが発行されます。

The queue of events for the name remote server at address has x events, has exceeded the limit of y events per remote server, but is below the limit of z total events in memory. The remote server may be misconfigured, inoperative, or unreachable.
 

計算されたサーバごとの限界に到達(100%)し、かつ Maximum Pending Events 値の 50% 以上。たとえば、各関連サーバのイベント数が 10,000、保留中イベント最大数の合計が 20,000 です。

限界を超過している間、次のように 2 分ごとに ERROR ログ メッセージが発行されます。

The queue of events for the name remote server at address has x events, and has grown so large that the server cannot continue to queue new events to the remote server. The limit of y events per remote server and z /2 total events in memory has been reached. This and future updates to this server will be dropped. The current eventID n is being dropped.
 

サーバでは、現在のトリガー イベントとそのサーバ上の後続のすべてのイベントがドロップされます。

Maximum Pending Events 値に到達(100%)。たとえば、すべての関連サーバのイベント総数が 40,000 です。

次のように ERROR ログ メッセージが発行されます。

The queue of pending events has grown so large that the server cannot continue to queue new events. The queue's size is z , and the limit is z .
 

サーバは、すべての関連サーバにおけるすべての後続イベントをドロップします。

SNMP トラップと DHCP サーバ ログ メッセージにも、関連するサーバが到達不能であることが記載されます。

DNS ゾーン分散サーバ

DNS ゾーン分散を使用すると、同じセカンダリ サーバ アトリビュートを共有する複数のゾーンを簡単に作成できます。ゾーン分散内のプライマリおよびセカンダリ DNS サーバを表示および設定できます。

ローカル Basic または Advanced Web UI

DNS をクリックし、 Zone Distribution をクリックします。List Zone Distributions ページが開きます。デフォルトでは、ローカル クラスタはゾーン分散を 1 つだけ使用できます。ゾーン分散名をクリックして Edit Zone Distribution ページを開きます。このページにゾーン分散内の権限サーバとセカンダリ サーバが表示されます。

リージョナル Web UI

DNS をクリックし、 Zone Distributions をクリックします。List/Add Zone Distributions ページが開きます(図15-7を参照)。リージョナル クラスタでは、複数のゾーン分散を作成できます。ゾーン分散名をクリックして Edit Zone Distribution ページを開きます。このページにゾーン分散内のプライマリ サーバ、権限サーバ、およびセカンダリ サーバが表示されます。

CLI コマンド

zone-dist name create primary-cluster を使用してゾーン分散を作成し、 zone-dist list を使用してそれを表示します。次に例を示します。

nrcmd> zone-dist distr-1 create Boston-cluster
nrcmd> zone-dist list
 

DHCP フェールオーバー サーバ

DHCP フェールオーバー ペアの関係にある関連サーバは、次の情報を表示できます。

タイプ :メインまたはバックアップの DHCP サーバ。

サーバ名 :サーバの DNS 名。

IP アドレス :ドット付きオクテット形式によるサーバの IP アドレス。

要求 :未処理の要求の数、または 2 つのダッシュ(該当する要求がない場合)。

通信のステータス :OK または INTERRUPTED。

クラスタの状態 :この DHCP サーバのフェールオーバー状態。

パートナーの状態 :パートナー サーバのフェールオーバー状態。

DHCPv6 フェールオーバー実装の詳細については、 第27章「DHCP フェールオーバーの構成」 を参照してください。

ローカル Basic または Advanced Web UI

DHCP をクリックしてから Failover をクリックします。List DHCP Failover Pairs ページに、フェールオーバー関係にあるメイン サーバとバックアップ サーバが表示されます。

CLI コマンド

dhcp getRelatedServers を使用して、DHCP サーバのメインとパートナー間の接続のステータスを表示します。関連サーバが存在しない場合、出力は「 100 Ok 」だけです。

リースの表示

スコープの作成後、リースのアクティビティを監視し、リースのアトリビュートを表示することができます。

ローカル Basic または Advanced Web UI

DHCP をクリックしてから、 Scopes または Prefixes をクリックします(Advanced モードの場合)。List/Add DHCP Scopes ページまたは List DHCPv6 Prefixes ページで、Leases カラム内の View アイコン( )をクリックし、List DHCP Leases for Scope ページまたは List DHCP Leases for Prefix ページを開きます。

リージョナル Web UI

Address Space をクリックしてから、 Lease History をクリックします。クエリー パラメータを設定し、 Query Lease History をクリックします(「リースの照会」を参照)。

データ整合性ルールの実行

整合性ルールを使用して、アドレス範囲とサブネットの重なりなど、データの不一致をチェックすることができます。データ整合性ルールはリージョナル クラスタおよびローカル クラスタに設定できます。各クラスタで設定できる整合性ルールについては、 表7-7 および 表7-8 を参照してください。

 

表7-7 リージョナル クラスタにおけるデータ整合性ルールの設定

リージョナルの整合性ルール
説明

Attributes Consistency Rule

複製で名前が同じポリシーとクライアントクラスが同じ値を持つことを保証します。

Broadcast Address Rule

スコープのダイナミック アドレス範囲にブロードキャスト アドレスが含まれないことを保証します。

Cable Helper Consistency Rule

ケーブル ヘルパーと DHCP フェールオーバーに一貫性があることを保証します。

Client-Class Selection Match Tag Rule

スコープによって定義されたスコープ選択タグが、すべてのクライアントクラスにあることを保証します。

Ensure Scope for Subnet Rule

スコープがどのサブネットにも存在することを保証します。

Ensure Subnets for Scopes Rule

サブネットがどのスコープにも存在することを保証します。

IP Range Consistency Rule

重複するスタティック アドレス範囲またはダイナミック アドレス範囲を識別します。

Owner Match Rule

ルータ上の各サブネットがサブインターフェイスと同じ所有者を持つことを保証します。

Router Subnets in Database Rule

ルータ上の各サブネットはリージョナル データベースに対応するサブネットがあることを保証します。

Selection Tags Consistency Rule

スコープ上のスコープ選択タグがアドレス タイプに定義されたタグの 1 つと一致することを保証します。

Subnet Consistency Rule

重複するサブネットを識別します。

Utilization Collection Rule

DHCP サーバの収集間隔がリージョナル サーバの収集間隔よりも大きいことを保証します。

 

表7-8 ローカル クラスタにおけるデータ整合性ルールの設定

ローカルの整合性ルール
説明

Broadcast Address Rule

スコープのダイナミック アドレス範囲にブロードキャスト アドレスが含まれないことを保証します。

CNAME RR and Host Alias Consistency Rule

CNAME レコードとホスト エイリアス名に一貫性があることを保証します。

Client-Class Selection Match Tag Rule

スコープによって定義されたスコープ選択タグが、すべてのクライアントクラスにあることを保証します。

Failover Pair Consistency Rule

CCM サーバと DHCP サーバが、同じバージョンの DHCP フェールオーバー ペア オブジェクトを持っていることを保証します。

IP Range Consistency Rule

重複するスタティック アドレス範囲またはダイナミック アドレス範囲を識別します。

Lame Delegation Rule

管理対象サブゾーンに不完全な委任がないことを保証します。

Missing Hosts Consistency Rule

PTR レコードに対して欠落しているホストを特定します。

Missing PTR Records Consistency Rule

ホストに対して欠落している PTR レコードを特定します。

Owner Match Rule

ルータ上の各サブネットがサブインターフェイスと同じ所有者を持つことを保証します。

Router Subnets in Database Rule

ルータ上の各サブネットはリージョナル データベースに対応するサブネットがあることを保証します。

Subnet Consistency Rule

重複するサブネットを識別します。

Zone Reference Rule

ゾーンから参照されるアップデート ポリシー、アクセス コントロール リスト(ACL)、暗号キー オブジェクトの解決可能性を保証します。

ローカル Basic または Advanced およびリージョナル Web UI


ステップ 1 Home をクリックしてから Consistency Rules をクリックし、List Consistency Rules ページを開きます(ローカル クラスタ用のページについては図7-8を参照)。

ステップ 2 リストに表示された整合性ルールのうち、適用する各ルールのチェックボックスをオンにします( 表7-7 および 表7-8 を参照)。

ステップ 3 Run Rules をクリックします。この操作により、Consistency Rules Result ページが表示されます。CCM サーバが違反を発見すると、各ルールに対する違反がページに一覧表示されます。

ステップ 4 違反の原因となったネットワーク オブジェクトを表示するには、その違反の下の Detailed Objects の横のプラス記号( + )をクリックします。オブジェクト クラス名、オブジェクト ID、シーケンス番号、不整合により影響を受ける値が表示されます。

ステップ 5 Return をクリックして、List Consistency Rules ページに戻ります。


 

図7-8 List Consistency Rules ページ(ローカル Basic)

 

サーバのトラブルシューティング

ここでは、設定のトラブルシューティングおよび、DNS、DHCP、TFTP サーバのトラブルシューティングについて説明します。

迅速なトラブルシューティング処置

問題に直面したときは、最初の問題を分離し修正している間にさらに悪影響が生じないようにすることが重要です。特に次の点に注意してください。

メモリを 512 MB、データ パーティションを 2.5 GB 以上にする。

ケーブル モデム ターミネーション システム(CMTS)をリブートしない。

DHCP フェールオーバーをイネーブルにする。

Network Registrar のフェールオーバー再同期中に、リロード、再起動、または中断を行わない。

cnr.conf ファイルの修正

Network Registrar では、 cnr.conf ファイルにある基本設定パラメータを使用します。通常、このファイルは、 install-path /conf ディレクトリにあります。Network Registrar は、インストール時にこのファイルを作成し、1 行ずつ処理します。

このファイルを編集して、設定パラメータを変更できます。動作が正常な場合は、特に影響の大きい MCD キーなどの値を変更しないことを推奨します。しかし、状況によっては、一部の値の変更が必要になることがあります。たとえば、ディスク容量を確保するためにデータ ファイルを移動する場合などです。

cnr.conf ファイルでは、各行にパラメータ名と値のペアが並びます。Windows ローカル クラスタにインストールした場合の例を示します。

cnr.rootdir=C:\\Program Files\\Network Registrar\\Local
cnr.ccm-port=1234
cnr.datadir=C:\\Program Files\\Network Registrar\\Local\\data
cnr.java-home=C:\\Program Files\\Java\\jre1.5.0_12
cnr.logdir=C:\\Program Files\\Network Registrar\\Local\\logs
cnr.https-port=8443
cnr.tempdir=C:\\Program Files\\Network Registrar\\Local\\temp
cnr.http-port=8080
cnr.ccm-mode=local
cnr.mcdpath=ccmsrv
cnr.backup-time=23:45
cnr.mcd-key=01A58EE87DD4EE78368805FD366F8505446FAD449D6C7A
 

ディレクトリ パスは、オペレーティング システムのネイティブ シンタックスで記述する必要があります。コロン(:)は、ディレクトリ パスに使用できますが、名前と値の間の区切り文字には使用できません。継続行と Unicode 文字の埋め込みはできません。ログ ディレクトリの場所が変更された場合(「ログ ファイル」を参照)や、 mcdshadow バックアップが発生した場合(「シャドウ バックアップ時刻の設定」を参照)も、このファイルを修正します。

サーバ障害のトラブルシューティング

サーバ エージェント プロセス(nwreglocal と nwregregion)は、通常、サーバ障害を検出してそのサーバを再起動します。通常は障害から回復し、再起動後すぐにサーバに障害が再度発生する可能性は低くなります。まれに、サーバ障害を生じさせた原因によってサーバが正常に再起動できないために、サーバを再起動するとすぐに再度障害が発生することがあります。この場合は、次の手順に従います。


ステップ 1 サーバの再起動に非常に長い時間がかかる場合は、サーバ エージェントを停止して再起動します。各オペレーティング システムごとに示します。

Windows

net stop nwreglocal or nwregregion
net start nwreglocal or nwregregion
 

Solaris

/etc/init.d/nwreglocal stop or nwregregion stop
/etc/init.d/nwreglocal stop or nwregregion start
 

Linux

/etc/rc.d/init.d/nwreglocal stop or nwregregion stop
/etc/rc.d/init.d/nwreglocal stop or nwregregion start
 

ステップ 2 すべてのログ ファイルのコピーを保存します。ログ ファイルは、Solaris および Linux では install-path /logs ディレクトリに、Windows では install-path \logs フォルダに保存されます。これらのログ ファイルには、有用な情報が含まれていることが多く、サーバ障害の原因を特定するのに役立つことがあります。

ステップ 3 オペレーティング システムに応じて、「TAC ツールの使用」で説明されている TAC ツールを使用するか、コア ファイルまたは user.dmp ファイルが存在する場合はそれを保存します。

Windows :user.dmp ファイルがシステム ディレクトリにあります。このディレクトリは、Windows システムによって異なります。このファイルを検索して、名前を変更したコピーを保存します。

Solaris および Linux :コア ファイルが install-path にあります。このファイルの名前を変更したコピーを保存し、Network Registrar が上書きしないようにします。

ステップ 4 Windows で、ネイティブ イベント ロギング アプリケーションを使用して、System と Application のイベント ログをファイルに保存します。これは、Event Viewer から実行できます。これらのイベント ログには、通常、Network Registrar サーバの問題のデバッグに役立つデータが含まれています。各サーバ モジュールのログ メッセージについては、 install-path /docs/msgid/MessageIdIndex.html ファイルを参照してください。


 

TFTP サーバのトラブルシューティングと最適化

特定のアトリビュートを設定して、TFTP サーバのパフォーマンスのトラブルシューティングと最適化ができます。

TFTP サーバ アクティビティのトレース

TFTP サーバのアクティビティをトレースするには、 packet-trace-level アトリビュートを 1 ~ 4 の値に設定します。値は、TFTP サーバがメッセージをトレース ファイルに書き込む量に応じて選択します。トレース ファイルは、インストール ディレクトリの /logs サブディレクトリにあります。Windows のトレースは file_tftp_1_log ファイルに、Solaris と Linux のトレースは /var/nwreg2/local | regional/logs/file_tftp_1_log および file_tftp_1_trace ファイルに保存されます。

トレース レベルは次のとおりです。それぞれのレベルはそれより低いレベルの機能をすべて含みます。

0 :サーバ トレースをすべてディセーブルにします(デフォルト)。

1 :トレース ファイルのログ メッセージをすべて表示します。

2 :すべてのパケットについて、クライアントの IP アドレスとポート番号を表示します。

3 :パケット ヘッダー情報を表示します。

4 :パケットの最初の 32 バイトを表示します。


) トレース レベルの設定と取得は、TFTP サーバが起動している場合のみ機能します。パフォーマンスに影響するため、パケット トレースをオンにするのはデバッグの必要がある場合に限り、長時間の使用は避けてください。


TFTP メッセージのロギングの最適化

TFTP サーバのパフォーマンスは、ロギングとトレースを制約することにより向上する可能性があります。デフォルトでは、サーバはエラー、警告、および情報メッセージを file_tftp_1_log ファイルにロギングします。ログ レベルは、いくつかの TFTP サーバ パラメータを使用して設定できます。

ログ レベル log-level アトリビュートを使用):サーバ ロギングを制御する基本となるものです。レベル 3(すべてのエラー、警告、および情報メッセージのロギング)にプリセットされ、プリセットの状態が最適です。パケット トレースと同様、それぞれのロギング レベルはそれより下のロギング レベルの機能をすべて含みます。0 に設定すると、サーバのロギングは実行されません。

ログ設定 log-settings アトリビュートを使用):2 番目のレベルのロギング制御で、 default または no-success-messages の 2 つの値にだけ設定されます。 default ログ設定は、デフォルト値のログ レベル 3(エラー、警告、および情報メッセージ)を変更しません。ただし、正常な情報メッセージの書き込みをディセーブルにすれば、サーバのパフォーマンスを向上させることができます。これには、ログ設定を no-success-messages に変更します。

ログ ファイルの数とサイズ log-file-count アトリビュートを使用):保持するログ ファイルの数と /logs ディレクトリで許容するファイル サイズを設定します。デフォルト値では、それぞれ 1 MB のファイルを最高 4 つ保持できます。


) この値の変更後は、TFTP サーバをリロードしてください。


TFTP ファイル キャッシュのイネーブル化

TFTP サーバのパフォーマンスは、サーバでファイル キャッシュをイネーブルにすることにより大幅に向上する可能性があります。ファイル キャッシュはディセーブルにプリセットされているため、明示的にイネーブルにする必要があります。また、ファイル キャッシュ ディレクトリを作成してポイントする必要があります。このディレクトリの最大サイズを設定することができます。手順は次のとおりです。


ステップ 1 TFTP キャッシュ ファイルの送り先を決定します。これは、TFTP ホーム ディレクトリのサブディレクトリとなります。TFTP ホーム ディレクトリは install-path /data/tftp(Solaris および Linux では /var/nwreg2/{local | regional}/data/tftp)にプリセットされています。場所を変更する場合は、 home-directory アトリビュートを設定します。

ステップ 2 TFTP ホーム ディレクトリに移動し、ホーム ディレクトリで mkdir Cachedir コマンドを使用して、たとえば CacheDir という名前でキャッシュ ディレクトリを作成します。Network Registrar は、このキャッシュ ディレクトリのサブディレクトリにあるファイルをすべて無視します。

ステップ 3 file-cache-directory アトリビュートを使用して、TFTP サーバがキャッシュ ディレクトリをポイントするようにセットアップします。ディレクトリ名には、.../cachedir のような相対パスは使用できません。ディレクトリが存在しない場合は、ファイル キャッシュが実行されません。

ステップ 4 file-cache-max-memory-size アトリビュートを使用して、キャッシュの最大メモリ サイズをバイト単位で設定します。プリセット値は 32 KB です。Network Registrar は、ファイル サイズの合計がこのメモリ サイズに達するまで、すべてのファイルをキャッシュにロードします。この値を 0 に設定すると、ファイル キャッシュをイネーブルにしても Network Registrar はデータをキャッシュしません。

ステップ 5 キャッシュするファイルはすべてキャッシュ ディレクトリにコピーします。サブディレクトリにはコピーしないでください。このディレクトリにあるすべてのファイルがキャッシュにロードされるので、大きなファイルは除いてください。

ステップ 6 file-cache アトリビュートをイネーブルにしてファイル キャッシュをイネーブルにします。次に、サーバをリロードします。Network Registrar は、各キャッシュ ファイルの名前をロギングし、ロードできない名前があればスキップします。すべてのファイルはバイナリ データとして読み取られ、TFTP クライアント要求に変換されます。たとえば、クライアントがファイルを NetASCII で要求した場合、クライアントはキャッシュされたデータを NetASCII 形式で受け取ります。

ステップ 7 キャッシュへの書き込みはできません。キャッシュファイルを更新する必要がある場合は、キャッシュ ディレクトリで上書きしてから、サーバをリロードします。


 

Solaris と Linux のトラブルシューティング ツール

Solaris システムと Linux システムでは、次のコマンドを使用して、Network Registrar のトラブルシューティングを行うことができます。次のコマンドを実行します。

すべての Network Registrar プロセスを表示する。

ps -leaf | grep nwr
 

システムの使用状況とパフォーマンスを監視する。

top
vmstat
 

ログイン エラーまたはブートアップ エラーを表示する。

Solaris: grep /var/adm/messages*

Linux: grep /var/log/messages*

構成済みのインターフェイスおよびその他のネットワーク データを表示する。

ifconfig -a
 

TAC ツールの使用

トラブルシューティング手順を何度も実行しても問題が解決せず、最終的な手段として Cisco Technical Assistance Center(TAC)に援助を要請することが必要になる場合があります。Network Registrar には、サーバやシステムの情報を簡単に収集し、TAC のサポート エンジニア向けにデータをパッケージするためのツールがあります。これを使用することで、この情報を TAC の指示に従って手動で収集する手間が省けます。このツールを使って作成されるパッケージは、十分なデータをエンジニアに提供するため、エンジニアは問題をより迅速で容易に診断し、解決策を提供できます。

cnr_tactool ユーティリティは、Windows の bin ディレクトリ、および UNIX または Linux のインストール ディレクトリの usrbin ディレクトリで使用できます。 cnr_tactool ユーティリティを実行します。

> cnr_tactool -N username -P password [-d output-directory]
 

出力ディレクトリはオプションです。通常はインストール ディレクトリの temp ディレクトリです(Solaris および Linux では /var パス内にあります)。コマンドラインでユーザ名とパスワードを指定しない場合は、入力を求めるプロンプトが表示されます。

> cnr_tactool
username:
password:
[processing messages....]
 

ツールはパッケージされた tar ファイルを生成し、ファイル名に日付とバージョンが含まれます。tar ファイルには、診断ファイルがすべて含まれます。