管理者が必要とされる規模のネットワーク・システムには必ずといっていいほどサーバがあり、なんらかのサービスをネットワークに対して提供している。ここにトラブルがあれば、その影響はユーザー全員に及んでしまうが、逆にサービスの品質を向上させることで、会社業務の利便性を向上させることができる。サーバ管理は、ネットワーク管理者の非常に大事な仕事の1つである。
サーバの監視
サーバやそこで使われるソフトウェアは、ほとんどの場合、一度設定してしまえば、あとはそう頻繁に操作する必要はない。しかし常にサーバの状態を監視しておかないと、トラブルの発生や予兆を見逃して、被害を拡大させてしまう恐れがある。管理者は日常的にサーバを監視する必要がある。
また、サーバの設定を変えた直後などにはトラブルが起きやすい。管理者が何らかの変更をサーバに加えた場合には、数日は重点的に監視するようにしておこう。また、設定直後は問題なかったが、システムを再起動したときに、設定変更によるトラブルが発生するということもあるので注意したい。
以下ではWindows NT ServerとLinuxなどのUNIX系OSついて、監視の方法を見てみよう。
(1)Windows NT Serverの場合
Windows NT Server(以下NTと略)の場合は、サーバの監視や管理にはスタートメニューの「管理ツール」にある各種管理コマンドが利用できる。特にサーバ監視用としては、パフォーマンスモニタ(perfmon.exe)やイベントビューア(eventvwr.exe)、サーバマネージャ(svrmgr.exe)などが使われる。こうしたコマンドは、起動時のオプションで
管理コマンド \\マシン名
とすることで、外部のNTマシンから別のサーバをリモートで監視することが可能だ。常時監視する項目としては、管理下のサーバの稼働状態(負荷状態)や、ディスクの残り容量、プリンタおよびプリントキューの状態などが挙げられる(これらのコマンドの具体的な使い方については、ヘルプなどを参照してほしい)。
パフォーマンスモニタ(画面1)を使う場合は、監視する内容に応じて「表示」メニューにある「グラフ」や「警告」、「レポート」などのモードを使い分ける。
 |
|---|
| 画面1 Windows NTマシンの状態を監視するには、パフォーマンスモニタが利用できる。Windows NT Serverのサーバ機をリモートから監視するため、監視側のホストにはWindows NT Workstationを使う必要がある |
「グラフ」は、CPU負荷のように比較的変化の激しく、その形から動作内容が分かりやすいものを表示させ、「警告」ではディスクの残り容量など、緩やかに変化するが一定値を越えたときに警告が必要なもの、「レポート」は数値での表示が適しているものにする。
これらは、監視項目を追加するときに、ホスト名を指定できるので、複数のサーバを指定して、一台のマシンから同時に監視することが可能だ。複数のサーバを監視する場合は、全部のサーバの重要度の高い監視項目を入れたワークスペースと、各サーバごとに必要な監視項目を登録したワークスペースを作るなどして、1つのウィンドウにあまりたくさんの項目を同時に表示させないようにする。やたらとたくさんの項目を監視させるようにしても、なかなか異常には気付きにくいからだ。また警告については、本当に危険なものだけを表示させるようにしておく。あまり重要でない警告が頻繁に発生するような設定では、本当の危険な状態を見逃す可能性がある。
(2)UNIX系OSの場合
LinuxやSolarisなどのUNIX系OSではsyslogの機能やtelnetが管理や監視に使用できる。管理を行なうホストマシン上で、管理対象のサーバへのtelnetウィンドウを表示させておくと、サーバが落ちればエラーが表示されるのですぐに分かる。また、syslogの設定により、各種の警告をtelnetウィンドウ内に表示させることもできる(具体的な方法はmanコマンドで“syslogd”や“syslog.conf”を参照すること)。UNIX系のサーバを監視／管理するマシンとしては、Windowsマシンよりも同じUNIX系OSの方が便利だ。たとえば、manコマンドなども、管理マシン側で参照してtelnetで作業ができる。
なお、UNIX系では、毎日送られてくる管理レポートを日常的に利用するマシンへ送るようにしておいたほうがよい。多くの場合、rootあてのメールとなるが、これを実際の管理者のメールボックスになるようにaliasファイルを変更しておくのである。一般的なAliasファイルには、以下のような部分があるはずで、ほとんどの警告メールもroot宛に送られるようになっている。
# Basic system aliases -- these
MUST be present
MAILER-DAEMON: postmaster
postmaster: root
ここで、以下のようにroot宛のメールが管理者のメールアドレスに届くようにaliasファイルを変更する。
root: 管理者のメールアドレス
aliasファイルを変更した場合は、これをデータベース形式にコンバートして初めて設定が有効になる。このコンバートにはnewaliasesコマンド(システムによって違うので、aliasesをmanコマンドで確認する)などを実行する。
(3)サーバ管理ツールを使う
OpenViewやMicrosoft System Management Serverをはじめとするシステム管理ツールでは、サーバ側にエージェントソフトを動かしておき、別のホストからサーバを監視することで、サーバのクラッシュやディスク容量の不足などをメールやポケベルなどで通知する機能を備えている。こうしたソフトを利用すれば、日々の監視業務を自動化できるうえ、外出先からでもサーバの異常に迅速に対応することが可能になる(画面2、表1)。
| 製品名 | メーカー | 対応OS(管理対象側) | 価格 |
|---|---|---|---|
| BOM for Windows NT Ver.2.0 | コベルコシステムズ | Windows NT 3.51／4.0 | 14万8000円～ |
| e-Care Ver.1.4 | ソリトンシステムズ | Windows 95／98／NT 4.0／2000 Solaris 2.5／2.5.1／2.6 |
40万円～ |
| HP OpenView ManageX 4.21 | 日本ヒューレット・パッカード | Windows NT 4.0／2000 | 49万円～ |
| Microsoft System Management Server 2.0 | マイクロソフト | Windows NT 4.0 | 22万6000円～ |
 |
