回老家,转行到企业IT运维。第一个任务便是非常重大的活儿——企业信息化系统建设。由于公司是大型集团企业,公司架构庞大复杂,从事传统行业,信息化程度相对落后。所以使得任务非常重要、又异常艰巨,我们领导压力很大。
软件方案招标还在进行,领导要我事先着手预备硬件招标方案,为今后决策打好基础工作。软件商普遍提到了上马私有云的硬件方案,并推荐了一些硬件方案厂商,比如深信服、联想超融合。
由于本人之前对硬件接触不算太深,在联想过来做产品介绍的时候,提到自己的两款超融合产品H1000和H3000,虚拟化技术前者是在KVM平台,后者在VMware平台。按照我们的体量和实际情况,当然推荐我们采用H3000。这次介绍提起了我对KVM、VMware再做进一步最新了解的想法(早在大学期间就在PC端装过VMware),以便深入了解在企业IT建设运维过程中虚拟化技术相关情况。
接下来找到一篇给我提供了非常多实用信息的帖子,看了下时间戳2015-2-3,虽然距今2018-2-5有3年时间了,但是不乏很多干货。原帖链接在实战:基于OpenStack搭建公司私有云平台
下面列出我得到的知识点:
因为KVM属于开源平台,所以应用在联想H1000中,相比应用搭建在VMvare平台的H3000,整体价格要低。当然采用的不通参数规格的硬件也对价格产生很大影响。
帖子中属于自己采用传统硬件架构搭建私有云,我们公司目前预备是采用超融合一体机进行搭建,虽有区别,但私有云架构本质是一样的。
OpenStack和CloudStack是两大主流开源云平台,各具优势。CloudStack安装和部署都很方便,OpenStack框架相对开放灵活,可以根据用户需求方便的进行开发定制。
CloudStack是从cloud.com公司的产品转向开源,从产品化方面来说,本身是个比较成熟的产品,安装和部署都很方便,且提供了完整的升级流程,可以便于将来和社区保持同步。然而随着社区版本的不断更新和兼容各家产品,CloudStack也逐渐变得庞大。以公司搭建私有云落地方案而言,很多功能无用且显得多余。
OpenStack开放至今,并没有完成产品化发行,优势在于其插件化的框架,因为技术框架允许自由的选择可用插件,私有云落地方案中,可以只选择需要的组件进行安装。因为框架允许插入不同组件,所以OpenStack社区也获得了更多厂商的支持,社区活跃度也比较高。在企业实施落地方案的时候,可以有更多的选择余地,对遇到的问题,也有了更多更快的响应。
OpenStack的产品化不成熟,搭建落地到将来的升级,以及后续的二次开发,都需要进行不少的开发和测试人力投入。但是如果本身有着比较成熟的运维团队和研发团队,开发和测试在人力资源成本方面计算,也不是太大问题。CloudStack如果进行二次开发,代码未合并入社区版本的时候,升级则需要再次merge代码,重复工作比较多。
OpenStack原生对KVM支持更加完善。
KVM也是比较成熟的虚拟化平台,于2006年写入Linux内核,且在Redhat 6以后,转向对KVM的支持而非之前大力推广Xen的虚拟化方案。
KVM相比较于Xen,更小,更轻量级,更方便管理。
XenServer是Citrix将之前的商业版本开源而来,其产品成熟,功能和管理界面更加友好。但OpenStack对于XenServer的管理却并不完善。
VMware是商业软件,在虚拟化平台中,目前应该属于IO和稳定性都最优化的方案。OpenStack中,因为VMware本身提供了相应的driver,对VMware的支持也比较成熟。但VMware授权比较昂贵。
OpenStack社区对Ubuntu支持比较完善,Ubuntu更新速度快,内核版本比较新,可以支持更高版本的KVM,对OpenStack使用者来说,Ubuntu可以提供更好的性能。
就系统的稳定性而言,CentOS来自Redhat商业版本的重新编译,稳定性和系统优化以及兼容性方面要略好。CentOS7 以后,也换用了 Linux3.x内核版本。
硬件打包化,建设简单快捷,后期扩容类似“热插拔”,工作量也比较小。
一体化管理界面,运维人员相对轻松。硬件方面出问题一般由超融合提供商进行运维解决,解放了公司自己的IT运维人员(当然由提供商进行运维解决会额外增加成本)。
由于超融合将服务器资源存储资源网络资源全部集成于一体,因此不能像传统架构那样可以轻松随意更换或选择其中的任何一块内容。也就是一旦用了某一品牌超融合,势必会受到这个品牌厂家一定程度的牵制。除非整体换掉,更换代价就更高了。
另外,超融合对于所有资源进行了虚拟化,对于一些特定应用场景,例如需要高可靠性(一旦出了问题物理上易定位)的情景,超融合相比传统架构可能也不占优势。