| 摘要：经历多年的炒作，IT行业今年春季才如梦初醒：云计算基础设施同样遗传了传统的数据中心运营中的IT缺陷，而这困扰着数据中心业务：意味着这一切都迟早会失败。 |
具有讽刺意味的是，这些事件也突出了云基础设施，如果管理正确，实际上可以提供了IT运营前所未有的能力，如高性能、灵活性和连续性的业务。
应对云失败的规划
保护您的组织针不受计划外的停机影响直接进入您的灾难恢复和业务连续性系统的冗余性和多样性的广泛依赖。业务系统需要能够在不同基础设施运行—无论它们是公共云，如亚马逊，Rackspace公司，或使用传统硬件的私有云，按照需要它们之间可以进行快速和高效地切换。
尽管有亚马逊的中断事件，公共云还是给组织实施业务连续性提供了在几年前根本不存在的广泛选择，而且其成本在他们能负担的水平，这让人留下了深刻的印象。看看这样的情形：现在，通过我的笔记本电脑，我可以启动十几个世界各地的不同地点的服务器-包括美国，欧洲和亚洲，而花费每小时只有几美分。因此，我可以设计我的业务需要的系统，可以更低的成本并合理地承受的本地的中断，这是以前做不到的。
这里的关键是你的基础设施设计要考虑各种失败的可能性。亚马逊的首席技术官WernerVogels多年来一直推崇这种宗旨，他建议测试系统的真实可靠性的唯一途径是“拔掉插头”。Netflix公司本身是一个重要的云基础设施的用户，它创建了一个叫“混沌”的流程就是随机地停止正在运行的某个服务器或服务应用程序，以确保整个系统没有他们也可以继续运行。毫无疑问，当美国东部AWS中断发生时，Netflix的整体运作没有受到什么影响。
实现抵御故障的系统并不是一件容易的事。当服务器的警钟响起，压力不断时，你怎么快速把您的业务从一个基础设施移动运行中的另一个？你如何设计一个系统，不仅可以为您部分业务的新计算资源开始运作，而且同时让用户和客户依赖的最新数据拷贝接续？
云中的冗余和自动化
云中当然有冗余，而且没有灵丹妙药。但是，一般来说合适的方式是：将冗余设计与云的自动化管理层相结合。第一步要建构一个解决方案，由能够承受单个节点的故障的组件组成，无论这些是服务器，存储量，或整个数据中心。每个组件（例如，在Web层，应用层，数据层）都要独立地考虑，其设计要与现实的数据中心基础设施和网络带宽，成本和性能等考虑到。弹性设计的解决方案，几乎和它用的软件组件的数量和花样一样多。例如，单就数据库来看就有许许多多的方法和弹性特点，包括SQL，NoSQL的复制，缓存技术等等。
但真正的秘决的在于你的架构是如何运行的。系统的哪些部分可以自动响应失败，哪些部分可以接近自动响应近，哪些不是？更具体点，如果一个给定的云资源失败了-无论是磁盘驱动器，服务器，网络交换机，SAN，或一个完整的地理区域-如何无缝地启动或转移到另一个，并保持不中断业务运行？理想的情况下，当然越多的自动化（或接近自动化），您的卓越运营会更好。
为实现这一自动化水平要求您的系统设计和配置很容易复制。例如，服务器需要跨不同云基础设施用可预见的方式的迅速重新部署。正是这样的自动化为组织提供了危机袭来时他们需要拯救数据的灵活性。作为例子，我们自己的RightScale的ServerTemplate方法提供了重新部署的能力，如果停电带造成中断允许一台服务器在云中，可以在短短的几分钟内启动另一个。
在云中的可自定义的最佳实践
正确的云管理解决方案可以通过可定制最佳实践来简化整个部署过程的启动。它还应提供所有基础设施，通过一个中央管理仪表板，也就是一个“单一窗口”，完全看到设施的各部分-通过这样的途径管理员可以监视基于实时需求进行能力调整的性能和容量变化。同样的自动化和控制，使用多台服务器让用户能够在需求增加时扩大容量，当灾难来时，也使他们能够迁移整个服务器部署到一个新的基础设施。
从日本地震和亚马逊中断的影响正在波及整个商界并导致组织重新思考他们如何确保业务的连续性。云架构提供了必要的应对区域灾害的分布式结构，但企业还需要云管理能力来转移它的运营到多个基础设施以保持正常运行操作。
有些人可能认为云是一个神奇的灵丹妙药。这不是，其实这是个好消息。认识到云架构的创始原则之一：一切都失败的方面，企业现在都在以前成本的一少部分基础上设计和构建比过去更弹性的服务。有了正确的架构和管理层，基于云计算的服务，可以提供无与伦比的灾难保护和业务连续性。
责任编辑：Alice
评论表单加载中...
