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

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

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.

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