分布式系统架构调研

本文最后更新于:1 年前

嗨嗨嗨,基于我的本科毕设以及研究生方向是和Distributed System相关,这里在老师的要求和自己的探索精神下,简单的读了一些文献,这里浅做记录。

分布式消息系统研究综述:

paper link: https://www.jsjkx.com/EN/article/openArticlePDF.jsp?id=18255

  • 本文主要讲述的是分布式消息系统,分布式消息系统是分布式系统之间进行消息传递的重要组件,它利用高效、可靠的消息传递机制进行平台无关的数据交流,并基于数据通信进行分布式系统的集成。

  • 分布式消息系统中的消息传递主要有两种模式,分别是:

    • 点对点模式(Point to Point,PTP),说白了就是信息一对一关系。生产者-消息队列-消费者,一条消息由一个生产者生产,被一个消费者消费。

    image-20230128155913539

    • 发布-订阅模式(Publish-Subscribe,Pub-Sub),消息生产者生产消息,将消息发布到 Topic中,消 息消费者订阅 Topic,从 Topic中取出并且消费消息.消息一 直保存在 Topic中,一条消息可以被所有订阅该 Topic的消费者消费。

    image-20230128160056580

多数分布式消息系统采用发布G订阅模式进行消 息传递,有些消息系统也支持点对点模式的消息传递.

RabbitMQ

系统架构

  • 整体架构:

image-20230128160336636

  • 组成部分:

    • Broker: 消息队列服务器, 用于接收和分发消息.每一个 RabbitMQServer是一个Broker, 一个 RabbitMQ集群由一个或多个 Broker组成。
    • Queue: 用于存储消息, 一 条消息可以被转发到多个Queue中。
    • Exchange: 用于转发消息,根据分发规则,将消息转发到 Queue中。
    • Binding: Exchange和Queue之间的虚拟连接, Binding中包含RoutingKey。Binding信息保存在Exchange的查询表中, 用作消息的分发依据。根据RoutingKey绑定的Exchange与Queue的对应规则, 决定消息发送的方向。
    • VirtualHost: 用于区分不同用户权限. 把AMQP的基本组件划分到一个虚拟的分组中,当多个不同的用户使用同一个Broker时,可以划分多个VirtualHost,每个用户在自己的VirtualHost上创建Exchange,Queue等.Broker中可以有多个VirtualHost.
    • Connection: Producer, Consumer和 Broker之间的TCP连接.除出现网络故障、Broker宕机情况外,Broker不会断开连接, 只有客户端可以断开连接。
    • Channel: Connection内部建立的逻辑连接.每个 ChanG nel代表一个会话任务,所有操作都在 Channel中进行,如果 应用程序支持多线程,通常每个线程创建单独的 Channel进 行通信.Channel作为轻量级的 Connection,减少了系统建立 TCPConnection的开销.Channel之间是完全隔 离 的,Connection中可以建多个 Channel。
  • Exchange模式:

    • Direct: 默认,处理RouteingKey,Queue与Exchange绑定,Exchange消息转发到与RoutingKey完全匹配到Queue上。
    • Fanout: 不处理RoutingQueue,消息转发到和Exchange绑定的所有Queue上(广播)。转发速度最快。
    • Topic: 模式处理RoutingKey, Queue与 Exchange绑定,将发布到 Exchange 的消息转发至与 RoutingKey模糊匹配成功的Queue上,
    • Headers: 不 处 理RouG tingKey,Queue与 Exchange绑定,绑定时 Queue提供一组键 值对,如果消息的键与其完全匹配,则 Exchange将消息转发到Queue.(和Direct思路一样,但是性能差很多,不太实用)

Producer发送消息至Exchange,Exchange根据ExGchange模式匹配到对应的Queue,将消息存入Queue中,Consumer从Queue中取出消息进行消费.

性能分析

  • 负载均衡:

    • 如果有多个 Consumer同时订阅同一个 Quque中的消 息,Quque中的消息会被平均分配给多个 Consumer.
    • 若每条消息的处理时间不同,就会导致某些 Consumer一直很忙,而 另一些 Consumer很快处理完工作,处于空闲状态.可以设 置 PrefetchCount=1,则 Quque每次给每个 Consumer发送 一条消息;Consumer处理完这条消息后,Quque会再给 ConG sumer发送一条消息,以实现负载均衡。(类似于Ack)
  • 可靠性:

    • 通过消息回执 (MessageAcknowlegment)机制、消息持久化(MessageDurability)机制和消息跟踪机制保证系统的可靠性。
    • Consumer在消费完消息后,发送一个回执Broker, Broker收到消息回执后,才将该消息从Queue中移除.如果Broker没有收到回执,并检测到消费者的Broker连接断开,则Broker会将该消息发送给其他Consumer进行处理。
    • 当将 Queue设置为可持久化(Durability)时,数据会保存在硬盘上,保证了数据的可靠性。
    • RabbitMQ提供消息跟踪机制,如果出现消息异常 的情况,用户可以通过跟踪机制找出异常。
    • RabbitMQ 支持集群模式,多台服务器的 Queue数 据同步,若一台服务器丢失消息则可从其他服务器上获取,以 保证数据不会丢失。(Replication)
  • 可拓展性:RabbitMQ 提供了许多插件,用户可以从多方面进行扩展,也可以根据需求开发自己的插件.

