标签：clu 初始化 user unix oss www 群组 network 节点
前述:0.硬件CMDB,即面向设备资源的资产管理,面向运维人员钟情于此.
软件CMDB,面向业务资源的配置管理,类似业务信息管理平台, 开发、PE和测试人员更加关心此处.
1.硬件CMDB各个公司都在建设(程度不一),软件CMDB(业务信息管理平台)系统化管理维护更少.
2.运维人员钟情硬件CMDB,对业务信息管理也只是笼统维护,远远没有到达基于应用项目的业务维护,监控力度只是系统和服务层面).
3.开发人员开发任务繁重,没有精力提交应用业务信息,结果.....大家都很忙,可是开发出什么鬼呀,经常被市场同事投诉(真实经历).
4. 当然开发肯定有需求分析和项目规划, 可是必须让维护人员(运维)了解和维护相关的业务应用项目.
5. 沟通很重要, 运维人员不单单被动的维护, 以运营的手段对待项目.
困惑:
1.涉及到微服务的开发需要了解服务部署在哪时,当前实例数和资源调度情况,更别说相关应用的日志和监控数据.
2.运维人员进行报警巡检或性能分析或添加监控,某些服务出现问题(访问出错|服务报警|应用上线和下线回收),不知道找
哪些相关开发和测试人员进行沟通处理, 尤其优化某个子项目服务组, 确认影响故障域和风险评估.
3.大量应用上线,特别是容器和微服务化, 导致业务项目更加复杂, 系统<->服务<->应用数据串更新频繁,传统手段无法维护.
4.对于某些爆发性(广告秒投项目)或者弹性伸缩应用项目,应用业务资源使用情况更加需不同人员知晓.
最近TW业务推广,此项目资源是否充足,以便进行扩充; 结果突发专线跑满,影响到其它业务,原来就是推广业务造成, 临时追加带宽.
5.反正很多都是口口相传,只有专门人员知晓,人员沟通成本非常高,知情度低也会影响工作效率.能不能提供一个便捷平台,让开发、
运维、测试人员更加高效处理应用项目业务.
应用业务配置管理-大图
应用业务配置管理系统相关资源(系统层、宿主、容器、服务、服务组、应用项目)关联,以及对应监控系统关系.
部分成果展示:
1. 面向业务资源配置管理, 全部隶属于'应用及服务'下.
2.服务器系统管理, OS系统作为应用及服务的基础资源.
3. 基于硬件服务器维护(类似硬件CMDB)， 基于服务器系统维护, 基于应用项目维护, 大约这三个阶段.暂时到达服务器系统到应用项目之间, 监控系统也是基于服务器系统, 作为运维人员更加需要此切点.
4. docker宿主节点, 专门拆分出来.
5. 宿主节点和容器实例拓扑图.
适用场景和环境: (https://github.com/tm-roamer/ctopo/)
(1)适用于监控网络ip节点互联关系的场景
(2)适用于社交网络的群组互联访问关系
6. 容器实例.
7. 应用项目
8. 有些服务组模块被多应用调用, 反正需要量化区分服务资源,在应用和服务间增加服务组层.
微服务项目也可以在此处添加, 定义为应用则太大, 定义为服务又太小, 暂时此处.
9. 应用服务
暂时不写. 服务注册和服务发现, 类似服务治理吧.
容器服务 基于 consul+register 作为 服务注册 发现及健康检查中心.
10. 我的小目标.
只知道这些服务器系统资源正常, 服务也正常, 这些数据都太片面, 独立无法关联起来.
监控需求(贴近业务,告警合并压缩), 非常需要此业务配置管理系统.
告警合并压缩, 某个项目故障,可能多方位报警, 需要挑选出更加上层报警上报, 需要知道关系链.
####################################################################
如何标识资源:
硬件设备-Asset(X86服务器、小型机、交换路由设备、防火墙、机架等)最终选用SN进行唯一标识,device_id用于存放设备编码(条形码/二维码标签),
name则为设备名称(X86服务器则为主机名, 交换设备则为设备名). 服务器业务IP和管理IP会存放在Asset-server, 交换机管理IP存放在Asset-switch.
####硬件设备不一定有OS系统,特别是购买腾讯云和阿里云VM主机,硬件设备肯定就不用提供, 所以造成Asset-AgentInfo拆分.
主机信息-AgentInfo(kvm、vm、hwvm、X86服务器系统)必须存在OS(linux|windows|unix),安装系统初始化同时需要安装agent. 最终使用hostname
作为唯一标识, agent_ip使用映射IP(hostname -i). 刚开始使用IP标识, 居然有些系统居然有四种IP(私网|公网)且没有合法(hostname -i), 最后用回hostname.
####遇到过硬件服务器系统同时安装KVM和Docker,kvm宿主机和依附vm都存放在AgentInfo(可以安
####装agent), 可是主机系统和宿主节点属性不一致, DockerNode引擎版本、network、storage、
####image,反正就要拆. 有时购买云供应商容器服务,无法提供AgentInfo,对接加入维护使用,也是拆分
####的原因之一; 对接授权和监控和代码发布应用, 方便以后松散对接.
宿主节点-DockerNode, node_id用于主健(用于它用); host_on为可选,用于对接主机系统; 最终使用docker_name作为唯一标识.
####
容器实例-Container, node_id用于主健(用于它用); node_on和name最终作为唯一标识.
####不同宿主节点的容器实例name有可能一致(反正当前情况是这样);生命周期特别短,标识ID和IP地
####址经常变,暂时选用node_on和name联合识别.
资源收集方式和更改通知.
服务器管理信息收集:
手动录入: 通过网页进行手动填写信息.
Agent自动汇报: 在系统OS同时安装Agent代理,进行数据收集和汇报.
中继自动汇报: 例如华为fushion cute私有云, 可以通过相关API读取VM相关信息, 直接入库.
宿主节点和容器实例:
Agent自动汇报: 主要在宿主机器通过docker info|docker inspect进行数据收集和录入.
中继自动汇报: 某个第三方平台,通过API进行信息入库.
服务管理:
手工录入: 非常不推荐, 针对非规范化和量少的服务.
Agent录入: 服务必须规范化, 服务安装部署时进行服务自动添加, 一般针对传统服务.
consul服务发现: 特别是针对consul和register服务,对容器服务非常有用.
服务组管理:
一般通过nginx和haproxy进行分发管理, 或者其它方式.
haproxy可以通过状态API页面读取service_cluster和相关服务, 方便自动入库.
更改通知:
以上资源变动, 最好能对接到监控系统, 让相关人员了解, 解放我们双手.
参考链接:
http://blog.csdn.net/younger_china/article/details/52243759
http://blog.csdn.net/yeasy/article/details/47749725
http://blog.csdn.net/zhangjun2915/article/details/44080453
http://blog.csdn.net/gsying1474/article/details/51773391
https://gliderlabs.com/registrator/latest/user/quickstart/
http://blog.csdn.net/daiyudong2020/article/details/53559008
http://blog.csdn.net/yeasy/article/details/47749725
http://www.techweb.com.cn/network/system/2016-01-28/2270190.shtml
http://www.cnblogs.com/wintersun/p/6747355.html
http://blog.csdn.net/u010246789/article/details/51871051
http://blog.51cto.com/renyongfan/1827797
标签：clu 初始化 user unix oss www 群组 network 节点
原文地址：http://blog.51cto.com/teemomo/2061218
