Distributed Management Approaches

A small network can be managed conveniently by a single NMS. All desired functions are performed by this NMS. In a large network, a single NMS may not be able to handle the load of managing the entire network. Especially in a geographically distributed network, the WAN links may have relatively low bandwidth and could become bottlenecks. Hence, it is desirable to have several managers. These managers may all perform similar functions, or they may be functionally specialized. For example, one manager could perform only fault management, while another manager is used only for performance monitoring.

A distributed management application consists of several manager applications running on different management stations. Each manager performs its management functions either by directly interacting with agents or indirectly via other lower-level managers. Distributed management can be classified into categories ranging from centralized management at one end of the spectrum, through weakly distributed, strongly distributed, to cooperative management at the other end [Meyer, 1995].

In the centralized and weakly distributed paradigms, there is a well-defined hierarchy of management stations, and a manager can delegate tasks only to those strictly below it in the hierarchy. In the strongly distributed and cooperative paradigms, horizontal delegation is also allowed.

Another issue is the selection of a suitable management technology to implement the paradigm and whether delegation of management tasks is static or dynamic. For weakly distributed systems, it is customary to have static code running at various lower-level managers. Each manager knows the system being managed and is statically configured to manage it. A lower-level manager can execute a predefined task when requested by a higher-level manager.

The dynamic delegation of management functions to intermediate-level managers allows more flexibility [Meyer, 1995]. Management operations can be instantiated by higher-level managers by downloading or transferring code to remote management stations on the fly.

Multitier Architecture. In choosing a multitier architecture, there is a

[Vanchynathan et al., 2004]. A strongly distributed or cooperative architecture permits almost unlimited flexibility, while a weakly distributed (hierarchical) architecture is much easier to implement correctly and efficiently. In particular, with the restricted communication and links between managers, it is straightforward to ensure consistency of data that may be replicated in several managers. This is much harder to achieve with strongly distributed designs. Further, most network operators and

enterprises have well-defined hierarchical structures for their networks and their personnel.

Topology. We partition the set of elements to be monitored into groups of manageable size based on some criterion, say geographical. A manager process monitors each group and these processes constitute the lowest layer of the management architecture (Figure 9.35).

Figure 9.35. Hierarchical Multitier Management

One or more managers that run management processes at higher levels in the hierarchy are a parent of each of these management stations. This concept can be extended to as many layers as required.

To ensure predictable behavior, each cluster of network elements can have at most one parent, i.e., exactly one manager. If we represent each management station by a vertex and draw a directed edge (i, j) between two vertices i and j, if i is managed by j, the topology of the resulting network corresponds to a directed acyclic graph (DAG) [Horowitz, 1995].

9.4.8. Server Platforms

The NMS server requires two software platforms, namely the OS and the DBMS. The choice of these is important as they affect the development effort, performance, security, reliability, and cost of the NMS server. Once the OS and DBMS are chosen, the server design and implementation tend to become specific to these. Changing these at a later date is costly and time-consuming. The platform must be stable, of modest cost, and with a guarantee that it will be supported for the foreseeable future.

A detailed comparison of the available platforms is beyond the scope of this book. We would like to mention the trend of open-source platforms that can compete with commercial platforms in all respects. While in the past the designer of a large and complex software application such as an NMS server was constrained to run it on one of the commercial platforms, today, increasingly we find designers opting for open-source platforms.

Operating System (OS). The OS must support threads, processes, and

shared-memory multiprocessors. It must support very large RAM and disk and a variety of peripherals. It must have a good programming interface for access to and control of its functions. It must efficiently support a variety of programming and scripting language chosen by the designers. It must have available a range of third-party software tools, components, and libraries.

Several popular server operating systems today are Linux, various flavors of UNIX (Sun Solaris, IBM AIX, HPUX, MacOS X, FreeBSD) and Microsoft Windows. All of these meet the requirements stated above though to varying degrees. Linux, FreeBSD, and NetBSD are popular open-source server OSs. The others are commercial (Sun Solaris has an open-source version available).

Database Management System (DBMS). The DBMS must efficiently

support very large amounts of data. This includes hundreds of tables and 100s of millions of records. The DBMS must support transactions. It must have good administrative tools for creating indexes, recovering from table corruption, taking backups, and especially performance tuning.

As with the OS, the designer has a choice of several high-quality DBMS platforms, both commercial and open source. The viable open-source platforms are MySQL and PostgreSQL. Commercial platforms include Oracle, IBM DB2, Microsoft SQL Server, and Sybase.