热度 1|
这几个月一直忙于一个公司的项目,说起来似乎挺简单的,但真正实现起来也真是一波三折啊。这几天空下来,总结一下分享给大家。
公司现有一坨VMware的Esxi,有一个PHP的BS系统通过VMware提供的PerlSDK+CLI封装成了驱动层。现在的想法是使用OpenStack来替换——至少是部分替换掉Esxi节点。
初看这件事情,PHP的驱动层是现成的,OpenStack(Havana版本)的RestFul接口很容易封装,只要完全遵循VMware的驱动层的接口就能很容易的实现OpenStack的驱动层。甚至乐观的估计,连UI层都不需要太多的修改就能完成替换。可事实真的如此吗?
首先遇到的坑是存储问题
VMware ESxi是单机系统即便使用了NFS或者其他外接存储设备,照样是映射到了系统的某个路径下。而OpenStack支持多种存储方式,任何一种存储都是用户无关的,这看似方便的设定,其实意味着最终用户根本不知道虚拟机的磁盘文件路径保存在什么位置,系统无法对文件直接操作。
处于保守考虑,整个项目第一期直接放弃了OpenStack的SAN/NFS/NAS这类共享存储的设定,每一个主机只能使用自己的本地磁盘。这种考虑其实本质上是放弃了OpenStack的集群负载能力而保留那套仅存的API,为的是换取根Esxi相类似的拓扑结构。可事实上并没有降低丝毫的复杂度,而且给日后又挖了一个不小的坑。
然后是虚拟机部署流程的问题
VMWare的所有solution的虚拟机部署流程根本上说就是一个传统上买电脑裸机的过程:定制硬件、设置好启动方式、光盘iso安装操作系统、安装配置完成交付用户。而OpenStack的虚拟机部署流程更像一个厂商安装的过程:定制硬件、通过现有的模板定制克隆一块新的虚拟硬盘、挂装硬盘到虚拟机、启动系统完成配置、交付用户。传统上用户说我有个iso想要装台虚拟机这样的过程根本不成立!而且对于我们使用的Havana版本OpenStack来说,没有任何方式可以修改默认的启动顺序,启动顺序永远是第一块硬盘为空的情况下无限尝试pxe网络启动。
作为虚拟机来说,还有一个重要的用途是通过拷贝虚拟磁盘文件的方式大量克隆主机。这对于VMware来说,第一知道文件路径;第二都是本地磁盘操作的模式来说真的非常方便,而且众所周知的是VMware对这个拷贝过程做了大量的优化,允许用户选择仅拷贝一个体积很小继承文件。但对于OpenStack来说,有现成的API可以将虚拟机直接转换成模板,然后通过模板大量部署。可问题来了:尽管只用了本地存储,OpenStack本质上是一个集群,很大的可能你虚拟机转模板或者模板转虚拟机的过程中需要跨主机之间通讯。动辄以10G计算的虚拟磁盘文件一下子就吃光了所有的网络带宽和IO,让这个过程变得极其难以预测。当然,你可以选择共享存储的方式优化OpenStack,表现上甚至于远远好于VMware 的终极解决方案Vcenter。但痛苦的是我们跳进了自己挖的坑……
接下来是网络问题
这一点上感觉其实OpenStack更适合大批量部署,OpenStack通过Neutron组件可以在虚拟机部署的同时就给虚拟机分配合适的IP并通过API返回给用户,这个IP是在DHCP里与mac直接绑定的,这也就意味着只要虚拟机的DHCP没有问题,它的IP是固定不变的。但传统上VMware必须通过工作在虚拟主机上的插件获取虚拟的IP,插件的前提是VMware愿意提供而且要记得安装,这对于很多妖孽的操作系统来说就呵呵了。由于脱胎于传统的“装机模式”Vmware似乎更推荐用户手工指定IP或者通过外部网络的DHCP,而OpenStack更喜欢自己管理一套DHCP服务。
对于VMware VCenter支持的分布式交换机技术而言,尽管我有Vcenter的环境,但受软件授权的限制并不支持,只能说说OpenStack集成了网络管理能力,支持Vlan切换和调整,但至少Exsi这个级别的产品,VMware提供的和OpenStack出入不大。但很明显的是licence 的不同导致了VMware本身网络管理的差异化也不小。
各式各样的细节问题
我们一路上碰到的各种不同之处
OpenStack的各种各样的bug
吐槽部分,作为开源软件的软肋,bug是最让人头疼的,何况作为复杂的OpenStack更是如此。随便说几个吧: