General deployment concepts and recommendations

BMC Database Automation is designed to dramatically streamline the process of building, patching, and maintaining database environments. Organizations of all sizes have implemented the system for their database infrastructure. They often have questions about how the components of the solution make up a typical implementation, and the best practices for deploying the software. This topic provides an overview of how the different components that comprise BMC Database Automation can be effectively implemented in your environment.

BMC Database Automation has a fairly standard architecture for enterprise software of this nature — there is one or more central consoles, known as Managers, with a set of Agents connected to each Manager. The Manager acts as the business logic of the operation, as well as a storage depot for automation content. The Manager creates jobs and sends the workflows over the network to the desired Agents, which then execute the commands and report back to the management server.

The user interface mechanism is web-based, with the GUI running on the BMC Database Automation Manager. There is also a SOAP-based API that users can use to launch jobs outside the GUI context.

Deployment considerations

The following sections detail important considerations for deploying the key components in BMC Database Automation.

Manager

The Manager, as the central brain of a BMC Database Automation implementation, is often the first tier planned for during an implementation. Currently, all of the individual components that make up a Manager (dmanager, mtd, postgresql, httpd) must be run on the same server. While this server can be a VM, BMC recommends running the Manager on dedicated physical hardware. In addition, the Manager must be running either Red Hat Enteprise Linux 4, 5 or 6 (RHEL5 and 6 are 64-bit only).

For a detailed list of requirements, see System requirements. For sizing recommendations, see the Sizing and scalability.

As a general guideline, BMC recommends that BMC Database Automation be installed on the Manager into a dedicated partition that is on SAN or other RAID-protected infrastructure. This partition should be mounted on /app/clarity, and should be sized appropriately for your implementation. In addition, for large production environments, it might be beneficial to cluster the Manager using a third-party clustering solution. For best practices on how to do this, see High availability Similarly, there are mechanisms to prepare the Manager for disaster recovery scenarios. These mechanisms are described in Disaster Recovery.

Multi-Manager

Multi-Manager is a configuration of multiple BMC Database Automation Managers where one centralized Content Manager communicates with one or more Satellite Managers, enabling various benefits to your environment. For more detailed information on these benefits, see Multi-Manager configuration and the best practices for planning a Multi-Manager configuration.

Agents

BMC Database Automation Agents are, as stated previously, installed once per managed server. As part of the same architecture decision, the Agent is bundled for each platform as an OS package — for example, on Red Hat Linux, it is an RPM, on Solaris, a PKG, and so on. This allows administrators to easily install the Agent using whatever OS package management tool they have already invested in (such as BMC Server Automation).

After the Agent is installed, the only post-installation configuration is to edit the dagent.conf, located in /etc under the Agent install directory and specify the host name of the Manager to connect to.

The standard installation directory of the Agent is configurable on Microsoft Windows, and on other OS defaults to /app/clarity/dagent. The Agent installation will honor symbolic links, however, so it is possible to symlink /app/clarity to, for example, /opt/clarity, and then install the Agent. The Agent will be placed in the /opt/clarity directory. If the installation directory needs to be customized on Linux or UNIX, contact BMC Database Automation customer support.

The dagent.conf also contains the failover related instructions for when to failover and connect to one or more alternate Satellite Managers in a Multi-Manager configuration. For more information, see Configuring failover period on Agents.

Data warehouse

The BMC Database Automation data warehouse is an optional Oracle database that is used to store historical configuration, asset, and job information for reporting purposes. While it is possible to run the data warehouse on the same computer as a Manager, for production BMC strongly recommends that the data warehouse run on dedicated hardware. The database can be on any platform, as long as the version of Oracle is later than 10.2.0.3.

The data warehouse can be used to store information from multiple BMC Database Automation Managers, allowing organizations that have independent Managers to aggregate that information for global reporting purposes. Because the data in the data warehouse is also available for general consumption, it is often used to integrate into other systems, such as enterprise CMDBs or asset management systems. The data warehouse is also required for reporting, using the following reporting system:

• Reporting functions provided by BMC Database Automation. For more information, see Managing reports.

For sizing and scale recommendations, see Sizing and scalability.

General considerations

The following sections detail additional items you should consider when deploying BMC Database Automation.

Network access

Network connectivity is critical to the correct operation of BMC Database Automation, because the Agents and Manager need reliable access to each other in order to launch jobs and properly collect status. While it is possible to have geographically disparate Agents connecting to a central Manager,  BMC recommends that architects review the Sizing and scalability guides for minimum performance requirements for the network connectivity.

The type of connections between the Agents and Manager are bidirectional. The Agents connect to the Manager on startup and maintain an open connection, and the Manager connects out to the Agents to launch jobs. There is also a network heartbeat once a second that reports up/down status from the Agent to the Manager. Connections are made on the following ports by default:

• 7003 TCP Agent->Manager
• 7004 TCP Manager->Agent
• 7001 UDP Manager <-> Agent

Any firewalls between the Manager and the Agents need to have rules added to permit the traffic between these port combinations. If these ports need to be changed to accommodate the planned implementation, contact BMC Database Automation Customer Support.

Content delivery

By default, certain types of content are delivered from the management server to the Agent over the standard communications channel, including  content the Agent expects to find locally available on its file system. Types of content:

• Oracle Installers and Patchsets (non-Windows) - Local
• Oracle Patches — Manager
• Sybase Media — Local
• Sybase Patches — Manager
• SQL Server Installers and Patches — Manager
• Oracle Installers and Patchsets (Windows) — Manager
• Actions — Manager
• Updated OPatch — Manager

For the content that is expected to be found locally, a common architectural design is to have an NFS server or set of NFS servers available on the network, and have them mounted on the target computers. For specific locations for the various media, see Loading database media.

It is possible to change the default behavior of content delivery through custom integration and pre-scripts and post-scripts for jobs. If that is necessary in the environment, contact BMC Customer Support.

Time zones

BMC Database Automation uses the Manager's time zone and current time for reporting purposes. Agents can use local or a centralized timezone. The most important consideration is that the time skew between Agents and Managers stays consistent, because sudden changes of the Manager's clock compared to the Agent's clock can cause issues with job execution and log collection. This is typically only seen in environments where the Manager is running on a VM that does not have its time managed by NTP or another source.

Agent and root privileges

The nature of the operations performed by the Agent requires that it run as root. Provisioning (especially in clusters), patching and many of the pre-flight checks contain commands that need to be performed as root. When running commands as the database user, as is done for some provisioning functions, the agent uses su to switch context to the required user account. For all other operations, the agent assumes it can run them as root. Attempting to run the Agent by using a non-root account will inevitably lead to failures when these operations are performed. With good governance practices in place, the role-based access controls (RBAC) included in BMC Database Automation can be used to control access to all activities that the Agent executes as root. For more information about security planning using RBAC, see RBAC access control.

Command privileges

In order to perform certain administrative operations, you might need to execute certain commands inside a shell on the BMC Database Automation manager. In some cases, these commands must be run by the root user, while in other cases the operations can be performed by a less privileged user.
See the BMC Database Automation (BDA) Command Privilege Overview document for more information.