如何实现云管平台与CMDB系统的联动探讨

本期交流探讨的重点问题主要如下：

【云服务管理平台与数据中心环境适应性】；
【云服务管理平台与周边环境对接】；
【云服务管理平台与CMDB联动】；
【云服务管理平台下自动化及其交付内容】

云服务管理平台与数据中心环境适应性问题

1、 云管平台管理的底层基础设施边界？
2、在生产环境、开发测试环境、两地三中心架构中，如何部署云管平台？

Q1：**云管平台一定是有一个最适用的基础设施管理框架和边界的，是不是上了云管，就要想方设法把所有的基础设施都丢进去，好实现大一统管理？还是要讲究策略，精挑细选，设置准入门槛呢？
实在不想把云管平台做成一个大杂烩。**

这个问题其实不是边界问题，是云管平台的服务目录到底是给谁做的问题。云管平台如果是面向基础设施管理员，那么就是为基础设施操作人员精简操作、减少重复操作等内容，因此这时云管平台就是成为集合各种云资源池的操作上的抽象和提炼；
如果云管平台是面向业务运维人员，那么就不得不考虑梳理业务-应用服务-资源关系，并且还要站在业务运维人员的使用场景去抽象和提炼服务内容，基础设施层的内容就相当于是消费品，其它权限、端口、防火墙、资源配置、容量、基线版本、安全巩固等等一系列基础设施上要操作的内容，业务运维人员全然不关注。但是这些仍然是需要对应的服务平台去整合统一集中，这就将云管平台服务侧（专门面向资源admin）来提供服务和操作的。
个人经验是说，云管平台首先适应输出什么内容，一定是面向谁来说。不至于跑去政府部门去报案——找错衙门发生。一定是先定位使用者，然后将使用者的用户场景进行分析和整合、剖析抽象和提炼成服务目录，然后再形成需求、开发去实现。
比如代码管理和业务应用服务自动化发布，到底该不该入云管平台，从资源交付来看，确实不应该，因为这是完全业务应用服务的事儿，资源平台完全不关注。但是若使用者就是业务应用服务运维人员，那他们就是关注代码、自动化编译和发布到指定的服务器上，并启动服务（这些场景是使用者的日常操作场景），自然就要考虑如何纳管这些代码管理、业务应用服务自动化发布等。
平台首先不能先设条件和门槛，应该是先找准用户群体，这样的平台才有生命力，有用户的平台，一定可以获得持续反馈并升级改造，平台自然就逐步提炼成了服务平台。

Q2：在生产环境、开发测试环境、两地三中心架构中，如何部署云管平台？两地三中心架构中的云管平台能否纳入统一管理？

一般理解是把云资源池及其相关的资源叫做供给侧（包括两地三中心架构），那么这一侧是会有不同的业务域，或叫不同的池化用途，比如生产环境、开发环境、测试环境、准生产环境、培训环境、运维区环境等等，这些都是供给侧依照不同业务要求做了相应的物理隔离、安全管控、访问限制和自动化交付水平等都各有差别。因为这些业务属性或者要求才质上区别了供给侧的输出方向和面向用户群。
每一种供给侧输出所面对的使用者，都有一个服务侧，有可能是不同版本下的原生态openstack或foreman或oVirt等，也可能是不同版本的vCenter或Ctrix管理平台，这些服务侧可以独立操控供给侧的资源输出。如果需要统一云管平台，那么这些服务侧的 API 服务能力是必须要梳理和建立，否则难以完成统一云服务管理平台；
接下来，就是构建统一云管平台，即消费侧的实现交付，就要考虑统一云管平台下各服务侧数据粒度的对接了，如何维护和保证这个粒度一直，就需要构建一个适合将不同域数据粒度转换的管控数据库/CMDB，通过这个CMDB将不同域的数据进行用户化划分、角色化定位，通过这个些集成，将不同维度数据，围绕使用者的角色和安全管控粒度，业务归属和交付粒度，重新定义面向使用者的实现。
所以资源 Administrator 这一层，我理解多数是站在资源池供给侧、资源服务侧的理念进行操作管理，尽可能降低资源 admin 的手工操作和加速排错，以自动化和脚本化的模式进行准确的 silence 交付。
但是作为面向业务开发、运营和运维使用者的消费侧，那就得重新定义和考虑不同用户的所关注不同的数据粒度，操作交付，关联交付，历史追溯，性能跟踪等等，这些都是需要重新梳理和定位用户真实使用需求。如此才能更为适中的交付云管平台，吸引使用者成云管平台粉。

