MVP に聞く！MOM 管理パックを活用したサーバ管理 実践

トピック

	DNS 管理パックのロード
	管理パックによる DNS Server の認識
	DNS 管理パックの醍醐味、パフォーマンス監視
	DNS 管理パックで取得できるパフォーマンス値の解説
	DNS Server の動作確認
	まとめ

DNS 管理パックのロード

DNS 管理パックを使用するには、管理パックのロードが必要です。
「Microsoft Windows DNS Server 管理パック」 をロードしてください。
管理パックのロード方法については、こちらをご覧ください。
http://www.microsoft.com/japan/mom/community/vol1/page4.mspx

ページのトップへ

管理パックによる DNS Server の認識

DNS 管理パックでは、DNS Server を以下の二種類に分類して管理しています。

この二つの違いは以下の通りです。
Windows 2000 の DNS Server を使用している場合、DNS 用 WMI プロバイダがインストールされているかを監視します。
Windows Server 2003 の DNS Server を使用している場合、Windows 2000 の DNS サーバーが持つ監視項目に加えて、NETSH コマンドを使用した DNS サーバーの列挙や生存確認が可能です。

Windows 2000 の DNS を DNS WMI プロバイダ抜きで監視させることはあまり望ましくありません。
これは、DNS 管理パックでは WMI スクリプトによる DNS サーバーの監視を行う機能が提供されているためです。
そのため、もし上記環境で DNS 管理パックを使用する場合、是非 DNS WMI プロバイダをインストールしてください。
DNS WMI プロバイダは Windows 2000 Server リソースキットで提供されています。
なお、Windows Server 2003 には DNS WMI プロバイダが標準で含まれています。

DNS Server は次のルールで認識されています。

(図1) Windows Server 2003 の場合の DNS Server 判別式

この式によれば、以下の条件に当てはまる場合、コンピュータ グループへの分類がされます。

ここからは、MSCS 上の DNS Server も、正しく監視が可能なことが伺えます。

なお、Microsoft DNS Server フラグは、次のレジストリ値の有無によって判断されます。

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DNS\Start

このレジストリ値は DNS サービスのスタートアップの状態を示しますので、DNS Server がインストールされているならば、このレジストリ値が存在することになります。

このルールは管理コンソールの次の画面に定義されています。

(図2) Microsoft DNS Server フラグ

正常に認識しない場合など、「含めるコンピュータ」 や 「除外するコンピュータ」 にコンピュータ名を追加することで、強制的に設定が可能です。
必要に応じて、設定すると良いでしょう。

ページのトップへ

DNS 管理パックの醍醐味、パフォーマンス監視

DNS 管理パックでは、パフォーマンス カウンタによる様々なパフォーマンス計測が可能です。すべてのカウンタは 15 分おきに取得され、オペレータ コンソールのパフォーマンス ビューから確認できます。

(図 3) パフォーマンス ビュー

一般的なパフォーマンスの表示方法にはなりますが、実際にグラフを表示してみたいと思います。

まず、過去のデータを表示させるため、新しい表示画面を作成します。
画面左側ペイン上部、「パフォーマンスの表示」 欄を右クリックし、プルダウン メニューから 「新規」 - 「パフォーマンス データの表示」 を選択します。
すると以下の画面が表示されます。

(図 4)

「指定された条件を満たすパフォーマンス データ」 を選択し、次の画面へすすみます。パフォーマンス データの範囲を指定する詳細の画面が表示されますので、条件を入力します。

(図5)

ここでは、過去のデータを参照したいので、「次の期間に測定された: 値」 項目を選択し、下側に表示された 「値」 のリンクをたどります。
その後、表示されるダイアログから、参照したい期限を入力していきます。
あらかじめ参照したい DNS サーバーのコンピュータ名などを入力すると便利でしょう。
その後、表示名や説明を入力します。
すると、次のようなビューが得られます。

(図 6)

グラフとして表示したい値を選択し、上部にある 「グラフの表示」 ボタンを選択してみましょう。これで、表示したいグラフが表示されます。

以下のグラフは、過去 7 日間の Total Query Received/sec を追跡したものです。

(図 7)

続いて、Total Response Sent./sec です。

(図 8)

このように、過去のパフォーマンスを様々な角度で照らし合わせながら確認できます。
サンプルの二つは本来合致しなくてはならない値ですが、見事に合致していることが確認できます。

これらの値を観測し、通常どの程度で動作しているか確認し、その値に従ったパフォーマンスのしきい値を設定しておくと良いでしょう。
しきい値の設定方法については、次の URL を参照してください。http://www.microsoft.com/japan/mom/community/vol8/page4.mspx

ページのトップへ

DNS 管理パックで取得できるパフォーマンス値の解説

ここでは先ほど説明しましたパフォーマンス値を順に説明していきたいと思います。

サイジングに役立つカウンタ

これらの値は将来のシステム増強に役立てることができます。
また、パフォーマンスが低下した際の原因追求にも便利でしょう。

Caching Memory

DNS サーバー サービスがキャッシュ用に使用しているシステム メモリの総容量です。
通常は 0 となり、あまり増大する値ではないようです。
異常な増加が見られる場合は、CPU などにボトルネックがあると予想できるでしょう。

Database Node Memory

DNS サーバー サービスがデータベース ノード用に使用しているシステム メモリの総容量です。
データベース ノードとは名前が示すとおり、DNS データベースのことです。
名前解決のためのキャッシュをローカルに多く保持している場合、より多くの容量を消費します。
無登録状態で 10,000 程度を示し、DNS 参照が発生すればするほど増大していきます。
1,000,000 程度の値は通常の値だといえるでしょう。
DNS サーバーのデータベース容量の増加に従い数値も増加しますので、ここからメモリ サイジングが行えます。

