某科技研发云计算心酸史之工作总结.docx

《某科技研发云计算心酸史之工作总结.docx》由会员分享，可在线阅读，更多相关《某科技研发云计算心酸史之工作总结.docx（27页珍藏版）》请在优知文库上搜索。

1、某科技研发云计算心酸史之工作总结（2011年11月2012年9月）虚拟化基础架构业务部王毅2012-9-24目录1 .概述32 .项目41 .1云计算服务底层核心42 .2云计算服务管理系统112.3云计算服务监控系统142.4弹性计算应用152.5云计算服务计费系统162.6云计算服务用户中心系统172. 7云服务网站173. 8云服务网站内容管理系统184. 9企业私有云实体机柜操作系统185. 10企业私有云实体机柜监控系统193 .团队建设193. 1初期204. 2中期225. 3后期274 .总结291.概述从2011年11月份至2012年九月份，我主动要求同意公司分派的云计算开源

2、软件OPenStaCk的研发任务,到至今已经完成云计算产品服务的大部分功能，并基于已经研发出来的功能生产出一系列的软件产品共花了11个月的时间。在这11个月的时间里,不管是关于产品项目的开发、云计算底层服务研发，还是团队建设等方面都遇到了不一致程度的问题与困难。虚拟化基础架构业务部从刚刚开始的IaaS组”到现在成为部门，人员也由最初的四个人进展到现在的13个人。下列是我从项目与团队建设两个方面着手，将问题融入到项目与团队建设当中来进行虚拟化基础架构业务部的工作总结。2.项目目前虚拟化基础架构业务部围绕着云计算底层服务的研发所完成的项目比较多，要紧包含云计算服务管理系统-PUBECM、云计算服务

3、监控系统-PUBECC、弹性计算应用-ECA、云计算服务计费系统-CSBS、云计算服务用户中心系统-CSlJC、云服务网站-CSNT、云服务网站内容管理系统-CSMS、企业私有云实体机柜操作系统-PRVECM、企业私有云实体机柜监控系统-PRVECC等。事实上，作为云计算服务底层的研发工作，也能够算是一个要紧的项目，毕竟它是我们云计算服务底层的核心。2.1云计算服务底层核心2011年11月，由于当时我还在杨颖部门下作为一个组的组长，我们所同意的任务是ESDP的开源与ESDP的开源网站的开发。我们组准确的来讲一共只有四个人，在接触了云计算服务开源软件OPenStaCk以后，由于我跟同组的凌志对O

4、PenStaCk的云存储部分“swift”从安装到使用都已经进行完成，因此也不得不对OPenStaCk的虚拟机部分对晓明进行辅助性工作。当时云计算开源软件OPenStaCk给我的感受是务必集中精力，才能够顺利的进行，因此我主动要求承接云计算服务开源软件OpenStack的研发工作。在研发初期，我们要紧的精力还是关于OPenStaCk的集群式安装部署，由于OpenStack是一个开源性的软件，除了它自己的开源项目，包含云存储（swift）、云虚拟机（nova）、镜像服务（glance）、统一身份认证系统（keystone）、管理系统（当时被叫做dashboard,后来改称之“horizon）之外

5、，还包含其他的一些开源的软件项目服务。如：数据库服务（mysql）.时钟服务（ntp）消息队列服务(rabbitmq)虚拟服务器远程服务(noVNC)网络服务(network)、访问工具(ecua)、卷组服务(volume)等等。各个服务之间首先务必安装正确，在安装正确的基础之上通过配置文件的相互配置才能够达到想要的功能效果，除此之外各个服务之间的安装还存在一个顺序的问题，因此要顺利的安装集群部署就需要反复的实验，为了保证实验的正确性与准确性，我们有的时候不得不要求将服务器进行重新格式化；之因此格式化的要紧原因是卸载往往有的时候是无法卸载干净的，同样的安装过程，关于卸载的服务器有的时候能成功；

