分布式资源管理和调理架构

概述

不管是盘算任务还是数据存储都会涉及资源分配，资源包括但不限于硬件资源如CPU、内存、硬盘、网口。在单机情况中，资源管理相对简单；分布式情况中，资源分布相对分散，怎样协调资源应对盘算任务和数据存储就是亟待办理的问题。
资源管理和调理是将盘算任务分配到资源的过程，为了处理并发的盘算任务，体系会通过集群的方式构造资源。集群中的资源可以按照服务器或者虚拟机的方式分别。
注：本文是《分布式架构原理与实践》的读书笔记。
静态资源分配和动态资源分配

也可翻译为静态资源调理和动态资源调理。
静态资源分配

简单来说，静态资源分配就是提前知道体系面对的几种盘算任务，且预设各个资源节点是稳定且可靠的，此时直接将各盘算任务分配给对应的资源实行即可。

显而易见，静态资源分配存在如下问题：

• 如果某种范例的盘算任务比较简单，任务很快实行成功，而另一种范例的任务实行耗时久，比如MR任务实行成功后，Spark任务还在排队中。则存在资源节点的闲置（浪费），没有充分使用预分配的体系资源
  
• 在体系举行资源扩容不方便，如果用户提交过多且比较告急的Spark任务，能不能增加资源节点
  

动态资源分配

鉴于上面静态资源分配这种调理方式的弊端，可考虑引入一个调理器。当某种范例的盘算任务实行完毕后，资源调理器会开释相应的资源，从而让其他盘算任务有时机获取资源。如果有部分资源节点不可用，也不会影响整个集群的正常使用，全部资源节点都会在资源调理器的安排下完成盘算任务。即便是对整个集群举行扩容，也只需把注意力放到资源节点的扩充上即可，任务与资源的动态匹配过程由资源调理器完成，实现盘算任务和资源的解耦。

动态资源调理的优势：

• 动态资源分配会根据盘算任务及时分配资源，通常不会出现资源闲置的情况，只要没有到达资源的使用上限，是不会出现任务匹配不到资源的情况的。总体来说，资源利用率较高，硬件资本较低，有良好的扩展性
  
• 必要收集资源的团体信息，形成资源池以便调配，因此能增加数据共享功能，全部盘算任务的哀求都可以共享资源
  
• 动态资源分配方式同时支持如Spark、Storm、MapReduce等盘算框架。让盘算框架和资源利用得以完全解耦，使资源管理和调理平台实现平滑切换
  

资源调理

指的是根据调理计谋对资源和盘算任务做匹配。从参与者的角度讲，涉及资源、资源调理器和盘算任务三部分。三者的关系，根据调理计谋对盘算任务和资源举行配对。常用的调理计谋，如FIFO计谋、公平计谋、能力计谋、耽误计谋。
资源调理器中包含工作队列、调理计谋、资源池和资源收集器。工作队列既是用来存放盘算任务的容器，也是资源调理器构造和管理盘算任务的一种形式。调理计谋包含所需的任务调理计谋，也就是对资源和盘算任务举行匹配的算法。资源池是对收集起来的硬件资源举行存储和管理的地方。资源收集器，就是对资源节点上报的资源举行收集和汇总。

资源调理的整个过程解析：

• 硬件资源（CPU、内存、硬盘、网口）分布在不同的网络节点上，为了让资源调理器能够更好地构造和管理它们，在每个资源节点上都安装节点管理器。节点管理器主要负责不停地向资源收集器汇报资源节点上的资源情况。管理资源的时候，必要按照规则对资源举行分割，这里临时将这些分割后的资源称为容器。设置容器的目的是将资源隔离，每个容器中都会运行指定的盘算任务，隔离的做法使得盘算任务的实行互不影响。节点管理器负责管理这些容器，并且将容器的运行情况和资源使用情况汇报给资源收集器。
  
• 资源收集器接收到节点管理器上报的资源使用情况以后，将这些资源放入资源池中实施管理。这里的资源池是一个逻辑概念，实在际存放的是目前可用的资源信息。这些信息会提供给调理计谋使用，当有盘算任务到来时，通过调理计谋在资源池中选择资源分配给它。
  
• 资源池的信息也会上报到调理计谋中。调理计谋中维护着FIFO、公平调理、能力调理、耽误调理等分配算法。
  
• 调理计谋会不停监控工作队列中的盘算任务，并依次处理这些任务——使用调理计谋对盘算任务与资源做匹配，让盘算任务在具体的容器中实行。当盘算任务实行完毕以后，资源调理器会回收资源，并通过节点管理器将空闲资源上报给资源收集器，使其重新回到资源池中等候被分配。
  
