云原生应用递送机制随需编排不仅只负载平衡

应用递送服务是企业IT环境重要的一环,但VMware原本的NSX Data Center方案中,应用递送服务仅有基础本地负载平衡的功能,VMware为此收购了Avi Networks,并改名为NSX Advanced Load Balancer,如此一来产品线功能就变得更加完整了。

 

在2019年7月,VMware正式宣布收购Avi Networks,并改名为NSX Advanced Load Balancer,为VMware的网路暨安全产品线增加了一名强力生力军。Avi Networks是应用递送方案(Application Delivery Controller,ADC)市场内技术非常革新的公司,对于导入新云原生应用,需要高流量负载平衡、采用自动化编排、部署于虚机容器混合环境、甚至公有云的企业来说,是非常值得考虑的方案。在接下来的文章中,将就NSX Advanced Load Balancer方案的效益、架构、功能等进行相关说明。

回忆应用递送方案的历史,大约是在上个世纪末开始到现在超过二十年,几乎每个台湾的中、大型客户应该都有采购并部署应用递送方案。各企业的资料中心内可能已经使用了相关的解决方案,但是传统的递送应用方案有许多早期的设计与包袱,虽然在传统应用架构内运作顺畅,但对应到新一代云原生应用的扩充性、随需部署、自动化编排等现代化需求上就有所不足了。

因应新应用架构变化新方案须考量AP面需求

近三、五年,因应云原生架构转变,新资讯系统需要被自动化、快速部署与更版、在不同的公有云私有云部署等需求大幅提升。而不仅是应用递送方案,现在企业对于任何的IT底层基础方案,其实都应该要对应新型态应用架构,在购买前考量如图1所示的事项。那么在台湾已经有超过两百个客户进行NSX Data Center设计方案的生产环境部署,是否符合了上面的要求呢?

图1 对应到新应用架构的变化,任何资讯方案建置时需要考量AP面需求。

第一,企业希望将网路与安全的配置能自动化编排,易于快速部署、异动、删除、Scale Up/Down、Scale Out/In。要达成这样的需求,首要必须要把网路与安全构件的管理集中化(NSX Management Cluster),提供现代化的API(支援Swagger – OpenAPI,以宣告式方式进行呼叫)以及SDK,而且可以很容易地被自动化工具调用(vRealize Automation/Ansible/Terraform)。

其次,NSX Data Center能够同时管理虚机与容器,无论用户的应用会采用哪种底层,都能让维运团队可以统合管理,并且容易横向扩充。而且功能应该要资源池化随需调用,不锁定特定硬体才能部署。

第三,NSX Data Center不仅在企业私有云环境内可以使用,也可以扩充到公有云环境(VMC on AWS, NSX Cloud)。

简单来说,上述的要求(易于自动化、原生就可以支援虚机∕容器环境、能够部署至不同公有云)已经是企业导入各种新IT方案前都应考量的项目。

而在理解NSX Advanced Load Balancer的方案与架构时,可以很直接地说,上述的需求都已被纳入设计。NSX ALB的架构根本与NSX Data Center如出一辙,甚至在几个地方走得更前面,与VMware产品的愿景与理念是天作之合。

而且应用递送服务是企业IT环境重要的一环,但这却是原本VMware的网路系列产品较为欠缺的。原本NSX Data Center方案内,应用递送服务仅有基础本地负载平衡的功能。但如图2所示,可以看到NSX Advanced Load Balancer的完整功能列表:

图2 NSX Advanced Load Balancer在各种异质平台上达成完整的应用递送服务与部署自动化。

‧本地负载平衡功能(Local Load Balancing):四层七层负载平衡、SSL Offload、基于URL的转址及安全防护、Web Cache/Compression。

‧全域负载平衡(Global Load Balancing)

‧Web Application Firewall与安全功能:OWASP弱点的防护,连线数∕连线频宽限制、来源地址限制。

‧连线日志与分析:做得极为完整,后面会对此进行详尽的介绍。

‧以软体定义的方式,在私有云、公有云以及集中管理的方式部署,并提供完整的API及自动化编排工具整合。

‧完整多租户支援

以目前NSX Advanced Load Balancer与其他的传统应用递送方案或是Application Switch等比较,功能面上大概没有做的就是SSL-VPN与WAN-Link Load-Balancer。但这反而不是在资料中心内「应用递送」的需求重点。

现有传统应用递送方案(负载平衡器)存在某些限制。请大家回忆目前标准采购负载平衡器是怎么做?一对一对买。需要买负载平衡器的「盒子」,上架、接线、配置。而且,基本上一定是买一对,因为担心单台硬体失效,此时另一台要马上进行接手。

