Mongo Ops Manager 部署

Mongo 作为 Nosql 的代表,对开发来说,提供了很大的自由度,但对于运维来说,就非常难受。比如没有图形化的监控工具,比如永远他的投票机制和文档上不一样,比如他的备份方案。

当然,他有数据接口,里面有所有和运维相关的数据,也有现成的监控工具,利用这些工具也能还行。但是,但是请和 ES 比一比...

大约 Mongo 自己也意识到了这个问题,在 3.0 发布的同时,也发布了一个管理、监控和备份的服务 MMS。无法理解 MMS 这个服务,难道要把内网的数据库对公网暴露吗?难道 Mongo 希望别人用一个公网的服务做监控,和 管理 以及 备份?这安全性和速度(数据备份和恢复)怎么保证?

还好 Mongo 将 MMS 背后的工具也 免费 发布了,这里,说的就是我部署的过程。

基本概念

Ops Manager 其实就是 MMS,只是可以自己部署,官方文档在这里

MMS 由 3 大块组件构成

  • MMS HTTP Service
    • 用于监控和管理
    • 需要有一个既能访问 MongoDB 服务,又可以访问 MMSS HTTP Service 的代理
    • 自身需要有一个 MongoDB 服务保存信息
  • Backup HTTP Service
    • 用于备份
    • 备份对象不能是 Standalone 的(独立的,没有做 Replica 或 Sharding,因为它通过 oplog 工作)
    • 需要一个和 MMS HTTP Service 类似作用的代理
    • 需要一个和 MMS HTTP Service 类似作用的 MongoDB 服务
    • 需要磁盘空间保存备份对象的快照(Snapshot)
    • 有一个独立的 Backup daemon 进程,用于生成快照。
  • Backup Alert Service
    • 用于通知,没有详细研究

MMS 服务本身需要使用 MongoDB,这个数据库的版本大于等于被宿主数据库的版本即可。但,备份服务需要有一个和宿主数据库相同的 Mongo 程序放在指定位置,后面会提到。

管理/监控和备份服务,各需要一个代理,这 2 个代理会访问宿主数据库,传递数据,对宿主数据库来说,他们相当于不可见的 Secondary。

数据库备份的快照,最快 6 小时生成一次,不能更快,也无法手动生成。

数据库的恢复,详细文档可以看这里,大致过程,是从 MMS 管理网页上,选择快照(Snapshot),下载,按照文档文档提示一步步恢复,期间 不能 相应请求。快照的时间间隔决定最多会有 6 小时的数据丢失,为了解决这个问题,MMS 有一个机制:如果是恢复一天内的,可以指定精确的时间(精确到分钟),但这样 MMS 需要一定的时间生成恢复文件下载链接,而且MMS 服务器需要额外的磁盘空间。

部署

为了方便测试,MMS 提供了测试部署方案,也就是把所有 HTTP 服务,MongoDB 服务,备份 Daemon 服务放在一台服务器上,具体可以看这里

可能是没考虑轻量级用户的需求,Mongo 提供的方案,都是可以容纳几百个 MongoDB 服务(每个服务是一个完整 Sharding 或 Replica)的,要求高可靠性,高性能,因此文档上对机器的要求都比较可怕。对轻量级需求,用一般的服务器就可以了,CPU 内存问题都不需很好,硬盘大一点就可以了(看宿主 Mongo 占用的磁盘大小)。

MMS 强制要求两个数据库都有 Primary Secondary 和 Arbiter 至少一个,否则在启动服务时,会报错。

详细的部署文档在这里。说几个我遇到坑:

  • 如上面所说,至少要一个 Secondary,我没配,MMS 服务没启动起来;
  • 启动 Backup daemon 时,文档写 27017,我觉得文档肯定写错了,将数据库配成了 27018,也就是备份服务用的数据库,启动服务不成功,/opt/mongodb/mms-backup-daemon/logs/daemon.log 里一直有 The application version is unknown. Ensure that the MMS HTTP Service of version XXX was started up before the Backup Daemon. Stopping. 的错误。正确的的配置,应该用 MMS 数据库,也就是 27017,27018 这个数据库,是在 MMS 的网页控制台里配置的。
  • 备份服务需要保存快照,配置文件 rootDirectory 的设置,默认存在这里 /var/lib/mongodb/backup/,但这个地方要有足够的空间
  • 我配置好所有服务和代理后,oplog 传完了半天,都没有开始建 Snapshot,以为要到指定的时间,但是也没有。查了 daemon.log,一直有 Could not find mongod matching major verison 2, minor version 4, and maintenance version >= 9 in /opt/mongodb/mms-backup-daemon/mongodb-releases/这样的提示,按照这里的提示,下载了宿主 Mongo 服务对应版本的程序,放到这里,才开始正常建快照。

搭建好服务后,就可以访问控制台,需要注册账号(竟然还要注册..),按照提示添加代理就可以了,添加代理的过程是最舒服的,完全傻瓜化操作,复制粘贴命令就行,也有验证的按钮可以用。

MMS 是比较新的服务,做的还是不错,问题不多,但有问题时,也很难 Google 出来。

最后,最好不要将这个服务放到公网上,不知道有什么漏洞,一定要放的话,务必限制好端口的访问。

标签: none

添加新评论