Kafka

系统架构

image-20230128185145233

  • 组成部分:
    • Broker: 用于持久化和备份消息.每一个KafkaServer是一个Broker, 一个Kafka集群由一个或多个Broker组成
    • Topic: 消息按照类别区分,每个类别是一个Topic,一个Broker可以容纳多个Topic
    • partition: 用于存储消息数据和索引文件.partition是一个有序的队列,每条消息在partition中拥有一个偏移量(offGset),保证了消息的有序性,一个Topic可以包含一个或多个partition.
    • Producer: 生产消息, 产生的消息将被发送到Broker的Topic.
    • Consumer: 消费消息,消费的消息内容来自Broker的Topic.Kafka在创建Consumer时,设置其属于某个ConsumerGroup, 一个partition的数据可以同时被多个ConsumerGroup消费, 但是只能同时被ConsumerGroup内的一个Consumer消费. 当一个Topic被多个ConsumerGroup订阅时,如果每个Consumer属于不同的ConsumerGroup, 则实现了消息的广播;如果所有Consumer属于相同的ConsumerGroup,则实现了 消息的单播.

Producer产生消息,向Broker的Topic发布;Consumer订阅Broker的Topic,主动从Broker中拉取消息进行消费,通过指定offset可以消费任意位置的消息。

性能分析

  • 效率
    • partition设计和consumer group设计提高了系统的吞吐量和并发处理能力
    • 创建Topic时设置partition数量,所有的partition被均匀地分布在集群的所有节点上。Producer向Broker的Topic发布消息时,可以通过随机、哈希、轮训等策略选择将某条消息发布到某个partition。消息被并行地发布到不同节点的partition中。Producer和Consumer可以同时从多个partition上读写数据,提高了系统的并行处理能力。
    • Kafka在创建Consumer时,设置其属于某个ConsumerGroup。ConsumerGroup之间完全独立,不同的ConsumerGroup可以同时消费一个partition的数据;ConsumerGroup内的多个Consumer可以交错地消费一个Topic的所有partition的数据,减少了每个Consumer连接Broker的通信开销,ConsumerGroup的设计有效地提高了消费消息的效率.
    • Kafka采用发布、订阅模式传递消息,Producer只负责向 Broker发布消息,Consumer只负责从Broker消费消息, 消息的发布与消费是异步的,极大地提高了Kafka的吞吐量。
  • 负载均衡
    • ZooKeeper进行集群管理.Broker,ConsuGmer和ConsumerGroup都在ZooKeeper中注册,增加或减少Broker和Consumer均会触发负载均衡.此外,Topic与BroGker的对应关系以及partition在集群内的分配也由ZooKeeper进行维护.
  • 可靠性
    • Producer通过确认机制保证发布消息的可靠性.Producer发布消息后,如果在等待时间内未收到确认消息,则重新发布消息.
    • Kafka将消息持久化到本地磁盘,消息被消费后不会立即删除,通过设置消息存储时间或存储消息最大值,自动处理消息.消息在存在期间可以被多次消费,若Consumer发生故障,没有正常消费消息,可以根据offset查找到上一条消息,重新处理.
    • Broker通过备份partition提高系统的可靠性.每个parGtition有多个备份,其分布在不同的服务器上,即使某个服务器发生故障,数据也不会丢失.同时,ZooKeeper查找可用Broker,并通知生产者和消费者,生产者和消费者转而使用其他Broker,不影响其正常工作
  • 可扩展性
    • Kafka使用ZooKeeper保存元数据信息,进行负载均衡,提高系统的健壮性,在增加Broker,partition时,直接向ZooKeeper注册即可,不影响系统正常运行,使Kafka支持在线水平扩展,具有高可扩展性.

ActiveMQ

ActiveMQ是一个开源的消息中间件

系统架构

ActiveMQ 架构主要包括3层5个模块:传 输协议、消息域、消息存储、集群(Cluster)和监控(Monitor).

image-20230128191332148

  • 组成部分:
    • 传输协议: 消息之间的传递需要协议进行沟通.ActiveMQ支持多种通信协议,包括TCP,NIO,STOMP等;ActiveMQ默认使用的应用协议是OpenWire,端口号为61616。
    • 消息域: PTP,Pub-Sub两种消息传输模式。
    • 消息存储: 消息存储到数据库或文件系统中,遇到机器故障时,信息不会丢失。
    • Cluster(集群): 最常见的集群方式包括network of brokers和Master Slave.
    • Monitor(监控): ActiveMQ一般由JMX来进行监控.

ActiveMQ支持PTP和Pub-Sub两种消息传递方式。ActiveMQ提供通信接口、消息保存接口和网络服务接口。通信接口负责网络连接和消息传输;消息保存接口将数据持久化;网络服务接口支持存储转发、集群和命名服务等

