編成面からの対策

Sun Management Center には、ローカル環境を定期的に自動チェックして管理対象ノードを確認できる強力な検出マネージャが付属しています。検出マネージャは、Sun Management Center の構成に役立つだけでなく、ネットワークベースの物理的なラインに沿って管理情報の体系化も行います。

環境の特性によっては、検出マネージャを使用することが管理情報の表示やステータス情報の収集に最適な方法とは言えない場合もあります。しかし、Sun Management Center 環境の編成に先立って管理対象となるシステムをすべて特定するのには検出マネージャが非常に役立ちます。検出マネージャの詳細は、Chapter 4, 「Adding Objects to the Topology Database Using the Discovery Manager,」 in 『Sun Management Center 3.6 User’s Guide』を参照してください。

Sun Management Center 環境を編成する方法としては、ほかに次のようなものがあります。

• 物理面

• 環境面

• アプリケーション面

• サービス面

各 Sun Management Center 環境では、完全性を重視する必要があります。たとえば、対応範囲は、システム障害を事前に、あるいは少なくともただちに発見できるぐらいの範囲でなければなりません。環境にとってきわめて重要でありながら Sun Management Center による監視が行われていないデバイス、ホスト、サービス、プロセスなどで障害が発生すると、この対応にギャップが生じ、実装の全体的な有効性に影響を与えかねません。このためには、Sun Management Center 管理環境を構築する際に、カスタマイズされたモジュールやプロキシソリューションを考慮するとともに、ほかのサーバーコンテキストからの情報も考慮する必要があります。

物理面からの編成

管理対象となるシステムの物理的な位置が、そのシステムが存在するネットワークに対応していないという場合があります。このような場合には、その Sun Management Center グループを物理的なライン上に構成できる新しいドメインを作成することをお勧めします。都市、サイト、ビル、フロア、サーバールームのほか、機器を設置するラックまでも簡単に表現できます。これらの場所のシステムは、検出マネージャを使用して検出作業が行われたドメインからコピーしてペーストできます。

物理的なラインに沿って Sun Management Center 環境を構成するには、システムが実際に配置されている場所を知る必要があります。この編成は、簡単に利用できる貴重なリファレンスとなります。物理面からの編成では、ステータスの収集パスも決定されます。このため、障害は物理的なライン上で分離され、共通モード故障 (CMF) の検出が容易に行われます。たとえば、特定の場所で発生した停電は複数のネットワーク上に渡って存在するシステムに影響を与える可能性がありますが、物理的な場所ということでは 1 個所にしか現れません。

情報は管理者自身で最新の状態に保つ必要があります。検出が実施される際にこの情報が自動的に更新されることはありません。検出プロセスは物理的に再配置が行われた資産の自動追跡は行いません。

環境面からの編成

組織によっては、場所とリソースが重複していながら論理的な機能はそれぞれ独立しているという複数の論理環境を抱えている場合もあるでしょう。論理環境には、職務グループ (営業や技術など)、機能グループ (小売や大口など)、論理的なソフトウェア環境 (ユーザー承認や製造など) があります。

この 3 つのケースとも、各グループの要素を分離させる個別の Sun Management Center トポロジを生成することを検討してください。トポロジグループを分離させると、1 つのグループで問題が発生してもほかのグループで警告が出されるということがありません。この分離は、マルチドメインサーバーを抱えるシステムで Sun Management Center 環境を構成する場合にとりわけ重要となります。ドメインが異なると、それぞれまったく異なるグループまたは環境を対象として機能している可能性があります。単一のトポロジグループに複数のドメインを含めると、紛らわしい情報やアラーム通知が生成される可能性があります。

アプリケーション面からの編成

システム管理においてアプリケーションは複雑な存在です。アプリケーションがどのような要素から構成されているかを管理的な視点から確認するのは容易ではありません。特に、適切な稼働を目的としてアプリケーションが分散され、多数の外部サービスに依存している場合はとりわけ困難でしょう。このため、アプリケーションを編成してから Sun Management Center のインストールをする必要があります。問題が実際に発生するまで因果関係の検討を先延ばしにすることがあってはいけません。初期分析を実施することで効率向上の一助となり、アプリケーションレベルの問題の解決策につながります。

アプリケーションを重視した Sun Management Center 環境を構成する場合は、一般にトポロジコンテナにホスト、モジュール、および特定のオブジェクトを混在させます。この場合、一部のホストを完全にそのアプリケーション専用とし、ほかのホストはそのアプリケーションを正常に稼動させるために部分的に使用するだけにとどめるという方法を採ることができます。たとえば、コーポレートディレクトリサービスを使用するアプリケーションの場合、アプリケーションの処理上、そのディレクトリサービスが健全に機能していることが重要視されますが、サーバー上のほかのサービスの健全性はアプリケーションにとって重要ではなく必須要件ではありません。

サービス担当面からの編成

状況によっては、1 つのグループまたは 1 人の管理者が特定のサービスを担当し、使用中のリソースは担当しないという場合があります。たとえば、データベースサービスの可用性とデータの整合性を担当するデータベース管理者の場合、ハードウェアやオペレーティングシステムは担当していないことが考えられます。この場合、データベース管理者はそのデータベースサービス用に作成された Sun Management Center ドメインの支援によって必要な作業を進めることができます。また、一般的なシステムやネットワークステータスのアクセスには、一般ユーザー の役割の権限を使用できます。