漫谈：基于云服务的运维模式初探（云计算漫谈之二）

虽然说公有云向普通用户屏蔽的很多底层细节，但通过云服务的使用方式，其实可以看到一些底层运维的机制。举一个最简单的例子，公有云的虚拟机服务，通常都不会做虚拟化中很常见的一个功能——在线迁移，这意味着如果需要对云服务所在的底层基础架构进行运维时（如打补丁），不会将上面的虚拟机在线迁移到其他物理节点，这时候用户就会面临一个问题，你的VM可能会被关闭和重启。

如果用户没注意到这个问题，可能以为云服务发生了中断，但其实这一点在【云服务的SLA】中有着明确的定义。还是以虚拟机这个云服务为例，通常单实例的VM是没有SLA保障的，不同的云服务提供商或许有不同的定义，如要求多个VM要在同一可用性集中（或者在不同的AZ中），实质上是将多个实例分布在不同的更新域，这样维护的时候这些VM不会同时重启，以保证服务的连续性。可见，使用VM这个云服务，对你的应用架构会有着强制的要求，即你的应用本身应该具备分布式或者高可用能力，这样在底层基础架构的维护窗口中，上层的应用才不会中断。

我想，到这里你或许发现了，传统的应用，简单的搬迁到云服务上，这件事实际上是有问题的，风险无法规避，SLA也无法保障。当然，技术的说，这个也不是一成不变的，例如目前Azure通过【就地实时迁移】技术，已经具备单实例SLA，这里就不深究了。

以上谈的内容可能有些技术了，但这件事情本质在于，云服务在试图进一步将上层应用和底层的运维进行剥离。这绝不仅仅是一个技术问题，更会逐渐的影响到未来企业IT的【组织架构】和【运营模式】。

这里会有一个有趣的话题，一直以来，我想单纯的虚拟化大家早已经想的很清楚了，但在企业中私有云的价值却一直不显著，其中一个原因是，私有云对降低运维成本和提高效率带来的收益，并不足以抵消其复杂程度和IT要求提升所带来的成本上升，或者说这种提升并不是那么显著。那么问题来了，如果私有云也【云服务】化，其价值体现是否足够呢？

目前华为的私有云方案正在走云服务化的道路。我想在这个时间点，我们可以看一下Microsoft Azure Stack这个方案，不同于传统的私有云方案，Azure Stack主打的是和公有云一致的体验和API，在微软看来，Azure Stack相当于在企业侧放了公有云Azuer的一个Endpoint，私有云的使用，完全围绕着云服务为中心。于是乎，现在有个有意思的问题了，使用公有云，用户可以显著降低对运维的投入，实际上用户也接触不到基础架构运维这个层面。但使用私有云，整套基础架构实际上是放在用户场内数据中心，如果说要一致的体验，用户是否也可以从降低运维投入上获益？

在这件事情上，微软非常大胆的做了几点设定（由于产品尚未GA，因此以下内容不一定是最终实现方式）：

1、基于AzureStack的建设必须非常标准化，在这种标准化建设中，整个基础架构更为模块化，不会存在SPOF的问题，由于硬件层面彻底和软件层面分离设计，所以硬件层面的运维完全以备件替换的方式进行。例如，任何一块硬盘、一台服务器、一个网络交换模块、甚至于一个机柜的故障告警，可以通过直接更换硬件的方式进行，更换过程中可以不考虑或者只需要有限的考虑对其上业务的影响，这些会通过标准的流程固定下来。

2、在整个云平台的软件层面，企业的基础架构管理员实际上不具备完整的【本地管理员权限】，这就是说，企业基本不能对云平台进行运维。因为所有的云服务全部标准化和微服务话，解耦程度和自动化程度相当高，企业自己的管理员只能监视有无故障发生。大部分情况下，软件故障可以自动排除，如果出现无法排除的软件故障，需要交付厂家（通常就是集成的硬件厂家）进行一线故障排除，由微软远程进行二线故障排除，这些费用已经（部分）包含在云平台的订阅价格中。

3、对于云平台的补丁升级，或者更新云服务，必须由交付厂商进行，企业自己不能进行。

4、企业只对云平台的租户管理、资源分配具备管理员权限，使用体验完全向公有云Azure看齐。

看起来，使用微软定义的客户就是【傻瓜】，你就好好用就行了，运维这么复杂的东西你就别碰了。从下面这张图中，可以看到微软的想法——把AzureStack做成一个高度集成和标准化的【盒子】嵌入到用户数据中心中。

从我个人的感觉中，这个想法确实很超前，也许不适合目前90%的企业用户，原因是对标准化和自动化的要求太高了。但如果用户非常习惯使用云服务来搭建企业的云平台，这种方式或许是私有云价值体现的一条路径。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。