前往顾页
以后地位: 主页 > 精通Office > 其他教程 >

若何从零搭建一个主动化运维体系

时候:2018-11-22 21:27来源:知行网www.zhixing123.cn 编辑:麦田守望者

对主动化运维体系的需求,是跟着业务的增加、对运维效力和质量的请求不竭进步而产生的。

媒介: 在很多草创公司和中小型企业里,运维还逗留在“刀耕火种”的原始状况,这里所说的“刀”和“火”就是运维职员的长途客户端,比方 SecureCRT 和Windows 长途桌面。

在这类事情体例下,办事器的装置、初始化,软件摆设、办事公布和监控都是经由过程手动体例来完成的,需求运维职员登录到办事器上,一台一台去办理和保护。这类非并发的线性事情体例是限制效力的最年夜停滞。

同时,因为手动的操纵体例过于依靠运维职员的履行依次和操纵步调,稍有不慎便可能导致办事器建设不分歧,也就是同一组办事器的建设上呈现差别。

偶然候,这类差别是很难直接查抄出来的,比方在一个负载均衡组内里个别办事器的异常就很难发明。

跟着业务的生长,办事器数量愈来愈多,运维职员开端转向利用脚本和批量办理东西。

脚本和批量办理东西与“刀耕火种”的事情体例比拟,确切晋升了效力和工程质量。

但这个别例仍然有很多问题。

  • 第一是脚本的非标准化的问题。

不合运维职员写的脚本在所用的编程说话、编码气势和结实性方面存在巨年夜差别,同时这些脚本的版本办理也是一个应战。

  • 第二是脚本的传承问题,职员的离职和事情交代,都会导致脚本无法很好地在运维职员之间传承和再操纵,因为下一个运维职员可能无法了解和点窜前一个运维职员编写的脚本服从。
  • 第三是批量办理东西的挑选。

不合的办理职员挑选不合的批量办理东西必定会带来办理混乱的问题,也无法很好地实现在运维职员之间相互备份事情的需求。

是以,对构建主动化运维体系的请求变得愈来愈火急。经由过程主动化运维体系来实现标准化和进步工程效力,是独一精确的挑选。那么若何扶植主动化运维体系呢?

本案例研究分为三个年夜的方面:

  • 第一个是为甚么要扶植主动化运维体系,就是处理“3W”中的Why和What的问题,即为甚么和是甚么。
  • 第二个是介绍我司各个运维子体系是怎样设想、运行和措置问题的,处理“3W”中的How的问题,也就是怎样去做的。
  • 第三个是对我司在主动化运维过程中碰到的一些问题的思虑,做一个总结。

一、扶植主动化运维体系的启事

先来看一下我们为甚么要扶植一个主动化运维体系。起首来看运维碰到的一些应战,以下图所示。

运维面对的应战

第一个是游戏的需求。它表示为三个方面:

  • 一是游戏数量多,我司现在运营的游戏多达近百款。
  • 二是游戏架构复杂。游戏公司和一般的互联网公司有一个很年夜的辨别,就是游戏的来源可能有很多,比如有国外的、海内的,丰年夜厂商的、小厂商的;每个游戏的架构可能不一样,有的是分区制的,有的是集合制的,林林总总的需求。
  • 三是操纵体系种类多,这与刚才的环境近似,游戏开辟者的背景与编程喜好不一样,会有Windows、Linux等。

第二个是在硬件环境方面,首要表示为办事器数量多、办事器型号多。

因为公司从建立到现在有十几年的时候了,在这个过程平分批、分期推销的办事器几近高出各年夜OEM厂商的各年夜产品线,型号多而杂。

最后是人的身分。我们在扶植主动化运维体系过程中,有一个比较首要的考虑点是人的身分。

如果年夜家的技术才气都很强,很多时候一小我可以完成所有事情,可能也就不需求主动化运维体系了。

恰是因为每个运维职员的才气不一样,技术程度良莠不齐,乃至是运维习惯和东西也不一样,导致我们必必要建立一套标准的主动化运维体系,来晋升事情效力。

