【 DCOS 】织云 CMDB 管理引擎技术详解

欢迎大家前往腾讯云技术社区，获取更多腾讯海量技术实践干货哦~

作者 : 李琦 , 腾讯高级工程师 , 就职于网络平台部。曾负责公司海量运营系统的规划设计，如 TMP、Sniper、GSLB、IDCSpeed、IDCProbe 等网络运营平台，以及参与腾讯云云主机、云网络、云安全等基础产品规划和大客户的需求管理。目前主要聚焦在私有云基础架构的统一监管控，把腾讯基础架构的自动化管理能力以产品化方式输出。

引言

云计算经过多年的发展，逐渐从概念到渐为人认知、到接受、到现在全行业拥抱上云，云的客户也从最初的中小初创互联网企业为主，逐步渗透到大型互联网企业、金融企业、传统企业，甚至到大型央企/政企。

因此，为了应对不同客户的市场需求，云的形态也开始多样化，根据客户对资源控制权的不同，基本分为以下几类：

图1 云的集中形态

在传统公有云中，计算资源主要是虚拟机的形态，以至于在云计算早期一段时间内，大部分人认为云计算技术 = 虚拟机技术，这种形态下的云，你只能接触到虚拟机，任何物理资源对你都是透明的；

当这些物理资源产生冲突时，势必会影响到你的业务，所以当业务要求越来越高，他们对资源的控制权也慢慢提升，希望能独享物理机，就有了裸机云；

进一步，他们还希望能自定义组网，方便其原有业务的迁移或重新规划，于是有了黑石云的解决方案（顺便提一下，其实“黑石”的核心是支持Overlay的虚拟网络，而非外界解读的物理机售卖）；

到最后连数据中心也要求独享，就有了私有云。这时，相当于裸奔了，原来隐藏在客户背后的供应链管理、运营支撑管理、异常发现和处理等机制、系统稳定性/易用性/安全性、运维背后的人海战术等，都表露无遗，要把数据中心真正“交”给客户，不是那么简单的。

公有云 VS 私有云

关于私有云和公有云的 PK，业界一直有争论，大部分都认为公有云才是未来，私有云是历史的倒退，尤其是技术发展的倒退，觉得这东西就是以前传统系统集成商干的事情，不是互联网人变革的上流新事情。

其实，这种说法是片面的，他们只看到了“私有”这部分，要“私有”并不难，但关键是在“云”这部分，即提供一套私有云管理系统，实现整个IDC的自动化闭环管理，由之前的手工管理变成系统管理，减低用户的使用门槛。从某种程度来讲，私有云其实是公有云发展到一定阶段成熟后，一种产品化的结果，也是能力输出的一种最极致的表现。

另一方面，受限于安全合规的要求和商业竞争的考虑，传统金融（尤其银行/证券）、央企/国企/政企和大型传统企业，一般不会把核心业务放在公有云上，宁愿花更大的成本代价，也要以私有化独享的形态来掌控自己的核心业务，因此，在很长一段时间内，私有云或混合云，都还是这些金主的主要考虑方案。

DCOS 1.0诞生

关键词：站在巨人的肩膀，服务器/网络融合

为什么会有 DCOS？

去年，腾讯云迎来了一位新筹民营银行客户 - 上海华通银行。

如下图，按银监会的要求，金融机构基本都是两地三中心，IDC 之间通过腾讯的DCI互联，访问公网则通过腾讯的 TIX，他们的IDC和腾讯内部IDC是不能互通的，因此是独立隔离的私有环境。IDC 在外部接入方面严格控制，通过ssl vpn 实现点对点接入，从物理层面来做安全防护，VPN 接入后，再通过云管理门户，实现对所有资源的管理。

图2 银行私有云整体网络示意图

在公有云环境中，用户只需要接触到虚拟的云资源，比如云主机、云硬盘、云数据库等，公有云会提供配套的自动化管理系统，对这些云资源进行管理，如生产、分配、回收等。

但在私有云的环境里，所有基础架构设施均由用户自行管理，包括物理服务器资源的初始化安装、远程开关机、重启和部署重装等操作，如果还是通过以往人工和现场的方式来管理，效率会非常低，进而影响到云资源的管理。

