2017年中国数据分析师行业峰会:大数据与云计算_分会场(之二)
时间:2017年7月29日
地点:中国大饭店
主题:大数据与云计算-分会场
主持人:时间已经到了九点,这个时刻非常欢迎大家,首先先加入我们的论坛,我们会后可以在里面做一些更多更深入交流,因为会场今天上午时间很有限,稍候会开始我们今天的会议。
尊敬的各位来宾、小伙伴们,上午好!现在是CDAS2017第四届中国数据分析师行业峰会大数据云计算的分会场,我是主持人代立冬,对大家的到来表示热烈的欢迎,非常欢迎大家的到来,也欢迎各位嘉宾给我们进行比较深入的分享,因为大家在数据行业做了很多年,接下来先进行第一场的关于云计算基础设施服务的,大家知道随着移动互联网与大数据的爆发给我们企业架构和运维带来很多挑战,很多这样的数据公司可能选择慢慢的把自己的服务进行云化这样的一个方向,其实给我们的云基础设施带来了很多挑战,请第一位嘉宾,承载美团电平的云计算与基础设施服务,美团云的开发运维专家雷雨同学给大家进行一个分享,热烈欢迎。
雷雨:我跟大家讲一下我们美团云这一边基础设施运维和自动化方面的实践和探索,对于大数据来说偏底层一些,我们这边云计算基础设施运维的大团队,我直接进入正题。
在美团和点评来说,所有内部业务和对外公有云上了云平台,所有业务,DPI和大数据这些用户需要物理集群,其他的业务跑在虚拟机上,有传统的基因,服务的框架结构大概这样的,中间才是美团云,下面IDC服务器和网络,下面美团云,承载外卖、猫眼、美团、点评,以及酒旅,公有云用户,整个相当于美团云的平台。今天主要讲处于美团云底层的基础设施的探索,这是基础设施分层的结构图,底层的物理层用服务器,大家都是互联网云计算圈里的人士,对这些都比较了解,大概分层的介绍,物理层上面主要是服务器、网络设备,以及一些多米环境的设施,IT层,还有IP层,再往上DNS,NTP还有一些HTTP的服务,这是基础设施服务方面分层的结构介绍。
下面直接切入一个网络方面的高可用的一些探索,这是我们一般来说现在标准的数据中心的网络结构,基本上这样一个形态,上面是运营商的网络,接下来是两个外网核心的设备,外网核心设备加的四层负载,包括负载均衡和北向流量的网关设备,接下来数据中心两个内网核心设备,还有交换机和下面的服务器,整个的网络设备中间,我们最主要的一层,从四层来说,做应用分发负载的主要层面在于四层的负载,大家可以看得出来,运营商过来客户的请求流量全部落到我们的路由厂,然后进行路由分发,上面承载整个美团的业务,包括现在所有APP的通道,包括我们的长连接做的其他路由通道,所以整个这一层的,因为全部是普通服务器,稳定性直接决定业务稳定性,所有业务在上面,大家可以看,一个普通的服务器,我们的从服务器的运维经验,一个服务器三年的质保期内,故障率在1%左右。作为基础设施平台这样集群化的服务,单台的稳定性决定整个集体的可用性,可以保持两个九左右的稳定性,这样对于我们这么大规模的业务来说不可接受的,所以我们在这方面探索了一个同步的功能,就是用户从公网进来可以访问,落到某个方面以后,分发到后端,当这台机器故障的时候,是可以漂移其他节点,其他节点继续往下走的。
下面直接介绍一下一个验证,这是四层负载均衡设备的结构优化,实现session同步,这是刚才上面的两个外网核心设备,这是我们的一个集群,每个集群原有的结构上分出一支来做一个二层的广播设备,然后做到集群内部的session表同步,可以是session在集群内部的漂移。做了这样一个功能以后,可能会有一定的问题是什么呢?当我单台的session里面承载力是四千八百万,整个集群的容量,因为每个节点会有集群下全量session的内容,所以整个集群session的容量四千八百万,是什么概念呢?整个现在我们的业务,美团点评整个的业务来说,单点机器上一个集群量一千万到两千万之间,这是集群切割控制的,远远高于我们的需求的。这个功能做出来以后,整个能实现到百万session的切换率为零,session后续会做到增量的同步,可能每个节点不会有所有集群内部全量的session内容,可能会做策略性的分发会提高整个集群的容量。
如图,这是比较现实的测试用力,模仿了刚才说的,如果一个MGW节点故障,用户感觉长连接断开,不可用的一个体验,对于业务运维来说之间能感受有包括数据库这种对实时连接特别敏感的连接都会感知到,内部调度很多报错需要排查,现在模仿四个连接客户端的下载,这边是流量图,上面每个客户端下载连接的图,这边是整个集群内部状态流量的图,可以看出这个点上,我们把一台机器当掉,模仿是机器的鼓掌当机,同一个核心下另外一个节点流量漂移过来,更主要的是,这个漂移是路由层面,动态路由的效果,用户端感知这个时间点十个连接下载没有任何一个断开,这是我们要追求的效果,集群内部单点故障不会让用户有任何的感知。
我们一个集群四台机器,我们关掉四台当中的三个,故障概率单台机器的概率故障是1%,稳定性两个九,现在已经模仿到了整个集群在六个九情况下的极端概率,就是四台机器当了三台,全部流量承载到一台MGW上,可以看出来,用户所有下载连接没有任何感知的。这个是整个模仿了session同步实现效果以后用户侧的直观感受。
那么故障节点修复以后,上线用户是不是有感知也是我们需要验证的,这个时间点我们恢复整个集群内部四台机器里面三台全部恢复上线以后,流量自动从之前的单点全部均衡到四台机器上,然后流量在集群内部得到均衡以后可以看得出来用户这个时间点上是没有任何感知的。然后这两个连接的结束需要说明一下,我们当时测试的时候打了一个4G的包做十个连接的下载,为了区分图上的一个效果的话,我们做了从一道到两道之间十个连接区分,下载最快的两个连接,4G包测试一个小时直接结束了,和整个没有关系只不过图上的效果。我们这样一个功能可以做到基础设施的四层负载均衡内部30秒同步,对于任何一个单点的故障对用户来说可以无感知。
百万级session迁移的过程当中,miss率可以做到零。除了刚才说的MGW,说一下数据中心内部有DNS服务,怎么做优化,这是用了一下动态协议的用法,可能有一些公司也有一些实践,这是传统意义每个集团DNS服务的配制,相对比较传统,每个数据中心里面会有两台DNSStructure服务器,本机房的配制上会配制两台IP,所有的请求落到这两台Structure上,另外的中心有两台Structure,然后会配IP,各个机房请求自己的DNSStructure,做解析,这是传统的结构,带来的问题是什么?IDC单台机器刚才说的一个两个九,基础服务的稳定性就是两个九,因为当掉以后所有的解析一半是失败的,这个时候可以补救最快这台机器赶快恢复起来,别的更大所有机器的配制刷一遍,终端会更大。这种情况下运维的工作效率和稳定性的保证没法得到更好的体验的。
然后基于此,我们做了一层基于网络动态协议的一个AnyCast布局改造,这是改造后,一个机房两到三台,可以根据机房的负载来看,可以看每个机房的需求,数据根据负载情况来看的,这个和该数据之间跑,这样的话,我们发统一的AnyCastVIP,统一配到这个上面,四个路由作为地址。另外也和核心之间跑,发的四个十的地址,这样本机房的机器上所有的机器全配制四个十的IP,所有的DNS请求走到核心全部下到这三台机器,下到本机房,这个机房路由上优先本机房的转发。先说本机房,当机动态路由协议,直接四个十路由上面直接离线,那么DNSUDP,无状态的,用户没有任何感知,落到这两台,如果这一台机器当机服务落到这一台机器上,这一台机器当机机房就当了,是不是代表机房不可用了?我们全量机房是同步的,这台机房是正常的,三台机器当机以后,下面的机器DNS核心以后,动态路由协议的链路状态的监测,这三台机器全部当机,上面四个十的路由走到超级核心上,超级核心会把自动负载均衡到其他的IDC上,同样是可以解析本机房的主机云,如果做到整个机房的故障都不会影响本地,整个机房的故障代表DNS的故障不会影响本地的DNS解析的服务,稳定性超过六个G。
这是DNS服务,当然利用的一个AnyCast的网络结构,内网没有必要走IOS做转发,直接有一个集群直接到DNSVIP对外提供集群的服务。这是基础服务方面一个是MGW,一个DNS给用户带来直接稳定性高可用的体验。
下面主要说一下我们在网络质量上监测上的一些探索,之前是这样的,可能很多公司也会遇到这种情况,互联网公司来说业务的迭代很快的,包括业务对质量的感知很敏感的,经常会在我们的运维沟通群里面有业务顾问说,刚才网络是不是有错误,业务的运维排查问题的时候,会很头疼,因为看到的是一些日志,顶多看到报错,从内容看到说刚才网络是不是有问题,实际上我们的基础设施运维团队,是很被动的,天天在群里面看到,刚才网络设施是不是有问题,然后来问我们,我们手上没有太好的方式查看,基于监控平台做一些交换机,或者流量采集的一些监控,这些监控代表不了网络质量,所以整个运维还是相对比较被动,业务会反推着问你刚才维护基础设施环境是否有质量的问题。
基于此我们做了内部的尝试和探索,沉淀了一些工具,这是一个结构图,这是做内网质量的探测的拓弧,我们的目标做到我们内部所用的所有网络设备下面的服务器到内部任何一台网络设备下面的服务器之间,网络质量的探测和展示。大概的结构,所有我们的交换机下面选取物理机的埋点,点到点的质量采集,原理比较简单,整个的数据,量级比较大,数据整个上报控制侧,做数据的存储,图形展示以及报警。出来的直观感受就是这样,运维平台上的展示,业务可以直接输入你所怀疑有异常的主机名,我们全部上了虚拟化云平台的,你的主机名输进去以后,可以直接看到,你这台业务在哪台机器上面,在哪台网络下面,然后这是源,这是目的,之前这个时间段内延迟是多少,是直观可以感受到,所有内网的一个ICMP级别的质量对业务全透明,业务有问题排查可以直接在这感受到刚才网络质量的情况,而不是直接在群里面或者去找网络的运维同学去沟通质量的情况,网络的同学同样也可以上面可以感受到刚才查到质量情况,而不是说束手无策的去验证刚才是否有问题。
其实这样的一个结构出来以后,能就觉就是说明运维同学手上有武器,有很多被人挑战的地方,首先做ICMPN对N的采集,大家知道ICMP的采集,最早的这个网络拓弧可以看到,这个圈到这个圈的服务器,可以走的路由,网络设备上ICMP的条数很多的,路由一个机房到另一个数据中心可以走的路由七百多条,所以一个ICMP真实采集并不代表真实感受所走的路径采集,这是被挑战的地方。特别还有ICMP的采集和DCP的转发,质量是有区别的。
基于此我们做了升级,这是现在已经上线的一个全网路由质量监控,同样的还是在一个圈下面做埋点的探测,这一台机器到这一台机器之间,不做简单的ICMP,做TCP,自己写的做一些TCP的P,然后会去向先探测整个我所到的目的地之间有多少种路径可走,构造同样的发包,探测整个TCP的质量,可以覆盖所有业务会走的路由上面的转发质量,这样对于业务来说全覆盖了的。
有一个问题,我们做跨机房和软机房做分离,做跨机房数量指数增长的,所以优先做本机房的质量探测再做一个分层的跨机房的链路探测,所以最后给业务展示出来的效果这样,查询方式一样,员工主机就是这样,但是会告诉你多少路径可走,每条路径怎么样,有一个汇总,展示效果相对来说不是那么完美,现在改进当中,数据量有点大,所以我们在看网络质量,但是实际可以看出同机房四条路由,这一条路由刚才时间段之内延迟有抖动的,做到这个级别用户可以直接感觉是否和网络质量变化有关,做到这个程度基本上我们内部网络的一些调用可能性的情况,质量我们都是会拿到数据,后续会对这些数据基于机房的网络质量的一些,因为这个监控是秒级,十几秒,根据规模有关,十秒以内,会对这些数据做数据的分析,分析内部网络质量,包括网络设备之间对转发性的一些差异的地方。
上面说的基于内网的一些质量探测,公网作为互联网公司来说对于公网的质量依赖也是很重的,经常有业务会说我们哪个地方的网络到达成功率是不是OK的,网络上看看是不是有问题,刚才说的情况,基于此我们做网络的沉淀,网络数据中心到全国各地可以做到每个省的地级市,每个城市有50个以上的不同网段的IP去做确保分段的网络IP做质量的采集,这是全国地图,从北京机房,大家可以看得出来,北京这边,环绕北京最近的地方质量会更好,这也是当时有一天,应该3月份,最近当然也有,南方电信可以很明显的看出来南方电信的质量整体下滑的,会有报警到我们运维同学那里,然后提示对内部业务做提前的通告,不是等着业务找过来确认运营商是否OK。然后在线路上,电信、联通、移动,教育网和鹏博士,这是教育外网的展示,然后一些图。
这样一个外网质量的采集模式,我们有数据中心出去的,以及我们业务到达成功率,相当于说类似于APP的那些请求,因为现在美团的这么多APP上,各个APP的用户从全国各地的上报请求是有一个专门的探测平台对每个APP,每个运营商,每条线路,每个地区的成功率做统计,我们基于这个数据做反向的质量探测,基于数据中心做正向的质量探测,双向的质量探测放在一起可以看到业务处于公网环境的质量。基于整个业务模型以后我们做了一套,在后面拓展了一些对质量整体的大盘,对标我们作为一个云计算公司来说,对标现在是腾讯云和阿里云,我们在华北,这只是华北区,现在延迟什么样的,可以看出来,这个东西实时的,并不代表哪家绝对好,哪家绝对差一些,这个和打点的区域有关,然后就是我们跟各家的一个实时的监控,包括一些质量的对比,这是各家到全国每个省市的延迟分布情况,然后还有一些丢包的情况,这是外网质量大盘,之前只做业务外网质量的通告到可以做行业内的网络质量的一个对比。
上面说的是我们网络上面的一些沉淀,接下来再讲一下资源数据的运营,对于我们来说作为基础设施的运维团队还有一个很大的方面就是怎么向前端业务去输送更多的弹药,我们的弹药就是我们的资源,服务器网络设备的交互,效率上怎么保证,这是自动化的流程平台,流程平台不光限于像大家平常公司里面都会用到一些流程的平台,后台有一套独立的服务器自动化操作的一个框架,然后我们的机器从采购下单以后,到最后交互业务,整个的一套流程自动化的,从机器到之前资产信息录入,上架之后自己走的装机和系统部署,以及监控部署等是自动化的流程,这里面需要网络运维同学参与主要异常的处理,非异常的可以自动交互业务的,这是平台的统计和流程的一些回调,这是给运维同学看到整个单子调用执行情况的改善,这边是统计。
资源交互的话,是我们刚才流程平台去做的一个效率的保证,然后作为基础设施运维的话,一个大头,另外一个大头就是成本,因为我们有数据中心,一些云计算包括基础设施大的部门来说,可能是公司最能花钱的部门,像IDC这种便利、动力环境,极其资源带宽和采购服务器是公司大头的开销,除了人力成本以后基本上就是这些。我们先说电力,其实每太服务器电力数据都是可以采集的,但是相对来说还是比较少有人把这些电力数据做简单的关联,位置关联就可以看到数据中心电力的使用情况的宏观数据,这是我们每天会,当然这个表比较简陋丑陋,后面的数据分析还是在做,这是简单给大家直观看一下我们的数据中心,可以细化数据中心每一个房间,可以看到服务器电力负载情况,我们和运营商签了多少电力,用了多少电力可以看出来,整个基础设施可以优化调整整个电力的负载改造,优化怎么更好降低成本,我们有这个这个机房,员工的机房,大家都了解,电力改进有推进难度,利用率比较低的,一个机构平均利用率有的一个房间只有4%的电力应用率,相对来说自己话语权相对较高的数据中心可以做到90%多,像润泽这种80%、90%没有问题的,再高有风险的,当你的业务一旦分散的,COP超屏有电力风险超电风险的。
这是主推基础设施给混合云提供的服务,基础设施来说一个用户买了一个混合云,我们想让用户掌握数据中心内部感知到我们能提供的一些数据,比如现场的一个实时画面,这是混合云用户已经购买使用的,可以知道所用的这些与现场的画面图我们从数据中心可以传输到用户混合云的控制端可以看得到,以及所处环境的温度和湿度的监控,这是简单的数据截图,这是混合云上面的一些基础设施的角度对用户提供的一些数据的支持,让他感受到,包括电力以及整个的温度环境和现场实时画面的一些改造。谢谢!
来源:CDA数据分析师峰会:大数据与云计算分会场


雷达卡



阅读权限+下载200次/日+产品折扣+免费数据库+免费广告+人才库+海量论坛币
阅读权限+下载40次/日+产品折扣+免费数据库+海量论坛币
京公网安备 11010802022788号