2、扶植主动化运维体系的目标

再看一下扶植这套主动化运维体系的目标,也就是说我们的准绳是甚么?

笔者将主动化运维体系的扶植目标总结为四个词。

  • 第一个是“完整”,这个体系要能涵盖所有的运维需求。
  • 第二个是“简练”,简朴好用。如果体系的操纵流程、操纵界面、设想思惟都比较复杂,运维职员的学习本钱就会很高,利用的结果是会打扣头的,体系的才气、阐扬的效力也会是以打扣头。
  • 第三个是“高效”,特别是在批量措置或履行特定任务时,我们希望体系可以或许及时给用户反应。
  • 第四个是“宁静”,如果一个体系不宁静,可能导致很快就被黑客领受了。所以宁静也是首要的身分。

3、主动化运维体系的布局和运作体例

下图所示是我司以后主动化运维体系的几个子体系,我们来看一看它们是怎样结合起来事情的。

起首办事器会经过主动化装置体系完成装置,然后会被主动化运维平台领受。主动化运维平台会对主动化安检体系、主动化客户端更新体系和办事器端更新体系供应底层支撑。

主动化数据阐发体系和主动化客户端更新体系会有关联关系。主动化数据阐发体系会对主动化客户端更新体系的成果赐与反应。

主动化运维体系布局图

下面我们来看一下每个子体系是若何设想和事情的。

3.1、主动化装置体系

说到主动化装置,年夜家可能其实不陌生,我们刚才说到应战是“两多两少”,型号多、操纵体系多,但是人少,可用时候也比较少。

以下图所示,全部流程采取通用的框架,起首由PXE启动,挑选需求装置的操纵体系范例(装置Windows或Linux),然后按照Windows体系主动辨认出需求装置的驱动。办事器托付用户之前,会进行根基的宁静设置,比方防火墙设置和封闭Windows共享,这在必然程度上进步了宁静性,也减少了需求人工做的一些操纵。

主动化装置流程图

3.2、主动化运维平台

当办事器由主动化装置体系装置完成今后,就会被主动化运维平台领受。主动化运维平台是运维职员的功课平台,它首要处理的问题就是因办事器、操纵体系异构并且数量特别多而带来的办理问题。操纵体系是八门五花的,我们在设想体系过程中考虑了以下几个身分:

把全部体系的用户界面设想成基于浏览器的架构。运维工程师不管甚么时候何地都可以登录办理体系进交运维操纵,如许的话就比较便利。由Octopod办事器对被操纵的机器公布指令。

同一办理异构办事器。年夜家之前可能对Windows忘恩负义,其实Windows也能够管得很好。我们利用开源的SSH体例办理Windows,如许便可以对体系进行批量的补丁更新,还可以做批量的暗码办理和操纵。

充分操纵现有和谈和东西。这个平台的特性是所有的体系利用SSH办理,而不是本身开辟一些Agent,这也表现了主动化运维的观点。

很多时候我们没需求从头造轮子,即便本身造出一套客户端的别例,年夜部分时候也并没有在生产环境里获得严格的考证。

而SSH和谈本身已存在很多年了,并且已在我司利用了很多年,该出的问题已出了,相对造轮子,利用SSH更加不变,更经得起磨练,利用起来更便利。

3.3、主动化安检体系

下一个体系是主动化安检体系。因为我们的子体系比较多,业务也比较多,怎样设想一套体系去保证它们的宁静呢?这里主如果两个体系:主动化安检平台和办事器端。

先来看主动化安检平台。游戏公司和一般的互联网公司有一个辨别,就是前者需求给玩家发送很多的客户端(特别是有的客户端比较年夜),或补丁文件,去更新、下载和装置。

如果这些文件内里呈现病毒和木马,将是一件很糟的事情,乃至会对业务和公司的名誉造成卑劣影响。当这些文件被发到玩家电脑上之前,必须颠末病毒检测体系检测,确保它没有被注入呼应的病毒代码。

