saltstack高可用架构设计

少于 1 分钟阅读

Contact me

或者用邮件交流 jacky.wucheng@foxmail.com

一、待解决问题

  1. Master负责的Minion数量过多，并发消息量过大，导致Master过载而丢消息

  2. 如果使用MultiMaster模式，会导致Minion跟Master跨机房通信

  3. 如果使用Syndic会导致MOM(MasterOfMaster)无法感知存活的Minion

  4. Salt-API没有身份鉴定，命令审核功能

    ​

二、解决方案

MultiMaster架构

为了解决如上问题，根据官方Saltstack的高可用架构的描述，我们选择了MultiMaster-With-Failover模式作为基础，在此基础之上扩展出了MultiMaster-With-Failover-With-Proxy模式。此处我们将Syndic替换成自研的Proxy。

salt高可用架构

我们的架构中，同一个机房部署多台Master，Minion使用master_type: failover和 master_shuffle=True的方式随机连接本机房其中一个Master，并且让Minion根据master_alive_interval 定期检查所连Master的健康状态，发现当前Master故障后会自动连接其他Master实现Failover。

优点：该方案可以使得

  1. Minion跟Master之间的通信不跨机房
  2. 一个Minion同时只跟一个Master保持连接，避免了重复接收命令的问题，并且高可用
  3. 通过水平扩展Master，使得Master和Minion的配比保持在一个合理的范围，分散了单个Master的压力

开发Proxy

为了实现如上的架构，我们还需要开发Proxy来替换Syndic，对Proxy的需求有

  1. 部署在Master机器上，负责从消息管道Subscribe消息，匹配规则，匹配通过后转给本地的Master进而发送给Minion，不匹配则丢弃，规则有
    1. 如果使用minion id精确匹配，那么Minion需要与本Master直接相连
    2. 如果使用list、glob、regex等方式，则对连接本Master的Minion进行匹配计算，需要至少匹配到一个
    3. 待续
  2. 将Minion返回给Master的执行结果写入中心的Database保存
  3. 定期（如每10s）向Connector汇报本机Master所连接的Minion的连通性状态

优点：该方案可以使得

  1. 尽可能减少无用命令的下发
  2. 全局知晓Minion的连通性
  3. 通过MQ将Connector跟Proxy进行解耦，Proxy也可以水平扩展，Connector也可以

开发Connector

对Connector的需求有

  1. 以HTTP协议接收用户请求的命令，兼容原生Salt-API的接口格式
    1. 支持高并发
    2. 支持用户身份鉴定
    3. 支持调用方IP白名单
    4. 支持命令内容检查
    5. 支持限流，1分钟内调用不超过N次，可配
    6. 除了特权用户，其他用户匹配Minion不能用*，批量不超过30，可配
  2. 将命令Publish到MQ中，等待Proxy来Subscribe
  3. 接收来自所有Proxy的Minion连通状态数据，维护在状态表里，对于精确匹配和List匹配Minion id的API调用，如果其中有失联的Minion，根据用户参数决定是拒绝请求还是接受，如接受，则在返回结果里注明失联

优点：该方案使得

  1. Connector可以水平扩展
  2. Connector提供了更强的认证和审查机制

如何从日志中找出问题？

通过Flume将Proxy日志，Master日志，Minion日志，Connector日志统一采集汇总到ES

  1. 被动模式：实时将错误日志通过邮件发送给开发人员进行问题排查
  2. 主动模式：开发人员通过Kibana过滤错误日志进行问题排查

猜您还喜欢