为首次部署MongoDB做好准备：容量计划和监控-InfoQ



 写点什么

如果你已经完成了自己新的 MongoDB 应用程序的开发，并且现在正准备将它部署进产品中，那么你和你的运营团队需要讨论一些关键的问题：

最佳部署实践是什么？
为了确保应用程序满足它所必须的服务层次我们需要监控哪些关键指标？
如何能够确定添加分片的时机？
有哪些工具可以对数据库进行备份和恢复？
怎样才能安全地访问所有新的实时大数据？

本文介绍了硬件选择、扩展、HA 和监控。在查看详细信息之前，首先让我们处理一个最常见的问题：

部署 MongoDB 和部署 RDBMS 有什么不同？

你会发现 MongoDB 作为一个文档数据库，它和你已经熟悉的关系型数据库分享了很多同样的概念、操作、策略和过程。监控、索引、调整和备份等内容的流程和最佳实践可以应用到 MongoDB。同时如果你想要开始自己的培训，那么可以从 MongoDB 大学中获取到来自于开发者和 DBA 的免费在线课程。

系统性能和容量规划是两个重要的主题，任何部署都需要处理这两个问题，无论是 RDBMS 还是 NoSQL 数据库都是如此。作为规划的一部分我们应该对数据卷（volume）、系统负载、性能（吞吐量及延迟时间）和容量利用建立基线。这些基线应该反映你对数据库在产品环境中执行的工作负载的期望，它们应该随着用户数、应用程序功能、性能 SLA 或者其他因素的变化定期地调整。

基线将帮助你理解系统哪些时候是按照设计运行的，哪些时候可能会影响用户体验质量或者其他决定性系统因素的问题开始浮现。

下面将会讨论关键的部署要素，包括硬件、扩展和 HA，同时还会讨论为了维持最佳的系统性能你应该监控哪些内容。

清楚自己的工作集

在为部署 MongoDB 优化硬件预算的时候，RAM 应该是或者接近于列表的第一位。

为了实现低延迟的数据库操作 MongoDB 中广泛使用了 RAM。在 MongoDB 中，所有的数据都是通过内存映射文件读取和操作的。从内存中读取数据是使用纳秒来度量的，而从磁盘中读取数据则是使用毫秒度量的，所以从内存中读取数据几乎比从磁盘中读取要快了十万倍。

在正常操作期间最频繁访问的数据和索引的集合称为工作集，在理想的情况下它们应该在 RAM 中。工作集可能是整个数据库的一小部分，例如最近的事件所关联的应用程序数据或者最常访问的热门产品。

MongoDB 试图访问数据时发生的页面错误并不会被加载到 RAM 中。如果有空闲内存，那么操作系统将定位到磁盘上的页面并将它们直接加载到内存中。但是如果没有空闲内存，那么操作系统必须将内存中的一个页面写入磁盘，然后将被请求的页面读取到内存中。这个流程比访问已经存在于内存中的数据要慢。

有些操作可能会在不经意间从内存中清除大量的工作集，这样会对性能产生严重影响。例如，对于一个浏览数据库中所有文档的查询而言，如果数据库比服务器上的 RAM 大，那么将会导致文档被读入内存而工作集被写出到磁盘。在项目的模式设计阶段为自己的查询定义合适的索引将会极大地降低这种风险发生的可能性。MongoDB说明操作能够为查询计划和索引的使用提供信息。

MongoDB服务状态命令中包含了一个有用的输出：工作集文档，它提供了一个MongoDB 实例工作集的估算大小。运营团队可以按照给定的时间跟踪实例访问的页面数，包括工作集中最旧的文档到最新的文档之间的运行时间。通过跟踪这些指标我们能够发现什么时候工作集会接近现在的RAM 限制从而积极地采取行动确保系统是可扩展的。

MongoDB 管理服务和 mongostat 能够帮助用户监控内存的使用情况，下面我们将会对此进行详细地讨论。

存储和磁盘 I/O

MongoDB 不需要共享存储（例如存储区域网络）。MongoDB 能够使用本地附加的存储和固态硬盘（SSD）。

MongoDB 中的大部分磁盘访问模式并没有顺序属性，这样做的结果便是客户可以通过使用 SSD 获得巨大的性能收益。我们已经观察到使用 SATA SSD 和 PCI 获得的良好结果和强大的性能。商业 SATA 旋转驱动器可以媲美成本更高的旋转驱动器，这得益于 MongoDB 的非顺序访问模式：应该更有效地使用预算将其用于更多的 RAM 或者 SSD 上，而不是更多地用于昂贵的旋转驱动器上。

在数据文件受益于 SSD 的同时，MongoDB 的日记文件由于其自身的高顺序的写属性成为了快速常规磁盘的一个很好的候选。

