In large and distributed network and system environments, management tasks are handled by local administrators, each responsible for one subnetwork. For these distributed management functions, theGuard! NetworkManager can run as a Multi Site Edition. The Multi Site Edition has the full functional range of the Terminal Server Edition, but can additionally manage remote sites within a central database. The performance parameters of the Multi Site Edition are determined by the following criteria:

 

• number of locations (sites) with local administrators
• number of nodes (network and system components) at all sites
• number of workstations (administrator licenses) at all sites
• the PSMs needed at all sites

 

Performance features and application possibilities can best be explained using the Multi Site Edition as an example:

A company headquartered in Munich not only manufactures at its own premises, but also operates international production plants in Poland, China and Brazil.

All locations have local administrators to manage the local system and network landscapes within their own scope of responsibility. The central components for integrating the sites are managed from Munich headquarters. The network management system needs to fulfill the following requirements:

 

• central network and system status
• central overview of all important components
• local system and network administration
• local monitoring (polling) and event processing
• forwarding of important events to headquarters
• 24/7 monitoring 
• processing of on-call services 
• centralized data inventory 
• centralized data archiving
  

To locally manage locations, each site has its own local management system installed. Since there are a number of administrators running the systems/network at headquarters, as well as at the production plants in Poland and Brazil, theGuard! NetworkManager is installed at these locations on a server platform. Since only one administrator manages the network in China, theGuard! NetworkManager is installed there on a workstation.

The local administrators configure all monitoring functions for their own areas of responsibility and release all the components, which would be relevant to the other sites. This releasing can best be imagined as being similar to the enabling of files or directories in a Windows network (the analogy in this case would be that the node is the file and the submap is the directory). The difference here, however, is that the data doesn’t just remain at the source but is imported by the other sites. The greatest advantage in this lies in the data then also being available off-line and able to be consolidated centrally.

Since the remote (site) configurations are also known centrally and by all the other sites, management functions can, depending upon authorization, also take place centrally or be executed by the other sites. This would be needed in the following cases, for example:

 

• processing on-call services
• assisting with special network problems
• backup in the event of local management station failure

 

Transferring the data is a fully automatic process set for definable times as controlled by theGuard! NetworkManager Scheduler. The comparison interval set determines the updating of the data.

• configuration data on released nodes 
• released map hierarchies (submap layouts)
• inventory data on imported nodes
• performance data on imported nodes
• availability data on imported nodes
• current topology tree (with node references)

 

Configurations already imported are not compared, but fully overwritten. Such data thus remains linked to the source, meaning changes to the source data are visible subsequent each import. Should a local administrator need to modify a configuration himself, he can copy the data locally and use it further in any manner needed. Node allocation is maintained even in copied submaps. Imported submaps can additionally be linked at will and inset anywhere into one’s own map tree.

In the above example, the sites each release their main components (local backbone switches, central server). The central location, which actually monitors the network components of the WAN connections, makes them available to the sites. The central location additionally makes all central servers available (SAP, Exchange, PPS, etc.).

It is likewise possible to have events be forwarded to the central site from a site system. Although since not all problems which may arise will be of interest to the central site, it makes sense to set up a few limitations. To do so, the respective nodes for which events are to be forwarded must be tagged as such. The event is then depicted accordingly on the imported node.

If desired, the central site server can assume the monitoring function (polling) for a site, should the site experience a failure. This case as well is limited to the important components so as to avoid not only the system but also the network connection from becoming overloaded. These nodes must likewise be tagged accordingly.

The sample firm described above has a network with an approximate total of 12,600 network and system components (nodes). They are distributed among the individual locations as can be seen in this table.

Site	Nodes	Administrators	Components
Munich headquarters	4500	6	CISCO Router, CISCO Catalyst Switches, Extreme Summit Switches, Netscreen Appliance Series, Fujitsu-Siemens Server
Poland	3800	3	CISCO Router, Foundry BigIron Switches, Hirschmann Rail Switches, Netscreen Appliance Series, Fujitsu-Siemens Server
Brasil	3500	4	CISCO Router, HP Procurve Switches, Hirschmann Rail Switches, Netscreen Appliance Series, Dell Server
China	800	1	CISCO Router, CISCO Catalyst Switches, Siemens ESM Switches

Multi Site Edition: up to 15,000 nodes

• This license comes with 5 PSMs and 3 site server licenses. Thus, for the most part, ideally covering the above requirements. 
• Yet a total of 10 different PSMs are needed for the various network and system components, which means an additional 5 PSMs will need to be purchased.
• Since among all the sites, a total of 14 administrators work with the system at the same time, 14 administrator licenses are needed.
• The above system can be expanded or adapted to new requirements at any time by the acquisition of additional licenses.

Windows 2000 Advanced Server, alternatively Windows 2003 Server

• One Terminal Server client license per workstation
• Optional: Citrix MetaFrame application server

• MS SQL server at the central site server (Processor license); for performance reasons, possibly separate from application server; for more information on cascading, see System Concept. 

For the central site server, a multi-processor system as well as application scaling is recommended (see: System Concept).
The Multi Site Edition is limited to a maximum of 5000 nodes per site.

Functionally, the concept follows that of the Terminal Server Edition. The difference is that the Multi Site Edition can license the total number of client workstations at all sites. For more information, see: Terminal Server Edition.