System Center Operations Manager 2012: 簡単に監視機能を拡張する
新しい System Center Operations Manager では、統合および拡張が進んだネットワーク監視機能が提供されることが約束されています。
Paul Schnackenburg
IT ネットワーク環境を監視することは重要です。Microsoft System Center Operations Manager (SCOM) では、Microsoft ネットワークの状態に関する総合的な情報を提供してきました。SCOM 2007 R2 エディションでは、混在環境を監視するために Unix と Linux の監視機能が追加されました。
SCOM 2012 は、今年の後半にリリースが予定されています。この新しいバージョンでは、高可用性 (HA)、アプリケーションのパフォーマンス監視機能、ダッシュボード、ネットワーク デバイスの監視機能、Java アプリケーション サーバーの監視機能など興味深い機能が追加されます。
新しいバージョンの SCOM では、インストール ウィザードが大幅に強化されています。最も顕著な変化は、運用データベースとデータ ウェアハウスのデータベースがインストール時に作成されることです。以前のバージョンでは、インストール前に、これらのデータベースを準備する必要がありました。
インストール ウィザードには前提条件チェッカーが組み込まれているため、インストール プロセスが簡略化されます。この機能により、エラーが検出され、エラー メッセージが自動的にコピーされます。定義したクリップボードの資格情報は、ウィザード内でテストされ、問題なく機能することが確認されます (図 1 参照)。
.jpg)
図 1 System Center Operations Manager 2012 のインストール プロセスには、いくつかの改良点が施されました
インストール プロセスでは、管理サーバーのアクション アカウント、構成サービス、およびデータ アクセス サービスを指定する必要があります。管理サーバーとゲートウェイの役割に同じサービスを使用することは可能ですが、セキュリティの観点では、お勧めしません。
すべての SCOM 2012 のサーバー機能は、仮想マシン (VM) として実行することがサポートされています。パフォーマンスの観点から、SQL Server データベースは、物理サーバーまたは直接取り付けディスクのある仮想サーバーで実行することが推奨されています。他の多くのワークロードと同様に、VM スナップショットを、SCOM 2012 と併用することはサポートされていません。
管理サーバーとゲートウェイ サーバーでは、Windows Server 2008 R2 SP1 が実行され、2.8 GHz の CPU と 2 GB 以上のメモリが搭載されている必要があります。SQL Server では、x64 エディションの SQL Server 2008 SP1 以上または SQL Server 2008 R2 が実行され、最低 4 GB のメモリが搭載されている必要があります。また、データベースの照合順序が、SQL-Latin1_General_CP1_CI_AS に設定され、フルテキスト検索が有効になっている必要もあります。
大規模な環境では、高可用性を実現するために SQL Server をクラスター構成にすることをお勧めします。SCOM 2007 R2 では、データ ウェアハウス データベースはオプションでしたが、SCOM 2012 では、SCOM 環境の必須コンポーネントです。ただし、データ ウェアハウス データベースは管理グループ間で共有できます。Windows エージェントは、32 ビット バージョンと 64 ビット バージョン以外に、64 ビット Itanium バージョンも提供されます。
アップグレード パス
SCOM 2012 に直接アップグレードできるのは SCOM 2007 R2 だけです。アップグレードする SCOM 2007 R2 管理サーバーは、x64 ハードウェアで実行されている 64 ビット バージョンで、ホスト OS は Windows Server 2008 R2 SP1 でなければなりません。
セカンダリ管理サーバ、ゲートウェイ、およびエージェントをアップグレードしてから、ルート管理サーバー (RMS) をアップグレードするのが、一般的なアップグレードの順序です。いずれかの管理サーバーまたはゲートウェイで SCOM 2007 R2 が実行されているとアップグレードはブロックされます。いずれかのエージェントで SCOM 2007 R2 が実行されている場合、RMS のアップグレード時に、そのことが検出されますが、アップグレードがブロックされることはありません。SCOM 2007 R2 エージェントは、SCOM 2012 にアップグレードされるまで、単にレポートできなくなります。
1 台の SCOM 2007 R2 サーバーで管理できる小規模な環境の場合、一括アップグレード (サーバーがハードウェアとソフトウェアの要件を満たしている必要があります) を実行するか、別の管理サーバーをセットアップして、そのサーバーからアップグレードを開始できます。1 つ目の方法を採用した場合、エージェントが SCOM 2012 にレポートするには、すべてのエージェントをアップグレードする必要があります。
TechNet ライブラリでは、適切な移行オプションを特定するのに役立つ、フロー ダイアグラム (英語) が公開されています。また、このページでは、ステップ バイ ステップの手順が記載されたチェックリストとアップグレード ヘルパー管理パック (MP) へのリンクも提示されています。
アップグレードの計画に関する推奨事項としては、データベースのバックアップ作成、通知の無効化 (間違った警告を防ぐため)、コネクタの停止 (アップグレード中に間違ったチケットが生成されることとエージェントが RMS に直接レポートすることを防ぐため) があります。最も重要な推奨事項は、問題が発生したときにイベント ログを確認することです。アップグレードしても問題は解決しないので、アップグレード前に管理グループに問題がないことを確認します。
しばらくの間は、SCOM 2007 R2 と SCOM 2012 の管理グループと管理サーバーが混在した状況が続くかもしれませんが、そのような環境では、SCOM 2012 エージェントが SCOM 2007 R2 サーバーとしか通信しないことを覚えておいてください。逆方向には機能しないので、古いエージェントは、できるだけ早くアップグレードすることが重要です。
MP のスキーマは変更されていないので、SCOM 2007 R2 で機能する MP は、すべて SCOM 2012 で機能します。ただし、API の変更により、エージェントに新しいモジュールをインストールすること、新しい MP テンプレート、または新しいビューの種類が必要になるサードパーティ製の一部の MP は例外となります。簡易ネットワーク管理プロトコル (SNMP) を使用するネットワーク監視 MP は、新しいバージョンでも引き続き機能しますが、新しいネットワーク監視フレームワークと統合するための更新が必要になることがあります。
インフラストラクチャに関する改良点
SCOM 2007 R2 では、RMS が単一障害点でした。RMS がコンソールと Web コンソールの接続ポイントで、構成サービスを実行し、コネクタ、正常性データの収集、ロール ベースのアクセス制御 (RBAC) に対応していました。SCOM 2007 R2 で高可用性を確保するには、RMS サーバーをクラスター構成にするほかありませんでした。これは技術的にも運用上も複雑でした。また、関連付けられているハードウェアとライセンス コストについては、アクティブ/パッシブ モデルが採用されていました。
SCOM 2012 では、Microsoft Exchange と他の複数のマイクロソフト アプリケーションを経由することで状況が変化しています。高可用性は、既定で備わっており、最も重要なのは管理サーバーです。複数の管理サーバーをプールに配置するだけで、負荷は分散され、可用性が確保されます。各サーバーで、構成サービスが実行され、データはデータベースに格納されています (SCOM 2007 R2 では、データは、XML 構成ファイルやメモリに格納されていました)。そのため、管理サーバーの起動時間が短縮されます。
フェールオーバーは瞬時に行われるものではありません。プールで管理されたインスタンスが再度読み込まれるまでに、最大 2 分かかります。また、すべての管理サーバーは、同じ処理能力があるものとして処理され、プロセッサの速度とメモリ容量の違いは考慮されません。既定のプールは、All Management Server Resource Pool (すべての管理サーバーのリソース プール)、Notification Pool (通知プール)、および Active Directory Integration Pool (Active Directory 統合プール) の 3 つです。また、ニーズに応じて独自のプールを作成することもできます。
一部の MP (Exchange Server 2007 や Exchange Server 2010 用の MP など) は、RMS に依存しています。SCOM 2012 には RMS サーバーが存在しないため、1 台の管理サーバーに、RMS Emulator (RMS エミュレーター) の役割が割り当てて、このような MP との互換性を維持する必要があります。この役割は管理サーバー間で移行可能ですが、役割のフェールオーバーを自動化する MP があります。
特定のプールに含まれる役割は手動で制御できます。手動による制御は、テキスト/SMS で警告を配信するデバイスを特定の管理サーバーに接続している場合に適切です。この役割をハードウェアが接続されていない別のサーバーにフェールオーバーしても意味がありません。
互換性に関する問題
現在の System Center スイートに関する問題は、このスイートが、複数の異なるアプリケーションが少し統合された状態で構成されていることです。これは、System Center 2012 で変更される予定です。このように異なるプログラムを接続するのは System Center Orchestrator 2012 です。この製品では、SCOM を含む System Center の主なアプリケーションに対応した統合パック (IP) を提供します。SCOM の IP では、Alerts and Monitors (監視とモニター) を作成および操作し、メンテナンス モードの開始/終了を制御します。
System Center Service Manager (SCSM) の IP もあります。この IP では、SCOM の警告に基づいて自動的にインシデントを作成します。たとえば、System Center Virtual Machine Manager (VMM) の IP では、VM、サービス、プライベート クラウド、およびホストに関する情報を SCOM に転送できます。この System Center を統合する新しいアプローチが、多くのユーザーから求められていた統合をようやく実現するかどうかが見物です。
現在、SCOM 2007 R2 では、IBM Tivoli や HP OpenView など、他の管理システムとの統合にコネクタを使用しています。SCOM 2012 では、コネクタがサポートされておらず、SCOM と他の管理システムの統合は、System Center Orchestrator 2012 によって行われます。
Windows PowerShell のサポート
朗報は、SCOM 2012 で Windows PowerShell 2.0 と多数の新しいコマンドレットが完全にサポートされていることです。古いコマンドレットも依然として機能するようですが、新しいコマンドレットの名前には SCOM という名詞が含まれているため、新しいコマンドレットについて学習する必要があります。Unix コンピューターや Linux コンピューターを監視する新しいコマンドレットもあります。これらのコマンドレットは、現在、Community Technology Preview (CTP) 版が提供されている Windows PowerShell 3.0 に依存しています。
Windows PowerShell コマンドレットを実行するには、管理グループへの接続を確立する必要があります。この接続は、複数のコマンドレットを実行できるように固定接続にすることも単一のコマンドを実行する一時的な接続にすることもできます。
高度な監視機能
多くの場合、大規模な企業では、ネットワークのトラブルシューティングとサーバーのメンテナンスは別の任務になります。そのため、問題の原因がハードウェア、OS、またはネットワークのどこにあるのかを迅速に特定するのが困難になります。SCOM 2012 に追加された最も興味深い機能の 1 つは、ネットワークの監視機能です。これは、可視性を強化して、迅速な問題解決を手助けをすることを目標に設計されています。
SCOM 2007 R2 には、基本的なネットワーク デバイスの監視機能が用意されていましたが、(各デバイスを手動で構成しない限り) ポート レベルの監視機能は提供されませんでした。SCOM 2012 では、SNMP v1、v2、および v3 がサポートされており、IP v4 と v6 の両方に対応しています。新しい SNMP スタックは、SCOM 2012 固有のものなので、SCOM 2007 R2 では OS の SNMP スタックを使用します。
SNMP に対応している任意のネットワーク デバイスをポート レベルで監視できます。また、特定のデバイスを検索結果から除外することもできます。プロセッサとメモリの使用率と断片化状況を追跡する拡張された監視機能もあります。この監視機能では、これ以外に、SCOM 2012 でサポートされているデバイス固有の項目についても追跡することが可能で、現時点では、80 社以上のベンダーと 800 種類以上のデバイスがサポートされています。
デバイスでシステム変更 (カードの追加やシャーシの構成変更など) の SNMP トラップがサポートされている場合、SCOM 2012 では、SNMP トラップをリッスンします。読み取り専用の SNMP 文字列によって、すべての監視処理が行われます。ノードがダウンするとその他の監視がすべて抑制されるので、ポートやリンクがダウンしていることに関する警告で画面が溢れ返ることはありません (図 2 参照)。
.jpg)
図 2 ネットワークの監視データは問題を迅速に特定するのに役立ちます
ポートのステッチ機能では、エージェントで監視しているノードの接続先ポートが提示されます。SCOM では、VLAN と各 VLAN に参加しているスイッチを検出します。重要なネットワーク ポートのルールに手動でポートを追加しない限り、接続されているポートのみが監視されます。Cisco 製のルーターでは、ルーター自身が参加している Hot Standby Router Protocol (HSRP) グループを特定します。SCOM 2012 では、200 個以上の新しい項目がネットワーク監視機能の対象になります。
現在、SCOM 2012 のスケーラビリティに関する推奨値は、1 台の管理サーバーにつき 500 台のデバイス、1 つの管理グループにつき 2,000 台のデバイスです。今後、より包括的なサイズに関するガイドが提供される予定です。1 台の管理サーバーに設定できる検出ルールは 1 つだけなので、そのルールで必要なすべてのデバイスが検出されるようにすることが重要です。
ネットワーク監視のダッシュボードは 4 つあります。Network Vicinity (ネットワーク近接度) ダッシュボードでは、選択したノードから 1 ホップ以内にある接続されているデバイスについて視覚的な情報を提供します。ホップ数は 5 まで上げることができます。ダッシュボードでは、チーム化された NIC をチーム化されているものとして認識せず、Unix/Linux コンピューターも表示されません。VM は、ホストと同じネットワーク デバイスに関連付けられますが、Hyper-V スイッチは、SNMP デバイスとして表示されます。その他のネットワーク監視ダッシュボードでは、問題のあるデバイスの概要、特定のデバイスに関する詳細情報、個別のポート情報が提供されます。
トラブルシューティング戦術
アプリケーションのパフォーマンスに関する問題のトラブルシューティングは困難です。多くの場合、このような問題のトラブルシューティングを行うには、そのプログラムの詳しいしくみを理解していることが必要になります。問題の原因が、コード、サーバー ハードウェア、サーバー ソフトウェア、またはネットワークのどこにあるのかを特定するには、すべてのアプリケーションにおける標準的なメトリックスと問題が潜んでいる層を簡単に特定する方法が必要です。
AVIcode では、アプリケーション コードのパフォーマンスに関する問題を検出します。AVIcode は、最近、マイクロソフトが買収したもので、アプリケーション パフォーマンス監視 (APM) エージェントとして SCOM に統合されます。APM エージェントは、Microsoft .NET Framework/Web アプリケーションとのみ連動し、スタンドアロンの実行可能ファイルとは連動しません。また、監視対象となるのは IIS 7 と IIS 7.5 のみです。
SCOM 2012 のインフラストラクチャは完全に統合されており、個別のデータベースはありません。SCOM 2012 で IIS を実行している Windows Server 2008 または Windows Server 2008 R2 サーバーを監視している場合、そのサーバーには APM エージェントが自動的に展開されます。各 Web アプリケーションのサービス レベル契約 (SLA) を個別に構成するのではなく、 すべての Web アプリケーションに対して総合的な SLA を設定できます (SLA では、許容できない待機時間を秒単位で規定します)。このような SLA を設定することで、必要に応じて、特定のプログラムの SLA を調整できます。
インターセプターがアクティブになって IIS に読み込まれると、サーバーの再起動が必要になります。一度再起動すると、その後は、さらにアプリケーションを追加した場合でも、特定のアプリケーション プールをリサイクルするだけでかまいません (図 3 参照)。
.jpg)
図 3 アプリケーションのパフォーマンス監視機能を構成することは難しくなく、簡単にアプリケーションを監視できます
このレベルの統合のすばらしさは、ネットワーク、ハードウェア、OS の監視情報がアプリケーションのパフォーマンス情報と並べて表示されたときに明らかになります。この情報により、これまでよりも簡単に問題に照準を合わせることができます。
ダッシュボードを操作する
SCOM では膨大な量のデータを収集します。ただし、単にデータを収集しているわけではなく、データをフィルター処理して、ユーザーに適したデータを表示しています。グラフやチャートは、このようなデータの提示に打って付けの方法です。以前のバージョンの SCOM では、ビューとシンプルなダッシュボードが用意されていましたが、SCOM 2012 では、これらのものをまったく新しいレベルに発展させています。
ダッシュボードを作成する新しいウィザードにより、特定の対象ユーザー用にカスタマイズされたデータが簡単に表示できるようになります。ウィザードは、既定のコンソールと Web コンソールの両方で利用できます。作成したダッシュボードは、コンソール、Web コンソール、および SharePoint 2010 で表示することが可能で、外観は、どの環境でもほぼ同じです。SCOM 2012 では、ダッシュボードを入れ子にして、特定のデータをドリルダウンすると別のダッシュボードが表示されます。
SCOM 2012 でダッシュボードを作成するには、3 つの手順を実行します。まず、必要なセルの数に基づいてレイアウトを選択します。次に、各セルにウィジェットを追加します (ウィジェットの種類は、Alert (警告)、Performance (パフォーマンス)、および State (状態) です)。最後に、各ウィジェットで、範囲、条件、および表示の設定を構成します (図 4 参照)。
.jpg)
図 4 System Center Operations Manager 2012 では、簡単にカスタム ダッシュボードを作成できます
SCOM ダッシュボードは、Web パーツを使用して、SharePoint 2010 に統合できるようになりました。ダッシュボードを参照するユーザーが SCOM ユーザーでない場合は、共有の資格情報を使用して Web パーツを構成できます。統合対象は、SharePoint Server 2010 Standard、Enterprise、および無償の Foundation バージョンです。
ダッシュボードの個人設定はデータベースに格納されるので、別のコンピューターや環境からアクセスした場合でも設定が維持されます。SCOM 2007 R2 では、ダッシュボードは、ローカル コンピューターのレジストリに格納されていました。Web コンソールの各ダッシュボードには、個別の URL が設定されています。ユーザーは特定のダッシュボードをお気に入りに追加できるので、IT に詳しくないユーザーにも簡単に情報を提供できます。
最も一般的な組み込みのダッシュボードは "Management Group Health" (管理グループの正常性) です。このダッシュボードは、コーヒーブレイクと呼ばれることもあります。このように呼ばれるのは、このダッシュボードが SCOM 2012 のオペレーターが管理している環境の簡単な概要を一目で確認できるように設定されており、「コーヒー ブレークを取ってもいいですか」という質問に答えられるからです。このダッシュボードでは、インフラストラクチャと SCOM システムで提供されている機能の両方を監視しています (図 5 参照)。
.jpg)
図 5 Management Group Health (管理グループの正常性) ダッシュボードでは簡単な概要情報が提供されます
混在環境を監視する
SCOM 2012 では、Unix コンピューターと Linux (*nix) コンピューターのサポートが継続されていますが、いくつかの重要な機能強化が施されています。*nix エージェントでは、PA-RISC と IA64 で実行されている HP-UX 11i バージョン 2 と 3、SPARC で実行されている Sun Solaris 9、SPARC と x86 で実行されている Sun Solaris 10、x86 と x64 の両方で実行されている Red Hat Enterprise Linux 4、5、および 6、x86 で実行されている Novell SuSE Linux Enterprise Server 9、x86 と x64 の両方で実行されている Novell SuSE Linux Enterprise Server 10 SP1 と 11、POWER で実行されている IBM AIX 5.3、6.1、および 7.1 がサポートされています。
混在環境の監視を簡略化するため、SCOM 2012 では、sudo と SSH キーがサポートされています。前者により、管理されているコンピューターで必要なアクセス許可を設定した標準アカウントを構成できるようになります。また、後者により、エージェントのメンテナンスがセキュリティで保護されることが保証されます。
SCOM 2012 では、Java Enterprise Edition (JEE、旧称 J2E) アプリケーション サーバーの総合的なサポートにも対応しています。SCOM 2012 では、4 種類のサーバーがサポートされています。サポートされているのは、Windows と Linux の両方で実行している IBM WebSphere 6.1 と 7、Red Hat JBoss 4.2、5.1、および 6、Oracle WebLogic 10g Rel3 と 11g Rel1、およびオープン ソースの Apache Tomcat 5.5、6、および 7 です。また、AIX で実行されている WebSphere と Solaris で実行されている WebLogic がサポートされています。
環境に合った Java の MP をインポートすると、MP によってアプリケーション サーバーが検出されます。標準的な監視機能によって、アプリケーション サーバーが実行されているかどうか、リソースの使用率が定義されているしきい値の範囲内にあるかどうかが報告されます。
さらに詳細な監視を行うために、マイクロソフトでは、アプリケーション サーバーに読み込む BeanSpy (旧称、JMX Extender) という名前のオープン ソースの Java Management Extension (JMX) を用意しています。BeanSpy では、HTTP または HTTPS 経由 (基本認証を使用または使用せずに) で SCOM に報告します。BeanSpy では、MBean カウンター (Windows のパフォーマンス カウンターのようなもの) と通信して、実行中の各アプリケーション、メモリのガベージ コレクションの頻度と処理時間、アプリケーション サーバーのパフォーマンスを監視します。
残念なのは、SCOM で Windows クラスターが既定でサポートされていないことです。ですが、アプリケーションの監視機能で、Windows Azure パブリック クラウドのアプリケーションを監視したり、JEE のクラスター化された Java アプリケーションを監視できるのは嬉しい限りです。
全体的に、SCOM 2012 は、いくつかの非常に便利な機能によって、十二分な改良がなされています。簡略化されたインフラストラクチャと簡単に利用できる可用性は歓迎されるでしょう。また、高度なネットワーク監視機能により、トラブルシューティングの作業が楽になるでしょう。ですが、おそらく、最も興味深い機能は、System Center Orchestrator が System Center スイートをどのように結合するのかを目にすることではないかと思われます。
.jpg)
Paul Schnackenburg は、286 コンピューターの時代から IT 業界で働いています。オーストラリアのサンシャイン コーストで自分の会社である Expert IT Solutions を経営しながら、パートタイムで IT 関連の講師を務めています。MCSE、MCT、MCTS、および MCITP という認定資格を持ち、Windows Server、Hyper-V、および Exchange のビジネス向けソリューションを専門としています。連絡先は paul@expertitsolutions.com.au (英語のみ) です。彼のブログは TellITasITis.com.au (英語) でご覧になれます。