使用 Tupperware 對任何規模的叢集進行高效、可靠的管理
今天在 我們推出了 Tupperware，這是我們的叢集管理系統，可以在運行幾乎所有服務的數百萬台伺服器上編排容器。 我們於 2011 年首次部署 Tupperware，從那時起，我們的基礎設施已從 直至整體 。 一直以來，特百惠並沒有停滯不前，與我們一起發展。 我們將向您展示特百惠如何提供一流的叢集管理，包括對有狀態服務的便利支援、適用於所有資料中心的單一控制面板以及在服務之間即時分配容量的能力。 我們也將分享隨著基礎設施的發展所學到的經驗教訓。
特百惠執行不同的任務。 應用程式開發人員使用它來交付和管理應用程式。 它將應用程式程式碼和依賴項打包到鏡像中，並將其作為容器傳遞到伺服器。 容器在同一伺服器上的應用程式之間提供隔離，以便開發人員處理應用程式邏輯，而不必擔心查找伺服器或管理更新。 特百惠也監控伺服器的效能，如果發現故障，則會從有問題的伺服器傳輸容器。
容量規劃工程師使用 Tupperware 根據預算和限制向團隊分配伺服器容量。 他們還使用它來提高伺服器利用率。 資料中心營運商求助於特百惠在資料中心之間正確分配容器，並在維護期間停止或移動容器。 因此，維護伺服器、網路和設備需要最少的人工幹預。
特百惠架構
特百惠 PRN 架構是我們資料中心的區域之一。 該區域由附近的幾座資料中心大樓（PRN1 和 PRN2）組成。 我們計劃製作一個控制面板來管理一個地區的所有伺服器。
應用程式開發人員以 Tupperware 作業的形式提供服務。 一個作業由多個容器組成，它們通常都執行相同的應用程式程式碼。
特百惠負責配置容器並管理其生命週期。 它由幾個組件組成：
- Tupperware 前端提供使用者介面、CLI 和其他自動化工具的 API，您可以透過它們與 Tupperware 互動。 他們向特百惠工作所有者隱藏了整個內部結構。
- Tupperware Scheduler 是一個控制面板，負責管理容器和作業生命週期。 它分為區域級和全域級部署，區域調度器管理一個區域內的伺服器，全域調度器管理不同區域的伺服器。 調度程序分為多個分片，每個分片管理一組作業。
- Tupperware 的 Scheduler Proxy 隱藏了內部分片，並為 Tupperware 用戶提供了方便的單一管理平台。
- Tupperware 分配器將容器指派給伺服器。 調度程序處理容器的停止、啟動、更新和故障轉移。 目前，一個分配器可以管理整個區域，而無需拆分為分片。 （注意術語上的差異。例如，Tupperware 中的調度程序對應於 ，Tupperware 分配器在 Kubernetes 中稱為調度器。）
- 資源代理儲存伺服器和服務事件的真實來源。 我們為每個資料中心運行一個資源代理，它儲存有關該資料中心中伺服器的所有資訊。 資源代理程式和容量管理系統或資源供應系統動態地決定哪個排程器交付控制哪個伺服器。 健康檢查服務監視伺服器並將有關其健康狀況的資料儲存在資源代理程式中。 如果伺服器出現問題或需要維護，資源代理程式會告訴分配器和調度程序停止容器或將它們移至其他伺服器。
- Tupperware 代理程式是在每台伺服器上執行的守護進程，用於處理容器的配置和刪除。 應用程式在容器內運行，這為它們提供了更多的隔離性和可重複性。 在 我們已經描述瞭如何使用映像、btrfs、cgroupv2 和 systemd 建立單一 Tupperware 容器。
特百惠的顯著特點
Tupperware 在許多方面與其他叢集管理系統（例如 Kubernetes 和 ，但也存在差異：
- 對有狀態服務的內建支援。
- 適用於不同資料中心伺服器的單一控制面板，可依意圖自動交付容器、停用叢集和維護。
- 控制面板的縮放劃分清晰。
- 彈性運算可讓您在服務之間即時分配電力。
我們開發了這些很酷的功能來支援龐大的全球共享伺服器群中的各種無狀態和有狀態應用程式。
對有狀態服務的內建支援。
特百惠經營各種關鍵的有狀態服務，為 Facebook、Instagram、Messenger 和 WhatsApp 儲存持久產品資料。 這些可能是大量鍵值對儲存（例如 ）和監控資料儲存庫（例如， и ）。 維護有狀態的服務並不容易，因為系統必須確保容器的供應能夠承受大規模的中斷，包括網路中斷或斷電。 雖然傳統技術（例如跨故障域分配容器）對於無狀態服務效果很好，但有狀態服務需要額外的支援。
例如，如果伺服器故障導致資料庫副本不可用，您是否應該啟用自動維護來更新 50 個伺服器池中 10 個伺服器上的核心？ 視情況而定。 如果這 50 台伺服器中的一台有同一資料庫的另一個副本，最好等待，不要一次遺失 2 個副本。 為了動態地做出有關係統維護和效能的決策，我們需要有關內部資料複製和每個有狀態服務的放置邏輯的資訊。
TaskControl 介面允許有狀態服務影響影響資料可用性的決策。 使用此接口，調度程序通知外部應用程式有關容器操作（重新啟動、更新、遷移、維護）。 有狀態服務實作一個控制器，該控制器告訴 Tupperware 何時可以安全地執行每個操作，並且這些操作可以暫時交換或延遲。 在上面的範例中，資料庫控制器可以告訴 Tupperware 更新 49 台伺服器中的 50 台，但暫時保留特定伺服器 (X)。 因此，如果核心更新周期過去且資料庫仍然無法恢復有問題的副本，Tupperware 仍將更新 X 伺服器。
Tupperware 中的許多有狀態服務不是直接使用 TaskControl，而是透過 ShardManager（用於在 Facebook 上建立有狀態服務的通用平台）使用 TaskControl。 借助特百惠，開發人員可以準確指定容器如何跨資料中心分佈的意圖。 使用 ShardManager，開發人員可以指定資料分片如何跨容器分佈的意圖。 ShardManager 了解其應用程式的資料放置和複製，並透過 TaskControl 介面與 Tupperware 進行通信，以安排容器操作，而無需應用程式直接參與。 這種整合極大地簡化了有狀態服務的管理，但 TaskControl 的能力還不止於此。 例如，我們廣泛的 Web 層是無狀態的，並使用 TaskControl 動態調整容器的更新速率。 最終 每天，而不影響可用性。
管理資料中心的伺服器
當特百惠於 2011 年首次推出時，每個伺服器叢集都由單獨的調度程序管理。 當時，Facebook 叢集是一組連接到一個網路交換器的伺服器機架，資料中心容納了多個叢集。 調度程序只能管理一個叢集中的伺服器，這意味著作業無法跨多個叢集分佈。 我們的基礎設施不斷發展，我們越來越多地取消叢集。 由於特百惠無法在不進行任何更改的情況下將作業從退役集群轉移到其他集群，因此需要應用程式開發人員和資料中心運營商之間進行大量努力和仔細協調。 當伺服器因退役程序而閒置數月時，此過程會導致資源浪費。
我們創建了一個資源代理來解決叢集退役問題並協調其他類型的維護任務。 資源代理追蹤與伺服器關聯的所有實體訊息，並動態決定由哪個排程器控制每個伺服器。 將伺服器動態連結到調度程序允許調度程序管理不同資料中心的伺服器。 由於 Tupperware 作業不再侷限於單一集群，Tupperware 使用者可以指定容器如何跨故障域分佈。 例如，開發人員可以聲明他的意圖（例如：「在 PRN 區域的 2 個故障域上執行我的作業」），而無需指定特定的可用區域。 即使叢集或服務退役，特百惠本身也會找到合適的伺服器來實現這一意圖。
可擴展以支援整個全球系統
從歷史上看，我們的基礎設施已分為數百個供各個團隊使用的專用伺服器池。 由於分散化和缺乏標準，我們的營運成本很高，閒置的伺服器更難以再次使用。 在去年的會議上 我們介紹了 ，這應該將我們的基礎設施整合到一個大型的單一伺服器園區。 但單一伺服器園區也有其自身的困難。 它必須滿足某些要求：
- 可擴展性。 隨著我們在每個地區增加資料中心，我們的基礎設施不斷發展。 伺服器變得更小、更節能，因此每個區域的伺服器數量都更多。 因此，每個區域的單一調度程序無法處理每個區域中數十萬台伺服器上可以運行的容器數量。
- 可靠性。 即使調度程式可以擴展那麼多，調度程式的大範圍也意味著出現錯誤的風險更高，並且整個容器區域可能變得難以管理。
- 容錯性。 如果發生巨大的基礎設施故障（例如，運行調度程序的伺服器因網路故障或斷電而發生故障），負面後果應該只會影響該區域的一部分伺服器。
- 易於使用。 您可能看起來需要為一個區域執行多個獨立的調度程式。 但從便利的角度來看，區域共享池的單點入口可以更輕鬆地管理容量和作業。
我們將調度器劃分為分片來解決維護大型共享池的問題。 每個排程程式分片管理該區域中自己的一組作業，這降低了與排程器相關的風險。 隨著共享池的成長，我們可以添加更多的調度程式分片。 對於特百惠用戶來說，分片和調度程式代理程式看起來就像一個控制面板。 他們不必使用一堆編排任務的分片。 調度器分片與我們先前使用的叢集調度器有根本的不同，當時的控制面板是分區的，沒有根據網路拓撲靜態劃分伺服器的共用池。
透過彈性運算提高使用效率
我們的基礎設施規模越大，有效使用我們的伺服器來優化基礎設施成本和減少負載就越重要。 提高伺服器使用效率有兩種方法：
- 彈性運算 - 在安靜時段縮減線上服務規模，並使用釋放的伺服器來處理離線工作負載，例如機器學習和 MapReduce 作業。
- 過載 - 將線上服務和批次工作負載放在同一伺服器上，以便批次工作負載以低優先順序運作。
我們資料中心的瓶頸是 。 因此，我們更喜歡小型、節能的伺服器，它們可以提供更多的處理能力。 不幸的是，在 CPU 和記憶體很少的小型伺服器上，過載的效果較差。 當然，我們可以將多個小型服務的容器放置在一台小型節能伺服器上，該伺服器消耗很少的處理器資源和內存，但在這種情況下大型服務的效能會很低。 因此，我們建議大型服務的開發人員對其進行最佳化，以便他們使用整個伺服器。
基本上，我們透過彈性計算來提高使用效率。 我們的許多主要服務，例如動態消息、訊息功能和前端 Web 層，都會根據一天中的時間而有所不同。 我們有意在安靜時段縮減線上服務規模，並使用空閒的伺服器來處理離線工作負載，例如機器學習和 MapReduce 作業。
我們從經驗中知道，最好將整個伺服器配置為彈性容量單元，因為大型服務既是彈性容量的主要提供者也是主要消費者，並且經過最佳化以使用整個伺服器。 當伺服器在空閒時間從線上服務中釋放時，資源代理將伺服器租給調度程序以在其上運行離線工作負載。 如果線上服務遇到尖峰負載，資源代理程式會快速召回借用的伺服器，並與排程器一起將其傳回給線上服務。
學到的教訓和未來的計劃
在過去的 8 年裡，我們一直在開發 Tupperware，以跟上 Facebook 的快速成長。 我們分享我們所學到的知識，並希望它能幫助其他人管理快速成長的基礎設施：
- 在控制面板與其管理的伺服器之間建立靈活的連線。 這種靈活性允許控制面板管理不同資料中心的伺服器，有助於自動化叢集的退役和維護，並使用彈性運算實現動態容量分配。
- 透過該區域的單一控制面板，可以更方便地處理任務並更輕鬆地管理大型共享伺服器群。 請注意，控制面板保持單一入口點，即使其內部結構因規模或容錯的原因而被分離。
- 使用插件模型，控制面板可以通知外部應用程式即將進行的容器操作。 而且，有狀態服務可以使用外掛介面來客製化容器管理。 透過這個插件模型，控制面板提供了簡單性，同時有效地服務許多不同的有狀態服務。
- 我們相信，彈性運算（將整個伺服器從批次作業、機器學習和其他非緊急服務的捐贈服務中拿走）是提高小型節能伺服器效率的最佳方式。
我們剛開始實施 。 目前，我們大約 20% 的伺服器位於共用池中。 為了實現 100%，需要解決許多問題，包括維護共享儲存池、自動化維護、管理跨租用戶需求、提高伺服器利用率以及改善對機器學習工作負載的支援。 我們迫不及待地想迎接這些挑戰並分享我們的成功。
來源： www.habr.com