云服务管理平台与周边环境对接问题

1、如何将devops跟现有运维环境做深度整合?
2、混合云的情况下，如何实现云管平台和CICD平台的数据互通；
3、云管平台与网络设备如何结合？
4、云管平台与SDN关系？

Q1：金融数据中心运维环境能否更好的与devops做深度整合?是否具有可行性?

CI/CD部分，主要是整合服务管理侧的内容，通过 API 集成了操作管理侧供给的服务化内容，比如 Jenkins 发布，SVN GUI改造，GitLab 的BRAC权限管控集成入统一门户、包括 Harbor 等，这些目标是使业务运维用户从资源申请--资源交付--业务应用代码管理--自动化发布--业务使用防火墙--业务运营过程中使用权限申请--业务日常操作过程中使用堡垒机/Jumpserver--监控运维--日志分析等，这样使资源到业务闭环，同时诸多API串联到业务用户下的资源和日常操作、运营运维。如此把资源粒度、业务粒度数据交互管理闭环完成。

Q2：在私有云环境内，还有SDN,负载均衡器，防火墙等网络设备。在云混进下，云主机的创建和变更非常频繁，相对的，网络设备的变更也非常大量。云管平台如何将这一块更好的管理起来？

比如openstack与SDN的环境下，目前常用的有两种方法。一是SDN对接openstack，再由openstack对接云管。二是直接由云管对接两者。哪种方法对业务的支持力度更好，跟容易把控？
防火墙，因为策略复杂的原因，需针对业务场景做大量定制化开发才能勉强用起来，是否还有更好的方法来管理？
目前市面上大多数的云管理平台都能对接 cisco的aci和 华为的ac
华为的ac先对接到华为openstack再次对接到 云管平台.
cisco的aci可直接进行对接,aci控制vmware的分布式交换机等虚拟网络操作
云管对接任何设备技术支持都是厂商级别,如果内部没有研发团队整体效果需要完整的业务需求,
需求明确后完成云管理平台的业务开发,
SDN就看什么地方接入网络，整个数据中心级网络接入SDN，我觉得有点难度。但是若是仅与资源池第一层对接的网络是可以做SDN的对接。但是是否这第一层网络设备是否可以与SDN控制器对接，取决于网络设备是否有对应的 API 服务能力或者叫 plugin 对应网络控制台。一般都是二层接入ML2plugin对接。对接难度完全取决于网络设备是否开放接口。
一句话，乞求网络设备厂商把这个蛋糕分出来给别人吃，有难度。毕竟不能给网络设备厂商带来白花花的银子，都是假象，不能长久之计。
SDN的部署有两种：1 硬件SDN厂家，如思科ACI 2 虚拟化SDN，如VMware nsx。我们这里用的是第二种，原有网络架构不用动，只需要部署新的NSX环境，NSX的部署环境就是路由可达，vxlan的封装在NSX自己内部搞定，所以也就是云管不需要纳管网络设备，nsx里自带网络模块由VMware自己管理。如果是第一种硬件厂家的SDN，应该有自己的控制器管理，具体细节没有实施过，不太清楚。

Q3：云管平台与SDN之间有没有关联？在设计时，二者之间如何考虑？

