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:
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 (or 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:
Hosts that are pending approval on a Primary (Home) Satellite Manager do not transfer to another Satellite Manager if the Primary (Home) Satellite Manager should fail. These hosts continue to attempt to connect to their Primary (Home) Satellite Manager.
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:
In a Multi-Manager environment, perform a backup in the following order:
For more information about recovering managers in a Multi-Manager environment, see Performing disaster recovery for Multi-Manager 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.
When dagent starts up, it always tries to connect to its Primary (Home) Satellite Manager first. Pending hosts do not failover. They continue to attempt to connect to their Primary (Home) Satellite Manager instead.
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.