仓库规模操作系统的背景之仓库规模计算机

最新推荐文章于 2024-02-16 20:28:04 发布

进德

最新推荐文章于 2024-02-16 20:28:04 发布

阅读量1.6w

点赞数

分类专栏：分布式系统文章标签：分布式操作系统

分布式系统专栏收录该内容

12 篇文章 1 订阅

订阅专栏

前言

本文是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倍。