注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

itoedr的it学苑

记录从IT文盲学到专家的历程

 
 
 

日志

 
 

关于信息系统的 负载均衡的层次结构(收集)  

2016-03-31 15:13:37|  分类: 容灾备份 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |
随着Maglev这个由google开发开源负载均衡系统,负载均衡再次让人们关注起来,随着云系统的普及,满以为云可以帮且完成所有事务,实际上谁来负责我们云系统的负载均衡呢?一个运行系统的架构师,也许真还少不了关注你的负载均衡。

硬负载

所谓「硬负载」就是采用硬件设备来提供负载均衡。

在七、八年前那时我在做 Java 的企业软件开发,开发出来的企业级 Java 应用程序就部署在像 Weblogic 之类的应用容器中。而这类应用容器软件又跑在 Unix的小型机上。把硬件和软件一体打包作为企业应用解决方案卖给客户。这类应用部署的方案十分简单,层级也比较浅。为了保证可靠性,使用两套小型机上各部署一个 Weblogic Server,在应用服务前面使用像 F5 之类的硬件负载均衡器,如下图所示。

LB 负载均衡的层次结构

由于小型机和前面的 F5 负载均衡硬件都比较贵,所以出于可靠性、可维护性和成本的综合考虑,一般应用部署两套跑在两台小型机上,在前面共享一个 F5 做负载均衡。而一般 F5 和小型机这类硬件设备都至少是 5 个 9 的可靠性保障,所以整体的系统可靠性基本有保障。

进入互联网时代后,应用开发拥抱开源,部署使用更廉价的 PC Server 和免费开源的应用容器。负载均衡也逐步从硬负载向软负载变迁,由于互联网应用的海量特性和部署规模的急剧膨胀,前端负载均衡也开始变得丰富起来。

软负载

进入互联网公司后,我们刚开始开发应用时,业务规模小用户量还不大,机器数量也少(<10)。所以一开始的负载均衡的结构也是很简单的,类似硬负载只是把硬件换成了免费的开源软件并跑在可用性是有 3 个 9 的廉价 PC Server 上。

LB 负载均衡的层次结构

前面一个 LVS 后面跟着几个应用服务,后来为了方便做按域名的分流和适配切流量上线,中间又加了一层 Nginx。

LB 负载均衡的层次结构

这样就变成了两层软负载结构了,LVS 负责 4 层,Nginx 负责 7 层。 但 Nginx 只负责了单机内多实例的负载均衡,这里主要是因为当时PC Server 是物理机,CPU 16/32 core,内存 32/64G 不等,为了更充分的利用资源,一台物理机上都部署了多个应用服务实例,而考虑到 Nginx 工作在 7 层的开销远高于 LVS/DR 模式,所以一般在一个 Nginx 后面挂的实例数也不会超过 10 个。

但随着业务发展和用户流量上升,机器规模也在不断扩张,导致一个网段内的 IP 都不够用了,这套负载结构又遇到了横向扩展的瓶颈,因为 LVS/DR 模式下跨不了网段。所以后来又在 LVS 和 Nginx 之间加了一层 HAProxy,负载结构就变成了下面这样。

LB 负载均衡的层次结构

其实加了 HAProxy 之后,它也是工作在 7 层,这样 Nginx 这层看起来就不是很有必要。但三层的负载结构能支撑更大规模的集群,而原本在 Nginx 层做了一套方便研发切流量上线的运维管理系统,所以牺牲一点性能换取现在的可维护性和将来扩展性,Nginx 这层就一直保留下来了。而且 Nginx 相比 HAProxy 不是纯粹的负载均衡器,它还能提供 cache 功能,对于某些 HTTP 请求实际只走到 Nginx 这层就可以通过缓存命中而返回。

DNS负载

随着业务发展,公司开始了多个 IDC 的建设,考虑到 IDC 级别的容灾,集群开始部署到多个 IDC。跨 IDC 的负载均衡方案可以简单通过 DNS 轮询来实现,但可控性不好。所以我们没有采用这种,而是采用一主加多子域名的方式来基于业务场景实现动态域名调度和负载。主域名下实际是一个动态流量调度器,跨多个 IDC 部署,对于 HTTP 请求基于重定向方式跳子域名,对于 TCP 方式每次建立长连接前请求分配实际连接的子域名,如下图所示。

LB 负载均衡的层次结构

CDN负载

最后再加上互联网应用必不可少的 CDN 将静态资源请求的负载分流,那么整个负载的层次结构就完整了。

SSL 带来的负载结构变化