• 当有盘算任务哀求资源调理器的时候，会将这些任务放到工作队列中以便管理。资源调理器在这里起到承上启下的作用。承上是对接盘算任务框架并对其举行构造；启下是获取资源信息并对其举行抽象；最后，对盘算任务和资源按照计谋举行匹配。同时这也是一个动态资源分配的过程，这种方式可用支持不同的盘算框架。真正做到盘算任务和资源的解耦。
  

架构

在Malte Schwarzkopf的论文Omega: flexible, scalable schedulers for large compute clusters中，提到集群调理器的架构演化履历中央式调理器、两级调理器和共享状态调理器：

• 中心化调理：也叫单体调理，由一个网络节点参与资源的管理和调理
  
• 两级调理：在单体调理的基础大将资源的管理和调理从一层分成两层，分别是资源管理层和任务分配层
  
• 共享状态调理：通过共享集群状态、共享资源状态和共享任务状态完成调理工作
  

中央式调理器

Monolithic Scheduler，也叫单体式调理器，指在集群中只有一个节点能够运行调理步伐，要保证该节点对集群中的其他节点都有访问权限，该节点可获取其他节点的状态信息和资源，并且管理这些节点。中央式调理器同时也是用户哀求实行任务的入口。当用户发起盘算任务时，调理器就会对哀求任务与自己管理的资源举行匹配，然后将盘算任务分配给指定的资源节点，完成调理工作。中央式调理器必要维护资源列表和任务列表，以便对资源和任务举行束缚并实行全局调理计谋。
接纳中央式调理器的集群管理体系还不少，如Google Borg。与分布式资源调理的架构相似，中央式调理器一边接收盘算任务的申请，一边对管理资源，同时通过任务调理计谋将两者匹配在一起。
调理过程分为以下三个步调：

• 调理器的资源状态管理模块通过集群中节点上的资源管理器收集节点的资源信息。位于节点1~3上的资源管理器会将节点当地的资源信息汇集给调理器
  
• 调理器的资源状态管理模块会接收用户发起的盘算任务，并通过对集群中节点的资源把握情况，将任务交由任务调理计谋模块处理
  
• 任务调理计谋模块根据具体的调理计谋将任务分配给集群中的节点，使其运行
  

核心思想是由同一服务器管理和调理集群中全部的节点资源以及盘算任务。长处是实现起来轻易，缺点是负责管理和调理的服务器会成为性能瓶颈，限制调理规模和服务范例。
Hadoop MapReduce 1.0，就是通过中央式调理的方式对任务和资源做匹配，有不少范围性，如扩展性差、可靠性差、资源利用率低以及对无法支持多种盘算框架等。
两级调理器

Two-Level Scheduler，也可译为两层调理，为了办理中央式调理器的单点性能瓶颈问题，可考虑将资源管理和任务调理分开，即一层调理器负责资源管理，一层调理器负责任务与资源的匹配。两级调理架构的经典代表，如Hadoop 2.0 YARN（Yet Another Resource Negotiator）、Mesos。
将原来中心化的单个调理器分成两级，目的是更好地应对复杂的盘算框架和高并发的盘算任务。一级调理器的任务原来是管理资源和任务的状态，而面向不同的盘算架构扩展出多个二级调理器后，一级调理器的主要任务就是匹配任务与资源，也就是实行调理计谋。二级任务调理器又称为框架调理器，是面向不同范例的盘算框架对一级调理器的扩展。假设调理架构必要处理Spark、MapReduce、Storm三类不同的盘算任务，就可以在二级任务调理器中对调理框架举行扩展，既起到与调理计谋解耦的效果，又可以应对高并发的盘算任务。

调理步调：

• 一级调理器的资源任务状态管理模块通过集群中节点上的资源管理器收集各节点的资源信息，位于节点1~3中的资源管理器会将节点当地的资源信息汇总到一级调理器上。和中央式调理器是一样，管理资源信息的工作依旧是由一级调理器完成
  
• 一级调理器的资源任务状态管理模块会接收用户发起的盘算任务，通过对集群中节点的资源把握情况，将盘算任务交由二级调理器对应的任务调理计谋器处理
  
• 二级调理器接收到任务调理哀求后，根据盘算框架的调理计谋对资源和任务举行匹配。对不同范例的盘算任务举行分类。另外，二级调理器支持水平扩展，可提高节点的处理能力
  
• 二级调理器在处理完任务调理以后，会将结果返回给一级调理器，然后根据调理计谋的结果将任务分配到对应的服务器节点上运行。一级调理器会不停地监控资源和任务运行情况，保证任务的顺遂运行
  

两级调理器办理调理器扩展和处理大数据量任务哀求的问题，但还是无法看到体系的全部资源。调理器没有全局视角，无法知道作业可以被分配到哪个服务器节点上运行，仅能感知资源管理器收集并提供的资源，以及资源管理器分配给应用步伐/作业的部分资源。总结为以下两点：

