test

Sun Management Center 3.5 インストールと構成ガイド

サーバレイヤのリソース

サーバレイヤは、Sun Management Center ソフトウェアの中核です。サーバレイヤのホストに適切なハードウェアを指定することは、Sun Management Center において応答性に優れた確実な処理を実現する上で重要な意味を持ちます。Sun Management Center サーバレイヤのハードウェア要件は、エージェントの要件よりもはるかに厳しいものです。Sun Management Center 3.5 サーバレイヤのシステム要件は、Sun Management Center 2 x や 3.0 サーバレイヤのハードウェア要件よりも厳しいものです。バージョン 2.x や 3.0 サーバホストは、必ずしも、Sun Management Center 3.5 のシステム要件に適合するものではありません。

Sun Management Center サーバレイヤは、Solaris バージョン 8 またはバージョン 9 を使用している SPARC プラットフォームデスクトップとサーバのうち、この節で説明している最小のハードウェア要件を満たすマシンでサポートされます。

注 –

最大限のパフォーマンスを得るためには、サーバレイヤアプリケーションだけを実行する専用マシンに Sun Management Center 3.5 サーバレイヤをインストールしてください。

サーバとして推奨されるハードウェアプラットフォーム

次の表に、Sun Management Center サーバのプラットフォームとして採用できるマシンの 4 つのクラスとそのハードウェア構成を示します。どの場合でも、代替マシン構成で同等のパフォーマンスを提供できます。

表 C–4 Sun Management Center サーバとして推奨されるハードウェアプラットフォーム

アーキテクチャ 

マシンの種類 

CPU の種類 

RAM 

スワップ領域 

小型サーバ 

Netra X1、Netra T1、または Sun Blade 100 (あるいは、これに相当するマシン) 

502 MHz UltraSPARC IIe 以上の CPU x 1  

1G バイト 

最小 512M バイト、1G バイトを推奨 

中型サーバ 

Sun Enterprise 80 (あるいは、これに相当するマシン) 

450 MHz UltraSPARC II 以上の CPU x 2  

1G バイト 

最小 512M バイト、1G バイトを推奨 

大型サーバ 

Sun Fire 280R、Netra T4、または Sun Blade 1000 

750 MHz UltraSPARC III 以上の CPU x 2 

1G バイト 

最小 512M バイト、1G バイトを推奨 

超大型サーバ 

Sun Fire 480R (あるいは、これに相当するマシン) 

900 Mhz UltraSPARC III 以上の CPU x 4 

2G バイト 

1G バイト 

サイジング要件

Sun Management Server のホストサイジング要件は、サーバレイヤで管理されるエージェントの数とそれらのエージェント上の管理作業に大いに左右されます。管理作業には、システムが生成する作業 (イベントの生成や処理など) とユーザが起動する作業 (データのブラウジング、ネットワーク検出、グループ処理、システム監視および診断など) があります。

管理作業の影響のため、サイジング要件は、サーバにインストールされている Sun Management Center アドオンパッケージの数、種類、および構成、そして管理ノードの数によって変わります。一般には、使用中のアドオンの数が多いほど管理作業の量が多く、サーバのハードウェア要件も厳しくなります。

次の図に、Sun Management Center サーバとして推奨されるマシンのクラスを、管理対象となるエージェント数とおおよその管理作業の関数として示します。この図では、サーバ上では Sun Management Center コンソールが動作していないことを想定します。また、小型サーバの場合は 5 個の遠隔コンソールセッション、中型サーバの場合は 10 個の遠隔コンソールセッション、そして、大型サーバと超大型サーバの場合は 15 個の遠隔コンソールセッションが存在することを想定します。

図 C–1 イベントごとに示した Sun Management Center サーバの 1 日当たりの負荷と管理対象オブジェクトの数

イベントごとに示した Sun Management Center サーバの 1 日当たりの負荷と管理対象オブジェクトの数

上記図に示したマシンのクラスは、同様な性能を持つホストの代表的なクラスを示します。

注意 – 注意 –

Sun Management Center コンソールアプリケーションをサーバレイヤホスト上で実行することによって、サーバは性能に影響を受けます。さらに、この影響はアクティブなコンソールセッションの数によっても変わります。サーバホストがサーバレイヤコンポーネントをサポートできる余裕がない場合、Sun Management Center コンソールをサーバマシンで実行してはなりません。

Sun Management Center サーバと Performance Reporting Manager アドオン

Sun Management Center の Performance Reporting Manager (PRM) アドオンを使用すると、Sun Management Center エージェントが監視している任意のデータプロパティに関して、その履歴的な傾向を追跡したり、レポートを生成したりできます。PRM アドオンは大量のデータを収集および処理できるので、Sun Management Center サーバのサイジング要件に大きな影響を与える可能性があります。

PRM アドオンの影響は、図 C–1の PRM 部分に示されています。一般的に、管理作業と PRM が追跡するデータプロパティの総数が増えるほど、Sun Management Center サーバが管理できるエージェント数は減ります。

PRM アドオンを持つ Sun Management Center サーバの要件を判断するには、2 つの手順が必要です。

  1. PRM アドオンがインストールされている Sun Management Center サーバが管理するエージェントの総数にもとづいて、図 C–1の PRM 部分を参照しながら、必要なマシンのクラスを判断します。

  2. 収集したい PRM データプロパティのおおよその数にもとづいて、次の節を参照しながら、適切な PRM 構成を判断します。

PRM 構成の種類

Sun Management Center 設定中、PRM 構成の中から 1 つの種類を選択するように確認するメッセージが表示されます。次の表に、PRM 構成の種類を示します。「アーキテクチャ」列は、表 C–4に示したマシンのアーキテクチャを指します。

