离开IaaS行业已经1年多了，回顾当年的工作，自觉误区不少。 大学里有个段子：高中时代，爱情是奢侈品，少数人才有的起；大学时代，爱情是必需品，没有则很寒酸。 同样适用于前两年甚至当下的IaaS 产业。似乎大家都同时步入了云时代，互联网+ 如果没有个云平台，岂不是寒酸到家了。 恋爱还有个你情我愿，云嘛，有钱就有了撒～～～ 其实，是否需要云平台，还是要从当前实际情况来决定，是否有真实的需求。 先说说虚拟化本身对机器的需求：

单以笔者最熟悉的CloudStack而言，恰当的部署应该是(master+mysql)x2 + PrimaryStorage + SecondaryStorage + (hypervisor)xN。

对于CloudStack而言，PrimaryStroage是个单点。如果要保证效率和数据安全性，PrimaryStorage质量和价格都是必需要考虑到的。

Hypervisor是真正的计算资源，对CPU/内存/网络要求也比较高。

CPU按调度策略来分割使用，超出4倍则可能会对用户使用产生可见的影响。

内存和硬盘则是更容易就被用满而无法继续Over Provision。

最大的可能还在于网络，千兆网卡支持一个业务或许没有问题，但是如果开了10个VM 运行同样业务，则可能需要万兆网卡和交换机的支持才能满足了。

iowait，因为虚拟化最终还是依靠CPU来模拟最终的文件落地和中断，而不是依靠类似DMA的硬件装置。大量小文件读写可能会造成CPU在某一个时间段卡顿。

从笔者从业经验中的几次失败案例来讲（失败是指部署成功但是使用极少或者最终放弃），以下几个误区可能会导致一次 IaaS 平台实施方案的失败：

一、虽然机器并不多，但是我们要上云平台，要有上云的能力

虽然有国外的虚拟化狂热爱好者坚定的认为超出3台物理服务器就需要虚拟化，但是笔者并不认同，况且，云平台和虚拟化也并非相同等级。

云平台作为一个虚拟化和物理资源的管理平台，本身管理节点就需要单独部署并且消耗部分资源。

这种消耗一般是固定的，比如CloudStack的2台master和mysql，或者OpenStack则会按部署模块需要更多的管理节点。

管理节点并不需要性能特别优秀的服务器，但对热备还是有很高的要求的，一台出现问题的情况下，需要有其它机器来替代它执行管理功能。

在资源并不充足的情况下，单独拿出2台物理服务器，对成本的影响很大。尤其国内企业大部分都是集中采购同类型服务器，则管理节点浪费会很严重。

二、数据重要并且读写量大

尤其指数据库和图片服务器。

大部分企业在迁移云平台的时候，会试图将这两种服务器一并迁移到云中。做成整个数据中心的云化。

具体实施中，的确有很多方案是为了解决这两种情况而产生的，比如数据的write through，故障及时恢复，周期性快照，同类型应用分开机器部署等等。

笔者个人认为，此类方案从根本上应该就是需要避免的。

数据的安全性在于分散存储和实时备份，对于系统的部署，并不能相信任何一个模块可能是稳定的。

如果主存储故障，则可能造成灾难性的后果，数据完全无法恢复。

如果数据库或者图片服务器的主库所在的一台hypervisor跑入了一个高并发的应用，或者因为意外操作而导致CPU或网络被耗尽，则可能出现另一种更为诡异的灾难，即主库响应被拖慢甚至拖垮相关的上层服务。

三、业务类型单一并且基本上撑满整个物理集群

此类业务规划好并且迁移到云上，并不会有太大风险，只是纯粹的浪费资源而已。

单一类型的业务，放到云上，只会增加系统的虚拟化管理开销，意味着在原本峰值的时候能刚刚好撑满的集群需要相应扩容以抵消虚拟化带来的损失。

四、以云平台来做机器利旧

此法尤为不可取，似乎是2010年前后，笔者刚刚接触云平台的时候的一个主流提法。

似乎是来自于传说中的Google收了无数的低端服务器，搭建了自己的一个数据中心，每天抬出去坏掉的无数个硬件。

如前文所述，云平台实际对硬件速度和安全性要求都比较高。旧机器一方面是配置落伍，即便是配置还不错，性能也已经老化。

此类机器部署云平台，异常会变得更加不可控并且某些时候无法调试。

另外，我们弄点开源云平台搭一搭，甚至改一改再搭，也实在达不到Google的水平，况且也没法证实Google是这么干的～～～

三、有了云嘛，一切就都得在云上

云：虽然不知道为什么起了这么个名字，但的确是云里雾里的。

因为云里雾里，所以就很牛，因为很牛，所以所有东西放上到牛的东西上，就变得更加高大上。

如前文所述，并非所有应用都适合放到云上，具体哪些不适合，还得看企业应用类型，但是统一认为不适合的：数据库，图片存储服务器，HDFS等大数据相关的应用。

这类应用统一有一个特征：高吞吐，高安全性

四、上了云，是不是就更安全了？

非也，非也

上了云，可以认为是可以工作的机器变多了。而不是机器变强横了。

原本一台机器可能产生的风险，现在变成多台一起产生了。

假设原来一台机器部署一个应用稳定性是99.99%，现在100台VM可以部署100个应用很容易从概率学角度上算出来是(0.9999)^100。大家算算就知道了。

入侵风险也并没有降低，反而多了一个途径。没有云的时候，可以入侵服务器，有了云，可以入侵服务器并且可能通过虚拟化的shm或者bus之类方式，入侵同机器甚至同机房机器。如果同集群有其它业务甚至子公司应用，那风险就更加大了。

所以，云平台只是资源调度和管理，至于安全，则应该是云安全相关系统的职责了。

五、云+大数据

虚拟化 + Hadoop 基本上没什么用处。

Hadoop会根据一定的标准找到距离客户端最近的一个节点，如果文件在本地，则不会产生网络消耗。

移植到虚拟化平台则无论是否在本地，均会引发网络传输，除非换用光线类的存储，从成本方面解决这个问题。

从资源方面考虑，Hadoop之类的平台在运行时很可能会撑满整个集群资源的运算能力来提供快速的结果输出，此时如果平台没有其它类型的应用，则变成了上文说过的单一类型并且吃满整个集群的应用，如果有其它类型应用，哪买其它应用可能会卡顿。

HDFS如果大部分都是小文件，则在Hadoop任务运行时，大量的小文件读取会造成系统cpu某个或者某几个核的iowait飙高而无法响应其它问题，此时，需要修改某些配置，合并成大文件来进行读写，或许对此种问题有所帮助。

虚拟化+Hadoop 平台，尽量还是用于测试开发环境，而不要用于生产比较好。

六、CloudStack和OpenStack之争

虽然我全文都以CloudStack举例，但并不是说OpenStack就不好或者有问题，只是因为笔者本人做CloudStack出身并且更加喜欢CloudStack而已。

同样作为虚拟化管理平台，问题是有就会统一都有，能解决的各自也都可以解决。版本的bug并不能成为选型的依据。

实际选择的时候，还是需要考虑技术积累和应用场景。

到底怎么做云平台选型呢？

1、了解业务类型

业务是否适合运行在云上？是否更加高效？迁移是否需要大量改造？

未来的业务规划是否需要有虚拟化或者云的支撑？

是否要上云平台，当前物理集群是否有运维不了的情况，如果上了虚拟化，带来的额外开销是什么？（人员，机器，还是机房）

2、了解运行时数据

业务峰值是在几点，每天几次，当前有几个业务是峰值，都耗用了什么资源？

业务日常运维的最大开销和正常开销分别是什么样的，如果迁移到云，是否在某个时间段需要增加机器或者调度其它资源？

当前的硬件状况是什么样子，怎样支撑当前的业务，如果迁移到云平台，需要增加或者改造当前硬件么？

3、了解接下来的系统开发和使用需求

系统是否合适迁移到虚拟化平台

如果迁移到云，需要做怎样的系统改造，系统改造能用到云平台多少功能？

4、是否选云，选哪家？

按照业务类型和接下来的需求，选择一个适合自己的云平台，并且依据自己的运维能力来选择一家合适的供应商或者使用开源产品。