Pacemaker - 《Storm 1.1.0 中文文档》

介绍
配置
- 示例
安全
- Digest
- Kerberos
容错
ZooKeeper 比较

介绍

Pacemaker 是一个旨在处理 worker 心跳的 storm 守护进程. 随着 storm 的扩大, ZooKeeper 由于 worker 进行心跳的大量写入而开始成为瓶颈. 当 ZooKeeper 尝试维护一致性时, 会产生大量写入磁盘和跨网络的流量.

因为心跳是短暂的, 它们不需要被持久化到磁盘或跨节点同步; 会在内存�的存储中来做. 这是 Pacemaker 的作用. Pacemaker 作为一个简单的 key/value 存储, 具有类似 ZooKeeper 的目录样式键和字节数组值.

相应的 Pacemaker client 是 ClusterState 接口的插件 org.apache.storm.pacemaker.pacemaker_state_factory. 心跳调用由漏斗 ClusterState 由生产 pacemaker_state_factory 到 Pacemaker 服务进程, 而另一 set/get 操作被转发到 ZooKeeper.

配置

pacemaker.host : （已弃用） Pacemaker 守护程序正在运行的主机
pacemaker.servers : Pacemaker 守护程序正在运行的主机 - 这取代了 pacemaker.host
pacemaker.port : Pacemaker 监听端口
pacemaker.max.threads : Pacemaker 守护进程将用于处理请求的最大线程数.
pacemaker.childopts : 任何需要转到 Pacemaker 的 JVM 参数.（由 storm-deploy 项目使用）
pacemaker.auth.method : 使用的身份验证方法（以下更多信息）

示例

要使 Pacemaker 启动并运行, 请在所有节点上的集群配置中设置以下选项：

storm.cluster.state.store: "org.apache.storm.pacemaker.pacemaker_state_factory"

Pacemaker 服务器还需要在所有节点上设置：

pacemaker.servers:
    - somehost.mycompany.com
    - someotherhost.mycompany.com

pacemaker.host 配置仍适用于单个 pacemaker, 尽管它已被弃用.

pacemaker.host: single_pacemaker.mycompany.com

然后启动所有的守护进程(包括 Pacemaker):

$ storm pacemaker

Storm 集群现在应该通过 Pacemaker 来推动所有 worker 的心跳.

安全

目前支持摘要（基于密码）和 Kerberos 安全性. 安全性目前只在于读取而不是写入. 写入可以由任何人执行, 而读取只能由授权和认证的用户执行. 这是未来发展的一个领域, 因为它让群集开放给 DoS 攻击, 但它阻止任何敏感信息到达未经授权的眼睛, 这是主要目标.

Digest

要配置摘要身份验证, 请 pacemaker.auth.method: DIGEST 在集群配置中设置托管 Nimbus 和 Pacemaker 的节点. 节点也必须 java.security.auth.login.config 设置为指向包含以下结构的 JAAS 配置文件：

PacemakerDigest {
    username="some username"
    password="some password";
};

配置了这些设置的任何节点将能够从 Pacemaker 中读取. Worker 节点不需要设置这些配置, 并且可以保留 pacemaker.auth.method: NONE 设置, 因为它们不需要从 Pacemaker 守护进程读取.

Kerberos

要配置Kerberos身份验证, 请 pacemaker.auth.method: KERBEROS 在主机 Nimbus 和 Pacemaker 的节点上的集群配置中进行设置. 节点也必须 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 作为单个守护进程运行, 使其成为潜在的单点故障.

如果 Pacemaker 由 Nimbus 无法通过崩溃或网络分区, worker 将继续运行, Nimbus 将重复尝试重新连接. Nimbus 的功能将受到干扰, 但 topology 本身将继续运行. 如果 Nimbus 和 Pacemaker 位于分区同一侧的集群分区, 分区另一侧的 worker 将无法心跳, Nimbus 将重新安排其他任务. 这可能是我们想要发生的事情.

ZooKeeper 比较

与 ZooKeeper 相比, Pacemaker 使用更少的 CPU, 更少的内存, 当然也没有磁盘用于相同的负载, 这是由于缺乏维护节点之间的一致性的开销. 在千兆网络上, 有6000个节点的理论限制.然而, 实际限制可能在2000-3000节点之间.这些限制还没有被测试. 在拥有 topology 结构的270个管理员集群中, Pacemaker 的资源利用率是一个核心的70％, 在具有4个 Intel(R) Xeon(R) CPU E5530 @ 2.40GHz 和 24GiB RAM 的机器上的近 1GiB 的 RAM.

Pacemaker 在支持 HA.多个 Pacemaker 实例可以在 Storm 群集中一次使用, 以实现大规模的可扩展性. 只需将 Pacemaker 主机的名称包含在 pacemaker.servers 配置中, worker 和 Nimbus 将开始与他们进行通信. 他们也是容错的.只要至少有一个 Pacemaker 运行, 系统就会继续工作 - 只要它可以处理负载.