负载均衡设备哪家好?最好是能适用于金融业的
在金融行业的传统IT基础架构中,专有硬件负载均衡设备(如F5、Radware等)普遍具备功能强、性能高、运行稳定等特点,成为解决应用系统对外提供统一服务的首选方案。近年来,随着OpenStack、Kubernetes等云技术的兴起,应用系统的微服务化、快速迭代对资源的弹性伸缩能力提出了更高的要求,这就要求负载均衡有更好的灵活性和开放性。开源负载均衡软件因其开放的设计,完善的API接口以及对应用灵活部署需求的满足,在金融行业的云环境中逐步推广使用。民生银行在Kubernetes容器平台建设中,探索使用了一种灵活的软件F5解决方案,在利用F5传统优势的同时,也满足了容器应用的高灵活性要求。
Kubernetes服务发布方式及局限性
Service是Kubernetes最核心的资源对象之一,通过它可以为一组具备相同功能的容器应用提供一个统一的访问入口地址,并将请求负载分发到后端的各个容器应用上。这一点与传统IT基础架构中F5等负载均衡设备将访问请求负载分发到后端功能相同的应用上类似,Kubernetes集群中每个节点上运行的kube-proxy其实就是一个智能的软件负载均衡器,它负责把对Service的请求转发到后端的某个pod实例上,并在内部实现服务的负载均衡与会话保持机制。Service被分配了一个全局唯一的虚拟IP地址,称为ClusterIP。但ClusterIP只能实现集群内部的访问(即东西向服务),对于需要通过外部IP对外提供访问(即南北向服务)的场景,Kubernetes提供了三种主要方案,分别是NodePort 、LoadBalancer 、Ingress。
1 NodePort
NodePort 的实现方式是在每个节点上为需要外部访问的Service开启一个对应的TCP监听端口,外部系统用:可以从集群外部访问一个NodePort服务,NodePort 服务会路由到 ClusterIP ,通过kube-proxy转发至后端的容器,完成对服务的访问。NodePort的方式是解决服务暴露问题最直接的做法,其配置和维护都很简单,但它依赖于kube-proxy,目前仅支持轮询算法以及源地址会话保持。在负载均衡的其他特性方面还有一定缺陷。另外,NodePort占用node节点一个独立的端口,限制了集群中暴露服务的数量。且在实际使用过程中定义一个NodePort,需要在Kubernetes集群中的所有节点上开通此端口的入访能力,因此一般会结合集群外的负载均衡设备,与kube-proxy形成两级负载均衡的架构,对性能会产生一定影响,同时增加成本。
2 LoadBalancer
LoadBalancer 是Kubernetes深度结合云平台的一个组件,使用它构建服务时,实际上是向底层IaaS申请创建一个负载均衡来实现。IaaS网络和容器网络在不同云平台的融合方案不同,因此LoadBalancer 和云平台的网络方案深度耦合,只能在特定的云平台上使用,局限性较大。
3 Ingress
Ingress可以很好的解决LoadBalancer和NodePort的限制。它由3个组件组成:Ingress策略集、Ingress Controller和反向代理负载均衡器(如Nginx)。Ingress策略集定义了集群外的流量到达集群内的Service的规则。Ingress Controller与Kubernetes的API交互,实时感知后端Service、pod的变化,再结合Ingress策略集生成配置,然后更新反向代理负载均衡器的配置,实现动态服务发现与更新。反向代理负载均衡器对集群外流量进行负载分发。现有的Kubernetes版本已将Nginx与Ingress Controller合并为一个组件Nginx-Ingress-Controller,无需单独部署Nginx。但Kubernetes原生Ingress是一个七层负载均衡技术,仅适用于http服务。另外,其并未解决Kubernetes环境下,不同租户的服务隔离问题。
F5容器服务发布方案及实践
随着容器技术的发展,在应用容器化、微服务化的趋势下,F5公司基于多年在负载均衡领域的经验推出了Kubernetes容器服务解决方案,既兼顾了容器环境下应用随时可能启停、迁移等灵活性要求,又具备传统F5稳定、安全、高性能等特性。
F5容器服务解决方案实现了容器的南北向服务更加灵活的发布能力。相对于开源方案具备以下优势。
简化的架构:目前开源方案中,在业务量增大后,需要在容器外部再部署负载均衡设备来实现node级的扩展,而F5的方案只需要通过一组设备就可以实现pod或node级的扩展,简化结构,方便使用。
广泛的应用场景:目前开源方案只能支持七层应用的分发对用户的使用场景有所限制;F5的方案可以支持四、七层方案,可以满足用户绝大部分的使用场景。
灵活的发布能力:开源方案使用node的IP地址进行发布,发布场景受到很大限制;F5方案中VS(VirtualServer)地址可以使用用户规划的任意网络地址进行发布,实现灵活部署的需要。
增强的应用交付能力:开源方案在应用交付的算法、健康检查等都比较简单;F5方案中提供了19种负载均衡算法、38种健康检查、11中会话保持方法,丰富的方法方便用户各种应用的灵活配置。
监控能力:开源方案实现了基本分发功能,但监控能力很弱,对数据流以及业务的监控很有限。F5方案中,可以通过本身的HSL功能实现最高每秒20万日志的发送,同时可以配合requestlog或irules方式可以读取到所有应用层数据,方案网络故障排除及系统层分析,为大数据平台提供数据支撑。
安全防护能力:F5本身提供了大量的安全功能,包括SSL、访问控制、应用防护等。开源方案只提供了基本的应用分发功能,没有安全功能扩展。
该解决方案包含2个组件,VE(Virtual Edition)和CC(Container Connector)。VE是F5LTM的软件化商业产品,可以安装在虚拟机或者物理机上,其功能与硬件设备完全一致。CC是F5解决方案的一个关键组件,为用户提供了企业级支撑,同时也是开源产品,用户可以根据自己的需要对CC进行功能扩展。它以容器的形式部署在Kubernetes集群中,通过读取Kubernetes API获取集群内的服务资源并将其转化为VE上的配置。管理员可以为每一个租户部署一组CC,每组CC独立控制VE上的一个对象配置隔离区域(partition),该partition下的资源完全由该组CC独立控制。该方案中,负载均衡策略的定义可以由多种方式实现,可以使用Ingress,也可以使用ConfigMap。
民生银行经过前期技术预研,选择F5 CC+VE方案,利用CC与Kubernetes进行API交互,实现与容器平台的联动,满足容器应用的灵活性需求;配置上采用ConfigMap进行负载均衡策略下发,实现在Kubernetes层面进行F5策略配置工作;网络架构上采用VE直接对集群中的pod进行负载分发,减少网络层次,提升负载均衡性能;同时,通过将Kubernetes的namespace与VE的partition映射,实现不同容器租户负载均衡资源的隔离。
1网络部署方案
目前,民生银行Kubernetes环境采用的是Flannel VXLAN网络模型,容器网络由Flannel负责分配与管理,不同节点上的容器间互访由Flannel自动化管理各个节点上的路由表、ARP表及FDB表。本方案中,F5 VE是以虚拟Kubernetes node节点加入到集群,需要配置VXLAN网络信息,这些网络信息会被Flannel同步到各个节点。同时,CC从Flannel获得其它容器的网络信息后传递给VE,VE上生成相应的表项后,实现与容器之间直接通信。
2 服务发布方案
在服务发布上,通过部署YAML文件方式进行发布,操作均在Kubernetes管理平台上进行,可采取的形式如下:
基于VE资源属性的ConfigMap方式进行发布,此发布模式下,根据VE定义的ConfigMap资源属性进行发布,VSIP,健康检查,负载均衡算法等均在该ConfigMap中定义。ConfigMap方式支持以下类型的发布:
o 像传统F5部署一样部署所有高级应用交付特性(iApp)
o 发布L4类型业务
o 发布L7类型业务
o 应用WAF安全特性
基于Ingress的发布,实现基于L7策略的发布。
发布UnattachedPool,此场景主要用于有自动化分配VS地址需求的场景。
同时,对于上述网络模型下,也支持通过VE FQDN技术实现headless服务的自动化发现,通过在Kubernetes内发布标准的headless服务,容许VE访问Kubernetes内置的DNS服务,即可实现通过域名自动化发现相关endpoints到VE中,实现更加灵活的自定义发布:
3 资源隔离方案
在Kubernetes内不同的namespace(以下简称NS)隔离不同的资源对象时,管理员为每个NS创建一组 CC,监视NS内的资源对象,并将其发布到同一个VE的不同partition上或者不同的VE上,以达到资源隔离的目的。
对于业务访问量相对较小的环境,可以选择复用VE,不同NS对应不同的partition,提高资源的利用效率。随着业务规模的扩大,可以采用不同NS对应不同的VE的方案进行扩容。
实际应用效果与收益
本节以某项目为例,介绍本方案在落地场景中探索使用的应用效果和收益。该项目为典型三层架构体系,在Web区和App区均部署了高可用的F5 VE用于服务发布。实施效果与收益如下:
1 实现F5设备动态感知容器服务能力
通过部署在Kubernetes租户内的F5 CC动态感知容器服务的变化,解析服务创建以及销毁事件,动态更新F5 VE设备,实现服务自动发现,动态感知能力。以此来支持应用弹性伸缩能力。
2 实现F5到pod的负载转发能力
通过F5 VE和Kubernetes集群建立的VXLAN网络,实现了VE服务直接访问pod的能力,如下图:
通过实现以上功能,减少了NodePort的服务器端口独占以及端口不足的问题,同时减少了NodePort方式下对kube-proxy的依赖。
3 实现负载均衡多租户能力
在F5 VE方案中通过伪host定义、CC定义、F5 VE下发策略等配置明确定义了F5 VE租户(partition)和Kubernetes租户(namespace)之间的一对一关系,实现了F5 VE和Kubernetes的多租户联动支持能力。为F5 VE设备在容器环境下租户化运营提供了基础。
如下图所示,在实际应用场景下,Kubernetes租户是scfp,F5 VE partition是scfp_partition。
所有Kubernetes的scfp租户下发布的服务,对应在F5 VE上的转发策略,仅在scfp_partition下可见。
4 实现F5设备在容器环境下的自服务能力
F5 VE在实现租户安全的前提下,实现了通过Kubernetes原生语义ConfigMap定义F5 VE负载均衡策略,通过Kubernetes的命令行实现F5设备规则的配置管理能力,实现了在租户内F5资源的自服务能力。
5 丰富容器环境下负载均衡算法
通过引入F5,丰富了容器环境中的负载均衡算法。在ConfigMap中的balance字段可以实现负载均衡转发算法的选择,默认是round-robin,除此之外还有18种算法。在实际应用中,我们采用的是least-connections-member算法,如下图所示:
综上所述,我们对Kubernetes的容器管理能力和F5的负载转发能力进行强强联合,在实际应用中充分利用F5 VE、F5 CC在应用系统交付、配置自动化、应用系统弹性伸缩等方面的特性,取得了显著效果。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
端产品多版本共存服务器端兼容的问题
今天偶然跟同事聊天,说到pc端产品升级的问题,由于我们是服务器端,理论上我们需要兼容不同版本的产品。 细想了下,这个场景是一定存在的,cs架构的产品比bs架构的产品一定要处理这种问题,在一定程度上的版本兼容之外,才能考虑强制升级的问题。 服务器端需要做的是,提供不同版本的api接口,实际上需要提供不同版本的数据存储,以及不同版本的业务逻辑处理。 在网上查了下,没有发现成型的方案,估计有成型的方案也不会放到网上,但是觉得市面上的端产品这么多,肯定有方案。 自己画了一个,觉得可能可行吧,一个初步的没有经过实践的构思,留作以后补充吧。 本文转自 斯然在天边 51CTO博客,原文链接:http://blog.51cto.com/13172906/1967541,如需转载请自行联系原作者
- 下一篇
企业数据保护:全面巩固优势,灵活创造价值
如今,人们越来越痴迷于数据,确保数据安全成为了企业必须承担的责任。确保数据安全的应用、海量存储、备份流程、培训等工作,占据了IT部门的大部分精力,导致他们几乎没有时间来梳理数据,评估需要通过什么方式备份什么内容。对于许多企业而言,默认的方法就是简单地备份所有数据。 然而,随着数据的来源不断增多,人们开始思考如何将数据保护的作用从确保业务正常运转转变为革新现有业务模式,以及如何提高数据保护的效率和效果。 信息是企业最重要的资产,但是保护这些信息却代价不菲,且流程十分复杂。我们注意到,企业每花费 1 美元保存客户信息,就必须花费至少4-6美元去保护它。对于企业和机构而言,数据保护是一种昂贵,但又不可或缺的保障,防止数据丢失可以有效避免品牌声誉受损或卷入诉讼纠纷。 过去五年中,科技进步催生了众多企业必备的解决方案,包括: 服务器 虚拟化 、物联网 、数据分析和 软件 定义数据中心;而每一种解决方案都带来了新的备份需求和挑战。最终,大多数企业至少拥有三种备份解决方案以满足数据保护需求。 企业并没有将更多预算用于IT部门,而数据处理和分析成本却水涨船高。因此,许多企业希望能够降低数据保护成本的同...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7编译安装Cmake3.16.3,解决mysql等软件编译问题
- Hadoop3单机部署,实现最简伪集群
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS7安装Docker,走上虚拟化容器引擎之路
- SpringBoot2全家桶,快速入门学习开发网站教程
- SpringBoot2初体验,简单认识spring boot2并且搭建基础工程
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- CentOS8安装MyCat,轻松搞定数据库的读写分离、垂直分库、水平分库