This section provides an overview of Sun Management Center management approaches. Understanding the systems under management and their implementation can contribute to the successful deployment and use of Sun Management Center.
The highest-level building block for the organization of management information is the server context. Each Sun Management Center server provides only one server context. Each server context might have one or more managed systems that report to the server context. A managed system can report to only one server context.
Communication between server contexts is typically restricted, and management events are not forwarded between servers. The use of server contexts should parallel the structure of the groups within the organization using Sun Management Center. Server contexts should also parallel the responsibilities of these groups with respect to systems management. The administrative group that owns the server also owns the management data within the server. This group controls all access to all system and network resources managed by the Sun Management Center server.
Domains are the highest-level construct within a server context. Domains provide individual environments within which you can create custom topology configurations. Domains are very generic. You can create a domain to represent information specific to users, environments, or any other logical division. Managed systems may appear in more than one domain, enabling multiple, overlapping domains to exist. You can therefore construct several different representations of the same management information and system resources.
Domains typically contain a hierarchical collection of Sun Management Center groups that you can use to aggregate sets of managed systems, Sun Management Center management modules, or managed objects. This hierarchy defines the visible breakdown of information in the user interface. This hierarchy also defines the rules for aggregating management status and providing this status to high-level summaries. This capability and flexibility makes domains, and the containers within them, a powerful tool for the construction of logical management models of a specific environment.
Sun Management Center contains a powerful Discovery Manager, which can be used to automatically and periodically examine the local environment to identify all managed nodes. While instrumental in the configuration of Sun Management Center, the Discovery Manager structures management information along physical, network-based lines.
Depending on the nature of your environment, using the Discovery Manager might not be the most useful way to view management information and aggregate status information. Conversely, using the Discovery Manager is very useful for identifying all managed systems prior to organizing your Sun Management Center environment. For further information about the Discovery Manager, see “Adding Objects to the MIB Using the Discovery Manager” in the Sun Management Center 3.5 User's Guide.
Other ways to organize the Sun Management Center environment include:
Physical
Environmental
Application
Service
In each of the Sun Management Center environments, emphasis should be placed on completeness. The breadth of coverage must be sufficient to proactively or at least immediately identify system problems. Failures in devices, hosts, services, or processes that are critical to an environment but that are not being monitored by Sun Management Center can cause gaps in the coverage that will affect the overall effectiveness of an implementation. To this end, you should consider customized modules, proxy solutions, and even information from other server contexts when building your Sun Management Center management environments.
The physical locations of managed systems might not correspond to the networks on which the systems reside. In this case, you might want to create a new domain in which the Sun Management Center groups are structured on physical lines. Cities, sites, buildings, floors, server rooms and even equipment racks can easily be represented. The systems at these locations can be copied and pasted from the domain in which discovery was performed using the Discovery Manager.
To configure a Sun Management Center environment along physical lines requires you to know where the systems are physically located. This organization can become a valuable and easily accessed reference. A physical organization also defines a status roll-up path, enabling problems to be isolated on physical lines and assisting in the identification of common-mode failures. For example, a localized power outage might affect systems that reside on several networks but will only appear in one physical area.
You must keep the information up-to-date yourself. This information is not automatically updated when discoveries are performed. The discovery process does not automatically track assets that are physically relocated.
Your organization might have several logical environments whose locations and resources overlap, but whose logical functions are distinct. Logical environments include corporate groups such as sales versus engineering, functional groups such as retail versus institutional, and even logical software environments such as user acceptance versus production.
In all of these cases, consider producing separate Sun Management Center topology groups that isolate the elements of each group. Separate topology groups prevent problems in one group from raising alarms in another group. This isolation is particularly important when configuring the Sun Management Center environment for systems that include multi-domain servers. The different domains might be performing functions for completely different groups or environments. The inclusion of the different domains in a single topology group could result in misleading information and alarm notifications.
Applications are complex entities in systems management. Determining what constitutes an application from a management perspective can be difficult, particularly when applications are distributed and rely on many external services to operate properly. For this reason, you should organize applications before installing Sun Management Center. Do not defer consideration of the cause and effect relationships until a problem is actually encountered. Some initial analysis contributes to increasing the efficiency with which application-level problems are resolved.
When configuring an application-oriented Sun Management Center environment, the topology containers typically contain a mix of hosts, modules, and specific objects. Some hosts might be completely dedicated to that application, while other hosts might only be partially responsible for the application's proper operation. For example, in the case of an application that makes use of a corporate directory service, the health of the directory service is critical to the operation of the application, but the health of other services on the server are not critical to or needed by the application.
In some circumstances, a group or administrator might be responsible for a specific service but not the underlying resources. For example, a database administrator might be responsible for the database service availability and data integrity, but not responsible for the hardware or operating system administration. A Sun Management Center domain that is created specifically for the database services can assist the database administrator in performing the necessary tasks. General user role privileges can assist the administrator by providing access to general system and network status.
Several facilities in Sun Management Center can help you to simplify management of large enterprises. One facility is Reference Domains, which allow groups to share management information across server contexts. Another feature is the Grouping Operations system, which facilitates performing large, highly distributed management operations.
The grouping system enables you to set data property values, and modify data property attributes. You can also load, unload, enable, and disable modules in your Sun Management Center server environment. All of these operations can be applied to a large group of managed systems and nodes. These groups can be defined using existing topology structures or flexible, discovery-style filters. Grouping operations can be saved and performed multiple times. A scheduler is available to automate grouping operations. Grouping operations also include Module Configuration Propagation (MCP), a facility in which a reference node's entire configuration can be cloned by pulling it to the server and then pushing it to all similar nodes.
For further information about Reference Domains, see “Monitoring Remote Administrative Domains” in the Sun Management Center 3.5 User's Guide. For further information about group operations, see “Managing Group-related Jobs” in the Sun Management Center 3.5 User's Guide.