文|启迪云交付经理 董乐

人人心中的哈姆雷特

前阵子与行业内的朋友聊到企业云的建设路线选择事有些客户可能感觉云应该是一个很复杂的东西，因为它要涉及计算、存储、网络；而有些客户可能感觉云是很简单的东西，因为它用了VMware的vSphere和Citrix XenServer，人人心中有一个“哈姆雷特”。

但云的复杂，不应该表现在其安装部署上

也不应该表现在其页面的难用和费解程度上

云的复杂应是充分考虑用户的现有IT环境，自如应对用户各类应用上

我认为，云更多考虑不应该是“颠覆”，而是如何“融入”。就像两个人谈婚论嫁一样，要过的长，就得门当户对，两个家族能够很好的融合在一起才行。否则，初期爱的死去活来，日子长了，感情淡了，矛盾也就出来了。可能云厂商都在问，用户为什么不选择我，但请想想你为客户做了什么？婚姻的长久需要两个人为彼此的改变、妥协、将就，而不是在一边孤芳自赏，盛气凌人。

各个云厂商的产品，就像一个个适龄待嫁的姑娘，客户呢，我觉得就是适龄待娶的小伙子，双方能不能走到一起，各自还真需要一些努力。刚才提到了云的复杂性，我认为云的产品只是一个未曾打磨的工具，或者说只是一个未嫁的姑娘，还没有成为适合这个家的女主人，行家里手，如果要真正过期日子来，需要学的东西还蛮多，做饭、大扫除、收纳、换被罩、生孩子、洗尿布，还要有个好态度，把这当自己家，能够容忍、融合、融入家的环境，满足日常家长里短过日子的需求技能才成。“云真正能够用起来，到底还有多长的路要走？”

存储方面

客户环境中会有多个存储资源池，例如：针对数据库或核心业务系统的FC SAN存储池，针对非结构化数据（如：合同扫描件、产品销售时的双录资料（录音、录像）等）的分布式存储，已经针对开发测试、大数据平台的服务器本地磁盘，并且在各大类的存储池中。

还要按盘的类型进行细分小的资源池，如：SSD的铂金资源池，SAS盘的黄金资源池，SATA盘的银级资源池，这些都是针对不同应用的容量、IOPS等需求提供不同的应对方案，如果只是将云的SDS（软件定义存储理解为分布式存储，能不能做压缩、能不能做cache，能不能本地存储优先），我认为很狭隘。

用户的真正需求是：能够将存储资源池、分级分类，按不同的数据类型、应用需求来提供不同级别SLA的服务。在此云存储的本意是：集成、统管、分级，而不是教导客户什么都用分布式存储来解决。

原因：

1. 分布式存储的道行还不深，还没有那么久的生产积淀，无法满足用户核心系统的SLA；

2. 分布式存储的故障恢复，系统管理员通常都搞不定的，需要研发介入才成；

3. 分布式存储，如果优化不好（如：水位和IOPS的分配），会给管理员带来灾难。网络方面

用户对于网络的需求，决定了云平台的部署架构，对于像政务一样内外网物理隔离的，那只能是部署两套云平台来满足需求，如果客户的安全要求逻辑隔离，管理网能通，数据网隔离，那一套云平台就是可以的。

另外，目前公有云资源，好多用户是作为自身资源波峰需求时的一个补充，并且做相应的市场拓展时，也利用公有云的带宽和机房分布优势来补充自身数据中心分布和带宽的不足，所以私有云和公有云需要通过专线或广域网打通，在这个层面，阿里投资的ZStack联合daho做的还不错，可以实现公有云、私有云在页面简单的配置，即可打通混合云。

再就是，今后对于白盒交换机的支持，即：由云来根据需求自动置备操作系统给交换机，并且策略自动下发，云的SDN不绑定特定型号、品牌的交换机，并且通过云自定义浮动IP（EIP）或网络出口的QoS。计算机方面

