猛犸系统

目录

• 前言
• 猛犸系统特点
• 猛犸抽象分层
• 猛犸原型
• 猛犸如何和已知应用交互
• 猛犸如何提供高可用存储支持组件
• 猛犸打通应用集群和大数据集群

前言

统一的，高效的分布式系统诞生的条件已经成熟：

1. 资源管理/调度系统。资源模型取代传统的服务器模型。
2. 容器技术。
   • 单机上混跑任务互不干扰
   • 应用与服务器互不依赖
3. 分布式协调组件，例如Zookeeper，消息队列等的成熟

猛犸则是基于这些组件之上构建的分布式，大数据/传统应用部署运维平台。

猛犸的特点

猛犸提供了一个一致统一的大数据以及相关应用的部署，运维平台。

1. 猛犸是可编程的。意味着你可以开发一套组件增强系统的功能，然后进行安装而不需要修改系统的内核。

2. 猛犸简化大数据平台部署，加快产品落地，真正撸起袖子即可快速构建平台进行数据处理

3. 猛犸统一了应用和组件的概念，使用者只需要了解两类应用：

   • 系统组件(Framework)，用来增强系统的功能。典型如动态扩容等功能。
   • 应用程序(APP)，实际业务系统

4. 支持App Store. 所有应用都是APP,部署过程就是APP的安装过程，和现在的单机系统保持了高度一致。即使没接触过猛犸的人也能轻而易举的部署一个可以服务成千上万人的业务系统。

5. 基于资源模型的部署组件允许你上传一个.image文件(Docker镜像)，指定资源占用量以及实例数即可完成所有部署

6. 猛犸解决容器跨机器通讯问题

7. 猛犸提供的应用自我修复机制可以使得应用总是运行在用户期望的状态，譬如维持恒定的用户规定的实例数，资源要求等。

8. 猛犸自身是极度易于部署，不依赖单机操作系统或者本地库

9. 猛犸的交互应该是区分人机交互和系统之间交互。人机交互应当提供一个友好的web界面，而系统之间交互应该提供一个良好的沟通API.

10.猛犸也支持通过分布式Shell引擎支持传统的服务器模式。并且资源模型和传统的服务器模式同时并存，解决各自擅长的问题

猛犸抽象分层

2.png

猛犸由5层构成，类似传统的单机操作系统：

1. 交互层

   • 外部服务调用，类似单机的IP/Port定位，分布式操作系统通过封装 Nginx/Haproxy 实现。
   • 人机交互界面，类似单机的Shell终端，通过Web化界面实现。

2. 应用层

   • 支持.tar.gz, .image, .git 三种文件的安装。在分布式系统中，用户看到的一切，要么是APP,要么是Framework,他们都可以以规范的方式安装进分布式系统。APP就是属于应用层。而Framework则属于系统级组件，对应用层提供各种隐形功能支持。
   • 以Docker为进程模型进行运行。基于服务器的传统部署组件(Framework) 允许采用其他进程模型，譬如裸机上直接运行一个Java程序。
   • 进程支持异步或者同步同步通讯，通过系统封装的Zookeeper API 来实现协调。

3. 系统服务层

   • 部署：基于服务器的传统部署组件(基于内核分布式Shell引擎开发的Framework)；基于资源的部署组件(基于内核Yarn开发的Framework)
   • 应用稳定性支持，基于资源的部署可保证服务实例的数量，保持对所需资源的占用。
   • 存储稳定性支持。实现实现MySQL,Redis这种单Master的高可用性，保证存储的稳定。而类似HBase,Cassandra这些服务本身已经实现了高可用性，不需要分布式系统的系统服务来支撑。
   • 对应用提供依赖性API.譬如安装Hadoop时，需要以来Zookeeper,安装程序可直接调用系统查询是否有可以使用Zookeeper.

4. 文件系统

   • HDFS分布式文件系统
   • MySQL高可用支持事务的存储引擎
   • Redis高可用缓存组件
   • HBase高可用KV存储组件

5. 内核层(Borg)

   • 集成分布式Shell引擎
   • 集成Yarn资源管理引擎

现在，单机和分布式操作系统结构得到了完美统一，下面是单机操作系统：

1.png

猛犸原型系统

mammuthus.png

从架构图中可以看到，这是一个典型的master-salve结构。

Master 进程包含三个大的模块：

1. ResourceManager.资源模型的管理和调度中心。基于Yarn封装的一套组件。
2. CommandEngine，命令系统，服务器模型的中枢模块。该模块通过Akka可以向Slave的ShellEngine发布任何Shell脚本指令。
3. APPEngine,APP部署支持，APP信息存储查询等。提供了一系列功能方便管理Slave以及和Web进行交互。譬如安装部署解析引擎可根据配置为特定应生成安装页面，手机安装信息。

Slave进程:

