对于 Apache Pulsar

Apache Pulsar 是 Apache 软件基金会顶级我的项目，是下一代云原生分布式音讯流平台，集音讯、存储、轻量化函数式计算为一体，采纳计算与存储拆散架构设计，反对多租户、长久化存储、多机房跨区域数据复制，具备强一致性、高吞吐、低延时及高可扩展性等流数据存储个性。
GitHub 地址：http://github.com/apache/pulsar/

本文要点

• 使存储系统感知云的传统形式是间接迁徙，这种形式体现良好，但从咱们的教训来看，重构云感知架构成果更好。
• 目前，在跨区域环境中部署 Apache BookKeeper 时须要手动将存储节点映射到特定区域 / 可用性区域，但在区域中断时，持久性和可用性会受到影响。
• Salesforce 独有的使 Apache BookKeeper 感知云的办法是通过智能化存储节点，让其在云中部署能够无效运行，并保障持久性和可用性。
• 这些办法简化了集群的改良、降级和重启操作，对生产服务的影响最低。

在 Salesforce，咱们须要能够同时解决两种流的存储系统：一种流用来预写日志，另一种流用来解决数据。但对这两种流，咱们的要求互相矛盾：预写日志流的写入提早低，而读取吞吐量高；数据流的写入吞吐量高，但随机读取提早低。作为云计算的领军企业，咱们的存储系统必须具备云感知能力（可用性和持久性要求越来越高）。为了在商用硬件上运行并不便扩容，咱们无奈更改部署模型设计。

开源计划

在对存储系统进行初步钻研后，咱们思考是本人搭建一套还是购买一套。

思考到整体规划和上市工夫、资源、老本等次要的业务驱动因素，咱们决定应用开源存储系统。

在查看了开源代码后，咱们有两个备选计划：Ceph 和 Apache BookKeeper。因为这套零碎须要对客户凋谢，可扩展性和一致性都很重要，零碎必须齐全满足用例的 CAP（Consistency：一致性；Availability：可用性；Partition Tolerance：分区容错性）要求以及咱们本人的非凡需要。首先，咱们来看一下 BookKeeper 和 Ceph 在 CAP 和其余方面的体现。

Ceph 能够保障一致性和分区容错，读取门路能够借助不牢靠读取提供可用性和分区容错；但要使写入门路保障可用性和分区容错性并不容易。并且，咱们不能更改部署数据。

咱们决定抉择 Apache BookKeeper。BookKeeper 反对仅追加 / 不可变数据存储，采纳高可复制的分布式日志，满足咱们对系统 CAP 的要求。BookKeeper 还具备以下特点：

• 已 Ack 的写入始终可读。
• 已读 Entry 始终可读。
• 无 Master 服务器，客户端应用 Apache ZooKeeper 实现共识（consensus）算法，获取元数据。
• 数据布局无需简单的哈希 / 计算。

Salesforce 也始终反对开源产品，Apache BookKeeper 社区踊跃沉闷，充满活力。

Apache BookKeeper——近乎完满，但还有改善空间

Apache BookKeeper 简直实现了咱们对存储系统的全副要求，但仍需做一些工作。首先来看一下 Apache BookKeeper 能够实现咱们的哪些要求。

• 存储节点称为 Bookie；一组 Bookie 称为 Ensemble。
• 写入的最小单元为 Entry，Entry 不可更改。
• 一组 Entry 称为 Ledger，Ledger 仅可追加，不可更改。
• 写入或复制 Bookie 的数量称为 Write Quorum——Entry 的最大正本数。
• 确认写入前 Bookie 的数量称为 Ack quorum——Entry 的最小正本数。

从持久性来看，Ledger 跨 Bookie Ensemble 复制，Ledger 内的 Entry 能够跨 Ensemble。

写入依据 Write Quorum 和 Ack Quorum（可配置）进行确认，从而保障低写入提早和高可扩大。

但实际上，在云中的商用硬件上运行 BookKeeper 并不轻松。

