Docker关联使用的一些工具:Clip名字服务(转载)

Clip名字服务

Clip(http://blog.puppeter.com/read.php?7)是一个名字服务C/S架构,它将传统的IP管理维度替换为名字服务即有意义可记忆的String。Clip将IP对应的String关系保存在Server端。Client端可以下载SDK,通过SDK遍历Server端的String对应IP的关系,并在本地对获取的IP模块关系进行重新的组织与编排。传统服务器IP方式与String方式相比,String方式有3点优势:


    传统IP管理方式,IP由4组无意义的数字组成,比较难记忆。String更方便记忆;
    管理海量服务时,IP相似经常会导致运营故障,譬如A模块(10.131.24.37 )和B模块(10.117.24.37),后两组数字一致,系统惯性的认为B模块就是A模块,发送配置导致线上故障。通过string管理方式可以规避此问题;
    String 可以解析1个IP,也可以解析一组IP ,根据IP也可以反解析String对应关系,使得管理一组服务更加方便。


  Clip中的String由四段(字段含义idc-product-modules-group)组成,读者会发现String与Cmdb的结构很像:四级模块定位一个服务。但是为了充分利用资源我们的业务要求一个IP可能要对应多个服务,不同的服务有自己的波峰与波谷,在相同的IP上只要保证各业务的波峰不重叠就满足了业务的需求,也充分了利用资源。而在一台服务器上混合部署不同的业务模块,四级模块就只能定位到服务的IP级别,而无法精确定位到真正的服务,所以Clip名字服务在Cmdb的基础上增加了port端口,即五段(字段含义idc-product-modules-group-port)定位一个服务。我们可以将动态的IP通过Clip接口注册到指定含义的String上,通过Clip自带工具来解析实时的String对应IP关系,譬如:


# clip cstring -q idc-product-modules-group-port
192.168.0.1
192.168.0.2
192.168.0.3
192.168.0.4
192.168.0.5


Clip数据存储结构分为两层:
关系层保存了String对应IP或内部系统Cmdb的模块关系(见图3)。


Clip名字服务关系表(图3)
关系层数据含义见表1


关系层数据含义表1
数据层保存了String与IP的具体关系(见图4)。


Clip名字服务数据表(图4)


Clip名字服务在存储String对应IP关系基础上,在SDK上还提供了远程端口扫描、远程ssh、远程文件拷贝和查找String关系结构的工具子命令等,更多可以见http://blog.puppeter.com/read.php?7。

Clip名字服务与Docker应用
如笔者上文所提,离线系统的建设思路就是将离线业务通过Docker快速的部署在资源空闲的机器上,而空闲的机器是通过数据分析系统长期分析沉淀的结果,Clip名字服务就是这两种资源建立联系的桥梁,但只有Clip绑定关系还是不够的,还需要建立绑定关系String对应Docker环境的关系,所以在Clip名字服务的基础上我们又扩充了Docker的资源关系表。


Docker资源关系表图5
其中Docker资源使用的关系表的字段含义见表3:


我们来看一个需求案例:某视频转码业务在上海需要使用资源约1000核心,对应的关系表为表4


由于buffer资源不时在变动,我们需监控String (sh-buffer-qq-video-2877)整体核数是否低于mcount值,如果低于则出发自动扩容策略。同时也需针对Docker资源使用关系中的app_port字段来监控整体String (sh-buffer-qq-video-2877)业务是否处于健康状态。在这里我们沉淀了String (sh-buffer-qq-video-2877)的一些基础数据如负载、内存、网络和磁盘IO等为资源的调度奠定的基石(见图6)。


离线运营系统图6

原文地址:https://www.cnblogs.com/YatHo/p/7845104.html