大多数 MongoDB 部署应该使用 RAID-10。RAID-5 和 RAID-6 没有提供足够的性能。RAID-0 提供了很好的写性能，但是读性能有限，容错能力也不足。部署的 MongoDB 可以通过副本集（下面将会讨论）提供很强的数据可用性，同时用户应该考虑使用 RAID 和其他因素满足想要的 SLA 可用性。

虽然我们应该设计 MongoDB 系统让它的工作集适合于内存，但是磁盘 I/O 依然是一个关键的性能考虑。MongoDB 会定期地将写操作刷新到磁盘并提交到日记，所以在写负载较重的时候基础的磁盘子系统可能会变得不堪重负。iostat 命令可以用于显示高磁盘利用率和过多的写队列。

CPU 选择——速度还是内核？

MongoDB 的性能通常不会绑定到 CPU 上。因为 MongoDB 很少会遇需要利用大量内核的工作负载，比起时钟速度较慢的多核服务器最好的选择是有更快的时钟速度。

无论是什么系统，测量 CPU 的利用率都是非常重要的。如果观察到 CPU 的利用率很高但是并没有出现磁盘饱和或者页面错误这样的其他问题，那么系统中可能会存在不寻常的问题。例如，一个存在无限循环的 MapReduce 工作或者一个没有建立良好索引就对工作集中的大量文档进行排序和过滤的查询都可能会导致 CPU 利用率的飙升，但是它们却不会引发磁盘系统问题或者页面错误。用于监控 CPU 利用率的工具将在下面介绍。

扩展数据库——何时扩展和如何扩展？

MongoDB 通过一种称为 Sharding 的技术提供了水平扩展能力。Sharding 能够在多个物理分区（称为片）之间分发数据。Sharding 可以让 MongoDB 的部署解决单个服务器的硬件限制而不需要增加应用程序的复杂性，解决的硬件限制包括 RAM 和磁盘 I/O 的瓶颈。

MongoDB**** 自动分片和应用程序的透明度

在系统资源变得有限之前实现分片是非常容易的，因此容量规划和主动监控在需要成功地扩展应用程序时是非常重要的元素。

在下面的场景中用户应该考虑部署一个分片的 MongoDB 集群：

RAM限制：系统活动工作集的大小很快就会超过系统 RAM 的最大容量。
磁盘 I/O限制：系统有大量的写活动，但是操作系统写数据的速度不够快，无法满足需求；同时 / 或者 I/O 带宽限制了数据写入磁盘的速度。
存储限制： 数据集接近或者超过了系统中的单个节点的存储容量。

Sharding 的目标之一就是在多台服务器之间一致地分发数据。如果服务器资源的利用率并不是近似地相等，那么可能会存在引发调度错误的潜在问题。例如，选择一个糟糕的分片键可能会导致不平衡的数据分发。在这种情况下，即便不是所有的但是大部分查询也会被导向到正在管理数据的那个单独的 MongoDB。

另外，MongoDB 可能会试图重新分发文档从而在服务器之间实现更加理想的平衡。虽然重新分发最终会实现一种更加令人满意的文档分发，但是有大量与重新平衡数据相关的工作，这些工作本身就有可能会产生影响导致无法实现预期性能的 SLA。

通过运行 db.currentOp() 命令，你将能够了解集群现在正在执行哪些工作，包括跨分片的文档再平衡。

为了确保数据能够在集群中的所有分片间均匀地分发，选择一个优秀的分片键是非常重要的。MongoDB 文档中包含了一个关于如何选择优秀分片键的教程。

MongoDB 复制集的高可用性

MongoDB 使用本地复制维护复制集之间的多个数据副本。复制集可以通过发现错误（服务器、网络、OS 或者数据库）和自动化故障修复避免停机时间。推荐的做法是：所有的MongoDB 部署都应该配置复制。

（单击放大图片）

使用MongoDB 复制集自恢复

对主节点数据库的修改操作会通过名为_oplog_ 的日志被复制到其他二级节点上。oplog 包含了一个排序的幂等操作的集合，该集合中的操作会在二级节点上重放。oplog 的大小是可配置的，默认是可用磁盘空间的5%。

正如下面的图表所阐述的，可以通过定位副本为服务器、机架、数据中心故障和网络分区提供容错性。

（单击放大图片）

复制延迟是作为正常运行的一部分来监控的。它表示的是将主节点上的一个写操作复制到二级节点上所花费的时间。一定的延迟是正常的，但是如果复制延迟增长，则可能会引发问题。复制延迟产生的典型原因包括网络延迟、连接问题和磁盘延迟（例如二级节点的吞吐量劣于主节点）。

复制状态和复制延迟可以通过 replSetGetStatus命令重新恢复。

日志概述

作为所有部署的一部分，应该监控应用程序和数据库的日志以便发现错误并查看其他的系统信息。将应用程序和数据库的日志关联起来是非常重要的，因为这样才能决定应用程序中的活动最终是否需要对系统中的其他问题负责。例如，用户写入峰值可能会增加写入 MongoDB 的容量，这反过来可能会压垮下面的存储系统。如果没有应用程序和数据库日志的关联，那么可能要花费更多的时间才能够确定写入容量的增长是应用程序的问题而不是运行在 MongoDB 中的某些进程的问题。

