在 Google Compute Engine 上部署 MongoDB

本解决方案探讨了在设计、部署和维护 MongoDB 部署时要考虑的因素,还介绍了将部署与各种 Google Cloud Platform 服务集成的方法。

设计 MongoDB 部署架构

本部分将介绍 MongoDB 的主要架构功能,并提供用于部署到 Cloud Platform 的示例架构。

主要概念

副本集

MongoDB 支持通过创建副本集跨多个服务器复制数据。副本集包含以下成员:

  • 一个主实例,其中包含数据集的主副本。当客户端将新数据写入 MongoDB 时,它会将该数据写入主实例。
  • 一个或多个辅助实例,它们维护主实例数据集的其他副本。辅助实例与主实例保持最终一致性

主实例由副本集的成员投票选出。副本集必须具有奇数个投票成员。如果主实例和辅助实例票数相同,则可以添加一个轻量级投票成员(仲裁者),以帮助选出主实例。与主实例和辅助实例不同,仲裁者仅进行投票,不存储数据集的副本。

您可通过多种方式配置辅助实例以支持特定用例。可能的配置包括:

  • 优先级为零的成员:可以将辅助实例的优先级设置为 0,让它永不成为主实例。此类服务器可用于报告或分发读取负载。
  • 隐藏成员:可对应用服务器隐藏辅助实例,以便只有专用客户端才会连接到它。此类服务器可用于报告。
  • 延迟成员:可以指定辅助实例按延迟间隔接收更新。此类服务器可用于将 MongoDB 返回到某个时间点,从而纠正用户错误。

分片

使用辅助实例进行分布式读取时必须小心谨慎。辅助实例仅与主实例保持最终一致性,因此它们可能提供过时的结果。处理过时的结果通常会增加应用的复杂性,而且某些应用无法处理。请考虑改为跨服务器分片数据。

分片是一种数据库分区方法,MongoDB 用它来跨多台机器存储数据。通过跨多个服务器水平扩展数据,您不再受到单个服务器的读/写吞吐量和存储容量的限制。通过创建单独的分片,MongoDB 可以提供严格一致的数据视图,同时跨多个服务器分配读写负载。然后,您可将分片与复制结合使用,以在保持高可用性的同时提高写入吞吐量。

示例架构

跨区域复制

下图演示了分布在多个 Compute Engine 区域中的 MongoDB 副本集。在图中,紫色箭头表示从 MongoDB 主实例复制到辅助实例的数据流。绿色箭头表示从应用服务器写入到 MongoDB 主实例的数据流,以及从 MongoDB 服务器读取到客户端的数据流。

说明分布在多个 Compute Engine 区域中的 MongoDB 复制的图表。

在此示例架构中,区域配置如下:

  • 区域 1 是生产服务器所在的 Compute Engine 区域。最终用户流量中的大部分会到达该区域中的应用服务器。除非发生灾难性中断,否则 MongoDB 主服务器应始终位于此区域。
  • 区域 2 是在地理位置上靠近一小部分但很重要的用户群的 Compute Engine 区域。

在每个区域中,MongoDB 服务器均配置有副本集标记。这些标记让客户端能够按角色而非名称指定所需的服务器。

在区域 1 中,主实例和辅助实例各自运行一个 MongoDB 服务器,且两者大小和配置相同,因为它们都可能被选为主实例。从生产应用服务器读取的负载始终到达该区域中的主 MongoDB 服务器。

在本例中,仲裁者与其他副本集成员均作为成本较低的投票成员部署在同一地区。由于此实例不包含副本集数据并且不处理最终用户流量,因此它未配置数据磁盘,且使用 g1-small 机器类型

区域 2 中的辅助实例的大小和配置与区域 1 中的 MongoDB 实例完全相同,目的是确保它们能够处理工作集大小和应用负载。鉴于其与生产应用服务器的地理距离,如果区域 1 中的实例运行状况良好,则标记为 production 的 MongoDB 实例绝不能被选为主实例。此生产实例应配置为低优先级,使其不太可能(或者通过优先级 0 使其不可能)被选为主实例。

区域 2 中的应用服务器配置为从最近的生产辅助服务器读取数据。此配置可加快应用的响应速度,因为 MongoDB 查询不必跨区域传递;但是,采取此方法时应十分谨慎。由于 MongoDB 总是写入到主服务器,因此必须对此示例中的应用服务器软件进行相应编码,以处理最终一致的数据读取。

