我可以使用一個廚師服務器實例管理多少個節點？

Question

我正在配置一個廚師服務器，並希望通過此服務器管理超過500個節點 - 可能接近1000.這是我可以期望在EC2上說一個超大型實例的有效工作嗎？我應該考慮在單獨的服務器上運行rabbitmq，solr等嗎？是否可以在分佈式設置中運行廚師服務器本身？

Answer 1

更新

廚師11今年早些時候發佈。隨着發佈的是Opscode與可擴展性測試合作的公司的一些新聞稿/案例研究。值得注意的是，Facebook和Cycle Computing使用一臺Chef服務器管理了10,000多個節點羣集。廚師服務器的規格適中，但未公開。更多信息，請訪問：

• Chef 11 announcement
• Facebook announcement
• Phil Dibowitz, Facebook, spotlight
• Phil's talk at ChefConf
• Cycle Computing case study

需要注意的是這適用於開源廚師服務器和企業廚師。 Opscode的託管企業廚師服務本質上是一個巨大的企業廚師實例，因爲它基本上運行「相同」的代碼庫。

（不精確一樣的，Opscode公司擁有的自定義和所需的運行可公開訪問的SaaS平臺，它允許多個客戶支付和使用的附加服務。）

對廚師的Wiki這個頁面有很多優秀的鏈接和信息：

• http://wiki.opscode.com/display/chef/Scalability+and+High+Availability

幾點考慮：

1. 重要的度量標準不是節點數量，而是您期望的節點收斂數量。例如，每天運行Chef一次的500個節點在服務器上的負載低於每10分鐘運行Chef的50個節點。當然，每10分鐘運行Chef的500個節點（或者甚至30分鐘，一個普通的間隔時間）是系統上的大量負載。

2. 廚師服務器被設計爲分佈式系統，因此組件可以在單獨的節點上運行。這正是Opscode Hosted Chef和Opscode Private Chef的工作方式 - 各種服務在不同的系統上運行以分配負載。如果你期望有很多節點經常運行Chef，那麼你應該在不同的系統上運行這些服務。 Wiki上的Chef Configuration Settings頁面描述了這些服務的配置選項。

3. 高可用性和可擴展性不是一回事，需要不同的方法。這些差異完全不在廚師的範圍之內。雖然，「Scalability and High Availability」頁面應該有所幫助。

4. Chef 10.x或0.10.x版本使用基於Ruby的API服務，而CouchDB作爲後端數據存儲。在託管廚師的規模，Opscode公司發現了可擴展性，這是在Seth Falcon's talk at ChefConf 2012描述的問題。雖然這次談話主要是關於客戶數據的真實遷移，但關於CouchDB的可擴展性還有幾點意見。此外，Chef 11 will be migrated to an Erlang-based API service，和SQL（MySQL的或的PostgreSQL）作爲後端數據存儲器中。

5. 更新 Open Source Chef Server的Chef 11版本如前所述需要在Erlang中完全重寫服務器API服務。這個答案頂部的信息通過案例研究和談話提供了更多關於這一切的意義。

Answer 2

@jtimberman概括起來相當不錯，你確實可以由廚師服分手了到一些獨立的節點，並在它投入更多資源，擴大東西到某一點。

通過我看到〜由單個（開源）管理的客戶端700使用Solr和CouchDB的在單獨的節點廚師10.x的服務器中的數據點的方法。