This appendix provides guidelines for selecting the appropriately sized hardware for the Sun Management Center basic management framework and base add-on products. The Sun Management Center basic management framework and each base add-on product have specific disk space requirements for the Sun Management Center core layers agent, server, and console.
This chapter discusses the following topics:
The information provided in this section does not take into consideration any third-party modules, nor are such modules reflected in any of the sizing figures.
Sun Management Center 3.6 agents should be installed on every managed node in your network to enable advanced management and monitoring functions. Sun Management Center agents are supported on any SPARC platform workstations and servers running Solaris version 2.6, Solaris version 7, Solaris version 8, Solaris version 9, or Solaris version 10. Sun Management Center agents are also available for Solaris operating system (x86 Platform Edition) systems running Solaris 9 and Solaris 10 and on Linux.
The same limitations apply for the Linux agent.
The x86 agents do not support any hardware-specific add-ons. The x86 agents have modules under the Operating System, Local Applications, and Remote Systems categories of the Module Browser tab in the Host Details window. Features such as Physical View, Logical View, Hardware Diagnostic module, and the Config-Reader module are not yet available on the Solaris x86 platform.
In the Java Console window, all x86 platforms have the same x86 icon. For example, two different x86 platform machines, such as the Sun Cobalt LX50 and the Sun Fire V60x, would both have the same icon.
You can filter by platform type when you use the Discovery feature, the Manage Jobs feature, or the PRM add-on. You can filter for the x86 platform by selecting x86 as the platform option.
For the Performance Reporting Manager (PRM) add-on, no system reports and hardware configuration reports are available.
Sun Management Center agents add a minimal computational load on the host system. The computational load is caused by normal management operations, including periodic data acquisition, alarm rule processing, alarm annunciation, alarm action execution, and the processing of client requests.
The amount of load introduced is proportional to the rate at which data is gathered, the amount of data gathered, the number of alarms detected, and the number of user requests. The percentage of CPU resources consumed therefore depends on the number and type of modules loaded on the system, the configuration of these modules, and the computational capacity of the host system.
Even on low-end machines with a comprehensive suite of modules loaded and high management activity, the agent should never consume more than a fraction of the CPU resources.
The following table gives estimates of the agent CPU and RAM usage by system type and includes information for the x86 agent.
Table C–1 Agent CPU and RAM Use Estimates by System Type
|
CPU Usage |
RAM Usage |
|
|
|
|
---|---|---|---|---|---|---|
Server Type |
Heavy or Light Configuration |
Maximum |
Minimum |
Average |
Average Size |
Average Resident Size |
Sun Blade 100 |
Light |
0.10% |
0.00% |
0.21% |
8.77 Mbytes |
7.02 Mbytes |
Sun Fire 280R |
Light |
0.10% |
0.00% |
0.10% |
10.47 Mbytes |
8.49 Mbytes |
Sun Blade 2000 |
Light |
0.20% |
0.00% |
0.05% |
8.89 Mbytes |
7.06 Mbytes |
Sun Fire 880 |
Light |
0.00% |
0.00% |
0.00% |
8.97 Mbytes |
7.31 Mbytes |
Sun Blade 100 |
Heavy |
1.20% |
0.50% |
0.79% |
14.83 Mbytes |
12.99 Mbytes |
Sun Fire 280R |
Heavy |
2.60% |
0.10% |
0.81% |
16.22 Mbytes |
13.92 Mbytes |
Sun Blade 2000 |
Heavy |
0.30% |
0.20% |
0.20% |
14.45 Mbytes |
12.76 Mbytes |
Sun Fire 880 |
Heavy |
4.40% |
0.10% |
0.88% |
16.15 Mbytes |
14.41 Mbytes |
Light configurations are based on an agent with the following modules loaded:
Kernel-Reader Simple
Agent Statistics
MIB-II Simple
The heavy configuration is based on an agent with the following modules loaded:
The heavy configuration is likely to be greater than needed. Larger machines typically have larger hardware configurations with more processors and disks. These configurations result in greater memory consumption by agents running on larger machines.
The virtual memory used by an agent depends on multiple factors. The primary considerations are the number of management modules loaded and the amount of information being monitored by these modules. Loading many modules on an agent increases its memory requirement. Similarly, agents managing hosts with large disk arrays or other highly scalable assets will probably require more virtual memory because the volume of management information passing through the agents will increase.
In general, a base agent with the default set of management modules loaded is under 10 Mbytes in size. The base agent requires only 50% to 60% of the 10 Mbytes to be resident in physical memory.
The majority of Sun Management Center management modules are portable across all SPARC platform systems running Sun Management Center agents. Some advanced hardware-specific Sun Management Center modules, however, are not supported on all Sun hardware. Specifically, the platform Config-Reader and Dynamic Reconfiguration modules provide advanced management of the underlying hardware platform. The functions these modules provide are not necessarily applicable to all hardware systems in the Sun product family.
The following table summarizes the availability of the Sun Management Center management modules on the various hardware platforms.
Table C–2 Hardware-Specific Module Availability
Hardware |
Config-Reader Module |
Dynamic Reconfiguration Module |
All Other Sun Management Center Modules |
---|---|---|---|
SPARCStation 1, 2, 5, 10, 20 |
No |
No |
Yes |
Sun Ultra 1, 450 |
Yes |
No |
Yes |
Sun Enterprise 5, 10, 150, Sun Fire 280R, Sun Fire V480 |
Yes |
No |
Yes |
SPARCserver 1000, 1000E |
Yes |
No |
Yes |
SPARCcenter 2000, 2000E |
Yes |
No |
Yes |
Sun StorEdge A5x00, T3 |
Yes |
No |
Yes |
Netra T1120-1125, T1400-T1405 |
Yes |
No |
Yes |
Sun Blade 100, 1000, 1500, 2500 |
Yes |
No |
Yes |
Sun Fire 3800, 4800, 4810, 6800, V210, V240, V250, V440, V880, E25K, E20K, E6900, E4900 |
Yes |
Yes |
Yes |
The resource requirements of management modules depend on the following factors:
The number of managed properties in the module.
The volume of managed property data processed in the module. Tables with many rows of data incur increased resource usage.
The refresh intervals of managed properties.
The complexity of data collection and rule processing.
The following table summarizes the resource impact of the Sun Management Center management modules.
Table C–3 Sun Management Center Management Module System Impact Summary
Module |
Impact |
---|---|
Incurs low footprint increase and low CPU load increase. |
|
Uses CPU and memory relative to the complexity of the hardware configuration of the managed node. |
|
Incurs low footprint and CPU load increase that is proportional to the amount of data values being logged. |
|
Incurs a low footprint increase that is proportional to the number of directories monitored. Incurs low to moderate CPU load that depends on both the number of directories monitored and the activity within those directories. |
|
Dynamic Reconfiguration |
Has minimal footprint impact and utilizes CPU only when performing reconfiguration operations. |
Incurs low footprint increase proportional to the number of files that are monitored. Incurs low to moderate CPU load, depending on both the number of files that are monitored and the activity within those files. |
|
Incurs low footprint and CPU load increase. |
|
Has relatively low impact on resources. |
|
Incurs low footprint increase and low CPU load. |
|
Incurs low CPU load increase and low to medium footprint increase dependent on the number of network interfaces. |
|
Affects CPU and memory based on the number of file systems, CPUs, and other system resources under management, as well as the rate of refresh of this information. Consumes more resources than the Simple Kernel Reader. |
|
Kernel Reader, Simple |
Has minimal impact on CPU and memory. |
Incurs minimal CPU load and low to moderate footprint increase depending on the number of network interfaces, and the size of the routing tables, ARP tables, and related system tables. |
|
MIB-II Proxy Monitoring |
Incurs moderate footprint increase proportional to the size of the MIB of the proxy-monitored SNMP agent. Incurs low to moderate CPU load proportional to the number of managed objects in the proxy-monitored SNMP agent. |
Incurs virtually no CPU load and very little footprint increase, proportional to the size of the system interfaces, IP forwarding, and IP address table. |
|
Incurs low footprint increase that is proportional to the number of network file systems mounted on the host machine, and low CPU load. |
|
Incurs low footprint increase and low to moderate CPU load. |
|
Incurs low footprint and CPU load increase. |
|
Incurs low footprint increase that is proportional to the number of processes monitored. Incurs low to moderate CPU load, depending both on the number of processes monitored and how often the processes are started and stopped. |
|
Incurs moderate footprint and load increase that is proportional to the size of the storage device. |
The server layer is the core of the Sun Management Center software. The specification of appropriate hardware for the server layer host is critical to ensure the reliable and responsive operation of Sun Management Center. The hardware requirements for the Sun Management Center server layer are significantly greater than the requirement for agents. Sun Management Center 3.6 server layer system requirements are greater than the hardware requirements for Sun Management Center 2.x and 3.0 server layers. Version 2.x or 3.0 server hosts do not necessarily meet the Sun Management Center 3.6 system requirements.
The Sun Management Center server layer is supported on SPARC platform desktops and servers running on Solaris version 8, version 9, or version 10, that meet the minimum hardware requirements described in this section.
For the best performance, install the Sun Management Center 3.6 server layer on a dedicated machine running server layer applications only.
The hardware systems specified in the following table represent four broad classes of machines that can be employed as Sun Management Center server platforms. In each case, alternate machine configurations could provide equivalent performance.
Table C–4 Recommended Sun Management Center Server Hardware Platforms
Architecture |
Machine Type |
CPU Type |
RAM |
Swap Space |
---|---|---|---|---|
Small server |
Sun Blade 100 or equivalent |
One 502 MHz UltraSPARC IIe CPU or better |
1 Gbyte |
512 minimum, 1 Gbyte recommended |
Medium server |
Sun Fire 280R |
Two 750 MHz UltraSPARC II CPUs or better |
1 Gbyte |
512 minimum, 1 Gbyte recommended |
Large server |
Sun Blade 2000 |
Two 1015 Mhz UltraSPARC III CPUs or betterr |
1 Gbyte |
512 minimum, 1 Gbyte recommended |
Extra-large server |
Sun Fire 880 |
Four 900 Mhz UltraSPARC III CPUs or better |
2 Gbytes |
1 Gbyte |
The Sun Management Server host sizing requirements are highly dependent on the number of agents being managed by the server layer and the management activity on these agents. Management activity consists of system-generated activity such as event generation and processing, and user-initiated operations such as browsing data, network discovery, group operations, and system monitoring and diagnosis.
Because of the impact of management activity, the sizing requirements depends on the number, type and configuration of all Sun Management Center add-on packages that are installed on the server, and on the number of managed nodes. In general, the more add-ons that are in use, the greater the management activity and the higher the server hardware requirements.
The following diagram shows the machine classes recommended for the Sun Management Center server as a function of the number of agents under management, and the estimated management activity. The diagram assumes that Sun Management Center consoles are not running on the server machine. The diagram also assumes that there are 5 remote console sessions for the small server; 10 remote console sessions for the medium server; and 15 remote console sessions for the large and extra large server.
The machine classes depicted in the above diagram are representative of classes of hosts with similar performance.
Server performance is adversely affected by running the Sun Management Center console application on the server layer host and by the number of active console sessions. If the server host is not sized generously to support the server layer components, do not run Sun Management Center consoles on the server machine.
The Sun Management Center performance reporting manager (PRM) add-on is used to track historical trends and generate reports for any data property being monitored by Sun Management Center agents. The PRM add-on can have a significant impact on the sizing requirements of the Sun Management Center server since it can involve the collection and processing of large volumes of data.
The impact of the PRM add-on is shown in the PRM segment of Figure C–1. In general, increasing the management activity and the total number of data properties being tracked by PRM reduces the number of agents that can be managed by the Sun Management Center server.
Determining the requirements for a Sun Management Center server with the PRM add-on requires two steps.
Based on the total number of agents to be managed by Sun Management Center server with the PRM add-on installed, refer to the PRM segment of Figure C–1 to determine the required machine class.
Based on the estimated number of PRM data properties you want to collect, determine the appropriate PRM configuration as described in the following section.
During Sun Management Center setup, you are given the option to select one of the PRM configuration types shown in the following table. The architecture column refers to the machine architecture listed in Table C–4.
Table C–5 PRM Configuration Type Requirements
PRM Configuration Type |
Disk Space |
Total Number of PRM Properties |
Example Number of agents |
Example Number of properties per agent |
Architecture |
---|---|---|---|---|---|
Small PRM |
5 Gbytes |
50,000 |
100 |
300 |
Small |
|
|
|
400 |
100 |
Medium |
Medium PRM |
12 Gbytes |
150,000 |
300 |
300 |
Medium |
|
|
|
500 |
300 |
Large |
|
|
|
750 |
200 |
Extra large |
Large PRM |
24 Gbytes |
240,000 |
600 |
300 |
Large |
|
|
|
750 |
300 |
Extra large |
Small Sun Management Center servers are typically used for a small PRM configuration; medium servers are used for a medium PRM configuration; and large and extra large servers are used for a large PRM configuration. You can use an extra large Sun Management Center server with a small or medium PRM, depending on the available disk space and anticipated PRM data collection requirements.
The following table provides examples of the numbers of agents that can be managed by each architecture type, assuming that each agent is collecting an average of 300 properties each for PRM. The Hourly Data Collection provides the estimated time required to collect data. The Nightly Processing column provides the estimated time to process the collected data. The duration of the data collection and subsequent processing depends on the server hardware, the server activity, and the amount of PRM data in the database.
Table C–6 Server Examples: Number of Agents under Management
Architecture |
Number of Agents |
Total Number of PRM Properties |
PRM Configuration Type |
Hourly Data Collection |
Nightly Processing |
---|---|---|---|---|---|
Small |
100 |
30,000 |
Small |
2 minutes |
1 to 2 hours |
Medium |
300 |
90,000 |
Medium |
7 minutes |
3 to 4 hours |
Large |
600 |
180,000 |
Large |
7 minutes |
3 to 6 hours |
Extra large |
750 |
225,000 |
Large |
6 minutes |
3 to 6 hours |
A wide range of reports can be generated by specifying different numbers of agents, numbers of data properties, and report durations such as 4 hours to 1 month.
Typical reports take a few seconds to several minutes to generate. The actual time required is affected by the following factors:
The number of actual data points included in the report
Reports are limited to a maximum of 10,000 data points per report.
Amount of performance reporting manager data in the database
Server performance and activity
Concurrent generation of other performance reporting manager reports
For example, on a medium Sun Management Center server configured with the performance reporting manager add-on, a relatively simple report that includes 5 properties for 1 agent over the last 24 hours can be generated in about 20 seconds. Conversely, a more substantial report that includes 5 properties for 5 agents over the last 7 days can take around 10 minutes to generate.
A medium Sun Management Center server with the performance reporting manager add-on is assumed to be a SunFire-280R with two 450 MHz UltraSPARC II CPUs, 1 GB RAM, and 1 GB swap. It is also assumed that the SunFire-280R is monitoring 300 agents and collecting 300 data properties per agent for the performance reporting manager.
If a report takes more than 30 minutes to generate, it is recommended that you schedule the report to run between 4:00 AM and 8:00 AM. Scheduling large reports to run after 4:00 AM reduces the load on the Sun Management Center server during normal business hours, and also can reduce the chance of conflicts with the nightly Sun Management Center and performance reporting manager tasks that typically occur between 12:00 AM and 4:00 AM.
Major factors that affect the server layer performance include:
Simultaneous startup of Sun Management Center components
Topology group configuration
Management activity
Number of console users
Simultaneous startup of the server layer and many agents can adversely affect server layer performance. The initialization of a server layer managing hundreds of agents can result in slow console response and the temporary inability to access some agents.
The number of topology groups in a Sun Management Center server context should not exceed the following:
Small servers - 25 topology groups
Medium servers - 50 topology groups
Large servers - 75 topology groups
Extra-large servers - 100 topology groups
The maximum number of immediate child objects in a topology group is 256. For optimal performance, the number of child objects in a group should not exceed 100.
If you install the Performance Reporting Manager add-on, each topology domain should contain less than 200 Sun Management Center agents to ensure optimal collection of Performance Reporting Manager data.
Sun Management Center server activity depends on the following factors:
The number of operations initiated by users
The stability and activity of the host systems under management
The number of management modules loaded by the host systems
The specification of alarm thresholds and rule parameters for properties under management
The last two factors greatly influence the tendency of the managed nodes to generate management activity in the form of event processing.
As a result, high management activity can occur with no add-ons if alarm thresholds are poorly configured. Conversely, low management activity can occur with many add-ons if the managed systems are stable and the alarm thresholds are reasonable.
Increasing the number of concurrent Sun Management Center console user sessions incurs a modest increase in load on the server layer. The sizing estimates assume 5 active users for a small configuration, 10 users for a medium configuration, and 15 users for a large and extra-large configuration. The sizing estimates assume the users are performing activities such a browsing managed property data and events and editing property attributes.
Some user-initiated actions might temporarily affect the performance of the server layer for the duration of the operation.
Large group operations that are targeted at 100 or more agents can consume significant server resources. These operations can further affect server performance if the changes generate alarms on the managed agents. These alarms produce additional management activity in the form of event processing.
Network discovery operations involving the addition of many new entities for the server to manage can incur noticeable load on the server layer host during the discovery process.
Topology data import operations involving the addition of many new entities to manage can result in slower response from the server layer while the entities are being added.
The effect of these user-initiated actions can be minimized by not executing these operations concurrently, by breaking up large operations, and, when possible, by performing or scheduling the operations during off-peak hours.
For the best performance, the Sun Management Center console should be run from a host other than the server layer host. The console can be readily installed on any host and used to connect to the server layer remotely. The recommended server layer configurations assume that the host system is dedicated to running server layer applications only. Running other applications such as the Sun Management Center console on the server layer host should be avoided unless the server host has been sized generously to support the additional requirements.
The Sun Management Center console is based on the Java technology. The console is supported on SPARC systems running the Solaris 2.6, Solaris 7, Solaris 8, Solaris 9, or Solaris 10 operating systems and x86 systems running Solaris 9 and Solaris 10. The console is also supported on Intel systems running Microsoft Windows 2000, Microsoft Windows NT 4.0 with Service Pack 3 or 4, Microsoft Windows 98, and Microsoft Windows XP.
Sun Fire platform agents require a different installation procedure than standard Sun Management Center agents. Sun Fire platforms contain a number of domains, each domain with its own hardware allocation. Each domain runs a separate Solaris operating environment instance. Each of the Sun Fire domains runs a domain agent.
The Sun Fire platform as a whole consists of all the hardware in the platform allocated to the domains. The platform is controlled by a System Controller (SC) board within the platform.
To manage Sun Fire servers, Sun Management Center software uses Sun Fire platform agents that interact with the Sun Fire server system controller and Sun Fire domain agents. The platform agents must be deployed on a Solaris host external to the Sun Fire chassis that the agents are to monitor. Multiple platform agents can be deployed on a single host system to manage multiple Sun Fire servers, provided that the platform agent host system has been sized accordingly.
On average, each platform agent consumes 5% to 9% CPU and 15 to 18 Mbytes of memory. The CPU and memory consumption of platform agents deployed on the same host system are additive and can be used to gauge hardware requirements. The disk space requirements for multiple platform agent instances are minimally more than that for a single platform agent instance because the agents share the same software packages.
In general, the CPU and memory resource requirements of a platform agent are proportional to the size and complexity of the Sun Fire server configuration being managed. Sun Fire systems with larger configurations require more platform agent resources on the platform agent host.
You can install platform agents on either:
A Sun Management Center server layer host
A Sun Management Center dedicated platform agent host
The number of platform agents that can be installed on a given host varies depending on whether that host is a Sun Management Center server layer or platform agent layer host. To maximize the overall performance and responsiveness of Sun Management Center, platform agents should be deployed on dedicated hosts instead of the server layer host. If the server layer is deployed on a multiple CPU system with excess capacity, you can consider running platform agents on a server layer host.
The following figure shows the architecture for a dedicated platform agent host deployment, and a server layer host deployment.
Sun Fire platform agents refresh their management information hourly by default. When multiple platform agents are deployed on the same host and are initialized at the same time, the agents tend to perform their data refreshes in quick succession. If too many platform agents attempt to refresh their data concurrently, the overall responsiveness of the host system can be adversely affected.
To reduce the likelihood of concurrent operations by multiple platform agents on the same host, do not start all of the platform agents at the same time.
The following table lists typical hardware configurations and the corresponding number of platform agents that can be deployed on the dedicated host system.
Table C–7 Dedicated Host: Sun Fire Platform Agent Capacity
Representative Hardware Configurations |
Maximum Number of Platform Agents |
---|---|
Sun Blade 100 with a single 500 MHz UltraSPARC IIe CPU, 1 Gbyte of RAM and 1 Gbyte of swap |
5 to 7 |
Sun Fire 280R, Netra T4, or Sun Blade 1000 with dual 750 MHz UltraSPARC III CPUs, 1 Gbyte of RAM, and 1 Gbyte of swap |
14 to 20 |
Because platform agent resource use can vary, the limits shown in the table represent a range of acceptable values that leave sufficient capacity to ensure that operational peaks do not exhaust system capacity. Larger Sun Fire platforms require greater platform agent resources, with the result that fewer platform agents can be run on a single host. Conversely, smaller Sun Fire platforms require fewer platform agent resources, so more platform agents can be run on a single host.
The hardware sizing requirements of a host system running the Sun Management Center server layer are a function of the number of platform agents managed by the server layer and the management activity in the system.
Only large multiple-CPU systems should be considered for running both the Sun Management Center server layer and Sun Fire platform agents. The deployment of platform agents on a server layer host with limited capacity can adversely affect the overall performance of Sun Management Center.
Assuming a moderate level of management activity of fewer than 1000 events per host per day, the maximum number of platform agents than can be deployed on a Sun Management Center server layer host is the function of the number of agents under management and the machine class. The following table lists typical system capacity.
Table C–8 Server Layer Host: Sun Fire Platform Agent Capacity
Number of Agents Under Management |
Maximum Number of Platform Agents |
|
---|---|---|
100 |
6 |
7 |
300 |
5 |
7 |
500 |
4 |
6 |
750 |
NA |
6 |
Sun Fire 280R denotes a Sun Fire 280R, a Sun Blade 1000, or a Netra T4 system with a dual 750 MHz UltraSPARC III server host with 1 Gbyte of RAM and 1 Gbyte of swap.
For Sun Fire Sun Management Center installation procedures, see Sun Management Center Software Supplement for Sun Fire 6800/4810/4800/3800 Systems.