性能分析

  • 性能:
    • 支持集群模式,支持多种传送协议,如 TCP, SSL,NIO,UDP等,且支持JDBC 消息持久化和高效的日志系统。
  • 可靠性:
    • 支持内存、文件、内嵌数据库和外部数据库4种消息持久化方式,还提供失败重连机制、容错机制和多种恢复机制。另外,有很多种方法可以监控ActiveMQ不同层面的数据,包括JConsole,JMX等,保证了ActiveMQ消息的可靠性.

RocketMQ

阿里巴巴公司开源的分布式的消息中间件。RocketMQ去掉了ZooKeeper依赖,采用自主研发的轻量级名称服务(NameServer)进行元数据管理。由Java语言开发,采用发布订阅模式传递消息,具有高效的水平扩展能力和亿级消息堆积能力。是高性能、高吞吐量的分布式消息中间件.RocketMQ可以运行在Java语言所支持的平台之上。

系统架构

image-20230131091033238

主要由NameServer,Broker,Producer和 Consumer4 个 模 块构成,NameServer和Broker构成服务端,Producer和 Consumer构成客户端.。

  • 组成部分:
  • Broker:提供关于消息的管理、存储、分发等功能,是消息队列的核心组件。3种集群部署方式: 单Master部署、多Master部署、多Master多Slave部署。采用多Master多Slave部署方式时,Master和Slave可以采用同步复制和异步复制两种方式。
  • Producer:即消息生产者,每个生产者都有一个ID,多个生产者实例可以共用同一个ID,同一个ID下所有实例组成一个Producergroup,每个Producer都属于一个group.
  • Consumer: 即消息消费者,每个消费者都有一个ID,多个消费者实例可以共用同一个ID,同一个ID下所有实例组成一个Consumergroup.在集群消息的配置下,集群内各个服务平均分配消息,当其中一台Consumer宕机,分配给它的消息会继续分配给其他的Consumer.
  • NameServer: 即注册中心,存储当前集群的所有Broker信息以及Topic与Broker的对应关系.Producer,Broker和Consumer在启动时均向NameServer进行注册, NameServer之间不通信.NameServer监听端口,等待Broker,Producer,Consumer连接.Broker启动,与所有NameServer保持长连接,定时发送心跳包.心跳包中包含当前Broker信息、存储的所有Topic信息.Producer启动,与NameServer集群中的一台NameServer建立长连接,获取当前发送的Topic与Broker的映射关系,然后与对应的Broker建立长连接,向Broker发消息.Producer发送消息时,自动轮询当前所有可发送的Broker.若消息发送成功,再次发送消息时,选择下一个Broker,以实现将消息平均分布在所有Broker上.Consumer启动,与NameServer集群中的一台NameServer建立长连接,获取当前订阅的Topic与Broker的映射关系,然后与对应的Broker建立长连接,开始消费消息.

性能分析

  • 效率

    • 所有Topic数据同时只写一个文件,一个文件满1G后再写新文件,顺序写盘,使得发消息吞吐量大幅提高,为系统提供了的高并发读写服务.
  • 可靠性

    • Broker将消息持久化到磁盘文件,每天定时清理消息,文件默认保留时间为72h。Broker集群采用主从模式部署时,备机实时从主机同步消息,如果其中一台主机宕机,备机提供消费消息服务,但不提供发布消息服务,不支持主从自动切换.若某个Broker宕机,Producer仍然会向宕机的Broker发送消息,当消息发送失败后,会自动重发2次.如果仍发送失败,则抛出发送失败异常,自动轮询另外一个Broker重新发送。
    • NameServer之间没有通信,没有频繁的读写,性能开销较小,稳定性高,单台NameServer宕机不影响其他NameServer和集群的正常工作.
  • 可扩展性

    • 集群中增加Broker时,首先启动Broker,然后向NameServer注册信息.Producer和Consumer通过NameServer获取Broker信息,与Broker建立连接,进行收发消息,不影响系统中其他Broker正常工作.

系统对比

  • 横向对比图:

image-20230131092252217

  • RabbitMQ

    • 开发语言为Erlang,语言特性,并发好,学习成本高。
    • 消息大小无限制,有序,异步。跨平台,多语言,消息确认&持久化,事务。
    • 批量操作不支持。
    • 用于实时,可靠性较高的场景。
  • Kafka

    • 吞吐量大,集群,持久化,批量处理,透明扩展。容错性高(Partition), 三方Kafka-Manager,日志成熟。
    • 用于大量的活跃流式数据。
  • ActiveMQ

    • 消息持久化,多种持久化渠道。反馈确认机制,多种JMS协议,管理工具丰富,故障处理完善,水平拓展方便。
    • 性能不太好,不适合上千个队列的场景。
  • RocketMQ

    • 高吞吐量、高可用性、适合大规模分布式系统应用。消息可靠,事务优化。
    • 模型简单,接口易用。持久化,多主多从。
    • 支持的客户端语言不多,目前支持Java和C++。(Java支持最好,不愧是阿里orz,C++的支持都还不好)
  • Summary

    • 性能上,Kafka>RocketMQ>RabbitMQ>ActiveMQ。
    • RabbitMQ: 对路由、负载均衡、数据持久化都有很好的支持。支持多种协议(重量级),适合企业级开发。
    • Kafka: 高吞吐量的消息系统,支持持久化,适合于处理活跃的流式数据、产生大量数据的互联网服务的数据收集业务.
    • ActiveMQ在集成不同平台、不同语言编写应用时,拥有巨大优势。
    • RocketMQ猛的很,内部大量应用,经受住了考验。