表 C–5 PRM 構成の種類の要件

PRM 構成の種類 

ディスク容量 

PRM データプロパティの総数 

エージェント数の例 

エージェントごとのデータプロパティ数の例 

アーキテクチャ 

小型 PRM 

5G バイト 

50,000 

100 

300 

小 

 

 

 

400 

100 

通常 

中型 PRM 

12G バイト 

150,000 

300 

300 

中 

 

 

 

500 

300 

大 

 

 

 

750 

200 

超大型 PRM 

大型 PRM 

24G バイト 

240000 

600 

300 

大 

 

 

 

750 

300 

超大型 PRM 

通常、Sun Management Center の小型サーバは小型 PRM 構成に使用されます。中型サーバは中型 PRM 構成に使用されます。そして、大型サーバと超大型サーバは大型 PRM 構成に使用されます。Sun Management Center の超大型サーバは小型 PRM や 中型 PRM にも使用できます。ただし、利用できるディスク容量や予想される PRM データ収集要件によって条件は変わります。

PRM サーバの構成例

次の表に、アーキテクチャの種類ごとに管理できるエージェント数の例を示します。この例では、各エージェントが PRM ごとに平均 300 個のデータプロパティを収集しているとことを想定します。「1 時間ごとのデータ収集」列は、(1 時間ごとに) データを収集するのに必要なおおよその時間を示します。「夜間処理」列 は、収集したデータを処理するのに必要なおおよその時間を示します。データを収集および処理するのに必要な時間は、サーバのハードウェア、サーバの活動、およびデータベース内の PRM データ数によって変わります。

表 C–6 サーバの例: 管理対象となるエージェント数

アーキテクチャ 

エージェント数 

PRM データプロパティの総数 

PRM 構成の種類 

1 時間ごとのデータ収集 

夜間処理 

小 

100 

30,000 

小 

2 分 

1 から 2 時間 

中 

300 

90,000 

中 

7 分 

3 から 4 時間 

大 

600 

180,000 

大 

7 分 

3 から 6 時間 

超大 

750 

225,000 

大 

6 分 

3 から 6 時間 

Performance Reporting Manager レポートの生成

さまざまなエージェント数、データプロパティ数、およびレポート期間 (4 時間から 1 か月など) を指定することによって、さまざまなレポートを生成できます。

通常のレポートを生成するには、数秒から数分かかります。実際にかかる時間は、次の要因によって変わります。

たとえば、 Performance Reporting Manager アドオンが構成されている中型の Sun Management Center サーバでは、比較的簡単なレポート (1 つのエージェントの 5 つのデータプロパティを 24 時間調べたレポート) を生成するには約 20 秒かかります。より複雑なレポート (5 つのエージェントの 5 つのデータプロパティを 7 日間調べたレポート) を生成するには約 10 分かかります。

注 –

ここで、Performance Reporting Manager アドオンが構成されている中型の Sun Management Center サーバとは、450 MHz の UltraSPARC II CPU x 2 、1G バイトの RAM、および 1G バイトのスワップ領域を持つ Ultra-80 のことであることを想定します。また、Ultra-80 は Performance Reporting Manager 用に 300 個のエージェントを監視しており、エージェントごとに 300 個のデータプロパティを収集していることを想定します。

Performance Reporting Manager レポートのスケジューリング

レポートを生成するのに 30 分以上もかかってしまう場合、午前 4:00 から午前 8:00 までの間にレポートを実行するようにスケジュールすることが推奨されます。大きなレポートを午前 4:00 以降に実行するようにスケジュールすることによって、通常の営業時間における Sun Management Center サーバの負荷を下げることができます。また、 通常は午前 12:00 から午前 4:00 までの間にスケジュールされる Sun Management Center の夜間作業と Performance Reporting Manager の作業が競合する可能性も下げることができます。

性能に関する考慮事項

サーバレイヤの性能に影響を与える主な要因は次のとおりです。

Sun Management Center コンポーネントの同時起動

サーバレイヤと多数のエージェントの同時起動は、サーバレイヤの性能に悪影響を与える可能性があります。また、何百ものエージェントを管理するサーバレイヤを初期化すると、コンソールの応答速度が低下したり、一時的に一部のエージェントにアクセスできなくなったりする可能性があります。

トポロジグループの構成

Sun Management Center サーバコンテキスト内のトポロジグループの数は、次の値を超えてはなりません。

管理作業

Sun Management Center サーバの活動は、次の要因によって変わります。

最後の 2 つの要因は、管理対象ノードがイベント処理の形で管理アクティビティを生成する傾向を大いに促します。

結果として、アラームしきい値を適切に構成していない場合、アドオンが存在しなくても、かなりの管理作業が発生する可能性があります。逆にいえば、管理対象システムが安定したものでアラームしきい値も適切であれば、多数のアドオンが存在しても管理作業はわずかしか発生しない場合があります。

コンソールユーザの数

Sun Management Center の同時コンソールユーザセッションが増えると、サーバレイヤの負荷がわずかに高まります。ここで、ア クティブなユーザは、小規模構成の場合は 5 人、中規模構成の場合は 10 人、大規模および超大規模構成の場合は 15 人であることを想定します。また、ユーザが実行しているアクティビティーは、管理されたプロパティデータおよびイベントのブラウズや、データプロパティの属性の編集などであることを想定します。

ユーザによって開始される作業の中には、処理が実行される間サーバレイヤのパフォーマンスに一時的に影響を与えるものがあります。

ユーザによって開始されるこれらのアクションの影響は、同時実行を避ける、大規模のオペレーションを細分化する、可能であれば ピーク時以外に作業を行う (あるいはスケジューリングする) などの方法で最小限に抑えることができます。