随 着互联网的普及,安全问题益发严重,原本早期只有银行网银等使用 HTTPS 方式访问,现在电商类网站也开始启用全站 HTTPS 了。引入 SSL 后对负载结构带来了什么影响么?SSL 属于应用层的协议,所以只能在 7 层上来做,而 HAProxy 也是支持 SSL 协议的,所以一种方式是只需简单的让 HAProxy 开启 SSL 支持完成对内解密对外加密的处理。

但 HAProxy 的作者不太赞同这种方案,因为引入 SSL 处理是有额外的性能开销的。那么在承担确定流量的情况下,假设原本需要 M 台 HAProxy,在开启了 SSL 后可能需要 M + N 台 HAProxy。随着流量增长,这种方式的横向扩展成本较高(毕竟 SSL 证书按服务器数量来收费的)。他给出的解决方案是再独立一层 SSL 代理缓存层,像下面这样。

LB 负载均衡的层次结构

L4 和 L7 之间独立的 SSL 代理缓存层只负责 SSL 协议的处理,把 HTTPS 转换成 HTTP,并检查本地缓存是否命中。若未命中再转发请求到后端的 L7 层应用负载均衡层。这样的好处是每个层次都可以根据流量来独立伸缩,而且 SSL 层显然可以跨多个应用共享,更节省成本。如果按这个思路来重新调整我们前面的负载均衡结构层次,将会演变成下面这样。

LB 负载均衡的层次结构

其实,这时我觉得应用前面的那层 Nginx 可能就显得多余了点,不是必需的。但如果现实这么演进下来很可能就会有这么一层冗余的东西存在很长一段时间,这就是理想和现实之间的差距吧。

总结

好 了,本文到此为止。作为一名后台开发我其实对上面提及的各类开源软件如何配置、调优和管理并不熟悉,这属于运维开发的问题域范畴。但这并不妨碍我去了解我 所开发的应用所处的整个环境是怎样的,多了解些你工作领域范围边界外的 What 和 Why,有时也能帮助我们更好的设计和解决自身问题域内的问题,别为自己设限而最终画地为牢。

本来以为负载均衡这个古老的课题已经定型了,在写本文时又看到新闻,在近日举办的第十三届网络系统设计与实现 USENIX 研讨会上,来自 Google 的工程师又分享了其自研的 Maglev 负载均衡器。

*************************************
新的开源负载均衡系统Maglev
************************************

Google Maglev:基于商用服务器的负载均衡器

        在近日举办的第十三届网络系统设计与实现USENIX研讨会(NSDI '16)上, 来自谷歌,加州大学洛杉矶分校SpaceX公司的工程师们分享了Maglev:快速、可靠的软件网络负载均衡器(PDF)。Maglev是谷歌的网络负载均衡器。

不同于专用的硬件负载均衡设备,Maglev是运行在商用服务器上的软件解决方案。Maglev运行在普通的服务器上,在需求增长的时候通过将更多 的服务器添加进来,为流量高峰提供足够的容量,而不是提前获取特定硬件。Maglev是谷歌为自己的数据中心研发的,并已于2008开始用于生产环境。

谷歌服务器以集群的方式运行在世界各地的数据中心。每个集群都有一个负载均衡器构成多设备放置在路由器和提供服务的服务器之间。专用负载均衡器通常 以active-passive模式部署提供1+1冗余,使其中一个闲置,造成容量浪费。而且他们局限于他们的容量,很难或不可能重构。谷歌已经决定使用 一种配置提供N + 1冗余,为他们的软件和商用服务器提供了更好的可扩展性和灵活性,如下图所示。

关于信息系统的 负载均衡的层次结构(收集) - itoedr - itoedr的it学苑

在性能方面,单节点Maglev服务器可以“用很小的数据包使10Gbps链接达到饱和。Maglev也包含了一致性哈希算法和连接跟踪功能,以减少面向连接协议的突发故障和失败的负面影响。”。Maglev被Google的云计算平台使用,安装后不需要预热5秒内就能应付每秒100万次请求。谷歌的性能基准测试中,Maglev实例运行在一个8核CPU下,网络吞吐率上限为12M PPS(数据包每秒)。如果Maglev使用Linux内核网络堆栈则速度会慢下来,吞吐率小于4M PPS。

演讲文中详细介绍了如何通过Maglev处理请求,如何处理虚拟IP地址以及该请求是如何基于等价路由(ECMP)算法,哈希法和其他算法定向到一个服务端点的。

  评论这张
 
阅读(97)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2018