再来看办事器端,主如果经由过程宁静扫描架构来保证宁静。

宁静其实不是一蹴而就,与日俱增的。如果不对体系持续地查抄、检测、探测,那么你的一些误操纵会导致辖德澉露在互联网上,或是透露在歹意抨击打击者的眼皮之下。

经由过程一种主动、自发的宁静扫描架构对所有办事器进行宁静扫描,就可以在很年夜程度上躲避如许的问题。

举一个例子,客岁我们碰到过一个环境,某款互换机ACL到达必然的数量的时候,就完整见效了。

如果没有相关的配套机制去查抄和检测,那么你的办事器、你以为庇护得很好的端口或是敏感的IP可能已透露。所以,经由过程这类主动的探测可以减少很多体系的或是报酬的宁静问题。

3.4、主动化客户端更新体系

游戏是有周期性的,特别是在游戏公布当天或有版本更新的时候,这时候辰玩家活泼度很高,下载行动也是比较多的,但是平常平凡的更新和下载带宽可能其实不年夜,这也是游戏很明显的特性。

这个特性对我们构建如许一个分发体系提出了很年夜的应战。

第一个应战就是在岑岭时游戏产生的带宽可能到达数百GB。

第二是很多小运营商或中小范围的运营商会有一些缓存机制,这个缓存机制如果措置得不好,会对业务造成影响,也就是不法缓存的问题。

第三是关于DNS调剂的问题。

DNS调剂本身是基于玩家本身的Local DNS的机制剖析的,会有调剂不精确的问题。

第四是DNS污染,或是DNS TTL的机制导致调剂不那么活络和精确。针对这些问题,我们有下面两套体系来处理。

第一套是Autopatch体系,它处理的是年夜文件更新的下载问题,再就是多家CDN厂商流量调剂。其操纵流程也比较简朴,由运维职员上传文件、安检,然后同步到CDN,由CDN分发到相关边沿节点,最后解压文件。

刚才说到游戏的周期性特性,就是平常平凡带宽不是很年夜,但是在某个节点的时候,或是重年夜活动的时候,带宽比较年夜。

如果本身构建一套CDN体系,可能不是很划算,所以我们引入海内多家比较年夜型的CDN厂商调剂资本。我们经由过程302的体例调剂,而不是把域名给此中一家或几家。

因为直接利用CNAME的话很难按比例调剂,特别是带宽年夜的时候,一家CDN厂商处理不了,或是一产业生部分毛病,需求疾速切除。

而经由过程集合的调剂体系便可以实现按比例调剂的服从。用户发过去的所有请求,起首要在我们这边进行调剂,但是本身其实不产生直接下载带宽,而是经由过程相关算法,按比例和地区调剂给第三方的CDN厂商,然后玩家实际是由第三方CDN厂商节点去下载客户端的。

第二套是Dorado体系。方才讲到小运营商或某些运营商的不法缓存机制会对业务造成影响,那么对某些关头的文件,如果缓存的是一个旧版本,可能会造成很年夜的问题。比如我们的区服列表,如果我们办事器端增加了新的区服,在客户端没有闪现出来,就导致玩家没有体例进入到新的区服去玩。

针对这些问题,我们设想了外部代号为Dorado的体系,因为这些文件本身是比较小的,并且数量也不是特别多,但是需求用HTTPS加密,经由过程加密躲避小运营商的缓存问题。

所以我们对这些关头文件,全数有自有节点,在节点上支撑HTTPS加密体例,躲避小运营商缓存带来的一些问题。

3.5、主动化办事器端更新体系

我们采取的办事器端更新形式也是一种比较传统的近似于CDN的体例,是由目标办事器经由过程缓存节点到中心节点下载,由缓存节点缓存节制,如许可以减少网间传输的数据量和进步效力。

我们在设想这套体系的时候,也想过用P2P去做。年夜家想P2P是很炫,又节流带宽,但是用于生产环境中年夜文件分发的时候会有几个问题。

一是宁静节制的问题,很难让这些办事器之间又能传数据又能进行宁静端口的庇护。

