test

Sun Management Center 4.0 Installation and Configuration Guide

Appendix C Determining Hardware Resources

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 appendix discusses the following topics:

Note –

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.

Agent Layer Resources

Sun Management Center 4.0 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 the Solaris 8, Solaris 9, or Solaris 10 Operating System. Sun Management Center agents are also available for Solaris operating system (x86 Platform Edition) systems running Solaris 9 and Solaris 10 and on Linux.

x86 Agent Limitations

Note –

The same limitations apply for the Linux agent.

The x86 agents do not support any hardware-specific add-ons (except X86 Config Reader). 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.

CPU Resources

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.

Light configurations are based on an agent with the following modules loaded:

The following tables give estimates of the agent CPU and RAM usage for light modules.

Table C–1 Agent CPU and RAM Use Estimates for SPARC (light modules)

Machine 

Memory (MB) 

CPU (%) 

Resident Set Size (MB) 

Virtual Memory (MB) 

Min 

Avg 

Max 

Min 

Avg 

Max 

Min 

Avg 

Max 

Min 

Avg 

Max 

Small 

0.4 

0.4 

0.4 

0.3 

0.3 

0.3 

7.46 

7.46 

7.46 

9.17 

9.17 

9.17 

Medium 

0.2 

0.2 

0.2 

< 0.1 

< 0.1 

< 0.1 

7.38 

7.43 

7.43 

9.12 

9.17 

9.17 

Large 

0.1 

0.1 

0.1 

< 0.1 

< 0.1 

< 0.1 

7.62 

7.68 

7.68 

9.34 

9.40 

9.40 

Extra Large 

0.1 

0.1 

0.1 

< 0.1 

< 0.1 

< 0.1 

7.82 

8.08 

8.12 

9.40 

9.59 

9.62 

CMT (T2000) 

0.1 

0.1 

0.1 

< 0.1 

< 0.1 

< 0.1 

8.44 

8.44 

8.44 

9.43 

9.43 

9.43 

Table C–2 Agent CPU and RAM Use Estimates for x86 (light modules)

Machine 

Memory (MB) 

CPU (%) 

Resident Set Size (MB) 

Virtual Memory (MB) 

Min 

Avg 

Max 

Min 

Avg 

Max 

Min 

Avg 

Max 

Min 

Avg 

Max 

Small 

0.6 

0.6 

0.6 

< 0.1 

< 0.1 

< 0.1 

6.10 

6.21 

6.22 

7.69 

7.76 

7.76 

Medium 

0.2 

0.2 

0.2 

< 0.1 

< 0.1 

< 0.1 

6.25 

6.25 

6.25 

7.80 

7.80 

7.80 

Large 

0.2 

0.2 

0.2 

< 0.1 

< 0.1 

< 0.1 

6.19 

6.29 

6.29 

7.76 

7.82 

7.82 

Heavy configuration is based on an agent with the following modules loaded:

  • Agent Statistics

  • Data Logging Registry

  • Health Monitor

  • Kernel Reader (Full)

  • MIB-II Instrumentation

  • MIB-II Proxy Monitoring

  • Solaris Process Details

  • Config Reader

  • Directory Size Monitoring

  • File Scanning

  • Script Launcher

  • Script Repository

  • Service Management Facility

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. Heavy modules can include various user-defined custom modules.

The following tables give estimates of the agent CPU and RAM usage by system type for heavy modules.

Table C–3 Agent CPU and RAM Use Estimates for SPARC (heavy modules)

Machine 

Memory (MB) 

CPU (%) 

Resident Set Size (MB) 

Virtual Memory (MB) 

Min 

Avg 

Max 

Min 

Avg 

Max 

Min 

Avg 

Max 

Min 

Avg 

Max 

Small 

1.0 

1.0 

1.0 

1.2 

1.24 

1.4 

19.15 

19.15 

19.15 

21.68 

21.68 

21.68 

Medium 

0.5 

0.5 

