目錄
前言
本文是Malte Schwarzkopf的博士論文《Operating system support for warehouse-scale computing》第三章的一個翻譯版本，融入了作者自身的經驗和理解，讀者如果想閱讀原文，可以訪問：http://people.csail.mit.edu/malte/pub/dissertations/phd-final.pdf
編寫本文的目的是提供一箇中文版本的文檔，同時爲自己保留一份學習筆記，供日後事件參考以及優化調整。當然，優化調整部分不能更新在公網，因爲筆者同一時間在公司內網發佈了改文章，相應部分只會更新在公司內網的文章中。
3.一個去中心化的數據中心操作系統模型
在前幾章中，我強調了數據中心操作系統需要更統一、更簡潔的基礎，取代作爲分佈式基礎設施系統的一部分而構建的點對點抽象。我認爲，這種替代方案有可能使關鍵基礎設施更加安全和高效。
在本章中，我介紹一個在去中心化的數據中心規模操作系統中進行資源命名和管理的參考模型。這個參考模型提供了一個DIOS原型的實現，我將在第4章討論這個原型。
3.1定義和概念
系統軟件研究通常依賴概念之間的類比，使它們相互關聯，並定位新的概念。例如，我對現有數據中心基礎設施系統（作爲數據中心的“操作系統”）的調查依賴於這些系統與經典操作系統相似功能的類比。
爲了明確我的數據中心操作系統模型而不產生歧義，我需要更加精確概念。因此，我假定下面列出的術語和定義。
人類用戶：直接或間接與數據中心操作系統交互的人類用戶分爲三類：
- 操作人員(operator)是核心系統開發人員或系統管理員，有權訪問集羣基礎設施，並控制數據中心操作系統應用的許可和訪問控制策略。集羣管理器開發人員也是操作人員。
- 數據中心操作系統的基礎設施用戶是在共享集羣基礎設施上部署應用程序工作負載的開發人員。基礎設施用戶是訪問控制和安全機制的主體。
- 最後，最終用戶是由數據中心應用程序工作負載支持的應用程序或Web服務的用戶。最終用戶可以將數據存儲在數據中心，並通過應用程序API與其進行交互，但他們不能直接訪問基礎設施，也不能部署自己的應用程序。
系統軟件：基礎設施用戶與之交互的、由操作員提供的系統軟件的關鍵部分是：
- 數據中心操作系統（OS），是支持基礎設施用戶應用程序所需的一整套特權代碼、系統服務、運行時和庫。最重要的是，操作系統包含了通常不是由基礎設施用戶提供的所有此類軟件，而且這些軟件在整個數據中心都是普遍可用的。
- 可信計算基（Trusted computing base, TCB）由操作系統中由維護其安全最重要的部分組成，這些部分的損壞可能危及訪問控制。TCB由所有機器的本地操作系統內核和羣集管理軟件組成，但不包括其他基礎設施服務（如分佈式存儲系統）。
- 本地操作系統內核（kernel）是在每臺計算機上運行的特權代碼，用於在其硬件上初始化、管理和執行特權操作。它可以訪問任何物理內存，啓動和終止本地程序。內核是TCB的一部分，此處損壞會導致繞過（至少）本地數據的訪問控制。
- 集羣管理器不在內核內部運行，但仍然是TCB的一部分，因爲它啓動和停止集羣基礎設施中的應用程序任務，爲它們提供輸入和輸出，並將它們與其他任務隔離開來。集羣管理器的一個或多個實例在數據中心內運行，由操作員部署和配置，並處理基礎設施用戶部署應用程序的請求。
信息隱藏：當系統設計者構思抽象時，他們面臨信息暴露和隱藏之間的選擇。不同方法的特點如下：
- 如果抽象或操作對用戶來說是完全不可見的，例如，基礎結構用戶不需要知道正在發生的事情以及如何實現它的細節，並且確實沒有辦法發現，那麼它是透明的(transparent)。
- 相反的方法是不透明的(opaque)：如果抽象或操作不向基礎結構用戶隱藏任何底層細節，甚至要求明確的指定它們，那麼它是不透明的。
- 半透明的（translucent）方法採取了中間立場，默認情況下實現細節對基礎設施用戶隱藏，但允許內省。換句話說，半透明的抽象或操作可以被視爲透明的還是不透明的就看基礎設施用戶的選擇。
當我第一次介紹我的模型時，我定義了其他特定於我的模型的術語和概念。
3.2要求
我對現有數據中心操作系統軟件的調查揭示了現有系統難以解決的兩個挑戰：
- 在不同任務、分佈式基礎設施系統和應用程序之間高效地共享資源。我發現數據被不必要地複製，即使系統共享數據，關鍵信息也經常被隱藏。
- 缺少細粒度的保護和訪問控制，現有的機制是粗糙的、分散的，並作爲分佈式基礎設施系統的一部分實現，每個系統都發明瞭自己定製的保護概念。這使得安全地授權資源訪問變得困難。
在下面，我將這些挑戰細化爲一組去中心的數據中心操作系統模型的目標和需求。
3.2.1效率要求
爲了使去中心的數據中心操作系統儘可能高效，該模型必須滿足兩個高級目標：
- 它必須提供統一的抽象，應用程序可以建立在這些抽象之上，省去不必要地轉換數據或資源表示。
- 它必須爲應用程序的高效實現公開足夠的信息，並避免可能高昂代價的抽象。
換句話說，我們需要一個高效且富有表現力，並且大部分應用程序的最小化的共同點，滿足三個要求。
- 模型及其抽象必須是可伸縮的，這樣操作系統就可以跨多臺機器運行，併爲大量應用程序提供服務。例如，資源的不同副本應該可以同時訪問，而不需要同步。
- 抽象在應用程序中應該是統一的，並且易於理解。例如，由於資源的位置可能事先不知道，因此訪問本地和遠程資源的抽象應該是相同的。
- 抽象應該是內省的，允許應用程序獲取操作所需的有效信息。例如，對遠程資源的抽象應該公開它是遠程的這一事實，但是訪問不應該需要實現通信協議。
由於數據中心機器和網絡都可能發生故障，所以我的模型是去中心化的：在操作系統抽象的層次上，它是一個完全分佈式的體系結構。操作系統本身不能依賴單一的集中狀態，必須允許狀態的複製，這有助於擴展性和容錯性。具體來說，系統中存儲的所有數據都必須是可複製的，並且不需要中央機構來維護元數據或權限。
注意，這並不意味着在操作系統抽象之上構建的所有應用程序或基礎設施系統必須完全去中心的。事實上，這個模型之上的大多數基礎設施系統仍然可能使用中心控制器；但是，操作系統抽象本身不需要任何集中控制或依賴於單一故障點。
數據中心操作系統抽象和接口的可伸縮性可以從單機多核架構的操作系統開發的可伸縮原則中獲得：與可伸縮的多線程程序一樣，可伸縮的分佈式系統必須利用異步和無協調共享，並避免全局原子操作。在可能的情況下，操作系統抽象應該鼓勵參考其他類似系統的實現。
更通俗的說，由於分佈式系統中的同步代價高昂，因此模型必須避免隱式同步，例如基礎設施用戶可能不知道的同步。數據中心操作系統應告知應用程序併發訪問，但不應阻止應用程序默認或自行執行同步或互斥。然而，基礎設施系統和應用程序可以在操作系統公開的併發訪問通知（可以理解爲回調）之上構建同步抽象。
分佈式系統通常使用透明性來隱藏實現細節——例如，遠程過程調用（RPC）概念、Mach的利用端口基於消息的透明對象訪問，或者Dryad和CIEL中的自動依賴跟蹤。然而，完全透明因爲不可能內省具有潛在不可預測性能的缺點。例如，分佈式共享內存系統（如Mungi）和透明分佈式對象消息系統（如Mach和MIKE）中的每個操作都可能需要與遠程機器通信而帶來高延遲，但應用程序無法提前檢測到是否需要這樣做。
半透明可以在不限制應用程序內省自由的情況下提供簡單的透明性：抽象在默認情況下是透明的，但在請求時是不透明的。不需要對細節進行內省要就避免瞭解分佈式系統的底層操作細節。因此，我的模型中的操作系統抽象應該是半透明的，但也包含上下文元數據，這些元數據公開了有關資源的詳細信息以進行內省。應用程序可以選擇忽略此信息（放棄可預測的性能）或使用它來優化（例如選擇更接近的副本）。
3.2.2安全要求
如第2.2.3，當前分佈式基礎基礎設施系統的安全性有還有很大的改善空間：它是分散的、有選擇地強制執行的並且通常不夠精細。我的去中心化數據中心操作系統模型旨在改進這一點。接下來，我回顧所考慮的威脅模型以及該模型必須支持的安全主體。
目標：數據中心操作系統必須確保屬於不同作業、用戶、甚至商業實體的工作負載可以安全地共享羣集基礎結構。爲此，它必須確保三個屬性：
- 隔離基礎設施用戶、任務，以及他們的數據和資源，除非明確共享。
- 不可訪問的資源對於基礎設施用戶或任務是不可見的
- 數據或資源的共享或者通信以及訪問都是被審計的；
與傳統操作系統不同，隔離和共享還必須跨機器。例如，特定終端用戶電子郵件的存在可能僅對服務可見，授權的分析作業可以使用這些郵件。並且，分析作業中的任務可能需要將工作委託給助手任務（例如解壓縮例程或病毒掃描程序）而不泄漏敏感數據到外部，事實上他應該記錄在審計日誌中。
3.2.2.1定義
在我的模型中的安全主體和資源定義如下：
- 主體：是基礎設施用戶或非人類服務帳戶
- 對象（資源）：是易失性或持久性數據、硬件資源、任務、和其他操作系統級別的抽象（例如IPC endpoint，定時器）。
正如我在3.1節中已經提到的，可信計算基（TCB）——可以訪問任何對象，它爲主體提供權限——包含本地機器內核和集羣管理器。另外，我在3.4中討論的標識符解析機制，也是TCB的一部分。
3.2.2.2威脅模型
我的模型旨在保護數據中心基礎設施及其用戶免受兩種原因造成的威脅：蓄意的預謀和意外的錯誤。更具體地說，我的模型試圖解決四個威脅：
內部惡意發生在當惡意或破壞的主體試圖獲得對其不可見的資源訪問時。例如，惡意基礎設施用戶可能會運行一個特製的MapReduce作業，將其輸入泄漏給第三方。我的模型的目標是劃分資源以限制基礎設施用戶的權限，只能訪問他們的作業需要和合法訪問的資源，最大限度地減少暴露。這需要比當前系統提供的更細粒度的訪問控制。
外部危害通常放生在當外部方通過利用和冒充現有的主體獲得未經授權的訪問權限時。如果攻破一個有效的主體，這個威脅變得與內部惡意相同。例如，惡意最終用戶可能會利用解壓縮程序中的漏洞來獲取對基礎設施的訪問權限顛覆調用壓縮程序任務的身份。我的模型的目標是通過限制分佈式應用程序可訪問的抽象來降低這種危害的可能性。如果危害真的發生，儘可能遏制他。
由於bug或者配置錯誤的權限，私有資源遭到意外暴露。例如，分佈式文件系統的最終用戶可能沒有足夠的限制，允許錯誤的分析作業暴露的數據多於預期。我的模型的目標是通過限制任務對所需最少資源的訪問來減少這種情況下的暴露。
硬件故障通常在沒有惡意傾向的情況下發生，但會導致資源突然不可用，可能導致安全或可用性影響的。例如，一個網絡故障造成幾個獨立的分區，使得身份驗證服務器暫時無法訪問。我模型的目標是支持即使在故障情況下仍然安全且可用的訪問控制，只要目標資源仍然可用。
然而，有一些類型的威脅超出了我的工作範圍，必須使用其他機制：
如果惡意主體或外部攻擊者成功利用操作系統內核、名字服務或集羣管理器中的漏洞可能發生TCB危害。加密內存包(Encrypted memory enclaves，一部分物理內存是爲enclaves預留的)可能有助於減少應用程序暴露於此類攻擊。
硬件和物理訪問漏洞可以繞過訪問控制並可能暴露私有信息。操作系統在沒有端到端加密和硬件支持的情況下很難抵禦這種威脅。
信息流控制（IFC）涉及對信息能否在不同主體之間（包括間接）傳遞的策略的實施。雖然我的模型限制了信息的意外暴露，並通過細粒度訪問控制減少了攻擊面，但需要使用諸如污點跟蹤（如在Histar和DStar中）等IFC技術來實施此類策略。
3.2.3其他要求
去中心化數據中心操作系統模型必須滿足幾個額外要求，但這與效率或安全性沒有直接關係。
分佈式應用程序很複雜，許多策略的決定都是特定於應用程序的。一個數據中心操作系統必須平衡特定機制以保持靈活地支持應用程序指定的外部策略。要做到這一點，必須暴露給應用程序足夠的信息以制定他們選擇的通用的分佈式系統策略 。例如，在哪裏定位數據或者是否保持強一致的副本。
增量採用。即使新的數據中心操作系統模型具有許多優勢，軟件適配也是非常耗時的。因此，隨着使用新範式的數據中心工作負載越來越大，逐步採用必須是可行的，與此同時傳統應用程序還要繼續工作。雖然最初模型的所有優勢並非都可實現，但增量遷移可以提高效率和安全性。
接下來，我將解釋分佈式對象抽象如何幫助我的模型滿足這些以及之前的提到要求。
3.3分佈式對象
對象是一種方便的抽象通常用於編程和結構化數據存儲兩個方向。它們最小的共同點可能是：對象是一個相關、結構化狀態的集合。對象以原子方式創建和銷燬，並且通常具有唯一的身份標識。
對象抽象對於分佈式系統有幾個優點：
- 對象將結構強加於其他非結構化數據，併爲更新一致性劃定範圍。例如，亞馬遜的Dynamo鍵值存儲包含可以分開的版本化對象，而谷歌的BigTable存儲保證行內對象一致的更新，跨行對象不保證。
- 對象級複製可實現容錯：作爲一個獨立的、可複製的實體，對象封裝了所有狀態。例如，像Cassandra這樣的分佈式key-value存儲將鍵和值實現跨域複製，以實現高可靠。數據處理系統的對象抽象（例如spark彈性分佈式數據集(RDD)和CIEL的數據對象）基於副本和確定性重放(REDO日誌)提供容錯能力。
- 對象簡化了分佈式編程，因爲它們適合於actor模型通信，其中actor保持私有狀態並交換消息從而影響狀態變化。Sapphire可以通過透明地交互對象與模塊化“部署管理器”相結合，簡潔地表達複雜的分佈式系統。
- 對象之間的依賴可以使用數據流計算模型(data-flow computation model)，這會讓他們自動的並行化。例如，Dryad和Naiad基於狀態頂點之間記錄的數據流，而CIEL根據動態生成任務對輸入對象的依賴性調度他們。
這些，結合了完全分佈式體系結構的要求和對應用程序級可擴展策略的支持，使得分佈式對象模型非常適合數據中心操作系統。
我的模型圍繞兩個獨立的對象概念：
- 邏輯對象擁有全局唯一標識符命名，但可以有多個副本的實例給應用程序使用。
- 相反，物理對象是具有明確位置的單個特定對象實例，應用程序可以執行操作或I / O這個對象。每個物理對象都是一個邏輯對象的一部分。
否則，分佈式對象模型就要基於一些人爲的定義和假設：
- 每個邏輯對象都有一個全局唯一的標識符；
- 邏輯對象的副本實例（對應的物理對象）可以互換使用，並帶有相同的全局唯一標識符；
- 每個邏輯對象都有一個類型，可以是blob（字節序列）、endpoint、task或者group，物理對象就是對應類型的實體；
- 物理對象的創建和刪除是原子的，但是更新沒有必要是原子的；
- 物理對象的句柄公開元數據供應用程序察看；
具體來說，我的模型（不同於許多經典分佈式操作系統（2.2.1章節）的對象概念）不做：
- 假設集成任何語言級別的對象概念。
- 對物理對象的結構施加要求，例如，以特殊的方式存儲其他邏輯或物理對象的引用，或者耦合代碼和數據。
- 強制物理對象執行特定的一致性級別（≡副本數）。
- 出現故障時保證物理對象的持續可用。
對象的概念對於數據中心操作系統來說是實用的，因爲它對數據中心做出了關於應用實現的最小的假設。
圖3.1：去中心的數據中心操作系統模型的示意圖。三個任務對象T0-T2顯示爲圓圈;四個物理blob對象顯示爲文檔;兩個對象流通信顯示爲管道。陰影部分是TCB的一部分。實線箭頭表示數據流，點虛線箭頭表示對象創建，虛線箭頭表示持久化。
圖3.1，利用四個任務對象（T0-T3）、共享blob（o0-o3）、通過單向管道（o4-o5）進行通信的例子展示了對象概念。接下來，我將用我的對象模型表達兩個典型的數據中心應用程序。
例子：1)一個分佈式MapReduce實現，代表典型的確定性數據流應用；2)一個事件驅動的、帶有內存key-value後端存儲的HTTP服務，這是面向最終用戶的經典服務應用。
圖3.2：分佈式MapReduce（五個map任務，三個reduce任務）：一個確定性的數據流批量計算。在這個例子中，有五個邏輯輸入對象（“splits”） i0-i4，通過物理中間對象mi,o，轉換爲3個邏輯輸出對象o0-o2。中間和輸出對象由MapReduce控制器任務創建，也是通過集羣管理器生成任務。
在MapReduce框架中(圖3.2)，第i個map任務(Mi)在輸入對象(ii)上執行映射函數map(key, value)→ {<key2, value2>}。所有的map任務是並行執行的。隨後在key2上對每個結果列表中的項進行散列分區，以及得到的中間鍵值對數據集（存儲在中間物理對象mi,j中）作爲並行的reduce任務（Rj處理所有的mk,j）的輸入。這些任務執行reduce函數，reduce(key2, {values})→ {out-values},把最終排序的值輸出到對象oj中。控制器管理map和reduce任務並且監控他們，如果任務故障還要重新執行，實現容錯。
圖3.3：後端多進程HTTP服務器：面向用戶的服務通過三個前端工作任務（w0–w2）實現，這些工作任務共享一個提供物理客戶端連接對象（cs0–cs2）的物理接收器（acc）。他們的響應由靜態數據（di）和通過物理流對象（bs0-bs2）與三個後端任務（B0–B2）通信獲得的動態數據（bdi）（例如，來自鍵值存儲）組成。
相比之下，HTTP服務器（圖3.3）是一個非確定性的、事件驅動的應用程序。該設計類似於廣泛使用的nginx web服務器中的事件驅動的“reactor pattern”：多個工作任務（Wi）都輪詢TCP接收器對象（acc）以接受客戶端連接。客戶端連接即爲TCP流對象（csj），工作進程在該對象執行I/O操作。在後端，工作進程既可以與以blob對象（在內存或磁盤上）形式存在的靜態內容進行交互，也可以通過引用流對象（bsi）與後端任務（Bi）基於共享內存或者網絡通信獲取key-value存儲的動態內容交互。集羣管理器通過重新啓動任何失敗的工作任務實現容錯。
3.4資源命名
去中心的數據中心操作系統模型中的每個資源都由一個邏輯對象表示。這個邏輯對象必須命名，因此我的模型爲它分配了一個全局唯一的標識符。需要唯一標識符有兩個原因：
- 操作系統本身必須具有明確引用特定邏輯對象的方式。
- 應用程序必須具有邏輯對象的標識符，以便引導它們對邏輯對象的訪問，並記錄和表明它們的存在。
關於資源唯一標識符與對象的關係可以類比爲面向對象編程中的實例(邏輯對象)和指針(唯一標識符)的關係，指針既可以引用對象同時方便傳遞，唯一標識符也是這個目的（譯者注）。
爲了與前一節中我的模型的邏輯對象概念的定義保持一致，標識符引用了邏輯對象的所有物理對象，從應用程序的角度來看，這些物理對象必須是可互換的。
例如，考慮一個強一致性的分佈式key-value存儲，它需要副本寫入以實現容錯：其任務通過將value寫入多個物理對象，這些物理對象組合成表示value的邏輯對象。爲了適應分佈式數據中心操作系統模型的對象語義，key-value存儲在寫入之後必須保持物理對象的互換性。要實現這一點，必須確保所有物理對象都是原子更新的（通過應用程序級鎖或事務操作），或者更新的值存儲在新的邏輯對象中（使用新的標識符），並key-value存儲中的映射被原子更新以引用新的邏輯對象。。
值得注意的是，物理對象也有唯一的標識符，但這些標識符是短暫的：正如我在第3.5節中所解釋的，它們只在任務上下文中本地有效，不能持久存儲，並且只能部分暴露於應用程序。
屬性：然而，邏輯對象標識符暴露在應用程序中，可以被任意存儲和通信。因此，它們必須具有三個關鍵屬性：
- 爲了適合於持久性存儲和作爲純（二進制或文本）數據在網絡上進行通信，標識符必須是可序列化的。
- 爲了使它們在數據中心的任何地方都可用，並將它們與物理對象分離，標識符是位置無關的，不編碼資源的物理位置（與主機名：端口組合不同）。
- 爲了限制泄漏的影響，必須限制標識符到物理對象的轉換。因此，邏輯對象標識符有名稱空間：即使應用程序管理其來源，它們也只形成一個數據中心操作系統在命名空間內識別資源的能力。
生成：爲了滿足完全分佈式體系結構的需求，只需要利用本地信息就可以生成標識符。此外，出於安全目的，它們必須是不可僞造和不可預測的。在許多情況下，僅從大空間中選擇統一隨機的標識符就足以滿足這些需求，也可以生成一個可以存儲爲數據的明確的標識符。這與許多現有數據中心應用程序的用法非常匹配：例如，在許多Web應用程序中，引用照片和其他內容對象的URL中已經使用了不可僞造的標識符。
然而，許多數據中心應用程序（尤其是用於並行數據處理的應用程序）體現爲確定性計算。它們利用確定性來簡化編程模型，並支持基於重放(replay，可以理解爲重新執行)的容錯（例如在MapReduce、CIEL和Spark中）。確定性也有助於調度具有數據依賴性的計算，並實現記憶化(memoisation)優化（如CIEL和Tachyon）。因此，數據中心操作系統模型還支持使用散列函數確定地生成標識符，該散列函數結合了以前的標識符鏈來生成新的標識符。
關於memoisation維基百科的解釋是：在計算領域，memoization或memoization是一種優化技術，主要用於存儲“昂貴”函數調用的結果，並在相同的輸入再次發生時返回緩存的結果，從而加快計算機程序的速度。至於如何理解昂貴，暫且你就認爲非常消耗資源、非常耗時的計算就好了。
解析：存在邏輯對象標識符，以便將其轉換爲應用程序可以使用的可交換物理對象集。這種從獨立於位置的標識符到半透明地公開位置信息的物理對象的轉換稱爲解析，它是構成數據中心操作系統模型一部分的名字服務的責任。
此名字服務可以由操作系統本身實現，也可以委託給基礎設施應用程序，但這兩種方式都構成數據中心操作系統TCB的一部分。這是因爲名稱服務知道所有邏輯和物理對象，以及它們之間的映射。這對資源隔離、資源存在的可否認性和資源訪問的可審計性等安全目標至關重要（見第2.2.3.2節和第3.2.2節）。
資源標識符當提供給名字服務時形成名字解析的功能：邏輯對象標識符（例如能夠命名資源）授權任務獲取相應的物理對象集。重要的是，這種全局的、粗粒度的“標識符功能”可以被視爲數據（例如存儲和通信），因爲它們是通過加密生成的：擁有位模式（bit pattern）足以通過名稱服務授權標識符解析，而與獲得位模式的方式無關。標識符功能是原子的，也就是說，它不能被細分或細化（例如，只能細分爲物理對象的一個子集）。
但是，標識符功能有一個危險的安全缺陷：泄漏標識符使攻擊者能夠訪問物理對象。爲了防止這種攻擊，標識符是一個或多個名稱空間的一部分，並且只能在其中解析。命名空間和標識符的組合是拆分能力的一種形式：給定標識符並訪問映射它的命名空間，持有者可以發現相應的物理對象。然而，任何一部分本身都是無用的。
此限制僅授予對具有適當命名空間訪問權限的任務的訪問權限。命名空間本身被表示爲對象：它們可以被創建，具有標識符，並且可以在任務之間共享（儘管受到一些限制）。有沒有很熟悉，Kubernetets的namespace就是一種對象（譯者注）。
但是，即使標識符和命名空間本身也不足以在去中心的分佈式數據中心操作系統模型中完全實現基於能力的保護。這有兩個原因：第一，標識符是原子的，不表示細粒度權限（例如讀/寫訪問）；第二，它們沒有足夠的信息來形成半透明的抽象（根據效率要求，參見第3.2.1節）。實際上，單一能力不可能被應用程序管理、存儲、通信、可刪除和半透明，因爲這些屬性在某些情況下是互斥的（例如，任意持久存儲和半透明）。相反，我的模型支持另一種類型的能力，用作資源管理的特定於上下文的句柄，我將在下一節中對此進行描述。
相關方法：以前的幾個分佈式系統使用標識符作爲能力（capability）（見表3.1）。
表3.1：與去中心的數據中心操作系統模型相比，先前系統的分佈式能力方案。
在Eden中，“Ejects”認證能力，它是分佈式對象。Eden的能力與位置無關，但不能被視爲數據，因爲最初的設計是通過Intel iAPX 432中的“訪問描述符”依賴於硬件支持，它們被實現爲兩部分隔離能力，Eden內核保留使用所需的私有元數據。
Amoeba分佈式操作系統使用稀疏加密能力，完全由用戶空間服務器進程管理。因此，能力可以被視爲數據，並通過網絡進行交換。Amoeba的能力也是位置無關的，可以被提煉。然而，Amoeba依賴不可僞造的硬件源地址作爲網絡消息來保證安全。
許多現代Web應用程序使用密碼派生的URL作爲能力。共享這樣一個URL就相當於授權（複製）該能力，儘管接收者無法進一步提煉該能力。同樣，Web cookie和Macaroon也是有效的分佈式能力。所有這些能力都是位置無關的，可以作爲原始數據存儲和通信。
3.5資源管理
除了邏輯對象的標識符之外，模型還需要一個抽象來實現物理對象的安全句柄。這個句柄必須唯一地標識一個物理對象，攜帶足夠的信息以便等待任務與該對象交互（無論其位置在哪），並允許通過半透明元數據進行內省以提高效率。
句柄是資源管理操作（如共享、刪除）和物理對象數據I/O的目標。與標識符不同，它們攜帶權限和其他元數據（例如位置、持久性級別等）。某些元數據的值（例如位置）取決於觀察者。因此，句柄由特定任務擁有，它的元數據是針對擁有者任務和物理對象上下文的。
因此，句柄是短暫的，在擁有者任務生命週期內有效：它們不能持久存儲。對於最初未被引用的物理對象（例如，在持久存儲上），這意味着必須通過解析其標識符來創建句柄，因爲只有這些句柄可以作爲數據存儲。
爲了確保句柄只能由標識符解析生成，它們必須保證不可僞造性；也就是說，應用程序不可能通過合成假句柄來訪問物理對象。因此，句柄形成了本地的、上下文相關的句柄能力，這些能力不能被視爲數據，並且是TCB和應用程序之間的一種隔離能力。每個句柄都有一個嚮應用程序公開的公共部分，以及一個只有本地操作系統內核可以訪問的TCB私有對應部分。
授權：數據中心操作系統有時必須能夠生成能力的受限版本，例如刪除權限。與標識符不同，TCB可以提煉句柄能力。例如，當助手任務(helper task)只需要父任務可用權限的一個子集的限制訪問時，這很有用。這種能力的提煉是通過支持句柄授權的模型實現的。
授權通過TCB創建一個新的、可能更受限制的句柄副本。新句柄可能與原始句柄屬於同一個任務，也可能屬於不同的任務。TCB的職責是使句柄適應目標上下文，創建新句柄的內核和應用程序部分，並通知授權目標的上下文。
當句柄能力在多臺機器之間被授權時，它們必須通過數據中心互相連接。這要求跨計算機的授權能力不可僞造，這在分佈式系統中是非常重要的：
- 共享互連能力可能會被攔截，發生中間人攻擊：例如，一個受損的交換機可能通過模擬授權協議進一步將觀察到的能力副本授權給一個共謀主機（和受損交換機一起爲攻擊者）。
- 重放攻擊包括記錄和稍後重新使用某個能力，但可以通過確保授權句柄能力的新鮮性來防禦。
認證協議（如kerberos或needham-schroeder-lowe認證協議）通過對通信方進行身份驗證來解決此問題，但需要邏輯的、中心化的認證服務器來維護共享祕鑰（kerberos）或密鑰（needham-schroeder-lowe）。這種集中化將違反去中心的數據中心操作系統的完全分佈原則。
由於數據中心是由單一權威機構運營的，因此一些攻擊（如交換機固件的損壞）雖然可能，但可能性不大。此外，大多數數據中心運營商甚至對內部數據中心流量進行加密，這有助於防止窺探。在我的模型中，我認爲這樣的威脅超出了範圍，並假設一個沒有損壞的TCB和互連。然而，跨不受信任的商業互連的安全授權是未來工作的一個有趣領域。（見9.1.3章節）。
資源管理摘要：標識符和句柄能力一起強制執行訪問控制。在應用程序可以與邏輯對象交互之前，必須將標識符能力解析爲一個或多個本地、上下文敏感的句柄能力。雖然標識符能力指的是邏輯對象，但句柄能力有助於管理物理對象並影響對它的I/O。但是，句柄能力只在其任務上下文中有效，而標識符能力在任何可以訪問其命名空間的任務中都有效。
此拆分還控制能力的來源：在我的模型中，標識符能力的解析涉及命名空間，這限制了可以使用它們的任務集，但不限制它們的通信。相比之下，句柄能力只能通過TCB通過授權傳遞給其他任務，但可以進行提煉，並且可以授權給所有者任務可以命名的任何任務。。
相關方法：與標識符功能一樣，我對句柄能力的概念與之前幾個系統中的能力概念類似（表3.1）。
傳統的能力方案通常依靠機器硬件來保護它們的能力。例如，Cap Computer、iAPX432和CHERI使用自定義硬件或硬件擴展。相比之下，Mach、EROS、seL4和Barrelfish依靠內存保護硬件來隔離能力空間和數據空間。
Accent和Mach使用能力來控制對“端口”（IPC端點）的訪問，基於消息的IPC可以在這些端口之間進行通信。授予端口訪問權限並且與位置無關，但無法進行細化。Mach消息中端口能力的發送具有“移動”語義：發送者在授權能力時失去了對端口的訪問權限
Barrelfish操作系統使用基於分離的seL4能力的分佈式能力方案，該方案分層地提煉能力。當能力被共享時，它們必須被序列化並通過安全通道發送。由於Barrelfish沒有透明的對象抽象，因此能力不是位置無關的。
3.6永久存儲
數據中心存儲系統通常比當今複雜的分層文件系統（如ext4、ntfs或nfs）更像早期操作系統中的平面數據存儲。
Bigtable和Dynamo等存儲系統是分佈式key-value存儲，而FDS、Haystack和f4等存儲系統則是分佈式Blob存儲。雖然存在分層分佈式文件系統（如GFS、HDFS和TidyFS），但它們的功能比傳統文件系統受到的限制要大得多。例如，HDFS只支持在現有文件上追加寫入，而不支持隨機寫入訪問。如果需要，目錄服務通過元數據控制器實現，而實際數據存儲爲塊（例如，GFS和HDF中的64MB塊，FDS中的8MB“tracts”）。
因此，去中心的數據中心操作系統模型有機會簡化存儲子系統。簡化存儲棧可以使其不易出錯且易於擴展，如果抽象更適合數據中心存儲，還可以提高I/O性能。
因此，去中心的分佈式數據中心操作系統模型的存儲接口是最小的：唯一標識的對象存儲在持久對象存儲中。這種方法將分層（或其他）存儲抽象的實現放到更高級別的分佈式應用程序實現，而不是將它們分層到已經分層的基線存儲抽象之上。例如，Bigtable樣式的分佈式映射和GFS樣式的分佈式文件系統都可以在一個簡單的對象存儲之上實現。這兩個高級抽象的保護和訪問控制可以依賴於數據中心操作系統提供的統一功能抽象。
這種存儲抽象還允許輕鬆實現諸如緩存之類的常見優化。存儲中的邏輯對象可以使用多個物理對象副本，副本（物理對象）可能具有不同的持久性級別。例如，一些物理對象可以緩存在內存中，而其他對象則在持久性存儲中，最後，一些可能是內存映射的持久備份副本。物理對象各自句柄能力的半透明元數據公開了有關物理對象是否在持久存儲中的信息。
相關方法：對象存儲模型類似於Multics段模型，這是早期的操作系統存儲抽象。在Multics中，段被命名爲內存塊，可以由持久存儲或其他設備進行備份。Multics透明地提取段的實際存儲位置，並在不同位置之間自動、透明地移動段。相比之下，“半透明”句柄能力允許內省我的模型中物理對象的存儲位置。
許多後來的單地址空間操作系統，如Grasshopper、Opal和Mungi，也支持持久的段或對象。在Opal中，對象也被存放在一個無處不在的存儲中。最近，分佈式數據處理系統（如CIEL）和NAS系統採用了類似的以對象爲中心的存儲模型。
3.7併發訪問
許多數據中心應用程序都是I/O密集型的併發應用程序：它們與其他應用程序通信，處理來自網絡的大量流數據，或使用許多任務並行處理來自持久存儲的靜態數據。通常，不同的應用程序組合在一起，並且可以彼此共享數據。
因此，數據中心操作系統模型需要提供一種工作負載訪問遠程物理對象的方法，以及在任務之間共享物理對象的方法。根據物理對象和應用程序的一致性要求，某些併發訪問可能是可以接受的。由於應用程序級別的一致性保證在不同的系統中有很大的差異，所以我的模型不能規定特定的併發訪問語義，而是允許應用程序定義自己的策略。
因此，去中心的分佈式數據中心操作系統模型使用事務式I/O請求，這是一種靈活而低開銷的跟蹤併發訪問的方法，同時在事務完成時通知應用程序。I/O請求描述了從獲取I/O資源（即讀寫緩衝區）到完成預期操作（即讀取和處理數據，或將其寫入緩衝區）。I/O請求可以是讀請求，也可以是寫請求。
I/O請求從獲取請求開始：應用程序爲目標物理對象指定所需的操作和併發訪問語義。如果成功，則請求處於獲取階段，在此階段應用程序執行I/O。一旦應用程序完成其I/O，它將提交請求，並要求操作系統驗證併發訪問語義是否確實在其持續時間內保持不變。如果成功，將提交請求；否則，將中止請求。
I/O請求類似於優化併發事務（例如，在服務器場中）。但是，I/O請求不提供事務語義（例如ACID和保證的回滾）。每個I/O請求也特定於一個單獨的物理對象，即它不能提供多對象一致性語義，這必須由應用程序實現。
圖3.4說明了I/O請求是如何進行的，以及讀寫請求之間的數據流和控制流是如何不同的。
圖3.4：（a）讀和（b）寫請求的序列圖：調用方首先獲取（ACQ），然後提交（COMM）箭頭是從任務（T）到維護物理對象O的機器上的本地內核的調用，以及它們的返回。
讀取請求在獲取階段接收其數據，或者如果物理對象在當前狀態下無法滿足請求的併發訪問語義（例如，因爲其他任務上已經有未完成的I/O請求），則獲取失敗。在提交階段檢查數據讀取的有效性，如果在請求期間違反了所需的併發訪問語義，則可能會失敗。
寫請求在獲取時接收工作緩衝區。根據目標物理對象的類型，此緩衝區可能包含現有對象數據，也可能不包含現有對象數據。然後任務寫入緩衝區，提交階段指示請求期間是否保留併發訪問語義。
對於寫請求，提交失敗的影響取決於物理對象是否暴露緩衝區（例如使用共享內存對象）、影子副本（例如雙緩衝共享內存對象）或按順序追加寫操作（例如使用流）。使用按順序執行寫入或影子副本，很容易放棄更改。但是，對於暴露緩衝區，更改已經在提交點執行。在這種情況下，數據可能已被無效請求損壞，操作系統必須使訪問它的所有任務的物理對象無效，或者應用程序必須實現自己的恢復過程。
I/O請求是樂觀地併發的：換句話說，假設它們最終在潛在的退避和重新嘗試之後成功。每個請求沒有隱式操作系統級別的鎖，因爲它們需要“昂貴”且不可伸縮的分佈式鎖定協議。然而，I/O請求的獲取和提交點爲構建特定於應用程序和多對象的機制提供了“鉤子”。例如，可以在I/O請求上構建分佈式互斥鎖，讓它們競爭共享對象的獨佔訪問，並在成功時將值設置爲“鎖定”。
相關方法：與I/O請求類似的機制存在於以前的分佈式系統中，儘管它們通常具有更強的事務語義。例如，Locus分佈式操作系統具有網絡透明性，並且支持副本文件上的嵌套事務。
Clouds OS支持基於每個線程和每個對象一致性級別的事務語義的“原子操作”。線程經歷不同一致性語義階段的概念與我描述的I/O請求概念類似，但與I/O請求不同，它假定了特定的線程模型和對象級一致性標籤。
分佈式共享內存（DSM）系統通常具有相似的語義。例如，Munin基於Release consistency（允許對象的臨時不一致性），並且，像I/O請求一樣，可以表示多個一致性級別。我的I/O請求系統可以進一步擴展，使用類似於Munin使用的標誌。
最後，軟件事務性內存（STM）爲內存訪問強制執行事務性語義，通常以簡化併發編程爲目標。I/O請求比STM粒度更粗，不具有事務語義，待在內存和持久對象中操作相同。
3.8總結
本章介紹了去中心的分佈式數據中心操作系統模型，這是一個統一、高效和安全的數據中心資源命名和管理的全新參考模型。
在定義了關鍵術語和概念（§3.1）之後，我將在第2.2.3節中觀察到的當前基礎設施系統的缺點提煉爲我的模型（§3.2）的一組要求。
然後，我解釋了模型對分佈式對象的核心抽象（第3.3節）如何表示分佈式應用程序，以及資源命名（第3.4節）和管理（第3.5節）如何通過分佈式能力實現。
我的模型通過使其資源句柄半透明來實現效率：應用程序可以對物理對象的句柄進行內省，以便在對應於同一邏輯對象的不同可互換物理對象之間進行選擇。這樣的選擇可以實現透明分佈式系統中不可能實現的性能優化。
此外，該模型實現了基於統一、無處不在的基於能力的安全和訪問控制，滿足了隔離、可否認和可審計三個目標：
- 能力的不可僞造性確保了隔離：標識符能力是不可僞造的，因爲它們是隨機的或基於加密散列，句柄能力是不可僞造的，因爲它們是分離的（即有一個內核對應部分）。由於標識符能力具有命名空間，並且只能通過TCB授權句柄能力，因此如果確實發生泄漏，則泄漏是可以控制的。
- 必須解析標識符能力授予資源存在的可否認性：在解析標識符能力時，名字服務可以拒絕承認與邏輯對象標識符對應的物理對象的存在，這與實際不存在物理對象的情況是難以分辨的。
- 因爲TCB解析標識符能力並創建所有句柄能力保證了可審計性。在解析標識符能力時，名字服務可以記錄操作，並且句柄能力的授權也必須同樣通過TCB並可以被記錄。
最後，我解釋了對象如何持久地存儲在對象存儲中（第3.6章節），以及我的模型如何使用優化的併發事務（如I/O請求）靈活地表示對對象的I/O併發訪問（第3.7章節）。
在下一章中，我將介紹DIOS，我的模型作爲Linux的擴展的原型實現。