課題 3: 運用状況をレポートするのが大変

トピック

シナリオ
背景を考える
痛み 1 : そもそも全台を把握するのが大変
痛み 2 : 細かい数字を集めてレポート作るのが大変
痛み 3 :どのくらいキャパがあるのか知るのが大変
補足資料

シナリオ

システムは稼動させていればいいだけではありません。ちゃんと計画通りに稼動しているのか、どの程度の余裕があるのか、もしくはないのか、など運用状況をレポートしなければならないことがあるでしょう。もちろん、これらの情報は、システムの刷新や改善を行っていく際にはとても重要な情報となるはずです。しかし、この情報を取りまとめるだけでも大変です。運用スケジュールやキャパシティ、トラブルの有無、パフォーマンスなど多くの側面からのレポートが必要となってきます。どのような方法でこの煩雑ともなりえるレポート作業を軽減し、改善プランにいかしていけるのでしょうか？

背景を考える

システム投資を検討していく中でも IT エンジニアが担う役割は、多く存在します。その中でも重要なポイントとなるのは、今あるシステムが必要十分なのか、それとも追加投資しなければならなのかを判断するためのレポートです。定常的な管理業務を行っているなかで蓄積されたさまざまな情報を分析し、報告しなければ、システムそのものに新たな息吹を吹き込むことも収束させることもできないはずです。

課題 2 で挙げている問題点とも密接に関連してきますが、システムの環境が複雑化してくることで、日々の業務も複雑化し、そして、その稼動状況の分析やその妥当性の評価を行うことも困難を極めてきます。

しかし、ここで、正しい評価をすることができなければ、誤ったシステム投資が行われてしまうことにもなりかねません。過大投資が行われてしまえば、無駄に多くの環境を管理運用していかなければならなくなり、負担が大きくなってしまうでしょう。また逆に過少投資されてしまった場合は、必要十分なサービスを提供できないシステムとして運用が開始されてしまい、そのサポートに終始することになってしまい、ビジネス環境を阻害してしまう可能性まで生まれてきます。

どのようにすれば、より的確なレポートや計画を IT エンジニアの手で作成することができるのでしょうか。そして、どのようにすれば、その作業を軽減していくことができるのでしょうか？

IT プロ エバンジェリストからの一言

「うちの A システムは今月どんな運用状況だったんだ？」
「今のインフラでどこまで持たせることができるんだ？」
「どのくらい B システムは利用されているんだ？」

こういう質問の嵐を受け止めて頑張ってレポートを書いている人が皆さんの周りにどれだけいるんでしょうか。このようなレポートを出すには、継続的にシステムを運用していく上で避けて通れない サイジングとキャパプラ、しかも今の複雑なシステム構造ではそれも繰り返し Update しないといけない。それ以前にマシンの一覧、機器の一覧すらもきちんと仕切り直しをして整理をがっちりしていないと最新になっているかどうかわからないでしょう。皆さんの今の運用管理を考えた時に、どこまで自動化できているでしょうか。

そこで Systems Management Server（SMS） や Operations Manager（MOM） の出番です。特に MOM に関してはエージェントなしでも WMI を利用してリモートの PC からの情報採取も結構できますし、イベントログにあがる数多いイベントのうち、本当に対処しなければいけないものがどれなのか、どういうフィルターをすべきなのかという点を管理パックという形でお届けしています。また、SMS と MOM を利用いただいていれば、System Center Reporting Manager 2006 という製品で双方のバックエンドの情報を集約して SQL Reporting Services を活用したレポートが出力できます。SMS の収集した資産管理的な情報と MOM の収集した状態情報の融合レポートという訳です。System Center は進化中なのでまだまだ実際の現場では足りない情報もあると思います。しかし、現行のバージョンでも自動的に採取した情報からレポートが出てくるのは便利になるに違いありません。

サイジングやキャパプラに関する情報が Web の情報として足りないというご指摘をいただくことがあります。Windows Server 2003 あたりから情報提供量も多くなってきてはいますが、別のアプローチが System Center Capacity Planner 2006 です。このバージョンでは Exchange、MOM のキャパプラ シミュレーションか可能になりますが、MS 開発部門に集まった情報をベースに作ったものです。例えばメール サーバーの負荷というのはヘビー ユーザーもいれば、ライトなユーザーもいる、添付ファイルをいっぱいしてしまうユーザーもいればそうでないユーザーもいる。このように非常に負荷を想定するのが難しく、シミュレーション自身も難しいものです。しかし、Capacity Planner は入力するパラメーターは多いものの、いったんモデルができてしまえば、一部を変更するシミュレーションを容易にでき、その結果、ある拠点のユーザーのレスポンスがどう変わるかも計算で出します。元々MSの研究部門である MS Research が検討していたテクノロジー（Codename：Indy） で、MSN ウェブサイトでキャパプラをしたことをルーツにしているので SQL や IIS などもこの形態で取り込めるかを是非開発部門には検討して欲しいと思います。

痛み 1 : そもそも全台を把握するのが大変

Excel でマシンの一覧はあるよ、でも更新されてないから最新はチェックしてみないとわからない。恒例のリスト内容をチェックしてもらうメールを出したり、掲示板に載せたり、場合によっては手分けしてチェックして回ったり。

ソリューショ ン提案

Systems Management Server 2003

Systems Management Server ホームページ
Systems Management Server 2003の製品ホームページです。

Systems Management Server 2003 コンセプト、計画、導入ガイド
SMS 2003 を実際に導入する際に重要な展開計画、コンセプト、およびインストールに関するガイドです。

SMS 2003 資産管理
SMS 2003 の資産（インベントリ）管理機能について関連情報を集めたページです。

SMS 2003 資産管理データシート
フレキシブルできめ細かなインベントリ ログ、利用統計、およびカスタマイズ可能な Web レポート などの SMS 2003 の機能について概要が記載されています。

痛み 2 : 細かい数字を集めてレポート作るのが大変

パフォーマンス カウンターは定常的に採取しているし、イベントも採ってある、IIS のログもあるよ。そこから各サーバーの状況を抽出して健康状態をレポートしなければいけないが簡単にはできない。

ソリューション提案

System Center Reporting Manager 2006

System Center Reporting Manager 2006 ホームページ
System Center Reporting Manager の製品ホームページです。

System Center Reporting Manager 2006 の概要
大まかに System Reporting Manager 2006 の機能概要を説明しています。

System Center Reporting Manager 2006 データシート
SMS と MOM のデータをどのように統合できるのか説明文書をダウンロードできます。

痛み 3 :どのくらいキャパがあるのか知るのが大変

構築当時からサイジングとキャパシティ プランニングがちゃんとしていても想定条件に合致しない条件が発生した場合にはそれも検討し直し。ましてや想定がかなり甘い状態で構築したシステムであればなおさら大変。

ソリューション提案

System Center Capacity Planner 2006

System Center Capacity Planner 2006 （英語）
日本では残念ながら現段階で発売されていませんが、TechNet や MSDN から入手してお試しいただくことは可能です。

Q&A: Kirill Tatarinov Discusses Innovations in Microsoft’s System Center Family of Products （英語）
マイクロソフトの DSI 戦略と System Center 製品に関する 2006 年 4 月米国 San Diego で行われた発表内容です。

System Center Overview - Building toward Dynamic Systems （英語）
Capacity Planner が System Center 製品群の中でどういう位置づけかがわかります。

補足資料

Microsoft Research - Systems and Performance
Capacity Planner の元になった Indy プロジェクトのページです。

Microsoft Virtual Server 2005 ホームページ
仮想化を検討する際に是非このページをご覧ください。