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

目次

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

サーバの制御

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

ログの検索

ロギングの形式と設定

ログ ファイル

変更ログとタスク

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

サーバの状態

安定度の表示

統計の表示

DNS の統計

DHCP の統計

TFTP の統計

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

関連サーバの表示

DNS ゾーン分散サーバ

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

リースの表示

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

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

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

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

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

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

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

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

TAC ツールの使用

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

この章では、Cisco CNS Network Registrar の Web UI と CLI( nrcmd プログラム)を使用してローカル サーバとリージョナル サーバのオペレーションを管理および制御する方法について説明します。

サーバの制御

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

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

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

リロード:サーバを停止して再起動します。

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

Web UI では、プロトコル サーバを次の 2 種類の方法で管理できます。

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

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

 

ローカル クラスタとリージョナル クラスタでは、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 ページを開きます(図6-2 を参照)。

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

 

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

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

 

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

キャッシュのフラッシュ(「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 ページを開きます。このページは、Manage DNS Server ページに類似しています(図6-2 を参照)。

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

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

 

このページは、共通の制限 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 の場合(リージョナル クラスタでは 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
 

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


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

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 からイベントをクリアします。


ログの検索

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

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

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

 

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

ロギングの形式と設定

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

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

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

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

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

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

DNS: DNS をクリックしてから DNS Server をクリックし、Manage DNS Server ページを開きます。サーバの名前をクリックして、Edit DNS Server ページを開きます。Logging attributes セクションを展開し、ログの設定を表示します。必要に応じてこれらの設定に変更を加え、 Modify Server をクリックしてから、サーバをリロードします。

DHCP: DHCP をクリックしてから DHCP Server をクリックし、Manage DHCP Server ページを開きます。サーバの名前をクリックして、Edit DHCP Server ページを開きます。Logging セクションを展開し、ログの設定を表示します。必要に応じてこれらの設定に変更を加え、 Modify Server をクリックしてから、サーバをリロードします。

CLI では、各サーバに対してそれぞれ dns set log-settings dhcp set log-settings tftp set log-settings コマンドを使用します。


警告およびエラーは、Solaris の Syslog または Windows の Event Viewer に送られます。P.6-4の 注意を参照してください。各サーバ モジュールのログ メッセージについては、
install-path
/docs/msgid/MessageIdIndex.html ファイルを参照してください。


ログ ファイル

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

 

表6-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 つです。

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


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


変更ログとタスク

Web UI では、実行した設定の変更ログとタスクを表示できます。 Administration Change Log の順にクリックしてから、 CCM Tasks または MCD Tasks をクリックします。変更ログとタスクを表示するには、ccm-admin ロールまたは regional-admin ロールの database サブロールを割り当てられている必要があります。View Change Log ページ(図6-6 を参照)に、すべての変更ログが最新のものから順に表示されます。変更ログ エントリの DBSN 番号をクリックすると、そのエントリの View Change Set ページが開きます。

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

 

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

開始日または終了日

変更を開始した管理者

設定オブジェクト クラス、またはそのクラスの特定オブジェクト

サーバ(DNS、DHCP、TFTP、CCM、サーバ エージェント、RIC、または SNMP)

Filter List または Cancel 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 サーバ(リージョナル クラスタ):


ヒント 安定度の値が低下している場合は、そのサーバのログ ファイルを確認してください。


ローカルとリージョナルの両クラスタの Web UI で、 Administration をクリックしてから Servers をクリックします。Manage Servers ページで、各サーバの状態と安定度を確認します(DHCP サーバの例については、図6-1 を参照してください)。

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


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


統計の表示

サーバの統計を表示するには、サーバが動作している必要があります。ローカル クラスタの Web UI で、Manage Servers ページへ移動し、Statistics カラムの Statistics アイコン( )をクリックします。Server Statistics ページで、ポップアップ ヘルプを表示するには、アトリビュートの名前をクリックします。

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

 

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

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

DHCP

Web UI

Total Statistics

Activity Summary

 

CLI

Total Counters since( dhcp getStats

Sampled counters at
dhcp getStats sample

DNS

Web UI

Total Statistics

Sample Statistics

 

CLI

Total Counters since( dns getStats

Sampled counters at
dns getStats sample

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

nrcmd> dhcp enable collect-sample-counters
 

または

nrcmd> dhcp set log-settings=activity-summary
 

その後

nrcmd> dhcp set activity-summary-interval
 

) サーバの初期間隔カウンタ値を照会できるよう、collect-sample-counters をイネーブルにする必要があります。


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

カウンタをリセットするには、 dhcp resetStats を使用します。次の例を参考にしてください。

nrcmd> dhcp resetStats
 

DNS の統計

DNS サーバの統計を 表6-3 に示します。この表は、統計のカテゴリ、名前、説明と、次に示す形式の汎用の dns getStats コマンドの出力における統計の桁位置によって編成されています。

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

 

表6-3 DNS の統計

統計
説明

一般

 

 

Server Identifier(id)

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

{1}

Recursive Service(config-recurs)

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

2

Process Uptime(config-up-time)

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

3

Time Since Reset(config-reset-time)

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

4

Server Status(config-reset)

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

5

Authoritative Answers
(counter-auth-ans)

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

6

Authoritative No Such Name Answers(counter-auth-no-names)

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

7

Authoritative No Such Data Answers(counter-auth-no-data-resps)

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

8

Nonauthoritative Answers(counter-non-auth-datas)

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

9

Nonauthoritative No Such Data Answers(counter-non-auth-no-datas)

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

10

Forwarded Queries(counter-referrals)

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

11

Error Responses(counter-errors)

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

12

Single Label Name Queries(counter-rel-names)

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

13

Requests Refused(counter-req-refusals)

拒否されたクエリーの数

14

Unparseable Requests(counter-req-unparses)

解析不可能な要求の数。

15

Requests with Other Errors(counter-other-errors)

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

16

パフォーマンス

 

 

updated-rrs

エラーにもかかわらず、追加および削除されたリソース レコードの数(更新も含む)。

update-packets

処理された更新パケットの数。

ixfrs-out

正常に実行された発信差分ゾーン転送(IXFR)の数。

ixfrs-in

受信 IXFR の数(結果として完全ゾーン転送になったものを含む)。

ixfrs-full-resp

IXFR 要求への応答として行われた発信完全ゾーン転送(AXFR)の数。

axfrs-out

正常に実行された発信 AXFR の数(ixfrs-full-resp にカウントされたものを含む)。

axfrs-in

正常に実行された受信 AXFR の数。

queries

応答が行われたクエリーの数(更新を除く)。

xfrs-out-at-limit

発信転送が同時限度数に到達した回数。

xfrs-in-at-limit

受信転送が同時限度数に到達した回数。

notifies-out

発信通知パケットの数。

notifies-in

受信通知パケットの数。

クエリー

 

 

auth-answers

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

auth-no-names

authoritative no such name 」という回答が発生したクエリーの数。

auth-no-data-responses

authoritative no such name 」という応答が発生したクエリーの数。

nonauth-answers

信頼できない回答が(キャッシュから)行われたクエリーの数。

nonauth-no-data-responses

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

referrals

他のサーバの参照が行われた要求の数。

relative-name-requests

1 ラベル長の名前について受信された要求の数。

refusals

拒否されたクエリーの数。

lame-delegations

結果として不完全な委任となったクエリーの数(「不完全な委任のレポート」を参照)。

mem-cache-hits

メモリ キャッシュのルックアップのヒット数。

mem-cache-misses

メモリ キャッシュのルックアップのミス数。

mem-cache-writes

メモリ キャッシュ書き込みの数。

セキュリティ

 

 

rcvd-tsig-packets

処理された TSIG RR の数(「トランザクション セキュリティ」を参照)。

detected-tsig-bad-time

TSIG タイム スタンプが不良だった着信パケットの数。

detected-tsig-bad-key

TSIG キーが無効であるか不明だった着信パケットの数。

detected-tsig-bad-sig

TSIG シグニチャが不良だった着信パケットの数。

rcvd-tsig-bad-time

TSIG を送信後の BADTIME エラーの数。

rcvd-tsig-bad-key

TSIG を送信後の BADKEY エラーの数。

rcvd-tsig-bad-sig

TSIG を送信後の BADSIG エラーの数。

unauth-xfer-reqs

ゾーン転送制約をイネーブルにした状態での、ACL 許可の失敗の数。

unauth-update-reqs

結果として ACL 許可の失敗になった更新の数、または更新をサポートしていないそのようなターゲット ゾーンの数。

エラー

 

 

update-errors

結果としてエラーまたは失敗になった更新の数。前提条件のチェックに対する否定的な応答も含まれますが、TSIG 応答は除外されます。

ixfr-in-errors

受信 IXFR エラーの数。ただし、パケット形式のエラーは除外されます。

ixfr-out-errors

発信 IXFR エラーの数。ただし、パケット形式のエラーは除外されます。

axfr-in-errors

受信 AXFR エラーの数。ただし、パケット形式のエラーは除外されます。

axfr-out-errors

発信 AXFR エラーの数。ただし、パケット形式のエラーは除外されます。

sent-total-errors

エラー(RCODE 値が 0、3、6、7、8 のいずれでもない)で回答した要求の数。

sent-format-errors

受信された解析不可能な要求の数。

sent-other-errors

他のローカル サーバ エラーのために打ち切られた要求の数。

sent-refusal-errors

結果が REFUSED 応答だった要求の数。

rcvd-format-errors

FORMERR ステータスで受信された応答の数。

最大値カウンタ

 

 

concurrent-xfrs-in

前回のサンプリング期間中、受信転送を処理した同時スレッドの最大数。

concurrent-xfrs-out

前回のサンプリング期間中、発信転送を処理した同時スレッドの最大数。

DHCP の統計

DHCP サーバの統計を、 表6-4 に示します。この表は、統計のカテゴリ、名前、説明と、次に示す形式の汎用 dhcp getStats コマンドの出力における統計の桁位置によって編成されています。

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

 

表6-4 DHCP の統計

統計
説明

一般

 

 

start-time-str

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

{1}

total-discovers

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

2

total-requests

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

3

total-releases

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

4

total-offers

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

5

total-acks

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

6

total-naks

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

7

total-declines

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

8

サーバ

 

 

acks

時間間隔内に送信された DHCPACK パケットの数。

acks-per-second

クライアントへ DHCPACK パケットが送信された平均比率。

 

declines

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

 

discovers

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

 

naks

送信された DHCPNAK パケットの数

 

offers

送信された DHCPOFFER パケットの数

 

packets-dropped

ドロップされた着信パケットの数。

 

releases

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

 

request-buffers-in-use

統計計算時の要求バッファの数。

requests

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

 

response-buffers-in-use

統計計算時の応答バッファの数。

timeouts

時間間隔中のタイムアウト(リース、提供)の数。

 

フェールオーバー

 

 

binding-acks-received

時間間隔中に受信されたフェールオーバー DHCPBNDACK パケットの数。

binding-acks-sent

時間間隔中に送信されたフェールオーバー DHCPBNDACK パケットの数。

binding-naks-received

時間間隔中に受信されたフェールオーバー DHCPBNDNAK パケットの数。

binding-naks-sent

時間間隔中に送信されたフェールオーバー DHCPBNDNAK パケットの数。

binding-updates-received

時間間隔中に受信されたフェールオーバー DHCPBNDUPD パケットの数。

binding-updates-sent

時間間隔中に送信されたフェールオーバー DHCPBNDUPD パケットの数。

packets-dropped

ドロップされたフェールオーバー パケットの数。

 

packets-received

受信されたフェールオーバー パケットの数。

 

packets-sent

送信されたフェールオーバー パケットの数。

 

polls-received

受信されたフェールオーバー DHCPPOLL パケットの数。

 

polls-sent

送信されたフェールオーバー DHCPPOLL パケットの数。

 

pool-requests-received

時間間隔中に受信されたフェールオーバー DHCPPOOLREQ パケットの数。

pool-requests-sent

時間間隔中に送信されたフェールオーバー DHCPPOOLREQ パケットの数。

update-done-received

時間間隔中に受信されたフェールオーバー DHCPUPDATEDONE パケットの数。

update-done-sent

時間間隔中に送信されたフェールオーバー DHCPUPDATEDONE パケットの数。

update-requests-received

時間間隔中に受信されたフェールオーバー DHCPUPDATEREQ パケットの数。

update-requests-sent

時間間隔中に送信されたフェールオーバー DHCPUPDATEREQ パケットの数。

TFTP の統計

TFTP サーバの統計を 表6-5 に示します。この表は、統計のカテゴリ、名前、説明と、次に示す形式の汎用 tftp getStats コマンドの出力における統計の桁位置によって編成されています。

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 30 31
 

 

表6-5 TFTP の統計

アトリビュート
説明

id

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

{1}

server-state

サーバの状態。

2

server-start-time

起動日時(秒)。

3

server-reset-time

リセット日時。

4

server-time-since-start

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

5

server-time-since-reset

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

6

total-packets-in-pool

プール内のパケット数。

7

total-packets-in-use

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

8

total-packets-received

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

9

total-packets-sent

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

10

total-packets-drained

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

11

total-packets-dropped

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

12

total-packets-malformed

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

13

total-read-requests

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

14

total-read-requests-completed

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

15

total-read-requests-refused

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

16

total-read-requests-ignored

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

17

total-read-requests-timed-out

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

18

total-write-requests

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

19

total-write-requests-completed

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

20

total-write-requests-refused

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

21

total-write-requests-ignored

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

22

total-write-requests-timed-out

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

23

total-docsis-requests

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

24

total-docsis-requests-completed

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

25

total-docsis-requests-refused

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

26

total-docsis-requests-ignored

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

27

total-docsis-requests-timed-out

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

28

read-requests-per-second

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

29

write-requests-per-second

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

30

docsis-requests-per-second

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

31

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

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

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

CLI では、 report コマンドを使用すると、IP アドレス使用状況レポートを生成できます。設定できる追加オプションについては、『 Network Registrar CLI Reference 』を参照してください。

関連サーバの表示

Network Registrar は、DNS ゾーン分散内または DHCP フェールオーバー構成内のサーバ間の関係を表示します。Web UI では、さまざまなページで Related Servers アイコン( )をクリックすると、関連するサーバのページを表示できます。

DNS ゾーン分散サーバ

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

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

リージョナル クラスタで、 DNS をクリックしてから Zone Distributions をクリックします。List/Add Zone Distributions ページが開きます(図14-8 を参照)。リージョナル クラスタでは、複数のゾーン分散を作成できます。ゾーン分散名をクリックして 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 サーバのフェールオーバー状態。

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

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

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

リースの表示

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

Web UI の場合:

ローカル クラスタで、 DHCP をクリックしてから Scopes をクリックします。List/Add DHCP Scopes ページでスコープ名をクリックして、Edit DHCP Scope ページを開きます。ページの中ほどで、 List Leases をクリックして List DHCP Lease for Scope ページを開きます。

リージョナル クラスタでは、リース履歴を表示できます。 Address Space をクリックしてから、 Lease History をクリックします。クエリー パラメータを設定し、 Query Lease History をクリックします(「リースの照会」を参照)。

CLI では、 lease list を使用して、使用可能なすべてのリースのプロパティを表示します。

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

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

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

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

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

ケーブル モデム終端システム(CMTS)をリブートしない。

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

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

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

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


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

Windows

net stop nwreglocal または nwregregion
net start nwreglocal または nwregregion
 

Solaris

/etc/init.d/nwreglocal stop または nwregregion stop
/etc/init.d/nwreglocal stop または nwregregion start
 

Linux

/etc/rc.d/init.d/nwreglocal stop または nwregregion stop
/etc/rc.d/init.d/nwreglocal stop または 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 サーバには、ログへの詳細出力を作成し、トラブルシューティングに役立つ CLI コマンドが 2 つあります。ただし、これは通常、パフォーマンスに影響します。これらのコマンドは、サーバのパケット トレースをセットアップします。 tftp getTraceLevel コマンドは、現在のトレース レベルを識別します。トレース レベルのデフォルトは 0、つまりトレースなしです。 tftp setTraceLevel コマンドは、パケット トレースの値を 0 ~ 4 に設定します。トレース ファイルは、インストール ディレクトリの /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 ホーム ディレクトリのサブディレクトリとなります。ホーム ディレクトリのデフォルトは 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 ファイルには、診断ファイルがすべて含まれます。