引擎安装管理.md

引擎节点管理模块文档

背景

引擎节点管理的需求最早可追溯到v1.0.x版本，当时是希望实现任意数量的节点管理构成一个集群，但是因为实现过程中遇到了一些无法解决的问题，故以一种很多限制的形式流传了下来。
限制有不少，其中最大的限制是：管理节点必须为奇数，且引擎一旦安装成功，管理节点无法以任何一种形式变更数量、机器、IP地址等。
管理节点的数量变更需求每个版本都会有人提起，现如今又正式提出了，故对现状和历史状态进行一次梳理，以便看清前路。

名词旧解释

• 引擎节点: 一般用来概括称呼管理节点、工作节点、调度节点，不同的类型的节点区别主要是运行的组件不同
• 节点添加：为一个全新的OS安装工作节点或调度节点的组件；或者为一个当前引擎其他节点添加工作节点或者调度节点的组件。
• agent: 是installer-sr-server的一部分，它是一个运行在引擎节点的服务，下文中，会将其称呼为installer-sr-agent

名词新解释

• 引擎节点：指一个机器，或者说一个OS上装了石犀引擎的情况下。和旧版的区别在于其不可分/不可共享性。
• 节点添加：为一个全新的OS安装引擎组件。
• agent：是一个类似边车引擎的东西，属于镜像引擎的需求一部分，下文中，会将其称呼为sr-agent

演变历史

目前installer-sr-server能追溯的最早代码位于release-v2.0.2分支，其核心功能是引擎组件的安装。对于节点添加的支持，仅支持工作节点的添加。其添加的实现非常简单，和安装是一致的。也就是说，为某个OS添加工作节点的实现为安装所有引擎组件（含非工作节点组件），通过设置systemd的enabled属性来控制是否运行某些组件。
后续版本添加了调度节点的节点添加，但是实现上和工作节点添加差异并不大。

在1.5版本中，对安装逻辑做了一次重构, 在去掉了installer-sr-agent之后，虽然安装的逻辑发生了较多的变化，但是从节点管理这部分逻辑来看，并没有本质变化。都是和引擎安装复用同一个函数，根据节点类型筛选出需要安装的组件列表，依次执行他们的安装脚本。

整体设计演变

原设计伪代码描述

// installer-sr-manager
func (s *Service)Install(req InstallReqParam){
    dbGlobalParam := dosomething(req)
    s.db.Save(dbGlobalParam)

    dbGlobalParam = s.db.Query(req.EngineID)
    http.PostRequest(install-sr-agent.ip:port, dbGlobalParam)
}


// installer-sr-agent
func (s *Service) Install(req GlobalParam) {
    // download files from manager
    http.GetRequest(installer-sr-manager.ip:port/download, req.PackageVersion)
    s.SaveLocalFile(packagePath,md5)

    // parse install config 
    installConfig := s.ParseConfig(req,enginePackage)
    
    for _, elem := range installConfig.ComponentList {
        elem.Install()
        if elem.Start {
            systemctlStart(elem)
        }
        if elem.Boot {
            systemctlEnable(elem)
        }

        s.SaveLocalFile(elem,installed)
        http.PostRequest(installer-sr-manager.ip:port/report, Progress++)
    }
}

1.5设计伪代码描述

1.5的版本里面，进度相关的表已经名存实亡，进度和取消由另外的机制来实现。

// installer-sr-manager
func (s *Service)Install(req InstallReqParam){
    dbGlobalParam := dosomething(req)
    s.db.Save(dbGlobalParam)

    dbGlobalParam = s.db.Query(req.EngineID)

    sshClient := sshv2.NewClientWithPwd(req)
    sshClient.Upload(req.enginePackage)

    for _, elem := range installConfig.ComponentList {
        // elem.Install() 
        grpc.PostRequest(webserver.Cmd, "mv $elem /opt/$elem")
        grpc.PostRequest(webserver.Cmd, "/opt/$elem/scripts/install.sh")
        s.db.Save(elem)
        progress++
    }
}


// webserver
func (s *Service) Cmd(req CmdParam) {
    cmd := exec.Command(req.Name,req.Args...)
    cmd.Run()
}

依赖问题

对于将引擎的组件按照类型分割成3部分，并且允许独立安装的做法，最需要考虑的问题是节点与节点间的依赖、组件与组件间的依赖问题。
工作节点安装时，其实可以认为是独立的，它不需要依赖管理节点或者调度节点的信息。
但是工作节点要想正常工作，那么调度节点就需要知道有哪些工作节点。为了解决信息同步的问题，SX-HA模块从最早开始就介入了节点管理模块，节点的变更的实现对SX-HA模块有较强的依赖，可以认为节点管理是SX-HA和installer-sr-server共同实现的。

SX-HA主要负责的部分其实是通过k8s+etcd来实现一个动态更新节点列表，并且动态下发配置，并将其称为节点发现模块。它的理念是：SX-HA模块运行时，往公共的注册中心注册自身的节点信息，通过注册中心来保持节点信息的一致性。通过watch机制，来感知注册中心信息的变化，然后更新自身节点的一些配置。
在之前的版本实现中，SX-HA还接管了etcd的启动配置生成，这是因为当时也对管理节点的添加删除做了一些尝试，但是以失败告终。

节点新增

1.5版本，节点新增支持调度节点新增和工作节点新增。
假设有以下引擎

所属引擎	IP	角色组合
A	1.1.1.1	M
A	1.1.1.2	MS
A	1.1.1.3	MW
B	1.1.1.100	MSW

它在manager的节点表中，记录如下

所属引擎	IP	角色枚举
A	1.1.1.1	M
A	1.1.1.2	M
A	1.1.1.2	S
A	1.1.1.3	M
A	1.1.1.3	W
B	1.1.1.100	M
B	1.1.1.100	S
B	1.1.1.100	W

对于引擎A，它可以通过<节点添加>接口来添加一个1.1.1.1 W（或者S）
过程为：
在节点表中，添加一条记录
| A | 1.1.1.1 | W |
然后将每个工作节点的组件都执行一次安装脚本（引擎包会重新传一遍过去）
添加完毕后，会调用SX-HA的结构通知一下，后续流程应该是SX-HA模块在处理。

节点删除

节点删除并没有什么特别的设计，同样是执行对应组件的脚本，然后通知SX-HA

节点替换

调度节点是没有替换的，只有工作节点支持替换

替换的流程是先在新的节点执行节点添加逻辑，然后在旧的节点执行节点删除逻辑。

1.6迭代思路

首先是节点表的定义和需求匹配度已经不够了，要么重新定义一张表，要么修改原有字段的含义，各有各的做法。不过我认为原来的表定义字段存在一些意义不明的字段，直接重设计可以省去理解上的时间。
管理节点的添加、删除应该是主要的障碍，目前没有研究过这方面。调度节点1.5没有支持替换，原因可能只有原开发（贺泽）知道