Chat now with support
Chat with Support

Foglight 5.9.2 - Federation Field Guide

Planning for federation

* 
CAUTION: Before setting a more rapid refresh rate, it is prudent to consider the volume of alarms and potential performance impact of frequent alarm queries on the Federated Children.
 
* 
NOTE: Federation is an advanced feature, which requires a dedicated Management Server. Contact Quest PSO to design and implement a federation strategy.

When planning to deploy the federation feature, customers must respect the following practical considerations:

•
No agents may report directly to the Management Server.
If customers require monitoring of the Management Server OS/host/database, they must do it from a Federated Child.
•
Consideration must be given to service names.
Services on Federated Children sharing the same name are joined in the Federation Master (for example, if on Federated Child A, a user has created a service Foo, and on Federated Child B, another user has created a service Foo, then both services are merged in the Federation Master to service Foo, which contains any logical components included in either A or B).
•
Connectivity.
•
Scalability.
•
Service models and where they will be built.
•
Administration of the Federation Master.
Administration does not propagate in any way (Federated Child to Federation Master, Federation Master to Federated Child).
•
Cartridge versions (the Federation Master must have a super set of all installed cartridges in all Federated Children).
•
Co-locating all Management Servers is essential in order to ensure low network latency between them. Placing Management Servers in different data centers could affect dashboards on the Master Server as a result of WAN latency. Preventing a network lag between Federation Master and Child servers is therefore critical:
•
10 ms or lower in most cases leads to optimal results.
•
10 ms to 100 ms might be acceptable, depending on the complexity and frequency of browser interface requests.
•
100 ms and higher is likely to result in significant slowness.

Communication ports

To ensure that the federation setup works correctly, the Federation Master must open a certain set of connections to each Federated Child. When a firewall exists between the Federation Master and the Federated Children, the appropriate ports must be opened.

Federation connections are always established in the Federation Master to Federated Child direction. Once a connection is established, data transfer is bidirectional.

The Federation Master uses the RMI 1099 port during the connection setup process. In the server.config file of each Federated Child, specify the server.federation.port property to identify this port number.

 
 
* 
IMPORTANT: Starting in version 5.9.2, Foglight™ for Java EE Technologies no longer supports Nexus Federation. Without Federation, all application servers that could possibly participate in servicing the same request (through RMI or other remote calls) should be connected to the same Nexus.

HA considerations

High Availability (HA) mode enables you to install multiple servers, where one server is the primary server and the others are standby servers. If the primary server stops responding, then the responsibility is taken over by one of the standby servers.

Only the Federated Children can be run in High Availability mode. Running a Federation Master in HA mode is currently not supported.

In a federated environment with two or more Federated Children working in HA mode, the Management Server automatically chooses the primary Federated Child for data synchronization.

Configuring a federated environment

The Federation Master is a Foglight™ Management Server that has been configured to incorporate the data of federated instances. A Federation Master can not be utilized as any other Management Server (for example, no connected clients, agents, standard rule analysis).

When installing a Management Server, federation is by default disabled. When you install a Management Server, the server does not know if it is going to operate as a Federation Master or as a normal server. The server identifies this only on startup, by checking the server.federation variable in the server.config file. If this variable is set to TRUE, the server makes a number of changes that are necessary for it to run efficiently (given a certain load).

A Federation Master must always be started with server.federation variable set to TRUE. If a Federation Master starts up, even just one time, as a normal server, it makes modifications to the server that deplete its performance as Federation Master.

 
* 
CAUTION: If you accidentally start the server with this variable set to FALSE, you must then either restore from a backup (if you have one), or completely re-install the Federation Master and database.

When upgrading a Federation Master, you must first verify that the server.federation variable was not changed to FALSE before you restart the server.

 
* 
IMPORTANT: Starting in version 5.9.2, the Cartridge for Java EE Technologies no longer supports Nexus Federation. Without Federation, all application servers that could possibly participate in servicing the same request (through RMI or other remote calls) should be connected to the same Nexus.
Related Documents

The document was helpful.

Select Rating

I easily found the information I needed.

Select Rating