VMware 助力应用的多云自动化、自助服务、安全性和弹性扩展

商业市场的快速变化导致企业寻求不断加快数字化转型，不断推出新的应用以吸引客户并提升用户满意度。

为了缩短应用开发和上线周期，他们正在寻求实施持续交付/持续集成 (CI/CD) 实践;并且为了降低成本、提高系统抗风险能力，使用着包括裸机服务器、虚拟机和容器在内的各种计算基础设施，将应用从本地扩展到跨多个公共云的“数据中心”。应用开发人员以及应用所有者，希望通过 GitOps 或 CI/CD 流水线方法，自动化地完成应用的多次、多位置的重复部署。但是应用最终是运行在“基础设施层”之上，在运行和维护方式上，现代化应用层与基础设施层之间的差距是巨大的。

应用层使用 DevOps 和 CI/CD 方法时，最佳选择是只需面向一种抽象出来的底层架构，而不是面向多种硬件设备的多种 API。如果应用层要做的针对不同的底层设备 API 进行 DevOps 开发，人员和时间方面耗费巨大;如果出于对多种底层环境的陌生感而仅适配其中一种，就等于被锁定在特定的硬件之上——难道以“敏捷应用”和“DevOps 和 CI/CD”之名，将应用重新拉回“软硬件一体化”的时代?DevOps 和 CI/CD 需要跨多云环境的智能自动化和一致的网络服务，以消除由数据中心的负载均衡设备、云中的虚拟 ADC 或容器网络的开源解决方案造成的孤岛。

VMware 站在应用开发人员的角度，在应用与底层基础设施之间定义了“现代应用连接”这个虚拟化层，为 DevOps 和 CI/CD 屏蔽了底层设备的差异，打通了应用自动化开发、部署和维护之路。NSX 是“现代应用连接”解决方案中的重要支柱，自带了很多自动化元素，可以自顶向下进行基于 API 的意图自定义，而无需定义执行细节;NSX 高级负载均衡负责应用交付的自动化。VMware 的方案，将抹平应用层与基础架构层之间差异，使现代化应用的 DevOps 和 CI/CD 方法可以贯彻到“底”。

对于任何以“设备”为中心的基础架构，都面临这样的困境。随着虚拟化技术的普及，“设备”可能物理盒子，也可能被改造成虚拟机形态，但只要它们的工作原理没有变化，就不支持弹性扩缩、自恢复、自主决策这些真正的“自动化”特点。这个架构无法在 DevOps 环境中，真正支撑业务所需的自动化和自助服务。本文讨论的重点是负载均衡和应用交付，因为路由和交换等基础设施可以在应用发生更新变化时保持相对的稳定性，硬件设施和软件策略配置无需随应用频繁变更。而应用交付是直接为应用服务的，是连接客户与应用的必经之路，决定着新上线的应用是否能够被客户稳定且安全地使用。

传统应用交付方法的困境

应用交付的起源和核心是“负载均衡”。基于“设备”概念的构建的负载均衡器欠缺自动故障恢复功能，也缺乏跨多个云扩展的能力和自动化，欠缺根据流量模式自动扩张(或者缩减)负载均衡的能力，并且需要对每个“设备”实例进行大量的手动配置和单独管理。参见图 1。

图 1：创建虚拟服务的传统方法

图 1 中的架构和方法不是为 DevOps 和 CI/CD 的流水线设计的，因为这样的环境非常复杂、僵化和脆弱，它的使用方法严重地依赖“设备”——以设备为中心，而不是以业务和应用为中心。

VMware NSX 高级负载均衡(本文中简化缩写为 NSX-ALB)使用软件定义的架构，将中央控制平面(控制器)与分布式数据平面(服务引擎)分开。控制器是整个系统的“大脑”，充当分布式数据平面的智能、管理和控制单点，使其完全自动化并与 CI/CD 管道无缝连接以进行应用交付。控制器提供基于闭环遥测的全面可观察性，并提供易用的深度分析，以根据应用监控、端到端计时、可搜索的流量日志、安全分析、日志分析、客户端分析等信息做出自动化决策、部署和执行。

API ≠决策自动化

以应用为中心的架构需要自动化并向业务线提供自助服务。自动化和自助服务代表了现代智能网络的发展。很多时候，在为负载均衡、WAF、GSLB 和容器 Ingress 网络等应用服务提供 “API” 和“交付自动化”之间存在巨大鸿沟。问题是在于：人工编写脚本调用 API，不是自动化;而让系统闭环智能执行日常运维的“决策”，才是自动化。NSX-ALB 采用的声明式“决策自动化”可简化操作、提高敏捷性并提高安全性。

决策自动化允许管理员设定网络运行的预期结果，然后自动部署、配置、按需提供服务，并管理应用服务的整个生命周期，包括自动故障恢复。在闭环机器学习的帮助下，声明式模型中指定的计划和策略会自动实施、交付和强制执行。这避免了繁重的脚本手动编写脚本以应对特定场景的要求。决策自动化还允许 IT 架构师甚至应用所有者指定他们的意图，而无需依赖 IT 工程师手动输入或编写专用脚本。见图 2。

图 2：任务脚本与决策自动化

