Multi-Manager configuration

Multi-Manager is a configuration of multiple BMC Database Automation (BDA) Managers where one centralized Content Manager communicates with one or more Satellite Managers (known as a mesh). This configuration enables the following benefits:

• Synchronization of content to ensure consistent content across Satellite Managers. Content includes Actions, patch packages, templates and RBAC/user information.
• Centrally manage domains. Use the Content Manager to create and remove domains. The domain tree and any changes are replicated across all Satellite Managers.
• Built-in failover. If a Satellite Manager goes down or stops responding to Agents, its Agents can be configured to temporarily report to an alternate Satellite Manager.

In a scenario where you want more than one Manager with the exact content (including Actions, patch packages, templates and RBAC information), as well as the exact domain structure, a Multi-Manager configuration is a good solution. If you need to create or edit any content on a per-Manager basis, or require a different domain structure or users per Manager, a Multi-Manager configuration is not an appropriate solution. Although there is not a requirement for the number of Satellite Managers to be configured with a Manager, the most common configuration includes three Satellites (one Home or primary satellite) and one Content Manager in the mesh, as illustrated in the following architecture diagram:

_{click the image to expand}

The Manager software is installed on multiple hosts when the Manager function is implemented in a Multi-Manager configuration. Control of the Multi-Manager environment is provided by the Content Manager, which communicates and synchronizes with one or more Satellite Managers. This group of Managers is referred to as a mesh. The Satellite Managers connect to the Agents. The nodes, clusters, and databases are displayed on the associated Satellite Manager. The Satellite Manager that an Agent connects to is called the Primary (Home) Satellite Manager. Any content to be acted on by a Satellite Manager, such as Actions, templates, or patch packages, is created and stored in the Content Manager.

Multi-Manager configuration components include the following:

• Content Manager: The Manager that communicates with and synchronizes the content to all Satellite Managers in a Multi-Manager configuration. Agents never connect to this Manager.
• Domain tree: The hierarchy of domains in BMC Database Automation managed by the Content Manager.
• User Information: Information pertaining to users, groups, roles, and grants on domains managed by the Content Manager.
• Satellite Manager: A manager that agents connect to. Nodes, clusters, and databases are displayed on a Satellite Manager. Jobs are run on this type of Manager. Satellite Managers receive content from the Content Manager (therefore, content cannot be managed directly on a Satellite).
• Primary (Home) Satellite Manager: The primary (Home) Satellite Manager that an Agent is configured to report to.
• Alien Agent: An Agent that is temporarily connected to an alternate Satellite Manager after a failover event occurs.

Management and synchronization of content

The Content Manager stores, manages, and replicates user information, templates, Actions, and patch packages and automatically synchronizes new and changed content with the Satellite Managers. Polling is performed at 1 minute intervals.

Separately, information from Satellite Managers (including activities such as approving nodes and databases into domains), is updated in the Content Manager’s dstate as soon as those activities occur. The domain hierarchy is also managed by the Content Manager and propagates to available Satellite Managers. Nodes, clusters and databases never connect directly to the Content Manager. Approving objects such as nodes and databases are performed on Satellite Managers. Additionally, jobs such as provisioning, patching and Actions are run on Satellites.

When the Content Manager is down, you cannot run any jobs that create entries in the tree (for example, create DB). Jobs that remove entries from the tree can be run, and those changes are queued and sent to the Content Manager once it is available again. You can always run Actions and apply patches when a Content Manager is down, since that doesn’t affect the tree. Removing Satellite Managers from the mesh also breaks the connection with the Content Manager. For more information, see Detaching a Satellite Manager from the mesh.

Logs for the Content Manager and Satellite Managers are located in the following directories:

/app/clarity/dmanager/var/log/dmanager

/app/clarity/dmanager/var/log/MiddleTier.log

/app/clarity/dmanager/var/log/mtd.log

/app/clarity/var/log/slony/slon.log

Backup and Restore

In a Multi-Manager environment, perform a backup in the following order:

1. Back up all Satellite Managers
2. After the backup has completed on the satellite managers, back up the Content Manager

For more information about recovering managers in a Multi-Manager environment, see Performing disaster recovery for Multi-Manager environments.

High Availability environments

In a Multi-Manager environment, agents can be configured to fail over to alternate Satellite Managers.The dagent.conf contains the failover related instructions for when to failover and connect to one or more alternate Satellite Managers. The dagent.conf file is a comma-separated list of the fully qualified name of one or more Satellite Managers. The first entry in the file is the Primary (Home) Satellite Manager, and failover is performed in order. If dagent gets to the end of the list without connecting to a manager, it starts at the beginning of the list of Satellites again.

Patch candidate information is not up to date after nodes failed over to a different Satellite Manager. BMC Database Automation Collectors run automatically on a periodic basis. If you need this information updated immediately after a failover, you can Run Oracle Patch Collector by hand (in the Nodes Configuration page in the GUI of the Satellite Manager).

Agent failover activity is logged in /app/clarity/dagent/var/log/dagent on Linux and Unix systems, and in the installation directory on Windows (for example C:\Program Files\GridApp Systems\Clarity\agent\dagent.log).

For more information about configuring failover, see Configuring failover period on Agents.