摘要：清华大学数据中心运维那点事儿我徐葳显然是个科研人员，同时还管理很多行政事务等，但有些人命不好，就是系统管理员的命。最后，数据中心现在如此复杂，怎么能再利用一些人工智能的东西放在数据中心里帮助运维。
嘉宾介绍：徐葳，清华大学交叉信息研究院助理院长，青年千人学者，博士生导师，UC Berkeley 计算机系 PhD，曾供职于 Google。主要方向为基础架构的监控，日志等，目前以分布式系统以及人工智能等方向为主、包括人工智能、隐私保护、反欺诈等内容。
以下为徐葳在数人云PaaS Innovation 2017，构建灵动新IT大会上的演讲实录。
清华大学数据中心运维那点事儿我（徐葳）显然是个科研人员，同时还管理很多行政事务等，但有些人“命不好”，就是系统管理员的命。所以花了很多时间去管一个IT系统，学院的机房、云平台，基本上夜里大家都睡了，还要登陆上去看看日志，该修点什么就修点什么，我这个人有个毛病，就是看不得机器坏了，看不得什么东西不行，就得马上修好。
清华有系统管理员，就如同我一样都有系统管理员病，很喜欢做系统管理，但他们都是白天上班，因为没有加班费，所以不好意思让人晚上加班，所以晚上一般都由我来管。
这个数据中心做的是人工智能，现在人工智能很热，科研领域清华做的非常前沿，这是最最聪明的应用，但是跑在最最傻的基础架构上。
因为曾经供职于Google，非常想在清华复制一套Google的架构，但这并非一两个人就能开发出来。所以，即便在Google，唯一不能用的地方就是系统运维领域，这是灯下黑，这也是本次讲演的主题叫：“数据中心与智能”。
今天给大家分享几个方面：
首先，数据中心运维，这是和百度合作的一个数据分析的事情，会给大家展示几个有意思的结果。
其次，讨论下现在的新架构，Deep Learning深入学习，如何维护这个框架，怎么把数据中心改造成可以进行支持。
最后，数据中心现在如此复杂，怎么能再利用一些人工智能的东西放在数据中心里帮助运维。
如何平衡硬件+软件+运维？首先，这是和百度合作的一件事，百度有很多的机器，有个部门叫硬件运营部，他们收集了很多故障报修，各种产品线，各种不同的产品报修了硬件，硬件运维部就派人去处理一下，大部分处理的方法就是找厂商换新的。所以叫做出了问题的Ticket，几年内积累了29万个，我们可以帮助它的地方是，到底什么东西坏了，拿出来看看，什么时候报修的，大概什么故障，什么部件坏了，这里有很多结果，但因为时间关系，就不挨个赘述了。
报修了一个故障，多长时间会修？如同百度这样管理非常好的公司，报修之后多长时间会有人去处理？不是说修好它，修了不一定能够修好，但至少是去修了，该换什么就换什么，硬盘报错，坏了，就换一个硬盘。
具体时长看起来会非常奇怪：平均需要42天报完错可以修，中位数的修理时间是6.1天，其中有10%的是140天之后仍然没有修，但是没人修并不代表永远都不要这个东西了，过了200天以后仍然有人去处理它，而并没有忘记。
感觉这个时间过长，到底是因为什么？因为机器太多了？又或者系统管理员太忙了？其实未必。
因为如百度、Google这样的公司，系统架构非常容错，硬件出问题是不可避免的，它坏了，既然能容错，就像四个轱辘掉了一个还能跑，为什么要去修呢？所以逻辑是有一个超级容错的系统，在运维时对故障就没有那么敏感。从好的方面来说，可以省钱，因为一次修一个也得跑一趟，修若干个也得跑一趟，因此还不如一次批量的修。
当然硬件损坏无法避免，是否能降低一些容错的复杂性呢？大家目前越来越多的都在讨论这件事，就是三者的平衡，运维的可靠性、软件的成本、硬件的成本之间的三者平衡，现在越来越重要了。
另外，不管如何运维，运维的系统都是非常重要的，任何运维都不是登到界面上去敲几行命令，然后就派出一一件事，这个都是无法做到的，所以不管如何，系统的运维，从一个地方生成这样配置的操作，从一个地方生成的部署，都很重要。
以上讲的是硬件、软件、运维，这三个部分成本如何平衡，现在这个状态下，尤其是大规模的数据中心，有可能和过去小的企业数据中心不同。
基于数人云的Docker管理环境现在深度学习火了，每个人都想要深度学习的机器。最开始一个人要的时候，没关系，从桌面虚拟机集群拆出两台来，装上GPU，自己去用。现在这样的人多了，装了60几块GPU仍然不够，所以这种集群如何共享这60几块GPU，非常麻烦。
后面做了一个什么事情呢？找数人云做GPU虚拟化，虽然GPU支持虚拟化但太贵所以不买，买的都是消费者级别的GPU，因为便宜。当它不支持虚拟化时联合容器，所以将GPU集群上放上了Docker，又找了数人云，帮助开发一个数人云的管理系统，是基于Mesos的开源软件。同时写Mesos的人是我在伯克利的同学，因此对它的印象很好。
将来的就是这样的架构，好处是解决了一个问题，即服务封装，DeepLearning这事真的不复杂，如果你玩过，会发现很简单，其实就是找一个开源的软件框架，上面有很多模型，将其下载下来，都是开源的，这些模型甚至都是训练好的，可以跑人脸识别应用，或者跑其他的什么识别应用，虽然没有专业跑的好，但也不会太差。
但它的问题在于是基于框架，尤其在中国，版本不一样，升级版本升级的特别快，随便动一个升级，其他人都烂了，而不同人就要不同的版本，为什么，因为它下的那个模型是基于某个特定版本开发的，在别的版本上跑不出来，所以在这种情况下，大家去到无数多个配置好的镜像和环境，这个场景挺好，Docker、数人云有它的界面，将这个东西配置好，这种Docker配置的这种Docker，只有这个Docker里面用的是那种版本的东西，因为Docker是一层一层的，不用做那么多镜像，只有一点点区别没有关系，那么多借点有一点点区别，占不了那么多空间，好多镜像，各自用各自的Docker。
所以这解决了一个叫软件分发部署的问题，但有一个问题，总得有训练数据，有点什么东西在里面，完成后改了配置等等，这些东西不可能存回到那个镜像里头去，就想那怎么办呢？可能过了两个星期之后还用呢？所以就不上Docker，留着，等两个星期后再说，但两个星期后做别的项目去了，机器就卡在那里，所以这是个问题，存储它的周边结果存在哪里，是个好大的问题。
简单的方法，有OpenStack，集群上500块硬盘总是有的，挂上NFS，每台机器上面有一个Ceph的NFS，把这些东西对接好，想把这个东西存在那个上面保证安全的，关了以后重启时再挂回来，设计了这样一套存储。
那有什么问题呢？DeepLearning的模型也很大，有些人直接在上面跑，本想让它存储一个备份数据用，跑到上面做一下其实还是存在本地。
所以后来自己改造了存储的架构，做了一个开源项目Alluxio，也是伯克利实验室的一个同学做的。
Alluxio缓存非常有用，它还为Ceph和NFS适配了一个接口，还有Hadoop集群，HDFS里面也有几百块盘，将这三种东西适配城了两个借口，适合放在Docker里面，也适合放在Hadoop里面，且它加了些缓存，这样用机器人内存吸收了很多流量，上图就是大概的基本架构。
HDFS也可以支持，同时也能顺便支持Hadoop，但是如果有一些大的文件，愿意用HDFS的，就用HDFS。
有写机器内存还蛮多的，就是当年趁内存时买了一些内存，还是很有用的，可以将内容缓存住。分布式内存很有意思。
用人工智能帮助数据中心运维最后说一下很多做DeepLearning的程序，这张图片解释了一个词“复杂”，OpenStack觉得自己很干净，为什么？拿个笔都能画出来，但是这张图很复杂，复杂的原因不光是因为有这么多图，凡是看见的都是数据库，数据库是一个持久性的状态，每个组件里都有自己持久的状态，那如怎么保证一致？讨论了这么久分布式系统的一致性，它一旦跨了组件，尤其是跨了开源项目，谁也不会再说这件事。
但若组件坏了，里面还有一个复杂的结构，它一层一层的封装起来，所以什么东西坏了，你可能根本不知道，没坏的时候什么都特别好，但坏了就会很麻烦。
我是个很好的系统管理员，这点特别有信心，但是搞不定这个，因为我不是每天都在配这个，记不得这些东西到底在什么地方，随便查一个什么东西，后面的参数那么长，咱们记不住，但别人天天都在做当然可以记住。
那么，如何能动呢？我们说通过挖掘日志、系统里的状态、跑一些系统里的命令、看一些系统里的数据库，在里面找一些相关的事情，这是纯从样子上找到的，跟语义没有关系。比如ID长那样，那个ID就是ID，IP地址就是IP地址，将这些东西都找在一起，把这些关联性插在一起，就能生成知识图。
另外，为什么三台机器一起坏了，有可能用户只看到一台机器坏了，但其实另外两台也是如此，因为它坏的原因是一个物理机，要坏肯定是三台一起坏，所以都可以找到系统里的一些东西，这有多少个节点？看这个系统看三天，120台物理机不算大，待该有60多个存储的借点，120多个虚拟机的节点，大概出来的结果是几千万个状态，如上图所示，所以可以想象为什么这东西老坏。
最后总结一下，运维是个什么样的过程？刚才说到DevOps，过去的系统管理员如何适应DevOps是一个非常大的挑战，因为DevOps，运维的人是靠开发程序来自动化运维数据中心的，这是必然的趋势，听起来都对。但DevOps推广起来非常难。
DevOps想要推行，一定要把DevOps这些东西的接口配置到过去的系统管理员能懂的那些地方，基本的意思是，预生几个命令行，别说那么多分布式的东西，感觉就是几个配置文件，点点什么东西，这个接口怎么配置，是一个非常大的挑战。
以上是小数整理的徐葳教授在PaaS Innovation 2017上的演讲实录，后台回复“1116”即可下载本次大会的PPT资料。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/19664.html
摘要：本篇文章内容来自年链家网大数据部资深研发架构师李小龙的案例分享。编辑李小龙链家网大数据部资深研发架构师，负责大数据工具平台化相关的工作。导读链家网大数据部门负责收集加工公司各产品线的数据，并为链家集团各业务部门提供数据支撑。 本篇文章内容来自2016年TOP100summit 链家网大数据部资深研发架构师李小龙的案例分享。编辑：Cynthia 李小龙：链家网大数据部资深研发架构师，负责...
摘要：本文为来也联合创始人兼胡一川老师分享的吾来对话机器人解决方案案例实录。基于吾来对话机器人解决方案，我们为中国移动打造了在线智能客服及个性化推荐服务。基于吾来对话机器人解决方案，我们为学旅家打造了销售线索生成机器人。 showImg(https://segmentfault.com/img/bVblRIN?w=1080&h=720);本文内容节选自由msup主办的第七届TOP100sum...
摘要：开放生态计划，回馈社会阿里巴巴全球运行指挥中心掌门人沈乘黄首先分享了智能运维在阿里巴巴线上故障管理领域的应用经验。 摘要： 为响应马老师家国情怀，世界担当的号召，开放AI+生态计划，将让集团内部服务过程中积累下的技术与经验更好地回馈社会，任何企业或合作伙伴均可以简单方便的接入阿里巴巴智能故障管理平台，通过对接入数据的训练学习实时提供异常检测、关联分析、根因定位的能力，使原有的IT管理模...
摘要：导读为数人云系列活动专题，本文是月日北京站线下活动当西方的遇上东方的互联网中京东金融王超老师的分享。王超京东金融企业高级目前在京东金融平台负责一个人左右的应用运维团队团队，也曾负责人人网团队。 导读：[GO SRE！] 为数人云SRE系列活动专题，本文是3月4日北京站线下活动当西方的SRE遇上东方的互联网中京东金融王超老师的分享。 他将从SRE，Devops， PE间的关系开始，介绍企...
摘要：导读为数人云系列活动专题，本文是月日北京站线下活动当西方的遇上东方的互联网中京东金融王超老师的分享。王超京东金融企业高级目前在京东金融平台负责一个人左右的应用运维团队团队，也曾负责人人网团队。 导读：[GO SRE！] 为数人云SRE系列活动专题，本文是3月4日北京站线下活动当西方的SRE遇上东方的互联网中京东金融王超老师的分享。 他将从SRE，Devops， PE间的关系开始，介绍企...
阅读 3369·2023-04-26 02:10
阅读 3016·2021-11-25 09:43
阅读 1038·2021-11-22 15:25
阅读 1526·2021-09-22 10:02
阅读 1947·2021-09-08 09:36
阅读 722·2021-09-06 15:02
阅读 3247·2019-08-30 15:55
阅读 500·2019-08-30 13:58