MongoDB 监控工具

MongoDB 包含了各种监控工具，让你能够积极地管理系统的运行和性能。

MongoDB 管理服务 (MMS)

MongoDB 管理服务（MMS）提供了云监控和备份服务，帮助用户优化集群、解决性能问题、减轻运维风险。MMS 备份服务将在以后的文章中讨论。

MMS 监控支持图表、自定义仪表盘和自定义警告。MMS 仅需要最低限度的安装和配置。用户在所有的MongoDB实例上安装一个本地代理，该代理会跟踪与数据库使用情况相关的数百个关键的健康指标，包括：

操作数（Op Counters）—每秒钟执行的操作的数量
内存（Memory）—MongoDB 正在使用的数据量
锁百分比（Lock Percent）—写锁消耗时间的百分比
后台刷新（Background Flush）—将数据刷新到磁盘消耗的平均时间
连接（Connections）—MongoDB 当前打开的连接的数量
队列（Queues）—等待运行的操作的数量
页面错误（Page Faults）—磁盘的页面错误数
复制（Replication）—主节点操作日志的长度以及复制延时
日志（Journal）—写入日志的数据量

（单击放大图片）

这些指标会被安全地报告给MMS 服务，告诉它它们是在哪里处理、聚合、通知的，并在浏览器中可视化显示。用户能够容易地根据各种性能指标了解他们集群的健康状况。

硬件监控

Munin node 是一个开源软件程序，它可以监控硬件并报告磁盘和 RAM 的使用情况这样的指标。MMS 能够收集 Munin node 产生的这些数据，并在 MMS 仪表盘中将这些数据和其他数据一起展现给用户。因为每一个应用程序和部署都是唯一的，所以用户应该为磁盘利用率的峰值、网络活动的主要变化和平均查询长度 / 响应时间的增长创建警报。

数据库分析工具

MongoDB 提供了一个性能分析工具，该工具能够记录数据库操作相关的细粒度信息。分析工具可以记录所有事件的信息，也能够只记录那些持续时间超出了配置阈值的事件的信息。分析数据存储在一个固定集合中，用户能够很容易地从中搜索相关的事件——查询这个集合可能比尝试着去解析日志文件更加容易。

其他的监控工具

有各种各样的监控工具让你能够从其他的方面深入理解 MongoDB 系统。

mongotop 是随 MongoDB 提供的一个工具，它能够跟踪并报告一个 MongoDB 集群当前的读、写活动。
mongostat 是随 MongoDB 提供的另一个工具，它为所有的操作提供了一个全面概览，包括更新、插入的计数，页面错误、索引的丢失情况以及很多其他的关系到系统健康的重要指标。
Iostat、vmstat、netstat 和 sar 这样的 Linux 工具也能为深入探索 MongoDB 系统提供有价值的信息。
对于 Windows 环境上的用户而言，性能监控器（Performance Monitor，一个 Microsoft 管理控制台单元）是一个非常有用的工具，可以用来测量各种指标。

如果想要获取更多与监控工具和监控内容相关的信息，可以查看 MongoDB 文档中的监控数据库系统页面。

配置 MongoDB

用户应该将配置选项存储到 MongoDB 的配置文件中。sysadmins 能够通过这种方式在整个集群之间实现一致性的配置。配置文件支持 MongoDB 命令行所支持的所有选项。安装和升级应该通过流行的工具（例如 Chef 和 Puppet）自动完成，同时 MongoDB 社区还提供并维护了这些工具的示例脚本。

一个基础的 MongoDB 配置文件类似于下面的内容：

fork = true
bind_ip = 127.0.0.1
port = 27017
quiet = true
dbpath = /srv/mongodb
logpath = /var/log/mongodb/mongod.log
logappend = true
journal = true

你能够通过文档了解到与 MongoDB 配置选项相关的更多内容。在 MongoDB 文档产品说明页面上还维护着针对操作系统、文件系统、存储设备和其他系统相关主题特定配置的最新建议。

结论

在本文中我们介绍了哪些用于部署关系型数据库的概念、操作和流程可以被直接地应用到MongoDB 上，同时还介绍了硬件选择和部署及监控的最佳实践。另外，有关于所有这些主题的详细讨论可以从 MongoDB 操作指南（一个.pdf 文件）中获取。

关于作者

Mat Keep (@matkeep) 是 MongoDB 产品营销团队的一员，负责为 MongoDB 的产品和服务构建愿景、定位和内容，同时也负责对市场趋势和客户需求进行分析。在就职于 MongoDB 之前，Mat 是 Oracle 公司的产品管理总监，负责 MySQL 数据库在 Web、电信行业、云和大数据方面的应用。在这之后他还在技术供应商和面向最终用户的公司中从事过一系列的工作，包括销售、商业开发与分析、程序员。