目錄
前言
本文是Malte Schwarzkopf的博士論文《Operating system support for warehouse-scale computing》一個翻譯版本，融入了作者自身的經驗和理解，讀者如果想閱讀原文，可以訪問：http://people.csail.mit.edu/malte/pub/dissertations/phd-final.pdf
編寫本文的目的是提供一箇中文版本的文檔，同時爲自己保留一份學習筆記，供日後事件參考以及優化調整。當然，優化調整部分不能更新在公網，因爲筆者同一時間在公司內網發佈了改文章，相應部分只會更新在公司內網的文章中。
操作系統
前面章節中的例子說明了典型的大型數據中心的工作負載，同時它們的細節不同，所有分佈式應用程序都依賴於本地的和分佈式的底層系統軟件。在這一節中，我考慮在數據中心操作系統的性質和作用。操作系統提供硬件抽象，多進程，資源共享以及程序和用戶之間的安全隔離。這種操作系統概念在六十年的過程中進化，主要驅動力就是資源共享效率。
起源：早期的機器只相當於原始的引導加載程序，例如“某個特定的引導程序”。 在圖靈的自動化計算引擎ACE上的一種不變的初始次序，或者在EDSAC上硬連線的初始化命令。很快大家都意識到，由系統軟件運行多個用戶程序對於高效的使用機器是至關重要的。
因此，設計了監視器（或監控器）程序自動按順序運行多個作業（“批處理”）。這樣的批處理監視器開啓了多道程序設計（multiprogramming
），但沒有支持交互系統的使用。機器的時間共享能夠使用多個程序共享處理器看似並行執行，但是需要一種機制來中斷當前計算並跳轉到監督器中。早期共享系統，如CTSS和Titan監控器，作爲一個批量監控器和交互式操作系統的組合：遠程終端交互式的訪問計算機，但處理器在空閒時才運行傳統的批處理作業。這有點類似於數據中心批處理和服務之間的資源共享，其目的是回收服務的空閒資源嘗試性用於批處理作業。這裏需要注意的是，當批處理作業運行過程中被優先級更高的服務或者批處理中斷時，可以選擇“暫停”或者“結束”作業，這要視情況而定。筆者以前設計的視頻/圖像高性能計算平臺選擇的就是結束，因爲這種方案實現比較簡單，受限於現場環境沒有比較好的“暫停”方案，利用資源空閒期賭博性的執行批處理作業，萬一成了呢！
時間共享產生了許多在今天的操作中使用的保護和隔離機制：段、虛擬內存、保護環(protection ring)和一個具有ACL的單個文件系統命名空間。然而，所有這些抽象專注於在多個程序和用戶之間安全地共享一臺機器。後面，我解釋如何分佈在多臺機器上。
經典分佈式操作系統
早期的計算只限於一臺帶有遠程終端的通用機器。然而，跨機器的分佈式操作的研究早在20世紀60年代中期，當Fuchel和Heller在兩個數據中心6600臺機器之間共享一個擴展的核心存儲（extended core store ECS）。他們的“基於ECS的操作系統” 通過把數據交換到ECS使進程在機器之間遷移成爲可能，並且引入了緩衝的I/O和容差故障。其實這一點比較好理解，就好像現在的虛擬機關機後再把虛擬機文件拷貝到另一個主機上啓動就可以復原，當然進程遷移要比虛擬機遷移要輕量一些。
然而，直到20世紀70年代末，當小型機和個人工作站的成本、穩定性變得可以接受，同時出現相對廉價的局域網技術，幾乎沒有一家機構運行多臺計算機。當第一次可能擁有大量連接的計算機時，資源池的概念觸發分佈操作系統的發展（見表2.5）。
表2.5：典型的分佈式操作系統及其屬性。
早期分佈式操作系統：HYDRA的C.mmp機是其中之一最早的分佈式操作系統。C.mmp由十六個具有共享時鐘和共享存儲的PDP11機器組成，通過交叉連接。儘管它相當像C.mmp的對稱多處理(Symmetrical Multi-Processing SMP)架構，HYDRA開創了分佈式操作系統幾個關鍵的原理，比如使用分佈式對象作爲主要抽象，容忍機器和連接故障，以及基於能力(capability-based )的保護。
Medusa，CMU早期的另一個分佈式操作系統，目標是Cm*架構，以10爲簇連接50個“計算模塊”。由於在模塊之間通信成本高，Medusa強調了局部性和限制性共享。Medusa是以顯式消息傳遞爲中心的分佈式操作系統的先例之一，並抽象三類對象暴露給用戶，包括（i）頁、（ii）管道和信號量，和（iii）文件、“特別工作組（task forces）”和描述符列表。由於硬件的限制，Medusa只提供了適度和粗粒度的保護：通過描述符訪問對象，這些描述符駐留在受保護的描述符列表中 。關於特別工作組原文是task forces，我的理解是具備較高權限的一些進程/線程之類的東東。
消息傳遞系統:Rochester Intelligent Gateway（RIG）的Aleph OS、Acdent和Mach是80年代初開發的三個分佈式操作系統，他們都是基於利用端口的消息傳遞（進程消息隊列）。
Aleph的設計很簡單：端口不受保護，全局標識符被當作數據對待，消息傳遞不是完全透明的，即用戶必須瞭解消息接收者的定位（這句話筆者也不太理解想，所以也找不到好的翻譯詞語）。它的使用場景是提供小型計算機網絡，並充當大型、分時複用機器的“網關。
Accent重新設計RIG的原理，圍繞虛擬內存、完全透明和一個對象風格編程模型。Accent有一個磁盤上的“頁面存儲”用於持久存儲，內核將頁面加載到內存中以響應消息。爲了優化較大消息傳輸，Accent使用copy-on-write重新映射到主機地址空間，跨機器邊界通消息過懶檢索（我的理解是需要時在檢索）遠程存儲來實現。Accent編程人員使用接口描述語言IDL編譯器生成的高級的過程調用接口，類似的IDL概念存在於後來許多的分佈式和微內核操作系統中，以及在今天的數據中心RPC庫中，例如Protocol Buffer。
Mach使用了Accon的原理，並擴展它們支持多處理器和兼容Unix。它引入了線程，允許共享任務的（進程的）端口，可以用戶空間共享內存做同步，並支持外部用戶空間頁。Mach作爲一個微內核架構具有影響力，但作爲一個分佈式操作系統，它因爲全透明的消息抽象的通信成本比計算昂貴得多而最終受到阻礙。
其他分佈式操作系統提供了更接近傳統系統調用API的接口。例如，LOCUS和VAXCluster在VAX機器上創建分佈式系統，擴展VAX/VMS和Unix範例用於支持分佈式。LOCUS在共享存儲的副本文件上支持嵌套事務，每個副本所在本地操作系統強制執行互斥。LOCUS通過分佈式命名目錄定位文件，對它們的訪問是完全透明的。還有，LOCUS支持的動態集羣節點，並在網絡分區依然保持可用，在修復時使用協調協議合併分歧狀態。相比之下，VASCluster組合了一些VAX機器和專用存儲節點成爲單個安全域。決定是由節點投票產生的，出現分區時，少數節點分區不可用。不像LUCUS，分佈式存儲中的文件操作依賴於分佈式鎖管理器。
基於RPC的系統：20世紀80年代後期，出現了幾個大型分佈式操作系統項目，例如V、Sprite和Amoeba，它們使用遠程過程調用（RPC）模型，沒有直接暴露消息格式。然而，他們的方法不同：Sprite和V目標是每個用戶工作站（per-user workstation）模型，使用進程遷移來利用空閒資源。Sprite基於共享文件系統（類似LOCUS），強調了Unix的兼容性（比如Mach），並且沒有開放支持分佈式應用程序的特殊特性。相比之下，Amoeba假設所有用戶共享基於分佈式對象和能力（如Chorus）的集中處理池。它有一個微內核體系結構，具有系統範圍用戶空間的服務和完透明的遠程操作。
Plan9：Plan9是在20世紀90年代初作爲UNIX的概念繼承者開發的。對於透明的分佈式操有更普遍的文件抽象和內核級支持。Plan9目標是網絡終端用戶的工作站，並提倡以文件爲中心，允許遠程資源掛載到每個進程命名空間。因此，通過命名空間掛載，本地應用程序可以透明地與遠端進程、設備和其他資源交互。
Plan9從未被廣泛採用，但它的一些關鍵概念隨後出現在操作系統：Linux中目錄結構的procfs是一個以暴露文件的方式控制鉤子的例子；容器使用的內核命名空間是每個進程一個命名空間的例子；和基於JSON的REST API類似於Plan9的文本消息傳遞。
爲什麼分佈式操作系統不能被採納？分佈式操作系統開發超過了30年，當時他們的特徵很少出現在現代操作系統中。我相信分佈式操作系統未能廣泛採用的原因有三：
- 沒需求.20世紀80年代的工作負載很少需要多臺機器的資源，複雜的分佈式操作很難讓他們體現價值。經典的分佈式操作系統是可行的技術，但是沒有任何迫切的使用場景。
- 單機性能增益戰勝了並行計算。原則上可以利用並行性提高性能的工作負載通常在大型、昂貴、分時複用的機器上運行也很好。對於桌面工作負載而言，並行計算很難獲得收益，因爲更快的工作站很快就可用了。
- 計算和網絡速度之間的差異更有利於本地計算。儘管隨着網絡技術的不斷完善，本地計算速度仍然大大超過了跨機的通信速度。事實上，這個差距在80年代末擴大了：時鐘速度迅速增加，但網絡延遲僅緩慢地降低，使得遠程消息傳輸變得越來越昂貴。
然而，在現代數據中心的環境下，所有這些條件都發生了重大變化：
- 工作負荷已經需要分佈式。數據中心工作負載從根本上需要分佈式規模的擴容和容錯能力，以及面對大量機器分佈式是必要性而非可選。
- 單機性能提升放緩。工作負載不再依賴機器變得越來越快。此外，基於請求和數據並行的工作負載需要超過單個機器資源的網絡和存儲帶寬。
- 網絡性能相對於計算速度增加。20世紀80年代計算速度超越網絡速度的趨勢在90年代開始逆轉：網絡帶寬仍然增加並且接近DRAM帶寬，並且網絡延遲再次降低。
因此，數據中心運營商已經開發了分佈式基礎設施系統滿足這些需要。在下一節中，我將在概念上的“數據中心操作系統”中討論他們的作用。
數據中心操作系統
在倉庫規模的數據中心中看到的工作負載需要跨機器協作、資源管理、數據共享和身份驗證。專用分佈式基礎設施系統服務於更上層的用戶應用程序。用戶應用程序依賴於分佈式基礎設施系統，就像傳統應用程序依賴於本地操作系統一樣：它們假設分佈式基礎設施服務總是可用的，並且依賴它們實現關鍵功能（例如，持久存儲）。因此，分佈式基礎設施系統充當數據中心操作系統。
表2.6列出了傳統單機操作系統功能的分佈式基礎設施等價物。例如，集羣管理器在啓動、調度和終止任務時形成特權內核的分佈式等價物。集羣管理器還執行准入控制，並在不同的任務之間劃分硬件資源(另一個傳統的內核職責)。同樣，分層分佈式文件系統是傳統本地和網絡文件系統的可伸縮等價物，旨在公開類似的存儲抽象。
表2.6：許多經典的本地操作系統組件在當前的分佈式基礎設施系統中具有等價物，它們構成了事實上的數據中心操作系統。
然而，這個列表僅僅有點粗略的近似。一些分佈式基礎設施沒有直接的本地操作系統等價物：非結構化存儲系統，如blob存儲和鍵值存儲，最多可以視爲繞過內核文件系統或在其上構建的數據庫後端的等價物。
在其他情況下，類比更加微弱：例如，並行數據處理系統在某些方面是多線程庫的分佈式等價物，但是通常具有更高層次的編程模型和內置的容錯機制。同樣，用於分佈式鎖定、資源和服務發現的協調服務在傳統操作系統中也有類似的前輩（例如，UNIX/etc文件系統和Windows註冊表），但是協調服務必須使用Paxos或Raft等算法來實現分佈式一致性，以便在多個機器之間提供一致視圖。可以這麼理解：單機的多個服務一般採用文件系統/註冊表等實現全局配置，但是對於分佈式系統來說，全局的配置也是通過每個單機的文件系統/註冊表實現，但是要通過一致性算法實現每個單機的文件系統/註冊表的內容一致。當然了，我們肯定不能直接訪問協調服務的文件系統，而是訪問協調服務提供的接口，這樣解釋是爲了方便理解。
鑑於這些相似之處，人們可能會想知道爲什麼這些系統不是從經典的分佈式操作系統抽象的基礎之上建立，開發人員之所以設計自己的抽象並從頭構建新系統，有兩個原因：
- 靈活性：數據中心棧通常有幾個專用的系統，例如Facebook棧中不同的緩存系統。這些系統不是衆所周知的長期用例發展而來，而是爲了響應緊急的業務需求。從零開始構建系統可以快速演進，獨立於更新很慢的廣泛使用的標準、通用抽象或操作系統擴展。
- 不可用性：經典分佈式操作系統未來不再被使用，它們的抽象在當前的操作系統中不存在或者沒有被採用。因此，沒有廣泛部署的用於構建分佈式系統的抽象可用。
數據中心操作系統的這種演進產生了一系列系統，這些系統對於它們的特定用例和部署工作得很好。然而，這並不是沒有它的缺點，導致幾個問題和挑戰，我接下來將討論。
問題和挑戰
與單機操作系統和經典的分佈式操作系統不同，組成數據中心操作系統的基礎設施服務集合實際上在某種程度是點對點的，並且分佈式操作系統組件缺乏統一性和可組合性。
表2.7通過比較當前數據中心基礎設施軟件和經典的分佈式操作系統來說明這一點。在高層上，顯然，經典的分佈式操作系統在抽象上力求統一，期望它們被各種各樣的應用程序使用。
表2.7：當前用在“數據中心操作系統”的分佈式基礎設施系統和經典分佈式操作系統的比較。
然而，數據中心操作系統中的每個系統都有自己的方法、API和抽象。接下來，我將討論這種差異對數據中心基礎設施的效率和安全性的影響。
效率
不同的分佈式基礎設施組件使用並公開它們存儲和處理的數據的表示：例如，考慮HDFS文件vs Spark RDD vs BigTable的三維映射中的值。所有這些都包含任意的二進制數據，但是不復制數據就不可能從一個表示轉換爲另一個表示。
這不僅導致不必要的拷貝，而且使不同系統之間的數據共享複雜化：不存在共享只讀內存映射的分佈式等價物，例如，在Web服務器、分佈式文件系統和分析作業之間共享的一組圖片。實際上，由於這個原因，數據中心基礎設施最終得到了多個、不協調和衝突的數據緩存實現：本地機器操作系統緩衝區緩存、memcached之類的鍵值存儲以及Tachyon之類的文件系統緩存覆蓋。
現有的分佈式系統的抽象也常常缺乏對內省(計算機程序在運行時檢查對象類型的一種能力，通常也可以稱作運行時類型檢查)的支持。如果不知道特定於系統的API細節，則很難或不可能找到數據的位置、它們的持久性或它們副本的位置。然而，這些信息對於跨系統優化可能是至關重要的。例如，從緩存在另一臺機器內存上的數據集讀取比從本地磁盤讀取更有效，但是寫入可能需要在不同的故障域中進行復制。
最後，大多數當前數據中心管理資源的基礎設施系統都有一箇中心化控制器：例如Borg中的BorgMaster、HDFS中的NameNode和Spark中的Spark master。“高可用”是通過控制器的多副本實現的，不以分佈式方式管理資源及其元數據。
因此，數據中心操作系統的效率取決於具有更加統一、支持內省和分佈式的資源管理抽象。實際上，未來的數據中心硬件趨勢——例如RDM的預期廣泛部署——只會加劇這種需求。
安全
命名還與資源存在的可否認性密切相關：如果用戶在鍵值存儲中獲得數據項的鍵，那麼他們可以認爲它存在。大多數現有系統沒有名稱空間，因此不能劃分資源發現（比如只能看到自己所在命名空間的資源）或選擇性否認絕資源存在（即使資源存在但是也看不到），無論它們是基於能力權限的還是基於ACL的。例如，memcached命名空間必須使用鍵前綴或後綴實現，並且HDFS目錄列舉只能通過UNIX文件系統權限表達拒絕。
當前的訪問控制方案不僅過於粗粒度，而且缺乏一致性：每個系統有它們自己主體（例如，HDFS中的用戶/組、Mesos中的用戶和框架工程）、身份驗證方法和限制屬性的自定義概念。由於每個系統都從頭開始實現訪問控制，而且常常不完整，因此多個用戶訪問同一數據中心操作系統的組件的端到端安全性和隔離性通常很差。
最後，數據中心運維人員需要審計資源訪問，不幸的是，當前系統要麼根本不支持審計，要麼僅僅支持定製的審計日誌（例如，在HDFS中）。
經典的分佈式操作系統通過依賴能力保護解決了許多這些問題，主要有兩個原因。首先，雖然ACL和權限都可以被分佈式管理，但是由於它們不需要使用ACL和能力對主體進行身份驗證，所以它們適合分佈式使用。第二，能力權限很好地映射到分佈式系統中常見的數據流抽象。它們傳統的缺點——複雜的編程模型和撤銷的困難——在完全分佈式的環境中影響不大。
顯然，當前數據中心基礎設施將受益於使用統一方法實現的更細粒度的保護和訪問控制。因此，在數據中心環境中，良好的安全性和細粒度保護需要基於廣泛的、細粒度的能力訪問控制。
觀察
對當前充當操作系統的數據中心繫統軟件的調查表明，有很大的改進潛力。確實，其他人也提出了類似的觀點，並呼籲在數據中心操作系統中採用更統一、可重用和可組合的抽象和機制。
我的主要觀點是，經典的分佈式操作系統已經解決了上述許多問題——儘管是在稍微不同的上下文中——因此，我們可以並且應該向他們學習。因此，我們可能能夠識別新的通用分佈式操作系統抽象，這些抽象爲當前的數據中心操作系統組件提供更加統一、有效和安全的資源管理和訪問控制。
下一節將研究我們是否可能希望僅通過少量的抽象來支持現有數據中心應用的需求。
新抽象的可行性
對於一個數據中心操作系統來說，新的資源管理和訪問控制抽象的概念必然會引起複雜性的問題：需要多少這樣的抽象來支持通用應用程序，我們能夠讓應用程序來僅使用新的抽象嗎？後者從安全性角度來看很有趣：只使用新抽象的應用程序不可能繞過它們的訪問控制機制。
關鍵問題是，一小組操作是否足以有效地支持數據中心應用程序——或者甚至僅僅支持性能敏感的“數據平面”。如果是這樣，那麼數據中心操作系統的清潔模型似乎是可行的。下面，我提出一個探索性的研究，提供了對這個問題的一些見解。
實驗：我使用Linux系統調用作爲典型數據中心應用程序調用的操作系統功能的（原始）代理，我研究了四個應用程序：Hadoop MapReduce、Redis鍵值存儲、Zookeeper協調服務和GraphChi圖形計算框架。使用典型的工作負載對每個應用程序進行基準測試，並使用strace監視其系統調用調用。當然，這無法捕獲所調用的高級分佈式操作，但是它給出了一個指示，表明一個乾淨的模型必須提供最小的本地操作系統功能。
圖2.8：公共數據中心應用程序上的探索性系統調用跟蹤的結果。
圖2.8a比較了不同應用程序調用的不同Linux系統調用的總數。對於Hadoop，我測量了典型Hadoop集羣的四個不同的系統組件：（i）MapReduce JobTracker（“Hadoop-JT”），（ii）MapReduce TaskTracker（“Hadoop-TT”），（iii）HDFS NameNode（“Hadoop-NN”），（iv）HDFS DataNode(“Hadoop-DN”)。
在Java虛擬機（JVM）上運行的Hadoop使用最大數量的85個不同的系統調用；然而，同樣基於Java的ZooKeeper只使用28個，而基於C/C++的Redis和GraphChi分別使用19個和20個不同的系統調用。這表明操作系統功能的使用範圍主要並不取決於編譯器或運行時，而是以數據爲中心的應用程序的固有屬性。如果只考慮通常調用的系統調用，則系統調用數量將進一步收縮，所謂常用系統調用要麼(i)佔所有調用數量的1%以上，要麼(ii)在每個應用程序級請求(即“數據平面”)上至少發生一次。實際上，除了Hadoop之外，所有應用程序都有五個或更少的“公共”系統調用（圖2.8a）。
在圖2.8b中，我按類別對系統調用進行分組。可能毫不奇怪，主要的類別是I/O、同步和資源管理，其中I/O系統調用占主導地位，正如我們在分佈式、數據密集型應用程序中所期望的那樣。
圖2.8c顯示了每個系統調用的相對頻率，它們佔總調用的1%以上。系統調用調用總數的35-50%是read（2）或write（2）；接下來最頻繁的調用是與Linux的futex（“fast user-space mutex”）同步機制相關的那些。總而言之，總共有11個系統調用覆蓋了所進行的調用的99%。這是326個Linux系統調用的一個小子集，表明在這些數據中心應用程序的“數據平面”上不需要Linux系統調用API的全量。
觀察：雖然這些結果暗示許多數據中心應用程序只使用一小組本地操作系統抽象，但是應該謹慎。Linux中提供的許多額外系統調用僅用於向後兼容，很少使用，而其他系統調用可能僅用於很少觸發的代碼路徑（例如，用於錯誤處理），甚至像ioctl(2)和fnctl(2)這樣的其他系統調用都具有高度過載的語義。我的理解是，像ioctl(2)這樣的系統調用可以被很多種設備實現，同時每種設備還有不同的請求命令，看上去都是相同的系統調用，背後的意義卻大不相同。
然而，這些結果是令人鼓舞的：他們建議構建一個新的分佈式數據中心操作系統是可行的，其抽象足以支撐通用的分佈式應用程序。這具有雙重優點：(i) 評估建立在新抽象之上乾淨的“數據平面” 的性能變成可能，(ii)撤銷對遺留操作系統設施的訪問，防止潛在的安全漏洞和旁路 (例如，通過pipe(2))。
總結
在本節中，我解釋了操作系統的發展是如何通過共享底層硬件來尋求更高資源利用率的。我調查了二十世紀八十年代的經典分佈式操作系統，它們沒有得到採用，可能是因爲它們的設計超前當時的工作負載。
然後，我發現現代數據中心事實上已經由當今使用的多個分佈式基礎設施系統組成了分佈式操作系統。然而，這種方法有幾個缺點，並且面臨效率和安全挑戰：
- 我發現分佈式基礎設施系統缺乏經典分佈式操作系統的統一抽象。
- 因此，數據中心操作系統的效率總體上受到損害：數據跨系統表示必須複製和轉換、共享需要副本，並且系統利用新的硬件範例並不容易。
- 缺乏單個訪問控制方案降低了數據中心操作系統的端到端安全性：系統有自己的身份驗證概念，使用可變粒度的訪問控制原語，並且通常不可能進行選擇性委託。
因此，在數據中心OS上下文中考慮來自經典分佈式操作系統的想法似乎很有用。的確，我藉助於一項探索性的研究論證，數據中心應用的狹隘和統一的需求使得設計一套新的分佈式操作系統抽象是可行的，它完全支持這種應用的“數據平面”（2.2.4）。
在下一節中，我將研究數據中心OS的特定部分：集羣管理器的調度器，它決定將兩個應用程序任務放在共享集羣基礎結構中的何處。