1. NodeManager. 对特定服务器进行资源管理的核心模块。该模块 基于Yarn封装。
2. ShellEngine. 在Slave上执行各种Shell脚本。支持阻塞，异步模式。
3. ConfEngine. 如果系统发现用户安装了Zookeeper,则会请求确认开启，从而支持配置文件管理。配合Web端，可以对各个系统的文件进行可视化管理，比如/etc/hosts文件等。

Web Console:

猛犸的默认交互端。通过该Console可以进行应用安装，管理等。

通讯协议：

调用者	服务者	协议
Web Console	Master	HTTP
CommandEngine	ShellEngine	AKKA
ResourceManager	NodeManager	HADOOP RPC

猛犸系统透过APPEngine支持两种应用/资源管理模式：

1. 服务器模型。 也就是传统的‘指定服务器’部署模式。APPEngine默认透过CommandEngine做这种支持。基本步骤为：

   1. 上传安装包
   2. 选择服务器
   3. 收集参数
   4. 生成配置文件
   5. 分发安装包
   6. 安装
   7. 进入管理界面

对于不是很复杂的系统，比如flume之类的，则只需要在根目录里按格式要求放一个两三行的脚本，分布式系统便能够完成安装，启动，关闭，监控进程存活等功能。

而如果像Hadoop这么复杂的应用，目前猛犸直接默认提供支持，从官方下载tar.gz包上传即可安装。Hadoop/Zookeeper的安装已经简化到只需要选择机器即可完成一个任意规模的集群。后续可以通过配置管理系统重新编辑相应的配置文件从而优化集群性能。
如果用户开发的应用非常复杂，而猛犸默认的安装规则不足以满足要求的话，则可在安装包的根目录放一个json描述文件，系统会根据该json描述文件自动调整页面中的安装流程。不会对原有程序有侵入。

安装完之后会自动通知LoadBalance 以及注册中心(Zookeeper).

这种方式适合带有存储类的应用。譬如搜索，MySQL,HDFS等。

应用的安装信息并不会存储在master上，而是存储在每台Slave上。由Slave通过心跳上报到Master端。静态模型中，Master是完全无状态的。

安装成功后，透过Web Console可对应用进行生命周期管理，譬如关闭，开启等。同时对每个应用，用户可以在Web Console中浏览整个目录。

对于更新操作，用户可以在界面先停一部分服务，然后对这些服务重新走安装程序。接着按同样的方式对第二批服务进行操作，直到所有服务都是最新版本的。

2. 资源模型

该模式下，所有资源由Yarn内核进行动态分配管理。我们提供了一个DynamicDeploy的系统组件(猛犸单独开发的一个组件，用户通过Web Console上传后自动便会开启该功能)。

如果用户在部署过程中选择动态部署，那么用户有两种选择：

1. 纯Java程序(.tar.gz后缀文件)
2. 容器(.image后缀文件)

猛犸在该种模式下，对容器没有任何要求，只要能Run起来就行。而如果是Java程序，则该程序启动过程中，必须使用分布式系统给予的端口，而不能自定义端口。

当用部署时，AppEngine会将安装包提交给DynamicDeploy，DynamicDeploy会按下面的流程进行处理：

1. DynamicDeploy向ResourceManager模块提交资源资源申请，ResourceManager启动ApplicationMaster
   3. ApplicationMaster启动DynamicDeploy的Driver(Master)
   4. ApplicationMaster向Resource Manager申请资源，Resource Manager根据集群资源情况为其分配YARN Container，
   5. 这些Container会连接Driver。Driver发布启动指令给各个Container.Container会执行download image,load image,run image 三部分指令
   6. run指令会自动添加cpu,内存，磁盘配额。并且给Docker的容器配置一个随机端口
   7. Container会将Docker容器的IP,端口上报给Driver,Driver会将这些发送给APPEngine.
   8. APPEngine会把通知发送给LoadBalance 以及注册中心(Zookeeper)
   9. 完成部署

部署完成后，DynamicDeploy会保证：

1. 如果有服务实例当掉，DynamicDeploy会检测到，并且在找到合适的服务器重新启动该实例。也就是DynamicDeploy会保证实例的个数稳定不变。
2. DynamicDeploy 对自身提供 FailOver机制

• 如果是Driver挂掉，并不会影响正在运行的服务。直到分布式系统进行多次尝试仍然无法启动DynamicDeploy Driver,才会出现服务Fail的情况。
• 如果是伴生进程挂掉，则猛犸有两套机制保证用户的进程不会成为‘没人管’的进程。
  首先伴生进程如果不是JVM crash掉了，会自动将用户进程杀掉。Driver然后会在其他服务器重新调度，保证实例数不变。如果是JVM crash掉来不及做清理工作，Driver会监听心跳，一定时间内会将该信息发布给猛犸，猛犸会通过分布式Shell引擎来完成最后的清理工作。

更新操作中，灰度更新变得很简单，在Web Console中重新部署一套服务，该服务会根据LoadBalance策略，或者和原来的服务同时对外提供，或者保证只有旧的服务被关停后新的服务才能对外提供服务。