标记为 reporting 的辅助实例用于报告来自专用报告应用的工作负载。此实例配置为优先级为 0 的隐藏成员,因为只有报告应用将连接到此实例。

跨区域分片

下图演示了跨多个 Compute Engine 区域进行数据分片的 MongoDB 架构。在图中,紫色和蓝色箭头表示从 MongoDB 主实例复制到辅助实例的数据流。绿色箭头表示从应用服务器写入到 MongoDB 主实例的数据流,以及从 MongoDB 服务器读取到客户端的数据流。

表示跨多个 Compute Engine 区域的 MongoDB 分片的图表。

在此示例架构中,区域配置如下:

  • 区域 1 是生产服务器所在的 Compute Engine 区域。最终用户流量中的大部分会到达该区域中的应用服务器。
  • 区域 2 是在地理位置上靠近一小部分但很重要的用户群的 Compute Engine 区域。

此示例假定区域 1 中用户最常访问的数据与区域 2 中用户最常访问的数据不同。通过创建两个分片并使用标记识别分片,该架构可确保区域 1 中用户最常访问的数据存储在区域 1 中,区域 2 中用户最常访问的数据存储在区域 2 中。

MongoDB Query Router 以透明的方式将传入查询路由到相应的主服务器。由于生产应用绝不会从辅助服务器读取数据,因此该应用永不必处理过时读取和最终一致性所造成的复杂性。

主实例和辅助实例各自运行一个 MongoDB 服务器,且两者大小和配置相同,因为它们都可能被选为 Shard A 的主实例。从生产应用服务器读取的负载始终到达主 MongoDB 服务器。预计大部分客户端服务器流量都将保留在该区域内。

在本例中,仲裁者与其他副本集成员均作为成本较低的投票成员部署在同一地区。由于此实例不包含副本集数据并且不处理最终用户流量,因此它未配置数据磁盘,且使用 g1-small 机器类型

Shard B 的主实例、辅助实例和仲裁者的配置与 Shard A 中的相同。Shard A 和 Shard B 都额外配置了一个辅助实例,用于报告工作负载。在此报告用的辅助实例中,其配备的内存与任何生产实例的都多。此实例配置为优先级为 0 的隐藏成员,因为只有报告应用将连接到此实例。

将 MongoDB 部署到 Google Cloud Platform

选择机器类型

Compute Engine 提供多种虚拟机类型用于运行数据库工作负载。对于 MongoDB 部署,标准机器类型可很好地平衡 CPU 和内存资源,而高内存机器类型则非常适合相比 CPU 需要更多内存的工作负载。Compute Engine 还提供自定义机器类型,它可实现 CPU 或内存资源的独立扩展。

不同的应用具有不同的需求,但与添加更多 vCPU 核心相比,添加更多内存通常是一种更具成本效益的性能提升方法。当最大限度地减少磁盘访问时,MongoDB 服务器的性能最佳。要尽可能减少磁盘访问,请调整 MongoDB 服务器实例的大小,使活动工作数据集能够保留在内存中。

如果您的部署包含 MongoDB 仲裁者服务器,请考虑使用 g1-small 实例。仲裁者实例主要处于闲置状态,它与其他 MongoDB 服务器交换检测信号信息,而且仅在需要选择新的主实例时才会短期非常活跃。要预留不常需要的关键 CPU 周期,一种实惠的方式是使用共享核心实例(例如 g1-small)。

配置永久性磁盘

永久性磁盘为 Compute Engine 实例提供高性能和一致的块存储。磁盘性能随磁盘大小进行扩缩,最高可达其关联虚拟机的最大容量。

Compute Engine 永久性磁盘可用作标准硬盘 (HDD),也可用作固态硬盘 (SSD)。标准永久性磁盘对有序读/写工作负载很有用,但不是随机读/写工作负载的最优选择。SSD 永久性磁盘是 MongoDB 部署的最佳选择,因为它们提供了最佳性价比,并且可以支持高速率的随机每秒输入/输出操作 (IOPS)。

Compute Engine 磁盘具有内置冗余,可保护数据免受故障影响,还能通过维护事件确保数据可用性。数据还在写入磁盘之前自动加密,让您不必在写入前加密文件。

为 MongoDB 数据调整磁盘大小时,请执行以下操作:

  • 计算数据所需的大小。
  • 检查此磁盘大小是否提供了写入数据、日志文件和日志所需的性能。如果没有,请选择更大的磁盘以提供您所需的性能。