除了上面介绍的,还有ZeroMQ,Redis等,也可以用作消息队列。相比上述4种成熟的分布式消息系统,ZeroMQ和Redis较为简洁,系统开发人员可根据其提供的发布订阅消息传递机制,进行定制开发.。

分布式系统可伸缩性研究综述

摘要

​ 可伸缩性(Scalability)反映了系统可随系统需求和资源变化,持续满足性能需求的能力。在不同的场景下,可伸缩性的基本定义和度量方法能够通过不同的角度进行理解和表达。根据系统需求和运行状态,改变可用资源数量以及任务调度方式,动态调整系统性能,是系统可伸缩性实现的主要途径。

​ 分布式资源管理系统可伸缩性设计的关键技术可以从并行任务调度和分布式系统框架两个方面进行分析。可伸缩性测试是检测和评价系统性能的主要依据,并行代码测试以及可伸缩性测试系统设计的主要方法是测试技术的两个重要组成部分。

​ 随着软件范型的发展变化,软件的部署和提供逐步向基于开放、共享虚拟化资源管理平台的在线服务方式的转变,可伸缩性已成为云计算背景下软件服务的重要性能指标,进一步探讨可伸缩性在新的软件范型下所面临的挑战性问题是可伸缩性研究的新方向。

概述

可伸缩性是分布式计算和并行计算中的重要指标,它描述了系统通过改变可用计算资源和调度方式来动态调整自身计算性能的能力。

  • 可伸缩性:
    • 硬件:通过改变硬件资源来满足变化的工作负载,比如改变处理器的数目、内存和硬盘的容量。
    • 软件:通过改变调度方式和并行化程度,来满足变化的工作负载。

度量、设计与测试是系统可伸缩性研究的3个主要方面。

  • 度量:可伸缩性的度量方法是设计和测试可伸缩系统的基础。但是由于可伸缩系统存在的环境复杂多样,因此准确地度量一个系统的可伸缩性是非常具有挑战性的。一般的度量方法是通过加载不同的系统资源和系统负载,来评价系统在这个过程中的性能变化。在最理想的情况下,如果同时对工作负载和计算资源进行K倍的增长或减少,而系统或应用的平均响应时间不变,则系统拥有最优的可伸缩性
  • 设计:资源的按需动态分配和调度是系统可伸缩性的重要基础。对于传统的分布式和并行系统,在工作负载变化时,底层的资源管理机制和调度效率决定了系统应用的可伸缩性。资源调度效率高的管理机制,在工作负载增大的情况下,能够为系统和应用及时分配更多的资源,使得系统和应用的计算能力在短时间内适应大工作负载,避免造成计算能力的大幅滑坡;在工作负载降低的情况下,及时回收限制资源,提高系统对资源的利用率,为其余的应用预留资源储备。反之,资源调度效率低的管理机制对改变资源的请求不敏感,会造成分配或者回收资源不够及时和充分。
  • 测试:测试是检验和评价可伸缩性的依据。目前对可伸缩性存在着两个层次的测试:1)代码级别测试;2)系统级别的测试。代码级别的是针对并行程序中的每一个代码块,检测它对系统可伸缩性的影响。一般利用统计学的方法,对并行算法进行统计建模,根据多次实验的结果统计评价代码块对于系统性能的贡献,定义可伸缩性的权重参数,从而分析整个并行程序的可伸缩性。系统级别的测试方法是通过工作负载的预分析和实时运行状态的监控,将预分析的结果和实时的监控结果结合,分析整个系统的可伸缩性。

随着云计算等分布式计算平台技术的发展,SOA(Service-Oriented Architecture)和Saas(Software As A Service)等新型软件开发范型的发展对可伸缩性提出了更高的要求。例如,云计算和Saas提出了“无限资源”的概念,为大规模应用提供海量资源共享、高可伸缩的能力。可伸缩性已成为新型服务计算模式的基础和关键,也对传统的可伸缩性度量、设计和测试技术提出了新的挑战。本文在对上述已有研究和实践工作调研和分析的基础上,进一步探讨云计算平台下服务软件的可伸缩性研究的挑战性问题。

