MongoDB Ops Manager 是任何企业 MongoDB 部署的必需组件。MongoDB Ops Manager 可实现 MongoDB 数据库的自动化、监控和备份。MongoDBOpsManager 自定义资源定义三个组件:
MongoDB Ops Manager 应用程序 — MongoDB Ops Manager 的主要组件和前端用户界面。
应用程序数据库 — 即MongoDB Ops Manager的后端MongoDB数据库。
备份守护程序 — 在备份和恢复过程中支持 MongoDB Ops Manager 应用程序。
Kubernetes 操作符 托管 MongoDBOpsManager 资源的规范。当规范发生变化时,Kubernetes 操作符 会验证这些更改,并在部署 MongoDB Ops Manager 组件的每个 Kubernetes 集群中应用适当的更新。
下图显示单个 Kubernetes 集群上 Ops Manager 部署的架构:
应用程序数据库
对于应用程序数据库, Kubernetes 操作符 将MongoDB副本集部署为 StatefulSet 。应用程序数据库的每个 Pod 都包含以下容器:
mongod — 数据库进程。
MongoDB Agent — 托管
mongod生命周期。您可以使用$AGENT_IMAGE环境变量或 Helm 图表中的agent.version来覆盖 MongoDB Agent 版本。监控代理 — 将监控数据发送到 MongoDB Ops Manager。版本会自动选择以实现向后兼容,且不能被覆盖。
Kubernetes 操作符 通过挂载到每个 Pod 的 Secret (<om_resource_name>-db-config) 将应用程序数据库配置传递给代理。
Kubernetes 为每个节点创建一个 Pod。每个 MongoDB Agent 启动 mongod,并将其添加到副本集。The Kubernetes 操作符 creates PersistentVolumeClaims for each Pod, and you can customize them using spec.applicationDatabase.podSpec.persistence。
Kubernetes 操作符 会创建一个无头服务以实现内部连接。在多集群部署中,Kubernetes 操作符 还会为每个 Pod (<om_resource_name>-db-N-svc) 创建一个服务,以实现单个 mongod 可对地址。
应用程序数据库拓扑结构考虑事项
要选举主节点,应用程序数据库副本集的大多数节点必须可用。如果可能,请使用奇数个 Kubernetes 成员集群,并将节点分布到数据中心、区域或集群。
考虑以下分布示例:
五节点应用程序数据库,两个集群:将 3 个节点放在集群 1 中,将 2 个节点放在集群 2 中。如果集群 2 失败,集群 1 将拥有大多数。如果集群 1 失败,集群 2 将不拥有大多数。
五节点应用程序数据库,三个集群:将 2 个节点分别放入集群 1 和 2,将 1 放入集群 3。任何单集群失败都会留下大多数。
七节点应用程序数据库,两个集群: 将 4 放在集群 1 中,将 3 放在集群 2 中。只有集群 2 的损失才能保持大多数。
要了解更多信息,请参阅 副本集部署架构 和 MongoDB Ops Manager 和 AppDB 资源的灾难恢复。
MongoDB Ops Manager应用程序资源
应用程序数据库进入“正在运行”状态后, Kubernetes Operator 开始部署MongoDB Ops Manager应用程序:
Kubernetes 操作符在每个节点 Kubernetes 集群上配置 StatefulSet。
Kubernetes 为每个 Ops Manager 副本创建一个 Pod。
每个 Pod 包含一个MongoDB Ops Manager应用程序进程。
为使单集群部署具有对 Pod 故障的弹性,请增加 spec.replicas。为使多集群部署具有对数据中心故障的弹性,请将 spec.topology 设置为 MultiCluster,并将实例分布到 Kubernetes 集群。
备份守护程序资源
如果 spec.backup.enabled 为 true,则在 Ops Manager 应用程序达到运行状态后,Kubernetes 操作符将启动备份守护程序。Kubernetes 操作符在每个节点集群上部署备份守护程序的 StatefulSet。Kubernetes 会创建 spec.backup.members 个备份守护程序 Pod。
如果启用备份,Kubernetes 操作符 会在每个节点集群上为备份守护程序的头部数据库创建持久卷声明。您可以通过 spec.backup.headDB 配置头部数据库。
Kubernetes 操作符 调用 MongoDB Ops Manager API,以确保 MongoDB Ops Manager 应用程序的备份配置与自定义资源定义相匹配。请在全局 spec.backup 级别配置 oplog 存储、块存储或 S3 快照存储,而不是在每个集群中进行配置。
您还可以加密备份作业,但如果同一个 Kubernetes Operator 实例没有同时管理 MongoDBOpsManager 和 MongoDB 自定义资源,则会受到限制。
MongoDB Ops Manager 协调
下图描述了 Kubernetes 操作符如何协调对 MongoDBOpsManager CRD 的更改:
协调通过以下步骤进行:
创建或更新
<om_resource_name>-db-config秘钥,包含 MongoDB Agent 用于启动应用程序数据库副本集的配置。创建或更新
<om_resource_name>-db应用程序数据库的 StatefulSet。此 StatefulSet 包含至少三个 Pod。每个 Pod 运行一个 MongoDB Agent,该 MongoDB Agent 会在其 Pod 上启动mongod。配置 Secret 会挂载到每个 Pod。在多集群部署中,StatefulSet 命名为
<om_resource_name>-db-<cluster-idx>(例如om-db-1)。创建或更新
<om_resource_name>Ops Manager 应用程序的 StatefulSet。每个副本都会连接到应用程序数据库。大多数更改都会 trigger 滚动升级。为应用程序数据库启用 TLS 也会触发滚动重启,因为连接字符串会发生变化。对spec.backup的更改不会 trigger 滚动升级。在多集群部署中,StatefulSet 命名为
<om_resource_name>-<cluster-idx>(例如om-1)。通过 Ops Manager API 创建管理员用户,并将凭证保存在
<om_resource_name>-admin-keySecret 中。此步骤仅在初始部署时发生。通过对应用程序数据库 StatefulSet 执行滚动升级来启用监控。这也只在初始部署时发生。
如果
spec.backup.enabled是true,则部署备份守护程序。StatefulSet 命名为<om_resource_name>-backup-daemon(在多集群部署中为<om_resource_name>-backup-daemon-<cluster-idx>)。通过 Ops Manager API 配置备份,以确保备份配置与自定义资源定义相匹配。