HP OpenView System Administration Handbook [Electronic resources] : Network Node Manager, Customer Views, Service Information Portal, HP OpenView Operations نسخه متنی

21.1 PLANNING THE OVO ENVIRONMENT

During the planning phase, determine what types of systems and applications will be monitored. Devise a list of supported operating systems and applications. Determine which applications may be monitored using existing solutions or

Smart Plug-Ins (SPIs). Refer to Chapter 15, "Smart Plug-Ins," for a detailed discussion of Smart Plug-Ins. Determine which applications require custom template and application development.

You may want to begin your planning with a network diagram. NNM discovery can assist in documenting the network layout.^{Chapter 5}, "Network Discovery"). You may find that your network actually looks different than expected. In this case, it may be prudent to revisit some of the initial planning. For example, if systems are not discovered by NNM, it could be due to a firewall blocking the ICMP requests. In this case, you may want to deploy a NNM collection station on the other side of the firewall for NNM to communicate to clients. Depending on the location of the OVO server, you may be required to open firewall ports for communication between the OVO server and its clients.

^[1] The underlying NNM processes are automatically installed and integrated when you install OVO.

The location of OVO servers should be placed strategically throughout your enterprise. Typically, OVO servers are located in a Network Operating Center where the operations staff has access and control of the servers. You should consider whether they should to be placed behind firewalls for security purposes. If firewalls are required, opening firewall ports between the OVO server and clients will need to be included in the plan.Chapter 12, "Introduction to OVO," for a detailed description of these topics.

OVO corrective actions can be automated and/or manual. Consider that you are monitoring the

sendmail process on a UNIX system. An OVO agent determines that the process is no longer running. OVO allows you to define a corrective action that will attempt to restart the process without manual intervention. It also allows you to define an operator-initiated action that will restart the process with customizable command options. Customization of OVO application monitoring needs to be well planned.

The OVO administrator is responsible for the overall configuration of OVO. This includes creating and adding nodes, node groups, templates, applications, message groups and operators. The three types of OVO users are defined as follows:

• Administrator
  Responsible for the overall configuration.

• Template Administrator
  Responsible for template creation and modification.

• Operator
  Responsible for the day-to-day operation of the environment, using the Message Browser as the central monitoring component.

The OVO administrator can begin the configuration plan by determining which nodes to monitor, which message groups to create, which applications are required, and the responsibilities of each operator. Figure 21-1 depicts the administrator's configuration responsibilities and the outcome of the operator's view of OVO.

The following is a list of questions that may help in the OVO planning phase:

1. How many OVO servers are required?

2. Which OS will the server run on?

3. Where will the server be located?

4. Do firewalls exist between the OVO server and client?

5. Which systems/apps need to be monitored?

6. Which systems/ apps are mission critical?

7. What service levels are required? (Platinum, Gold, Silver, Bronze)

8. Which templates need to be assigned?

9. Who will deal with the problems?

10. Will OVO be linked to a external notification system?

11. Which SPIs are available to monitor applications?

12. How many operators are required?

13. What node groups should be configured?

14. What message groups should be configured?

15. How many template administrators are required?

16. Which applications require template and/or application development?

After these questions have been addressed, the administrator can begin configuring the OVO environment. Template administrators can assist in creating and modifying templates and integrating SPIs. The administrator is the only user capable of assigning and distributing templates.

Note

The opcnode command can be used for routine maintenance such as adding and removing nodes, and assigning, deassigning, and distributing templates.

21.1.1 Architecture

To create a network diagram, obtain a list of router IP addresses for the networks you intend on managing. Implement a seed file to include these IP addresses. Allow NNM to discover your network. If necessary, tweak the seed file and re-discover the network. Repeat until desired systems have been discovered by NNM.

Determine the number of OVO servers required to manage your enterprise. If you are managing fewer than 1000 systems, most likely a single OVO server will suffice. However, this depends on variables such as the number of templates distributed to the servers, the polling frequency, and the horsepower of the OVO server.

Determine OVO server locations. This should be done in conjunction with the network design team to ensure communication with all necessary managed nodes. List client locations and ensure that you have network connectivity between the OVO server and the client systems. If firewalls exist between the OVO sever and any of the clients and you are using the default OVO ports, the firewall ports will need to be opened.

21.1.2 The Systems