|---|
| 画面2 表1に挙げているサーバ管理ツールの多くは、サーバの状態監視だけでなく、ネットワーク内の資産管理や全クライアントのリモートインストール、バックアップといった広範囲な管理機能を提供するため、価格も比較的高い。小規模のオフィスでのサーバ監視という点では、Windows NTサーバの状態監視に機能に絞った「BOM for Windows NT」が低価格でお薦めだ |
ディスクの空き容量
サーバのディスクの空き領域が足りなくなると、多くのサービスに影響が出る。このため、ディスクの残り容量を監視するのは当然だが、ログファイルのように随時サイズが増大していくファイルのメンテナンスも忘れないようにしよう。管理するためのログファイルで、ディスクを食いつぶしてトラブルを起こしていたのではどうしようもない。
このほか、テンポラリファイルを定期的に削除したり、ユーザーごとのディスク利用率を集計しておくと、ディスクの効率利用が図れ、トラブルを未然に防ぐことが可能になる。
なおOSによっては、各ユーザーごとに最大利用可能ディスク容量を制限できるものもある。だが、こうした機能を使うと、アプリケーションが作成するテンポラリファイルがこの制限に引っかかってしまい、ユーザー側でアプリケーション・エラーが出たり、誤動作するといった現象が発生することがある。こうした制限を設けるよりも、日常の監視作業から、長期間、大容量のディスクを占有しているユーザーを発見して、削除を依頼するとほうがよいだろう。
また、特定のプログラムやユーザーなどに最低でも一定量の作業ファイルを使わせる場合、パーティションを分ける、あるいは別ドライブ上に領域を確保するなど、ユーザーのディスク利用量の影響を受けないようなハードウェア構成を検討しておいたほうがいいだろう。
トラブルの予兆を掴む
大きなトラブルの予兆を発見するには、ログファイルなどの警告やエラーメッセージをチェックするのが基本だが、そのほかにもログに現われてこない現象、たとえば、コマンドの実行が妙に遅い、印刷に時間がかかるといった現象にも普段から注意したい。
ハードディスクは故障する前に異音が発生することが多い。また、それほど高負荷でもないのにディスクのアクセスランプが点灯し続けたら、ディスク上でエラーが起こっている可能性がある。このような場合は、たとえばバックアップの頻度を上げたり、故障に備えて交換用のディスクを用意しておくなどの準備が必要だろう。
とにかく、「あれっ」と思ったら、すぐに原因究明するようなクセを付けておくと、トラブルの発生による被害を最小限に防ぐことが可能になる。
管理者不在時の緊急の対応
利用者がサーバのトラブルを発見したら、まずは管理者に通報してもらうように日頃から指導しておくことが大切であるが、問題なのは管理者が不在のときだ。管理者が出張している間、あるいは休暇を取っている間にも、いつサーバがトラブルを起こすとも限らない。
まずやっておきたいことは、管理者の不在時にサーバがクラッシュあるいはフリーズしたときに備えて、再起動の手順を文書化しておき、分かりやすい場所に置いておくことだ。何らかのサービス異常が発生したときでも、再起動すると直ってしまうこともよくある。応急処置的な対応ではあるが、サーバの再起動は極めて有効な方法だ(ただし、本質的な問題解決ではないので、再起動したら事後でもいいから管理者に連絡させるようにする)。
また管理者の外出時でもトラブルに対応できるように、リモートからサーバを制御できるような体制を整えておき、外出からシステム不調の原因を突き止められるような環境を作っておくとよい。市販のリモート管理ツールを利用すると、専用の電話回線とモデムと使って、自宅や出張先からサーバをメンテナンスすることが可能だ(画面3、表2)。
| 製品名 | メーカー | 対応OS | 価格 |
|---|---|---|---|
| Desktop On-Call Ver.3.0 | 日本アイ・ビー・エム | 管理される側：Windows 95／98／NT 4.0 OS/2 Warp 3／4 MacOS 8以上 管理する側：Javaが動作するWebブラウザ |
1万1800円～ |
| LAPLINK 2000 Second Editonプラス | インターコム | Windows 95／98／NT 4.0 | 1万6800円～ |
| pcANYWHERE Ver.9.2 | シマンテック | Windows 95／98／NT 4.0／2000 | 1万6800円～ |
| REACHOUT ENTERPRISE | ソリトンシステムズ | Windows 95／98／NT 4.0 | 1万9800円～ |
 |