可伸缩性定义

  • 可伸缩性是指网络、系统或者进程能够通过扩充自身资源来支撑更大工作负载的能力。他将可伸缩性分为4个类别:负载可伸缩性、空间可伸缩性、时空可伸缩性和结构可伸缩性:

    • 负载可伸缩性是指系统能够平滑地在变化的工作负载下过渡,通过调节资源来满足变化的负载,在调节的过程中不会产生超过规定限度的时间延迟和资源占用。
    • 空间可伸缩性是对系统调节资源的一个限制,即在负载增大的情况下,所占用的资源(内存、磁盘空间等)最多和负载呈线性增长,禁止了通过无穷尽地增加资源来支撑负载的做法。
    • 时空可伸缩性是指在给定的运行时间要求下(时),通过扩展资源(空)来满足增大的负载,在扩展的同时应用的运行时间依旧满足要求。
    • 结构可伸缩性是指实现的结构能够很容易地进行资源上的扩充和调节。
  • 可伸缩性的定义是:对于特定的需求集合,在不同的负载下,系统对资源的利用率保持不变。对于可伸缩性的度量,在特定的领域下才有意义,这样也就产生了可伸缩性度量的多个维度。三个维度的示例:

    • 处理效率的维度中,系统对信息的处理效率是影响系统行为的最重要指标,它指导了系统调节资源适应负载的行为。在这个指标下,可以对可伸缩性进行更明确的度量。
    • 同样地,在存储空间接入点数目的维度中,系统的伸缩行为受到存储空间和接人点数目的影响和指导。一些研究进一步扩展了可伸缩性的维度,提出了性能、经济、物理大小、寻址、软件独立性、通信能力、技术独立性和可选择性等多个维度。
  • 上扩和外扩:

    • 上扩是指给单个计算节点使用性能更好、速度更快和成本更高的硬件来增加资源,包括添加更多内存、添加更多或更快的处理器,或者只是将应用程序迁移到功能更强大的单个计算机。
    • 外扩是增加计算节点的数目来增加资源。外扩增加了计算节点的数目,对管理提出了更大的挑战。

image-20230202161427657

外扩比上扩更容易达到最佳可伸缩性;而且外扩这种方式可以更加灵活地增加或者减少计算节点。

可伸缩性的度量方法

多数的可伸缩性度量是在并行系统中定义的,主要有基于速度的、基于加速比的和基于效率的方法。

  • 速度:

    • SunXian-He提出了isospeed方法来度量算法的可伸缩性。Isospeed方法可以有效度量同构系统的可伸缩性。为了度量异构系统的可伸缩性,
    • SunXian-He又提出了isospeedefficiency方法。
  • 加速比:加速比s是系统使用k个计算节点所能达到的速度与只使用1个计算节点时的速度的比值,理想状态下就是k倍。

    • 大小固定加速比
    • 执行时间固定加速比
    • 内存有界加速比
    • 普遍加速比
  • 基于效率的方法

    • 并行系统中执行时间是表示效率的重要指标。并行系统中每个节点是匀称,所以节点数目是适合的缩放属性。

分布式资源调度与管理

​ 分布式资源管理是分布式系统和应用的基础,资源分配和调度的效率直接决定了上层系统和应用的可伸缩性。本节分析了分布式资源调度的两种模式和它们所对应的典型管理系统。

​ 分布式资源调度围绕资源调度器,构建资源管理系统,监控各个资源的状态,将状态反馈给资源调度器作为决策的基础。根据调度器做出的分配方案,操作底层的资源为任务在不同的节点上分配资源。资源分配方案和资源的操作都可以影响系统的可伸缩性,方案决定了任务需要的资源可以得到调度的时刻,而资源的操作效率则决定了为任务调度资源所耗费的时间,二者联合决定了系统对于变化的任务需求和资源变化的反应时间,从而影响了可伸缩性。

​ 根据是否具有资源分配的核心控制程序,分布式资源管理系统可以分为中心式和分布式两种模式。中心调度的分布式资源管理系统把所有对于资源的请求都交给核心调度程序处理,由这个核心程序来分配各个节点的资源。而分布式调度由一个计算节点接收请求,这个节点同其他的节点进行交互和协商来完成资源的分配。

中心调度模式

一般由4个组件构成,它们是调度器、信息存储中心、资源分配器和本地资源管理器:

image-20230202165302917

在这个框架中 ,4个组件的功能如下:

  • 调度器:是资源调度请求的接收者和调度算法的执行者,它根据请求的具体内容,以信息存储中心中所存储的资源和任务的状态信息为基础,用调度算法计算得出一个资源分配方案,并且把这个方案传递给资源分配器。
  • 信息存储中心:存储着资源和任务的实时状态信息,这些信息是调度器做出资源分配方案的依据,调度器可以通过主动查询的方式获得这些信息。
  • 资源分配器:是资源分配方案的实际执行者,它将调度器给予的资源分配方案拆分为更小单元,即资源分配命令。每个资源分配命令是一个二元组,包括了一个资源节点的标识符和在对应资源节点上需要分配的资源数量。同时,资源分配器还负责更新信息存储中心中的信息。
  • 本地资源管理器:是每一个资源节点上的监控者和资源分配者,它接收资源分配命令,在节点上为请求分配数量的资源,并且监控本地节点的任务运行状态和资源状态,把这些状态信息反馈给资源分配器,由资源分配器对信息存储中心的数据进行更新。

Legion就是其中一个例子

Legion

image-20230202165641435

​ 在Legion中,资源节点利用资源预留的机制来进行本地资源的分配。即对于某一个资源分配命令,监控器把命令解析之后传递给对应的资源节点,节点根据命令为任务预留资源,在任务执行完毕之前,这些资源将不会被占用。同时,资源节点还负责更新任务和资源状态,它可以主动地向信息收集中心添加或者更新信息,信息收集中心也可以询问资源节点来获得自己需要的信息。

