倉庫規模作業系統的背景之倉庫規模計算機
目錄
前言
本文是Malte Schwarzkopf的博士論文《Operating system support for warehouse-scale computing》一個翻譯版本，融入了作者自身的經驗和理解，讀者如果想閱讀原文，可以訪問：http://people.csail.mit.edu/malte/pub/dissertations/phd-final.pdf
編寫本文的目的是提供一箇中文版本的文件，同時為自己保留一份學習筆記，供日後事件參考以及優化調整。當然，優化調整部分不能更新在公網，因為筆者同一時間在公司內網釋出了改文章，相應部分只會更新在公司內網的文章中。
背景
現代許多執行在資料中心中應用直接或間接依賴於大規模計算叢集分散式系統。這些資料中心概念上形成“倉庫規模計算機”（後文會大量用到倉庫規模這個詞，源於資料倉庫這個概念，反正理解為很大很大規模就好了，比如成千上萬的伺服器），因為這些應用的操作細節從終端使用者和程式設計師抽象出來。
與大多數現代計算機一樣，倉庫規模的資料中心“機器”有一個大規模的系統軟體棧，雖說是唯一包含分散式系統軟體的軟體棧。粗略地說，它包含三種類型的軟體：
- 本地作業系統核心作為本地機器硬體和應用程式的介面，獨立於硬體的軟體。作業系統核心強制隔離、仲裁機器資源，並代表其他軟體在本地執行特權操作。說白了，就是我們常用的作業系統，比如CentOS、Ubuntu。
- 分散式基礎設施系統是在倉庫及資料中心許多機器上或所有機器上執行的使用者空間應用程式。它們共同構成資料中心的“作業系統”。它們的許多服務都是經典OS功能的分散式版本，例如資料儲存、排程或協作(如zookeeper)。此處基礎設施已經99不僅僅侷限於虛擬機器這些，大部分PaaS也被納入到了基礎設施範疇，因為資料庫已經和檔案系統一樣成為應用程式必備的“基礎設施”；MapReduce是大資料應用必備的基礎設施；類似Zookeeper功能的系統是分散式應用必備的基礎設施。
- 使用者應用程式實現資料中心暴露給終端使用者的功能，依賴於分散式基礎設施系統提供的服務和抽象。他們由專用的基礎設施系統“作業管理器”或“叢集管理器”管理。這一點可以做個類比：單機應用系統就是本機暴露給使用者的功能，使用者用的是應用而不是計算機本身。但是這個應用依賴於作業系統的排程才能執行，因為在這個機器上有很多應用在同時執行，這個抽象可以延伸到資料中心級的系統上。
在本章中，我將介紹如何在當前的資料中心實現這種分散式軟體棧，以及為兩個關鍵部件“資源管理”和“叢集排程”程式設計更關鍵、更安全、更有效率的方案。
倉庫規模計算機
現代許多執行在資料中心中應用直接或間接依賴於大規模計算叢集分散式系統。這些資料中心概念上形成“倉庫規模計算機”（後文會大量用到倉庫規模這個詞，源於資料倉庫這個概念，反正理解為很大很大規模就好了，比如成千上萬的伺服器），因為這些應用的操作細節從終端使用者和程式設計師抽象出來。
與大多數現代計算機一樣，倉庫規模的資料中心“機器”有一個大規模的系統軟體棧，雖說是唯一包含分散式系統軟體的軟體棧。粗略地說，它包含三種類型的軟體：
- 本地作業系統核心作為本地機器硬體和應用程式的介面，獨立於硬體的軟體。作業系統核心強制隔離、仲裁機器資源，並代表其他軟體在本地執行特權操作。說白了，就是我們常用的作業系統，比如CentOS、Ubuntu。
- 分散式基礎設施系統是在倉庫及資料中心許多機器上或所有機器上執行的使用者空間應用程式。它們共同構成資料中心的“作業系統”。它們的許多服務都是經典OS功能的分散式版本，例如資料儲存、排程或協作(如zookeeper)。此處基礎設施已經99不僅僅侷限於虛擬機器這些，大部分PaaS也被納入到了基礎設施範疇，因為資料庫已經和檔案系統一樣成為應用程式必備的“基礎設施”；MapReduce是大資料應用必備的基礎設施；類似Zookeeper功能的系統是分散式應用必備的基礎設施。
- 使用者應用程式實現資料中心暴露給終端使用者的功能，依賴於分散式基礎設施系統提供的服務和抽象。他們由專用的基礎設施系統“作業管理器”或“叢集管理器”管理。這一點可以做個類比：單機應用系統就是本機暴露給使用者的功能，使用者用的是應用而不是計算機本身。但是這個應用依賴於作業系統的排程才能執行，因為在這個機器上有很多應用在同時執行，這個抽象可以延伸到資料中心級的系統上。
在本章中，我將介紹如何在當前的資料中心實現這種分散式軟體棧，以及為兩個關鍵部件“資源管理”和“叢集排程”程式設計更關鍵、更安全、更有效率的方案。
工作負載
倉庫規模計算用於支援需要大量計算和儲存資源的負載。大量機器的分散式既要及時執行並行處理及時響應大量的使用者請求，也要夠容忍故障不中斷終端使用者應用程式（例如移動或Web前端）。
一般來說，這樣一個數據中心的“負載”分為兩類：提供必要服務的基礎設施系統和處理資料或暴露給終端使用者的應用程式。
此外，負載也可以分為批處理和服務兩種型別。這種劃分與劃分成基礎設施系統和應用程式是一致的，大多數基礎設施系統是服務型別的負載。
- 服務型負載是持續執行，直接向終端使用者提供功能或面向終端使用者的應用程式。它們只因失敗、人為、叢集排程器干預而終止。分散式key-value儲存就是一種服務。
- 批處理型負載是在有限的資料上啟動處理作業，執行某些工作，作業處理完成後終止。批處理工作負載的一個例子是定期執行日誌爬蟲。
從經驗上看，大多數的工作和任務通常是批處理作業，但隨著時間的推移大多數叢集資源都用於服務型作業。
按照批處理和服務分類並不意味著優先順序順序，然而，服務可能具有更高優先順序，因為對於服務最終端使用者請求和保證其他應用程式可用，他們是必不可少的。
值得注意的是，大多數服務型作業（和大多數基礎設施系統）都是面向請求的，線上事務處理（OLTP）型別的工作內容（即使它們不需要顯式使用事務處理）。相比之下，批處理型作業通常是線上分析處理（OLAP）型別工作內容，對於請求也沒有太多的嚴格限制，並且容忍較高的響應延遲
分散式基礎設施系統
基礎設施系統是資料中心應用程式執行的關鍵。他們的功能通常和傳統作業系統核心一樣。例如，他們提供協調、儲存和檔案系統以及上層應用程式依賴的類似程序的抽象。因此，一個新的、相互依賴的基礎設施系統的“棧”被創建出來。圖2.1和圖2.2用google和facebook基礎設施軟體棧中已知的分散式元件來展示這一點。
圖2.1：google基礎設施棧。我省略了F1資料庫（被Spanner取代）和未知或未發表的前端服務系統。箭頭表示資料交換和系統之間的依賴關係；“分層”並不意味著依賴或關係。
圖2.2：facebook基礎設施棧。沒有一個類似於google的Borg和Omega 的共享叢集管理器，目前還不清楚Bistro是否處理所有的負載。箭頭表示資料交換和依賴關係；“分層”並不意味著依賴或關係。
廣義地說，基礎設施棧通常包括協調和叢集管理服務、儲存服務、並行資料處理框架。
協調和叢集管理:許多資料中心基礎設施服務是相互依賴的。並且需要一個權威的配置資訊源來協調彼此。此協調通常實現為可靠的、一致性的分散式key-value儲存。該儲存記錄主程序（leaders）的位置，提供分散式鎖定，並通過跟蹤服務任務的位置來實現服務發現。谷歌Chubby的服務是基於Paxos共識演算法實現此功能，雅虎的基於Zab的Zookeeper和基於Raft的etcd是類似的開源協調服務。這些都使用分散式共識演算法，在故障時保證足夠的可靠性。
群集管理器需要在管理服務和應用程式任務之間仲裁資源。這需要跟蹤機器是否線上，啟動、監視和終止的任務，使用叢集排程程式來決定任務執行位置。Mesos及谷歌的Borg和Omega是這樣的叢集管理者。任務排程決策是群集管理器的一部分，雖然不是所有部署環境都使用統一的叢集管理器。相反，一些資料中心被劃分為單一功能的子叢集，每個都有獨立的叢集排程程式。我將後續章節中回顧這些以及其他排程器的體系架構。
資料儲存：倉庫規模資料中心儲存海量的資料，但使用什麼樣的基礎設施系統取決於資料的訪問頻率和結構。塊儲存要麼是非結構化儲存的形式，要麼類似於分層網路檔案系統或者本地檔案系統。facebook的Haystack和f4是非結構化儲存，用於儲存和複製不同熱度的二進位制大物件（blobs）。相比之下，google的GFS及其繼承者Colossus，facebook和yahoo使用Hadoop分散式檔案系統（HDFS）、微軟使用的TidyFS和FDS都是分散式檔案系統。
對於更多的結構化的資料，資料中心執行分片、副本的key-value儲存，要在一致性和效能之間的變化尋找權衡。BigTable在GFS的之上實現由行、列和時間戳索引的三維對映，並且提供行級一致性；facebook網使用HBase通過HDFS以類似的方式儲存使用者的訊息。其他資料儲存更接近傳統資料庫並提供ACID的事務能力：例如google基於BigTabe的Migastore和Spanner。在某些情況下，經典的分片和副本的關係型資料庫也在用：例如facebook，使用MySQL實現長期結構化的儲存。
對於請求型服務應用程式的快速訪問，資料通常快取在臨時儲存中。這些儲存可以是通用key-value儲存(例如facebook用memcached作為記憶體層服務)。或者專門為特定的用例設計，例如，google的Drimel和PrimeReal，以柱狀形式儲存資料實現快速聚集查詢，而facebook的Tao是以圖形結構快取區域性資料。
並行資料處理：一些分析應用通常需要及時地處理非常大量的資料。為了向非專家程式設計師開放一個程式設計介面，並行資料處理框架隱藏具有挑戰性的分散式程式設計，例如容錯、排程、和基於訊息的通訊。
MapReduce是被廣泛使用的對這種透明的分散式並行的一種抽象。它相對簡單(使用者只需實現一個map（）和一個reduce（）函式)使得他特別吸引人。其他框架也具表現力：例如，微軟的Dyyad將計算為資料流圖模型。
為了能讓並行資料處理能夠被使用者訪問，甚至在資料處理框架的之上部署更高階的抽象：常見的例子是特定領域的語言（例如google類SQL的Tenzing和facebook使用的Hive）或語言整合（例如google的FlumeJave和微軟的DryadLINQ）或像facebook的Scuba這樣的互動UI。
對於某些應用，專用系統執行專門的處理：例如google的Percolator，專門針對BigTable中的Web搜尋索引進行快速增量更新。同樣，流資料是用特殊的流處理框架來處理的，比如google的MillWhile，雅虎的S4和它的繼任者Storm，twitter的Heon。圖形結構化資料處理系統讓使用者以“頂點為中心”的方式表達計算，比如facebook的Unicorn和google的Pregel是眾所周知的。
監測和跟蹤:上述基礎設施系統之間複雜的相互關係，需要定製效能跟蹤和除錯工具。因為不同的機器和上下文的事件一定是相關的。這樣的工具要麼使用通訊庫入侵式掛入，就像在google的Davper中或twitter的Finagle，或利用通用識別符號構建跨系統請求跟蹤，如facebook的ByTrace。大量可用的跟蹤資料讓統計分析能夠匯出因果關係。
應用與使用者作業
應用程式形成了資料中心的“業務邏輯”：它們為終端使用者的請求服務，分析資料以獲得知識，亦或支援其他生產型任務。
例如，Facebook的Web伺服器通過聚合從TAO、memcached、Haystack和f4儲存系統來結果響應終端使用者請求。在同時，Hive執行MapReduce作業，分析相同的資料以收集使用者行為資訊，以及執行長時間的MapReduce作業在儲存系統之間移動資料。其他公司也有類似的設定。
這樣的應用程式和使用者作業與基礎設施服務有三點不同：
- 不像大多數基礎設施系統那樣直接與本地OS核心介面，應用程式通常依賴於與基礎設施系統互動的庫。
- 高效能和低延遲對於某些應用（例如服務前端）非常重要，但其他應用可能不需要（例如批處理工作），而作為服務級別目標的一部分，幾乎所有基礎設施服務都受到延遲限制。
- 相比於基礎設施系統開發，應用程式開發人員使用高階語言，並依賴於高階介面；因此，應用程式程式碼是對機器、協調和並行的細節一無所知。
由於應用程式僅僅是基礎設施系統提供的API的消費者，對底層作業系統的更改（無論是在本地OS核心中還是在分散式作業系統中基礎設施元件）對於應用程式程式設計師來說是完全不可見的，後面的章節將說明這一點。
硬體異構
倉庫規模的資料中心通常批量購買機器，因為量大自然就便宜。然而，在實踐中，機器是多種型號混合的，有硬體升級的原因，也有故意多樣化的原因。
例如，google在2011釋出的叢集跟蹤記錄中，由大約12550臺機器，其中包括三種不同的機器平臺和十種不同的機器規格。如果再考慮其他屬性（比如“核心”版本，時鐘速度，是否存在外部IP地址，或機器是否執行GFS chunkserver）,機器屬性組合的數量增長到34個。在這些組合中，有八種組合的機器超過了100臺，有十三種組合的機器數量在十臺或更多（圖2.3）。來自Amazon等其他資料中心也證實了資料中心這種異質性的統計。此外，影響效能的關鍵點：google已經發現到相同負載在不同的平臺上執行表現為不同的效能特徵。
圖2.3：Google在2011年中公開的跟蹤叢集機器型別和配置的桑基圖。叢集是異構的：12583臺機器由於平臺、規範和屬性的不同變得越來越碎片化。
異構硬體的影響：為了說明這種影響，我們做一組簡單的基準測試。在一組空閒機器（表2.2）測量整數和浮點運算吞吐量、記憶體訪問頻寬、磁碟I/O頻寬和網路I/O成本（表2.1）。所有的機器都是2009年後的當代資料中心中的主流機型。
表2.1：機器異質性基準負載
表2.2：圖2.4中實驗中使用的機器配置。所有機器執行Ubuntu 14.04與Linux 3.13。
圖2.4顯示了歸一化到最老的機器型別（A）的結果。對於單執行緒，計算使用SPEC CPU2006基準hmmers和gromacs，高CPU時鐘頻率的機器（型別A和C）超過低CPU時鐘頻率的機器（B型）D）。我們預期的一樣，CPU效能與Linux核心測量BogoMips大致相關。
然而，單執行緒STREAM記憶體訪問基準，僅限於單個儲存器控制器的頻寬。A型機器（唯一的單顆CPU機器）優於所有較新的機器型別。這可能是由於NUMA機器上快取一致性的開銷。
在多執行緒STREAM NUMA中，多個儲存器控制機器效能輕易的高過A型機器高達2倍。D型優於更新的Valencia-based的C型別，因為D型機器有四個記憶體控制器，而不是兩個。然而，總吞吐量最高的是由雙控制器QPI-based Sandy Bridge致強機（B型）。
儲存和網路基準更依賴於外圍裝置而不是CPU，儘管體系結構和時鐘速度也有影響。從磁碟讀取時（bonnie-rd）和寫入(bonnie-wr），較新型機器和A型對比，效能高出20 - 40%，儘管A型機器具有高速SAS硬碟驅動器。
對於iperf網路I/O，所有的機器都飽和鏈路。但是，可以看到型別A機器CPU負載最低，這可能是由於A型機的NIC掛起了CPU導致的，在其他機器的NIC是不可用。
圖2.4：表2.2列出的異構機器上微基準的歸一化效能，越高越好，不同機器型別間存在±50～100%的差異。
同位干擾
即使在同類機上，當多個負載位於同一位置時，效能也會發生很大變化。具體來說，工作負載經常爭奪共享的硬體或軟體資源。爭用可以是直接的，例如，用於訪問硬碟、網路介面或一個鎖，或者它可以是間接的，例如通過快取驅逐。
在商用伺服器中的一些硬體資源配置了極高的效能（例如CPU），而其他資源由於機器體系結構而過度購買——例如，NIC網路傳輸通常是不需要消耗CPU組資源的。說白了，由於CPU效能太高，與其搭配的其他外設效能也非常高。因此超額購買結果是受到物理約束、硬體成本浪費和類似典型伺服器一樣的較低負載。接下來，我會使用對快取高度敏感的測試基準和並行資料處理工作負載來展示各種硬體資源競爭對效能的影響。
成對干擾：使用SPEC CPU2006等通用基準可以容易地測量同位干擾。我曾經做過一些測試，資料顯示B型和C型兩種機器，機器上只有兩個任務，SPEC CPU2006執行時基準遭受到高達2.3倍的退化。
圖2.5：在同位實驗中使用的系統結果。Ci是物理CPU核心，而Ti表示超執行緒；一級快取（L1$）顯示為紅色，二級快取（L2$）在綠色，三級快取（L3$）在藍色。
表2.3：成對干擾實驗中使用的資料中心的常規應用（圖2.6）
然而，像SPEC CPU2006這樣的基準使用典型的高度優化的計算核心,具有良好的快取親和性，所以共享會造成非常大的影響。而很多人發現，大多數資料中心應用程式並沒有調整為快取親和性。
因此，我用一組資料中心的應用重複相同的同位實驗。我執行表2.3中不同組合的應用，在12核心Opteron 4234（“Valencia”圖2.5a）以及12核英特爾Xeon E5-2420（“Sandy Bridge”圖2.5b）處理上將其固定到不同的核上。為了隔離競爭並且設定儘可能接近SPEC CPU2006的實驗，我只在單個核心上執行每個應用程式
圖2.6顯示了不同應用一起執行（同位）的標準化執行時（runtime）。很明顯，與單獨執行相比，干擾發生時工作負載執行時降級高達2.13倍。與SPEC CPU2006觀點一樣，干擾的頻率和幅度隨著共享記憶體層級增加而增加。例如，PageRank和QuickSort在圖2.6a中的Opteron上（沒有快取共享）和圖2.6c（共享的L3快取記憶體）之間是有效能差異的。
圖2.6：AMD Opteron 4234（左列）和Intel Xeon E5-2420（右列）上的不同資料中心應用程式之間的同位干擾。所有執行時在y軸基準存在的情況下測試x軸基準，歸一化到為x軸基準在其他空閒機器上的獨立執行時。黑色方塊表示結果超出了標度；灰色方塊表示基準測試失敗。
很多實驗資料(此處不列舉)說明了許多效能退化的同時伴隨著快取miss次數的增加。然而，在某些情況下，即使與快取記憶體未命中無關也存在干擾，或者當應用程式在單獨的CPU(多路CPU)上執行時，也存在干擾。這種干擾可能發生有以下幾個原因：
- 應用程式可以爭奪其他共享機器資源，例如磁碟或網路介面；
- 作業系統抽象（例如，不可伸縮的鎖或核心資料結構）被競爭
實驗還表明，兩臺機器出現競爭情況下表現不同。在Xeon機器上，Spark的Sql查詢應用程式比QuikSort排序和PageRank的干擾更為嚴重。（超過2倍效能衰減，相比Opteron上的1.4倍）。然而，Xeon對L3共享快取的競爭並不那麼敏感，由於L3快取更大（15MB相比於Opteron的6M）。同樣，應用程式在Xeon上使用超執行緒（共享一個256KB的L2快取記憶體）干擾也非常強，但在Opteron共享一個L2的cache(2MB)受到的影響較小。
多路干擾：到目前為止，我們已經考慮了空閒機器上成對的工作負載。實際上，資料中心中的許多核心機器一次執行兩個以上的任務：谷歌的生產叢集的機器執行8個任務排序也僅僅在中位，排序高位的機器大約可以同時執行25個任務。
因此，我研究了多個應用(多路)同位（對於多個CPU核）是如何影響資料中心應用工作負載。圖2.7顯示了七個不同批處理工作負載在28個機器的叢集上的標準化執行時。大部分工作負載是使用Naiad實現的（見表2.4）,叢集執行在80到90%任務時隙利用率。與許多叢集排程程式一樣，作業是由一個簡單的隨機第一匹配演算法排程。作為排程程式偶爾做出糟糕的決定，工作負載間最終會產生干擾。然而，更糟糕的是有些應用比其他遭受到了更大的效能衰減：計算密集型的影象分類任務平均降級約20%，I/O密集型的 Netflix退化2.1倍，高度迭代和同步密集型的強連線分量（strongly connected components
）和PageRank工作負載降級達3倍。這些資料還算是比較符合預期，計算密集型的任務分別在獨立的核心上執行，隔離性比較好，干擾自然就少；而IO密集型的任務因為共享一個主機的磁碟和網路，資源競爭帶來的干擾是非常大的。
圖2.7：28個機器叢集上的七個工作負載的歸一化執行時,使用隨機第一匹配排程策略。所有的結果都歸一化到獨立的工作在空閒叢集上的執行時。
這個實驗表明，在機器和叢集資源上的干擾會對現實的批處理作業從頭到尾的執行產生實質性的影響。
相關研究：我的觀察證實了相關工作報道的結果。例如，Lingjia Tang等人展示多執行緒工作負載由於執行緒放置而表現出20%的效能變化。Haris等人發現任務因為錯誤排程放置在繁忙機器上時甚至降級高達3.5倍。同樣，Mars等人發現谷歌不同程序中的工作負載35%的應用級效能衰減都是因為共享了同一個機器。
Xiao Zhang等人同位干擾對谷歌生產服務的影響並發現有些應用效能最壞10倍退化。Leverich和KoyyrkIS對延遲敏感的key-value儲存的後臺批處理工作負載間的影響進行深入研究同樣也證實了干擾對效能的影響。最後，Delimitrou和Kozyrakis研究了一系列資料中心工作負載對專用機和EC2虛擬機器的干擾，發現干擾高達2倍。
表2.4：圖2.7所示的干擾實驗中使用的批處理（頂部）和服務（底部）工作負載。
我的實驗和豐富的相關工作表明，對於資料中心干擾是一個關鍵問題，並建議在多個層次（在一個機器內或者跨機器）更好的排程
總結
倉庫規模的資料中心是一個比較新的環境，其中分散式系統軟體執行在數千臺相互連線的機器上。它們的工作負載是異構的：表現為天然的差異性，對資源需求，以及他們機器和叢集資源的影響。
此外，資料中心硬體遠沒有想象的均勻，共享基礎設施的工作負載之間干擾可以對效能產生重大影響。為了充分支援一個通用資料中心工作負載，我們必須做到：
- 開發機制處理叢集中硬體異質性，用合適的機器匹配工作負載。
- 避免資料中心工作負載之間的同位干擾，並通過分離那些干擾的工作負載提供可預測的效能。
在下一節中，我將介紹資料中心工作負載與作業系統的關係。