计算层面，虚拟机这是个必选项，但对于AI、机器学习、大数据等场景，要不要由云来管，这是业界一直在纠结的问题，支持的声音是因为要由云做统一的资源调度、电源管理、监控，不支持的声音因为云这块一直做得不太好，一直是一个鸡肋，从OpenStack的Ironic功能来看，物理机的操作系统必须是云的控制节点传过去的，才能实现监控、电源管理，那新机器还成，旧机器呢，如果旧机器还跑着业务呢，这就完全与云独立开来，无法由云来做统一管理了，所以如果物理机管理这块，能够自动推送Agent，无感知的安装，才是正道（类似于BMC等各大监控厂商所做的东西）。监控方面

我看过好多家云厂商的监控，总结下来，云厂商做监控，完全不专业，虚拟机、物理机、控制节点的视图完全是割裂的，不能从一个Dashboard看到所有用户关心的点，所以从现状来分析，这块应该是集成用户现有的监控系统，云平台吐数据到指定地方也好，虚拟机或物理机装Agent也罢，还是按照之前的套路来做，但反过来，私有云纳管所有设备的监控、以及私有云+公有云的跨云混合监控，这块还是很大的痛点，值得做下去。

镜像制作

目前的云这块做基本很烂，反而不如原来的VMware、Citrix这些虚拟化的厂商，也不如SmartX这些超融合的厂商，私有云的镜像必须经过定制。

至于其原因，是因为用户的OS一定要合规，要打N多的补丁，做N多的防护才行，不是云厂商自己从社区下载下来的CentOS就能用的；另外，为能够快速部署应用，用户也会将自己的应用预装到镜像之中。

但现在的云厂商还是自以为是，做镜像没有界面，只能后台通过命令行操作，得先用装了KVM的机器先装一个虚拟机，然后装应用，打补丁，之后再打成RAW或QCOW2的包，命令行上传到云平台，有些甚至需要再手工改下数据库表，做下Insert，这样搞，用户会疯掉的，做一个镜像一个礼拜，如果云上线了，我应用的快速迭代怎么实现？还不被你拖死！能不能有个镜像上传界面？能不能有个虚拟光驱的功能？APM（Application Performance Management）

其实目前的IaaS还是基础架构是基础架构，应用是应用，两层没有联系，没有互动。如何让IaaS层更加灵动，让客户对IaaS产生更好的审美，必须与应用来结合，动态、弹性的支撑应用，但目前看下来，包括阿里、京东在双十一的时候，也不是真正的弹性，也是通过去年的资源情况和今年的任务先评估，在之前预开了很多的资源，所以目前看来弹性架构是个伪命题，但IaaS既然接过了资源调度的任务，那就有责任将其变为真实的命题。

我寓言APM是串其应用和IaaS的这条线，APM去监控应用的响应速度，后台每个资源的利用率、连接数等各种维度的参数，然后由APM来判断资源是否过度或者到了阀值，需要弹性扩容或缩容，并且调用IaaS的API来动态开启和关闭这些资源。这个理想很美好，但万一实现了呢？

自动化部署和运维，每家的云平台对客户来说都是个毛坯房，要住就得装修，那云的装修指什么呢，就是根据用户的环境、需求、应用、运维的流程等形成的一个个的定制化的脚本。

新生成一个虚拟机，能不能先去配置库查一下命名规则，然后自动改一下hostname；新生成的一个web服务器，能不能自动连上数据库，并与LB协商，改下LB的Pool配置，把自己加到集群里去；这些工作量可能不大，但积累起来，管理员会累死，IaaS落地的时候，有责任将管理员从这些琐事中解放出来，实现自动化或半自动的部署和运维，但这些都需要根据用户现状定制化的写脚本才成，这也是云这个毛坯房的装修，我们说的云要融入客户的环境，不只是支持用户的现有设备就可以了，还有这些软的东西，需要我们实实在在的去做，这样云才能真正产生价值，这门婚事才能长久。

最后总结一下，云厂商除了要卖给用户产品，还要管人家的死活，既要管杀、又要管埋才行，做事做全套。否则出来混，总是要还的！

总结

云=三分产品+七分服务！