6、而有的时候却成功不了，这大大干扰了我们的安装思路。后来公司不同意进行服务器的重新格式化，原因是服务器所在集装箱的机柜不能够经常反复的开启，对服务器机柜内的温度有很大的影响，容易造成服务器的损坏；由于服务器当时在八角楼C4机房，我们只有使用的权限，关于有的时候所发生的服务器死机需要重启等工作，我们只能间接的通过网络部来配合进行完成，而网络部负责这项工作的王炜辉的工作也很忙，我们很多时候不得不进行等待，这也给我们的工作带来了一定的困难与烦恼。当时我们服务器在机房中一共拥有20台服务器，为了能够在沟通与管理上方便，我针关于服务器进行了从1#20#的编号，其中五台服务器是DELL的R410服务器，其他

7、服务器是2GB的内存配置。为了保证安装脚本在我们自己掌控下顺利进行，我决定将八角楼的服务器中的1#机与2#机搬到了办公地点作为云存储的脚本安装及功能测试；后来张亚丽组的张志楠与张贺军的加入所带来的两台惠普服务器成为了办公地点虚拟机的脚本安装及功能研发与测试的环境，通过这四台服务器构成了我们的办公地点的实验环境。但是为了能够完全解决OPenStaCk底层各项服务之间的搭配工作，能够准确的找到问题的出现位置，锁定服务目标；我采取了将服务器各个服务单独存放至一台物理服务器当中，来进行功能性验证与观察。准确的来讲在C4八角楼机房里有18台服务器供我们使用，但是由于不能够经常性的重新格式化服务器与经常性

8、的进入服务器机房，因此我们关于C4机房中的18台服务器的使用非常慎重，当然也大大影响了我们的工作效率。OPenStaCk的官方网站，只是介绍了表面层次上的大体原理，与各个服务之间的相互作用服务，但是像ntp,rabbitmq这样的其他开源服务是没有介绍的，我们所找到的线索完全得益于从网上下载某些志同道合的网友所提供的安装部署文档；但是想要达到与解决各个服务以单独物理服务器提供服务的目的，这项工作仍然非常的艰难。为了避免机房服务器的重新安装，我下令让研发人员在自己的台式机上通过VirtUalbox安装虚拟服务器，我们自己的台式机箱只有2GB的内存，最多也就能够跑三台虚拟机，因此只能在这三台虚拟机

9、上跑安装脚本，另外由于我们的台式机CPU等配置不支持虚拟化，因此我们只能够通过返回的命令行提示来确定是否安装成功，但创建虚拟机是得不到任何验证的；同时我们只能关掉一部分已经安装了虚拟服务器后再跑其他的虚拟服务器，花在查看上的时间非常多，更不要说再遇到问题与解决问题了。在这个工作过程的进行当中，我们实验环境服务器所在机柜的PDU坏了，关于PDU的采购花了很长一部分时间，大概有一个月左右，这也导致了我们的工作无法在实验环境的18台服务器中进行。我们只能在自己的台式服务器里的虚拟机中跑我们的脚本。在初期的过程中，我们并不敢跑大的虚拟机镜像，而是使用了OPenStaCk官方没有操作系统界面，只有命令行

10、的小型UbUntU镜像。在整理与跑通安装脚本并等到实验环境的PDlJ修复后,我们才得以反复进行我们的安装脚本的实验，这个时候我们的卸载脚本也已基本成熟。能够说安装部署方面的问题已经基本上得到熟悉决。公司还要求能够自动进行安装部署，为了实现这个目标，我们将实验环境的12#服务器当作我们安装部署的资源机环境，安装部署资源大概占到了40GB左右。之因此需要一个资源机，是由于在我们的安装过程中，经常遇到了版本不统一与不一致所导致的无法安装成功，究其根源在于使用apt-get的方式安装都是使用网上资源进行下载后的安装，地址是一样的，版本却改变了。OPenStaCk当时还相当的不成熟，源代码更新比较快，同

11、样的安装地址，昨天还能够正确安装并安装成功，转过天来就会出现有些命令都执行不通的情况出现,Keystone（身份认证）与glance（镜像服务）的安装版本不一致就导致了我们很长一段时间关于Glance的命令执行不得不使用EC2工具绕过了Keystoneo最终的解决是将版本统一后，将glance的安装步骤与Keystone的结合安装过程顺序进行倒置才成功的。在以上工作完成的基础上，由我完成了OPenStaCk的手动安装文档的初版编写，与一个版本的脚本自动安装部署由张贺军来完成的，但是关于公司的要求我们还是有很大一段距离的。比如说，关于不一致的开源服务对服务器都有不一致的要求，mysql数据库服务

