需要了解的pssh(r11笔记第28天)

   昨天的一篇文章,关于ssh命令的几个使用小技巧(r11笔记第27天),也收到了不少朋友的反馈,其中有个朋友提议说还是用pssh吧,我想想也是。

    对于pssh早有耳闻,但是一直没有尝试用过。自己体验了一番,感觉确实不错,对于我们日常碰到的批量操作都可以胜任。当然还有很多可选方式,比如pgm,fabric,puppet,ansible等,只要能实现需求,怎么玩都是套路,而且也急不得,一个学明白了学其他的就会容易很多。

     关于pssh的p是什么含义,我和朋友还讨论过,到底是python还是parallel的意思,其实按照官网的意思是parallel,当然它是用python写的。查看官网目前较新的版本是2.3.1,可以参考如下链接:

https://pypi.python.org/pypi/pssh/2.3.1

下载得到的不是rpm包,而是一个tar.gz的包,解压以后,直接执行如下的命令即可完成安装的过程。

# python setup.py install

其实这个pssh还有很多附加的功能pscp,prsync,pslurp,pnuke等。

比如我们有几台服务器需要做一些相同的检查。

服务器列表我们提供一个文件test.txt

10.12.133.125
10.12.2.102
10.12.2.32

比如想批量查看主机名的情况,那么执行的结果如下:

# pssh -h test.txt  -i "hostname"
[1] 17:41:44 [SUCCESS] 10.12.133.125
newtest.oracle.com
[2] 17:41:44 [SUCCESS] 10.12.2.102
bill_10.12.2.102_sx
[3] 17:41:44 [SUCCESS] 10.12.2.32
snewtest2.oracle.com

如果想先显示结果再显示检测情况,可以使用-P选项。

# pssh -h test.txt  -P "hostname"
10.12.133.125: newtest.oracle.com
[1] 17:42:08 [SUCCESS] 10.12.133.125
10.12.2.102: bill_10.12.2.102_sx
[2] 17:42:08 [SUCCESS] 10.12.2.102
10.12.2.32: snewtest2.oracle.com
[3] 17:42:08 [SUCCESS] 10.12.2.32

当然这只是开始,比如想查看一下服务器的uptime情况,超时时间为10秒,对于那些服务器访问不通的情况,情况就会大大改善。

# pssh -h test.txt -t 10  -i uptime

如果服务器有100台,使用如上的方式就会瞬间导致服务器的进程数暴增,如果成千上万台服务器,后果不堪设想,其实我们想让这个过程更平滑一下,那就是使用-p选项,指定并行进程数,比如指定并行进程数为20个,这样就是一个动态控制的过程。

# pssh -h test.txt -t 10 -p 20 -i uptime

如果服务器不算太多,可以使用传入变量的方式,而不适用IP列表。

#  pssh -H "10.12.133.125 10.12.2.32" -i uptime
[1] 23:22:35 [SUCCESS] 10.12.133.125
 23:19:59 up 268 days,  6:53,  0 users,  load average: 0.07, 0.10, 0.28
[2] 23:22:35 [SUCCESS] 10.12.2.32
 23:04:38 up 220 days,  8:43,  1 user,  load average: 0.22, 0.24, 0.25

大体的使用情况就是上面这样,基本达到的效果就是一个服务器能够通过ssh操作,那么放大到100台,1000台,从客户端来说操作复杂度没有太大的差别。

    pssh这个工具蛮有意思,在安装的目录下有个AUTHORS的文件,作者是两个。

# less AUTHORS
Andrew McNabb <amcnabb at mcnabbs.org>
Brent Chun <bnc at theether.org>  

而我自己也简单看了下pssh的实现代码,说实话,python还是小白,但是从Java学习的基础来看,有些代码大体还是能基本看懂,代码不是很长,所以我打印出来准备抽空好好看看。

    pssh的核心部分有几个文件,pssh和几个库文件,manage.py,task.py,psshutil.py,还有辅助的cli.py,color.py,askpass_client.py,askpass_server.py

简单总结了下,Andrew写了不少的内容,而且近些年的维护都是他。

# Copyright (c) 2009-2012, Andrew McNabb
manager.py
task.py
askpass_client.py
askpass_server.py

而早期的时候更多的内容是Brent来做,2009年左右交接给了Andrew,所以会看到共同作者。

# Copyright (c) 2009-2012, Andrew McNabb
# Copyright (c) 2003-2008, Brent N. Chun
psshutil.py
color.py
cli.py       可见一个开源的项目能够健康发展至今,还是离不开很多默默奉献的人。

这就印证了一句话:

想要走得快,请独行;要想走得远,请结伴而行

时间: 2024-09-19 17:06:30

需要了解的pssh(r11笔记第28天)的相关文章

用Oracle的眼光来学习MySQL 5.7的sys(下)(r11笔记第25天)

