Foglight Agent Manager 6.3.0 - Foglight Agent Manager Guide

Configuring multiple Agent Manager instances

The files related to the Agent Manager’s run-time state (for example, configuration and log files), are saved in the <fglam_home>/state/ directory tree. Under the state directory, there is a sub-directory for each available Agent Manager instance.

You can run multiple instances of the Agent Manager using a single Agent Manager bin directory.

CAUTION: Running multiple instances of the Agent Manager on the same host is intended for cluster and failover support only and is not intended to be used for any other purposes. Installing separate instances of the Agent Manager on the same system is therefore neither recommended nor supported.

In this type of configuration, you create multiple instances and each instance uses a different state directory but runs from a single Agent Manager bin directory. One example of this type of configuration is to test new agent settings without making changes to the agents you are currently using to monitor your production environment.

CAUTION: In a configuration where multiple Agent Manager instances share one bin directory, each time you deploy agents, upgrade agents, or deploy Agent Manager upgrades to one instance, all other instances are also updated.

You can also configure multiple physical installations of the Agent Manager to use a corresponding state directory that exists on a single shared drive. One example use of this functionality is running the Agent Manager in cluster environments. See Example: Running multiple instances in a cluster environment for more information.

As described below, you create a new instance (and its associated state sub-directory) by including the --create-state and --location "<state_name>" (or -l "<state_name>") options with the fglam command; you then use the fglam ‑‑location "<state_name>" command to run that new instance.

CAUTION: The --create-state and --location command-line options are not recommended for use with the embedded Agent Manager, because the embedded Agent Manager does not include its own JRE. Instead, it is configured by the Management Server to use the same JRE that the Management Server uses.Since the Management Server is not aware of additional state directories that you may have created, it cannot properly configure them. Instead, you need to manually configure and maintain the JVM location in the Management Server installation.

If you do not create multiple instances (by following the instructions below), the Agent Manager creates an instance called default and stores the state files in the state/default directory.

IMPORTANT: On UNIX® platforms, the entire Agent Manager installation — including all state directories — must be owned by the same system user.

When you deploy agents to the instance, files related to the run-time state for these agents (including log files) are stored under the <fglam_home>/state/<state_name>/agents directory for that instance.

Example: Running multiple instances in a cluster environment

IMPORTANT: This section is provided as an example only. The commands shown are fully supported, but the example itself does not describe a configuration that is supported as part of the product warranty.

One example use of this functionality is running the Agent Manager in cluster environments, since it allows the next assigned host in the cluster to relaunch an Agent Manager instance—and the specific agents it manages—when cluster failover occurs.

In this type of installation, there are multiple physical installations of the Agent Manager on different failover nodes. When one node fails and shuts down, the next one starts and its Agent Manager instance accesses the latest changes stored in its state directory on a shared drive.

The process of running multiple Agent Manager instances in a cluster environment follows the outline presented below.

Begin by installing the Agent Manager on each node in your cluster. See Installing the Agent Manager for installation instructions.

When the Agent Manager installation is available to the nodes in the cluster, the next step is to initialize a state directory for an instance on the shared drive that is used by the cluster. When setting the state location locally from one of the nodes, you must define the full path to the remotely-mounted state directory.

In the following example, <state_dir> is a path to a state directory on a shared network server that is accessible locally from all machines. For example: on Windows clients, the <state_dir> can be f:\cluster_shared_dir\fglam_states\STATENAME_A, while on UNIX® clients, it is /mnt/cluster_shared_dir/fglam_states/STATENAME_A.

fglam --create-state --location <state_dir>

NOTE: When you provide a full path with the --location parameter, the state directory can be located anywhere on the shared drive, it does not need to be in a subdirectory of an Agent Manager installation.

Run the Agent Manager from the active node and provide the full path to this instance’s state directory on the shared drive. For example:

fglam --location <state_dir>

The files related to the Agent Manager instance’s run-time state—for example, configuration and log files—are stored under its remote state directory on the shared drive.

When the Agent Manager is running, you can deploy agents to it and create agent instances. Files related to the run-time state for these agents (including log files) are stored under the remote state directory for this Agent Manager instance. Using the example above, they are stored in <state_dir>.

Ensure that only one instance of the Agent Manager that uses a particular state directory is running at a time. Do not run two instances of the Agent Manager on separate machines (or separate active nodes in the cluster) and cause these instances to use the same shared state directory simultaneously.

Controlling the polling rate

The FglAMAdapter, a component included with the Management Server, controls how often the connected downstream Agent Managers and agent instances connect and poll for messages. In general, the more hosts that are connected to the server, the less often they should be instructed to poll. The properties included with the FglAMAdapter control the polling behavior. They can be found on the Agent Properties dashboard. In most cases, changes to these properties are not required. Doing so is only recommended when instructed by Quest Support.

The polling rate is controlled by the following properties:

For more information about the Agent Properties dashboard, see the Administration and Configuration Help.

Configuring the Agent Manager to work in HA mode

High Availability (HA) mode is a configuration in which multiple Agent Managers work together in an HA Partition, where one Agent Manager is a primary host (HA Primary), and others are standby hosts (HA Peers). When configured, agent instances whose types are configured as HA Aware and belong to the same HA Partition are managed by the HA Primary host. If that Agent Manager stops responding or goes offline, the agent instances fail over to another Agent Manager.

Under a configured HA Partition, a common deployment set of agent types is kept in sync across all HA Peers. Agent packages deployed to that HA Partition are checked for any HA Aware agent types. Any detected HA Aware types are automatically deployed to all other HA Peers.

The FglAM Adapter monitors the deployments of the each Agent Manager host within the named HA Partition. The HA Primary is considered the master in terms of the deployment set and automatically deploys (or undeploys) HA Aware cartridges to each HA Peer. This also happens during cartridge upgrades, when the Adapter automatically pushes out the updates to all of the HA Peers in that HA Partition.

CAUTION: Do not create Agent Manager HA clusters on Agent Manager installations that already contain agent packages. Doing so causes any HA-aware packages, that only exist on the secondary node, to become automatically undeployed. This is because the primary node controls the deployment all HA-aware packages.