• Deploy and Configure Ops Manager Resources >
• Plan Your Ops Manager Resource

Plan Your Ops Manager Resource

MongoDB Ops Manager is an enterprise application that manages, backs up, and monitors MongoDB deployments. With Ops Manager, you can scale and upgrade MongoDB, optimize queries, perform point-in-time restores, receive performance alerts, and more. To easily manage and maintain Ops Manager and its underlying database, you can use the MongoDB Enterprise Kubernetes Operator to run Ops Manager as a container on Kubernetes.

Before you deploy an Ops Manager resource, make sure you read the considerations and complete the prerequisites.

Architecture

The Kubernetes Operator manages and monitors each MongoDBOpsManager custom resource through a resource definition file that you create. Every time you create or update a resource definition, the Kubernetes Operator performs the following reconciliation process:

1. The Kubernetes Operator creates or updates the StatefulSet that runs the Ops Manager Application Database. The Application Database is always deployed as a replica-set with SCRAM-SHA authentication enabled. Each database pod runs an instance of the MongoDB Agent which is configured directly by the Kubernetes Operator.
2. The Kubernetes Operator creates or updates the StatefulSet that runs the Ops Manager pods. The Ops Manager instance connects to the Application Database.
3. The Kubernetes Operator ensures the StatefulSet for the Backup Daemon Service is running unless backup is disabled. The StatefulSet consists of a single pod. The Backup Daemon connects to the Application Database.
4. The Kubernetes Operator registers the first user with the Global Owner role and saves a public API key to a secret for later use.
5. The Kubernetes Operator configures the Backup Daemon using Ops Manager API according to the spec.backup.enabled specification in the Ops Manager resource definition.

Considerations

Encryption Key

The Kubernetes Operator generates an encryption key to protect sensitive information in the Ops Manager Application Database. The Kubernetes Operator saves this key in a secret in the same namespace as the Ops Manager resource. The Kubernetes Operator names the secret <om-resource-name>-gen-key.

If you remove the Ops Manager resource, the key remains stored in the secret on the Kubernetes cluster. If you stored the Application Database in a Persistent Volume and you create another Ops Manager resource with the same name, the Kubernetes Operator reuses the secret. If you create an Ops Manager resource with a different name, then Kubernetes Operator creates a new secret and Application Database, and the old secret isn’t reused.

Application Database

Topology

When you create an instance of Ops Manager through the Kubernetes Operator, the Ops Manager Application Database is deployed as a replica set. You can’t configure the Application Database as a standalone database or sharded cluster. If you have concerns about performance or size requirements for the Application Database, contact MongoDB Support.

Authentication

The Kubernetes Operator enforces SCRAM-SHA-1 authentication on the Application Database.

The Kubernetes Operator creates the database user which Ops Manager uses to connect to the Application Database. This database user has the following attributes:

Username	mongodb-ops-manager
Authentication Database	admin
Roles	readWriteAnyDatabase dbAdminAnyDatabase clusterMonitor

The Ops Manager database user’s name and roles cannot be modified. However, you can set the database user’s password by creating a secret and can later update the password by editing that secret. If you don’t create a secret, or if you delete a previously created secret, then the Kubernetes Operator automatically generates a password and stores it internally.

If you need to authenticate to the Application Database as a different user:

1. Deploy the Ops Manager resource
2. Add a new user to the database using the mongo shell.

Offline Deployments

The Kubernetes Operator bundles MongoDB Enterprise version 4.2.2 with the Application Database image to enable offline deployments of Ops Manager resources.

To deploy Ops Manager inside Kubernetes without an Internet connection, omit the spec.applicationDatabase.version setting or leave the value empty.

When you upgrade the Kubernetes Operator, the Application Database performs a rolling upgrade for new patch releases of MongoDB, such as from 4.2.2-ent to 4.2.3-ent. However, the Application Database does not automatically upgrade between major versions, such as from 4.2.2-ent to 4.4.0-ent.

Backup

Kubernetes Operator enables Backup by default. The Kubernetes Operator deploys a StatefulSet comprised of one pod to host the Backup Daemon Service, and then creates a Persistent Volume Claim and Persistent Volume for the Backup Daemon’s head database . The Kubernetes Operator uses the Ops Manager API to enable the Backup Daemon and configure the head database.

Important

To configure Backup, you must create MongoDB database resources for the oplog store and S3 snapshot store. The Ops Manager resource remains in a Pending state until these Backup resources are configured.

Oplog Store

You must deploy a three-member replica set to store your oplog slices.

If you enable SCRAM authentication on the oplog database, you must:

• Specify a MongoDB version earlier than v4.0 in the oplog database resource definition.
• Create a MongoDB user resource to connect Ops Manager to the oplog database.
• Specify the name of the user in the Ops Manager resource definition.

S3 Snapshot Store

To configure an S3 snapshot store, you must:

• Have an oplog store already configured.
• Create an AWS S3 or S3-compatible bucket to store your database Backup snapshots.
• Deploy a three-member replica set to store snapshot metadata.

You can update any additional S3 configuration settings that are not managed by the Kubernetes Operator through the Ops Manager Application.

Disable Backup

To disable backup after you enabled it:

1. Set the Ops Manager Kubernetes object spec.backup.enabled setting to false.

2. Disable backups in the Ops Manager Application.

3. Delete the Backup Daemon Service StatefulSet:

   copy

   kubectl delete statefulset <metadata.name>-backup-daemon -n <namespace>
   

Important

The Persistent Volume Claim and Persistent Volume for the Backup Daemon’s head database are not deleted when you delete the Backup Daemon Service StatefulSet. You can retrieve stored data before you delete these Kubernetes resources.

To learn about reclaiming Persistent Volumes, see the Kubernetes documentation.

Ops Manager Application Access

By default, the Kubernetes Operator doesn’t create a Kubernetes service to route traffic originating from outside of the Kubernetes cluster to the Ops Manager application.

To access the Ops Manager application, you can:

• Configure the Kubernetes Operator to create a Kubernetes service.
• Create a Kubernetes service manually. MongoDB recommends using a LoadBalancer Kubernetes service if your cloud provider supports it.
• If you’re using OpenShift, use routes.
• Use a third-party service, such as Istio.

The simplest method is configuring the Kubernetes Operator to create a Kubernetes service that routes external traffic to the Ops Manager application. The Ops Manager deployment procedure instructs you to add the following settings to the object specification that configures the Kubernetes Operator to create a service:

• spec.externalConnectivity
• spec.externalConnectivity.type

Managing External MongoDB Deployments

When you deploy Ops Manager with the Kubernetes Operator, Ops Manager can manage MongoDB database resources deployed:

• To the same Kubernetes cluster as Ops Manager.
• Outside of Kubernetes clusters.

If Ops Manager will manage MongoDB database resources deployed to different Kubernetes clusters than Ops Manager or outside of Kubernetes clusters, you must:

1. Add the mms.centralUrl setting to spec.configuration in the Ops Manager resource specification.

   Set the value to the URL by which Ops Manager is exposed outside of the Kubernetes cluster:

   copy

   spec:
     configuration:
       mms.centralUrl: https://a9a8f8566e0094380b5c257746627b82-1037623671.us-east-1.elb.example.com:8080/
   

2. Update the ConfigMaps referenced by all MongoDB database resources inside the Kubernetes cluster that you deployed with the Kubernetes Operator.

   Set data.baseUrl to the same value of the spec.configuration.mms.centralUrl setting in the Ops Manager resource specification.

   Important

   This includes the ConfigMaps that the MongoDB database resources for the oplog and snapshot stores reference.

Prerequisites

1. If you have not already, run the following command to execute all kubectl commands in the namespace you created:

   copy

   kubectl config set-context $(kubectl config current-context) --namespace=<namespace>
   

2. Install the MongoDB Enterprise Kubernetes Operator 1.4.1 or newer.

3. Ensure that the host on which you want to deploy Ops Manager has a minimum of five gigabytes of memory.

4. Create a Kubernetes secret for an admin user in the same namespace as the Ops Manager resource.

   When you deploy the Ops Manager resource, Ops Manager creates a user with these credentials and grants it the Global Owner role. Use these credentials to log in to Ops Manager for the first time. Once Ops Manager is deployed, you should change the password or remove this secret.

   copy

   kubectl create secret generic <adminusercredentials> \
     --from-literal=Username="<username>" \
     --from-literal=Password="<password>" \
     --from-literal=FirstName="<firstname>" \
     --from-literal=LastName="<lastname>"
   

5. (Optional) To set the password for the Ops Manager database user, create a secret in the same namespace as the Ops Manager resource.

   The Kubernetes Operator creates the database user that Ops Manager uses to connect to the Ops Manager Application Database. You can set the password for this database user by invoking the following command to create a secret:

   copy

   kubectl create secret generic <om-db-user-secret-name> \
     --from-literal=password="<om-db-user-password>"
   

   Note

   If you choose to create a secret for the Ops Manager database user, you must specify the secret’s name in the Ops Manager resource definition. By default, the Kubernetes Operator looks for the password value in the password key. If you stored the password value in a different key, you must also specify that key name in the Ops Manager resource definition.

   If you don’t create a secret, then the Kubernetes Operator automatically generates a password and stores it internally. For more information, see Authentication.

6. (Optional). To configure Backup to an S3 snapshot store, create a secret in the same namespace as the Ops Manager resource.

   This secret stores your S3 credentials so that the Kubernetes Operator can connect Ops Manager to your AWS S3 or S3-compatible bucket. The secret must contain the following key-value pairs:

   Key	Value
   accessKey	The access key ID of the user who owns the S3 or S3-compatible bucket.
   secretKey	The secret key of the user who owns the S3 or S3-compatible bucket.

   To create the secret, invoke the following command:

   copy

   kubectl create secret generic <my-aws-s3-credentials> \
     --from-literal=accessKey="<AKIAIOSFODNN7EXAMPLE>" \
     --from-literal=secretKey="<wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY>"
   

   To learn more about managing S3 blockstore snapshot storage, see the Prerequisites.

←   Deploy and Configure Ops Manager Resources Deploy an Ops Manager Resource  →

© MongoDB, Inc 2008-present. MongoDB, Mongo, and the leaf logo are registered trademarks of MongoDB, Inc.