• 无法举行全局优化：考虑集群资源告急时，如果有一个任务运行失败，任务应该怎样分配呢？即怎样选择实行节点？如果调理器能够获取整个体系的资源情况，这样可以优化资源调理。
  
• 悲观锁导致并发量受限：在匹配任务与资源的时候，为了制止资源抢占冲突，即制止不同的作业抢占同一个资源，通常会对资源做加锁操作。两级调理器接纳的是悲观锁并发调理，也就是事前预防资源抢占的情况。具体地，在任务运行之前首先查抄是否存在资源冲突的情况，如果不存在冲突就继承运行，否则等候或举行回滚操作。在调理过程中，会将全部资源依次推送给每个盘算框架，让这些框架依次匹配资源，从而保证不会出现多个盘算框架使用同一块资源的情况。这种做法固然制止资源抢占冲突，但同时也减少体系任务的处理并发量。
  

共享状态调理器

Shared State Scheduler，针对两层调理体系存在的全局优化和并发调理受限问题，提供两点措施：

• 让集群全局资源对每个调理器均可见，把集群资源信息转化成持久化的共享数据（状态）；
  
• 采取多版本并发访问控制（MVCC）的方式对共享数据举行访问，也就是常说的乐观锁。乐观锁并发调理，夸大事后检测，会在任务提交的时候查抄资源是否存在冲突，如果不存在冲突就继承运行，否则举行回滚操作或者重新运行。也就是说，它是在实行匹配调理算法之后举行冲突检测，优点是能够处理更高的并发量。
  

乐观并发调理和悲观并发调理的对比：

• 乐观并发调理：夸大事后检测，在事务提交时查抄是否制止冲突，若制止，则提交，否则回滚并自动重新实行。
  
• 悲观并发调理：夸大事前预防，在事务实行时查抄是否会存在冲突，不存在，则继承实行，否则等候或者回滚。
  

共享状态调理的理念最早是Google针对两层调理器的不足而提出的，典范代表有Google Omega、微软的Apollo，Hashicorp Nomad容器调理器。
Omega使用共享状态调理的思想，在一个同一模块中完成以下功能：对整个集群中的全部资源分组；限制每类应用步伐的资源使用量；限制每个用户的资源使用量等。只是将优先级限制放到共享数据的验证代码中，当多个作业同时申请同一份资源时，优先级最高的作业将获得该资源，其他资源限制全部下放给各个调理器实行。
Omega架构中没有中心资源分配器，全部资源分配决议都由应用的调理器自己完成。与Borg架构雷同，Omega中也有一个单位（Cell）的概念，每个单位分别管理集群中的一部分服务器节点，一个集群由多个单位构成。单位中资源的状态由Cell State记载，同时Omega会在State Storage里维护Cell State的主复制，每个调理器中都会维护一个Cell State的备份信息，用来和State Storage保持同步，从而保证每个调理器都能够获得全局的资源信息。

集群里有多个调理器，主要负责作业和资源的调理工作，定期与State Storage同步Cell State的主复制，通过不停地同步可以获得集群中全部节点的资源情况。State Storage会不停地从集群中搜集Cell State信息，用作调理器同步。当调理器确定作业与资源的分配方案后，会通过原子的方式更新共享的Cell State，也就是通过乐观锁的方式将分配方案提交给Cell State。之后，调理器会重新同步当地的Cell State到State Storage的Cell State中，此时其他调理器可以通过同步State Storage中的Cell State，得知全局资源的使用情况。
Omega使用事务管理状态的计划思想，将集群中资源的使用和任务的调理雷同基于数据库的一条条事务去管理。调理器对Job的调理是具有原子性的，一个Job中全部的Task都是一起调理的，即使部分Task调理失败，调理器再次调理时必须调解整个Job。Omega的调理流程如下图所示：

对比

关于单体调理、两层调理和共享状态调理的具体比较
对比项\调理中央式调理两级调理共享状态调理调理架构集中式结构：一个中央树调理器形结构：一个中央调理器，多个第二层调理器分布式结构：多个对等调理器调理形式单点集中调理Resource OfferTransaction调理单位TaskTaskTask任务调理的并发性无并发悲观并发调理乐观并发调理是否是全局最优调理是否是体系并发度低中高体系可扩展性低中高调理服从低中高适用场景小规模集群，适用于业务范例比较单一的场景中等规模集群，适用于同时具有多种业务范例的场景大规模集群，适用于同时具有多种业务范例的场景典范应用BorgMesos、YARNOmega 参考

• 分布式架构原理与实践
  
• 调理框架：共享状态调理
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。