对 AWS 和 Azure 的高可用性考虑
Resolution
当客户开始使用 VM 系列来保护其业务关键应用程序和公共云中的数据时, 就会出现 "您是否支持 AWS 或 Azure 中的高可用性" 问题。原2016年11月邮报 (下) 没有清楚回答这个问题。答案是肯定的, 您可以在 AWS 和 Azure 上部署具有 VM 系列的体系结构, 从而提供企业应用程序部署所需的高可用性和弹性。然而, 魔鬼在实施细节。
VM 系列主动-被动高可用性在 AWS 上
在 aws 上, VM 系列通过在一个 AWS 可用性区域内部署两个 VM 系列防火墙 (主动和被动) 来支持主动被动高可用性。如果出现故障, 则链接到活动 vm 系列防火墙的 AWS 埃尼将移动到被动 vm 系列防火墙。埃尼的移动是通过对 AWS 的 API 调用完成的, 通常需要60秒, 但有时更长。延迟是 AWS 结构的功能, 而不是由 VM 系列控制的副产品。在这段时间内, 有些会话可能会丢失, 但状态仍保持不变。
用这种方式使用主动被动, 可在传统定义中提供高可用性。除了故障转移滞后时间之外, 由于不允许埃尼移动跨越 AZs 的 AWS 限制, 此主动被动 HA 无法跨越多个可用性区域。此外, VM 系列许可证都是活动的, 因为它是运行所需的 AWS 资源, 从而导致开支考虑。
VM 系列在 AWS 上的高可用性 (使用自动缩放和 ELB 集成的入站)
提供数据中心级别高可用性的另一种方法是利用云结构构建 HA, 它可以跨多个 AZs 到您的部署中。VM 系列自动缩放和 ELB 集成允许您完成入站通信的最终目标。
AWS 上的 VM 系列的自动缩放在 VPC 中的两个可用性区域中部署多个防火墙。如果 VM 系列防火墙中的任何一个失败, 就会发生两件事情: 首先, AWS 负载平衡器检测到故障并将通信转移到剩余的、健康的 VM 系列防火墙上-这通常会在几秒钟内发生, 具体取决于健康证明设置。 其次, AWS 自动缩放组将自动删除不健康的防火墙, 并用新的、引导的 VM 系列防火墙来替换它们, 它们将被完全配置、许可并准备处理通信。
根据性能和成本敏感性的平衡, 可以调整健康检查和自动缩放组对检测和替换故障组件非常有攻击性或非常保守。 这使您可以在设计部署时进行自己的成本/福利决策。VM 系列不仅可以自动扩展进出, 还可以自我修复, 为跨多个可用性区域提供全面、高可用的解决方案。
VM 系列在 AWS 上的高可用性 (使用 Lambda 函数的多亚利桑那州)
另一种选择是利用 Cloudticity 为需要跨多个可用性区域的 HA 的客户创建的社区支持的基于 Lambda 的解决方案。在此部署方案中, Lambda 函数监视部署在每个 AZ 中的 VM 系列的运行状况。每个亚利桑那州都有一个活动的主防火墙来处理通信。如果 VM 系列防火墙失败, 另一个 Lambda 函数将将通信重新路由到部署在另一个亚利桑那州的辅助 VM 系列防火墙。
关于 Azure 高可用性的 VM 系列
对于 Microsoft Azure 部署的 VM 系列, 通过使用下面的 Azure 资源使用多个 VM 系列实例, 可实现高可用性。
VM 系列在 Azure 上的高可用性 (使用应用程序网关和负载平衡器集成的入站)
在 azure 上, VM 系列高可用性可以通过与应用程序网关和负载平衡器集成结合使用的 azure 可用性集实现。可用性集通过在不同主机上分配工作负载, 最大限度地减少或消除 Azure 基础结构维护或系统故障可能对您的业务产生的负面影响, 从而解决了高可用性和弹性的需要。作为负载平衡器三明治部署, 应用程序网关充当外部负载平衡器前端, 而负载平衡器充当内部通信分配机制, 将通信分配给 web 应用程序。
通信量被分配到两个 VM 系列防火墙, 每一个都指派给不同的可用性集。如果 VM 系列防火墙失败, 则由 Azure 应用程序网关将通信重定向到剩余的健康 VM 系列防火墙。当 VM 系列被修复 (通过可用性设置功能) 时, 将重新分发通信量。此体系结构不仅提供了可伸缩性, 而且还通过对 Azure 可用性集的支持提供了弹性和高可用性。
VM 系列在 Azure 上的高可用性 (使用应用程序网关和负载平衡器集成的入站和出站)
为了满足对 Azure 的入站和出站高可用性的需要, 基于社区的 ARM 模板可用于为入站和出站通信部署独立的负载平衡防火墙。每个防火墙由一个可用性集中的两个或多个 VM 系列防火墙组成, 以便可以独立管理和扩展或缩小以适应负载。来自应用程序网关的入站通信由入站负载平衡器接收, 将负载分配给入站 VM 系列防火墙的实例。防火墙应用安全策略并将安全通信路由到后端负载平衡器, 将负载分配给后端 web 工作负载的实例。
在 Azure 部署资源上确保面向 Internet 的 Web 工作负载安全
在 Azure 白皮书中确保面向 Internet 的 Web 工作负载安全
-----------原创文章: 2016年11月-----------
当客户将其应用程序和数据移动到公共云中时, 听到围绕传统数据中心构造 (如高可用性 (HA)) 的问题并不少见。这个问题常常被摆在 "你如何在 AWS 或 Azure 中支持 HA" 的时候。一个以云为中心的方式来提出这个问题, 是 "我们需要在公共云中的 HA 吗？
要回答这个问题, 我们首先需要准确地定义我们所指的 HA。如果问题是, 我们是否需要一个完全冗余、高可用的解决方案来保护公共云应用程序？那么答案肯定是的. 但如果问题是, 我们是否需要 PAN OS 有状态的 HA 故障切换就像我们在私有云中做的那样,那么答案可能不是 .
公共云是关于利用共享资源和部署可以在体系结构中的任何位置上生存失败的应用程序的。 这包括但不限于以下故障:
- 一个虚拟路由器
- 虚拟防火墙
- 网络交换机
- 应用程序实例
- 负载平衡器实例
- 可用性区域故障
- 甚至整个地区的失败
客户可能在您的笔记本电脑、平板电脑和智能手机上使用了许多甚至数以百计的应用程序, 而使用的基础结构出现了某种类型的故障。 99% 的时候, 他们不知道发生了什么事。 某些负载平衡器或交换机或路由过程绕过了故障, 应用程序默默地尝试了一下, 但对用户很少或根本没有中断。因此, 将我们的 VM 系列防火墙安全集成到公共云应用程序中的重点应该放在本地云服务上, 如自动缩放组、弹性负载平衡、路由等, 而不是泛 OS HA。
VM 系列确实支持 AWS, 但如果客户使用公共云迁移作为更新其应用程序的机会, 以利用本机云服务来构建一个能够最大化运行时间的弹性体系结构, 则通常不需要这样做。许多客户将开始迁移到公共云中, 它们遵循传统的数据中心硬件要求列表 (冗余交换机、路由器、防火墙等), 这可能限制了利用云能力的能力。使用冗余作为驱动程序的要求, 然后利用云 o 实现它将允许客户: a) 提高应用程序正常运行时间和 b) 降低成本。 我知道这并不总是可能的, 但试图把行李放在后面。
对于除了将遗留应用程序移到公共云之外别无选择的客户, 我们确实为 AWS 提供了 ha, 我们正在调查对 Azure 的 ha。 但代价是这样的。 他们不仅需要一个被动的防火墙和运行在任何时候 (以及与该法案), 但在公共云的 HA 依赖 API 调用, 这可能需要更长的时间, 我们可以在硬件上的专用网络基础设施。例如, 在 AWS 中, HA 解决方案依赖 API 调用将接口 (埃尼) 从故障的防火墙移动到被动防火墙。实际上, 这需要 30-45 秒, 但有时更长。很有可能, 医管局打算保存的会议, 在这段时间内已需要重新建立。
相反, 集中于负载平衡和动态路由可以收敛得更快, 让应用程序处理会话重新建立。公共云正在开发新的体系结构模式, 与 IT 应用程序体系结构中的一般趋势一致:
- 使用水平缩放 (又称扩展) 来处理更大的负载和可用性。
- 基于 web/HTTP 的体系结构的增长, 其总体状态较差;任何状态信息 (如会话 cookie) 都可以轻松地重建或被冗余
- 使用面向服务的体系结构 (SOA), 如微服务 (通常建在容器上) 来分解。跨多个层的应用程序栈, 独立于负载平衡器后面进行缩放。
在这些环境中, 会话数据存储在可靠的数据库服务中, 如亚马逊 DynamoDB 或亚马逊 ElastiCache, 并由应用程序服务器共享。例如, 在购物车服务中, 用户的 cookie 会话可能在 web 服务器之间同步 "ed/存储", 这样单个 web 服务器的故障就不会影响用户体验。在公共云和内部私有云中, 新体系结构的重点是服务可靠性, 而不是会话可靠性。
在 AWS 上使用自动缩放 VM 系列实现 HA
如上所述, 任何 AWS 部署都必须架构为弹性, 以消除基础结构组件故障可能带来的负面影响。如果出现故障, 解决方案必须能够检测并绕过故障。这对于解决方案的安全性也是如此。AWS 上的 VM 系列的自动缩放可使用本机云服务提供 HA。
AWS 上的 VM 系列的自动缩放在 VPC 中的两个或多个可用性区域中部署多个防火墙。如果 VM 系列防火墙中的任何一个失败, 就会发生两件事情: 首先, AWS 负载平衡器检测到故障并将通信转移到剩余的、健康的 VM 系列防火墙。 其次, AWS 自动缩放组将自动删除不健康的防火墙, 并用新的、引导的 VM 系列防火墙替换它们, 它们会完全配置并准备处理通信。
根据性能和成本敏感性的平衡, 可以调整健康检查和自动缩放组对检测和替换故障组件非常有攻击性或非常保守。 这使您可以在设计部署时进行自己的成本/福利决策。VM 系列不仅自动扩展进出, 独立于工作负载, 它还是自我修复, 为跨多个可用性区域提供全面、高可用的解决方案。
使用 VM 系列 Azure 应用程序网关和负载平衡器集成
实现 HA
VM 系列使您能够使用负载平衡器 "三明治" 为入站 web 应用程序工作负载通信部署托管扩展解决方案。应用程序网关充当外部负载平衡器, 前端应用程序, 并充当整个服务的 internet 网关。它将应用程序传递控制器 (ADC) 作为服务提供, 包括 HTTP 和 HTTPS 的7层负载平衡, 以及 SSL 卸载和基于内容的路由等功能。部署在应用程序网关后面的 VM 系列防火墙将提供全面的下一代安全保护 Azure 部署免受已知和未知威胁的攻击。在防火墙进行安全检查后, 通信量被发送到 Azure 负载平衡器, 充当内部负载平衡, 它将通信分配给 web 应用程序。此体系结构不仅提供了可伸缩性, 而且还通过对 Azure 可用性集的支持提供了弹性和高可用性
应用程序网关和负载平衡器处理任何通信中断, 可用性集针对 Azure 基础结构的计划和计划外维护提供保护。通过在不同主机上分配工作负载, 可以最大限度地减少或消除 Azure 基础结构维护或系统故障可能对您的业务造成的负面影响, 从而解决了弹性和可用性的需要。
引用
- 幻灯片 45-AWS 重新: 发明 2013-高可用性应用程序体系结构在亚马逊 VPC (ARC202) |..。
- 11页-亚马逊 Web 服务-云的架构: 最佳实践- https://media.amazonwebservices.com/AWS_Cloud_Best_Practices.pdf