この付録では、Sun Management Center の基本管理フレームワークとベースアドオン製品に適切なハードウェアを選択するためのガイドラインを示します。Sun Management Center の基本管理フレームワークと各ベースアドオン製品をインストールするには、Sun Management Center の中核レイヤであるエージェント、サーバ、およびコンソールに特定のディスク容量が必要です。
この章の内容は次のとおりです。
この節の内容は、サン以外のモジュールを考慮したものではありません。また、サイズ情報を示した図表にもサン以外のモジュールは含められていません。
高度な管理および 監視機能を確立するには、ネットワーク内のすべての管理対象ノードに Sun Management Center 3.5 エージェントをインストールする必要があります。Sun Management Center エージェントは、Solaris バージョン 2.6、Solaris バージョン 7、Solaris バージョン 8、または Solaris バージョン 9 が動作するすべての SPARC プラットフォームワークステーションおよびサーバでサポートされます。Sun Management Center エージェントは、Solaris オペレーティング環境の x86 Platform Edition システムと Microsoft Windows システムでは利用できません。
Sun Management Center エージェントがホストシステムに与える演算負荷は、最低限のものです。演算負荷は、定期的なデータ収集、アラーム規則の処理、アラーム予告、アラームアクションの実行、クライアント要求の処理といった通常の管理オペレーションによって引き起こされます。
負荷の量は、データの収集の頻度、収集されるデータ量、検出されるアラームの数、ユーザ要求の数などに比例します。したがって、消費される CPU リソースの割合は、システムに読み込まれるモジュールの数と種類、これらのモジュールの構成、およびホストシステムの演算能力によって決まります。
総合的なモジュールセットが読み込まれた、管理処理の多いローエンドマシンの場合でも、エージェントは CPU リソースのごく一部しか消費しません。
次の表に、CPU 使用率と RAM 使用率の概算を示します。
表 C–1 各システムにおけるエージェントの CPU と RAM の概算使用率
サーバの種類 |
構成 |
CPU 使用率 |
RAM の使用率 (平均) |
|||
---|---|---|---|---|---|---|
重いまたは軽い |
最大 |
最小 |
平均 |
サイズ |
常駐サイズ |
|
Netra X1 |
軽い |
16.3% |
0.0% |
0.09% |
12M バイト |
10M バイト |
Sun Enterprise 420R |
軽い |
14.3% |
0.0% |
0.13% |
15M バイト |
14M バイト |
Sun Blade 1000 |
軽い |
0.3% |
0.0% |
0.03% |
17M バイト |
16M バイト |
Sun Blade 100 |
重い |
14.0% |
0.2% |
8.9% |
29M バイト |
29M バイト |
構成が軽いサーバは、以下のモジュールが読み込まれたエージェントをベースとしています。
カーネルリーダ (簡易)
エージェント統計情報
MIB-II システム (簡易)
構成が重いサーバは、以下のモジュールが読み込まれたエージェントをベースとしています。
|
|
構成が重いサーバは、必要以上の規模となる可能性があります。マシンのサイズが大きいほど一般にプロセッサとディスクが増え、ハードウェア構成が大きくなります。これらの構成では、大規模マシンで動作するエージェントのメモリ消費量が多大なものとなります。
エージェントが使用する仮想メモリは、いくつかの要因によって決まります。とりわけ重要なのは、読み込まれる管理モジュールの数と、それらのモジュールによって監視される情報の量です。1 つのエージェントに多数のモジュールを読み込む場合は、必要となるメモリが増えます。同様に、大規模ディスクアレイを始めとする拡張性の高い資産を抱えるホストを管理するエージェントの場合、より多くの仮想メモリを必要とします。これは、エージェントを通して渡される管理情報の量が増えるためです。
一般に、デフォルトの管理モジュールセットが読み込まれたベースエージェントはサイズが 10M バイト未満であり、 物理メモリ内に常駐させる必要があるのは、10M バイトのうちのわずか 50 から 60 %です。
Sun Management Center 管理モジュールのほとんどは、Sun Management Center エージェントを使用したあらゆる SPARC プラットフォームシステム間で移植できます。しかし、ハードウェア固有の高度な Sun Management Center モジュールの中には一部の Sun ハードウェアでサポートされていないものがあります。たとえば、プラットフォームに付属の構成リーダモジュールや動的再構成 (DR) モジュールはそのハードウェアプラットフォームを管理する高度な機能を提供しますが、それらのモジュールの機能が Sun 製品ファミリ内のあらゆるハードウェアシステムに適用できるとはかぎりません。
次の表に、各ハードウェア プラットフォームにおける Sun Management Center 管理モジュールの可用性を簡単に示します。
表 C–2 ハードウェア固有モジュールの可用性
ハードウェア |
構成リーダモジュール |
動的再構成 (DR) モジュール |
その他のすべての Sun Management Center モジュール |
---|---|---|---|
SPARCStation 1、2、5、10、20 |
不可 |
不可 |
可 |
Sun Ultra 1、2、5、10、30、60、80 |
可 |
不可 |
可 |
Sun Enterprise 5、10、150、250、450、220R、420R、Sun Fire 280R、Sun Fire V480 |
可 |
不可 |
可 |
SPARCserver 1000、1000E |
可 |
不可 |
可 |
SPARCcenter 2000、2000E |
可 |
不可 |
可 |
Sun Enterprise 3x00、4x00、5x00、6x000 |
可 |
可 |
可 |
Sun Enterprise 10000 |
可 |
不可 |
可 |
Sun StorEdge A5x00、T3 |
可 |
不可 |
可 |
Netra T1、T1120-1125、T1400-T1405 |
可 |
不可 |
可 |
Sun Blade 100、1000 |
可 |
不可 |
可 |
Sun Fire、3800、4800、4810、6800、V880 |
可 |
可 |
可 |
管理モジュールのリソース要件は、以下の要因によって決まります。
モジュールにおける管理対象プロパティの数
モジュール内で処理される管理対象プロパティデータの量。データ行の多いテーブルを使用すると、リソース利用率が増加します。
管理対象プロパティの更新頻度
データ収集とルール処理の複雑さ
次の表に、Sun Management Center 管理モジュールのリソース影響について概要を示します。
表 C–3 Sun Management Center 管理モジュールのシステムに対する影響
サーバレイヤは、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 個の遠隔コンソールセッションが存在することを想定します。
上記図に示したマシンのクラスは、同様な性能を持つホストの代表的なクラスを示します。
Sun Management Center コンソールアプリケーションをサーバレイヤホスト上で実行することによって、サーバは性能に影響を受けます。さらに、この影響はアクティブなコンソールセッションの数によっても変わります。サーバホストがサーバレイヤコンポーネントをサポートできる余裕がない場合、Sun Management Center コンソールをサーバマシンで実行してはなりません。
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 つの手順が必要です。
PRM アドオンがインストールされている Sun Management Center サーバが管理するエージェントの総数にもとづいて、図 C–1の 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 ごとに平均 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 か月など) を指定することによって、さまざまなレポートを生成できます。
通常のレポートを生成するには、数秒から数分かかります。実際にかかる時間は、次の要因によって変わります。
レポートに入れる実際のデータポイント数
データポイントの最大数はレポートごとに約 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 バイトのスワップ領域を持つ Ultra-80 のことであることを想定します。また、Ultra-80 は 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 個以上のエージェントを対象とした大規模グループオペレーションの場合、相当のサーバリソースを消費する可能性があります。このようなオペレーションは、変更によって管理対象エージェントでアラームが生成されるとサーバパフォーマンスにさらに影響を与える可能性があります。これらのアラームは、イベント処理という形で管理アクティビティをさらに発生させます。
サーバの管理対象となる新しいエンティティを多数追加する処理を伴うネットワーク検出作業を行うと、その処理中にサーバレイヤホストに相当の負荷を与える可能性があります。
管理対象となる新しいエンティティを多数追加する処理を伴うトポロジデータのインポート作業を行うと、エンティティの追加中にサーバレイヤの応答速度が低下する可能性があります。
ユーザによって開始されるこれらのアクションの影響は、同時実行を避ける、大規模のオペレーションを細分化する、可能であれば ピーク時以外に作業を行う (あるいはスケジューリングする) などの方法で最小限に抑えることができます。
パフォーマンスを最大限に高めるには、Sun Management Center コンソールをサーバレイヤホスト以外のホストから実行する必要があります。コンソールは任意のホストに簡単にインストールでき、サーバレイヤへリモート接続できます。サーバレイヤ構成として望ましいのは、ホストシステムをサーバレイヤアプリケーションの実行専用として使用することです。サーバホストのサイズがほかのアプリケーション (Sun Management Center コンソールなど) の要件をサポートできるものでないかぎり、サーバホストでそれらを実行することは避ける必要があります。
Sun Management Center コンソールは、Java 技術をベースとしたアプリケーションです。コンソールは、Solaris 2.6、Solaris 7、Solaris 8、または Solaris 9 オペレーティング環境が動作する SPARC プラットフォームシステムでサポートされます。コンソールはまた、Microsoft Windows 2000、Service Pack 3 または 4 をインストールした Windows NT 4.0、または Microsoft Windows 98 が動作する Intel システムでもサポートされます。
Sun Fire プラットフォームエージェントは、標準の Sun Management Center エージェントとは異なるインストール作業を必要とします。Sun Fire プラットフォームにはいくつかのドメインがあり、各ドメインには独自のハードウェア割り当てが行われています。各ドメインは Solaris オペレーティング環境のインスタンスを個別に実行します。各 Sun Fire ドメインは、ドメインエージェントを実行します。
全体として見た Sun Fire プラットフォームは、ドメインに割り当てられた、そのプラットフォーム内のすべてのハードウェアから構成されていることになります。プラットフォームは、そのプラットフォーム内の System Controller (SC) ボードによって制御されます。
Sun Management Center ソフトウェアは、Sun Fire サーバを管理するために Sun Fire サーバシステムコントローラおよび Sun Fire ドメインエージェントと通信を行う Sun Fire プラットフォームエージェントを使用します。このプラットフォームエージェントは、エージェントによって監視される、Sun Fire シャーシの外部に存在する Solaris ホストに導入する必要があります。プラットフォームエージェントホストシステムが適切にサイズ設定されていれば、単一のホストシステムに複数のプラットフォームエージェントを導入して複数の Sun Fire サーバを管理できます。
各プラットフォームエージェントは、平均して 5 から 9% の CPU と 15 から 18M バイトのメモリを消費します。同じホストシステム上に導入されたプラットフォームエージェントの CPU とメモリの消費は加法的で、ハードウェア要件を測る尺度として使用できます。エージェントは同じソフトウェアパッケージを共有するため、プラットフォームエージェントインスタンスが複数存在する場合のディスク容量要件は、少なくとも単一のプラットフォームエージェントインスタンスの場合の要件を超えます。
一般に、プラットフォームエージェントの CPU とメモリのリソース要件は管理対象となっている Sun Fire サーバ構成のサイズと複雑さに比例します。Sun Fire システムの構成が大きいほど、プラットフォームエージェントホスト上のプラットフォームエージェントリソースをより多く必要とします。
プラットフォームエージェントは、次に示すどちらのホストにもインストールできます。
Sun Management Center サーバレイヤホスト
Sun Management Center 専用のプラットフォームエージェントホスト
個々のホスト上にインストールできるプラットフォームエージェントの数は、そのホストが Sun Management Center サーバレイヤホストであるかプラットフォームエージェントレイヤホストであるかによって異なります。Sun Management Center の全体的なパフォーマンスと応答性を最大限に高めるには、サーバレイヤホストではなく専用のホストにプラットフォームエージェントを導入する必要があります。容量に余裕のあるマルチ CPU システムにサーバレイヤが導入されている場合は、プラットフォームエージェントをサーバレイヤホストで稼動させることができます。
次の図に、専用のプラットフォームエージェントホストへ導入した場合のアーキテクチャとサーバレイヤホストに導入した場合を示します。
Sun Fire プラットフォームエージェントは、デフォルトでは 1 時間ごとに管理情報を最新状態に更新します。同じホストに複数のプラットフォームエージェントが導入され、同時に初期化される場合、エージェントは立て続けにデータ更新をする傾向があります。同時更新を試みるプラットフォームエージェントが多すぎると、ホストシステムの全体的な応答性が悪影響を受けかねません。
同じホスト上の複数のプラットフォームエージェントによる同時オペレーションの可能性を減らすには、すべてのプラットフォームエージェントを同時に起動しないことです。
次の表に、一般的なハードウェア構成と、専用のホストシステムに導入できるプラットフォームエージェントの数を示します。
表 C–7 専用ホスト: Sun Fire プラットフォームエージェントの容量
代表的なハードウェア構成 |
プラットフォームエージェントの最大数 |
---|---|
シングル 500 MHz UltraSPARC IIe CPU、1G バイト RAM、1G バイトスワップを使用した Netra X1、Netra T1、または Sun Blade 100 |
5 〜 7 |
デュアル 450 MHz UltraSPARC II CPU、1G バイト RAM、1G バイトスワップを使用した Sun Enterprise 420R または Ultra 60 |
11 〜 15 |
デュアル 750 MHz UltraSPARC III CPU、1G バイト RAM、1G バイトスワップを使用した Sun Fire 280R、Netra T4、または Sun Blade 1000 |
14 〜 20 |
プラットフォームエージェントのリソース使用はさまざまに異なります。この表では、オペレーションのピーク時にシステム容量が不足しないように十分な容量を残すことができる許容値の範囲を示しています。Sun Fire プラットフォームの規模が大きいほど必要となるプラットフォームエージェントリソースも増えるため、単一のホストで実行できるプラットフォームエージェントはわずかとなります。逆に、Sun Fire プラットフォームが小さいほど必要となるプラットフォームエージェントリソースは少なくてすみ、単一のホストで多くのプラットフォームエージェントを実行できます。
Sun Management Center サーバレイヤを実行するホストシステムのハードウェアサイズ要件は、サーバレイヤによって管理されるプラットフォームエージェントの数とシステム内の管理アクティビティによって決まります。
Sun Management Center サーバレイヤと Sun Fire プラットフォームエージェント双方の稼動に対応できるのは、大規模のマルチ CPU システムの場合だけです。容量が小さいサーバレイヤホストにプラットフォームエージェントを導入すると、Sun Management Center の全体的なパフォーマンスに悪影響を与える可能性があります。
1 日にホスト当たりで 1000 個未満のイベントに対応する適度なレベルの管理アクティビティの場合、Sun Management Center サーバレイヤホストに導入できるプラットフォームエージェントの最大数は管理対象となるエージェントの数とマシンクラスによって決まります。次の表に、一般的なシステム容量を示します。
表 C–8 サーバレイヤホスト: Sun Fire プラットフォームエージェントの容量
管理対象エージェントの数 |
プラットフォームエージェントの最大数 |
|
---|---|---|
Sun Enterprise 420R |
Sun Fire 280R |
|
100 |
6 |
7 |
300 |
5 |
7 |
500 |
4 |
6 |
750 |
利用不可 |
6 |
Sun Enterprise 420Rは、1G バイト RAM と 1G バイトスワップを使用したデュアル 450MHz UltraSPARC-II サーバレイヤホストを持つ Enterprise 420R または Ultra 60 システムを示します。
Sun Fire 280Rは、1G バイト RAM と 1G バイトスワップを使用したデュアル 750MHz UltraSPARC III サーバホストを持つ Sun Fire 280R、Sun Blade 1000、または Netra T4 システムを示します。
Sun Fire Sun Management Center インストールの手順については、『Sun Management Center 3.5 Software Supplement for Sun Fire 6800/4810/4800/3800 Systems』を参照してください。