研究私有云的种种细节

    云计算在国内有个有趣的现象，它在技术领域掀起热潮的同时，也产生了不少“中国特色”的“文学”作品，见诸于各学者、高管和专家高屋建瓴 的云计算预测和顶层设计。它们往往带有一定的中国特色，叙述架构的形式工整（如“云计算的一二三四五”），活用骈句（如“云计算和海计算”）、类比（如 “像用水一样使用云计算”）和口号（“把烂机器组成云”）。

 

 

    然而理想丰满现实却不免骨感，真实世界总没有想象的那般工整，未经实践的“大处”着眼，往往容易忽略致命“细节”，发现问题时往往积重难返。撰写本文的目的便在于抛砖引玉，简单谈一谈这些细节。由于经验所限，本文仅涉及“基础架构即服务（IaaS）”型私有云。

 

 

    省钱的细节

 

 

    所有项目开始前，都要思考清楚为什么。“节省投资”、“降低TCO（Total Cost Ownership）”往往是私有云的卖点，这就涉及到计算投资回报率ROI（Return On Investment），或是考虑行业基准折现率的净现值NPV（Net Present Value）。这类分析通常需要一定的专业知识，因此云计算厂商也提供了一些自动化工具，帮助欠缺这一知识的IT人员进行计算。然而如果不注意细节，往往 会在万里长征第一步上栽跟头。

 

 

    在一个19台服务器将做P2V迁移的小型项目中，我们用VMware的ROI TCO Calculator（http://roitco.vmware.com/vmw/ ）来计算它的投资回报率，通过页面输入相关参数，ROI结果达到185%，投资回报周期（Payback）为1.7年。从结果来看，这样的数字让人备受鼓 舞，然而仔细分析，却发现了以下一些假设上的缺陷，导致了最终结果的失真。

 

 

    1. 虚拟化产生的某些额外的软件成本（如vCenter搭建所需的Windows Server、数据库等）并没有计算在内。

 

 

    2. 电费收益上的计算，忽略了虚拟化架构中共享存储（存储设备、光纤交换机等）带来的新成本。同时类似于电源管理功能DPM（Distributed Power Management）带来的收益在实际应用中很难兑现（将ROI TCO Calculator计算工具用于上述项目，号称可以通过DPM节省近21.5%的电力）。

 

 

    3. 虽然服务器管理效率得到提高，但没有落实到具体运维人员的削减、人力成本的收益无法兑现等，同时共享存储的运维成本并没有考虑进去。

 

 

    4. 空间成本同上。没有考虑共享存储（存储设备和光纤交换机等）会带来新的空间需求。

 

 

    5. 由于要建共享存储，所以分析工具采用“每单位存储估价”ד存储单位”的方式进行换算，成本估算结果会比实际情况（新购所需存储）低。

 

 

    6. 在被计算的四年周期内，并不会因为效率提高而裁减运维人员，同时客户自营机房，空余出来的空间也不能在所产生的真正成本上折现。

 

 

    因此，扣除这些收益之后，发现ROI只有45%，投资回报周期（Payback）为2.8年。如果考虑行业基准折现率换算达成净现值NPV，这个结果将变得更悲观。

 

 

    这一现象其实是私有云部署里的常见问题：虚拟化显而易见的硬件整合收益，会被价格不菲的虚拟化软件、新硬件（如共享存储）和新环境（如承载vCenter的 2008和数据库）的开销所中和，服务器运维的效率虽然提高，但在存储运维、新技术掌握和适应上却又会产生新的人力成本投入，使得在成本上的说服力下降。 这些细节，在前期的预算上，可能会被力推新技术产品和服务的厂商有意和无意地隐藏。如果自身不经过细致的消化，往往会基于错误的设想而开始投入项目。

 

 