​ Legion中,典型的资源分配流程如下:

  1. 决策步骤:调度器接收一个资源请求,通过解析请求的内容和查询信息收集中心中的任务和资源的状态信息,根据预先定义的调度策略来产生一个资源分配方案。
  2. 协商步骤:资源分配器从调度器处接收到资源分配计划,检验计划的合法性。如果合法,就进入分配步骤;如果不合法(例如在某个资源节点上需要分配超过可用数量的资源),资源分配器就与调度器进行协商,得出一个新的合法方案。协商的根据是信息收集中心中的信息和资源分配方案。
  3. 分配步骤:资源分配器根据合法的资源分配方案,向监控器发送预留资源的命令,监控器接到命令之后在本地为到来的任务预留所需数目的资源。在任务到达之后,监控器启动任务,并且监控本地任务的运行状态和本地资源的状态。
  4. 信息更新步骤:在任务开始运行之后,资源节点根据设定好的时间间隔向信息收集中心更新或者添加任务和资源的状态信息,信息收集中心也可以主动查询资源节点上的信息。
  • 以上4个步骤是循环的,当信息更新步骤结束之后,新一轮的决策步骤又重新开始,为下一个请求分配任务,直到所有任务的资源调度都结束之后,这个循环才停止。
  • 中心调度的资源管理模式在系统负载较小时能够较好地维护系统的可伸缩性,因为调度器可以从信息存储中心获得系统中所有的任务和资源的状态信息,根据一步到位的信息迅速做出决策,并把资源分配命令交给资源分配器去完成。但是当系统负载较大时,调度器需要频繁处理很多请求,造成调度器的响应变慢,系统需要较长的时间来重新调度,系统的可伸缩性较差。

分布式调度模式

Legion资源分布框架都是基于中心调度的中心调度的缺点也很明显,它只有一个组件能够做出资源分配的决策,这个组件很容易成为系统的瓶颈。当它出现问题的时候,系统的资源分配将不能继续进行。分布式调度框架中有多个成员组件都能够完成资源分配的功能,从而避免了系统中有明显的瓶颈存在。分布式调度模式的资源管理系统中,节点通过相互通讯连接构成一张图,任意一个节点都能够和自己相连的伙伴进行协同,从而满足所接收到的资源请求。其框架如图4所示。

image-20230203205736485

  • 通信组件:用于和其它的伙伴节点进行通讯,是资源节点之间进行协同和决策的基础。
  • 决策组件:是节点的核心控制单位,决定了节点之间的协同方式和最终资源分配方案指定的算法。
  • 本地资源管理组件:用于监控本地资源的状态,为决策组件提供决策的依据。

ARMS

的采用分布式调度模式的资源管理系统。Agent是自主的智能软件实体,它具有自主性、社会性、反应性和适应性的特点,Agent之间能够在目标驱动的情况下通过相互之问的交流,对外界环境的变化和事件做出响应,完成某些特定的任务。

  • Agent层次结构:

image-20230203205932194

  • ARMS中Agent分为3层,分别是本地资源管理层,协同层和通讯层。

image-20230203210030718

  • ARMS中Agent3层的功能如下。

    • 通讯层:负责Agent同其他Agent的通信,信息分为3个类型
      • 广告(Advertisement),一个Agent新加入ARMS的层次结构时,利用广告信息对其余Agent宣布自己的存在;
      • 探索(Discovery),探索信息是分布式应用程序的资源的请求;
      • 转发(To Another Agent),当Agent本身和它已知的父节点、子节点都不能满足一个请求时,它会将这个请求转发给自己的邻近节点,由邻近节点继续寻找合适的资源。或者当Agent发现自己的一个邻近节点满足请求时,这个请求也会被转发到该节点,由这个邻近节点来完成资源的分配工作。
    • 协同层:是Agent的核心结构,Agent利用ACT(Agent Capability Table)来维护自己本身、父节点Agent和子节点Agent所代表资源的性能信息。ACT可以分为4类:
      • T—ACT,用来维护自身的信息
      • L—ACT,用来维护子节点Agent的信息
      • G—ACT,用来维护父节点Agent的信息
      • C—ACT,用来维护缓存的Agent信息。
    • 本地管理层:负责本地资源的监控、分配和应用程序的管理,是Agent和本地底层系统的接口层。
  • 协同层详解:

Scheduler通过估计请求的结束时问来进行任务的调度,调度的目的是找到一个最小的请求结束时间。exet是估计的请求执行时间,ts是请求开始执行的时刻。PACE(Perfomance Analysis and Characterize Environment)引擎可以根据本地资源的情况和应用的请求来估计exet。ARMS的应用程序请求都包含一个应用模型(application model,am),PACE通过内部定义的eval函数来估计exet:Agent估计exet使用ACT的顺序是:C, T, L, G。根据估计结果,找出最小所对应的ACT。如果是T—ACT,则Match Maker把调度结果发送到本地管理层,进行本地的资源分配。否则,把请求转发到ACT对应的Agent。如果找不到满足条件的ACT,则将请求转发到自己的父节点和子节点,由父节点和子节点继续上面的寻找过程,直至找到满足条件的ACT。

  • 分布式调度的资源管理模式适用于系统负载较大的情况,把决策的指定分散到各个不同的节点并行进行,使得系统在大负载下仍然能够较快地对资源进行重新调度。在系统负载小的情况下,一个节点要做出调度需要同多个节点进行交流,这反而降低了决策的效率,降低了系统的可伸缩性。

