How does eG Manager Redundancy Work?

To make the eG manager redundant, do the following:

  1. After installing the different eG managers that are a part of the cluster, start the managers. To enable the secondary manager to synchronize their time with the primary manager, start the primary manager first and then the secondary manager.

    Note:

    • The primary and secondary managers can exist in different time zones.

    • Every time the secondary manager synchronizes its time with the primary manager, the time is recorded in the eg_db.ini file (in the <EG_INSTALL_DIR>\manager\config directory) of the secondary manager. Typically, the secondary manager will attempt to synchronize its time with the primary manager every 1 hour. During such attempts, if a primary manager is unavailable, then the secondary manager synchronizes its time with the last value stored in the eg_db.ini file.

      However, while attempting to start the secondary manager for the very first time, no time record will be available in the eg_db.ini file. During such a situation, if the primary manager is unavailable, then all attempts to start the secondary manager will fail.

  2. As an admin user can login to the primary manager only, configure the environment using the primary manager. The secondary manager then downloads the latest configuration details from the primary manager.

    Note:

    Configuration changes subsequently made using the primary manager will immediately be reflected in the secondary manager.

  3. Install the eG agents. Refer to the Detailed Installation Guide for a detailed installation and configuration procedure.

  4. Typically, the manager to which an agent reports will be set during the time of agent installation itself. To facilitate manager redundancy, this manager-agent association can be overridden using the eG administrative interface. To change the mapping, do the following:

    • Login to the primary manager’s administrative interface as admin.
    • Next, follow the menu sequence: Agents -> Assign to Manager

    • Figure 1 will then appear. By default, the primary manager will appear as the Manager (see Figure 1). Also, by default, all the agents configured in the environment will appear in the agents assigned to primary manager list box of Figure 1. In a redundant manager configuration, the manager IP/hostname and port number specified at the time of installing an agent is ideally the IP address and port number of the primary manager. When a component is added for monitoring via the eG admin console, a mapping is created in the eG manager indicating the preferred manager to which this agent should be reporting during normal operation of the cluster. By default, the preferred manager for all agents is the primary manager. The eG admin interface provides a way for an administrator to override this default setting.

      Figure 1 : All agents configured in the environment appearing in the AGENTS REPORTING TO PRIMARY MANAGER list box

    • Note that the eG Enterprise system does not permit users to directly disassociate agents from the primary manager. Instead, you will have to assign an agent to the secondary manager, so that it no longer reports to the primary.

    • For this, first associate agents with the secondary manager. To achieve this, first, select a secondary manager from the list box against Manager in Figure 2.

      Figure 2 : Selecting a secondary manager

    • By default, the agents assigned to other managers list of Figure 2 will display all the agents that are currently reporting to the primary manager. To assign agents to the chosen secondary manager, first, select an agent from the agents assigned to other managers list (see Figure 3). 

      Figure 3 : Selecting an agent to be associated with the chosen secondary manager

    • Next, click on the < button in Figure 3, so that the selected agent moves to the agents reporting to selected manager list (see Figure 4).

      Figure 4 : Transferring the selection to the AGENTS REPORTING TO SELECTED MANAGER list

    • This exercise also ensures that the chosen agent(s) is successfully disassociated from the primary manager.
    • Then, start the eG agents.

  5. Each of the managers will then receive performance metrics collected by each of the agents assigned to them. Measures reported to a manager will be made available to the other manager as well.

    Note:

    • As data reported by the agents will be available to all the managers, there will be no difference in the component state and reports displayed by the managers in the cluster.
    • The origin of email alerts depends upon the manager-agent association. In other words, a manager receiving measurement data from an agent will generate all the email alerts pertaining to that agent.
    • While the printing/mailing of a report can be scheduled using a secondary manager, it is the primary manager that implements the schedule. Therefore, if the primary manager is not available, then the reports will not be printed/mailed as per schedule.

  6. If a manager becomes unavailable, agents reporting to it will automatically begin reporting measures to the other available manager (see Figure 5).

    Figure 5 : A figure depicting what happens when a manager is rendered unavailable

  7. When a manager comes back online, the agents which switched loyalties earlier will automatically begin reporting measures to the original manager to which they were assigned.

  8. When a manager is offline, other manager receiving data from agents can be configured to store the data that it receives from the agents locally. When the manager comes back up, the other manager will transmit the saved data to the manager that has just come up. This ensures that there is minimal data inconsistency between the different eG managers.

    Note:

    • The amount of data that can be stored by a manager for transmission to other offline managers is controlled by two configuration settings - maxStoragePerFile and filesPerManager - that are present in the file eg_managers.ini located in the <EG_INSTALL_DIR>\manager\config directory.
    • The setting maxStoragePerFile defines the amount of data (in MB) that can be stored in each temporary file that is used to store data temporarily for transmission to a manager that is offline. An eG manager can store data in multiple files for transmission to the offline manager. Multiple files are used for storage (rather than a single file) to minimize data read/write operations to memory for transmission to the other manager. The filesPerManager setting defines the maximum number of data files per manager that are used for temporary storage of data.
    • By default, the maxStoragePerFile value is 0, and the filesPerManager is 0. This implies that a manager does not save data it receives from agents directly for transmission to another manager that may be offline. If the maxStoragePerFile is 10 and the filesPerManager is 20, then 200MB of data can be saved for transmission to another manager that is offline.
    • When a manager comes back online after a failure/shutdown, the agents that should be reporting to it do not switch back immediately. This is because, while agents are attempting to report new measurements to the original manager, the other manager will attempt to update the original manager with the data that was collected during its non-availability. In order to avoid data congestion at this juncture, the agents will wait until all the data in the <EG_INSTALL_DIR>\manager\data folder of the other manager is cleared, and will then begin reporting to their assigned manager.