数据布局策略不具备云感知能力，并且没有顾及底层云服务提供商（云基础设施）。目前，一些用户的部署办法是手动标识不同可用性区域中的节点，并进行逻辑分组，而后以组为单位改良数据布局策略。这不失为一种解决方案，但不反对区域故障，也升高了保护和降级大型集群时零碎的易用性。

另外，所有云基础设施的可用区域里都呈现过停机状况；而个别的了解是，应用程序要针对这些故障做相应的设计。一个很好的例子是，2012 年圣诞节期间，Amazon 网络服务可用区域故障，Netflix 底层所依赖的私有云基础设施停机，而 Netflix 服务依然能够在无限的容量上运行。

私有云中的问题

私有云基础设施易于扩大，在肯定水平上升高了应用和保护的老本，因而，从网站到应用程序，甚至是企业级软件，根本都在私有云服务提供商提供的基础设施上运行。然而，私有云也有其缺点，它在节点、区域或地区层面都可能呈现不可用的状况。底层基础设施不可用，用户什么都做不了。起因可能是某些机器、区域或地区呈现故障，也可能是由硬件故障引起的网络提早减少。所以最终当在私有云基础设施上运行应用程序时，开发人员在设计时须要思考由故障引发的问题。

Apache BookKeeper 自身不能解决这一问题，因而，咱们须要自行设计一个修复程序。

Salesforce 重构

对问题有了肯定的理解之后，咱们开始思考解决方案，让 BookKeeper 具备云感知能力，满足咱们的以下要求。

• 在私有星散群中的 Bookie 须要一个标识。
• 依据可用区域内 Ensemble 的散布设计数据布局策略，实现更好的高可用，简化保护和部署。
• 改良 Bookie 已有的性能，如读取、写入、数据复制等，使 Bookie 能够充分利用多区域布局的劣势，并计算跨区域传输数据的老本。
• 上述工作和云基础设施无关。

咱们的解决方案如下：

云感知能力：Cookie 和 Kubernetes

现有的 BookKeeper 架构为所有 Bookie 提供惟一标识（在首次启动时调配）。标识存储在元数据存储（ZooKeeper）中，其余 Bookie 或客户端能够拜访。

使 Apache BookKeeper 具备云感知能力的第一步是让所有 Bookie 均可获取它部署在 Kubernetes 集群中的地位。咱们认为 Cookie 数据是获取地位信息的最佳形式。

因而，咱们在 Cookie 中减少了 networkLocation 字段，它蕴含两局部：可用区域和降级域，用于定位 Bookie。Kubernetes 和云基础设施无关，咱们能够应用 Kubernetes API 来查问底层的可用区域信息。咱们还依据波及主机名顺序索引的公式生成了 upgradeDomain 字段。它能够用来滚动降级，而不影响集群的可用性。

在机器启动时生成上述字段和对应值，并保留在元数据存储中供用户拜访。这些信息能够用于生成 Ensemble，调配 Bookie 到 Ensemble，以及确定从哪些 Bookie 复制数据，复制的数据存储到哪些 Bookie。

私有云布局策略

当初，客户端曾经足够智能，能够与某些区域中的 Bookie 进行通信，下一步便是确保有一个能够应用这一信息的数据布局策略。咱们开发了 ZoneAwareEnsemblePlacementPolicy（ZEPP）。这是一个针对基于云部署而设计的两级层次化布局策略。ZEPP 能够获取可用区（AZ）和 upgradeDomains（UD）信息。

AZ 是区域内隔离数据中心的逻辑概念；UD 是 AZ 内的一组节点，敞开 UD 不会影响服务，UD 还能够监测到区域的敞开和重启。

下图为 ZEPP 可采纳的一种部署示意图。这种部署形式兼顾了 Cookie 中的 AZ 和 UD 信息，并据此对 Bookie 节点进行分组。

可用性 & 提早 & 老本