猛犸原型目前已经实现了分布式系统特性中的绝大部分。在Agent内核中同时支持分布式Shell引擎以及Yarn内核使得他们可以进行互补。

分布式操作系统如何现存应用进行交互

在软件行业，兼容现存的应用显得尤为重要，是决定一个平台系统能够存活的关键指标。容器技术使得所有应用可以被操作系统运行起来。并且可以吻合Yarn内核对资源控制的要求。但是我们可能需要对被容器包括起来应用更细致的控制。

我们先来看两个概念。

1. 哑应用

所谓哑应用指的是无法和分布式系统直接进行交互，分布式系统也仅仅透过容器能进行生命周期的控制，比如关闭或者开启的应用。典型的比如MySQL,Nginx等这些基础应用。他们一般有自己特有的交互方式，譬如命令行或者socket协议或者HTTP协议。

2. 伴生组件

因为有了哑应用的存在，操作系统为了能够和这些应用交互，所以有了伴生组件的存在。这些伴生组件和哑应用具有相同的生命周期。伴生组件其实是哑应用的Proxy,从而使得哑应用可以和分布式系统进行交流。典型的比如，某个服务被关停后，该事件会被操作系统获知，操作系统会将该事件发送给Nginx的伴生组件，伴生组件转化为Nginx能够识别的指令，将停止的服务从Nginx的ProxyBackend列表中剔除。

如果我们只需要对应用进行生命周期控制，而你的应用是基于容器的，那么我们只要分布式系统默认提供的伴生组件即可完成大部分功能需求。

• 基于资源的部署方式，需要你将应用容器化，或者如果你的应用是一个Java程序,则能够接受分布式系统提供的端口作为自己对外服务的端口，也可以被调度，然而，存在的另外一个风险是，对CPU的控制会比较困难。
• 基于传统服务器模式的部署方式，则并不强制要求容器化，我们提供封装了一套完善的Shell脚本引擎，你只要填写两到三行指令就可以完成完成分布式系统对对应应用的生命周期管理。对应用没有任何改动。然而，你需要自己解决应用本身对裸服务器的环境以来，譬如某些本地库。

猛犸中的DynamicDeploy是一个基于Yarn调度容器的Framework,也就是说属于系统组件。而DynamicDeploy的Slave同时也属于Docker的伴生组件，可以对Docker容器进行交互。指令发给DynamicDeploy的Master,Master将其转发给Slave,Slave转化成Docker能够识别的内容进行操作。

同时对于LoaderBalance,猛犸默认提供了MammuthusNginx伴生对象。

这些组件都是以标准的方式进行安装即可。

高可用存储支持组件

在分布式操作系统中，可提供分布式文件系统(HDFS),也可以提供‘硬件级别’的磁盘，还有高层次支持事务的MySQL集群，高速缓存Redis集群，优秀的KeyValue存储 HBase等。对于这些的支持，我们正在开发相应的组件进行支持。

在分布式系统中可以保证：

1. 这些存储以组件的形态供用户安装
2. 这些组件安装完成后，自动会获得高可用支持

这里，以MySQL为例，在分布式操作系统中是如何实现高可用的呢？

分布式操作系统中，MySQL 以容器状态运行，文件通过Volumn挂载在实际磁盘中，实现单Master多Slave结构，我们称之为一个Cluster,系统允许多个Cluster存在。

值得注意的是，MySQL这些信息都会在系统的注册表中找到。

我们开发了一套伴生组件，该组件是专门监控这种单Master节点类型的系统，一旦安装了MySQL,系统会自动启用该组件，定时监控Master的可用性，一旦发现Master不可以用，则找到数据最新的Slave，提升为Master,并且变更注册表信息(如IP,端口等)，所有使用该MySQL的服务组件都会得到通知，从而实现动态变更。

这里有一个可能的问题是，如果某些应用并不接受这种变更通知。最透明的方式将会是使用IP漂移技术。
如果并不希望使用类似IP漂移技术，则一个比较直观的方式，通过某种途径，修改使用了该MySQL的应用的配置文件(这个是难点，如何修改？)，并且将该重启该应用(cluster,可以rolling restart),到现阶段位置，目前这套机制并没实现。

同理，Redis Cluster也是通过相同的方式实现高可用。

猛犸打通应用集群和大数据集群

在猛犸(也就是您正在看的系统)里，所有资源包括大数据集群和应用服务器集群都是被统一管理的(你也可以安装两套猛犸单独管理)，所以其实大数据集群资源和应用集群资源是可以互相出让的。比如晚上应用使用的少，但是大数据集群非常繁忙，猛犸可以把部分计算资源让出来，给数据集群。反之白天则相反。目前大部分公司部署上都是独立的，大数据是大数据的机器，应用是应用的机器，而如果统一使用猛犸，可以打破这种界限。