《（工作总结）天津卓朗科技研发云计算心酸史之工作总结(XXXX年11月～》由会员分享，可在线阅读，更多相关《（工作总结）天津卓朗科技研发云计算心酸史之工作总结(XXXX年11月～（32页珍藏版）》请在金锄头文库上搜索。
1、工 作 总 结（2011年11月2012年9月）虚拟化基础架构业务部王 毅2012-9-24目录1.概述42.项目52.1云计算服务底层核心52.2云计算服务管理系统132.3云计算服务监控系统162.4弹性计算应用172.5云计算服务计费系统182.6云计算服务用户中心系统192.7云服务网站192.8云服务网站内容管理系统202.9企业私有云实体机柜操作系统202.10企业私有云实体机柜监控系统203.团队建设203.1初期203.2中期203.3后期204.总结201.概述从2011年11月份至2012年九月份，我主动要求接受公司分派的云计算开源软件OpenStack的研发任务，到至今已
2、经完成云计算产品服务的大部分功能，并基于已经研发出来的功能生产出一系列的软件产品共花了11个月的时间。在这11个月的时间里，无论是对于产品项目的开发、云计算底层服务研发，还是团队建设等方面都遇到了不同程度的问题和困难。虚拟化基础架构业务部从刚刚开始的“IaaS组”到现在成为部门，人员也由最初的四个人发展到现在的13个人。以下是我从项目和团队建设两个方面着手，将问题融入到项目和团队建设当中来进行虚拟化基础架构业务部的工作总结。2.项目目前虚拟化基础架构业务部围绕着云计算底层服务的研发所完成的项目比较多，主要包括云计算服务管理系统-PUBECM、云计算服务监控系统-PUBECC、弹性计算应用-EC
3、A、云计算服务计费系统-CSBS、云计算服务用户中心系统-CSUC、云服务网站-CSNT、云服务网站内容管理系统-CSMS、企业私有云实体机柜操作系统-PRVECM、企业私有云实体机柜监控系统-PRVECC等。其实，作为云计算服务底层的研发工作，也可以算是一个主要的项目，毕竟它是我们云计算服务底层的核心。2.1云计算服务底层核心2011年11月，由于当时我还在杨颖部门下作为一个组的组长，我们所接受的任务是ESDP的开源和ESDP的开源网站的开发。我们组准确的来讲一共只有四个人，在接触了云计算服务开源软件OpenStack以后，由于我跟同组的凌志对OpenStack的云存储部分“swift”从安
4、装到使用都已经进行完成，所以也不得不对OpenStack的虚拟机部分对晓明进行辅助性工作。当时云计算开源软件OpenStack给我的感觉是必须集中精力，才能够顺利的进行，因此我主动要求承接云计算服务开源软件OpenStack的研发工作。在研发初期，我们主要的精力还是对于OpenStack的集群式安装部署，因为OpenStack是一个开源性的软件，除了它自己的开源项目，包括云存储（swift）、云虚拟机（nova）、镜像服务（glance）、统一身份认证系统（keystone）、管理系统（当时被叫做“dashboard”，后来改称为“horizon”）之外，还包括其他的一些开源的软件项目服务。如
5、：数据库服务（mysql）、时钟服务（ntp）、消息队列服务（rabbitmq）、虚拟服务器远程服务（noVNC）、网络服务（network）、访问工具（ecua）、卷组服务（volume）等等。各个服务之间首先必须安装正确，在安装正确的基础之上通过配置文件的相互配置才能够达到想要的功能效果，除此之外各个服务之间的安装还存在一个顺序的问题，所以要顺利的安装集群部署就需要反复的实验，为了保证实验的正确性和准确性，我们有的时候不得不要求将服务器进行重新格式化；之所以格式化的主要原因是卸载往往有的时候是无法卸载干净的，同样的安装过程，对于卸载的服务器有的时候能成功；而有的时候却成功不了，这大大干扰了
6、我们的安装思路。后来公司不允许进行服务器的重新格式化，原因是服务器所在集装箱的机柜不能够经常反复的开启，对服务器机柜内的温度有很大的影响，容易造成服务器的损坏；由于服务器当时在八角楼C4机房，我们只有使用的权限，对于有的时候所发生的服务器死机需要重启等工作，我们只能间接的通过网络部来配合进行完成，而网络部负责这项工作的王烨辉的工作也很忙，我们很多时候不得不进行等待，这也给我们的工作带来了一定的困难和麻烦。当时我们服务器在机房中一共拥有20台服务器，为了能够在沟通和管理上方便，我针对于服务器进行了从1#20#的编号，其中15#19#五台服务器是DELL的R410服务器，其他服务器是2GB的内存配
7、置。为了保证安装脚本在我们自己掌控下顺利进行，我决定将八角楼的服务器中的1#机和2#机搬到了办公地点作为云存储的脚本安装及功能测试；后来张亚丽组的张志楠和张贺军的加入所带来的两台惠普服务器成为了办公地点虚拟机的脚本安装及功能研发和测试的环境，通过这四台服务器组成了我们的办公地点的实验环境。但是为了能够彻底解决OpenStack底层各项服务之间的搭配工作，能够准确的找到问题的出现位置，锁定服务目标；我采取了将服务器各个服务单独存放至一台物理服务器当中，来进行功能性验证和观察。准确的来讲在C4八角楼机房里有18台服务器供我们使用，但是由于不能够经常性的重新格式化服务器和经常性的进入服务器机房，所以
8、我们对于C4机房中的18台服务器的使用非常慎重，当然也大大影响了我们的工作效率。OpenStack的官方网站，只是介绍了表面层次上的大体原理，以及各个服务之间的相互作用服务，但是像ntp、rabbitmq这样的其他开源服务是没有介绍的，我们所找到的线索完全得益于从网上下载某些志同道合的网友所提供的安装部署文档；但是想要达到和解决各个服务以单独物理服务器提供服务的目的，这项工作仍然非常的艰难。为了避免机房服务器的重新安装，我下令让研发人员在自己的台式机上通过virtual box安装虚拟服务器，我们自己的台式机箱只有2GB的内存，最多也就可以跑三台虚拟机，所以只能在这三台虚拟机上跑安装脚本，另外
9、由于我们的台式机CPU等配置不支持虚拟化，所以我们只能够通过返回的命令行提示来确定是否安装成功，但创建虚拟机是得不到任何验证的；同时我们只能关掉一部分已经安装了虚拟服务器后再跑其他的虚拟服务器，花在查看上的时间非常多，更不要说再遇到问题和解决问题了。在这个工作过程的进行当中，我们实验环境服务器所在机柜的PDU坏了，对于PDU的采购花了很长一部分时间，大概有一个月左右，这也导致了我们的工作无法在实验环境的18台服务器中进行。我们只能在自己的台式服务器里的虚拟机中跑我们的脚本。在初期的过程中，我们并不敢跑大的虚拟机镜像，而是采用了OpenStack官方没有操作系统界面，只有命令行的小型ubuntu
10、镜像。在整理和跑通安装脚本并等到实验环境的PDU修复后，我们才得以反复进行我们的安装脚本的实验，这个时候我们的卸载脚本也已基本成熟。可以说安装部署方面的问题已经基本上得到了解决。公司还要求可以自动进行安装部署，为了实现这个目标，我们将实验环境的12#服务器当作我们安装部署的资源机环境，安装部署资源大概占到了40GB左右。之所以需要一个资源机，是因为在我们的安装过程中，经常遇到了版本不统一和不一致所导致的无法安装成功，究其根源在于采用apt-get的方式安装都是采用网上资源进行下载后的安装，地址是一样的，版本却改变了。OpenStack当时还相当的不成熟，源代码更新比较快，同样的安装地址，昨天还
11、可以正确安装并安装成功，转过天来就会出现有些命令都执行不通的情况出现，Keystone（身份认证）和glance（镜像服务）的安装版本不一致就导致了我们很长一段时间对于Glance的命令执行不得不采用EC2工具绕过了Keystone。最终的解决是将版本统一后，将glance的安装步骤和Keystone的结合安装过程顺序进行倒置才成功的。在以上工作完成的基础上，由我完成了OpenStack的手动安装文档的初版编写，和一个版本的脚本自动安装部署由张贺军来完成的，但是对于公司的要求我们还是有很大一段距离的。比如说，对于不同的开源服务对服务器都有不同的要求，mysql数据库服务要求内存和CPU；Vol
12、ume卷组存储服务要求硬盘多一些，glance镜像服务要求内存更大一些；控制节点的要求比较一般，计算节点则对内存要求非常高；rabbitmq消息队列服务要求网络；network也需要网络和服务器内存给予很好的支持；还有目前对于network和quantum服务最好是能够进行服务器的单独支持；存储服务方面，代理节点的要求一般，但是存储节点需要有内存和硬盘的支持等等。需要考虑的是服务器成本的降低以及整体服务的优化等方面的原因，将服务安排在指定的服务器，并自动进行修改配置；其实，在有了资源服务器的支持以后，脚本安装和人为的手动安装方面的速度是相差不大的。从安装的正确性和准确性以及成功率上来讲，手动安
13、装更加保质保量。我号召团队成员多关注QQ群中全国的竞争对手的情况，竞争对手的情况要比我们好很多，无论从实验环境方面还是人员构成方面都令我们羡慕不已，为了不落后于竞争对手，我要求在进行以后工作的同时着手将云计算服务底层的一些功能接口进行了梳理，包括统一身份验证服务（keystone）、镜像服务（glance）、云主机服务（nova）和存储服务（swift）等接口功能。这些接口功能也为后来的各项云计算服务产品项目的开发打下了良好的基础。OpenStack是用python语言开发的，在官方上有很好的接口服务文档，通过官方接口文档的描述，我们知道OpenStack是采用的http协议的Restful接
14、口技术实现的，类似于通常所说的WebService接口服务技术。对于接口的调用，研发人员从网上下载了针对于存储服务的两种接口调用源代码，一个是java的；另一个C#语言的。通过接口对于现有的功能的理解后，我对云计算服务有了更加深刻的理解，主要是云存储和虚拟机两个方面；我认为可以建设一个云服务的网站，可以提供类似于网盘服务以及虚拟主机的同时，还可以将企业的应用服务做在创建虚拟机的镜像当中，这样就实现了网上的SaaS平台，并通过邮件的方式向陈岩光副总提交了我的想法。由于当时公司想要一个比较绚丽的，所以.net的silverlight可以达到要求。张亚丽部门就负责了云服务网站的开发工作，我们作为底层
15、对他们提供接口服务，他们最先的工作主要是云存储。我让开发人员将接口源码进行了梳理，为了能够更好的给张亚丽部门的于彪组提供更好的服务支持，我让王琳将C#接口的源代码进行有效的整理和分割，我让凌志将swift做了安装部署后，为于彪组提供关于云存储的技术服务支持。虽然沟通方面我们也经常在见面打招呼的时候询问是否有什么问题，但是接口方面的技术支持也总是断断续续。为了验证在镜像中放入大的应用服务，在启动虚拟服务器时可以将作在镜像当中的应用服务进行正常的使用，我们制作了包含国外SAP应用的服务镜像，该镜像的制作过程中也遇到了很多的问题和麻烦，首先需要将多个光盘的安装文件进行合并，这个SAP服务的安装文件一
16、共有200多个GB，其中安装文件有四个，主要的安装文件就有200多个GB，当时在这个地方就存在着一个问题，就是将四个安装文件进行合并，合并成功以后再上传至服务器中。但是我们的合并没有成功，主要原因是安装文件太大了，普通的服务器或者台式机在进行合并的过程中需要花费很长的时间，并且经常是等待很长的时间，不知道计算机是否还在进行着合并过程。在我的直觉和猜测的引导下，我决定不进行安装文件的合并，以200多GB的主安装文件来进行应用的服务器安装和镜像的制作。镜像制作成功后，另外一个问题就是由于实验环境服务器性能的影响，通过镜像服务glance上传镜像需要花费很长的时间，而且上传至glance所在的物理服务器以后，再上传至计算节点物理服务器，又需要镜像的