进行上述调整后，Apache BookKeeper 能够具备云感知能力了。但老本也是设计架构时必须思考的因素之一。大多数云基础设施对传出服务的数据进行单向收费，跨可用区传输的费用会有所不同。这是 BookKeeper 客户端须要思考的一个重要因素，因为它当初是从 Ensemble 中随机抉择一个 Bookie 进行读取。

如果 Bookie 和客户端属于不同的可用区，会减少不必要的老本。数据复制可能产生在跨可用区的 Bookie 之间，当可用区呈现故障时，应用老本会减少。

咱们通过以下形式来解决这些非凡状况：

重排序读取

目前，BookKeeper 客户端从 Ensemble 随机选取 Bookie 进行读取。借助重排序读取个性，当初客户端能够抉择 Bookie，从而减小读提早，降低成本。

启用重排序读取后，客户端依照以下程序抉择 Bookie：

• 本地区域中满足要求且待处理申请少的 Bookie；
• 近程区域中满足要求且待处理申请少的 Bookie；
• 本地区域中故障起码或待处理申请高于设定阈值的下一个 Bookie；
• 近程区域中故障起码或待处理申请高于设定阈值的下一个 Bookie。

依照上述程序，运行很长时间且呈现过故障的零碎也能够满足咱们对提早与老本的要求。

解决区域故障

当区域敞开时，不同 Ensemble 中的所有 Bookie 都开始将数据复制到以后可用区域内的 Bookie 中，从而满足 Ensemble Size 和 Quorum 要求，引起“惊群问题”。

要解决这一问题，首先要确定区域敞开的工夫。故障可能是暂时性的操作失误，比方网络故障引起区域不可用，咱们不心愿零碎复制 TB 级的数据；但同时咱们也要做好筹备，应答真正的故障。咱们的解决方案蕴含两步：

• 分别区域是真正故障还是临时故障；
• 将整个区域的大规模主动复制转换为手动操作。

下图为区域敞开与重启时咱们的应答计划。

依据区域中可用 Bookie 数量和区域中 Bookie 总量能够计算出 HighWaterMark 和 LowWaterMark 的值。用户能够为这两个值设置阈值，零碎能够据此判断故障状况，进而确定故障类型。

当区域标记为敞开时，咱们会禁用主动复制，从而防止跨区域主动复制 TB 级的数据。此外，咱们在数据复制的中央减少了告警，提醒用户可能呈现的区域故障。咱们认为，运维专家可能将噪声与理论故障辨别开，并决定是否开始主动复制整个区域的数据。

咱们还能够通过 shell 命令启动已禁用的 Bookie 主动复制。

咱们的播种

Apache BookKeeper 是一个开源我的项目，社区十分沉闷，并始终在踊跃探讨面临的一系列挑战。因为 BookKeeper 是存储数据的组件，对很多用户而言，其云感知能力非常重要。

本文介绍的更改已在 Salesforce 进行了实战验证。目前，借助 Apache BookKeeper，咱们曾经能够反对 AZ 和 AZ + 1 故障。然而，这样的架构更改必然会影响到可用性、提早、老本、部署和保护的繁难性。社区曾经承受了咱们提交的一些更改，咱们会持续为社区做出奉献。咱们心愿这些更改能够简化集群打补丁、降级、重启的操作，同时尽可能升高对生产服务的影响。

对于作者

Anup Ghatage 任职于 Salesforce，次要负责云基础架构和数据工程，曾任职于 SAP 和 Cisco Systems，对保护和开发高可扩大的零碎有浓厚兴趣。他本科毕业于普纳大学计算机专业，硕士毕业于卡耐基·梅隆大学。他是 Apache BookKeeper 的 committer，积极参与 Apache BookKeeper 的开发。欢送在 Twitter 上关注 Anup（@ghatageanup）。

相干浏览

• Apache BookKeeper 很简单吗？你细品
• 为什么抉择 Apache BookKeeper – Part 1
• 为什么抉择 Apache BookKeeper — Part 2

点击 链接 ，查看英文版原文。