解析基于应用的负载均衡软件:(2)
2009-05-21 21:59
260 查看
早期的均衡问题解决方案是在应用服务器的操作系统或应用软件中直接部署均衡能力,但是大多数都涉及到基本的网络欺骗。 例如(让集群中的所有服务器监听除自身ip地址之外的" 集群ip"。)用户试图连接服务时,用户会连接到集群ip,而不是服务器的物理ip。集群中最先对连接请求做出响应的服务器将把用户重定向到物理的ip地址(可以是自己的ip地址,也可以是集群中的另一个),服务会话开始启 首先这个方案的主要优点是:应用开发人员可以使用大量信息确定客户端连接哪个物理ip地址;举例(集群中的每台服务器可以维护每个集群成员正在服务的会话数量,并将请求定向到利用率最低的服务器); 最开始该解决方案的扩展性很明显:但是随着集群成员服务器被添加到集群中的数量越多,集群成员之间的网络流量就会呈指数级增长。一般集群扩展到10台以后,流量就开始影响最终用户的业务流量以及服务器本身的利用率。 该方案的可用性也显著提高:由于集群成员始终互相通信,而且应用开发人员可以使用综合的应用知识了解服务器在何时正确的运行,因此几乎不会出现用户到达一个无法处理请求的服务器的情况;然而必须指出的是,对高可用性的另一个负面影响是可靠性。系统中分配流量的许多网络欺骗方法非常复杂,要求大量的网络级监控工作;相应的,这些方法经常会遇到影响整个应用以及应用网络上所有流量的问题。
该方案也提高了可预测性:对应用的深入了解,开发人员能够根据应用的真正健康状态更好的开发负载均衡算法,而不是根据连接。
最后给予应用的专用负载均衡软件还有一个缺点:过分的依赖应用供应商提供开发维护,这样的问题是并非所有应用都提供负载均衡或集群技术,而且提供这些技术的应用无法与其他应用提供商良好配合。尽管许多企业制作了不依赖供应商的操作系统级别的负载=均衡软件,但他们都遭遇了同样的扩展性问题!而且由于缺乏与应用的密切集成,这些软件的“解决方案”也遇到了高可用性的挑战。本文出自 “makeguan.blog.163.com” 博客,请务必保留此出处http://makeguan.blog.51cto.com/307328/159885
该方案也提高了可预测性:对应用的深入了解,开发人员能够根据应用的真正健康状态更好的开发负载均衡算法,而不是根据连接。
最后给予应用的专用负载均衡软件还有一个缺点:过分的依赖应用供应商提供开发维护,这样的问题是并非所有应用都提供负载均衡或集群技术,而且提供这些技术的应用无法与其他应用提供商良好配合。尽管许多企业制作了不依赖供应商的操作系统级别的负载=均衡软件,但他们都遭遇了同样的扩展性问题!而且由于缺乏与应用的密切集成,这些软件的“解决方案”也遇到了高可用性的挑战。本文出自 “makeguan.blog.163.com” 博客,请务必保留此出处http://makeguan.blog.51cto.com/307328/159885
相关文章推荐
- Tomcat下基于HTTPS协议应用的负载均衡配置问题
- 基于RYU应用开发之负载均衡(源码开放)
- 基于RYU应用开发之负载均衡(源码开放)
- 应用负载均衡基本原理解析(一)
- 应用负载均衡基本原理解析(二)
- PHP 多维数组的排序----服务器负载均衡的应用
- 负载均衡之---应用请求路由模块的使用(ARR)(九)[在应用程序服务器上为HostNameMemory亲和提供程序配置WMI服务]
- 【转】关于高可用负载均衡的探索-基于Rancher和Traefic
- SDN第五次上机作业--基于组表的简单负载均衡
- 利用负载均衡优化和加速HTTP应用
- 请教高手!!!关于基于web service的云端应用软件开发的问题(初步)
- Tomcat高级部分-使用特定模块和软件反向代理请求到后端tomcat实现负载均衡和session保持
- web应用的负载均衡、集群、高可用(HA)解决方案
- lvs+keepalived实现负载均衡,基于centos6.5
- 利用负载均衡优化和加速HTTP应用
- 基于DPI(深度报文解析)的应用识别
- 基于简单sql语句的sql解析原理及在大数据中的应用
- 应用 Rational 工具简化基于 J2EE 的项目第 8 部分 :测试软件
- 使用nginx sticky实现基于cookie的负载均衡【转】
- 负载均衡之---应用请求路由模块的使用(ARR)(六)[使用ARR管理试点方案(涉及到了A/B Testing)]