Sun Management Center 3.6.1 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 chapter 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 3.6.1 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 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.

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.

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:

Config Reader
Health Monitor
Full Kernel Reader
MIB-II Instrumentation
Directory Size Monitoring
File Scanning

Hardware Diagnostics Suite
Script Launcher
HP JetDirect
Agent Statistics
MIB-II Proxy Monitoring
Various other modules, including custom modules

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.

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

Management Module Resources

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
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.
Sun StorEdge A5x00 Array, Sun StorEdge T3 Array	Incurs moderate footprint and load increase that is proportional to the size of the storage device.

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. Sun Management Center 3.6.1 server layer system requirements are greater than the hardware requirements for Sun Management Center 3.0 server layers. Version 3.0 server hosts do not necessarily meet the Sun Management Center 3.6.1 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.

Note –

For the best performance, install the Sun Management Center 3.6.1 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.

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

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

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

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.

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.

PRM Configuration Types

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.

PRM Server Configuration Examples

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

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:

The number of actual data points included in the report

Note –
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.

Note –

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.

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
Topology group configuration
Management activity
Number of console users

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:

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.

Management Activity

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.

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.

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.

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 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, and Microsoft Windows XP.

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:

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.

Figure C–2 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–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.

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