昨天写了篇分析sys的文章,用Oracle的眼光来学习MySQL 5.7的sys(上)(r11笔记第24天)收到了一些朋友的反馈,还不错,今天继续努力,再整理一篇. sys还是很有借鉴意义     今天还和同事偶然聊起sys schema的事情,我觉得有几个地方要值得借鉴. 1)原本需要结合information_schema,performance_schema查询的方式,现在有了视图的方式,显示更加直观 2)sys schema的有些功能在早期版本可能无从查起,或者很难查询,现在这些因为新版

MySQL Online DDL(二)(r11笔记第88天)

对于Online DDL,之前简单分析了一些场景MySQL中的Online DDL(第一篇)(r11笔记第3天),其实有一个很关键的点没提到,那就是online DDL的算法,目前有三个操作选项,default,inplace,copy可选 具体可以参考  https://dev.mysql.com/doc/refman/5.6/en/innodb-online-ddl.html > select count(*) from newtest; +----------+ | count(*) |

复杂SQL性能优化的剖析(二)(r11笔记第37天)

    昨天的一篇文章复杂SQL性能优化的剖析(一)(r11笔记第36天) 分析了一个SQL语句导致的性能问题,问题也算暂时告一段落,因为这个语句的执行频率是10分钟左右,所以优化后(大概是2秒左右,需要下周再次确认)的提升很大.    对于优化是一个持续的改进,我们碰到的问题,最终的原因可能五花八门,但是正如柯南所说,真相只有一个.我把这个问题和前几天处理的一个问题结合起来,前几天处理了一个紧急问题,也是有一个SQL语句的执行计划发生改变,这个语句的业务比较关键,触发频率是每分钟一次,如果一旦

百倍性能的PL/SQL优化案例(r11笔记第13天)

我相信你是被百倍性能的字样吸引了,不过我所想侧重的是优化的思路,这个比优化技巧更重要,而结果嘛,其实我不希望说成是百倍提升,""自黑""一下.     有一个真实想法和大家讨论一下,就是一个SQL语句如果原本运行20秒,优化到了1秒,性能提升该说是20倍还是提高了95%.当然还见过一种说法,一条SQL语句每次运行20秒,每天运行100次,优化后每次运行1秒,运行还是100次,那么性能提升是说成优化累计时间为100*20-100=1990秒? 好了,我们来看看PL/S

闪回原理测试(二)(r11笔记第23天)

    对于闪回部分,Oracle本身提供了非常多相关的特性,我个人对于闪回数据库这个特性最为喜爱,尤其是应用再Data Guard环境中,真是一大杀器.     而对于DML的闪回部分其实也相对比较容易理解,毕竟就是原操作的逆操作,之前通过logminer的方式来读取redo来间接得以印证.Oracle闪回原理-Logminer解读redo(r11笔记第17天)     但是对于DDL的闪回,这个特性真是非常强悍了.比如一个truncate操作,它的逆操作改怎么定义,就很难去界定了.当然这个里

一个SQL性能问题的优化探索(二)(r11笔记第38天)

继续前几天的一个案例一个SQL性能问题的优化探索(一)(r11笔记第33天) 如下的SQL语句存在索引字段CARD_NO,但是执行的时候却走了全表扫描,因为这是一个核心表,数据量很大,导致数据库负载很高. SQL_FULLTEXT ---------------------------------------------------------------------------------------------------- SELECT ID,CN,CARD_NO,TO_CHAR(CHAR

insert导致的性能问题大排查(r11笔记第26天)

今天开发的同学小窗口消息给我,向我咨询一个ORA错误的问题. 错误代码是ORA-30036,使用oerr ora 30036查看,由于是undo空间无法扩展导致. 这是一个统计业务的数据库,而且平时的负载其实并不高,确实有一些奇怪.首先排除了大事务导致的原因,查看数据库日志,和开发同学沟通,没有发现相关的错误信息. 所以第一感觉这是一个偶然发生的情况,不过开发的这位同学貌似碰到了问题,他说从应用端抛出了ORA-30036的错误. java.sql.BatchUpdateException:ORA

Data Guard实现故障自动切换(二)(r11笔记第39天)

   今天下午我的一个朋友碰到了一个Data Guard的问题,大体是主备网络出现问题,因为环境中配置了自动切换,结果备库就自动切换为了主库,这样就成了"双主",我帮忙看了下,对备库做了闪回,然后直接转换主库为备库角色,一个看似繁琐的修复工作就完成了.    在一个一主多备的环境中,的确需要一个强大的工具来支持,所以最后朋友说DG Broker真是个好东西,我回了句 用好了DG Broker,手工管理Data Guard就是小米加步枪啊.    就如同我昨天文章Data Guard故障

Oracle 12c中JOB运行失败的简单处理(r11笔记第66天)

在之前简单分析过一个12c中数据字典的小问题. Oracle 12c数据字典的小问题(r11笔记第49天) 最近查看邮件,12c的一个PDB还是存在JOB运行异常的情况,因为是测试环境,不是业务类的JOB,这个问题就给了我一些时间来修复. 首先因为数据字典cdb_scheduler_job_run_details的问题,还不能一下子就查出数据.我们分阶段来完成这个工作,即分成几条SQL语句来查. 首先查看PDB中的JOB执行情况.可以看到con_id=8的PDB存在失败的JOB SQL> sel