二是在P2P里做流量节制或流量限定也是一个应战。所以终究我们采取了一个看起来比较简朴的架构。

3.6、主动化数据阐发体系

说到客户端更新,其实更新的结果若何,玩家到底有没有装置成功或进入游戏,很多时候我们也很茫然,只能看日记。

但是日记内里的很多信息是不完美和不完整的。下载客户端的时候,如果看HTTP的日记的话,内里是206的代码,很难计较出玩家到底完整下载了多少客户端,乃至他有没有下载上去,校验成果是不是精确,也很难晓得。所以我们终究设想了一个主动化数据阐发体系,目标就是阐发从用户开端下载到他登录游戏,数据究竟是怎样转化的。

最抱负的一种环境是用户下载客户端今后,就进入了游戏,但这是一个抱负环境。

很多时候,比如因为收集不好,致利用户终究没有下载成功,或是因为账号的一些问题,用户终究没有登录到游戏内里去。

所以,揭示出来的数据就是一个漏斗状。我们的目标就是让终究登录的用户数靠近于开初下载客户端的用户数。

我们来看一下体系的架构。起首由玩家这边的下载器或是装置客户端,游戏客户端内里集成一些SDK,对任何一个关头点,比如“下载”按钮或“停止”按钮的数据都上报,当然这内里不会触及敏感信息。上报今后会有Tomcat集群,集群措置今后会将数据写入MongoDB。

看一下这个游戏在引导过程中有甚么问题,左边的这一列它分为三个文件,有一个是3MB,有两个是2G多的文件,其实年夜家可以想像一下。很多时候玩家看到小的文件就把小的文件直接下载装置了,但是实际上其实不完整。这一点也奉告我们,其实很多时候在运营或是业务方面,在引导方面也是要比较公道才气去躲避失落一些问题。

3.7、主动化数据备份体系

我们第一个版本的备份体系,它的设想和实现是比较简朴的:不合的机房会有一台FTP办事器,本机房的数据写入FTP办事器,然后写入磁带,但是如许就导致磁带是分离的,没有集合存放的处所;别的,基于FTP的上传会有带宽乃至有延迟的请求。

后来我们设想了一个集合的备份体系。它首要处理了以下两个问题。
第一是简化建设。我们所有机房的全数建设,用一个负载均衡器的IP便可以了,当客户端需求上传文件时,经由过程负载均衡器获得实际上传的地点,然后上传文件,由左边第二个框内里的办事器进行领受,并且按照MD5值进行校验,如果校验没有问题,就转到Hadoop的HDFS集群内里去。目前这个集群有数十PB的范围,每天上传量有几个TB。

第二是进步传输效力和成功率。年夜家会想一个问题,在中国,收集环境十分复杂,运营商之间存在隔阂乃至是壁垒,导致收集不不变,丢包和延迟的问题是怎样处理的呢?如果基于TCP传输年夜文件,实际上存在单个连接上带宽延时积的限定。

这里我们立异的是,客户端的上传采取UDP和谈,UDP本身没有任何节制,说白了就是客户端可以肆意、用力地发文件。终究会由办事器端查抄你收到了哪些文件片段,然后告诉客户端补传一些没上传的片段便可以了。基于这类体例能躲避很多因为收集颤栗或收集延迟比较年夜而导致的问题。当然,在客户端做流量节制也是可以的。在碰到问题的时候多想想,或许能找到不走平常路的处理计划。

3.8、主动化监控报警体系

再看一下流戏的主动化监控报警体系(以下图所示)。游戏的架构中有游戏客户端、办事器端、收集链路,所以必必要有比较完整的体系进行全方位、平面式的监控,才气包管在业务产生问题之进步行预警,或在产生问题时报警。

对机房链路,有IDC(Internet Data Center)的收集质量监控;在办事器、收集装备和硬件方面,我们会做办事器的健康查抄、机能监控,和收集装备和流量监控;

