MongoDB多数据中心部署方案（五）

（草稿）

目录

第五章 MongoDB部署模式

下图显示MongoDB中的数据中心awareness如何为地域和全球部署提供高可用性和可扩展性。

高可用：单数据中心

在数据中心内，复制集可以分布在机架上，以便任一机架都不会包含一个给定分片的多个复制成员。

在这配置中可以容忍服务器和机架故障，复制集成员的数量决定系统可持续承受故障的规模，而不影响可用性。这种部署不会对数据中心本身的故障容错。

图3：单数据中心-服务器和机架容错

高可用：主/备 数据中心

在典型的灾难恢复中，复制集成员分布在两个数据中心的机架上。活动的数据中心（西部数据中心）包括一个偶数的复制集成员其中包含主成员。

图4：主/备 数据中心 - 数据中心容错

东部的备用或灾难恢复数据中心配有副复制集成员，配置较低的选举优先级（建议使用0.5）。这样可以确保只有West数据中心的节点才是主（Primary），除非一个数据中心完全中断它们才完全不可用。在活动/备份配置中，用户能避免任一数据中心丢失，而应用程序可能使用大部分write concern保持在任何服务器故障时写保护。

在西部数据中心发生故障时，运营团队的重点是把东部投入生产环境，同时要防止西部数据恢复时，一种“裂脑”（split brain）的可能性。去做这个，管理员必须确保西部至少有一个MongoDB节点停留下来，通过一定的措施，如移除电源或确认西部的永久性物理损失。下一步一个在东部节点上的“强制”重配置复制集移除西部两个成员的投票。东部节点大部分立即选举自己为主（Primary）并恢复生产能力。如果西部在任何时间停止服务，额外的复制集成员应该添加至东部为MongoDB部署恢复冗余。在更可能出现的西部恢复事件中，应采取以下步骤：

一旦连接恢复，在西部恢复的复制集成员自动同步当前东部的主复制集。东部剩下有投票权的成员以单独表决的形式选出西部较高优先级的节点为主（Primary）。

重启西部剩余的复制集。它会自动重新同步其余的复制集并承担次级角色。

恢复对西部MongoDB节点的选举投票权，完成恢复至初始状态。当加上MongoDB的持续备份和指定时间恢复工具，主/备设计模式在此示例中将通过灾难恢复和低PRO（目标点恢复）提供业务连续性。然而，它是分布式架构，MongoDB提供更灵活的配置支持主/主数据中心配置。

请注意此部署适用于单复制集或为一个未使用集群负载均衡的分片集群。负载均衡器在用于围绕集群自动重发数据的多数据中心环境中，建议在一个主/主数据中心配置中部署MongoDB。

高可用：主/主数据中心

两个数据中心，在这个例子中”西部“和”东部“配置相等数量的复制集成员，一个第三方数据中心（”中心“）包含一个附加的复制集成员。这个配置需要确保如果数据中心之中一个故障，大多数的复制集成员能构成一个法定人数（所以如果西部数据中心故障，剩下的两个数据中心能对集群状态达成一致并切换到东部数据中心）。

图5：主/主 数据中心 - 服务器、机架与数据中心加网络中断容错

高可扩展性：全球数据分布

为减少地理环境因素的影响，MongoDB可以将数据复制到本地站点。读操作可以通过 nearest 发布一个优先读取。根据一个ping距离，确保从最接近用户的数据中心提供数据。

这些读操作与主（Primary）保证最终一致，但通常不超过几毫秒在主（Primary）之后，加网络延迟。写操作发布给主（Primary）。

这种部署类型的典型用户案例是将数据和内容分发到地域远程受众。数据集被写入主（Primary）服务器，然后在这些数据中心被本地用户低延迟访问时将它们广播到世界各地的数据中的复制集成员。

图6：全球数据分布 - 消除地域读取延迟

高可扩展性：本地读操作/全局写操作

使用区分片，管理员能将数据库的特定分区引导到特定的地理区域。每个区域都是一样的，单集群能被全球查询到，但数据位于独立和本地访问需求的正确位置。通过根据用户位置将数据关联到分片，管理员能够保持低延迟访问。

为进一步说明，一个应用程序可以用友北美，欧洲和中国的用户。应用程序所有者可以将每个分片分配给改分片服务器的物理位置（北美，欧洲或中国）的区域，然后根据其区域字段将所有文档映射到正确的区（Zone）。任何数量的分片都可以和每个区（Zone）关联并且每个区都可以独立其他的进行扩展。例如，比起北美，中国的用户增长速度更快。

在这部署中，每个MongoDB分片都被本地化至一个特定的数据中心。每个数据中心都有一个具有其分片的主复制集成员并还保留位于其他数据中心的次级复制集分片。应用程序能执行本地数据的读写操作以及从其他区域复制的数据的读操作。如果用户从一个数据中心移至另一个，则可以通过简单地更新分片区域轻松的迁移数据。

一个用户从他的本地位置漫游不同区域的移动应用代表这类部署的典型案例。使用适当的写入策略，对移动服务的任何更新能被路由回它通常的起始位置的数据中心（全局写入），同时通过使用nearest读取优先级（本地读取）将其路由到最近的物理数据中心。

另一个案例是内容管理和交付。例如，McAfee全球Threat集成平台将内容更新写入最每个用户的数据中心，然后使用nearest读取优先级对该数据进行低延迟访问。

图7：本地读/全局写 - 启用移动应用

通过查看我们关于使用MongoDB区域创建地理位置分布式集群的教程了解更多信息：（https://docs.mongodb.com/master/tutorial/sharding-segmenting-data-by-location/）

分布式本地写入为Always-On 写入仅工作负载

MongoDB 区域通过为写入仅工作负载的持续可用性提供了解决方案，例如在IoT应用程序中摄入传感器数据。区域可用于本地化写入在一个分布式集群中创建特定地配置，确保即使在数据中心故障期间总是有可用的接受写入的节点。如图8所示，分布式本地写入的拓扑将维护每个数据中心的两个分片的节点。如果数据中心不可用，应用端逻辑能自动修改分片密匙去重定向写入到备用数据中心。

图8：维护MongoDB zones的持续可用性和本地写操作

通过查看我们关于使用MongoDB区域配置本地化写操作的教程了解更多信息。

下一章 管理多数据中心部署

本文译者：吴锦晟 R&D Director@MFG

原文链接：http://www.jianshu.com/p/0a04ee005f9e

版权归译者所有，转载请注明出处