 |
≫ |
|
|
|
|
業務や部門ごとに運用されてきたこれまでのサイロ型のシステムでは、サーバそのものの数の多さ、過剰なITリソース、複数のプラットフォームが混在する複雑さといった問題を抱えていました。これを解決するために、複数の分散したサーバをサーバ統合技術によって集約し、仮想化技術によって多様なITリソースをプール化・共有化するというアプローチが採用されるようになってきました。その結果、リソースの利用率は向上し、リソースへの投資額の大幅な削減、システム要求に応じた迅速で自在なリソース再配分などが可能になっています。
しかし、システムの運用管理は相変わらず人的リソースに依存する部分が多く、IT投資全体に占める運用コストの割合を減らすことができずにいます。今後、サーバ統合や仮想化の導入は、複数のシステムが連携する基幹系処理、そしてこれを支えるデータセンターの領域にも広がっていくものと見られています。基幹系処理やデータセンターでは複数のシステムにまたがった複雑で高度な運用管理が必要となり、運用担当者の負担は一層重くなっていくでしょう。
その解決には、運用管理の自動化が不可欠です。
 |
|
|
HW：ハードウェア、V：仮想化、A：自動化、M：管理 |
|
|
ますます重くなる運用コストの削減に向け、発生した事象に単純に対応する「イベント・ドリブン型」の対応では適切な削減に支障をきたす場合があります。
イベント・ドリブン型の動作原理は、ある事象が発生したときに実行すべき運用処理を記述したスクリプトをリソースやサービスごとに用意、これに沿って対応を実行するというものです。スクリプトは実行結果を「成功」あるいは「失敗」でしか返さないため、「失敗」の場合は運用担当者が処理をフォローしなくてはなりません。また、「成功」したとしても、サービス品質という点は基本的に考慮しません。このため、運用担当者による調整が必要となることもあるのです。さらに、スクリプトはリソースやアプリケーションとの依存関係が深いため、運用対象・発生事象ごとに大量のスクリプトを用意しなければならず、システム構成を変更する際には膨大な修正作業も必要となります。
つまり、既存のイベント・ドリブン型による、“第1世代”の管理方式では、格段と高度になる基幹系処理やデータセンターの運用負担とコストを削減することに対してまだまだ、不十分な仕組みといえるでしょう。サービス品質を維持しながら自律的な運用を可能にし、システムの導入や更新の際の負担も少ない“第2世代”の自動化ツール。その必要性はこれまで以上に高まっているのです。
|
|
印刷用画面へ
