一种基于ipmi和Pacemaker的集群整体关机的设计方案

集群一键关闭设计总结

运行条件

  • Daemon插件正常运行,且PCS集群运行正常;

  • Web页面能够正常打开,httpd组件运行正常;

  • impi正确部署,且功能开启;

需求分析

需求分解

Web前端提供集群关闭按钮

在Web前端页面增加[集群关闭]按钮,点击即可关闭集群;

集群基本信息反馈

在执行集群关闭时,能够确认当前关闭的节点的数量;

故障节点处理

在关闭集群时,集群中可能会有部分节点因为故障处于离线状态,在集群关闭时,控制节点会尝试通过ipmi来访问节点电源状态,并对power status处于on状态的节点发送impi关机请求。

节点关机失败处理

关闭流程中不收集节点是否关机失败的信息,如果部分节点关机失败,则需要人工介入。

不支持场景

  1. pacemaker、daemon模块为能正确部署,或现场两者无法正常工作;

  2. Web页面无法打开,管理员无法登陆;

  3. ipmi未部署。

功能设计

Web前端设计

略。

后端程序设计

概述

基于集群中不同节点的不同角色,分批次下达ipmi关机指令,完成集群关闭功能。

方案论证
  1. Daemon作用,是否直接依赖Daemon完成整个集群的关机

    • Daemon接受前端restful请求,且当半数以上控制节点处于离线状态时,Pacemaker集群下线,从而systemd使本地节点的Daemon服务下线,不能成功下发impi关机指令。故Daemon可以发送关机信号,不能直接完成关机动作。
  2. 独立关机程序控制关机指令下发

    • 使用独立的本地关机轮询程序完成ipmi关机指令的下发。这些关机检测程序运行于每个控制节点。当Web的restful请求经由flask框架路由至其中一个控制节点时,该控制节点的Daemon接受该请求,检测满足关机条件之后,通过某种方式来通知关机检测程序进行关机。
  3. 两者通信实现?

    • 目前的方案有两种:第一种是使用套接字(socket)进行进程间通信;第二种是通过读写同一文件完成信息交换,这里采用新建并写入某一文件来完成信息的交流。
  4. 独立关机程序管理?

    • 通过systemd管理。
功能架构
集群关闭功能设计架构
关机次序设计
节点类型 关机批次
计算节点 第一批
远程控制节点(非接受Web请求节点) 第二批
本地控制节点(接受Web请求节点) 第三批

</figure>

模块流程

Daemon完成的操作有

  1. 接受路由自集群的Web请求;
  1. 检测平台是否成功部署集群一键关闭功能,若否,返回错误信息;
  1. 手机集群节点信息;
  1. 创建集群信息文件cluster_shutdown_nodes_tmp.json节点信息,并写入;
  1. 写入完成后,将文件重命名为cluster_shutdown_nodes.json文件

注1: 成功部署集群一键关闭功能条件:相关配置文件中ipmi配置开启,一键关闭集群功能开启。

注2:为了防止写入时关键检查程序恰好访问集群信息文件,造成错误,故写入时命名为临时文件,写入完成之后才命名为目标文件。

集群关机检测程序完成的操作有

  1. 检测cluster_shutdown_nodes.json文件是否存在;
  1. 读取cluster_shutdown_nodes.json中集群节点信息;
  1. 删除cluster_shutdown_nodes.json;
  1. 分批次发送ipmi指令,完成关机。

配置文件路径选择

/var/run目录中内容会在系统启动的时候清空,为了防止意外集群关机检测程序未能成功删除集群信息文件(如执行集群关机操作时接收节点突然掉电),而在重启后集群关机程序继续关闭集群,将该文件放在/var/run目录下。

对外接口设计(restful)
Name 一键关闭集群
Method PUT
Version V1
Url ${version}/maintenance/devices/nodes?action=shutdown
Curl Curl -XGET -H "X-Auth-Token: xxx" http://ip:port/$version/maintainance/devices/nodes?action=shutdown

请求参数说明

name in type required description
X-Auth_Token header string YES 用户认证有效的Token
涉及的CLI封装
# ipmi 电源状态查看
ipmitool -I lan -U ADMIN -P ADMIN -H x.x.x.x power status
# ipmi 软关机
ipmitool -I lan -U ADMIN -P ADMIN -H x.x.x.x power soft
# ipmi 硬关机
ipmitool -I lan -U ADMIN -P ADMIN -H x.x.x.x power off
# ipmi 硬重启
ipmitool -I lan -U ADMIN -P ADMIN -H x.x.x.x power reset
# ipmi 开机
ipmitool -I lan -U ADMIN -P ADMIN -H x.x.x.x power on

方案局限性

  • 当前方案的关机检测程序为后台轮询模式,相对消耗资源;

  • 不能收集反馈信息(哪些节点没有关闭);

  • 不能对软关机失败的节点采取进一步措施;

方案设计中需要注意的问题

  1. 首先应该明确需求和运行环境,分解需求,确认支持的工作场景;

  2. 在提出任何设计方案的时候,都需要先进行可行性验证,并做好记录;

  3. 遇到不熟悉的模块及时与相关人员沟通;

  4. 及时通知进度,如果出现延期风险,请及时告知,不要阻塞他人乃至整体的进度。

设计的技术点

  1. 产品Daemon模组的架构、Pacemaker的架构及特性;

  2. ipmi组件的架构、使用方法

  3. systemd的使用;

  4. Flask框架、restful接口(需要写映射文件、注册函数、url解析接口、动作接口)。

最后编辑于
©著作权归作者所有,转载或内容合作请联系作者
平台声明:文章内容(如有图片或视频亦包括在内)由作者上传并发布,文章内容仅代表作者本人观点,简书系信息发布平台,仅提供信息存储服务。

推荐阅读更多精彩内容