Large enterprises often have thousands of devices, servers, and applications that have to be managed, and a single eG management console may not have the capacity to handle the entire enterprise. To support such enterprises, multiple eG managers may be needed. However, if each of these managers operate independently, they may not provide a common view of the entire enterprise. Hence, it could be very cumbersome to have the IT staff of the enterprise login to different eG management consoles to get a complete view of the status of the target infrastructure.

A SuperManager is a manager of managers that provides a consolidated view of the status of the IT infrastructure that is being handled by different eG managers. The eG suite offers two options for configuring a SuperManager. The eG SuperManager is a 100% web-based component of the eG suite that provides a consolidated view across disparate eG managers. On the other hand, an administrator can also use the Computer Associates Network and System Management (NSM) product as a super manager. The following sections however, discuss the eG SuperManager option alone.

To configure an eG SuperManager, you first need to ensure that the eG SuperManager license is enabled for your eG installation.

There are three main reasons why a SuperManager is necessary in an enterprise environment.

  • Scale of operation: Large enterprises may comprise of thousands of devices, servers, and applications, and a single eG manager may not be sufficient to manage this environment. Hence, a multi-level architecture with individual eG managers reporting to a SuperManager is necessary.
  • Autonomous domains: Large enterprises often comprise of multiple domains, which are managed autonomously. Each domain may require a separate eG manager, but there could be a common support team that is responsible for first level support for all the domains. The same situation could occur in a managed services environment as well - the manager service provider (MSP) is responsible for supporting different customer infrastructures (possibly from a central location) but each customer may prefer to have their separate management consoles for administration. In this case, the support organization/MSP will need a consolidated view of the status of the infrastructure across the different domains.
  • Geographically distributed environments: Large enterprises will span multiple geographical locations and multiple eG managers – one per location – may be preferred so as to reduce the bandwidth involved in communicating all the measurements to a central console. In this case, a common support organization may be involved, thereby necessitating a management console that consolidates the status across the individual eG managers.

The eG SuperManager is a central entity that integrates with multiple eG managers and provides a consolidated view of the infrastructure being monitored by each of the managers. Figure 14 depicts how the eG SuperManager works.

Figure 14 : How the eG SuperManager works

The salient features of the eG SuperManager are discussed hereunder:

  • HTTP/HTTPS communication between the eG SuperManager and eG Manager:

    When it is configured, the eG SuperManager is provided with the details of the individual managers that are reporting to it. Periodically, the eG SuperManager polls the individual eG managers at a pre-defined interval, collects status information from them, consolidates the information, and provides it to users. All communication between the eG SuperManager and the individual managers happen over HTTP/HTTPS.

    The SuperManager initiates all communication with each of eG managers in its control. Therefore, if a firewall exists between the managers and the SuperManager, this firewall should be configured to allow connections initiated by the SuperManager to the individual managers (see Figure 15).

    Also, when a user who logs into the eG SuperManager interface clicks on an alarm in the current alarms window, or the manager name in the home page, he/she would be redirected to the corresponding manager's console wherein further diagnosis can be performed. To facilitate this, network connectivity should be provided such that all users have direct connectivity not only to the SuperManager but also to the individual managers (see Figure 15).

    Figure 15 : Remote host accessing the SuperManager and individual managers

  • Configured to work in NATed Environment:

    In many large environments, there may be multiple demilitarized zones, with firewalls between the eG SuperManager and the eG managers. The geographic locations of the SuperManager and the eG managers may also be different. In such cases, the eG SuperManager cannot be accessed using a private IP address. For the eG SuperManager to be accessed externally by the eG managers, network address translation can be setup so that the eG SuperManager is accessed over the internet using a public IP address.

  • Manages redundant clusters:

    If one of the managers that it operates with is part of a redundant cluster, the eG SuperManager will first try to communicate with the primary manager of the cluster. If the primary manager is not reachable, the eG SuperManager will automatically try to communicate with the secondary manager of the cluster.

  • Minimal dependence on Local data storage:

    The eG SuperManager has an exclusive database to store specific data such as user logins, user preferences etc related to all the managers that are reporting to the SuperManager. Once these data are polled in the database of the SuperManager, whenever the user of an individual manager logs in, the SuperManager would check the database to find out which of the managers reporting to the SuperManager allows access to the user. Moreover, the database of the SuperManager does not store metrics reported by each of the individual managers reporting to the SuperManager. Instead, the SuperManager contacts the managers based on the user logged in, collects the required information from the managers and displays the information upfront. Nowhere does the SuperManager stores metrics collected from the managers reporting to the SuperManager. This architecture of the SuperManager considerably saves time since the SuperManager need not contact all the managers to figure out the user logged in and moreover database overhead of storing scores of metrics is avoided thereby increasing the efficiency of the SuperManager.


    A user can login to the SuperManager as long as he/she is a registered user of one or more of the managers reporting to the SuperManager.

    If a user is registered with one of the managers alone, the view that the user sees is consistent with what he/she would see if they were to login to the manager to which they were registered directly. On the other hand, if the user is registered with more than one manager, the SuperManager produces a consolidated view based on the responses from the individual managers.


    In its current implementation, the eG SuperManager mainly serves as a central console where users can get a consolidated view of alerts from different managers. Any configuration changes necessary have to be performed directly on the individual managers.

  • Supports eG managers with heterogeneous configurations:

    The individual managers reporting to a SuperManager can have heterogeneous configurations. For example, one of the managers can be running on Microsoft Windows, whereas another could be running on Sun Solaris. Likewise, the databases of the individual managers can also be different – for example, one of the managers may use Microsoft SQL server as the database, while another may use Oracle as the database.

  • Supports multiple languages:

    The alarm and dashboard displays in the eG SuperManager console are language-customizable! The language preferences set by the users registered with each of the managers reporting to the SuperManager, will affect the alarm and dashboard displays in the eG SuperManager console as well. For example, say that a user to an eG manager at Spain chooses Spanish as the language in which he/she would prefer to view performance information reported to the manager. When such a user logs into the SuperManager that manages the Spain manager, the alarms and performance details pertaining to that user will be displayed in the eG SuperManager console in the Spanish language only. Moreover, if the managers reporting to a SuperManager are double-byte enabled and support double-byte languages such as Chinese or Japanese, then the SuperManager interface too will display data in double-byte.

  • No change in agent architecture:

    In this architecture, since the agents continue to report to their respective eG managers, there is no change needed in the eG agent architecture.

The eG SuperManager can be applied in the following environments:

  • In a large enterprise with thousands of devices, servers, and applications, the eG SuperManager ensures that the eG suite can scale to handle such an environment;
  • In a distributed network, eG managers can be installed in each domain of the network and managed autonomously; At the same time, using the eG SuperManager, a single integrated console can be provided for the support team that is responsible for monitoring each of the domains;
  • In a managed service environment, each customer network could have an independent eG manager, but with an eG SuperManager installed, the managed service provider could get an integrated view of the status of all the customer networks that they are responsible for managing.

The chapters to come will elaborately discuss how to install and configure the eG SuperManager.