这里是LVS集群项目的中文社区。欢迎大家在这里讨论和交流LVS集群的安装、使用、维护与开发,以及相关技术,帮助完善LVS的中文文档。也欢迎您在这里建立您的博客!
当LinuxDirector转发socket给RealServer之后,这个socket长连接,是保持在LinuxDirector?还是RealServer?还是二者都会保持呢? 如果socket连接数在10万,那LB能承受住吗?
存在一个需求,不仅客户端主动向服务器发送消息,也存在这个场景,就是服务器定时向指定的客户端发送通知消息,不知如何解决,目前思路是通过固定LVS转发端口来实现,但是不知道如何固定,请教高手如何指定固定端口转发,或者其它能够解决服务器主动向指定客户端发送消息的办法
目前手头有个应用,是工作在C/S模式下,用户通过客户端连接服务端,使用SSL进行通道加密。现在想做横向扩展,多加几个节点,在前面搭建LVS做负载均衡。目前客户端直接使用TCP连接已经可以通过LVS做负载均衡,但如果加上SSL通道加密的功能,客户端就不能正确连接服务端获取响应了,比如登录等。在网上查了,发现有关SSL的基本都是关于web应用的,有的说持久性连接可能对SSL连接有帮助,但也没具体说怎么配置。想问LVS是否支持这种场景的SSL连接,如果支持,应该怎么配置?谢谢!
一台LVS主机双网卡信息如下: eth0: 192.168.1.30 (外网,能跟windows主机通信并能上外网) eth1: 192.168.10.31 (nat网络,不能跟windows主机通信,但可以跟同网段的Linux虚拟机通信)
一台Real Server 1 Linux虚拟机单网卡信息如下: eth0: 192.168.10.32 gateway: 192.168.10.31 lo: 192.168.1.30
一台Real Server 2 Linux虚拟机单网卡信息如下: eth0: 192.168.10.33 gateway: 192.168.10.31 lo: 192.168.1.30
在LVS主机里的浏览器里输入http://192.168.10.32和http://192.168.10.33都能访问到Real Server1和Real Server2的Apache Server。 LVS上的操作都在截图里,我目前netstat -an|grep 80不能被监听,在浏览器里输入http://192.168.1.30不能访问,请高手指点迷经。
服务架构:(Vmware) Client 192.168.88.1 D ens33:192.168.88.134 ens36:192.168.66.128 rs1 ens36:192.168.66.130 [default route 192.168.66.132] Gateway eth1 :192.168.88.131 eth2 :192.168.66.132 [linux]
目前情况是我client发出TCP握手后,rs1接到请求转发都GATEWAY后 GATEWAY无法跨网段转发 其中rs1是可以正常ping通client的。麻烦众位大神给看看
请问在两台主机搭建lvs+keepalived,两台机器同时互为主备,同时也是realserver后端。我现在使用的是DR模式,通过vip:端口的方式访问,现在80端口能实现负载均衡,我换成其他端口就不行了,我现在需要通过vip访问不同端口,能够均衡的访问到两台后端上的不同端口,请问需要怎么做?
希望固定将源IP的报文一直转给同一个服务器(不考虑服务器超载或连接异常),即使重新启动后也是这样。 源地址散列调度获取服务器的HASHKEY算法是固定的,这样是否只要服务器节点个数不增加,源IP每次都是转给固定一个服务器节点?
//LVS 源地址散列HASH算法 static inline unsigned hashkey(unsigned int dest_ip) { return (dest_ip* 2654435761UL) & HASH_TAB_MASK; } 其中,2654435761UL是2到2^32 (4294967296)间接近于黄金分割的素数, (sqrt(5) - 1) / 2 = 0.618033989
rt,官网最新的版本是1.26,但是linux发行版(ArchLinux)软件库里面的版本是1.28,到底哪个才是最新的啊?
想动态完成lvs中权重设置,实现负载均衡。
用jmeter,对vip进行get文件时,会出现Response message: java.net.ConnectException: Connection refused: connect。 对真实的ftp服务器,get文件时能成功,请问问题出在哪里
There are currently 0 users online.