要实现部署vm自动化网络配置功能, 云管理平台必须对接 sdn 控制器,
安装部署vm需求完成vm的网络隔离和安全配置, 包括ip分配, vlan, 路由, 安全组, 负载均衡,
snat,dnat和端口的安全策略；
实现云，80%工作量是在规划、设计、配置网络，网络实现了。云也就实现了，网络没有实现好，云也就基本风雨飘摇。这是我的理解，所以网络是云里面极其重要的内容。
云管平台本身面向的使用者/消费者来说的话，那么就是SDN的消费者；
如果是面向资源管理员/网络管理员，那么就是如何规划、设计、配置网络的操作，这部分需要借助于SDN技术来是资源管理员减少手工操作和不必要重复配置。
SDN对于整个云来讲，能实现到什么程度，控制器如何控制实体网络交换机，这都有赖于数据中心的真实网络环境和网络厂商是否愿意开发接口供云管平台调用。
所以与云管平台的关系，就看站在谁的角度去思考，可以说有关系，也可以说没有关系。

Q4：**多技术栈、多平台的混合云环境，在持续交付的过程中，存在同一系统在混合云部署的情况。
通过何种方式或方法，来进行混合云的配置信息的自动采集，聚合，分类，以达到云管平台数据的消费？**

多云环境、混合云环境我都能理解，但是多技术栈有点理解不透，是指一个云KVM-openstack, 一个云KVM-oVirt，一个云VMware-VCenter，还是指每个云都采用了不同技术栈比如这个是python实现、那个是Go实现、这个又是Java技术栈，又或是云管理平台下技术支撑是多技术栈，所以这个里有点不理解，请协助明确。
CI/CD过程中，无论是 Java系代码、Python代码、还是Docker/Go 代码，这些都是通过工具链来做到持续交付，与管理平台和发起CI/CD没有关系，理论上应该是先看工具链是否支持技术栈的CI/CD，因为云服务管理平台是与工具链进行CI/CD，而不是云服务管理平台自身就可以做 CI/CD。
既然混合云，一定是资源类型异构、交互通过API服务接口，还有就是如果归类、如何做好数据模型设计，这些都是靠现场团队去打磨、调研，有了这些前提基础，才有可能说如何维持数据完整性、鲜活性、一致性；
自动化采集的确是确保数据完整性、一致性和鲜活性的不可或缺的手段，但是不是唯一，有些配置数据自动化是采集不来的，比如业务-应用服务-资源 这种关系维护，就不能采用自动化去采集，而应该是渗入操作流程中，将这些关系维护好，保持数据的鲜活性和准确性。
自动化采集可以完成资源及其属性类的数据、或配置数据，其它关联关系、业务命名、应用服务创建或勘误，这些只能通过日常操作流程中不知不觉来维护这些信息。所以不全是自动化能解决的。

云服务管理平台与CMDB联动

1、如何实现云管平台与CMDB系统的联动？
2、云管平台建设中，如何准确定义上游业务应用模型和下游的基础设施模型？

Q1：新建的云管平台如何做好与CMDB的联动，数据以哪个系统的信息为主？数据有更新，如何做到信息的一致性？同步更新频率如何设置？

CMDB从逻辑上应该是数据中心的核心，它承载了数据中心的方方面面不同粒度的数据。正因为所有数据中心都希望CMDB保存所有数据中心的不同维度、不同粒度数据，所以CMDB一直都不能很好构建好。几乎没有完美的CMDB能承载数据中心所有的数据。原因就是每个人都希望CMDB承载自己关注的粒度数据，不相关的粒度数据都不希望出现，因此CMDB都不知道到底重点在哪儿，该满足谁的为主旨，也难以确定用什么维度来实现各种粒度数据关联和输出数据服务。
CMDB承载另一个就是流程，如果CMDB与管理内容粒度隔离，那就CMDB为存数据而大量吸收数据，输出数据服务就变得很渺茫，现实就是这样的。
但是反过来，一旦与流程对接，本来是期望通过流程运转过程中把CMDB更新和准确性得倒保证，就会因为流程流转和更新诸多变更受限制，反而牵制了流程的顺畅，如此为了流程顺畅，就牺牲数据了，因此CMDB中的数据不但没有更新和准确，反而增加了一些冗余数据，而且为了迁就流程流转，甚至写入错误数据。
所以CMDB到底该怎么定位，用到什么地方，通过什么方式保持数据鲜活性，如何保持CMDB数据准确一致，与周边环境的数据同步机制和消费形式，这些都取决于数据消费粒度的管制，如果消费侧对CMDB所存的数据粒度不适应，消费侧自然不会使用，如此久而久之，则CMDB就变成了没人问没人更新的sunset平台。
所以CMDB的构建，首先确立消费侧所需要粒度，如果有消费侧和明确粒度，CMDB则可以构建，然后CMDB能够有足够的灵活性可以扩展，并不断优化完善扩展维度/粒度，这样增加更多的消费侧供给和用户范围，这样就会有一个良性循环，否则CMDB一定是思路一条。
比如CMDB与云管平台对接这件事，是大CMDB，小云管？还是大云管小CMDB本来就很难决策，原因就是CMDB粒度数据与云管平台适应环境所需要粒度数据是否一致，不一致怎么解决，是在云管解决还是CMDB解决，者都是需要看面向使用者/消费侧的关注粒度。而且实际上云管平台无论怎么设计都会增加CMDB，只不过这个为了云管平台自行管理体系单独构建的管理粒度。这个粒度与数据中心级的CMDB粒度本身就存在差异甚至舛误，因此怎么有机统一关联，这个需要云管平台团队和CMDB团队相互了解，并且定好各自界面，目标都是维持各自粒度数据的鲜活性、准确性、一致性，给消费侧以安全感、准确无误。

