克服这些常见云爆发挑战

云爆发并未像有些人期望的那样取得成功，但是很多企业仍然渴望使用这种混合云架构。对于那些不惧潜在挑战的企业，需要考虑几个关键因素。

大多数企业使用公共和私有云基础结构来托管其应用程序。一项调查发现，85%的IT领导者认为混合云是理想的运营环境，而半数的人表示混合云可以满足他们的所有需求。

然而，“混合云”的术语涵盖了各种各样的场景，从简单的被动灾难恢复(DR)环境到复杂的冗余主动-主动应用程序。后者(同时处于活动状态和负载平衡的公共云和私有云环境)曾经被认为是理想的云运营模型，因为它使系统架构师能够充分利用两者的优势并最大程度地减少两者的弊端。

云爆发挑战

“云爆发”成为描述这种两全其美方案的术语。在此模型中，私有云基础架构可处理基线资源需求，并托管敏感的旧数据库和后端系统。而公共云基础架构则解决季节性负载高峰、临时爆发和横向扩展Web前端系统的问题。

云爆发的宏伟愿景甚至扩展到成本优化。在称为“多云套利”的概念中，企业利用多个IaaS提供商，以及实时成本分析软件，并在特定时间针对特定工作负载将突发定向到最便宜的供应商。

在什么情况下，云爆发挑战值得企业付出努力

云爆发需要大量的设计专业知识和部署规划。是否值得付出努力取决于每个工作负载的独特特征以及应用程序的业务价值。

突发模式非常适合那些容量需求发生极大变化的创收应用程序。在这种情况下，本地系统可以满足基线资源需求，而低成本、基于云的竞价型实例可以在需求激增时为这些系统提供支持。

不幸的是，就像通常的情况一样，这种“优雅”的理论面临着多云基础设施和应用程序设计混乱的现实。其结果是，即使有更多公司希望部署云爆发架构，但很少有公司真正能够部署。的确，持怀疑态度的人认为云爆发在很大程度上只是一个神话。咨询公司Architecting IT最近指出了通常阻碍部署的4个重大挑战：

我要添加第五个挑战：自动部署和动态扩展资源。这与公共云(主要是计算或容器实例、但也有存储I / O)处理瞬态突发需求的能力有关。

这些都是可解决但很复杂的问题，这使得很多企业得出结论，云爆发不值得付出努力，至少需要他们拥有可跨多个云运行的新一代分布式应用程序模型。对于那些仍然不为所动的企业，下面是解决每个云爆发挑战的方法。

网络和安全

网络和安全性是最基本的云爆发挑战，因为无论是否使用云爆发，任何混合环境都必须解决这两个挑战。幸运的是，IT团队可在这个领域获取最广泛的技术和服务，包括来自主要云提供商、电信公司、ISP和托管服务商的技术和服务。现在有多种安全方式可以链接私有云和公共云，以改善混合云的连接性：

这两种类型的专用电路服务都使企业能够完全控制网络路由、流量管理和安全策略。但是，Direct Connect等云提供商服务是克服云爆发挑战的最佳选择。这些服务依赖终止于云提供商数据中心的光纤电路，因此它们提供了最高的性能和最低的延迟。

数据一致性和保护

与云灾难恢复部署类似，云爆发需要将应用程序组件从本地复制到公共云IaaS。除非企业已经完全部署与云无关的基础架构即代码系统(例如Terraform、Chef、Ansible或其他允许以编程方式实例化资源和配置的系统)，否则企业必须手动构建必要的基础结构资源和网络拓扑。当部署到位后，云提供商的本机工具(例如AWS CloudFormation或Google Cloud Deployment Manager)就可以自动扩展或复制其他云区域中的资源。

企业可以多种方式解决数据同步问题，具体取决于应用程序架构：

动态资源分配

当建立网络管道和应用程序基础架构后，云爆发的操作部分包括在本地和云环境之间动态地定向和平衡工作负载。

这里涉及的主要工具是负载平衡器、应用程序交付控制器和虚拟网络接口。现代负载均衡器具有足够的配置选项，用于指定负载加权因子、资源/ CPU限制和备用配置，以适应任何突发情况。AWS Elastic Load Balancing、Google Cloud Load Balancer或Azure Load Balancer等云负载平衡服务会自动扩展容量以处理增加的流量。

云爆发的另一个挑战是动态容量管理。容器化应用程序在这里具有固有的优势，因为Kubernetes可以自动扩展群集和Pod，这是主机上的容器组。所有主要的云Kubernetes服务都包括集群自动扩展。

对于VM托管应用程序，容量管理更为棘手，尽管主要的云平台确实支持通过EC2 Auto Scaling和Azure Scale Set等服务对实例组进行自动扩展。这些工具会响应相应的监视服务中的策略，例如虚拟CPU利用率、网络流量或其他指标。

作者：邹铮 编译来源：TechTarget中国