如果 Compute Engine 机器类型的磁盘性能限制不能满足您的需求,则需要选择更大的实例或对数据进行分片。

部署 MongoDB

您可采用下述几种不同的方式在 Cloud Platform 上部署 MongoDB:

  • Cloud Marketplace for MongoDB 提供了用于部署 MongoDB 的最简单的入口点,让您能够通过网页界面快速部署副本集。
  • MongoDB Cloud Manager 与 Cloud Marketplace 相比支持更复杂的部署,例如复杂的副本集或分片集群。但是,您必须预配和配置 Compute Engine 实例并手动部署软件代理。
  • Google Cloud Deployment Manager 让您能够自动设置 MongoDB Cloud Manager,包括您本来需要手动执行的资源预配和配置步骤。

使用 Cloud Marketplace for MongoDB

借助 Cloud Marketplace,您可以快速部署在 Cloud Platform 上运行的功能型软件包。该服务让您能够在预定义配置中轻松部署软件包,而无需手动配置软件、虚拟机、存储或网络设置。

Cloud Marketplace for MongoDB 让您能够快速部署包含多达 7 个虚拟机的副本集,它还能简化初始配置步骤。

Cloud Marketplace 默认部署具有主实例、辅助实例和仲裁者的 MongoDB 副本集,但您可更改配置以适应您的用例。此外,您可以根据所需配置选择偏爱的机器类型和磁盘类型。部署副本集后,您可以根据需要更新集群配置

设置 MongoDB Cloud Manager

MongoDB Cloud Manager 是一款托管的软件即服务 (SaaS) 应用,它可将 MongoDB 管理任务统一到单个界面中。MongoDB Cloud Manager 集成了 MongoDB 的配置、查询优化、监控和备份功能。

借助 MongoDB Cloud Manager,您可以部署并配置 MongoDB 副本集和分片集群,还可根据需要升级或降级集群。它还包括全面的监控功能,让您能够查看超过 100 个 MongoDB 指标;此外,该应用提供自定义警报并与其他应用性能监控解决方案进行集成。MongoDB Cloud Manager 还为 MongoDB 部署提供完全托管的备份解决方案,可实现持续增量备份和时间点恢复。

要将 MongoDB Cloud Manager 与 Google Cloud Platform 结合使用,请执行以下操作:

  1. 创建 MongoDB Cloud Manager 帐号,并复制“mmsGroupId”和“mmsApiKey”。
  2. 为 MongoDB 集群预配 Compute Engine 实例和永久性磁盘。
  3. 将永久性磁盘附加并配置到每个 Compute Engine 实例。
  4. 安装和配置 MongoDB Cloud Manager 自动化代理
  5. 返回 MongoDB Cloud Manager 界面并完成集群设置

使用 Deployment Manager 引导 MongoDB Cloud Manager

如果不想手动执行设置 MongoDB Cloud Manager 中所有步骤,一种替代方法是使用 Cloud Deployment Manager 模板来自动预配和配置 Compute Engine 实例。

借助 Deployment Manager,您能以声明性格式指定 MongoDB 部署所部的全部资源。此外,您可实现模板参数化,使模板能采用不同的输入值并使其更加灵活且可重复使用。Deployment Manager 模板将被整理到声明式配置中,其中包含资源定义和运行时属性。

对于使用 MongoDB Cloud Manager 的部署,您可以使用 GitHub 上提供的示例 Deployment Manager 模板。借助这些模板,您能够快速预配和配置多个 Compute Engine 实例(每个实例都有一个永久性 SSD 用于数据存储),还能自动安装和配置 MongoDB Cloud Manager 自动化代理。

要使用 Deployment Manager 模板来引导 MongoDB Cloud Manager,请执行以下操作:

  1. 创建 MongoDB Cloud Manager 帐号,并复制“mmsGroupId”和“mmsApiKey”。
  2. 克隆 mongodb-cloud-manager GitHub 代码库
  3. 使用之前复制的值部署配置,如 mongodb-cloud-manager README 文件中所述。
  4. 返回 MongoDB Cloud Manager 界面并完成集群设置

调整 MongoDB 部署

要调整 Compute Engine 上 MongoDB 部署的性能,首先要调整 MongoDB 软件的性能。如果数据库设计低效以及索引不足或低效,则再多配置良好的硬件也无法弥补。有关提示和最佳做法,请参阅 MongoDB 优化策略

