总算又往下读了一部分。Google的Borg论文中，前面部分讲的都是Borg的架构。后面有讲了一些资源隔离，安全隔离等的技术方案和策略。
主机层面的资源隔离，都是由是Borglet来操纵的。
Google的混部情况：
Google几乎所有的机器都是混部的，在一台机器上，可能运行着不同jobs的tasks。根据论文中所说，Google的50%的机器运行了9个甚至更多的tasks。90%的机器运行着25个tasks，达到4500个线程。
因此，Google有完善的隔离技术来保证task之间不相互影响。目前，Google使用的隔离技术是Chroot和Cgroup。Cgroup本来就是Google最先提交到内核社区的，应该就是为了解决Borg的隔离。
对于外部的软件，比如GAE和GCE，Google的做法是让它们运行在虚拟机（KVM）上，KVM进程被作为Borg的task运行。也就是说，Borg是作为下层的，KVM运行在它之上。
资源共享的问题：
资源共享带来的问题主要就是两个，一个是安全，一个是资源之间的性能影响。
安全方面：
系统采用了Chroot隔离了文件系统。对于程序的调试，全都通过Borg来操作，Borg会让用户的命令在和被操作的tasks同一个容器下的shell中运行。
性能影响：
对于性能的影响，Google使用了很多技术来减少影响，这个是文章后面详细讲的。这里主要讲的是Google对任务混部对CPU性能影响的研究。
Google为了评估不同任务部署到同一个机器的CPU干扰影响做了一个实验。他们使用CPI（每条计算机指令执行所需的时钟周期）来衡量性能干扰。当CPI增加一倍，CPU密集型程序运行时间就会增加一倍，对应于即时相应的程序，可能就是延时增加了一倍。
实验发现，CPI和2个相同时间间隔的测量成正相关：机器的整体CPU使用率，以及运行在机器上的tasks。
- 添加一个task到一台机器上，会增加别的任务0.3%的CPI（使用线性模拟合数据）。
- 增加10%的CPU利用率会增加2%的CPI。
这是CPU密集型的程序测量的结果，事实上干扰存在于各种资源。
相对而言，专用的cells的CPI要低于混用的cells。据Google的统计，共享cells的CPI平均值为1.58（σ = 0.35）。在专用cells中，CPI平均值为1.53（σ = 0.32），CPU性能在共享cells中有大约下降3%。
但这也表明，使用共享的cells并没有大幅度增加程序运行的成本，而在机器需求方面，共享的cells更节约机器。另外。共享的优势适用于所有资源，包括内存和磁盘，而不仅仅是CPU。当然，Google还是有些特别的服务是放在专用的cell上的。
Google也对cell的大小进行了评估，发现cell越大越节约机器。
任务分类:
Google对jobs是分类为prod和non-prod的。prod指的是面向应用这类jobs，non-prod指的是批处理这类jobs。对于主机上的tasks，则是分为延迟敏感型（latency-sensitive）和批处理（rest）。因为non-prod的jobs中的master应该也是延迟敏感的，所以需要在task上进行分类。
个人理解：non-prod和prod是在BorgMaster调度时看的，是一个全局的维度。而latency-sensitive和rest是Borglet在主机的task层面上看的，是一个资源分配的维度。
另外，Borg中，主机的资源其实是超卖的（不然怎么节约资源），包括可压缩和不可压缩的资源。因此，可能会出现所有tasks都没有超过限制值，而主机资源不足的情况。此时，就需要根据task的分类来进行取舍。
延迟敏感型（latency-sensitive）：
未作特殊说明，下面采用缩写LS tasks来表示延迟敏感型的任务。
LS tasks用于面向用户的应用，以及共享设施服务，它需要快速响应请求。高优先的LS tasks享受最好的待遇。能暂时让批处理饥饿几秒钟。
批处理（rest）：
用于离线计算的进程，用于利用那些再生资源。基本是说被kill就被kill。
资源分类：
混部的一大问题是某个资源不足的情形。但是，不同的资源有不同的特点，有的资源能快速调整，而有的则需要很大的代价来调整。因此，Borg将资源分为两大类：可压缩资源（compressible resources）和不可压缩资源（non-compressible resources）。
可压缩资源（compressible resources）
这种资源指的是CPU，磁盘IO这类资源。它们是基于比例的，可以通过降低服务质量来调整资源分配，这种调整消耗的代价极少，几乎可以忽略。
可用的方案：
- CPU：Cgroup中的cpu子系统，可以限流CPU执行周期，也可以调整调度权重。
- IO：Cgroup中的disk子系统，可以在块设备层面限流IOPS和流量。也能在更底层的IO调度层调整权重（权重调整只支持CFQ，但是注意CFQ并不适合SSD）。
对LS tasks的优待：LS tasks可以保留完整的CPU核心，阻止其它LS tasks使用它们。批处理tasks可以运行在任何CPU核心下，但它被给予相对于LS tasks很小的调度份额。Borglet动态调整LS tasks的资源限制，为了确保它不会把批处理tasks饿死几分钟，在需要的时候，选择性的应用CFS控制带宽。
CFS改进：Cgroup中，CPU子系统是依赖于CFS调度算法，这是目前Linux的默认任务调度算法。Google为了减少调度延时和高利用率，调优了CFS调度程序。另外，Google的程序多采用多线程模型，这能减轻持续负载失衡的影响。
- 允许对LS tasks抢占批处理的tasks。
- 在多个对LS tasks在一个CPU下运行时，减少调度量。
主机资源超配:如果机器用尽了可压缩资源，Borglet会对某些task进行限流处理（给对LS tasks足够的资源）。这样，短负载峰值就可以被处理，而不需要kill掉任何tasks。如果情况没有改善，Borgmaster会从这台机器上迁移掉一些tasks。
不可压缩资源（non-compressible resources）
这种资源的典型代表就是内存，还有就是磁盘容量。此类资源的调整是很难的，比如内存，在内存不足的时候，Linux会进行内存回收，该刷盘的刷盘，写swap的写swap。如果这还不行，就会进入OOM-KILL流程。这个代价是很大的。
因此，如果不可压缩资源不足，就只能kill掉进程来回收资源，Google也是这么干的（操作系统也只能这么做）。
可用的方案：
- 内存：Cgroup的memory子系统可以支持限制内存使用。Cgroup内的内存有自己的LRU链，所以Cgroup内部也会自动换页。此外，在Cgroup内的内存用尽之时，也会触发Cgroup内的OOM-KILL流程。另外，系统自身的OOM-KILL级别是高于Cgroup的。
- 磁盘：这块不清楚Google是怎么做的，Cgroup也没有支持这个。有的软件是quota磁盘限额，可以限定文件夹内使用磁盘空间的大小，超过了就禁止写入。最早听说这是间隔扫描的方式，觉得不靠谱，现在应该改进成用inotify了。
主机资源超配：当不可压缩资源不足时，Borglet会从优先级最低的task开始kill，直到资源足够。
资源分配：
细粒度资源请求：
Google的资源分配是由用户申请的，用户可以指定各种资源的所需大小。而不是类似售卖虚拟那样有固定的规格。
Google对此做过实验，使用固定规格容器，根据CPU核心和内存两个维度的限制，四舍五入到下一个大于等于资源需求的规格。最小规格为0.5个CPU核心，1G内存。实验的结论是,这么做会增加30%-50%的资源开销。而且这还是在cell被压实之前的，压实后cell的资源开销更低。此外，cell还能支持CPU和内存的独立伸缩。
资源分配方法：
每个tasks和资源有3个相关的数据。分别是：申请值，估值，使用值。
- 申请值：也就是限制值，申请资源时，用户填写的值。
- 估值：Borg对程序使用资源量的估计，也被称为预定（reservation）。一般是使用值加上一定保护缓冲区。
- 使用值：当前task使用的资源值，是采集的数据。
估值是为了能回收利用那些没被用到的资源。每过几秒，BorgMaster会进行一次计算。
最初的估值会等于申请值，300秒之后，允许启动瞬变（startup transients），它会缓慢的向实际使用加上安全边缘靠拢。如果使用量超过了估值，估值会迅速增加。
Borg调度者使用申请值（限制值）来计划prod tasks（分配时按照限制来算），因此它们从不依靠再生资源，也不会超额分配资源。对于non-prod tasks，它使用现有tasks的预定，所以新的任务能调度到再生资源（分配时按照现有估值来算）。
资源超限制值：
Tasks允许使用资源量通常在限制值内。但只要主机资源足够，就可以使用超出限制值的资源。当然，这会增加tasks被Kill掉的可能性。当BorgMaster分配任务时发现资源不足时，它会优先回收超过限制值的tasks的资源。
大多数tasks允许使用可压缩资源超过限制值。比如CPU，Borg以此来利用未被利用的(松弛)资源。在Google中，只有5%的LS task禁止使用资源超过限制值，大概是为了获得更好的可预测性。只有少于1%的批处理tasks这么做（禁止资源使用超过限制值）。
使用内存超过限制值默认是被禁止的，因为这增加了task被kill掉的机会。但即使如此，10%的LS tasks重写了这个（允许内存使用超过限制值）。79%的批处理任务这么做，因为这是MapReduce框架的默认设置。
总结：
总的来说，Google节约资源其实就是在合理的情况下，对资源进行了超分配。因为很多任务其实并不是任何时刻都会用很多资源的。
另外，Google对任务和资源进行了分类。总体上，以高优先的LS task为核心，批处理任务以一个填坑的角色来吃掉剩余的资源。尽可能不kill掉tasks，万不得已情况下先拿低优先级开刀。
这确实是个很成熟的资源隔离方案，值得借鉴。
转载请注明：云计算技术手札 » 谷歌Borg论文阅读笔记（二）——任务混部的解决