我们可以打一个比方：图 2 中左侧依靠 API 调用任务脚本的方式，就好像是操作提线木偶，一举一动都离不开人工干预;而真正的人工智能和机器人，则如图 2 右侧所示，具备自主决策和自我管理的行动能力。虽然现有的“机器人”都不完美，但已经从本质上与“提线木偶”区别开来。

NSX-ALB 的决策自动化采用软件定义的、与底层无关的、基于云原生的架构。该架构将重点从基础设施转移到应用，将专有硬件转移到软件，从手动配置转移到集中策略。它允许调用程序接口 API ，但更重要的是可以实现更好的自动化、系统交付的结果并降低运维成本。参见图 3。

图 3：Avi 高层架构

自动化应用交付

使用 NSX-ALB 创建 VIP 的决策自动化

让我们举一个网络管理员日常工作可能面临的例子：比如，新业务上线，需要在负载均衡系统中为这个新业务的服务器创建一个新的虚拟服务。虚拟服务，就是负载均衡器后面的业务系统的所使用的虚拟 IP 和端口。

对于基于硬件的应用交付系统，首先按下面图中的列表进行自查：已有的负载平衡器是什么?是否配置在正确的网络环境中?它现有的性能水平是否足以正常运行?它有能力满足业务未来增长的需求吗?除了这些，还有其他依赖条件吗?

然后，一旦有了这些问题的答案，需要做出设计决定：是否需要调整网络环境，是否继续沿用现有的硬件，是否需要购买新硬件?如何配置负载均衡器?为这个应用预留哪一个 IP 地址作为虚拟 IP ?如何配置上下游相关的防火墙和路由?如何配置统一身份验证?设置哪些系统告警?这些需求调研、设计、测试、实施的过程需要几天到几周的时间，如果需要购买并添加新设备，则需要几个月。参见图 4。

图 4：创建新虚拟服务的传统部署流程

以上步骤显然不是对现代化应用架构和 DevOps 流程友好的方式。让我们看看如何使用 NSX-ALB 做到应用发布的自动化、流程化、敏捷化。

管理员只需在控制器上声明本次发布的应用所对应的虚拟服务属性(位置、协议、端口号、代理模式等)，然后控制器将进行完整的自动化策略配置：控制器在所有适配的基础架构环境中自动找到最佳位置(数据中心或公有云)、最佳主机来自动部署新的服务引擎、自动从地址池分配 IP 地址、配置网卡、下发虚拟服务策略、WAF 策略、安全策略、配置身份验证和授权、将虚拟应用的 FQDN 注册到 DNS、自动配置和获取 SSL 证书……参见图 5。

图 5：NSX-ALB 自动化部署创建新的虚拟服务

自动增加容量和重新平衡

NSX-ALB 的服务引擎(SE)是工作在数据平面的负载均衡器和 Web 应用防火墙 (WAF) ，可提供流量管理和应用安全性，同时从流量中收集实时分析。在执行应用交付任务时，服务引擎 SE 可能会遇到资源耗尽的情况。这可能是由于部署了新应用或已有应用的访问量提高，导致 CPU 利用率或内存利用率或流量出现大幅增长。

从 SE 实时监控多个应用和网络遥测数据，控制器实现了在应用的整个生命周期中基于决策的 SE 自动化管理和运维。从 SE 的初始部署开始，到根据需求动态增加 SE 数量或跨本地、多云和多区域部署的自动故障恢复。见图 6。

图 6：弹性 SE 扩展——数量和位置

多生态集成

借助 NSX-ALB ，企业可以毫不费力地跨多个云移动工作负载。通过在流量高峰期间自动将应用扩展到云上，使企业能够使用公有云作为其数据中心的自然扩展。NSX-ALB 控制器可以在公有云中自动创建应用资源，以吸收突增的流量。控制器可以与 vCenter 和公有云的 API 进行对话。因此，如果您希望在 任何环境中部署负载均衡器或服务引擎，管理员只需要声明虚拟服务属性“我想将此应用部署到xx环境中”，随后，控制器可以将负载均衡自动实例化为服务引擎 SE，并将虚拟服务自动配置到 SE 上。

NSX-ALB 本身并不是技术孤岛，它需要与周围的环境、周围的生态系统相结合。它可以通过与 Infoblox 或其他 IP 地址管理工具来协作自动配置 IP, 也可以通过与 Amazon 的 Route53 之类的功能协作来自动将虚拟服务注册到 DNS 中。它是如何工作的，应用所有者和开发者真的不需要知道，他们也不关心。所以从应用所有者的角度来看，就非常简单，只需要启动一个应用的部署意图， NSX-ALB 的控制器就会自动实例化它。参见图 7。

图 7：生态系统整合

与自动化工具集成

NSX-ALB 可以通过 Terraform、Ansible、VRO、VRA ，或 Python 脚本轻松构建自定义策略，并通过控制器内置的决策自动化智能来完成端到端的自动化。参见图 8。

图 8 NSX-ALB 与应用自动化工具的集成

总结

VMware 的 NSX 高级负载均衡通过集成的策略管理器、决策智能中心、应用监控和分析、安全性、预测性自动扩展和多云部署，提供了自动化的应用交付系统，同时实现了现代化应用架构中的运维流水线。无论应用是部署在私有数据中心或多个公有云的混合环境中，都可以提供统一的架构和一致的用户体验，以及基于集中控制的决策自动化、执行自动化和运维自动化。