Q2：云管平台建设中，如何准确定义上游业务应用模型和下游的基础设施模型？

云管平台站在使用者/消费者角度，先梳理业务模型，业务应用作为上游，目的是将下游管理员关注的基础设施分享给业务应用使用者，共同来关注资源运营状况，也将资源可视化放到业务应用人员面前。
定义这个两者模型，主要是考虑使用者的真实需求。模型之间通过建立映射关系，使得上下游的内容互相透视，这样在日常操作和运维过程中呢，沟通目标就成了一体，不会造成业务应说说的话，基础设施不同；或者基础设施说的内容，业务应用完全没概念。
模型构建粒度，宜模型够灵活即可。不宜过度设计这个模型！
A2: 业务蓝图完成业务模型规划和配置,
底层基础架构 自动按照分配算完成基础设施模式建设,
最后业务蓝图+基础设施蓝图,统一成业务部署模式图

云服务管理平台下自动化及其交付内容

1、云管平台自动化交付内容与传统有什么差异和优势？
2、金融企业云平台如何实现异构资源统一自动化交付？
3、如何梳理云管平台纳管资源的范围和输出服务内容？

Q1: 云管平台自动化交付内容与传统有什么差异和优势？

交付内容本质实现来说，其实没有任何差异。
但是实现形式确实变化很大。比如云管平台交付DBaaS服务，比如MySQL服务，之前可能就是准备资源、安装MySQL、配置cluster、启动服务、建MySQL业务用户、授权、调优参数和附加备份软件，如此繁琐操作实现了MySQL 数据库服务。在 DBaaS 服务是将这些操作做成了一个标准化执行子集进行编排，实现交付内容是一样了。
再比如交付一个业务应用服务，从基础资源（VM)、基础软件(DB+MW)、业务应用服务代码、部署并启动服务、最后到网络、安全支持，这全链路闭环交付，牵涉的负责人、管理员诸多，跨部门组织，有的甚至跨公司，但是通过自动化及编排引擎，全部将自动化子集以标准化的交付内容，逐步编排交付，可以一键式交付整套业务应用服务，直接进入业务应用服务运营。
当前差异，就是标准化、自动化引擎、编排引擎进行组合，与传统比，传统交付内容可能就是每个人负责这些操作进行个性化交付；
但是有一点差异特别明显，就是 Docker，这个与传统的自动化交付确实有质的提升，与传统和虚拟化时代的交付内容，完全不是一个等量级，包括运营、运维等相关操作都是大相径庭。

Q2：企业在做云管平台建设，应该如何梳理云管平台纳管资源的范围和输出服务内容？