12、要求内存与CPU；VoIUnIe卷组存储服务要求硬盘多一些，glance镜像服务要求内存更大一些；操纵节点的要求比较通常，计算节点则对内存要求非常高；rabbitmq消息队列服务要求网络；network也需要网络与服务器内存给予很好的支持；还有目前关于network与quantum服务最好是能够进行服务器的单独支持；存储服务方面，代理节点的要求通常，但是存储节点需要有内存与硬盘的支持等等。需要考虑的是服务器成本的降低与整体服务的优化等方面的原因，将服务安排在指定的服务器，并自动进行修改配置；事实上，在有了资源服务器的支持以后，脚本安装与人为的手动安装方面的速度是相差不大的。从安装的正确性与准确

13、性与成功率上来讲，手动安装更加保质保量。我号召团队成员多关注QQ群中全国的竞争对手的情况，竞争对手的情况要比我们好很多，不管从实验环境方面还是人员构成方面都令我们羡慕不已，为了不落后于竞争对手，我要求在进行以后工作的同时着手将云计算服务底层的一些功能接口进行了梳理，包含统一身份验证服务(keystone)、镜像服务(glance)、云主机服务(nova)与存储服务(SWift)等接口功能。这些接口功能也为后来的各项云计算服务产品项目的开发打下了良好的基础。我让开发人员将接口源码进行了梳理，为了能够更好的给张亚丽部门的于彪组提供更好的服务支持，我让王琳将C#接口的源代码进行有效的整理与分割,我让

14、凌志将swift做了安装部署后,为于彪组提供关于云存储的技术服务支持。尽管沟通方面我们也经常在见面打招呼的时候询问是否有什么问题，但是接口方面的技术支持也总是断断续续。为了验证在镜像中放入大的应用服务，在启动虚拟服务器时能够将作在镜像当中的应用服务进行正常的使用，我们制作了包含国外SAP应用的服务镜像，该镜像的制作过程中也遇到了很多的问题与烦恼，首先需要将多个光盘的安装文件进行合并，这个SAP服务的安装文件一共有200多个GB,其中安装文件有四个，要紧的安装文件就有200多个GB,当时在这个地方就存在着一个问题，就是将四个安装文件进行合并，合并成功以后再上传至服务器中。但是我们的合并没有成功，

15、要紧原因是安装文件太大了，普通的服务器或者者台式机在进行合并的过程中需要花费很长的时间，同时经常是等待很长的时间，不明白计算机是否还在进行着合并过程。在我的直觉与猜测的引导下，我决定不进行安装文件的合并，以200多GB的主安装文件来进行应用的服务器安装与镜像的制作。镜像制作成功后，另外一个问题就是由于实验环境服务器性能的影响，通过镜像服务glance上传镜像需要花费很长的时间，而且上传至glance所在的物理服务器以后，再上传至计算节点物理服务器，又需要镜像的长时间拷贝；这个在当时OpenStack的Diablo版本中是无法进行镜像上传进度的提示的，直到我们后来升级为OPenStaCk的Ess

16、ex版本以后才得以解决。最终我们成功实现了将大的应用服务SAP放置在已经制作完成的镜像文件中，并成功启动该镜像的虚拟机，由于实验环境服务器的影响，速度非常慢。在进行了目前现有功能与参考网上其他云服务产品功能以后，我筛选出了我们还没能够实现的功能，其中包含增开虚拟机外网代理、虚拟机实例快照、虚拟机负载均衡、虚拟机双机热备、虚拟机实例迁移、外部接口调用修改虚拟机主机名称、虚拟机时区不一致步、Glance于Swift服务的整合、虚拟机计算节点运行状况监控、虚拟机配额限制服务、多操纵节点集群、接口操纵虚拟机网络带宽流量、提高OPenStaCk数据库的稳固性等等功能。这些功能有些成功的实现了，但是也有受制于实验环境、网络环境的限制与研发团队技术能力方面的影响，我们没有成功。关于功能的实现我决定务必本着几个原则入手：1 .在进行功