Pacemaker · Storm 1.1.0 中文文檔

# 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 運行, 系統就會繼續工作 - 只要它可以處理負載.