与其说纳管范围，不如说云管平台在数据中心的适应性。选型一个云管平台，是否适应数据中心？这个其实是个选型问题。
一样的思路，与其说输出服务内容，不若说云管平台将对什么样的用户开放。这是个人感觉比较踏实可落地的方法。
与数据中心适应性问题，首先看数据中心物理位置（比如两地三中心、双活数据中心等），其次看网络安全域（有的以业务域划分，有的就以安全划分等），最后看各域内的资源属性（比如版本、存量系统接管方式、网络环境、存储环境、系统内运行的业务环境等）要求来确定云管平台是否适应当前所在域运营要求，如果不满足，只能按照隔离出部分手工独立运营。因为有些存量环境确实不适合纳入云生态环境进行运营和管控；
输出内容，真实的话是面向什么样的使用者开放，就像不可能到沃尔玛去买火车票的道理是一样的。如果面向资源管理员开放，那么就站在资源管理员/操作者的角度，如何使用自动化减轻管理员的重复工作和敏捷交付；如果是面向业务运维，那么需要增加业务-应用服务-环境（开发、测试、生产）-资源的关系模型，并且针对不同业务用户看到不同业务范围和资源等相关数据，同时要将业务运维过程中的CI/CD环节相关的内容也加入，比如业务应用服务的代码、自动化发布，此外就是运维监控部分的数据按照业务应用服务的维度/粒度进行拆析到资源、业务应用服务等。

梳理按照,物理资源,业务系统,网络资源等维度进行
纳管的资源范围需要你合理制定上云业务系统的范围,先从D类或C类系统进行上云
流程稳定和可操作后完成B类和A类以及A+类系统上云
按照未来规划云管理平台应该纳管新建数据中心的所有设备和系统,包括网络存储计算环境等
输出服务内容需要看企业内部it能力,一般的可输出vm,如果有开发脚本能力可输出vm+业务部署的组合云服务,如果有网络开发能力或者有sdn,可完成以业务系统为单位的云服务输出.

Q3：**问题集（6个）
1、云运营是否实现多数据中心纳管？
2、集中运营中，申请表单需要管理员做初始化配置，例如网络部分，申请者需要固定ip，不知在这方便的考虑如何？
3、申请表单中，对防火墙、访问策略方便的处理？
4、自动化方便，目标端是通过agent还是通过超级管理员？针对ansible瓶颈问题如何做到弹性伸缩？
5、DBaaS方面出去nosql和内存型数据库，在oracle和db2上云的实践分享？
6、分享贵公司在sdn方面实践经验？以及如何针对服务或者云机做QOS限制和亲和性部署？**

