FAQ: Automation
On this page
- What versions of MongoDB does Cloud Manager manage?
- How does Cloud Manager manage MongoDB deployments?
- How does Cloud Manager perform maintenance on cluster nodes?
- How many agents do I need?
- Is any MongoDB data transferred by the agent?
- Will Cloud Manager handle failures during an upgrade?
- What types of deployment can I create in Cloud Manager?
This addresses common questions about Cloud Manager and its Automation features.
Cloud Manager can automate management operations for your monitored MongoDB processes, allowing you to reconfigure, stop, and restart MongoDB through the Cloud Manager interface.
Cloud Manager Automation can run only on 64-bit architectures.
What versions of MongoDB does Cloud Manager manage?
For specific Cloud Manager functions and supported MongoDB versions, see MongoDB Compatibility Matrix.
How does Cloud Manager manage MongoDB deployments?
After you provision servers in Cloud Manager or deploy the agent in the environment of the MongoDB deployment, each agent periodically communicates with Cloud Manager and performs any required work.
Agents constantly reassess their environment to adapt their work as necessary. As part of this routine activity, the agent establishes frequent short-lived connections to the cluster members. If an agent encounters an issue, such as network connectivity problems or Cloud Manager failure, the agents adjust their work to compensate and safely arrive at their goal state.
Agents create plans to move from their current state to a goal state. Plans execute in steps, where each step is autonomous and independent of other steps.
Example
For an installation, the plan involves downloading MongoDB, starting the process with the appropriate command line options, initializing the replica set, waiting for a healthy majority. The configuration reaches goal state when the replica set is active and has a healthy majority.
How does Cloud Manager perform maintenance on cluster nodes?
Cloud Manager performs a rolling restart when you perform maintenance on nodes in a cluster. The agent updates nodes in a cluster one-by-one, always maintaining a primary node, until all nodes are updated to maintain cluster availability during a maintenance period.
For each secondary node in the cluster, the agent:
Restarts the
mongod
process running on the node instandalone
mode.Performs the maintenance task.
Restarts the
mongod
process running on the node inreplSet
mode.
After the secondary nodes are updated, the agent:
Steps the primary down using the rs.stepDown() command.
Triggers an election for a new primary node.
Performs the maintenance task on the former primary node.
Restarts the
mongod
process running on the former primary node inreplSet
mode to join the cluster as a secondary node.
In Cloud Manager, the agent performs rolling restarts on cluster nodes for maintenance tasks, including the following:
Rotating KMIP keys.
Rotating keyfiles.
Changing
mongod
configuration arguments.Upgrading or downgrading TLS,
auth
, orclusterAuth
mode.Changing the MongoDB version.
Changing the oplog size.
Removing a process from a replica set.
Cancelling a restore from backup.
Enabling the Profiler
How many agents do I need?
To use Automation, you must have an agent running on every host where a managed MongoDB instance runs.
Is any MongoDB data transferred by the agent?
Agents do not transmit any data records from a MongoDB deployment. The agents only communicate deployment configuration information and MongoDB logs.
Will Cloud Manager handle failures during an upgrade?
Generally speaking, yes. The design of the management and automation components of Cloud Manager do not account for all possible failures; however the architecture of the system can work around many types of failures.
What types of deployment can I create in Cloud Manager?
Using Cloud Manager, you can configure all MongoDB deployment types: sharded clusters, replica sets, and standalones.
The shards in a sharded cluster must be replica sets. That is, a shard cannot be a standalone mongod. If you must run a shard as a single mongod (which provides no redundancy or failover), run the shard as a single-member replica set.
Can I deploy MongoDB to a cloud provider with Cloud Manager?
Yes. See Provision Servers.
How does an AWS security group affect access to MongoDB instances?
The AWS security group affects whether MongoDB instances can
communicate with each other within the deployment and affects access to
the deployment from MongoDB clients, such as mongosh
or a
driver. For complete
documentation on configuring security group rules for Cloud Manager access,
see Firewall Configuration.