[page]    因此，面对私有云项目，要避免人云亦云，像这样专业的ROI分析工具也存在一定的缺陷，更何况某些专家缺少依据的预测。只有直接面对“并非省钱”的现实，才能进一步激发深入细节的潜力，在计划阶段规划“微操作”来获得更大收益。对此，有以下一些建议。

 

 

    1. 硬件分级：非生产环境是最能“螺蛳壳里做道场”的。不少企业内，应用的分级比较清晰，通常会有生产、预生产、测试开发、培训等环境，但很多时候承载这些环 境却常出现杀鸡用牛刀的情况，非生产环境往往和生产环境采用相同的硬件。其实硬件方面，大可不必消耗昂贵的共享存储，因为服务器本地存储往往在虚拟化平台 之后大量闲置，用在开发测试环境上也可胜任。

 

 

    2. 软件分级：除硬件上按需求来分级使用外，软件层面也可采用相同的策略。如在虚拟化层采用一些试用版，或是日渐成熟的开源软件来进一步降低成本。某国际半导体公司用于全球上百个实验室的测试床私有云，便架设在ESXi试用版上。

 

 

    3. 提升运维人员的“微操作”技能：鼓励运维人员掌握一些快速可以掌握的小技巧，即使在没有vCenter的情况下，通过ESXi Shell也可以实现镜像的克隆、迁移和注册；在没有商用备份软件的情况下，通过一些开源的脚本自动备份虚拟机等；巧用全克隆和链式克隆等细节，来提升在 非关键型业务管理上的成本效益。

 

 

    产品的细节

 

 

    一般来说，做私有云和公有云有很大不同，团队搭配、技术搭配和演进模式都不一样。通常，后者开发定制化的工作量有限，倾向于选择某些已产品化的方案。弯曲评论创办者陈怀 临曾提出过一个观点：系统是长出来的，不是设计出来的。选择私有云产品，也要注意某些细节，是“设计出来的”还是“长出来的”。市场私有云产品，或多或少 存在以下一些问题。

 

 

    1. 骑墙问题：云产品的设计，特别是IaaS产品，大体上朝两个鼻祖的产品模式发展：AWS（Amazon Web Service）所代表的公有云系统和VMware领军的私有云系统。如果某些产品设计希望能同时适用两种模式，往往带来一些问题，需要用户在心理上有些 准备，比如说云计算里最著名的两大开源平台。

 

 

    OpenStack是典型的“设计”出来的系统，参照AWS的产品几乎逐一对应地形成如 Nova、Swift、Glance和最新的Cinder等项目。OpenStack发展到现在可谓如日中天，几乎云计算领域的各大厂商都加入了这一阵 营，可以说它代表了未来，代表了方向。然而要部署到企业级环境作为私有云来使用，却不是“当下”拿之能用的，还需要在更多“接地气”的细节上努力。很多企 业级用户对AWS的使用模式很陌生。比如生成虚拟机（VM Instance）时，OpenStack沿袭了AWS的设计，对VM可以有临时性的Ephemeral Disk和持久性的Volume Storage。对于不熟悉这一模式的企业级用户来说，有时无法理解这样的公有云模式。当然随着Cinder的演进，这些问题在最新的Grizzly版本 中已有所改进，类似于“Copy Image to Volume”等更接近实际使用场景的功能，也已出现在Havana版本规划的路线图中。

 

 

    相对“设计”出来的OpenStack，CloudStack则更被认为是“长出来”的系统，它不像OpenStack在一开始便是开源的项目，因为需要考 虑到开源社区的协同合作，架构上必须模块化和松耦合。开源之前，它原本就是Cloud.com商品化的产品，因此更强调功能的实用性，更接地气。

 

 

    然而与OpenStack一样，它最初的目的也是面向公有云服务，当如今用到私有云的场景里时，一些公有云的痕迹也有待更多时日进行调整。例如，在某些功能 实现上，必须要保证整套系统能联通到外网，如实现“从内网某个IP上下载主机模板”，需要开通本地电脑的外网连接，确保能访问xxx-xxx-xxx- xxx.realhostip.com，才能得到解析内网的IP，这对一个强调与外界有效隔离、“私有”的企业级系统来说，不免有些背道而驰。

 

 

    2. 拼凑主义：相对开源云计算系统的“骑墙”问题，企业级厂商所推的方案也许更具“企业”性质。但这类方案，由于既想充分集成已有的企业级产品，又想套上“私 有云”的大帽子，往往会导致“拼凑主义”盛行。特别在早期，企业级厂商都急着在市场上卡位，新瓶装旧酒，按照功能模块，选择既有产品“拼凑”出一个私有云 方案。

 

 

    这类产品功能完整，适用性和实用性上却欠佳，例如产品之间的接口不一，整合困难。管理员面对的并非是统一的“私有云”界面，而是多个系统的管理接口。许多功能并非在私有云里需要，客户需要“快餐”，却上来一个“满汉全席”，给客户带来额外成本等一系列的问题。

 

 

