大家好,我叫张怀龙,是来自英特尔的营计算工程师,很高兴有能够在这个地方跟大家一起分享我们的一些想法和实践。下面让我们开始今天的分享。本质分享是由我和浪潮集团的同事为大家带来。我们分享的题目是Monitor Mesh for Edge Clusters,中文也叫编辑群的监控网格。现在来看一下我们的background,相比于云计算,编辑算由于部署更加靠近数据源以及中端用户。所以编辑算对实施性要求比较高,带宽流量密集型的服务能够提供更好的支持。这些更好的支持主要表现在,更低的延时以及解决了流量汇聚过大的问题等。正因为编辑算拥有这些优势,所以编辑算被很多星星的领域所迫切需要。这些领域包括智能制造、智慧城市、游戏实况以及车辆网等。为了解决这些应用场景的问题,编辑算实际上引入了云计算帕斯平台的一些工程能力,来解决编辑算在应用中遇到的一些问题。这些问题包括服务应用的API兼容问题、服务之间的网络联通性问题,以及服务、部署、监控等运萎问题。其中,不监控运萎问题是我们今天讨论的重点问题。随着编辑算应用场景的不断的扩张、集群的规模也在不断的扩大。于是,这会带来很多的监控问题。传统的监控方案对这些问题可能没法解决,也可能很难解决。于是,我们今天提出了我们自己的一套方案来解决这些问题。在提出我们的方案之前,我们先把编辑算的场景分为了两类,其中一类也就是通信运萎商的场景。我们以中国移动的MEC为例,这是一个小规模聚焦于高性能和高可靠应用的运计算平台。通信运萎商通常会组建一个一条专线来解决网络的质量问题,因此在这种场景下不存在弱网问题。所谓的弱网问题,我们可以简单的理解为,由于网络的不稳定导致的网络延时以及斗动或者网络传输的质量过低的问题。在下面的图里面,我们可以看到有集中的数据中心,有区域的数据中心以及编辑算中心。所有的这些数据中心都会组成各自的集群,而不同的中心集群之间,他们有不同的需求,主要表现的比如实严的需求不一样。对所有的这些集群和数据中心,我们需要提供一个统一的监控方案去解决,去对他们进行监控。这些是在通信应用上的场景里面,我们提出的监控问题。第二种场景是ITOT的场景。很多服务的提供商,他们把运气算的能力下沉到边界点上,边缘节点在边缘节点上做一些创新、开发。这个时候网络是一个黑盒,它极度的依赖于公网的能力。所以这有引入了一些问题,比如我们之前提到的弱网问题,以及网络单向连接的问题,不同的网络之间的接入问题,以及最后我们不同的边缘节点集群之间的自治机制的问题。我们把以上两种场景所遇到的各种问题总结为以下四个通点。关于边缘计算监控的一些通点。首先,第一个通点就是不同的边缘集群以及其上的工作负载的差异性导致给边缘计算监控带来的一些挑战。这种差异主要表现在在边缘集群当中,它创建边缘集群的一些框架性的版本问题。具体来说,比如 Kubernetes 的一些不同集群的 Kubernetes 的版本的不一致的问题。不同的集群当中监控设备、服务设备的版本不一致的问题,以及其上一些工作负载版本不一样的问题。很多工作负载虽然提供相同的功能,但是实际上他们的版本会有获得或者的差别。那第二个通点就是,基于第一个上面的通点,我们会发现在边缘计算当中,集群里面的这种监控设备以及服务的数量很多。他们的加入或者变更或者删除会很频繁也会很多,于是这就需要我们的监控方案能够提供监控对象的自发现的能力。这也是对我们的监控方案的一个挑战。第三点就是数据的同学同问题。这主要是表现在边缘中心和边缘节点,边缘中心以及云中心云或者叫云管平台之间的这种数据协同。这主要是表现在监控数据的协同问题以及监控配置以及这些监控组建的配置信息的问题协同问题。第四一点就是,我们需要解决在ITOT场景下的弱网问题以及各种各样的网络问题。那基于上述的四个痛点,我们提出了MonitorMesh的解决方案。我们的网格监控方案灵感来源于服务网格的概念。监控网格和服务网格拥有很多相似的一些概念,比如说控制面和数据面以及监控网格中的一些监控对象的服务监控自发现。这主要来源于我们对监控数据的一些分析,然后由我们的控制面去实现这种监控对象的自发现。下面这张图,我们可以先看这张图中的上半部分,也就是我们的控制面。它主要由四个组建构成监控策略的配置器。它主要是为了针对我们的边缘集群去做监控策略的配置、方案配置、各种集群的配置。第二个是我们的监控对象的探测器,这主要用于实现我们刚才说的监控对象的自发现服务。第三个,也就是我们的监控方案的生成器,相比于监控策略的配置器,监控方案是一条一条的有序的可执行的一些命令。所以在监控方案生成以后,我们需要有监控方案的分发器,有特别类似服务网格中的一些配置文件下发。这个地方我们是下发监控的一些执行方案到我们的数据面。然后,除这四个组建构成了我们的整体的MMC,也就是Monitor Mesh Control,控制面的四个重要的功能组建。除此以外,我们有个Resource Manager,也就是我们的资源管理器。在这个资源管理器主要管理了我们监控各种监控组建的一些images以及metadata,主要表现在我们加入我们编辑算的一些集群的集群信息。那下面我们来看一下我们的数据面。在下面,我们的数据面主要包含了两个组建,一个是Adresor Center,也就是我们编辑算资源中心。这是一个我们当前的数据面需要的一些信息。这个资源中心,编辑算的资源中心实际上可以说是我们的资源管理器的控制面资源管理器的一个子集。仅仅需要拉取它相应的需要的必要的一些数据信息。这是为了解决流量过度集中导致的问题。另外还有我们的MMA,也就是Monitor Match Agent,这是由monitor的一些我们监控的方案下发以后生成了一个个的具体的监控组建。这些监控组建主要负责监控的具体内容,对包括基础监控以及一些业务监控。监控的所有的数据产生会放到我们的一个实际数据库的,左边的Monitor Data当中。这里面的监控数据又为我们控制面当中的监控对象的探测器作为监控对象自发现的数据的依据。关于我们Monitor Match方案的更多的一些细节以及工作流程,下面我会交由我们的浪潮集团的同事来给大家进行解释。下面我把时间交给他,谢谢大家。大家好,我是浪潮数据的庞丽叶,由我继续介绍Monitor Match。首先看Monitor Match的控制面,由它进行监控对象的发现和监控方案的制定。这个监控对象的发现和监控方案的制定,它可以位于中心云,也可以位于边中心。如果是位于中心云的话,它对下面所有的边云进行上述操作。如果它位于边中心的话,它是只针对本边云进行上述操作。这个监控对象的发现,它并不是靠疲乏的调用边缘集群的成为平台来发现的,是通过监控数据来发现的,就是这里。大家看这里,如果监控对象发现器,它是一些定时任务,它会定时获取监控数据。当然,这个监控主要是获取一些服务、一些设备的列表,还有服务和设备的监控,然后对它进行比对。进行比对,它发现有些服务或者有些设备没监控,它就会制定监控方案。如果发现它这些,虽然是有了,但是进行改变了,或者进行删除了,它也会对监控发案进行相应的处理。就个例子吧,比如说这两个列表一对比的话,它发现新来了一个MRDB,它就会看监控对象的特律,发现MRDB有没有相应的监控特律。如果没有,它就到了监控特律的配置器,就这个监控特律的配置器,通过它进行监控特律的配置。如果是有监控特律之后,它就会往右走,它就会申选一个监控方案。这个监控方案同时会获取监控特律和监控的配置文件。这样的话,把它变成一个监控方案,再继续进行实力化。它得到它所带的继续信息,包括一些个性化的信息,包括监控对象是否要进行监控,还有它的一些个性化的配置,比如说MRDB的用户名密码,这地方都是通过用户配置好之后,它就生成了一个监控方案实力。同时会更新这个监控实力的列表,这种也是我们为了以后的更方便的控制。装完这些套套之后,它会将这个监控方案,然后同步下去。这个方案就包括一个监控查件的信息,还有部署了一些配置,部署的方法等等。这个监控方案制定之后,就到了监控方案的执行。这个监控方案的执行,就位于被验中心。这个MountedMesh的agent,他接收到MountedMesh controller,发来的这个监控网之后,然后他做两部分工作。第一部分,他会拿取一些监控的组件。另外是将这些监控组件的进行部署,拿取监控网。这地方以普拉米修斯的距离,他如果要新部署一个Med-DB的监控,他会拿取Med-DB,一个Porter,这么一个镜像,拿取了监控网。然后是在根据他的监控方案,如果部署Deployment,Service,还有ServiceMonitor等等。这个地方,另外说一点,一些基本的监控,还是以普拉米修斯的距离,还有一些基本的监控,像MountedPorter,比如Coupler的监控了。它是最开始就随着BNT旋的部署,就已经部署上去了。而我们MountedMatch是根据它返回的数据,才知道哪些设备没有被监控,或者哪些设备新插上了,或者哪些服务新部署了。然后是通过它返回的数据,进行的监控旋的发现,然后是在执行制定的监控方案。所以说BithicMonitor最开始是一定要部署。另外的话,看数据的采集,数据的采集是这样子的。每个边缘中心上,它有一个MountedSower,这个地方是它收集该边缘集群的监控数据,到了本边缘集群的一个实际数据库里。这个实际数据可能用于监控的展示或者告解,因为它这里面是更实施一些。同时,它会把监控数据写入到一个中心云的一个分布式边缘数据库里。这样的话,就是说它可以更全面的接行监控数据的分析,可能是后续的一些AirP的工作,各种。这个地方想说的是,就是说,边缘中心和中心云之间这个网络基本上是没有问题的。所以说,它这个数据可以全量的写入到上面的分布式实际数据库里。另外想说的是,这个监控的Agent到监控的Sower。这块的话,其实像容器的边缘,可能大多人还是那个,大多人采用的都是PromiseOS。但是这个地方,边缘中心和边缘络的之间,它存在弱网或者是单向网络的问题。使用PromiseOS吧,其实可能并不是一个很好的方案。因为PromiseOS的数据,它都是进行PromiseOS Sower进行数据拉取的。它每次拉取吧,只能拉取最新的数据。所以说,如果是做网情况下,是吧,它可能就是有些有些时间点了,它拉取数据可能就是拉取不到的。另外的话,就是说,这种单向网络,单向网络的话是边缘节点的话,它是知道边缘Sinter的边缘中心的。而边缘中心可能并不知道这个爱之诺的,这个地方可能就会需要加历随道。而如果采取这种上报的方式的话,一个是我立即数据可以缓存。假如说我数据上不上去的话,是吧,我数据可以缓得到本地。另外的话,它这个上报的话,它这个地方就不需要是加历随道。所以说,这个地方可能是更好的方案,可能就是说monitor agent,进行数据菜籍,进行数据缓分,然后进行数据上报,这种方式可能更适合边缘运。另外的话,想介绍一下分布式数据库,一般是边缘的所有江峰数据都会上报到中心位上。对于这个的话,中心园的数据库要遵处要求就很高。另外的话,也可能等下才能更适合地进行数据缓写。这样的话,其实我们选择的是分布式的eflotDB。分布式的eflotDB,就说它毕竟是seql的嘛,它可能是使用起来更方便一些,分布式起来也更方便一些。我们是自己开发了eflotDB,plaghtt这个出件,有它进行数据非发,然后再被切换,还有数据缓团。当然,我们这个eflotDBplaghtt也不是单点的,我们用kipon live,然后是确保eflotDB是活的。当数据来了之后,然后通过eflotDB,按照我们预设好的一些配置文件,通过按照不同的serious下发到对下面下面是部署的一些e4db的识典你看e4db1和e4db2它这两个是主背的方式e4dbproxy然后是把serious相同的serious放给e4db1和e4db2这两个是多写的方式这样的话就保证了数据的主背另外的话e4db1,e4db3,e4db5它这几个合起来就是表示了全局的e4db是数据的保证了数据的完整性就是我们开发的e4db然后确保了中心语言可以存储权量的加工数据这样的话就是说我们的基本数据营采集中心语言上又有权量的加工数据这样的话这个加工数据就可以用来可以被用来进行服务的发现我们的整个系统就整个都串起来了行上面的三个方面主要也都详细介绍了一下然后我再总结一下我们monit match这个方案吧这个方案首先就是说我们的将共对象的这种自发现的它不需要平凡的调用要不去的API当然它有时候这种备案集群特别是弱网的情况下你调这个API的话它可能反备回到数据也不全面因为它有弱网可能是备案设备上备案接待上清差的设备它可能是有网络问题它反馈不到也解决了不需要平凡的调用这一篇也解决了弱网带来了之后将共对象遗漏的问题另外的话就是我们的边缘中心它会按需的拉取一些将共的图件不需要存权力的将共图件是按需按照将共方案来了之后它按需拉取将共图件就行这样的话就解决省了存储空间也解省了网络这一块再有一个是这个方案的话就是针对多边缘集群的场景就一个边缘集群上它的一个策略都很容易应用到其他边缘集群上比如说我这个边缘集群上的设备几整一个谈的策略是吧另外一个集群上它如果版本是什么没有问题的话它也是一个设备让很方便的就把这个边缘集群上的策略应用到其他边缘集群上它是特别适合这种多边集群的场景最后一个是就是说它支持依供我可能是不同版本的Kubai 20或者是不同版本的Opiat包括是多集群这种的话它整个将共就不涉及到Kubai 20和Opiat它本身的开发它在这两个之外又进行了整个的WaterMesh这种将共系统就是它整个都是在它们外腾上开发的就不涉及它本身的版本而且它适合这种不同版本的Kubai 20和Opiat就这种而且是多集群的情况好那我订个我们的分享就这么多谢谢大家