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

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.

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:

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

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.