可伸缩性测试现状

​ 测试是验证和评价可伸缩性的基础。可伸缩性测试主要有两种方式:

​ 代码级测试。通过执行多组不同条件的测试,在每组测试中评价代码块与程序总响应时间的相关系数。对比各组测试中代码块相关系数的变化,来衡量代码块的并行度。通过各代码块的并行度评估程序的可伸缩性。

​ 系统级别测试。系统级别的测试通过对工作负载的估计,测试运行的实时监控和测试运行结果来综合评估程序的可伸缩性。在多数研究中,可伸缩性只是作为一个实验的性能指标,目前针对可伸缩性的测试方法和系统本身的研究比较有限。下面分别介绍一种代码级别和一种系统级别的可伸缩性测试方法。

并行代码的可伸缩性测试

​ 并行代码的可伸缩性可以通过分析每个代码块的性能得到:代码块的并行性越好,说明增加少量的处理器就可以保持并行程序的效率;反之,需要增加更多的处理器来保持程序的效率。测试人员经常用建模的办法来分析系统或者程序的性能,根据系统和应用内部模块的组成和相互关系来构造系统的结构模型,进行性能分析。

​ 由于并行计算系统内部的结构和组件之间的逻辑关系都比较复杂,建模十分困难且代价昂贵,且模型的正确性难以保证。为此,、DEX(statistically designed experiment)方法,DEX将被测的并行程序和系统视为一个完整的实验整体,把代码片段和系统的各个参数视为实验的各个因子。基于程序的运行结果,通过监控并行程序中各个代码模块的性能指标,采用统计的方法来分析各代码块对程序运行时间的影响,得出每一个代码块对算法效率的重要程度。DEX引入了SP(Synthetic Perturbation),用来对实验中各个因子施加扰动,这些扰动用于在系统运行时制造延时,用于构建实验因子到实验结果的映射。当某个因子厂被施加扰动时,可以通过对扰动造成延迟的分析来衡量对系统或者程序运行的影响程度。

​ DEX的目的是对于一个被测的并行程序P,找出P中可能成为程序运行瓶颈的代码块。DEX中,实验以组为单位进行。在同一组实验中,系统的各个因子保持不变,而对于每个代码块的扰动在持续改变,通过分析这组实验中扰动和程序运行时间的关系,得出运行时间对每个代码的敏感度E,E越大的代码块,当被施加同等长度的时间延迟扰动时,造成程序运行时间的延迟越大。接着进行其他组的实验,改变系统中的因子(一般是处理器的数目),在增加或者减少处理器数目的情况下,重新分析每个代码块的E值。最终,对比两组实验中同一代码块的E值,观察在处理器的增加的情况下E的增长幅度,E增长越大的模块,说明该代码块并行度越差,成为瓶颈的可能性越大。若E随着处理器增加而减小,则说明这个代码块的并行度较好,成为瓶颈的可能性越小。

可伸缩性测试系统设计

​ 可伸缩性反映了系统可随系统需求和资源变化,持续满足性能需求的能力。可伸缩性测试系统需要关注变化的系统需求和资源与系统性能的关系,所以可伸缩性测试系统可以分为下面4个模块:

1. 工作负载分析模块:用于实时捕获和分析动态变化的工作负载。
1. 资源性能分析模块:用于实时分析底层不断变化的资源的性能。
1. 系统性能监视模块:用于在运行时捕获系统性能数据,以便进一步进行分析。
1. 可伸缩性分析模块:根据前3个模块实时捕获的数据来分析系统的可伸缩性。

STAS(Scalability Testing and Analysis System)是一个典型的系统级别的可伸缩性测试系统,它由4个部分组成:系统特征组件、算法预分析组件、可伸缩性测试组件和可伸缩性分析组件。STAS的特点在于它结合了算法的工作负载和最后的测试响应时间,结合负载和资源的情况对可伸缩性做出评估。同时STAS还支持测试人员自定义可伸缩性的测试方法。STAS的结构如图:

image-20230203212354855

​ 系统特征组件:其任务是获得底层系统的信息,并衡量每个节点的计算性能。它分为两个模块:系统信息探测模块和节点性能衡量模块。系统信息探测模块探测系统中的每一个节点,从中去除重复或不可用的节点,只保留活动的节点。对于活动的节点,节点性能衡量模块通过用户自定义的benchmark来衡量该节点的性能。最终这个模块的输出是二元组的集合: (节点名,性能)。

​ 算法预分析模块:它将分布式算法的源代码作为输入,输出可执行的文件和算法的工作负载分析。算法的工作负载分析可以在编译器编译时同时完成,也可以采用用户自定义的分析方式。用户通过指定工作负载和输入数据之间的公式来人为地衡量算法的负载。