[page]    3. 过度包装：西方有条香肠法则，大意为爱吃香肠的人，绝对不要去了解香肠的生产过程。这条法则亦适用于私有云产品，特别是国际及国内厂商提供的某些产品。某 国际厂商带领全球云计算领导团队，设计了一个私有云框架，它可以涵盖IBM、HP、Cisco、VMware甚至是开源等各种产品的组合。

 

 

    这样的架构框图具有相当的说服力（或者说诱惑力），但实际落地却存在比较大的问题。某些无法自拔的实施人员，被技术陷阱所折磨，最后甩手不干，留下一堆难以收拾的烂摊子。

 

 

    4. 通用性设计带来的损耗：在奔往“美丽云世界”时，这经常是被忽略的地方。“通用性设计”指的是类似于云平台里跨虚拟化层（Hypervisor）管理资源 这一类设计，这往往在从“虚拟化”演进到“自助化”和“自动化”云运维平台的过程中出现，这样的需求和企业的长期策略吻合（如防止被锁定在虚拟化产品上， 为用户开放自助式服务以提供更便捷的资源获取等），在原有虚拟化平台上搭建更完整的云平台。这一过程中往往会带来一些损耗，值得大家注意。

 

 

    （1）功能的丧失：异构资源池管理是“统一”私有云的趋势，异构对象包含异构存储、网路设备、服务器和虚拟化平台等，但消除异构的代价，往往是一些特别功能的丧失。

 

 

    比如说CloudStack的跨虚拟化平台（Hypervisor）管理是其一个亮点，但当CloudStack和ESXi（需要vCenter支持）结合 时，会丧失原有的增量镜像、DRS和FT等特别功能，甚至原有的内存快照功能也无法使用。（当CloudStack的快照功能和ESXi结合时，会采取全 备份而不是增量备份方式，假如每次备份一个20GB左右的虚拟机，可能需要20～40分钟，通过网络方式，由主存储备份到二级存储。而且由于没有内存快 照，用户由快照恢复虚拟机时，看到的是一个被意外关机状态的虚拟机。）

 

 

    （2）性能的损耗：通用性设计也会在很多方面带来性能上的损耗，其一 是调用Web API产生的通信成本，其二是业务逻辑上复杂度增加。如果OpenStack与ESXi结合，里面生成虚拟机，spawn函数的逻辑就变得复杂许多。 vCetner里从模板克隆一个虚拟机的逻辑比较简单：在共享VMFS层拷贝vmdk，修改。vmx文件，调用Regrister VM挂载到某台物理主机。

 

 

    但在OpenStack里，由于要迁就虚拟机配置模板（Flavor）和OS模板（Template），生成VM 时就会比较复杂：要生成一个伪镜像硬盘（Dummy Disk），用它来产生描述文件（Metadata file），然后删掉这个伪镜像硬盘，再挂载真正使用的卷存储（Volume）。

 

 

    通过以上的分析，我们发现私有云产品的成熟度，并非想象中那么完美。不过，虽然我们无法控制产品本身，但实施上的方法却可以掌握。

 

 

    （3）需求上的取舍：是否需要自助式平台？是否有必要跨虚拟化平台？只有明确需求，才能最终落实到功能的选择上，区分必需的功能、可以有的功能和不必要的功能。

 

 

    （4）循序渐进：很多云计算项目，在真正进入实质性阶段之前，通过建立简单的PoC（Proof Of Concept）进行验证，这种方法是有效果的，特别是在某些关键功能上。

 

 

    另外，要认识到私有云还在演进过程中这一事实，某些方案可能还存在设想和具体实施上的差距，一旦发现错误要勇于改正。某金融界私有云项目采用Xen作为底层 虚拟化技术，可在OS层面最初的选型不太恰当，造成实施阶段暴露的很多问题难以解决，但由于某些因素又无法在OS层面做重新选择，给项目实施带来不少难 度。

 

 

[page]    （5）产品是生料，煮熟煮好还需要厨师功力配合。某些产品（如开源的云计算方案）上的不足，往往需要一定的定制化才能适应企业的特殊需 求，因此要合理搭配运维和开发能力。企业往往不像互联网类公司，可以培养具有开发能力的团队，因此要在定制化的开发工作量和后期维护上面做好规划，否则一 旦主要人员流失，便很可能导致系统陷入运维困难的境地。

 

 

    （6）认识到学院型技术（长出来的）和实用型技术（设计出来的系统）的不同 （CloudStack与OpenStack，VLAN与OpenFlow），均衡短期规划和长远规划。须知分布式计算不等同于云计算，“把烂机器组成 云”这一类概念，更多适用在互联网环境（例如OpneStack里的Swift分布式存储，以及某些互联网公司投入人力的开源项目Sheepdog）。而 在企业级环境里不太适用，一是需求不强烈，二是技术团队费用不菲，三是技术本身成熟度尚未到达可用程度。喜欢新技术，却不等于勇于拿企业环境做新技术的小 白鼠。

 

 

    （7）学会对云计算推销人员的望闻问切：当别人给你介绍方案或系统时，如果他有很多案例、数据、模块等细节，那多半有两把刷子；如果他只会用酒店、水电煤、格子铺、银行、公私车等各种比喻，号称能把烂机器组成云，说起Google好像他自家开的店，则要格外小心。

 

 

    总结

 

 

    想引用非技术领域的一段话来总结本文，这段话来自黄仁宇先生在《赫逊河畔谈中国历史》，对中国社会的“间架性设计（schematic design）”阐述，批判其“预先创造一个数目的公式，向真人实事上笼罩着过去……以至于一般政令上面冠冕堂皇，下面有名无实，官僚间的逻辑被重视，其 程度超过实际行政效能……”在“没有产生一个牛顿型的宇宙观之前，先已产生了一个爱因斯坦型的宇宙观”，导致中国在古代的辉煌，却在近代的无能。

 

 

    当我们看到国内云计算大会上，某些从未动过手的专家们，发表高屋建瓴的见解和预测，参杂玄学、易经、诗句，试图重新以间架性的设计，夹带一种美术化的趋向，来“污染”云计算这样的新科技时，请不要放弃独立思考和批判的力量。

 

 

    作为具有丰富工作经验的云计算从业人士，本文作者指出“细节是魔鬼”，忽略细节可能会导致严重的后果，这句话同样在私有云领域适用，并从省钱和产品两方面进行阐释，提醒读者注意私有云的细节，且给出了应对建议。