不要让复杂性影响云服务推广

至顶网 12年08月26日 20:45 【转载】作者：zdnet 责任编辑：唐蓉

导读：Thoran Rodrigues认为，企业在向公共云迁移的过程中复杂性可能是让企业怯步的主要因素之一。而自动化的监控和报警工具成为企业所必须的工具。

复杂性是云计算普及路上的一个潜在杀手：为了实现云服务所承诺的可扩展性以及高可靠性，基于云的系统架构就会变得越来越复杂。而服务本身必须设计具有足够的冗余度并且有自我监控能力，数据必须能够自动备份到多个不同地点，同时多个服务器间的工作负载必须平衡。随着企业越来越多的关键性应用迁移到云环境，系统错误的风险，以及与任何错误相关的成本损失，都会相应的增加。

在传统的IT系统中，使风险最小化的方法就是设置监控和报警系统。与这些系统不同，随着云计算系统的复杂性日益增加，任何人或者团队都无法对于系统出现的故障做出足够与及时的反应。而随着云服务之间的交互性越来越强，很难快速锁定系统错误的始发点，而人工介入调查往往会导致更大的风险出现。

如果雇佣大规模的IT团队来管理云服务系统，就意味着将企业应用迁移到云服务所带来的成本节约效果完全消失。而降低云服务系统的复杂性，看上去也并不是一条可行的路线。

而唯一可行的方案，就只能依靠自动化的任务管理工具了。随着云架构、平台以及软件的进化，很多专业性的云服务管理解决方案应运而生，这些方案可以让企业在云上的日子过得更舒适。

基于云的监控和报警

此类工具中最好的产品属于基于云的自动化监控工具。此类工具可以让任何人监控不同服务器上的多种资源，并根据所监控的任何参数设定报警触发机制。此类产品的代表之作是Amazon的 CloudWatch 和CloudKick (目前已经被Rackspace收购)。这两款解决方案都支持对资源的实时监控，并自带多种报警设置。这两款产品同样都拥有丰富的可视化界面，并且具有可扩展性。 CloudKick支持所谓的“插件”，即客户自定义的监控脚本，而CloudWatch则通过API的方式与其它应用程序通信，获取监控信息。

这两款解决方案的不同之处在于它们的监控范围。CloudWatch 的监控重点放在Amazon自身的服务器和服务上，并通过API以及客户的相应开发，来支持其它服务器。而CloudKick则可以支持更多的云服务供应商，虽然这种支持是通过代理来实现的，但这些代理可以支持多种操作系统。因此他可以更快更容易的开始监控任何云服务器，而不管是哪家的云服务供应商。

另一种方案是由很多大型云服务供应商提供的云服务器管理服务。虽然这种方案并不算真正的自动化工具，但是却可以让管理云服务器的工作变得更简单。但不幸的是，这些服务一般都非常昂贵。而如果考虑到价格差异，为了获得高可靠性的另一个方案就是选择多个云服务供应商，这意味着会有不同的人来管理企业架构的不同部分(基本上也会有不同的服务等级)，这种方案基本上没有任何吸引力。

从监控到自我修复、直至更高级的功能

一旦应用了上述监控解决方案，原本由管理员手工处理的工作就转为了自动执行的任务。很多云服务供应商都带有自己的报警系统，可以集成进监控解决方案中，此类功能可以通过电邮，电话或SMS短信的方式将警告信息发送给管理员。但是报警仅仅是第一步。

诸如Rackspace 和 Amazon这样的供应商可以提供API，通过API可以实现一系列自动化任务，实现系统的可靠运转。比如，一旦监控系统检测到CPU或内存超载，系统就会自动加大CPU或内存的处理能力，同时将报警信息传递给技术支持团队。在极端情况下，该方案还可以自动将出现问题的服务器下线，并将该服务器的IP动态分配给新的服务器，而这个过程作为用户是察觉不到的。

监控自动化是把双刃剑

和很多以技术为基础的解决方案一样，监控自动化解决方案也是一把双刃剑。在一些失败的案例中，自动化的数据恢复过程可能会导致灾难性的后果。实际上，Amazon在去年4.21日就出现过这样的情况。当时一个配置上的错误导致了一个可用性错误，继而触发了系统的自动化响应机制，最终导致大范围的系统不可用。同时，在安装设置过程中必须确定的一系列元素，也使得人工参与管理变得很不可行。

当然，如果依赖于传统的监控系统来跟踪云应用服务，也不是不可行，只不过传统的监控系统不是针对监控云应用而设计的。而这些产品中的大部分要么是没有针对云环境进行商业化开发，要么就是缺少某种监控云服务所必须的功能，或者是许可证费用太高。自动化并合理的使用API对于监控系统来说十分重要，尤其是在云环境中。因此，企业应当尽量使用专业的云解决方案。