在确定针对预期查询模式进行了优化的相应 MongoDB 架构后,请尝试以下建议来优化 Google Compute Engine 上的 MongoDB 部署。

将 MongoDB 日志文件和数据文件放在同一磁盘上

MongoDB 建议将组件分隔到不同的存储设备上。但是,Compute Engine 的永久性磁盘已在超大量的不同卷中划分了数据,因此无需手动执行此操作。

MongoDB 日志数据很小。如果将它放在其自带磁盘上,则您最终会创建一个写入性能不足的小磁盘,或是一个几乎未被使用的大磁盘。请将 MongoDB 日志文件与您的数据放在同一磁盘上。

增加最大打开文件数

每个操作系统都会跟踪打开的磁盘文件和网络连接,将它们统一视为打开文件。此任务可能需要大量系统资源,因此操作系统会强制实施可配置的限制,规定在给定时间内可打开的文件数量。

通常,默认限制为可打开几千个文件。但是,运行 MongoDB 的服务器通常需要维护数以万计的打开文件。为提高性能,请考虑增加 MongoDB 服务器主机操作系统的最大打开文件数。

如需了解详情,请参阅 UNIX ulimit 设置

减少 TCP keepalive 时间

操作系统具有检测信号机制,因此网络连接的任一端都知道另一端是否仍处于连接状态。一端在未收到另一端信号的情况下可保持连接的时长被称为 keepalive。当连接的一端在足够长的时间内未收到另一端的信号时,该连接将被视为不活跃并将被清除。

入站连接速率较高的 MongoDB 服务器可能会遇到网络堆栈太长时间保持不活跃连接的问题。为避免此问题,请考虑减少 TCP keepalive 默认时间。

如需了解详情,请参阅 MongoDB 诊断常见问题解答

降低预读缓存值

当应用请求从磁盘读取文件的一部分时,操作系统通常会假定该应用很快将请求该文件的更多内容,从而读取比请求量更多的内容并进行缓存。这种机制称为预读

通常,MongoDB 会随机访问磁盘上的数据,而非依序访问。这意味着大量预读更有可能阻碍而非改善性能,在不必要的预读上浪费内存、CPU 和网络资源。

为避免这种不必要的性能损失,请考虑降低 MongoDB 数据卷的预读值。

如需了解详情,请参阅 MongoDB 正式版说明

尽早进行数据分片

MongoDB 可在继续处理请求的同时进行数据分片,并优先处理最终用户流量而不是处理分片请求。因此,您无需关闭数据库即可进行分片。

但是,分片的确要使用网络、内存和 CPU 资源。随着系统的增长,您最终需要使用更少的资源对更多的数据进行分片。根据数据库的大小和集群的可用计算资源,分片可能需要数小时或数天。

借助 Compute Engine,您可以在需要时添加新的虚拟机实例,并在部署的 CPU 数和内存量方面选择多多。通过监控 MongoDB 基础架构,并配置较小的分片而非较大的分片,您可以保证部署灵活并始终满足资源需求。

维护 MongoDB 部署

升级和降级虚拟机实例

Compute Engine 永久性磁盘独立于其所连接的实例,这意味着您可以删除虚拟机实例、选择不删除其关联的永久性磁盘,还可稍后启动具有相同磁盘的新实例。在此过程中,新实例的虚拟机类型不必与原始实例相同。这样,您就能快速、轻松地升级和降级硬件。

能够快速更改虚拟机类型,再加上 MongoDB 复制,这意味着您可以轻松更改整个副本集的虚拟机类型,而尽量减少对生产流量的影响。请考虑以下操作顺序:

对于每个辅助服务器:

  1. 删除服务器实例,确保保留所附加的磁盘。
  2. 启动具有以下属性的新服务器实例:

    • 新的虚拟机类型。
    • 相同的名称、磁盘、网络、标记等。

发现到辅助实例的复制时,请执行以下任务:

  1. 删除主服务器实例,确保保留所附加的磁盘。
  2. 启动具有以下属性的新服务器实例:

    • 新的虚拟机类型。
    • 相同的名称、磁盘、网络、标记等。

删除主服务器后,副本集将从其中一个已升级或降级硬件的辅助服务器中选出一个新的主服务器。原始主服务器重启后,将作为辅助服务器加入副本集。

当 MongoDB 服务器重启时,数据最初不在内存中,而是按需加载到内存中。这一初始负载会显著影响性能。在使用本部分中所述方法升级或降级虚拟机实例时,请使用 touch 命令将存储中的数据显式引入内存。此操作可改善二次预热,同时减少完成维护过程所需的时间。

