DCOS :私有云的物理基础架构管理引擎

Keeli(李琦),2016年加入腾讯网络平台部。之前曾负责公司海量运营系统的规划设计,如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,在路上,路还很长…

文章来源:TEG云端专业号

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏SDNLAB

如何将SDN和自动化嵌入下一代云数据中心

云计算时代,企业需要新型的数据中心网络架构。而新型网络架构主要指的就是借助软件定义网络和网络自动化平台来打造数据中心网络架构。硬件厂商形象深入人心的...

2644
来自专栏斑斓

选型的目光瞄准Spark

在Spark社区,众多参与者已经在为Spark 1.4.0(RC2)推出的特性投票了。我之遗憾,在于我们暂时还未参与这项工程的创造工作;我之欣喜,在于我们可以毫...

2878
来自专栏MessageQueue

2017上海QCon之旅总结(上)

本来这个公众号的交流消息中间件相关的技术的。这周去上海参加了QCon,第一次参加这样的技术会议,感受挺多的,所以整理一下自己的一些想法接公众号和大家交流一下。

953
来自专栏云计算D1net

信息安全度量:什么是云要收集的

CISO需要知道云安全性能的真实数据。因为C级别的高管和董事会会一直问安全管理者风险暴露相关的问题——“我们需要多高级别的安全?我们距离满足合规要求还有多少距离...

2995
来自专栏PPV课数据科学社区

【资讯】SQL/NoSQL两大阵营激辩:谁更适合大数据

目前企业在着手推动大数据项目的过程中,经常会遇到这样一个关键性的决策难题——到底该使用哪种数据库方案?经过综合考量,最终的选项往往只剩下SQL与NoS...

2413
来自专栏IT技术精选文摘

架构之道:3个程序员成就微信朋友圈日均10亿发布量

1452
来自专栏程序你好

微服务的创建和管理最常见问题是什么?

如果你不正确地划分责任,你就会遇到问题。将任何应用程序应用到分布式系统中。想想你可能会遇到的问题。管理数据和管理状态是许多人在管理有状态和无状态数据时遇到问题的...

461
来自专栏云计算D1net

通信服务提供商在选择混合云之前要问的四个问题

如今,似乎云计算服务提供商与天空中的云朵一样多,那么你如何知道哪个云适合您的通信业务呢?毕竟,不同的业务应用对于可扩展性,性能和延迟有不同的要求。例如,适用于客...

3516
来自专栏Python中文社区

【腾讯云技术沙龙预告】云端数据库的设计之美

以数据为中心的信息化社会,数据库可以看做是所有应用程序成功运行的核心。而结合云计算,数据库的高可用性能够被放大到极致,可以实现按需付费、按需扩展、高可用性以及存...

1394
来自专栏纯洁的微笑

电商系统之订单系统

订单系统作为电商系统的“纽带”贯穿了整个电商系统的关键流程。其他模块都是围绕订单系统进行构建的。订单系统的演变也是随着电商平台的业务变化而逐渐演变进化着,接下来...

741

扫码关注云+社区