Total Query Received/sec
Total Response Sent/sec

それぞれ DNS サーバーが受信したクエリの数の 1 秒間あたりの平均値、DNS サーバーが送信した応答の数の 1 秒間あたりの平均値になります。
DNS は許可されたクエリに対して必ず応答があるべきです。
そのため、この値に変化がある場合は、処理できないクエリがある場合と、パフォーマンス不足の 2 種類の原因が考えられます。
全体的に両方の値が大きく、かつサンプリング ポイントにおいて双方の値に差異がある場合、CPU などにボトルネックがあると予想できるでしょう。

WINS Lookup Received/sec
WINS Response Sent/sec
WINS Reverse Lookup Received/sec
WINS Reverse Response Sent/sec

それぞれ、サーバーが 1 秒間に受信した WINS 参照要求、送信した要求、受信した WINS 逆引き参照要求、送信した要求の平均になります。
WINS 正引き、逆引きを指定している DNS サーバーでこの値を確認する必要が出るでしょう。送受信の値は等しくあるべきです。
値に違いが出ている場合でかつ値が大きい場合は、CPU などにボトルネックがあるでしょう。

セキュリティの維持に役立つカウンタ

セキュリティの維持に直接関係するカウンタです。
異常が見込まれた際は緊急であることが予想されますので、しっかり監視したい値でしょう。

Secure Update Failure

DNS サーバーで失敗した、セキュリティで保護された動的更新の総数です。この値は 0 である必要があります。
増大する場合は、ネットワークに許可されないコンピュータが存在していたり、攻撃を受けている可能性があります。
値は初期化されず蓄積されていきます。
突然の増大が発生した場合は注視する必要があるでしょう。

Dynamic Update Queued
Dynamic Update Received/sec
Dynamic Update Written to Database/sec

それぞれ、DNS サーバーがキューに登録した動的更新の総数、DNS サーバーが受信した動的更新要求の数の 1 秒間あたりの平均値、DNS サーバーがデータベースに書き込んだ動的更新の数の 1 秒間あたりの平均値になります。
Active Directory 環境であれば、ネットワークに変更が発生する場合や、DHCP のリース アドレス数が不足している場合に増大することが見込まれます。
管理者にて把握できない値の増加があった場合、Active Directory 環境、特にドメイン コントローラなどに不具合が発生していることが考えられます。
当然、原因究明が必要でしょう。

その他のカウンタ

Recursive Queries/sec
Recursive Query Failure/sec
Recursive TimeOut/sec

それぞれ、DNS サーバーが受信した再帰クエリの数、失敗した再帰クエリの数、再帰クエリ送信のタイムアウトの数の 1 秒間あたりの平均値になります。
再帰クエリとは、クライアントが DNS サーバーへ名前解決の問い合わせを行うためのクエリです。
この値の増大はそのまま DNS クライアントの増大に直結します。

Zone Transfer Failure
Zone Transfer Success

それぞれ、マスタ DNS サーバーで失敗したゾーン転送の総数、マスタ DNS サーバーが正常に送信したゾーン転送の総数になります。
ゾーン転送とは、マスタ サーバーからスレーブ サーバーへのデータ転送の操作になります。
値はサービスが起動してから現在までの総数になります。
Active Directory 統合ゾーンにて構成された環境では、ゾーンの転送は発生しません。
この操作は主にスタンドアロンで構成されたゾーンに対して発生します。

TCP/UDP カウンタ

TCP Message Memory
UDP Message Memory
TCP Query Received/Sec

それぞれ、TCP/UDP メッセージ メモリの使用量、DNS サーバーが受信した TCP クエリの数の 1 秒間あたりの平均値を示します。
筆者の検証環境においては、おおよそ TCP Message Memory が 10,000,000〜2,000,000,000 となり、残りの値は常に 0 となっています。
このカウンタはやはり、環境によってかなりばらつきがあるようです。

ページのトップへ

DNS Server の動作確認

最後になりますが、DNS 管理パックには、DNS Server が動作しているかどうかを管理することもできます。
この機能はイベント ログの監視機能によって提供されています。
DNS サーバー イベント ログの監視が主になります。
代表的なところでは、315x、400x 台の Active Directory に関するイベント ID、652x、653x 台のゾーン転送に関するイベント ID の監視や、サービスの状態などを確認しています。
サービスの動作が確認できない状態に状態が変化した場合、「サービスは利用できません」のアラートが表示されます。
運用していく上でこのような状態は滅多に発生いたしませんが、そのような状態変化があった場合は、最適なトラブルシュートを迅速に進めていきたいものです。

ページのトップへ

まとめ

DNS 管理パックについて簡単に解説していきましたが、理解は深まりましたでしょうか?
この章では大部分をパフォーマンス監視に割り当てましたが、実際 DNS Server の監視にパフォーマンス監視は必須です。
なぜならこのサービスは常にユーザーに利用され続け、刻々とその状態が変化していく性質のものだからです。
そのため利用状況の把握は必須といえるでしょう。

最後になりますが、この章が皆様の DNS Server 運用の糧になりましたら幸いです。

Windows 運用管理においてのノウハウを、主に雑誌原稿などの媒体を使用し、ユーザーへフィードバックしている。「誰もがほしがるような情報を提供すること」をモットーに、独自の技術サイト (http://www.admintech.jp) も運用している。 Microsoft MVP Windows Server - Management Infrastracture

ページのトップへ

2 of 6