Sun Management Center 3.5 Installation and Configuration Guide

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.5 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.5 system requirements.

The Sun Management Center server layer is supported on SPARC platform desktops and servers running either Solaris version 8 or Solaris version 9 that meet the minimum hardware requirements described in this section.

Note –

For the best performance, install the Sun Management Center 3.5 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	Netra X1, Netra T1, or Sun Blade 100 or equivalent	One 502 MHz UltraSPARC IIe CPU or better	1 Gbyte	512 minimum, 1 Gbyte recommended
Medium server	Sun Enterprise 80 or equivalent	Two 450 MHz UltraSPARC II CPUs or better	1 Gbyte	512 minimum, 1 Gbyte recommended
Large server	Sun Fire 280R, Netra T4, or Sun Blade 1000	Two 750 MHz UltraSPARC III CPUs or better	1 Gbyte	512 minimum, 1 Gbyte recommended
Extra-large server	Sun Fire 480R or equivalent	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 amaximum 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 an Ultra-80 with two 450MHz UltraSPARC II CPUs, 1 GB RAM, and 1 GB swap. It is also assumed that the Ultra-80 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.