​ 可伸缩性测试组件:它负责在运行时根据测试人员定义的方式测试系统和算法的可伸缩性。它由3个模块组成:被测试集生成模块、实时测量模块和数据库模块。被测试集生成模块从两个节点开始,每次将节点的规模扩大为上一次的两倍。被测试集和算法预分析模块得到的可执行文件与算法负载一并作为实时测量模块的输入,最终将测试执行的时问和这些参数一起存储到数据库模块,供分析组件进行分析。

​ 可伸缩性分析组件:它通过数据库模块中的数据,利用isospeed-e的定义来计算算法和系统的可伸缩性。

云计算背景下系统可伸缩性问题探讨

​ Saas(SoftwareasaService)是基于互联网提供软件服务的新软件应用模式,Saas为用户提供了完备的软件实现,用户通过互联网就可以访问服务,只需要按照自己的需求向提供商租赁服务,省去了购买硬件、开发软件和后期维护的费用。云计算是并行计算和分布式计算概念的发展,它能够为Saas提供可靠的基础设施。云是能够进行自我管理和维护的虚拟计算资源的集合。云计算拥有以下特点:

  1. 可伸缩性,云的规模可以动态地进行扩展和收缩,以满足用户变化的需求;
  2. 按需付费,用户可按自己实际的消耗来对购买的云资源进行付费;
  3. 超大规模,云计算的规模一般达到了几十万台服务器以上;
  4. 持久性,云计算系统能够为用户提供持久的计算资源和能力。这些不同于传统分布式和并行计算的特点,为云计算在可伸缩性方面的度量、设计和测试方面带来了新的挑战性问题。

云计算可伸缩性度量问题

​ 云的可伸缩性不仅仅注重传统的扩展性,也强调云的收缩性。它的重要特点之一即按需付费,让多个云的租户在共享云的计算资源时能够尽可能地节约费用。这就要求用户的应用在工作负载小的时候,能够把应用的资源消耗减少,在减少资源消耗的同时可以维持应用的性能,满足用户的需求。传统的可伸缩性更多着眼于代表了“伸”的可扩展性,在计算资源增加的情况下,衡量某一性能指标的增长率。与之相比,云计算同样也关注“缩”这一方面,即工作负载降低、应用性能依旧可以得到满足的情况下云能够回收的资源,提高资源的利用率,降低用户使用费用的能力。云计算的收缩性的度量不仅包括对资源增长带来的性能增长的度量,还包括对在负载减少时资源利用率提升程度的度量和用户费用减少的度量。

云计算可伸缩性设计问题

​ 云计算超大规模的特点使得在同一云计算平台中的资源数目变得极为庞大,其对资源管理系统的性能要求也越高。在中心调度和分布式调度两种模式中,当云的规模扩大时,中心调度的凋度器会成为系统的瓶颈。因此,分布式调度更适合云计算的范型。而分布式调度把决策工作分散到各个节点,降低了瓶颈出现的概率。与此同时产生了新的问题:资源分配是通过不同节点之间的沟通与协作进行的,多方协同的决策模式比中心式的决策更加复杂。

​ 在分布式调度中,设计多方协同的决策模式需要注意下面的问题。

​ 节点之间的异构问题:在超大规模的云计算系统中,会存在结构不同的资源节点。在对这些异构节点进行调度的时候,并不能直接操作这些异构节点,需要设计一个抽象的资源节点来屏蔽不同节点之间的差别,上层的操作只作用于抽象的资源节点。

​ 节点之问通信协议的设计问题:节点之间的协议规定了交换信息的格式和方式,而这些在节点之问交换的信息构成了调度算法做出决策的依据。在设计协议时,需要考虑到协议的准确性和完备性问题。准确性能够确保节点之问交换的信息是无差错的,而完备性能够确保协议能够囊括节点之间所有可能出现的信息交换场景,避免了因为缺少对某种场景的处理而出现错误。

云计算可伸缩性测试问题

​ 测试作为衡量系统伸缩性的基础,测试系统应该针对被测试系统的特点进行设计。云计算可伸缩性测试的系统应该拥有解决下面问题的能力:

  1. 实时监控的能力,云计算具有持久性的特点,而且无法对下一刻的工作负载、资源性能进行精确的估计,所以需要测试系统能实时地捕获这些数据,综合应用性能指标来分析云计算平台的可伸缩性;
  2. 双向测试的能力,相对于传统分布式计算只注重于扩展的能力,测试应该同时关注“伸”和“缩”两个方面,在不同的场景之下分析扩展性或者收缩性。当应用负载增加时,通过新分配资源的数目和应用性的提升来衡量扩展性能;在负载降低时,通过减少的资源消耗数目来计算衡量收缩性能。

结束语

可伸缩性作为云的一项重要属性,随着云计算和Saas的发展,它已经成为了当前研究的热点问题。可伸缩性的定义和度量方式也将随着不同的应用场景而改变。存云计算的背景下,可伸缩性的研究重点将集中在资源收缩时可伸缩性的定义和度量、基于异构资源节点的云资源分配和实时烈向的可伸缩性测量。


分布式系统架构调研
https://alexanderliu-creator.github.io/2023/01/28/fen-bu-shi-xi-tong-jia-gou-diao-yan/
作者
Alexander Liu
发布于
2023年1月28日
许可协议