サーバーレイヤーは、Sun Management Center ソフトウェアの中核です。サーバーレイヤーのホストに適切なハードウェアを指定することは、Sun Management Center において応答性に優れた確実な処理を実現する上で重要な意味を持ちます。Sun Management Center サーバーレイヤーのハードウェア要件は、エージェントの要件よりもはるかに厳しいものです。Sun Management Center 3.6 サーバーレイヤーのシステム要件は、Sun Management Center2.x および 3.0 サーバーレイヤーのハードウェア要件よりも厳しいものです。Version 2.x または 3.0 サーバーホストは、必ずしも Sun Management Center 3.6 のシステム要件を満たしていません。
Sun Management Center サーバーレイヤーは、Solaris バージョン 8 かバージョン 9、バージョン 10 を使用している SPARC プラットフォームデスクトップとサーバーのうち、この節で説明している最小のハードウェア要件を満たすマシンでサポートされます。
最大限のパフォーマンスを得るためには、サーバーレイヤーのアプリケーションだけを実行する専用マシンに Sun Management Center 3.6 サーバーレイヤーをインストールしてください。
次の表に、Sun Management Center サーバーのプラットフォームとして使用できるマシンの 4 つのクラスとそのハードウェア構成を示します。各ケースとも、代替マシン構成で同等のパフォーマンスを提供できます。
表 C–4 Sun Management Center サーバーとして推奨されるハードウェアプラットフォーム
アーキテクチャ |
マシンの種類 |
CPU タイプ |
RAM |
スワップ領域 |
---|---|---|---|---|
小型サーバー |
Sun Blade 100 (または同等のマシン) |
502 MHz UltraSPARC IIe CPU (またはこれ以上) x 1 |
1G バイト |
最小 512M バイト、1G バイトを推奨 |
中型サーバー |
Sun Fire 280R |
750 MHz UltraSPARC II CPU (またはこれ以上) x 2 |
1G バイト |
最小 512M バイト、1G バイトを推奨 |
大型サーバー |
Sun Blade 2000 |
1015 Mhz UltraSPARC III CPU (またはこれ以上) x 2 |
1G バイト |
最小 512M バイト、1G バイトを推奨 |
超大型サーバー |
Sun Fire 880 |
900 Mhz UltraSPARC III CPU (またはこれ以上) x 4 |
2G バイト |
1G バイト |
Sun Management Server のホストサイジング要件は、サーバーレイヤーで管理されるエージェントの数とそれらのエージェント上の管理作業に大いに左右されます。管理作業には、システムによって生成される作業 (イベント生成など) とユーザーによって開始される作業 (データのブラウジング、ネットワーク検出、グループ処理、システム監視および診断など) があります。
管理作業の影響のため、サイジング要件は、サーバーにインストールされている Sun Management Center アドオンパッケージの数、種類、および構成、そして管理ノード の数によって変わります。一般には、使用中のアドオンの数が多いほど管理作業の量が多く、サーバーのハードウェア要件も厳しくなります。
次の図に、Sun Management Center サーバーとして推奨されるマシンのクラスを、管理対象となるエージェント数とおおよその管理作業の関数として示します。この図では、サーバー上で Sun Management Center コンソールが動作していないことを前提にしています。また、小型サーバーの場合は 5 個の遠隔コンソールセッション、中型サーバーの場合は 10 個の遠隔コンソールセッション、また大型サーバーと超大型サーバーの場合は 15 個の遠隔コンソールセッションが存在するものとします。
上図に示したマシンのクラスは、同様な性能を持つホストの代表的なクラスを示します。
Sun Management Center コンソールアプリケーションをサーバーレイヤーホスト上で実行することによって、サーバーは性能に影響を受けます。さらに、この影響はアクティブなコンソールセッションの数によっても変わります。サーバーホストがサーバーレイヤーコンポーネントをサポートできる余裕がない場合は、Sun Management Center コンソールをサーバーマシンで実行しないでください。
Sun Management Center の Performance Reporting Manager (PRM) アドオンを使用すると、Sun Management Center Center エージェントが監視している任意のデータプロパティに関して、その履歴的な傾向を追跡したり、レポートを生成したりできます。PRM アドオンは大量のデータを収集および処理できるので、Sun Management Center サーバーのサイジング要件に大きな影響を与える可能性があります。
PRM アドオンの影響は、図 C–1 の PRM 部分に示されています。一般的に、管理作業と PRM が追跡するデータープロパティの総数が増えるほど、Sun Management Center サーバーが管理できるエージェント数は減ります。
PRM アドオンを持つ Sun Management Center サーバーの要件を判断するには、2 つのステップが必要です。
図 C–1 を参照しながら、PRM アドオンがインストールされている Sun Management Center サーバーが管理するエージェントの総数にもとづいて、必要なマシンのクラスを判断します。
収集する PRM データプロパティのおおよその数にもとづいて、適切な PRM 構成を判断します (次項を参照)。
Sun Management Center の設定では、次の表に示す PRM 構成の種類のから 1 つを選択することができます。「アーキテクチャ」列は、表 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 |
24G バイト |
240,000 |
600 |
300 |
大 |
|
|
|
750 |
300 |
超大 |
通常、Sun Management Center の小型サーバーは小型 PRM 構成に使用されます。中型サーバーは中型 PRM 構成に使用されます。そして、大型サーバーと超大型サーバーは大型 PRM 構成に使用されます。Sun Management Center の超大型サーバーは小型 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 時間 |
さまざまなエージェント数、データプロパティ数、およびレポート期間 (4 時間から 1 か月など) を指定することによって、さまざまなレポートを生成できます。
通常のレポートは、生成するには数秒から数分かかります。実際にかかる時間は、次の要因によって変わります。
レポートに含める実際のデータポイント数
データポイントの最大数はレポート 1 つあたり約 10,000 個です。
データベース内にある Performance Reporting Manager のデータ数
サーバーの性能と活動
ほかの Performance Reporting Manager レポートと一緒に生成しているかどうか
たとえば、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 バイトのスワップ領域を持つ SunFire-280R を想定しています。また、この SunFire-280R は Performance Reporting Manager 用に 300 個のエージェントを監視しており、エージェントごとに 300 個のデータプロパティを収集するものとします。
レポートを生成するのに 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 サーバーコンテキスト内のトポロジグループの数が、次の値を超えてはいけません。
小型サーバーの場合 - 25
中型サーバーの場合 - 50
大型サーバーの場合 - 75
トポロジグループのすぐ下の子オブジェクトの最大数は 256 個です。最適な性能を維持するには、トポロジグループの子オブジェクトの数が 100 を超えてはなりません。
Performance Reporting Manager アドオンをインストールしている場合、Performance Reporting Manager がデータを最適収集ができるようにするには、各トポロジドメインの Sun Management Center エージェント数が 200 を超えないようにします。
Sun Management Center サーバーの活動は、次の要因によって変わります。
ユーザーが開始する処理の数
管理対象となるホストシステムの安定性とアクティビティ
ホストシステムによって読み込まれる管理モジュールの数
アラームしきい値の指定と管理対象となるプロパティのルールパラメータ
最後の 2 つの要因は、管理対象ノードがイベント処理の形で管理アクティビティを生成する傾向を大いに促します。
結果として、アラームしきい値を適切に構成していない場合、アドオンが存在しなくても、かなりの管理作業が発生する可能性があります。 逆にいえば、管理対象システムが安定したものでアラームしきい値も適切であれば、多数のアドオンが存在しても管理作業はわずかしか発生しない場合があります。
Sun Management Center の同時コンソールユーザーセッションが増えると、サーバーレイヤーの負荷がわずかに高まります。ここで、アクティブなユーザーは、小規模構成の場合は 5 人、中規模構成の場合は 10 人、大規模および超大規模構成の場合は 15 人であると仮定します。 また、ユーザーが実行している活動は、管理されたプロパティデータおよびイベントのブラウズや、データプロパティの属性の編集などであるとします。
ユーザーによって開始される作業の中には、処理が実行される間サーバーレイヤーのパフォーマンスに一時的に影響を与えるものがあります。
100 個以上のエージェントを対象とした「大規模なグループ操作」の場合は、相当のサーバーリソースを消費する可能性があります。このような操作は、変更によって管理対象エージェントでアラームが生成されるとサーバーパフォーマンスにさらに影響を与える可能性があります。これらのアラームは、またイベント処理という形で追加の管理活動を生みます。
サーバーの管理対象にする新しいエンティティを多数追加する処理を伴う「ネットワーク検出操作」を行うと、その処理中にサーバーレイヤーホストに相当の負荷を与える可能性があります。
管理対象となる新しいエンティティを多数追加する処理を伴うトポロジデータのインポート操作を行うと、エンティティの追加中にサーバーレイヤーの応答速度が低下する可能性があります。
ユーザーによって開始されるこれらの操作の影響は、同時実行を避ける、大規模のオペレーションを細分化する、可能であれば ピーク時以外に作業を行う (あるいはスケジューリングする) などの方法で最小限に抑えることができます。