备注：本文根据主讲视频和文字速记整理而成。如有不当图片或文字，请以视频为准。很高兴有机会和大家分享CMDB的建设。屏幕前的每一个人都应该是运维的伙伴，所以大家应该对CMDB有一个很好的了解。我相信10个人中有9个人对CMDB有不同的理解。平日和其他同事同事交流的时候，我们都说CMDB可能是一个应用关系的记录，一个应用关系的库；还有CMDB，ConfigurationManagement就是配置管理，那么configuration包含什么关系呢？是否需要包含全链路，比如层应用，应用、数据库、交换机是不是一个配置？还有物理机、虚拟机等，要不要记录一下？一些朋友可能也会很惊讶。现在都上云了，云上有那么多资源管理控制台。您可以在生产虚拟机上标记这个时刻。当我们需要用到的时候，我们可以使用tag来搜索定位应用在哪个服务器上相信大家说的是对的，但是随着业务规模的增长，CMDB的维度越来越多。CMDB可以是一个简单的二维统计表，也可以是一个多维度的三维覆盖模型。如果一开始没有好的规划，那么后面CMDB就承受不起这样的复杂度。不知道你有没有这样的感觉。CMDB一开始搭建的非常顺利。不管是从云端，我们把数据拉回来存储在本地，还是我们用一些代理收集一些虚拟机的数据。但是随着业务规模的不断增大，随着一些模型，比如一些关系，加入到CMDB中，我们会发现我们的模型非常复杂，没有办法维护。这个时候，CMDB就成了一个dump。今天想和大家分享的是如何快速搭建一个可以长期使用的CMDB。相信听完今天的三部曲，大家会有一个新的认识。首先我们回到概念上，什么是CMDB，为什么一定要建设CMDB？大家都知道工具是解决同一个重复问题或者重复场景，减少重复劳动，提高生产效率的产品，CMDB也是如此。让我们看一张图片。这张图片是我们目前的故障排除图片。因为银行有一些规定，没办法直接把截图发到银行里，所以就和大家画个图吧。首先，从左上角开始。左上角是负载均衡集群，也是一个模型。在这个负载均衡里面，有集群ID，有域名，有运维团队的相关负责人。负载均衡下面是clustermember，也就是集群成员，加上端口号和IP，这个Member会指代两个OS节点，这两个OS都是系统节点，这个节点的数据记录了系统IP地址，虚拟化版本等系统级信息。系统信息层的上层是应用实例。应用程序实例将有一个应用程序APPID。我们的每个应用程序都会有一个独立的ID。这个ID代表了这个应用的画像。这个ID是一个什么样的容器，它是一个什么样的外部容器，它的语言，Release版本周期，releasechangewindows等等都是围绕着app的。这一层是我们的应用程序。应用程序上方是APPID模型。为具有独立IP属性的应用程序生成两个实例。这个应用就是我们的应用画像。然后应用程序的右侧是数据库集群。在CMDB中，我们将其托管为服务对象。应用程序使用该服务，即我们的数据库服务。在数据库服务中，会有集群的ID，数据库的类型，数据库的数据库名称，维护团队DBA。该集群下有两个数据库实例。这两个实例的区别是一主一从。如果是MySQL的话，那么他们的角色就是主从关系。以这样的排查图为例，假设今天有报警，红色区域报数据库集群，报警，说数据库集群查询慢，然后数据库实例发现DBsession异常group节点同时，在我们的OS节点上，我们发现宿主机的TIME_WAIT数量增加了，所以在我们的应用实例中，我们现在使用CAT埋点，可以得到期间的相互调用链代码执行过程SLA的响应时间。对于对方的SLA，这个地方有告警。至此，数据库TIMEOUT已经被调用。这是一个警报。告警底部的蓝色字体为CMDB的源数据。我们覆盖了警报，它今天就出来了。报警覆盖在这张图片上，然后我们同时覆盖更改记录。更改记录在绿色的一面。小编为大家解读一下。变更信息：某年某日某版本变更。换号。如果我们在排错的时候把这张图放在外面，其实我们可以很容易的判断出是哪个应用受到了什么影响，影响的范围是什么，可能是什么变化引起的。这是CMDB的一个典型场景。CMDB的数据远不止于此。通过学习和分析，所有数据都覆盖在CMDB上，所以CMDB源数据是非常重要的基础数据。如果说我们今天没有CMDB，所有这些东西都在我脑子里，我知道某个应用下有多少台机器，然后这台机器前面挂了一个F5，我就知道连接的是什么到数据库，那么如果你所知道的扩大一千倍，你还记得吗？也许当时你的脑海里就是这样。1、在建模阶段，相信刚才这张图已经足够让大家知道我们的CMDB有多好用了。下面给大家说说CMDB的建设。CMDB的建设分为三个阶段。第一阶段是建模阶段。让我们来看看这个模型。首先，我们需要确定这个模型是相对比较的。一个简单的模型，包括物理设备、操作系统和应用程序模型。每一方都会有物理模型，机柜，机房，物理设备，网络接口，网络设备到物理设备，还有我们的F5集群，集群成员，物理设备。集群，到网络设备。我们刚才看到，在这些集群中，其实并不是所有的信息都是我们的CMDB需要的，我们需要哪个CMDB，首先是我们平时使用的第一个，我们可以用来排错的管理信息和状态信息是缺一不可的.今天必须找到一个警报，对吗？至于刚才的管理信息，状态信息也是必不可少的，因为CMDB本身就是管理配置的生命周期。无论您的所有主机节点是否在线、正在维护、已部署或正在使用，您都需要拥有这些。是虚拟机的生命周期。不仅仅是虚拟机需要一个生命周期，包括我们的实例，包括我们的DB，都可能拉入、拉出、维护或者带部署等状态，那么状态信息是用来做什么的呢？用于告警抑制或者自动上架的时候，没有能力对外提供服务的时候，我们可以抑制这些告警，包括你今天正常计划的拉入拉出，不需要发出警报是的，所以我们需要能够通过状态的改变来淹没警报。那么第二个就是我们按照一个领域来划分。让我们来看看这张照片。实际上，每一行都是一个字段。所谓领域是相对来说的，因为这个领域跟我们的组织架构有关系，比如设备组负责机房机柜和物理设备；网络组负责网络交换机、防火墙、代理、VPN等网络设备，所以它的域网络设备和网络设备的端口，我们ADC组主要负责F5，那么F5的域包括物理集群，逻辑集群集群和成员，它们都与物理设备相关联。下面是系统节点，系统节点也出现在很多领域，比如中间件，Hadoop，ES，Kafka，主要是指Members等，还有我们的DB，DBinstance，DBcluster，DBentity.下面是我们的应用，应用运维，负责应用领域，还有应用实例，应用集群，应用画像。你见过有很多数据模型字段，但彼此之间没有通信吗？你有看到它吗？域与域之间不会有模型和关系。他们的关系总会对应一个相对集中的点。物理设备和设备组的所有域信息归于物理设备，网络归于物理设备。,F5也归结为物理设备。有人问，F5集群中的成员是主机，不是物理设备。就像主机节点一样，我们都与节点操作系统相关联。我们尽量不在域与域之间进行交互。它们只与三个特定的大模型相关联，这样做有什么好处？我们刚开始建数据的时候，数据量可能不是很大，服务器的数量也可能不是很多。如果我报一个虚拟机，我还需要把应用关系和所有的F5关系报给你。是的，但是随着时间的推移，闭环会越来越重，也就是越来越闭环。如果今天任何一个流程出了问题，你的数据就会乱七八糟，你也没有办法去管理，所以保证上传的数据在这个字段内做一个三层结构就可以了。如何理解内部三层结构？举个例子吧，我们就以网络为例。网络有网络设备端口，网络设备端口必须属于某个网络设备。那么网络设备和网络设备端口就是一对多的集群。网络只需要维护自己的数据就可以保证集群的每个端口对应一个集群。集群中必须有48个端口，交换机中必须有48个端口。只需要关联本层的数据关系即可。把网络设备和我们其中一台物理设备关联起来，因为它们之间有一个CI号，每个设备都会有一个CI号，这个CI号是唯一的，所以肯定不会有错误的关联。这时候，所有的报告都上报给CMDB，CMDB收到了很多关系，可以做下线。只要你有这个关系，你就可以使用这个关系来帮助你建立你的拓扑。我们刚刚看到了这张照片。这张图中所有的数据关系都是CMDB建立的，所以在收集数据的时候，其实并不知道彼此之间的关系，懂吗？只有cluster和自己字段的Member有关系，但是不知道对应的application是什么，F5也不知道application是谁？就是不知道下面的数据库关系是什么。这就是我们所说的建模。为了增加你的数据的灵活性和可扩展性，我们必须让模型更简单，关系更简单，把复杂的逻辑和复杂的数据关系带到CMDB中。这是一个禁忌。2.闭环第二阶段，我们需要在建立模型之后先做闭环。我们的闭环数据非常重要。CMDB如果没有闭环数据，是不可信的。闭环是保证数据准确性的基础。闭环方式可以通过强制留层驱动，可以使用服务目录或者流程引擎。然后简单说一下流程引擎的思想。当用户访问我们的服务目录时，他将访问运维流程引擎。之后，运维流程引擎会将所有任务发送给自动化工具系统执行。之后这些工具系统会告诉自己的域，因为这些工具都是域内的自动化工具，自己的域会收到一些相关的信息，那么这个进程down掉之后，就会被送到system域。system域知道我的某个虚拟机扩容成了4，它记录数据上报，把增量部分上报给CMDB，告诉CMDB现在我有一个虚拟机从2扩容到4、那么当CMDB收到这部分数据的时候，它能相信吗？CMDB不能随便更改我们库中的源数据，它必须有一个强大的进程驱动，所以进程引擎在执行的时候，会发消息给CMDB，告诉CMDB接下来是什么机器，它的2扩展会是改为4扩展。这就是通常我们说CMDBB表的时候，字段报告是C表，B表和C表统称。匹配是正常的变化。我允许你更改数据。如果不存在匹配项，则其上报的数据将被计入异常上报数据。这时候我们就可以反过来实现，说为什么2扩展会变成今天的4扩展，因为没有changedriver来做这个，从而形成一个闭环。我们首先建立这个闭环，然后再输入CMDB数据。今天有小伙伴可能会说我今天就是想收集服务器数据。在云上，我可能会用一个API把全量的数据拿进来，但是我们从来没有想过，如果你今天把全量的数据拿进来，你接下来生产机器的时候，你的数据怎么进来？也许你需要定期获取API，不断获取全量数据，永远覆盖你的CMDB的完整数据。那我觉得CMDB不应该这样做。它应该保留您所有的更改记录。CMDBA中的数据变更记录需要保留以供审计。所以今天在云上创建主机的时候，首先要想的是今天创建主机的时候，如何让CMDB知道这个信息，然后拿到这个信息，通过API上报，然后CMDB去修改你告诉它改变的数据，这是一个闭环。闭环还没有建立起来，所有的数据都是不可信的。这是我们的第二个闭环。3.解决库存第三阶段是解决我们的库存。盘点需要我们改变一些思维方式。首先，我们要相信这个领域。我们刚刚谈到了收集的数据。今天我们说按照组织架构，有网群和网络。团队可以提供权威的现场数据。如果今天的团队规模相对较小，不，没关系。我们将把它当作一个单独的实地报告。这里有一个思维转变。我们尽量不使用CMDB去探索。去争取它的东西有什么好处，但作为一个升级过程？第一个，你今天下去拿东西的时候，可能拿不到所有的东西。取回来的第二个东西，如果是从CMDB取的，可能会直接入库。如果报错，你分离出一个网域，你可以管理它的整个生命周期，因为你已经在你的网域中第一次和第二次感知到了，不会和CMDB数据发生冲突。东西要上报给CMDB，那些有变化和增加的东西都会上报给CMDB，这样CMDB可以有一个更简单、可追溯、可验证的流程。必须记录所有CMDB更改记录。每条记录的变化和谁的变化是以后可以追溯的关键方法。然后我们还有一个问题要解决库存，我的分布是什么，我怎么知道你这个领域应该有多少台机器，因为这个领域上报了，你作为一个CMDB你接受这个领域上报的所有数据，你相信它是权威的，我相信你的数据，但是我也想给你做一个交叉比较，交叉比较怎么做其实很简单，我们可以放一台机器，以一台主机为例，我们可以放一个Machine，扫描整个网络，扫描整个C端的所有端口，根据端口的特征来判断是什么主机和设备。这是一种方式，还有另一种方式。我们对于自建的IDC，我们可以拿到整个交换机的ARP表。我们银行现在主要是做TOP架构，一个柜子在上面，一排柜子，然后会有一个聚合，多个聚合形成一个核心，所以我们在每个柜子里。ARP表可以在顶部找到。有了这些ARP表，我就可以知道现在整个生产环境的分布有多大了。这是一种检测方法。我们不能仅仅依赖我们领域报告的数据。我们还需要有自己的帮助字段来加强和准确报告数据的覆盖率。那么接下来我们要讲一个逻辑上的交叉比较，它长什么样子呢？比如今天上报物理机的过程中，现在有5台物理机，都属于EXS系统，所以我要保证这5台EXS系统能够关联到我们的虚拟机，我们云团队将报告所有虚拟机。是不是这5台机器上的都是虚拟机？如果都落在这5台机器上，也没有问题。如果没有，让我们看看一些物理机。它未链接，因为它未被使用或丢失。这是一种交叉比对的方式，无论是ARP表的比对还是交叉比对，甚至是今天找一台生产中的机器。也是利用TCPdump找出上下游关系的一种方式。您可以在生产中找到所有活动的IP。这些在CMDB中活跃的IP是否都属于某个对象？这种方法可以连续进行。需要一个报告系统来促进数据治理。因为我们都知道CMDB的数据准确率是非常重要的一项。如果今天的数据准确率不按照这个报表系统，如果你每天、每周跟进处理，当然你需要及时建立一些像SLA处理的东西。对这些东西进行评分，以评估每个领域数据的准确性。只有这样，我们的CMDB才能继续稳步增长。那么我们会说，我们完成了三个阶段之后，我们就构建了CMDB，但是我们刚才说的最重要的一个环节是，我们把CMDB的数据拿进去之后，我们只能解决每一层的关系。现在还不能通过一个柜子知道DB相关的信息，整天链条都不知道。然后下一步是另一个。当我们完成了CMDB的搭建之后，接下来要做的就是关系。如何建立复杂的关系来实现快速检索。我们来看看这组架构图。这是我们的CMDB，我们的源数据在这里，所有的变化事件都会被推送到Kafka队列中。对于所有的变化事件，比如今天进来一条数据，这条数据发生了变化，这些变化就会被推送到Kafka。Flink会经过一个处理的过程，然后进行处理。没有处理，处理是业务需求，然后作为主要格式更好的检索和使用，然后推送给ES。上述道路能达到什么目的？以上道路可以实现快速的模糊查询。我们可以输入一个IP，一个APPID，一个CICODE，我今天输入一个联系人，也能查到所有相关信息。虽然说这个图不能补全，但至少能有一些类似百度的信息。如果你在百度上模糊查询，我搜索一个人的名字，我可以搜索到拥有他模型记录的相关管理员吗？，这在ES中并不难做到。现在CMDB模型有30个左右，导入ES的独立表有30个。大概700到800个字段，索引比较全面。目前数据量为20万到30万条记录。压力没有压力。ES集群也是用虚拟机做的，没有什么特别厉害的，因为ES擅长这个。要实现这张图，我们还需要依赖一个优秀的东西，NEO4J。NEO4J数据库最近也很火。我们从Flink中取出一段数据，输入到NEO4J中，原生输入，不加任何关联关系，直接把这一层的关系导入到NEO4J中，通过数据库改出来，这样就实现了这么一个吧，这样蓝色的部分就可以全部由NEO4J来处理了，然后我将导入后变更记录到NEO4J中，告警记录到NEO4J中，层层处理告警、源数据、变更日志信息。NEO4J的处理能力比较高，处理十亿以上的关系节点也非常高效。对于我们的使用来说，还是比较小的，只有几十万个节点，大约30万个关系进入NEO4J。总结由于时间有限，没办法对每个地方都做详细的介绍。让我们回顾一下今天的内容。CMDB首先必须有三个阶段。第一阶段是建模。模型必须足够简单。它的关系只是和OS相关就够了，不要在domain和domain之间做额外的关联，关联NEO4J会帮助我们轻松搞定。第二，解决闭环问题，因为闭环是CMDB的基础，必须先闭环才能得到增量，每天全额负责是不够的。三是解决存量问题。在解决库存问题时，一定要记得交叉比较，对上报的数据有疑虑。虽然说是该领域的权威数据，但是CMDB对上报的数据肯定是有信心的。怀疑、发现、想方设法检测等手段，帮助外业上报的数据更加完整准确。这三个步骤之后，我们需要继续做报告，及时抛出有问题的数据，因为时间长了数据很难管理。比如你今天做了一个改动，这个改动可能没有及时更新到CMDB，第二天CMDB就发现了。如果不上报，三五天之后，就没有人会记得这个数据变化了。也许它在我们的记录更改表中，但很难找到它。你可能想不到，所以我们要及时处理，尽最大努力推动这些数据的整改和治理。CMDB建好后，可以通过ES进行检索，通过NEO4J做拓扑。只需要Kafka继续将变化的数据传输到ES里面更新即可。从CMDB导入ES的数据可以保持原样。这样就可以导入一模一表。进入NEO4J时，可以将CMDB数据一一导入。可以原样导入原始模型，无需添加新模型。模型，NEO4J会为我们处理拓扑模型。道家有句话说，不管上层逻辑多么复杂，CMDB总是会保留最原始的关系，这是最好的，让它的扩展性和复杂性永远保持在一个相对稳定的水平。横线上也有说《道德经》，万物之始，大道简单，演变复杂，我们的CMDB也是如此。
