|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
| DBMS管理ツールの評価は機能や価格・手離れで判断 | ||||||||||
|
複数のOSSを組み合わせてDBMS管理ツールを作るとしても、それはどのような製品を目指せばよいのか。 システム運用監視にとって決定打となる統一的な方法論は、未だ確立されていない。それでも大手ユーザ企業であれば、大金をはたいて高価な管理・監視ツールを導入し、そのための専属エンジニアを教育すれば、安定したシステム運用監視への解決の糸口はある。 では、それだけの潤沢な資金がない企業はどうすればいいのか。筆者はこれまでの経験から、真に求められる運用監視ツールのあるべき姿を次のように定義した。
表2:監視ツールのあるべき姿
以下にそれぞれを補足しよう。いうまでもないが、価格は重要なポイントだ。大企業だけが優れた運用監視ツールの恩恵にあずかれればよいわけではない。重要なのは、すべての企業にとって、運用監視ツールを導入するかどうかの選択肢となりうる価格であることだ。そして導入にあたっては、運用監視ツール自身のインストールや、その後の設定が簡単でなければならない。 現在、大半のDBMSはWebシステムに接続されている。そのため運用監視ツールは、Webシステムとの高い親和性が要求される。 手離れのよさも大事なポイントだ。理想的な運用監視ツールは、サポートのいらないシステムであることだ。少なくとも、引継ぎ等で再教育が必要なシステムであるべきではない。 構築や運用が楽でも、機能が不足していては本末転倒だ。可用性やセキュリティ、パフォーマンスの監視機能は必須だ。また、商用とオープンソース、どちらのDBMSも監視できなければならない。一度起きた障害が再発する可能性を踏まえ、それら障害の履歴管理機能も必要だろう。 そして、システムの発展や技術の進化、追加要件への対応などのため、新しい技術を併用または取り入れられる柔軟性を持たなければならない。 DBの運用監視は、単一的な監視メニューだけではなく、それを利用するアプリケーションからの監視も必要となる。そうした個々のアプリケーションの監視に対して、独自にカスタマイズできることも望ましい。 こうした条件を備えた上で、運用監視ツール自身が安定して動作しなければいけない(図2)。 ![]() 図2:HA機能とデーモン群の関係 |
||||||||||
| OSSベースのDB管理ツールは | ||||||||||
|
すでに実用段階に入ったこうした要件に鑑みながら開発されたWeb-DB群運用管理支援ツールが「HiTo!」だ。 |
||||||||||
| オープンソースの技術を集約し、DB管理に必要な性能を達成 | ||||||||||
|
ITベンダー固有の技術や製品と比較すると、オープンソースのソフトは「技術やパフォーマンスで見劣りがするのではないか?」という声を耳にする。はたしてそうなの。「HiTo!」はオープンソースソフトをベースに開発されているが、その内容は決して商用DB管理ツールにひけをとるものではない。以下、同製品の具体的な特徴を紹介しよう。 |
||||||||||
| MySQL、PostgreSQLに対応 | ||||||||||
|
従来のオープンソース系システムの運用監視では、種々のツールを組み合わせたり、スクリプトを作り込んでいた。だがLinuxプラットフォーム上に構築されるシステムが増えている昨今、各エンジニアのノウハウや暗黙知を頼みにした、個別の作り込みによる運用監視手法では、業務規模の拡大に応えられなくなってきた。そうした背景からHiTo!ではMySQLとPostgreSQLに対応することとした。 |
||||||||||
| セキュリティ対策機能を強化 | ||||||||||
|
強力なログ監視機能が、不正アクセスを確実に記録・通知する。フィルタリング機能も協力で、様々なパターンをフィルタとして設定し、不正アクセスを検知する。Windows Server上のバイナリログに対しても、同様に監視・フィルタリングが可能だ。 ログファイルは、常にバックアップを保存。対象ファイルの増加を検知するたびに、増分を取得・保存する仕組みだ。ログファイルが改竄・消去されたとしても、直前のログファイルからバックトレースが可能だ。 NetSNMPやsnortなど、既存のネットワーク管理・監視のOSSを一括管理することもできる(図3)。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||



