天津卓朗科技研发云计算心酸史之工作总结XXXX年.docx
《天津卓朗科技研发云计算心酸史之工作总结XXXX年.docx》由会员分享，可在线阅读，更多相关《天津卓朗科技研发云计算心酸史之工作总结XXXX年.docx（22页珍藏版）》请在冰点文库上搜索。
天津卓朗科技研发云计算心酸史之工作总结XXXX年
工作总结
（2011年11月～2012年9月）
虚拟化基础架构业务部
王毅
2012-9-24
1.概述
从2011年11月份至2012年九月份，我主动要求接受公司分派的云计算开源软件OpenStack的研发任务，到至今已经完成云计算产品服务的大部分功能，并基于已经研发出来的功能生产出一系列的软件产品共花了11个月的时间。
在这11个月的时间里，无论是对于产品项目的开发、云计算底层服务研发，还是团队建设等方面都遇到了不同程度的问题和困难。
虚拟化基础架构业务部从刚刚开始的“IaaS组”到现在成为部门，人员也由最初的四个人发展到现在的13个人。
以下是我从项目和团队建设两个方面着手，将问题融入到项目和团队建设当中来进行虚拟化基础架构业务部的工作总结。
2.项目
目前虚拟化基础架构业务部围绕着云计算底层服务的研发所完成的项目比较多，主要包括《云计算服务管理系统-PUBECM》、《云计算服务监控系统-PUBECC》、《弹性计算应用-ECA》、《云计算服务计费系统-CSBS》、《云计算服务用户中心系统-CSUC》、《云服务网站-CSNT》、《云服务网站内容管理系统-CSMS》、《企业私有云实体机柜操作系统-PRVECM》、《企业私有云实体机柜监控系统-PRVECC》等。
其实，作为云计算服务底层的研发工作，也可以算是一个主要的项目，毕竟它是我们云计算服务底层的核心。
2.1云计算服务底层核心
2011年11月，由于当时我还在杨颖部门下作为一个组的组长，我们所接受的任务是ESDP的开源和ESDP的开源网站的开发。
我们组准确的来讲一共只有四个人，在接触了云计算服务开源软件OpenStack以后，由于我跟同组的凌志对OpenStack的云存储部分“swift”从安装到使用都已经进行完成，所以也不得不对OpenStack的虚拟机部分对晓明进行辅助性工作。
当时云计算开源软件OpenStack给我的感觉是必须集中精力，才能够顺利的进行，因此我主动要求承接云计算服务开源软件OpenStack的研发工作。
在研发初期，我们主要的精力还是对于OpenStack的集群式安装部署，因为OpenStack是一个开源性的软件，除了它自己的开源项目，包括云存储（swift）、云虚拟机（nova）、镜像服务（glance）、统一身份认证系统（keystone）、管理系统（当时被叫做“dashboard”，后来改称为“horizon”）之外，还包括其他的一些开源的软件项目服务。
如：
数据库服务（mysql）、时钟服务（ntp）、消息队列服务（rabbitmq）、虚拟服务器远程服务（noVNC）、网络服务（network）、访问工具（ecua）、卷组服务（volume）等等。
各个服务之间首先必须安装正确，在安装正确的基础之上通过配置文件的相互配置才能够达到想要的功能效果，除此之外各个服务之间的安装还存在一个顺序的问题，所以要顺利的安装集群部署就需要反复的实验，为了保证实验的正确性和准确性，我们有的时候不得不要求将服务器进行重新格式化；之所以格式化的主要原因是卸载往往有的时候是无法卸载干净的，同样的安装过程，对于卸载的服务器有的时候能成功；而有的时候却成功不了，这大大干扰了我们的安装思路。
后来公司不允许进行服务器的重新格式化，原因是服务器所在集装箱的机柜不能够经常反复的开启，对服务器机柜内的温度有很大的影响，容易造成服务器的损坏；由于服务器当时在八角楼C4机房，我们只有使用的权限，对于有的时候所发生的服务器死机需要重启等工作，我们只能间接的通过网络部来配合进行完成，而网络部负责这项工作的王烨辉的工作也很忙，我们很多时候不得不进行等待，这也给我们的工作带来了一定的困难和麻烦。
当时我们服务器在机房中一共拥有20台服务器，为了能够在沟通和管理上方便，我针对于服务器进行了从1#～20#的编号，其中15#～19#五台服务器是DELL的R410服务器，其他服务器是2GB的内存配置。
为了保证安装脚本在我们自己掌控下顺利进行，我决定将八角楼的服务器中的1#机和2#机搬到了办公地点作为云存储的脚本安装及功能测试；后来张亚丽组的张志楠和张贺军的加入所带来的两台惠普服务器成为了办公地点虚拟机的脚本安装及功能研发和测试的环境，通过这四台服务器组成了我们的办公地点的实验环境。
但是为了能够彻底解决OpenStack底层各项服务之间的搭配工作，能够准确的找到问题的出现位置，锁定服务目标；我采取了将服务器各个服务单独存放至一台物理服务器当中，来进行功能性验证和观察。
准确的来讲在C4八角楼机房里有18台服务器供我们使用，但是由于不能够经常性的重新格式化服务器和经常性的进入服务器机房，所以我们对于C4机房中的18台服务器的使用非常慎重，当然也大大影响了我们的工作效率。
OpenStack的官方网站，只是介绍了表面层次上的大体原理，以及各个服务之间的相互作用服务，但是像ntp、rabbitmq这样的其他开源服务是没有介绍的，我们所找到的线索完全得益于从网上下载某些志同道合的网友所提供的安装部署文档；但是想要达到和解决各个服务以单独物理服务器提供服务的目的，这项工作仍然非常的艰难。
为了避免机房服务器的重新安装，我下令让研发人员在自己的台式机上通过virtualbox安装虚拟服务器，我们自己的台式机箱只有2GB的内存，最多也就可以跑三台虚拟机，所以只能在这三台虚拟机上跑安装脚本，另外由于我们的台式机CPU等配置不支持虚拟化，所以我们只能够通过返回的命令行提示来确定是否安装成功，但创建虚拟机是得不到任何验证的；同时我们只能关掉一部分已经安装了虚拟服务器后再跑其他的虚拟服务器，花在查看上的时间非常多，更不要说再遇到问题和解决问题了。
在这个工作过程的进行当中，我们实验环境服务器所在机柜的PDU坏了，对于PDU的采购花了很长一部分时间，大概有一个月左右，这也导致了我们的工作无法在实验环境的18台服务器中进行。
我们只能在自己的台式服务器里的虚拟机中跑我们的脚本。
在初期的过程中，我们并不敢跑大的虚拟机镜像，而是采用了OpenStack官方没有操作系统界面，只有命令行的小型ubuntu镜像。
在整理和跑通安装脚本并等到实验环境的PDU修复后，我们才得以反复进行我们的安装脚本的实验，这个时候我们的卸载脚本也已基本成熟。
可以说安装部署方面的问题已经基本上得到了解决。
公司还要求可以自动进行安装部署，为了实现这个目标，我们将实验环境的12#服务器当作我们安装部署的资源机环境，安装部署资源大概占到了40GB左右。
之所以需要一个资源机，是因为在我们的安装过程中，经常遇到了版本不统一和不一致所导致的无法安装成功，究其根源在于采用apt-get的方式安装都是采用网上资源进行下载后的安装，地址是一样的，版本却改变了。
OpenStack当时还相当的不成熟，源代码更新比较快，同样的安装地址，昨天还可以正确安装并安装成功，转过天来就会出现有些命令都执行不通的情况出现，Keystone（身份认证）和glance（镜像服务）的安装版本不一致就导致了我们很长一段时间对于Glance的命令执行不得不采用EC2工具绕过了Keystone。
最终的解决是将版本统一后，将glance的安装步骤和Keystone的结合安装过程顺序进行倒置才成功的。
在以上工作完成的基础上，由我完成了OpenStack的手动安装文档的初版编写，和一个版本的脚本自动安装部署由张贺军来完成的，但是对于公司的要求我们还是有很大一段距离的。
比如说，对于不同的开源服务对服务器都有不同的要求，mysql数据库服务要求内存和CPU；Volume卷组存储服务要求硬盘多一些，glance镜像服务要求内存更大一些；控制节点的要求比较一般，计算节点则对内存要求非常高；rabbitmq消息队列服务要求网络；network也需要网络和服务器内存给予很好的支持；还有目前对于network和quantum服务最好是能够进行服务器的单独支持；存储服务方面，代理节点的要求一般，但是存储节点需要有内存和硬盘的支持等等。
需要考虑的是服务器成本的降低以及整体服务的优化等方面的原因，将服务安排在指定的服务器，并自动进行修改配置；其实，在有了资源服务器的支持以后，脚本安装和人为的手动安装方面的速度是相差不大的。
从安装的正确性和准确性以及成功率上来讲，手动安装更加保质保量。
我号召团队成员多关注QQ群中全国的竞争对手的情况，竞争对手的情况要比我们好很多，无论从实验环境方面还是人员构成方面都令我们羡慕不已，为了不落后于竞争对手，我要求在进行以后工作的同时着手将云计算服务底层的一些功能接口进行了梳理，包括统一身份验证服务（keystone）、镜像服务（glance）、云主机服务（nova）和存储服务（swift）等接口功能。
这些接口功能也为后来的各项云计算服务产品项目的开发打下了良好的基础。
OpenStack是用python语言开发的，在官方上有很好的接口服务文档，通过官方接口文档的描述，我们知道OpenStack是采用的http协议的Restful接口技术实现的，类似于通常所说的WebService接口服务技术。
对于接口的调用，研发人员从网上下载了针对于存储服务的两种接口调用源代码，一个是java的；另一个C#语言的。
通过接口对于现有的功能的理解后，我对云计算服务有了更加深刻的理解，主要是云存储和虚拟机两个方面；我认为可以建设一个云服务的网站，可以提供类似于网盘服务以及虚拟主机的同时，还可以将企业的应用服务做在创建虚拟机的镜像当中，这样就实现了网上的SaaS平台，并通过邮件的方式向陈岩光副总提交了我的想法。
由于当时公司想要一个比较绚丽的，所以.net的silverlight可以达到要求。
张亚丽部门就负责了云服务网站的开发工作，我们作为底层对他们提供接口服务，他们最先的工作主要是云存储。
我让开发人员将接口源码进行了梳理，为了能够更好的给张亚丽部门的于彪组提供更好的服务支持，我让王琳将C#接口的源代码进行有效的整理和分割，我让凌志将swift做了安装部署后，为于彪组提供关于云存储的技术服务支持。
虽然沟通方面我们也经常在见面打招呼的时候询问是否有什么问题，但是接口方面的技术支持也总是断断续续。
为了验证在镜像中放入大的应用服务，在启动虚拟服务器时可以将作在镜像当中的应用服务进行正常的使用，我们制作了包含国外SAP应用的服务镜像，该镜像的制作过程中也遇到了很多的问题和麻烦，首先需要将多个光盘的安装文件进行合并，这个SAP服务的安装文件一共有200多个GB，其中安装文件有四个，主要的安装文件就有200多个GB，当时在这个地方就存在着一个问题，就是将四个安装文件进行合并，合并成功以后再上传至服务器中。
但是我们的合并没有成功，主要原因是安装文件太大了，普通的服务器或者台式机在进行合并的过程中需要花费很长的时间，并且经常是等待很长的时间，不知道计算机是否还在进行着合并过程。
在我的直觉和猜测的引导下，我决定不进行安装文件的合并，以200多GB的主安装文件来进行应用的服务器安装和镜像的制作。
镜像制作成功后，另外一个问题就是由于实验环境服务器性能的影响，通过镜像服务glance上传镜像需要花费很长的时间，而且上传至glance所在的物理服务器以后，再上传至计算节点物理服务器，又需要镜像的长时间拷贝；这个在当时OpenStack的Diablo版本中是无法进行镜像上传进度的提示的，直到我们后来升级为OpenStack的Essex版本以后才得以解决。
最终我们成功实现了将大的应用服务SAP放置在已经制作完成的镜像文件中，并成功启动该镜像的虚拟机，由于实验环境服务器的影响，速度非常慢。
在进行了目前现有功能和参考网上其他云服务产品功能以后，我筛选出了我们还没能够实现的功能，其中包括增开虚拟机外网代理、虚拟机实例快照、虚拟机负载均衡、虚拟机双机热备、虚拟机实例迁移、外部接口调用修改虚拟机主机名称、虚拟机时区不同步、Glance于Swift服务的整合、虚拟机计算节点运行状况监控、虚拟机配额限制服务、多控制节点集群、接口控制虚拟机网络带宽流量、提高OpenStack数据库的稳定性等等功能。
这些功能有些成功的实现了，但是也有受制于实验环境、网络环境的限制以及研发团队技术能力方面的影响，我们没有成功。
对于功能的实现我决定必须本着几个原则入手：
1.在进行功能性实验前必须写好实现方案，以功能为单位进行方案文档的编写，计划好步骤，并按照步骤一步一步进行实验；
2.不管成功与否，对于出现的问题以及针对问题进行的解释性记录必须落实在实现方案的文档上；
3.如果实现方案最终成功，对成功的实验功能进行总结；如果不成功，说明不成功并注明不成功的理由或者是怀疑理由；以备将来进行针对性解决。
为了能够从根本上解决底层中出现的大量Bug和帮助我们将来的研发工作，我认为研发团队中的每个人必须对OpenStack大体结构框架有非常准确和清晰的把握，在此基础之上才更加有把握进行源代码的修改和二次开发整合。
我带着团队中的部分人员进行了文档的翻译性工作，在翻译工作的过程中也是我能够确定的了解到官方文档只是表面上的介绍或者接口功能的介绍，对底层功能的研发意义虽然有但是却并不大，这也是我错误的认识了开源软件这个概念。
正在这个关节上，OpenStack的Essex版本发布了，官方网站上很多文档进行了更新，我们有部分的文档的原有依据丢失了，只能凭借我们版本库中所存储的原有文档进行翻译性的查看。
我们通过对官方网站上的资料查看以及网上搜索到的信息资料，发现新版本的Essex改变了原来的Diablo版本中的很多不足，也包括我们目前所无法解决的Bug，比如镜像服务glance上传镜像时的上传百分比的现实；最让人感到抑郁的底层的数据库表结构的改变非常的大，这让我们花费了很多功夫在Diablo版本上的功夫很有可能是白做了。
可是，也就是在这个时候，公司的SaaS平台需要上线，我们要负责底层的虚拟化环境的搭建，我们需要为SaaS平台网站提供集群式部署的服务器，统计下来SaaS平台需要30到40台不同配置的高性能虚拟服务器来进行支持。
我们也从网络运维部门获得了8台R710和1台R810，另外我们给了网络部几台R310并给了所有的R410作为正式生产环境的服务器，提供其他服务的支持。
有几个问题明显的摆在我的面前，正式生产环境就要上线了，底层服务的Diablo版本还有很多Bug和不稳定的因素，在此基础上搭建正式生产环境，很多问题是无法应付的；将来在此基础上升级风险性是可想而知的，耽误了服务怎么办？
因为一旦SaaS平台一旦给公司带来盈利，赚钱的话，每一分钟、每一秒钟都是耽误不起的；OpenStack的Essex新版本已经解决了原有的很多Bug问题，数据库底层也与原来的版本发生了很大的变化；最重要的特点是Essex在网络方面提出了新的服务quantum；究竟采用Diablo版本还是Essex版本，前者对于将来研发的风险性很大，同时我们很可能会出现研发方向的迷失，而对于后者如果我们成功搭建完成的话不但可以解决老版本残留的问题，对于将来的工作可以开辟出大片的空间；最终的结论是Diablo版本的风险会发生在将来，而Essex版本的风险性就在当时，因为我们还没有成功集群式安装。
可是，就当时的情况而言，基于低配置实验环境的安装，不可能；但是有了正式的生产环境，明摆着的更好的实验环境，不如拼一把。
我把我的想法告诉了我的团队，在跟陈岩光副总进行沟通以后，我们在正式生产环境上基于新的Essex版本搭建了云计算服务平台。
后来的事实也证明，我的这个决定是正确的。
云计算服务底层核心服务的研发方面，目前具备了大部分的虚拟机的功能，在整个团队的这11个月以来，基本上是两个方面的工作内容，一个是对基于云计算服务核心底层的上层产品的接口和技术支持、环境的维护；另一个就是云计算服务的核心研发这两个方面的工作；对于基于研发的文档知识积累，我认为这一点非常的重要，研发工作必须落实在文档上面，尽管绝大部分研发人员对于文档不够重视，但是当遇到问题的时候，原始的文档就提供了必要的帮助。
2.2云计算服务管理系统
云计算服务管理系统是最早完成的一个系统项目，当时OpenStack对于云计算服务底层拥有一个软件界面可以操控的系统，名称叫做“dashboard”，后来官方将其改名为“horizon”，“horizon”这个软件系统是用python语言进行开发的，在安装过程中也是需要进行配置文件的配置修改，基于mysql数据库来进行存储业务数据，其他就是调用OpenStack的相应接口，来实现给用户进行云计算服务的界面操作。
对于“horizon”这个被OpenStack囊括在其内的云计算服务操作系统来说，它有几个不好的地方：
1.完全基于OpenStack云计算服务的底层功能接口和进行模块的划分，如果不了解OpenStack的原理的话，是无法理解并使用和操作的；2.缺乏人性话，也就是在客户体验性方面做的还差一些，页面显示也不是很美观，比如：
它没有分页的操作，更不要说对于模糊的查询操作了。
基于这些特点，我编写了适合我们进行操作的云计算服务操作系统的需求并进行了业务方面的设计。
为什么要提出这个系统项目，我主要是基于以下几个方面的原因：
1.对于云计算服务底层，我们需要有自己的操作系统软件，这个毫无疑问是必须的；
2.对于我们已经实现的接口服务，没完没了的通过命令行进行加以验证相当麻烦。
另外，该系统也是我们接口功能逐渐实现和确认的一个终点，可以完全体现我们的工作，我们实现的功能，还有我们的价值；
3.这个操作系统目前可以给我们自己进行使用，随着逐渐的优化和改良，将来早晚会成为公司的产品，我们的工作是有用功，将来不会白做；
4.该操作系统服务当中包含着我们已经实现的接口调用，可以把它比作一个活字典，对于接口源代码的调用可以准确的找到位置并进行复制和粘贴，为将来其他产品项目的开发打下良好的基础。
从后来的各个系统项目服务来说已经印证了这一点；这也是我们为什么后来系统项目得以快速开发的主要原因。
当然，在该系统项目的开发过程中，也遇到了很多的问题，比如对于一些业务数据，我们采取的是没有调用OpenStack所提供的接口服务，而是通过对OpenStack底层中各个服务所涉及到的数据库及数据库表结构之间的逻辑关系进行关联性方面的数据检索，当然这必须建立在我们对OpenStack数据库表结构相当了解的基础上。
另外，有很多接口在OpenStack服务当中并没有提供，必须通过调用命令行执行才能够做到，这个对于系统项目的响应速度来讲的确是慢了很多，但是能够达到我们现阶段的目的。
在云服务器资源和云存储资源的监控显示方面，我们也有很大的问题，比如云存储，我们没有办法通过接口获得剩余的存储资源、已使用的资源，我们就不得不通过人为设定系统总的存储资源，通过命令行调用获得存储已经占用的资源，剩余的则就是未使用的存储资源等等。
对于统一身份验证（Keystone）来讲，在Diablo版本中它是有超级管理员用户的，它可以管理所有的租户和租户下的用户，但是对于后来的Essex版本来讲是没有超级管理员用户的。
对于这一点，OpenStack的“horizon”服务当中也是以一个租户为单位进行登录并进行服务的。
从这一个角度来讲，我认为OpenStack服务还是面向于大批量集群式公有云服务的，因为“公有云”往往给我在概念上的理解就是“资源无上限”。
目前该系统项目的项目名称我给他取名字叫做“pubecm”。
这个系统项目目前的缺陷是浏览器兼容方面还有一些问题，功能上很多还没有来得及增加；由于当时最初的目的是给我们自己使用的，所以页面风格沿用了2011年公司联查时的系统项目的玻璃质感风格。
但是，在随后的企业私有云实体机柜的操作系统诞生后，企业私有云实体机柜的操作系统囊扩了pubecm的所有功能，而且在页面风格和美化以及客户体验等方面都完全超过了pubecm，我现在一直考虑以企业私有云操作系统取代该系统项目。
因为企业私有云实体机柜的操作系统是从pubecm中升级出来的，它青出于蓝而胜于蓝一点都不为过。
2.3云计算服务监控系统
云计算服务监控系统是在后期为了能够更好的监控公司SaaS平台正式生产环境而做的一个系统监控项目。
这个项目的需求和业务设计都是由我一个人来完成的。
它主要包括这么几个方面的内容：
整体概况、CPU使用情况、内存使用情况、磁盘使用情况和存储资源使用情况这五个方面对服务器资源进行监控。
在这个系统项目开发的过程中，遇到的最大的问题就是资源的上限一直都没有一个统一和准确的数据，在报警线数据方面我们也仍然没有一个准确的数字。
关于资源上限也就是指整个服务的计算节点一共有多少核CPU，而这些CPU能够虚拟出多少核的CPU，这些虚拟出的CPU最大数量就是它的上限数量，而真正使用了多少以后，它的服务性能会降低或者说有很大的影响；这一点上我们一直没有得到很好的解决。
我对研发人员提出的要求是把OpenStack底层的算法搞清楚，通过它的算法和我们实际的参数我们得到它的上限数据；这个算法虽然是被研发人员掏出来了，但是对于具体的数据一直没有一个准确的答案。
最后没办法，我们通过正式生产环境实际的数据库中的数据得到准确的答案。
在正式生产环境中，有其中一个生产虚拟机服务器的计算节点，它内部所生产的虚拟机的CPU总和是它实际CPU核数的3倍，运行状况没有任何的问题。
3倍的这个数据对于我来讲，已经相当的奢侈了，所以我就将3倍这个数据定为CPU的最大上限数量；对于内存来讲，OpenStack的官方给的参数一直都是1.5倍，也就是说生产虚拟机服务器的计算节点物理机内存的1.5倍是它能够虚拟出的内存的最大数量，因此我保守的将1.5倍作为了内存最大上限的倍数参数。
对于磁盘空间而言，它是不需要虚拟化的，剩余多少就是多少。
这样我们解决了监控系统对于数据的监控问题。
2.4弹性计算应用
弹性计算应用系统是为了能够给SaaS平台添加应用而做的一个小型的创建虚拟机服务器、给企业用户分配虚拟机服务器和销毁虚拟机服务器的一个小型的应用。
该应用的需求设计和业务设计也是由我来完成的。
该弹性计算应用，就功能上来讲该项目并不大，但是说到它当时的风险性也是与SaaS平台底层的ESSEX版本搭建是绑定在一起的，这个应用于SaaS平台上的其他应用相比，它很特殊，它的特殊性就在于它完全调用底层的接口创建虚拟机，而这些虚拟机是与支持SaaS平台的虚拟机以及各个应用所占用的虚拟机服务器是平级的。
因此首先为了能够把握和控制住底层资源的限制使用而不影响SaaS平台的其他应用，我们必须开发一个弹性计算应用的后台管理系统，这个系统的目的是将底层的虚拟机服务器规格（CPU核数、内存大小、磁盘空间）同步到弹性计算应用的业务数据库中，通过管理员的筛选过滤掉大的规格，使注册和登录SaaS平台的用户只能够创建和使用低配置的虚拟机服务器。
在进行该应用的开发时，首先必须开发除了底层调用的其他部分，因为底层环境还处在搭建过程当中。
最大的问题是当时我们还是IaaS组，组内没有专门的美工，美工需要从于彪组进行借用，当时于彪组负责美工的是郜帅；但是郜帅还负责于彪组的美工以及手机云存储的页面设计工作，对于弹性计算应用的页面美化方面肯定是精力投入的不会很多，但是开发任务也非常急。
为了能够达到页面美化方面的要求，我组织组内的开发人员周六都干起了美化的工作，他们都很尽力，但是他们毕竟不是美工专业人员，所以页面没有能够达到我的要求，作为管理人员来讲我是说不出什么来的。
最终是由张云俪所管理的美工组后来又重新给改良的。
2.5云计算服务计费系统
云计算服务计费系统是公司陈岩光副总提出的一个项目，该项目的主要目的是支持云服务网站的，对云服务网站上的产品进行定价服务的。
由于我之前有过关于计费系统项目方面的经验，我针对于该系统项目进行了针对于客户和业务统计方面的扩展，因为产品的价格是与供求关系以及产品的成
升级会员 