 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 | ||||||||||
|
||||||||||
| パフォーマンスのモニタリング | ||||||||||
|
これまで紹介した機能によってサーバの新規配置や設定の管理については、かなり省力化できることがわかったと思います。しかし、管理者の課題は設定管理だけではありません。 実際にサーバが運用開始され、幾度かの設定変更を行い安定運用フェーズに入るかと思いきや、管理者がぶつかる次の壁は、サービスの拡大に伴うパフォーマンスの低下です。 サーバ市場やインターネット商取引の急成長は今さら説明するまでもないと思います。それらの数字が物語るもう1つの側面は、個々のサーバにも「負荷の急成長」が訪れる可能性があるということです。 一般的にサーバのユーティライゼーション（利用率）は80%が理想であるとされています。これより高くなるとサーバの故障率が急激に上昇し、これより低いと費用対効果という観点からあまり望ましい状態ではないとされています。 ハードウェアのスペックアップの適切なタイミングを知ることができれば、サーバの管理者は急激な負荷上昇に慌てて対処する必要もなくなります。またコスト管理の観点からは、費用対効果を最大化することで、ビジネスにおける利益を拡大することが可能になります。 RHNでは、Linuxの様々なヘルスチェックデータやOS上で動作するアプリケーション、Oracle データベースやApacheのステータスなどを収集してデータベースに格納し、任意の期間を設定してレポートやグラフを生成できます。また、しきい値（上限値・下限値）を設定することで、エラーを管理者に通知することも可能です。  図3：モニタリングモジュールのレポート （画像をクリックすると別ウィンドウに拡大図を表示します） |
||||||||||
| システムの再配置 | ||||||||||
|
システムの運用が長期に渡ると、ハードウェアの入れ替え作業が発生することがあります。例えばそれまでデータベースサーバとして使っていたハードウェアをアプリケーションサーバに転用する、あるいはサービス開始時に想定したよりもメールサーバの負荷が軽く、むしろWebサーバにブレードを振り替えた方が良いといった状況です。 もちろん、それらのサーバを「新規」にインストールすることも考えられますが、長期運用の間にRPMパッケージは更新されていますし、設定も変更されている可能性が高くないでしょう。もし既存のサーバの状態を新たなハードウェアに簡単に再現できれば、管理者の作業は大きく軽減されることになります。 RHNは、このようなニーズにも応えられます。つまり既存のサーバのプロファイルをベースにキックスタート（自動インストール）することで、まったく同じ構成のサーバを短時間で構築することが可能です。 |
||||||||||
| 次回 | ||||||||||
|
次回は様々なニーズに応えることが可能なRHNの4つのモジュールについて、詳細を紹介します。 |
||||||||||
|
前のページ 1 2 3 |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
-
-
連載
