| Sun Fire V20z and Sun Fire V40z Servers--Server Management Guide |    
|
| Sun Fire V20z and Sun Fire V40z Servers--Server Management Guide |
|
| C H A P T E R 3 |
|
SNMP Server Management |
You can manage your server using the Simple Network Management Protocol (SNMP).
Simple Network Management Protocol (SNMP) is a network-management protocol used almost exclusively in TCP/IP networks. SNMP provides a means to monitor and control network devices, and to manage configurations, statistics collection, performance, and security on a network.
SNMP-based management allows for third-party solutions to be used. This includes products such as HP OpenView and CA Unicenter.
The base component of an SNMP solution is the Management Information Base (MIB). The MIB is included on the Sun Fire V20z and Sun Fire V40z Servers Network Share Volume CD.
This server management configuration is beneficial when, for example, you have a cluster of machines serving web content and the platform is connected to the Internet, but the SP is protected and accessible only on an internal network.
SNMP is an open network-management technology that enables the management of networks and entities connected to the network. Within the SNMP architecture is a collection of network-management stations and managed nodes.
Network-management stations execute management applications, which monitor and control managed nodes. Managed nodes are devices such as hosts, gateways and so on, which have management agents responsible for performing the management functions requested by the management stations.
SNMP is used to communicate management information between the management stations and the agents. In other words, SNMP is the protocol by which the agent and the management station communicate.
Monitoring status through SNMP at any significant level of detail is accomplished primarily by polling for appropriate information on the part of the management station. Managed nodes can also provide unsolicited status information to management stations in the form of traps, which are likely to guide the polling at the management station.
Communication of information between management entities in a network is accomplished through the exchange of SNMP messages, both in the form of queries (get/set) by the management station and in the form of unsolicited messages (traps) indicated by the agent.
The servers include SNMP agents that allow for out-of-band health and status monitoring. The SNMP agent runs on the SP and therefore all SNMP-based management of the server should occur through the SP.
The SNMP agent on these servers provides the following capabilities:
The Management Information Base (MIB) is a text file that describes SNMP data as managed objects. These servers provide SNMP MIBs so that you can manage and monitor your server using any SNMP-capable network management system, such as HP OpenView Network Node Manager (NNM), Tivoli, CA Unicenter, IBM Director, and so on. The MIB data describes the information being managed, reflects current and recent server status, and provides server statistics.
FIGURE 3-1 illustrates the MIB tree.
You use the server's MIBs to integrate the management and monitoring of the server into SNMP management consoles. The MIB branch is a private enterprise MIB, located at object identifier (OID) 1.3.6.1.2.1.9237. The standard SNMP port 161 is used by the SNMP agent on the SP.
There are certain prerequisites and setup requirements on both the SP and the platform in order to enable and utilize each of these services:
Customers can elect to manage a server out-of-band (OOB) through the SP. With OOB management, the SP is the target of the SNMP request. The SNMP agent on the SP is configured to provide proxy-request capability so that OID requests that are not related to the SP are forwarded, transparently, to the platform OS.
FIGURE 3-2 illustrates the SNMP architecture and communication paths between the SP and the platform.
The SNMP agent running on the SP facilitates the management and monitoring of the server. The SNMP agent can be used to query various types of SP information. Refer to FIGURE 3-1 for a list of the MIBs; refer to TABLE 3-3 for a detailed description of the MIBs.
There is no configuration required to use this functionality other than integrating the
server MIBs with your desired management station.
Refer to the procedure for using the SNMP agent on the SP, as explained in Integrating MIBs With Third-Party Consoles.
|
Note - The SNMP agent on the Sun Fire V20z and Sun Fire V40z servers supports SNMP v1 and v2c. For security reasons, there are no settable attributes in this agent. |
The SP acts as an SNMP proxy-agent intermediary for the platform. Queries made from a management station to the SNMP agent on the SP are intercepted by the proxy agent on the SP and forwarded to the platform; the SP proxy agent contacts the platform to retrieve the requested information. The proxy agent then receives the data from the platform and sends the request back to the management station. The management station never knows that the request was proxied. The SP and the platform communicate over an internal private network.
To enable this facility, you must first run an SNMP agent on your platform operating system (see your OS vendor to obtain this agent). This enables platform-level management transparently through the SP. Querying MIBs other than the server MIB (for example, the Host Resource MIB) and the MIBII System MIB on the SP obtains information from the platform by proxying the request to the platform SNMP agent.
Ensure that the SP can identify the read-only and read-write community names that are configured for your platform SNMP agent. Refer to Setting the Community Name.
The SNMP agent on the SP acts as a proxy for the SNMP agent running on the platform. (Refer to Configuring SNMP on the Servers.) To proxy properly, you must use the community string. The community string needed to do so is the value defined when you configured the platform for SNMP.
If you find that your SNMP queries are not being proxied to the platform SNMP agents, validate that the community string on the SP matches the community string on the platform. The SP proxy community string can be changed to match the platform community string using the following command:
# sp set snmp proxy community
There are no restrictions on the length of the community strings; common names are private and public. The default name is public.
For more information, refer to SP Set SNMP Proxy Community Subcommand.
A subagent using SNMP Agent X protocol on the platform can connect to the SNMP agent on the SP (through a special port) and forward query responses or unsolicited traps through the SP. This allows server-management traffic to be kept secure from the production network connected to the platform, if required.
To properly enable this facility, you must identify the IP address and port number pair associated with the SP (as seen from the platform). The Agent X port is fixed at 705 (TCP). However, the private-network IP address is configurable and, by default, this address is 169.254.101.2.
Refer to your application documentation for instructions on configuring the subagents.
|
Note - You can use the subcommand sp get jnet on the SP to retrieve the JNET IP address of the SP. For more information, see SP JNET Address Subcommands. |
The following procedure demonstrates how to integrate the server MIBs into an SNMP node manager.
1. From the browser's Manager Preferences menu, choose Load/Unload MIBS: SNMP.
2. Locate and select the SP-MasterAgent-MIB.mib.
4. Specify the directory in which the server MIBs are placed and click Open.
5. Repeat Step 2 through Step 4 to load other MIBs.
For example, SP-SST-MIB.mib, SP-INVENTORY-MIB.mib, SP-EVENT-MIB.mib, SP-PLATFORM-MIB.mib, SP-GROUP-MIB.mib, and so on.
6. Exit the Manager Preferences menu.
The SNMP standard tree displays in the MIB Browser.
8. Locate the newisys branch located under private.enterprises.
Refer to FIGURE 3-1 for a sample view of the MIB tree.
You can also easily integrate SP-generated traps and set logging options. The following procedure demonstrates the necessary steps when using HP OpenView Network Node Manager (NNM).
1. Load the SP-EVENT-MIB.mib according to the previous procedure.
2. Choose Options>EventConfiguration
3. Select the spEvent module from the Enterprises list.
4. Double-click an event from the Events for Enterprise spEvent list.
5. Select the Event Message tab.
6. Select Log and Display in Category and choose a category from the corresponding list, or create your own event category.
7. Select the severity of the event from the Severity list.
8. Enter a message or $* to display all information in the Event Log Message field.
SNMP traps are network-management notifications of an event occurring at a managed network node. These events can identify problems in the network, machines that are up or down, and so on. The Sun Fire V20z and Sun Fire V40z servers use traps to signal conditions related to the server's health, including critical conditions related to physical components, the return to a normal state for these components, and other situations related to the state of the software running on the SP (for example, network settings are being reconfigured).
Traps are defined in the MIB files and are generated, received, and processed by an SNMP management station. SNMP trap data is uniquely identified by the MIB. Each SNMP trap contains information identifying the server's name, IP address, and other relevant data about the event.
Within the server event MIB, each trap has variables and event bindings, as described in TABLE 3-1.
Although SNMP traps are generated for events that occur on the SP, you must configure where these traps are to be sent. There is no default destination for traps. You can use the server-management subcommands (see TABLE 3-2) on the SP to configure SNMP destinations.
For more information on these subcommands, refer to Appendix H.
Admin-level and manager-level users can define SNMP destinations to which SNMP events (alerts) will be sent. All users can view the current destinations (using read-only access).
The number of destinations you can create is limited due to memory constraints.
You can configure SNMP destinations using the sp snmp subcommands. For more information about these subcommands, refer to Appendix H.
SNMP uses object identifiers (OIDs) to provide name variables by which objects are grouped together for easier reference. These servers provide agents for the MIBs shown in TABLE 3-3.
The events listed in TABLE 3-4 are sent to the SNMP destination by
SP-EVENT-MIB.mib.
You might find that SNMP queries to the service processor (SP) are timed out. If so, note that the platform OS requires both the Newisys Platform Software (NPS) driver suite RPM and an active SNMP daemon sharing the SP's community string.
| Sun Fire V20z and Sun Fire V40z Servers--Server Management Guide | 817-5249-17 |
|
Copyright © 2004-2007, Sun Microsystems, Inc. All Rights Reserved.