0.6 

< 0.1 

0.66 

1.3 

20.93 

20.95 

20.96 

23.60 

23.61 

23.61 

Large 

0.2 

0.2 

0.2 

0.1 

0.12 

0.2 

19.13 

19.16 

19.20 

21.88 

21.88 

21.88 

Extra Large 

0.1 

0.1 

0.1 

0.1 

0.1 

0.1 

23.97 

23.99 

24.00 

26.38 

26.38 

26.38 

CMT (T2000) 

0.3 

0.35 

0.4 

0.1 

0.19 

0.3 

22.42 

24.41 

26.53 

23.69 

25.74 

27.79 

Table C–4 Agent CPU and RAM Use Estimates for x86 (heavy modules)

Machine 

Memory (MB) 

CPU (%) 

Resident Set Size (MB) 

Virtual Memory (MB) 

Min 

Avg 

Max 

Min 

Avg 

Max 

Min 

Avg 

Max 

Min 

Avg 

Max 

Small 

1.3 

1.4 

1.4 

0.1 

0.1 

0.1 

13.40 

13.76 

13.79 

16.60 

16.96 

17.00 

Medium 

0.4 

0.4 

0.4 

0.1 

0.2 

0.3 

14.25 

14.43 

14.45 

17.33 

17.50 

17.52 

Large 

0.4 

0.4 

0.4 

< 0.1 

0.06 

0.1 

13.97 

14.81 

14.89 

17.00 

17.82 

17.90 

Virtual Memory Requirements

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.

Hardware-Specific Module Availability

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–5 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 

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 

Management Module Resources

The resource requirements of management modules depend on the following factors:

The following table summarizes the resource impact of the Sun Management Center management modules.

Table C–6 Sun Management Center Management Module System Impact Summary

Module 

Impact 

Agent Statistics

Incurs low footprint increase and low CPU load increase. 

Config-Reader

Uses CPU and memory relative to the complexity of the hardware configuration of the managed node. 

Data Logging Registry

Incurs low footprint and CPU load increase that is proportional to the amount of data values being logged. 

Directory Size Monitoring

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. 

File Monitoring

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. 

File Scanning (System Log)

Incurs low footprint and CPU load increase. 

Health Monitoring

Has relatively low impact on resources. 

HP JetDirect

Incurs low footprint increase and low CPU load. 

IPV6 Instrumentation Module

Incurs low CPU load increase and low to medium footprint increase dependent on the number of network interfaces. 

Kernel Reader, Full

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. 

MIB-II Instrumentation

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. 

MIB-II Simple

Incurs virtually no CPU load and very little footprint increase, proportional to the size of the system interfaces, IP forwarding, and IP address table. 

NFS File System

Incurs low footprint increase that is proportional to the number of network file systems mounted on the host machine, and low CPU load. 

NFS Statistics

Incurs low footprint increase and low to moderate CPU load. 

Print Spooler

Incurs low footprint and CPU load increase. 

Solaris Process Monitoring

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. 

Server Layer Resources

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.

The Sun Management Center server layer is supported on SPARC and x86 platform desktops and servers running on Solaris 10 11/06 or Solaris 10 8/07 that meet the minimum hardware requirements described in this section.

Note –

For the best performance, install the Sun Management Center 4.0 server layer on a dedicated machine running server layer applications only.

Recommended Server Hardware Platforms

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.

For Solaris SPARC:

Table C–7 Recommended Sun Management Center Server Hardware Platforms for Solaris SPARC

Architecture 

Machine Type 

CPU Type 

RAM 

Swap Space 

Small 

Sun Fire V120 

One 650 MHz UltraSPARC IIe/i CPU 

2 Gbyte 

1 Gbyte minimum, 2 Gbyte recommended 

Medium 

Sun Fire V440 

Two 1.02 GHz UltraSPARC III CPUs 

4.096 Gbyte 

1 Gbyte minimum, 2 Gbyte recommended 

