What is an Active/Active cluster?
An Active-Active cluster is one where both the primary and secondary managers can both have agents reporting measures to them during normal operation.
Do I need to use separate database servers for each of the managers in a cluster?
The different managers in a cluster can use the same database server, but the database name assigned for the eG database should be different for all the managers in the cluster.
Do the primary and secondary managers have to be sized the same?
Ideally, the same amount of CPU, memory, and disk resources need to allocated to the primary and secondary managers, as the volume of data handled by both the managers will be the same.
Can the managers in a redundant setup use different operating systems?
Yes. The eG Redundant Manager setup provides heterogeneous platform support. For instance, you can have one of the managers on a Windows platform, and another on Solaris.
Can the managers in a redundant setup have different double-byte configurations?
No. A redundant setup cannot have a primary manager that is double-byte enabled and a secondary manager that is not, or the vice-versa. If so, then the redundant setup will not function properly. It is therefore recommended that all managers in a redundant setup have the same double-byte configuration.
Can only one of the managers in a redundant cluster integrate with the Active Directory server for management of domain users?
This is not recommended. For instance, if only the primary manager has been configured to integrate with the Active Directory server and not the secondary manager, then domain users created on the primary manager cannot login to the secondary manager. The vice-versa also holds good. You are therefore advised to ensure that all managers in a redundant setup either integrate with the Active Directory server or do not.
Do I need cluster hardware to support the redundant managers?
No. There is no need for any specific cluster hardware to be installed. eG Enterprise handles the cluster functionality at the application-level.
How does a manager in a cluster communicate with the other manager?
The primary and secondary managers in a cluster communicate via HTTP/HTTPS. If any of the managers in a cluster is behind a firewall, then the firewall needs to be configured to allow “two-way” communication - i.e., both inbound and outbound traffic from the manager should be allowed.
The manager port can be configured during installation. 7077 is the default port for all the managers.
How much bandwidth is needed for the communication between redundant managers?
Since all the data from one manager will be replicated to the other, the bandwidth requirement for manager-manager communication should be equal to the sum of the data traffic from the agents to the manager.
Can both the managers in the cluster be started simultaneously? If not, why?
No. It is recommended that you start the primary manager first, and then the secondary managers. This needs to be done to ensure that all the secondary managers synchronize their time with the primary manager.
What happens if the managers in a cluster are in different time zones?
Since the secondary manager synchronizes its time with the primary manager, alerts and measure data will be reported only in the primary manager’s time.
What if I change the time zone of the primary manager?
If you change the time zone of the primary manager while it is running, then ensure that you restart the primary manager after the timezone change so that, the change takes effect.
Does each manager in the cluster see all the data from the agents?
Yes. All the data from all the agents in the environment will be made available to all the managers in the cluster.
Do the agents report to both the managers in a cluster? If not, how does redundancy work?
No. At any given point in time, an agent reports to only one manager in a cluster. The measure data reported by an agent to a single manager will be sent by that manager to all other managers in the cluster.
How does an agent know that a manager in the cluster is down and how does the agent react to this?
The eG agent periodically reports measurement data to the eG manager for state computation and alarm generation. If the agent is unable to upload metrics to the manager, it is a clear indicator that the manager is down. Under such circumstances, the eG agent will read the secondary manager information configured in the eg_managers.ini file, and will try to connect to every secondary manager in the cluster in the same order in which they have been listed in the ini file. The agent will finally start reporting the measure data to the first manager it establishes a connection with.
The agent will continue reporting measures to the new manager, until its original manager becomes available. Once a manager in the cluster becomes available, every other manager in that cluster will be informed of this change in status. Once the manager to which the agent is currently reporting comes to know that the original manager is online, it alerts the corresponding eG agent, which will then switch back to the original.
When one manager in the cluster is down, does the other manager in the cluster store data for this manager and then send the data back when the manager comes up?
When a manager is offline, the other manager receiving data from agents can be configured to store the data that they receive 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.
The amount of data that can be stored by a manager for transmission to the other offline manager 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 the other manager that is offline. 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 other managers 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.
It is recommended that this storage specification be small.
The maxStoragePerFile and filesPerManager settings govern how much “measurement data” can be stored by a manager for transmission to other offline manager. It does not however govern “configuration data” - in other words, if configuration changes are made to a manager (using the eG administrative interface) during such time that the other managerin the redundant cluster is offline, then all these changes, regardless of size, will be automatically stored by a manager for transmission.
How does state computation happen in a cluster - is the state of the target infrastructure shared between the managers in the cluster?
No. The state of the target infrastructure is not shared between the managers in the cluster. Instead, state computation is performed by the individual managers in the cluster.
When setting up a redundant cluster, do both the managers have to be available first, or can one of the managers be set up first and the second one set up later. If yes, what are the steps involved?
The recommended approach is to have both the managers available and configured in the redundant mode. However, if for some reason, both the managers are not available simultaneously, then do the following:
- Configure the existing manager to function in the redundant mode.
- Install the eG license that supports a redundant manager setup.
- If this manager is set as the primary manager, start it and make configuration changes to it.
- Install and configure the other manager to function in a redundant setup.
- Backup the database of the first manager and restore it to the second manager’s database server.
- Similarly, copy the config files from the first manager to the second manager.
- Start the primary manager and then the secondary manager.
Can configuration changes (administration privileges) be done on both the managers in a cluster?
No. An admin user is authorized to login and make configuration changes to the primary manager only.
Are configuration changes done in one manager automatically propagated to the other manager in the cluster?
Yes. The primary manager will automatically transmit the updated configuration information to the other manager in the cluster.
Will both the managers in a cluster send out email/SMS alerts/trouble tickets when a problem is detected?
The origin of email/SMS alerts/trouble tickets 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.
How about scheduling of reports? Does each manager send out scheduled reports?
In an Active-Active setup, the printing/mailing of a report can be scheduled using both the secondary and primary managers. However, during normal operations, the schedules will be implemented only by the primary manager. If the primary manager is not available, then the scheduled reports will be printed/mailed by the secondary manager.
When an existing non-redundant setup is converted into a redundant setup, when do the agents reporting to the managers become cluster aware?
Typically, if an agent is started only after the redundant setup is configured and running, then the agent will recognize the existence of a cluster as soon as it polls the manager for configuration information.
On the other hand, if agents are already running, and the redundant setup is configured only later, then, soon after the redundant cluster is configured, you should restart all the agents using the Restart all agents button in the agents - status page (Agents -> Status menu sequence) of the eG administrative interface, to ensure that the agent is updated with the changes.
How does agent upgrade happen in a redundant setup?
The agent upgrade patch needs to be copied to both the managers in a cluster. The agents then download the patch from the corresponding manager, and get upgraded, automatically.
- A manager that locally stores the measure data pertaining to an unavailable manager, will send the data to the other manager when it comes online, but will not send the state computations. This could cause discrepancies in the event history and reporter modules across the managers.
- Settings such as mail server settings should be common to all the managers in the cluster. Moreover, all the managers should have access to the resources specified in the settings.
- Managers which are part of a redundancy setup cannot have the same internal IPs, as each manager identifies the other using the internal IP only.