因此，在私有云的环境里，需要有一套类似云资源管理的自动化系统，实现物理服务器资源导入、自动发现、电源管理、系统部署、配置初始化和回收等生命周期的自动化管理，DCOS就是在这样的需求背景下应运而生的。

DCOS的产品定位

DCOS全称Data Center Operating System，顾名思义，定位是数据中心操作系统，这是一个很泛的叫法，业界完全对标的独立产品几乎没有。回顾 DCOS这1年多摸着石头的不断探索、思考，经过近 30 个迭代版本的试错验证，从设计到开发到应用落地，慢慢其定位也越来越清晰–私有云的物理基础架构管理引擎。如果参考行业私有云老大 – OpenStack 的模型，DCOS正好补充了OpenStack 对物理资源监管控能力，如下图红框部分：

图3 OpenStack逻辑架构图

下面分别从两个维度介绍一下DCOS的定位：

1）从资源管理的角度看：私有云里会有腾讯自采物理资源（腾讯标准服务器和网络设备）、客户托管设备和云产品（虚拟机、云储存、云负载均衡、云数据库等），DCOS 定位是负责腾讯自采物理资源的监管控，同时提供中心化的CMDB，实现基础架构设施数据的资源管理。

2）从逻辑功能的角度看：如果把数据中心当作一个整体业务，最低配的银行私有云至少包括四大模块：接入层（TGW模块）、逻辑层（DCOS模块和Vstation 虚拟化模块）、数据层（TDSQL模块），TGW 负责外部或内部的负载均衡接入，DCOS 和 Vstation 分别负责物理和虚拟资源的逻辑处理如生产、监控、再分配、回收等，TDSQL 则是提供金融级数据库集群。

DCOS的设计思想

和支撑腾讯海量业务的需求场景不同，DCOS 主要是面向传统企业，支撑大概1万台服务器（含虚拟机）规模的私有环境，产品设计上和现在内部系统会很大的差异，重点不是物理分布式架构和高并发能力，而是 All-in-one 高度集成、轻量简单、易部署、易运维、易扩展：

图4 DCOS设计理念

DCOS的产品解决方案

DCOS 的产品解决方案如下图，按其功能主要分为四大子产品：

图5 DCOS产品解决方案

1）CMDB：涵盖了服务器、网络设备、网络端口、IDC 机架机位、IDC 专线、IDC 出口、IP资源等物理信息的生命周期管理，基于腾讯多年 IDC 运营经验而建立其 CI 模型，并提供 ADS 智能审计模块，形成数据管理闭环，保证 CMDB 基础数据的完整性和准确性。最终，以 API 方式提供给 web 或其他云组件，并封装好常用的IP裂解/分配/回收和服务器搬迁等流程逻辑。

图6 CMDB的CI关系项

2）BME（Bare Metal Engine）：物理裸机管理引擎，负责物理裸机的自动发现、带外管理、自动化部署、命令下发&文件传输等自动化管控运维，通过外部扩展，还可以实现私有云其他组件，如控制节点、计算节点、存储节点等初始化部署。

3）OneMonitor：服务器和网络融合的一站式监控引擎，涵盖服务器基础采集、服务器硬件部件采集、服务器进程&端口采集、自定义业务采集、网络设备SNMP采集、网络质量探测、网络应用数据流分析，并支持把原始监控数据转发第三方平台。

4）OneAlert：服务器和网络融合的一站式告警引擎，实现服务器硬件异常告警、服务器性能/状态告警、服务器进程&端口告警、网络设备性能和状态告警、网络设备日志告警、网络质量告警、自定义业务数值/字符告警，并支持把原始告警数据转发给第三方平台。

从业务场景讲，DCOS 希望实现从物理资源准备、生产到运营的闭环管理（如下图）：

图7 DCOS的业务场景

1）资源准备阶段：经过上游资源的申请、采购、建设交付后，得到物理配置信息和资源规划信息（IP 资源等），并导入 DCOS 的 CMDB，建立基础架构设施数据的 baseline；