从较晚分片中恢复

正如尽早进行数据分片部分所述,太晚分片会对生产集群造成切实的问题。但是,如果您发现自己已遇到此问题,您仍能够在不影响生产流量的情况下完成分片。

如果您的 MongoDB 服务器尚未在最大的可用 Compute Engine 实例上运行,请尝试以下步骤:

  1. 升级副本集中的虚拟机。例如,如果您的实例受 CPU 限制,请将其从 n1-standard-4 机器类型升级为 n1-standard-8。如果您的实例受内存限制,请将其从 n1-standard-4 升级为 n1-highmem-4。
  2. 创建新的副本集,然后将 MongoDB 配置为分片到新的副本集。
  3. 在分片完成后降级原始副本集的硬件。

如果升级您的机器可缓解即时资源短缺,则您应能够在对生产流量造成有限影响的情况下进行分片。

将 MongoDB 与 Cloud Platform 服务集成

与 Cloud Storage 集成

您可以将 MongoDB 数据轻松导出到 Google Cloud Storage,从而提供持久且高度可用的对象存储。Cloud Storage 提供了几种存储类别来涵盖各种用例:

  • Multi-Regional 提供了最高等级的可用性和性能,还提供 2 个以上区域的地理位置冗余。
  • Regional 具有与 Multi-Regional 相同的优势,但它费用更低且所有数据都存储在一个区域内。
  • Nearline 提供了费用低、高度持久的存储服务,非常适合通常每月访问不到一次的数据。
  • Coldline 针对归档、备份和灾难恢复提供了费用最低的存储,其持久性与其他所有 Cloud Storage 类别相同。

对于备份和归档,应分别使用 Standard 和 Nearline 存储类别,使用 mongodump 从 MongoDB 辅助实例本地导出数据,然后将数据上传到 Cloud Storage。如需了解详情,请参阅使用 MongoDB 工具进行备份和恢复文档。

对于分析,请使用 Standard 存储类别,使用 mongoexportJSON 或 CSV 格式从 MongoDB 辅助实例本地导出数据,然后将平面文件上传到 Cloud Storage。上传导出的数据后,您可将其用于一系列其他 Cloud Platform 工具,包括 BigQuery、Cloud Dataflow 和 Cloud Dataproc。

与 BigQuery 集成

BigQuery 是一个完全托管的 PB 级数据仓库,是大规模数据分析的绝佳选择。您可以将导出的 MongoDB JSON 或 CSV 数据导入到 BigQuery,并将该数据与其他数据源相结合,从而驱动临时分析和报告。BigQuery 原生支持 JSON,这意味着可以使用标准 SQL 存储和查询具有嵌套对象的 MongoDB 文档。

与 Cloud Dataflow 集成

Cloud Dataflow 是一个统一的编程模型,同时也是一项托管服务,用于开发和执行各种数据处理模式。借助 Cloud Dataflow,您可以创建 ETL 或批量计算数据处理流水线,并使用能根据需要动态预配资源的完全托管式服务来执行它们。Cloud Dataflow 编程模型支持许多内置数据转换(例如统计/数学聚合),还支持 map/shuffle/reduce 风格的算法(例如 group-by 和 join)。此外,编程模型支持用于更复杂的数据处理任务的自定义和复合转换。Cloud Dataflow 流水线可以从 Cloud Dataflow 读取输入数据,并将处理后的数据输出回 Cloud Dataflow,或者直接输出到 BigQuery 或 Cloud Bigtable

与 Cloud Dataproc 集成

对于 Hadoop 和 Spark 工作负载,Cloud Dataproc 可让您快速部署集群、随时调整集群大小,并在处理完成后删除集群。90 秒内即可启动 Hadoop 和 Spark 集群。如果您的作业所需的处理时间少于 24 小时,您还能在集群中使用 Compute Engine 抢占式虚拟机来最大限度地减少费用。Hadoop 和 Spark 作业可以通过使用 MongoDB Connector for Hadoop,直接从 Cloud Storage(BSON、JSON 或 CSV)或正在运行的 MongoDB 部署中读取所导出的 MongoDB 数据。

后续步骤

根据您自己的情况试用其他 Google Cloud Platform 功能。查阅我们的教程

此页内容是否有用?请给出您的反馈和评价:

发送以下问题的反馈:

此网页
Solutions