Determine the platform to be used as the OVO server. Current server platforms include HP-UX and Solaris.^{Chapter 25}, "OVOW Implementation Tasks," for details. This chapter is focused on the OVO product for UNIX.

^[2] At the time this manuscript was written, OVO Windows was the product available for a Windows management system. OVO-W is similar to OVO-UNIX but did not originate from the same application software. The OVO product is in the process of being ported to Windows.

Determine the platform's type to be supported as managed nodes. Currently supported agent platforms include:^[3]

^[3] Refer to the Installation Guide for the Management Server for a complete list of supported operating system versions.

• HP-UX

• Solaris

• AIX

• Linux

• Tru64

• Window NT

• Windows 2000

• Windows XP

• Novell Netware

• ptx

• SINIX

After the management server and the managed nodes have been determined, you are ready to determine which applications need to be monitored.

21.1.3 The Applications

OVO monitors applications. You should be able to list all applications that will be supported by the OVO environment. In addition to listing the applications, you need to know what components of the application need to be monitored. For example, you might want to monitor log files, resource utilization, or process status.

Distinguish between mission critical and non-mission critical applications. After determining the mission critical applications, you can begin researching whether a solution already exists for your particular application. Determine whether a SPI exists that can monitor your application sufficiently.

Consider monitoring the following list of mission critical applications:

• SAP R3

• OVSD Application Server

• WebSphere

• MicroSoft Exchange Server

• Citrix

• Radia

From the previous list, SPIs exist for the three applications: SAP R3, WebSphere, and Microsoft Exchange Server. The work for these applications is not complete yet. Each SPI needs to be configured and appropriate components (templates, monitors, and commands) need to be assigned and distributed to the appropriate systems. A good rule of thumb is to begin with at least one template administrator for each application and/or SPI used in OVO. As template administrators gain experience, they will be able to more effectively handle more template and SPI responsibilities. You shouldn't expect one administrator to do all of the work for the monitoring of these applications.^[4]

^[4] During an on-site experience for a large OVO implementation, the OVO customer employed 20 full time template administrators, one for each monitored application. This is not an uncommon practice.

Consider the first mission-critical application in the list, SAP R3. The SAP R3 Smart Plug-In guide consists of 322 pages. The following topics are included in the document:

1. Installing and Configuring the SMART Plug-In for SAP R/3

   • Phase 1:
     Installation Tasks

   • Phase 2:
     VPO Administration Tasks

   • Phase 3:
     SAP-Specific Tasks

2. Customizing Smart Plug-In Monitors

3. Installing and Customizing the Performance Monitor

4. Other Methods for Configuring and Customizing

5. Using the Smart Plug-In for SAP R/3

6. Service Views

As you have probably guessed, implementing the SAP R3 SPI, as with most SPIs, is not a trivial task. In order to implement the SPI, you will need to coordinate between the OVO administrator, the template administrator, and SAP R3 experienced engineers. Typically the OVO administrator has no prior SAP R3 experience and the SAP R3 engineer has no prior OVO experience. This makes for an interesting implementation.

An actual implementation of the SAP R3 SPI involved 2 OVO administrators and 2 SAP R3 experts working together over a month-long period. After two weeks of work, we were able to successfully get an SAP R3 message in the OVO message browser as well as display SAP R3 service views in the

OpenView Service Navigator (OVSN).^[5]

^[5] OVSN is an XML-based product that provides a service view in order to perform root cause analysis.

Now consider monitoring an application for which no available SPI exists, such as Radia. Radia is an inventory and software distribution application available for multiple platforms. In an actual implementation, the

Radia Configuration Servers (RCS) are located in various geographical locations throughout the world. The primary RCS is on a Windows XP system and several secondary RCSs are on HP-UX 11 systems. Listed here are the components to be monitored on the UNIX systems:

HP-UX processes

znfytmgr, ztoptask, zlogmgr, zbldpmgr, ztrymgr, ztcpmgr, zclkmgr, zutilmgr, zrexxmgr

HP-UX logfiles

nvd101_manager.log, radish.log

Because there is no Radia SPI template, development is required to monitor the above processes and logfiles. A single template with multiple message conditions can be used to monitor the processes. A log file encapsulator template will be required to monitor each of the logfiles. Implementation details should be handled by the template administrator. The administrator assigns and distributes the templates.