saltstack-2

slat-ssh介绍

 

 

1. salt-ssh是 0.17.0 新引入的一个功能，不需要minion对客户端进行管理，也可以不需要master；salt-ssh也支持salt大部分的功能：比如grains,modules,state等；salt-ssh没有使用ZeroMQ的通信架构，执行是串行模式

salt-ssh执行原理

 

 

1. salt-ssh是在salt基础上打了一个python包上传到客户端的默认tmp目录下, 在客户端上面解压并执行返回结果,最后删除tmp上传的临时文件。
3. salt-minion方法是salt-mater先执行语法验证，验证通过后发送到minion，minion收到Msater的状态文件默认保存在/var/cache/salt/minion

salt-ssh执行过程


问题：什么叫异步，并发，并行，串行？

 

 

 

 

 

 

案例：证实salt-ssh使用的tcp一对一结对通讯

 

 

salt-ssh的原理, 依然是在远程环境中运行salt-call命令，此时远程机器已经被部署了 salt运行环境。这样salt的很多特性和模块功能可以在本地调用。运行的结果用过ssh协议 返回给salt

 

 

ZeroMQ消息队列

 

 

1. ZMQ是一个简单好用的传输层，像框架一样的的一个socket library，它使得Socket编程更加简单、简洁和性能更高。它是一个消息处理队列库，可在多线程、内核和主机盒之间弹性伸缩。ZMQ的明确目标是“成为标准网络协议栈的一部分，之后进入Linux内核”。现在还未看到它们的成功，但是，它无疑是极具前景的、并且是人们更加需要的“传统”BSD套接字之上的一层封装。ZMQ让编写高性能网络应用程序极为简单和有趣。

两种基本模式（它有很多种）

 

 

  1. 订阅发布模式 （sub 和 pub）

 

 

发布-订阅”模式下，“发布者”绑定一个指定的地址，例如“192.168.233.132：4505”，“订阅者”连接到该地址。该模式下消息流是单向的，只允许从“发布者”流向“订阅者”。且“发布者”只管发消息，不理会是否存在“订阅者”。上图只是“发布-订阅”的最基本的模型，一个“发布者”可以拥有多个订阅者，同样的，一个“订阅者”也可订阅多个发布者。

 

 

1. Salt Master运行两个网络服务，其中一个是ZeroMQ Pub系统，默认监听4505端口，可以通过修改/etc/salt/master配置文件的publish_port参数设置，它是salt的消息发布系统，如果查看4505端口，会发现所有Minion连接到Master的4505端口，TCP状态持续保持为ESTABLISHED。

2. 请求应答模式（req 和 rep）

 

 

消息双向的，有来有往，req端请求的消息，rep端必须答复给req端

 

 

1. Salt Master运行的第二个网络服务就是ZeroMQ REP系统，默认监听4506端口，可以通过修改/etc/salt/master配置文件的ret_port参数设置，他是salt客户端与服务端通信的端口，比如说Minion执行某个命令后的返回值就是发送Master的4506这个REP端口。

 

 

消息流向: req->router->dealer->rep

 

 

1. 1、router
2. router 接受来自 req 的请求
3. router 接受客户端的请求后，进一步封装后扔给 dealer
5. 2、dealer
6. dealer 连接 rep
7. rep 需链接到 dealer

dealer 会把任务分发给 rep, 同时非阻塞方式接受它们的响应。最后通过 router 返回给 req
总结：
4506：salt-master Ret接口，支持认证（auth）、文件服务、结果收集功能；
4505：salt-mater Pub接口，提供远程执行命令发送功能；

 

 

 

 

通过以上对比，salt-ssh对比salt minion缺点

 

 

1. 1、 salt-ssh建立tcp连接以后，会发送一个压缩包到客户端，压缩包里面包含一些常用的salt-call的模块，然后解压缩后再在本地执行salt-call 。
3. salt master会采用pub接口发送执行命令，由于本身salt-minion客户端在安装的时候，就已经预装了salt的大部分模块，所以无需部署salt环境，直接调用模块。
4. 从这一点上看，salt的c/s架构比salt-ssh快
6. 2、 salt-ssh采用的是一对一结对通讯，每次操作都需要重新建立tcp连接。也就是传统的tcp socket模型，也就意味着，你的roster文件里，有多少台服务器，salt-ssh就会生成多少对salt-ssh工作进程进行连接。
8. salt c\s架构，默认使用的是zeroMQ 消息队列，当salt minion客户端一旦启动与master建立连接时，salt master和minion启动workers一直处于监听状态，同时zeroMQ是异步处理，发布者在发起连接请求时，发布者可以同时发送学多条息。
9. 从这一点上看，数量越多的时候，salt-ssh速度越慢于salt c/s结构
11. 3、 salt-ssh没有采用消息队列模式，所以当目标主机执行完时，通过ssh建立起的连接返回执行结果。由此可见，当数量过多时，同时返回过多消息是容易形成堵塞，延迟。
13. salt c\s架构，默认使用的是zeroMQ 消息队列，可以处理海量的请求，为了防止拥堵，dealer 会把任务分发给 rep, 同时非阻塞方式接受它们的响应。最后通过 router 返回给 req ，由此可见，salt c/s架构面对多消息请求时，更稳定，较之salt-ssh更快