Pacemaker
一、简介
Pacemaker 是 Storm 的一个进程，用于处理来自 worker 的心跳。随着 Storm 扩展，zookeeper 由于worker 心跳的大量写入逐渐成为瓶颈。当 zookeeper 尝试保持一致性时会产生大量的磁盘写入和网络流量。
而且由于心跳时短暂的并不需要在磁盘持久化存储或者跨节点同步；所以存储在内存就足够了。这就是 Pacemaker 的作用。Pacemaker 的功能是用作简单的键/值存储在内存，具有类似 ZooKeeper 的目录样式键和字节数组值。
相应的 Pacemaker 客户端是ClusterState接口的插件，org.apache.storm.cluster.PaceMakerStateStorageFactory。 心跳调用由 pacemaker_state_factory 生成的 ClusterState 汇集到 Pacemaker 守护进程中，而其他 set/get 操作则转发到 ZooKeeper。
二、配置
pacemaker.servers: 运行 Pacemaker 进程的主机。pacemaker.port: Pacemaker 监听的接口。pacemaker.max.threads: Pacemaker 程序将用于处理请求的最大线程数。pacemaker.childopts: 需要转到 Pacemaker 的任意 JVM 参数。pacemaker.auth.method: 使用的身份验证方法（更多信息如下）。
示例
若需启动并运行 Pacemaker进程，请在集群的所有节点上配置如下选项：
storm.cluster.state.store: "org.apache.storm.cluster.PaceMakerStateStorageFactory"
还需要在所有节点上设置 Pacemaker 服务：
pacemaker.servers: - somehost.mycompany.com - someotherhost.mycompany.com
然后启动所有进程:
(包括 Pacemaker): $ storm pacemaker
Storm 集群现在应该通过 Pacemaker 推送所有 worker 的心跳。
三、安全性Security
目前支持 digest (password-based)和 Kerberos。安全性目前仅限于读，不含写。 任何人都可以写入，而读只能由经过授权和验证的用户执行。 这是一个有待未来开发方向，因为它会使集群遭受 DoS 攻击，但它可以防止任何敏感信息泄露到未经授权的用户，这是主要目标。
Digest
要配置 Digest 身份验证，请在 Nimbus 和 Pacemaker 的节点上的集群配置中设置 pacemaker.auth.method: DIGEST。 节点还必须将 java.security.auth.login.config 设置为指向包含以下结构的 JAAS 配置文件：PacemakerDigest { username="some username" password="some password"; };
配置了这些设置的任何节点都可以从 Pacemaker 读取数据。 worker 节点不需要设置这些配置，并且可以保留 pacemaker.auth.method: NONE 设置，因为它们不需要从 Pacemaker 进程中读取。
Kerberos
要配置 Kerberos 身份验证，请在 Nimbus 和 Pacemaker 的节点上的集群配置中设置 pacemaker.auth.method: KERBEROS。 节点还必须将 java.security.auth.login.config 设置为指向 JAAS 配置。
在 Nimbus 节点上的 JAAS 配置必须如下所示：
PacemakerClient { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/etc/keytabs/nimbus.keytab" storeKey=true useTicketCache=false serviceName="pacemaker" principal="<nimbus@MY.COMPANY.COM>"; };
Pacemaker 上的 JAAS 配置必须如下所示：
PacemakerServer { com.sun.security.auth.module.Krb5LoginModule required useKeyTab=true keyTab="/etc/keytabs/pacemaker.keytab" storeKey=true useTicketCache=false principal="<pacemaker@MY.COMPANY.COM>"; };
- Nimbus 主机上
PacemakerClient部分中的客户端用户必须与 storm 集群配置值nimbus.daemon.user匹配。 - 客户端的
serviceName值必须与 Pacemaker 主机上PacemakerServer部分中服务的用户相匹配。
四、容错性
Pacemaker 作为单个进程实例运行，这就使得它可能会单点故障。
如果 Nimbus 由于崩溃或网络部分而无法访问 Pacemaker，worker 将继续运行，并且 Nimbus 将反复尝试重新连接。 Nimbus 功能将被中断，但拓扑本身将继续运行。 如果集群的分区中 Nimbus 和 Pacemaker 在分区的同一侧，则分区另一侧的 worker 将无法心跳，Nimbus 会将任务重新安排在其他地方。
五、与 ZooKeeper 比较
与 ZooKeeper 相比，Pacemaker 使用更少的 CPU、更少的内存，当然也没有磁盘负载，这要归功于少了维护节点之间一致性的开销。 在千兆网络上，理论上有大约 6000 个节点的限制。 然而，真正的限制可能在 2000-3000 个节点左右。 这些限制尚未经过测试。 在有 270 个 supervisor 的集群上，完全调度拓扑结构，在配备 4 个英特尔(R) Xeon(R) CPU E5530 @ 2.40GHz 和 24GiB RAM 的机器上，Pacemaker 资源利用率为一个内核的 70% 和接近 1GiB 的 RAM。
Pacemaker 现在支持 HA。 可以在一个 Storm 集群中同时使用多个 Pacemaker 实例，以实现大规模的可扩展性。 只需在 pacemaker.servers 配置所有 Pacemaker 的主机。然后 worker 和 Nimbus 就会开始与它们通信。 它们也具有容错能力。 只要至少有一个 Pacemaker 在运行，系统就会继续工作——前提是该 Pacemaker 可以处理所有负载。
该博客仅为初学者自我学习的记录，粗浅之言，如有不对之处，恳请指正。