Large 

Sun Fire V480 

Four 900 MHz UltraSPARC III CPUs 

16.384 Gbyte 

1 Gbyte minimum, 2 Gbyte recommended 

Extra-large 

Netra-T12 

Twenty-four 1.35 GHz UltraSPARC III CPUs 

49.152 Gbyte 

1 Gbyte minimum, 2 Gbyte recommended 

T2000 (CMT) 

Sun Fire T2000 

Sixteen 1 GHz SPARCv9 CPUs 

8.184 Gbyte 

1 Gbyte minimum, 2 Gbyte recommended 

For Solaris x86:

Table C–8 Recommended Sun Management Center Server Hardware Platforms for Solaris x86

Architecture 

Machine Type 

CPU Type 

RAM 

Swap Space 

Small 

AMD PC 

One 2.393 GHz AMD processor 

1.023 Gbyte 

1 Gbyte minimum, 2 Gbyte recommended 

Medium 

Sun Fire V20z 

Two 2.393 GHz AMD processors 

4.032 Gbyte 

1 Gbyte minimum, 2 Gbyte recommended 

Large 

Sun Fire X4100 

Four 2.200 GHz AMD processors 

3.968 Gbyte 

1 Gbyte minimum, 2 Gbyte recommended 

Sizing Requirements

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.

Figure C–1 Sun Management Center Server Load by Events per Day and Objects Managed

Sun Management Center Server Load by Events per Day and Objects Managed

The machine classes depicted in the above diagram are representative of classes of hosts with similar performance.

Caution – Caution –

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.

Sun Management Center Server with the Performance Reporting Manager Add-on

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.

  1. 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.

  2. Based on the estimated number of PRM data properties you want to collect, determine the appropriate PRM configuration as described in the following section.

Generating Performance Reporting Manager Reports

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:

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.

Note –

A medium Sun Management Center server with the performance reporting manager add-on is assumed to be a SunFire x4200 with two 2200 MHz x86 CPUs or a SunFire-v440 with two 1281 MHz SPARCv9 CPUs, 1 GB RAM, and 1 GB swap. It is also assumed that the server is monitoring 300 agents and collecting 300 data properties per agent for the performance reporting manager.

Scheduling Performance Reporting Manager Reports

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.

Performance Considerations

Major factors that affect the server layer performance include:

Simultaneous Startup of Sun Management Center Components

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.

Topology Group Configuration

The number of topology groups in a Sun Management Center server context should not exceed the following:

Management Activity

Sun Management Center server activity depends on the following factors:

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.

Number of Console Users

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.

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.

Java Console Layer Resources

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 8, Solaris 9, or Solaris 10 Operating System and x86 systems running the Solaris 9 and Solaris 10 operating system. The console is also supported on Intel systems running Microsoft Windows 2000, Microsoft Windows XP Professional, RedHat Enterprise Linux 4.0, SUSE 9.3, SLES 10.0, and Fedora Core 4.0.

Sun Fire Proxy/Platform Agent Resources

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.

System Requirements

You can install platform agents on either:

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.

Figure C–2 Platform Agent Architecture

Platform Agent Architecture

Startup of Multiple Platform Agents

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.

Deploying Sun Fire Platform Agents on a Dedicated Host

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–9 Dedicated Host: Sun Fire Platform Agent Capacity

Representative Hardware Configurations 

Maximum Number of Platform Agents 

Sun Fire V120 with a single 650 MHz UltraSPARC IIe/i CPU, 2 Gbyte of RAM and 1 Gbyte of swap  

5 to 7 

Sun Fire V440 with dual 1.2 GHz UltraSPARC III CPUs, 4 Gbytes 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.

Deploying Sun Fire Platform Agents on a Server Layer 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–10 Server Layer Host: Sun Fire Platform Agent Capacity

Number of Agents Under Management 

Maximum Number of Platform Agents 

100 

6 

300 

5 

500 

4 

750 

NA 

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.