|---|
| 画面3 代表的なリモート管理ソフトの1つ「pcANYWARE」の実行画面。モデムやインターネット経由の接続により、離れた場所からサーバなどのホストマシンを制御できる。サーバのリモート管理以外にも、一般ユーザーのシステム設定などを管理者が変更するといったヘルプデスク的な用途にも利用できる。こうしたリモート管理ソフトは、企業の大量導入用のライセンス・パッケージも提供されている |
バックアップ
ファイルを集中管理しているサーバをどうやってバックアップするかは、管理者にとって頭の痛い問題である。一般にバックアップデバイスは高価であるうえに、バックアップデバイスの記録容量がハードディスクの容量アップの進歩には追いついていないのが現実だ。複数のメディアを自動的に交換するチェンジャーを装備したバックアップデバイスを導入するという選択肢もあるが、予算やサーバの重要性とのバランスを考えると、購入が難しい場合もある。特に部署単位、あるいはSOHOなどでは、数十万もするようなDATドライブなど購入は不可能といってもよい。
1つの対策としては、安いハードディスクをバックアップ用に利用するという方法がある。たとえば、リムーバブルケースにバックアップ用のハードディスクを入れて、普段使っているハードディスクのボリューム全体をそこにコピーするのだ。このほうが、バックアップ速度の点から、テープデバイスよりは便利かもしれない。ただし、このバックアップ用のハードディスクはバックアップ専用に使い、日常的な利用は避けるようにする。「リムーバブルケースに入れて」といったのは、必要ない場合には外しておくようにするためだ(もちろん、ホットスワップをサポートしていないので、サーバを一度落とす必要はある)。
また、RAIDカードを使ってミラーリングを行ないつつ、バックアップを取る方法もある。具体的には、まず同一機種のハードディスクを3台用意して、このうちの2台を接続してミラーリングさせる。ミラーリングが完了したら、そのうちの1台を残りの1台と交換して再構築を行なわせる。これでハードディスク全体のコピーが作成できる。そして、定期的にミラーリングされている片方のハードディスクを、外してあったハードディスクと交換していけばよい。再構築中はディスクのパフォーマンスが低下するので、あまりバックアップ頻度を上げることができないが、まったく何もしないよりいいだろう。
また、バックアップするデータがそれほど多くないのなら、MOやCD-R/RWといったリムーバブルメディアを使うことも不可能ではない。
バックアップ・システムは、サービスを止めないことを最優先とするのか、データが保存されることを最優先とするのか、システムの特性や役割をよく検討してから導入するようにしよう。