在体系法度方面,我们会汇集和阐发体系日记;在游戏办事器端利用方面,有办事器端的法度监控;在客户端方面,我们会汇集植入的SDK做下载更新后的结果,和汇集崩溃的数据。

作为运维职员,我们考虑问题或设想架构的时候,视角不克不及仅范围于一个技术方面,或选用多炫酷、多么牛的技术,要想想技术在业务方面的架构,或可否经由过程业务目标监控我们的运维才气与运维体系。

在游戏里,有一个很首要的目标就是在耳目数,经由过程监控在耳目数这个业务目标,便可以晓得体系是不是事情一般,是不是是有漏报、误报的环境,因为很多时候任何一个环节出了问题,终究都会表现在业务上,在产生价值的数据上。

所以我们有一套监控在耳目数的体系,每个游戏上线之前会接入这个体系,把在线的人数及时聚集到体系内里。如果产生异常的颤栗,体系中都会有所显现,也便可以晓得是不是产生了问题。

以上讲的是一个框架,下面我们看一下细节,怎样做办事器的监控。起首由运维工程师在监控战略平台建设监控战略,监控战略平台会将这些数据格局化成相关格局,然后推送给主动化运维平台。

主动化运维平台会判定是这些数据是外部来的,还是长途检测到的;是收集摹拟的,还是本地的监控获得的。

比如流量、本地过程的监控、本地日记的监控,会别离推给长途探测办事器,或游戏办事器本身,然后由它们上报数据。数据上报今后,按照运维工程师建设的阈值,会触发相关的报警,然后告诉运维工程师进行相关措置。因为固然游戏多种多样,操纵体系八门五花,但是总有一些年夜家可以公用的东西,比如监控的模板或监控的战略,我们对办事器的东西也进行了整合汇总。

年夜家可以看到我们内里有很丰富的插件,运维职员只需挑选相关的插件,配一下阈值和周期,便可以节流时候和学习本钱,进步建设战略的效力。当建设战略完成今后,直接绑定到想要监控的办事器上便可以了。

总结 我们从2000年初到现在一向在做主动化运维体系,对畴昔进行总结,我感觉有3个方面可以供年夜家参考。

第一是按部就班的准绳,特别是中小公司或草创公司,很多时候其实不需求一个“高年夜上”的体系。聚焦以后的问题,把以后的问题措置好,前面的问题也就水到渠成。如果一开端设想的体系很庞年夜、服从特别丰富,会导致一些无法节制的场合排场。比如这个体系可能最后做不下去了,或因为耦合性太强,开辟节制不了了,或项目因为经费问题停顿了。

但是如果一开端的目标是处理一些特定的问题,有针对性,那么推动起来也会比较简朴。

在我司的主动化运维体系扶植过程中,我们起首构建的是一个根本的办事器批量操纵平台,先把一部分需求反复履行的事情搬到平台下去,再根据运维的需求丰富这个操纵平台的服从和晋升效力,最后把周边的体系打通,相互对接,构成完整的主动化运维体系。

第二是考虑可扩展性。设想体系的时候,服从或设想方面可能不消考虑那么多,但是要考虑当办事器数量产生比较年夜的扩展时,体系是不是还能支撑,比如数量级从十到百,或上千了,这个体系是不是还是可用的。

第三是以合用为目标。这在我们体系中也是有表现的。

很多环境下,市道上可能已有比较成熟的和谈和东西,拿来评价看看它们在生产环境内里是不是可用,如果能用就直接用,没需求本身再去做一套。

本身做的这一套东西,很多方面没有颠末考证,可能会带来宁静问题。

基于成熟的和谈和框架去做,可以晋升效力,包管不变性和宁静性。在“主动化运维平台”一节可以看到,我们并没有本身从头开端研发一套Agent植入到被办理的办事器上,而是用了开源的SSH和谈和成熟的OpenSSH软件。

这表现了优先考虑开源计划加一部分二次开辟而不是反复造轮子的思惟。

------分开线----------------------------
标签(Tag):主动化运维体系
------分开线----------------------------
保举内容
猜你感兴趣