负载均衡起步

首先声明：我对负载均衡基本上一无所知 


我看了F5的一些资料，好像负载均衡器的主要原理是 按流量把用户请求分摊到各服务器上 
这初看是没有问题的，但是考虑到“session”，这样能行吗？ 

比如说，现有A,B两台服务器被均衡，某用户的第一次WEB请求是登录网站，假设均衡器将他登录到了A服务器上，A服务器上就会保留他的session；然后，他要求查看“个人信息”，均衡器将他的请求转到了B服务器，而B上没有他的session，B就会拒绝服务，对不对？ 


类似的问题还有上传下载文件，如果文件上传到了A服务器上，再到B服务器上去下载，能下载到吗？ 


我真的啥也不懂。请大家教教我 

 

f5做负载均衡有很多种算法可以选择，你说的那种很少用，一般都是把同一个用户的请求都转向同一个节点，生产环境中f5用来保存session的话服务器的压力就大了点，当然没￥就算了。有讲究的中间会加一组缓存服务器。服务器都是做成集群，集群提供session的复制，这样在一台服务器死了后，f5就把该服务器的用户转到别的节点上。

 

 

谢谢，受教了。 

其实也就是说，如果采用了集群，系统的设计还是要受一些影响的，对不对？ 比如 我上面说的文件上传下载的例子， 文件只能存放在一个公共的地方，而不能和WEB服务器放在同一台机上

 

 

假设现在有三台机器，机器A专门做网络层的负载均衡，负责网络包的分发，机器B和C是中间件应用。 

客户甲现在请求应用，做一个page flow类似的操作，前三次操作刚巧被机器A全部分发到了机器C上，产生的session也都在机器C的JVM中，第四次操作被机器A转发到了机器B上，机器B的JVM中没有客户甲的session，这种情况下，请求就会失败。 

你所说的JVM可以跨机器、跨IP，那是WebLogic、OracleAS提供的所谓的集群、Session复制。而实际项目里session复制是比较恶心的，尤其是session里东西太多的时候，多机之间传递session对象的效率一点都不高。况且，如果采用叻产品级的集群，使用session复制，那你提出的这个所谓的网络层负载均衡根本也就是个无所谓的东西，因为后面的中间件已经被集群为相当于一个JVM，你网络层的负载均衡显然没有中间件产品提供的负载均衡来得有效。 

如果我没理解错，大家讨论的是在不使用产品集群、session复制的情况下，应该如何避免使用session。还是那句话，要是session能够在容器之间同步的非常理想，那整个帖子都没必要讨论叻，而且你那个负载均衡，更没意义，提供叻session同步的容器会不提供更高级的应用层的负载均衡么？

 

 

robin的见解：

所谓硬件负载均衡器其实就是一台功能简化的电脑，上面运行某种操作系统，在网络协议处理上面进行特殊的增强(路由器实际上也是这样的)。他的作用就是放在多个服务器的前端，接受外面的访问请求，然后根据某些特定的策略，分发到不同的服务器上。 

LVS原理是一样的，只不过是在各个参与负载均衡的服务器上面安装软件，而不是单独弄一台机器做这个事情(成本大幅度降低，同时也可以避免单点故障，不过效率要降低很多)。 

总之硬件也好，操作系统级别的负载均衡也好，实际上都是在网络协议层做请求的分发。它做的工作很简单，接受请求，根据策略进行分发。此外，它还承担故障切换的任务，当某个节点宕机以后，会将分发到这个节点的请求分发到其他节点(会定期进行心跳检测，确定节点工作与否)。当节点恢复正常以后，还可以继续把请求再分发过来。 

这种负载均衡方案是针对网络协议级别的，它至多实现对端口和协议的控制，但是它对服务器上面运行了什么程序，有什么数据一无所知。 

应用服务器的群集同样可以实现上述的功能，即： 
1、负载均衡 
2、故障切换和恢复 

只不过可靠性和效率要比硬件负载均衡器低很多罢了。 

前面提到硬件负载均衡器并不知道某个节点的应用服务器Session有什么数据，因此某用户登陆到节点A以后，当节点A宕机，负载均衡器将请求分发到节点B。但是节点B没有用户的Session，因此用户必须重新登陆！对于那些把pageflow状态保存在HttpSession的应用来说，意味着整个页面流程都丢失了。 

应用服务器群集除了上述两点，还具备 
3、HttpSession的复制和粘着功能 
即一旦某用户在节点A登陆，那么该用户后续请求会一直分发到A节点(有效降低了Session复制的频率)，除非节点A宕机，则请求分发到B节点，即使A节点恢复以后，由于粘着性，请求仍然交给B节点，除非B节点宕机。 

从某种程度上来说，硬件负载均衡和应用服务器群集功能上是有某种冲突的。当你把他们都用上的时候，例如硬件负载均衡根据策略将请求分发到B节点，但是由于应用服务器群集的session粘着性，B节点的应用服务器即使拿到了该请求，它也不会自己处理，而是转发给A节点的应用服务器。 

不过在实际的应用中，考虑到各种各样的情况，往往会硬件负载均衡和应用服务器群集都用上。硬件负载均衡器的作用不仅仅限于负载的均衡，有时候根据需要，可能会有更加复杂的控制策略，例如不同省份的请求分发给不同的服务器去处理(可能不同省份的应用处理逻辑不一样)，例如OLAP型请求分发给某节点，OLTP型应用分发给某节点等等，不同的业务分发到不同的节点等等。 

因此整个部署拓扑会变成一个混合方案：前端硬件负载均衡器根据各种需要指定策略分发，后端每个节点上面做应用服务器垂直群集。节点之间故障切换的时候是没有Session复制的，这个时候，要求用户重新登陆一次是可以接受的(前提是不要在Session里面放其他逻辑，像查询结果集，pageflow等等)。至于做应用服务器垂直群集的作用往往是为了实现不停机情况下的应用重新发布升级等等。

 

 

主要还要看你跑的是什么任务，是WEB还是数据库 

什么系统也没说，做什么服务器也没说…… 
用SERVER 2003自带的网络负载均衡管理器建集群吧，在两台服务器上分别建立，局域网里访问，不知道是WEB服务器还是文件服务器，还是数据库服务器？

如果是用微软的负载均衡是不需要特别的设备。
在每个节点上均安装windows server2003 x64 or x86 ENT,并安装SP1及其他补丁。
设置每个节点的网络连接，public的IP必须与AD同属一个网段(比如192.168.16.0/28)，DNS指向AD；private的IP必须与其他节点的private的IP同属一个网段（与不同网段比如：10.10.10.0/28），DNS不用设定，并禁用private中WINS选项中NetBIOS上的TCP/IP和DNS注册。

F5负载均衡技术
F5 BIG-IP LTM（本地流量管理器）是一台对流量和内容进行管理分配的设备。它提供12种灵活的算法将数据流有效地转发到它所连接的服务器
群。而面对用户，只是一台虚拟服务器。用户此时只需访问定义于BIG-IP LTM上的一台服务器，即虚拟服务器（Virtual Server）。但他们的
数据流却被BIG-IP灵活地均衡到所有的物理服务器。
BIG-IP LTM可以通过多种负载均衡算法对流量进行分配，这些算法包括：
轮询（RoundRobin）
比率（Ratio）
优先权（Priority）
最少的连接方式（LeastConnection）
最快模式（Fastest）
观察模式（Observed）
预测模式（Predictive）
动态性能分配（DynamicRatio-APM）
动态服务器补充（DynamicServerAct）
服务质量（QoS）
服务类型（ToS）
规则模式