ITPub博客

运维中的接入管理梳理

原创 IT综合 作者:jeanron100 时间:2018-04-21 21:59:08 0 删除 编辑

关于接入管理,之前是想做成接口型,通过配置组合起来,实现灵活的调用方案。

当时画了一个概要的图。

运维中的接入管理梳理

如果把上面的路径和技术序列联系起来,就可能是下面的一些解决方案。

ops_to_cm ssh,paramiko,ansible_adhoc
cm_to_host ssh,paramiko,ansible_adhoc
host_to_db command,pymysql,mysqldb
cm_to_db ssh,pymysql,mysqldb
ops_to_db pymysql,mysqldb
ops_to_host ssh,paramiko,ansible_adhoc

接入方式提炼出两点:

系统层接入:

paramiko和ansible_adhoc

数据库接入

pymysql,mysqldb

在这个基础上,进行进一层的提炼,接入管理提炼出两点:

数据库层的接入可以提炼出DAO层,通过工厂模式来提供灵活的配置接入,这会是一个通用的接口,同时其他数据库的接入也可以通过这种方式带来接入,提炼的结果就是对于数据库类型和接入方式,即可完成数据库的接入管理,比如MySQL,我只需要输入mysql.mysqldb的方式即可通过mysqldb库的方式接入MySQL

同理系统层的接入是类似的情况,目前可以暂采用paramiko和ansible_adhoc两个选项即可。

至于上层的接入路径如何串联,按照通用的思路:

ops到db的路径,目前只有三类

1)ops_to_cm,cm_to_host,host_to_db

2)ops_to_cm,cm_to_db

3)ops_to_db

而同理ops到host的路径,只有以下几类:

1)ops_to_cm,cm_to_host

2)ops_to_host

最后还有第三类,是host_to_db

如果是没有一个完整的路径分析,可能得到的路径不是很完整。

这些其实就跟管理层的工作类似,需要根据实际的情况和配置来得到一个最优路径,然后由具体的任务层来负责执行。

所以上面的思路抽象之后,就是得到接入路径,然后执行接入任务。

这只能算是刚刚开始吧,还有几个问题需要弄明白。

比如ops_to_db的路径有三个,拿第一个来说,

1)ops_to_cm,cm_to_host,host_to_db

如果是最后的执行节点,host_to_db,如果使用pymysql,mysqldb两种执行方式,那么相应的库文件需要在host层面具备,而ops,cm端只是调用而已。

而如果是第三个

3)ops_to_db

则只需要保证ops端具有完整的库文件即可。

所以第一种路径太深,而且对于目标端的环境依赖要重一些,相对来说是不大推荐的。

第三种,需要ops端具有直连的权限,能够直接访问数据库,则ops端需要配备完善的接入管理。这个不能说不合理,只是对于ops来说会相对重一些。

那么第二种相对而言是比较好的,我们基于中控端去做,支持命令方式和驱动方式,中控端的配置对于所有的其他服务器都是适用的,这样我们能够基本达到中控的一个基本需求,这个算是对需求的收敛吧。

所以对于这个基本的接入管理需求,会分为:系统接入管理和数据库接入管理,映射到这个场景中,就是如下的一个初步选择

2)ops_to_cm,cm_to_db

上一篇: TiDB测试小结
请登录后发表评论 登录
全部评论

注册时间:2012-05-14

  • 博文量
    1667
  • 访问量
    14185660