举例来说,当企业要导入新应用,比如新一代行动网银。这个时候,Web业务的前端需要一对Load Balancer,Application Server前面也要一对。而重要应用需要测试区,测试区内的Web/AP前也要至少各一台。灾备中心也得规划,那也要至少各一台。而重要应用不会只有一种,可能好几组,因此在机房内就会如图3所示这样,有很多对负载平衡器摆着。

图3 容器管理与自动化。

购买负载平衡器时的考量

这种传统架构,从负载平衡器面世到现在几乎都是这样子,功能上当然相当成熟,运作没问题。但从以前到现在,有几个经常会是企业在购买负载平衡器时考量,但不易解决的问题:

以大笔预算购买负载平衡器,但容量都只能用一半

在生产环境中,负载平衡器后面就是最重要的核心业务,设备失效中断几个小时没有人能承担。而在传统的Active-Standby架构下,采购的两台设备就是需要有一台当备援用,因此有至少一半的容量空着。

导入新应用,容量不易规划,负载平衡器常须购买过大的型号

如果专案团队很清楚应用需求的效能规格,当然可以基于设备的规格文件(Datasheet)进行需求型号的规划配置。这里通常要询问的问题包括:业务规划的交易容量是多少?同时最多连线数大概多少?每秒新增连线数大概多少?频宽需求又大概是多少呢?

但尤其是新的业务系统,上线前大家真的清楚需求效能吗?而且风险是如果设备买太小,结果应用的流量比规划的大。负载平衡器的「硬体」应该没法直接加CPU加RAM来提升效能,只好重买新的。

所以,规划单位通常希望降低风险,会抓Buffer买较大的型号。此时,常常就会发现设备摆在那里,但真正使用的效能其实没有那么多。

业务系统因应促销活动,结果现有设备容量撑不住,但无法提升

而与前面相反,现在的Internet服务可能因为业务单位的促销活动、抢票,或是周期性的某些时候就是交易量较大。在这些业务交易量短期突冲时,如果超过了负载平衡器硬体的能力,企业无法拿其他台空闲的设备过来帮忙。

因应新业务架构,企业要导入自动化流水线,负载平衡也要整合在应用部署流程中,怎么做?

应用递送方案已经很成熟并且运用多年。但要因应自动化业务敏捷时部署,经常需要从产品本身架构做改变,例如做成软体定义(Software-defined)并将方案的控制层与转发层区分,提供集中管理且有易于呼叫的宣告式( Declarative)开放API。而在传统的友商方案内,虽然都能宣称有提供API,但是呼叫方式以及支援范围都较难以方便使用及整合。

应用递送架构快速回应变化

这里想要说明的是,在传统的Client/Server或三层式应用架构业务系统中,原本的负载平衡方案没有什么问题,交易需求的容量也较能够规划及预测。但在新型态的云原生架构内,早期的容量估算方式早就不合适了。新的云原生应用常会有下面这几种特性:

‧应用的流量与以前相比,更难估算,峰值与平均值差异极大。能快速因应业务需求扩充(Scale Up/Scale Out)越来越重要。

‧业务上线下线异动频繁,支援自动化编排机制已经不再是加分项目,而是必要需求。

‧应用不再仅部署于私有云与虚机,也需要在不同的公有云环境可以支援,也可能是虚机或容器。

因此,一个支援云原生方案、能够快速回应变化的应用递送架构,可说是企业越来越需要的,而NSX Advanced Load Balancer可以因应这样的趋势。

在后续的投稿文章内,会陆续介绍的主题包括:NSX Advanced Load Balancer方案的技术架构简述、NSX Advanced Load Balancer方案在大型Internet应用上的效益、NSX Advanced Load Balancer方案的应用分析与日志、NSX Advanced Load Balancer方案在公有云上的应用、NSX Advanced Load Balancer方案在自动化编排上的优势与多租户架构。

结语

目前,Avi Vantage方案已经在VMware正式更名为NSX Advanced Load Balancer。因此在本系列文章,无论是谈论Avi、NSX Advanced Load Balancer或NSX ALB等等,都是指同一个方案。此外,如果本身已经是NSX Data Center的用户,一定会询问原本NSX DC内的Load Balancer功能还会支援吗?请不用担心,NSX DC内的负载平衡功能都会持续提供与维护,但如果是进阶的新功能,后续主要就放在NSX Advanced Load Balancer产品内。

Author: bwh