目录
前言
本文是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的扩展的原型实现。