# Pacemaker

### 介绍

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 运行, 系统就会继续工作 - 只要它可以处理负载.