システム運用における、5つの大間違いとは(4)
間違い4:システムの負荷上昇を障害検知
新卒でシステム管理部門に配属されたSは、先輩Tの指導のもとで新しいシステムの監視設定を任された。作業対象外のサーバーで設定されている監視項目を眺めてみると、ロードアベレージ(サーバーの負荷平均)ではなくCPU使用率の、しかもディスクI/O(外部記憶装置へのデータの読み書き)のみ閾値が設定されていることを見つけた。
Sは大学の授業で、「ロードアベレージが1以上ならダメなシステムだ」と教わってきたが、ロードアベレージに閾値が設定されていなかったため、Tに質問してみたところ、「DBサーバーだから」という素っ気ない回答であった。その回答に対して、理解に苦しむSであった。
以前はシステム負荷の監視など必要なかった
20世紀型のシステムでは、プリントサーバーやファイルサーバー、バックアップサーバーなど、単一の機能を持つサーバーが多く存在した。単一の機能しか持たないサーバーは、処理中に負荷が上がり、未処理時に負荷が低下することは自明である。
例えばプリントサーバーの場合、なんとなく処理が遅いと感じるときは、たいてい誰かが大きなファイルを印刷しているときだ。その処理が終わらない限り自分のファイルは印刷できないため、待ち続けるしかなかった。このように、サーバーに求められている適切な処理を行うために負荷が上昇するので、このシステムでは、サーバー負荷状況を監視することそのものに意味がなかった。
一方、単一機能のサーバーだけでなく、単一機能のシステムも多数存在した。
例えば、勤怠管理専用システムや会計処理専用システムなどの、各種専用システムがそれである。それら専用システムは、夜間にバッチ処理やバックアップ処理を集中させることによって、昼間の業務遂行のシステムリソースを確保するといったように、日中と夜間でシステムに求められる業務がそれぞれ決まっていた。このためシステム内のサーバー単位で、ある程度の負荷を予測し、システムの増強や縮小を行うことが可能であった。
今やシステム負荷の監視は必須となったが…
その後時代は変わり、複数のプリンタを管理・印刷しながら画像ファイルを同時出力するプリントサーバー、複数のオートローダーや複数の仮想ストレージを同時に利用しながらバックアップを行うバックアップサーバーといった、単一機能でも並列処理が可能なシステムが、市場多数出回るようになった。
また、会社全体でのコストダウンを目指し、システムごとに多数のサーバーを導入するのではなく、多数のサーバーを複数のシステムで同時並列的に利用するようにもなってきた。この代表的な例として、自社専用のプライベートクラウドなどが挙げられる。プライベートクラウド上には、勤怠管理システム用の仮想サーバーやスケジュール管理システム用の仮想サーバーなど、さまざまなシステムが同居することになる。
連載バックナンバー
Think ITメルマガ会員登録受付中
全文検索エンジンによるおすすめ記事
- システム運用における、5つの大間違いとは(2)
- クラウドのサービス継続性を確保するために必要なパフォーマンスとは?
- プライベートクラウドの作り方
- KVHとミドクラの協業から見えるOpenStackの現状と将来
- 運用を支える監視システムを構築する
- レッドハット、OpenStack対応クラウドインフラストラクチャを実現する「Red Hat Enterprise Virtualization 3.3」を提供開始
- クラウドからシステムの自動運用を目指す!
- ヴイエムウェア、 VMware vCloud Suiteのクラウド管理機能をアップデート
- プライベートクラウドが失敗する理由とは
- NetAppが考える“クラウド”とは何か