2）资源生产阶段：现场把服务器物理上架，并接上电源线后，即可进入远程管理阶段，服务器会通过带外 BMC 自动发送 DHCP 请求到 DCOS；DCOS 根据SN信息进行配置验收无误后，分配带外IP、标记为“已开电”状态，并纳入裸机资源池；然后通过带外 IPMI 即可远程初始化、开机、关机和重启；当DCOS接收到上层部署需求（RAID/OS/IP/初始密码等）后，会远程触发服务器进入PXE状态，在 PXE 环境通过 DHCP 获取部署 IP，通过TFTP拉取对应的镜像和配置文件，完成部署，并通过后置初始化脚本，实现网络的配置，以及应用组件的批量部署，实现私有云的初始化，全程可以做到服务器 Zero Touch；

3）资源运营阶段：服务器和网络设备的监控采集和异常故障告警，以及服务器和网络设备的日常运营管控。

图8 DCOS管理控制台

DCOS的技术解决方案：

1）逻辑架构

图9 DCOS的逻辑架构图

DCOS 采用模块化设计，每个模块（红框）负责部分功能，如 oob 负责带外&部署，sc 负责服务器信息采集管理，CMDB 负责配置管理等。模块可单独部署，成为独立的产品组件。模块之间基本没有依赖性（CMDB除外），维护和故障排查起来比较方便，同时易于进行模块扩展。

模块内部采用分层式设计，api 负责模块接入，master (storage)可进行任务调度、数据存储等控制逻辑，nodesvr (jobsvr/collect)完成任务执行、数据转发等，agent 在业务机器上负责信息采集、文件传输等。模块化+分层式设计，使得 DCOS 结构清晰，容灾方案也相对简单。

2）软件交付方式

为了实现离线部署，以软件包或镜像形式交付，部署在物理服务器上。

3）软件部署方式

DCOS 采用模块化+分层式设计，支持集中式部署和分布式部署。集中式部署：除 agent（部署在业务服务器）外，其它程序部署在一台控制服务器；分布式部署：分为中央控制服务器（如api、master、storager）、区域控制服务器（如collect、nodesvr、jobsvr）和agent（部署在业务服务器），可实现多机房或区域的统一管理。

所以说，DCOS 1.0是站在巨人的肩膀上，把网平多年来海量运营经验和工具系统进行了系统化的沉淀、浓缩，并结合私有云的和传统企业需求场景的一次全新的能力输出，服务器和网络 All-in-one 融合管理的一次新尝试。

图10 DCOS系统演进

DCOS 2.0 成长&展望

关键词：拥抱外部环境，走出自己的路
随着 DCOS 逐步成熟，以及外部客户需求的“洗礼”，DCOS 从2.0开始，逐步拥抱外部环境，抛开腾讯海量标准化机制的一些束缚，增加客户环境适配和自定义的能力，走出自己特色的路。

图11 DCOS 2.0的自定义能力

1）集成第三方组件监控
涵盖主流中间件/数据库/虚拟机/容器和开源组件的常用指标，开箱即用。

图12 集成的第三方组件

2）自定义 SNMP 监控
能适配不同厂家/型号/指标的 SNMP 信息采集，实现了一套 SNMP 采集通用框架，用户只需要定义好网络设备采集模板，系统即能自动识别通用 OID 和设备的私有 OID，实现 SNMP 的统一采集调度和数据处理加工，解决不同私有云客户的网络设备兼容问题。

3）自定义业务监控和告警
监控和告警与CMDB CI项解耦，支持用户自定义对象（如TGW集群、NAS集群、交易数据）、多维指标数据（如地域、门店、支付方式、交易金额等）的接入，和之前CI项+特性ID的一维度管理机制相比，更通用、门槛更低、更贴近外部客户的场景，尤其在业务监控方面。

4）服务器自定义部署能力
将原来标准化的服务器部署中的关键参数进行提炼、建模，实现BIOS、分区、RAID、OS镜像、网络等部署方案的自定义，以满足不同客户的服务器环境需求。

DCOS 2.0，在路上，路还很长…

欢迎关注腾讯织云公众号，获取织云最新技术资讯

相关阅读

基于 snapshot 的 MongoDB 从库读优化

在共享内存实现 Redis（上）

结合 qws 和 qbt ，本地开发环境搭建

此文已由作者授权腾讯云技术社区发布，转载请注明文章出处

原文链接：https://cloud.tencent.com/community/article/304971