1，多数据中心纳管不是问题，试想云管都可以纳管公有云资源，不是就通过API来完成资源管控么？所以多数据中心，可以采用很多方案，比如openstack的多Region等，甚至建不同的 openstack 环境，然后通过 API 统一到云管平台去管理，即云管平台下对接多个 openstack 环境。
2，云管平台中最难解决的问题就是网络问题，无论是IP手工指定或回收、VLAN管理、防火墙策略开通或查询，包括堡垒机访问等网络访问安全，这些都是云管平台比较难解决的问题。从个人的经验来看，云管平台面向资源管理员，这些网络权限是完全可以下放到资源管理员去操作指定及各种客户化；但如果是业务运维通过工单申请，个人经验工单可以增加申请者的备注信息（比如指定版本、IP、端口、目录等类似信息），有资源管理员统一去交付，一旦申请工单到了资源管理员手里，他们就可以比较灵活的指定，如果有些不满规范要求和基线管理规定，可以有管理员与工单申请方线下联系沟通，肯定能找到适中的解决办法。
3，申请表单中加入防火墙和访问策略，首先要解决的是防火墙自动化运维工具平台是否存在？其次看防火墙自动化运维平台对外 API 服务能力，若俩者均存在，那么云管平台就可以满足网络防火墙及其策略自助化服务开放。否则就变得申请单再各个部门之间流转，如此还不如有申请者多次多申请单，这样可以并行和追溯性更强。
4，自动化方面，就要交付内容，若是资源构建时的自动化交付，有很多渠道可以解决，openstack 在目标端使用 cloud-init配合heat编排，并非一定要通过自动化引擎（puppet/ansible/saltstack)，此时肯定是超级管理员权限进行自动化交付，而且构建时很多必须使用超级管理员/root来完成交付的。但若是资源交付后，运营过程中的自动化部分，必须要通过自动化引擎来解决，没有这个自动化引擎，这个自动化交付无从谈起。此外，提到弹性伸缩，互联网企业如何实现，我确实涉猎范围有限，不清楚。但是作为企业弹性伸缩，一般都是通过监控和业务要求来完成，有点类似资源构建；目前Docker也越来越多，Docker自动化伸缩全凭Kubernetes这样管理工具平台来实现，与自动化仅作为工具链在某个部署阶段会被采用。这是我所了解的自动化方面。
5，DBaaS无论是 NoSQL 还是传统 Oracle/DB2,又或是 MySQL 和 PostGreSQL、MongDB、Redis/Memcache等这些开源，首先在传统环境下的 DB 服务怎么构建得清楚，比如Oracle RAC, DB2 HADR，MySQL cluster、MongoDB cluster 等高可用架构,这些架构构建实现过程中进行产品化改造，只不过做了很多限制性，包括端口、访问协议等这些都标准化，当然可以增加诸如表化备份等内容。个人理解是将这些DB日常使用能力先标准化、让后产品化提供服务，就变成了DBaaS。
6，SDN方面有网络专门部门负责，但云管平台对接这些网络，基本上使用提供的 API 服务。所以SDN实现机制和底层技术了解不多。之前在通信行业做方案时，采用 openstack 与思科探讨过这个问题，对于数据中心来说，首先网络设备肯定不会是一个品牌，所以要从什么地方开始算接入 SDN ,这里需要看SDN做得有多深，如果将所有网络设备的控制端到 SDN 进行对接，这个比较彻底，目前我所知道，应该没有哪个企业已经做到这样了吧。如果是某个资源池，在一定范围内接入SDN的，这个的确有，甚至以某种管理网络作为基础进行SDN控制。此时，就是VM与第一层网络设备的控制，如果采用白牌交换机，可以用 openstack neutron，但如果是实体网络交换机，要与 openstack neutron 对接，则需要实体网络开放接口，比如思科N9K有部分API可用，其它貌似几乎很少，因为网络厂商不愿意放开这些对本身利益无关的投入吧。光赚吆喝和名声，与实际的银子比，还是利益银子比名声好些吧。所以SDN，如果在某个资源池与第一层网络设备对接的SDN，这种方案很多，几乎云厂商都可以做。但是运营业务网络，首先要评估业务访问量，尤其路由设置放在什么哪儿？实体路由器、防火墙？这些都需要与业务去评估。不能为了SDN而SDN，那样后面救火的场面会吃相难看的。

Q3: 端到端的业务性能监控、统一日志分析平台及应用性能监控有何定位上的不同，监控应用场景有何区别，引入这些监控系统，对现有应用或者系统有何影响？

准确断定端业务性能监控，确实还有很长一段路需要探索和实践。目前就某一种框架下的业务性能监控其实还是比较完善。比如某一个服务一秒钟调用了几次、一秒钟内调用多少服务及其链路情况进行分析，这些仅限于某一个框架下，比如SOA，Spring系等。但是诸如手机端/Web端--前置--业务逻辑--后台核心--数据库类似这样业务链路，其实就比较有挑战性，甚至说在业务应用程序中就得植入端到端的监控入口，并将这数据放入合成工厂，通过工厂来处理这些端到端的业务性能监控，如此其实投入巨大。所以现在很多银行采用旁路检测，只关注业务的有效性和失败性，即成功率的结果，也是不错的监控体系。
统一日志分析平台，作为业务监控还是很有必要，但是同样需要应用开发对日志进行统一和标准，形成可统一使用粒度的解析，以便获取准确分析结论。日志分析肯定是应用性能监控中不可替代的补充，尤其在为服务化下，日志分析对业务性能更具有不可或缺的作用。就看是采用 ELK 自主研发还是 splunk 的商业精品来服务应用性能监控了。