[1] Comentário enviado por
tucs em 02/05/2005 - 07:34h:
LVS é um Linux Virtual Server, onde ele atua como um DIRECIONADOR ou seja imagine que se tenha 3 maquinas em um LVS e mais um DIRECIONADOR, quando um cliente pede uma requisição o DIRECIONADOR manda para uma maquina, e quando outro pedir ele manda para a segunda maquina, e assim por diante.
Existe o Cluster de HA (Alta Disponibilidade), geralmente usado o HeartBeat + DRBD, ai sim, quando uma maquina parar a outra assume o serviço, no Caso do LVS, se o Direcionador parar acabo o esquema de LVS.
O correto seria usar LVS com HA no DIRECIONADOR.
Pelo menos foi assim que montei em uma Provedora.
Abraços.
Eduardo Assis.
[3] Comentário enviado por
agk em 06/05/2005 - 18:24h:
Parabéns pelo artigo, LVS realmente é um conceito muito bom, para balancear os acessos e distribuir nos servidores do LVS. O problema consiste no distribuidor (balancer), que se entrar em pane para todo o serviço, mas isso também pode ser contornado usando-se um balancer de backup, onde ele assumiria o lugar do principal se este parasse de responder, deixando assim tempo para o administrador resolver o problema sem que os usuários perdessem o acesso.
[5] Comentário enviado por
osvalcde em 14/08/2007 - 20:05h:
oi..
to trabalhando nom cluster trabanho da facultade..
to utilizando o manual de Ultramonkey
http://www.ultramonkey.org/3/topologies/hc-ha-lb-e...
eu fiz todo perfeito, mais aparece um problema de conexao.. disculpa o meu portugueis
meu cluster consiste em 4 maquinas 2 Diretores un Ativo o outro backup e 2 Servidores Reais.. to trabalhando en Debian 3.1 com kernel 2.6
tris is my problem, only 1 conect
# ipvsadm -ln
IP Virtual Server version 1.2.0 (size=4096)
Prot LocalAddress:Port Scheduler Flags
-> RemoteAddress:Port Forward Weight ActiveConn InActConn
TCP 172.18.200.33:21 rr
-> 172.18.200.31:21 Route 0 0 0
-> 172.18.200.32:21 Route 0 0 0
-> 127.0.0.1:21 Local 1 0 0
TCP 172.18.200.33:80 rr
-> 172.18.200.32:80 Route 0 0 0
-> 172.18.200.31:80 Route 1 0 0
TCP 172.18.200.33:443 rr
-> 172.18.200.32:443 Route 0 0 0
-> 172.18.200.31:443 Route 0 0 0
-> 127.0.0.1:443 Local 1 0 0
-----------------------------------------------------------------------------------------------------------
# ipvsadm -lcn
IPVS connection entries
pro expire state source virtual destination
TCP 00:40 SYN_RECV 172.18.200.39:2841 172.18.200.33:21 127.0.0.1:21
TCP 00:43 SYN_RECV 172.18.200.39:2852 172.18.200.33:21 127.0.0.1:21
TCP 00:46 SYN_RECV 172.18.200.39:2861 172.18.200.33:21 127.0.0.1:21
TCP 00:44 SYN_RECV 172.18.200.39:2855 172.18.200.33:21 127.0.0.1:21
TCP 00:47 SYN_RECV 172.18.200.39:2862 172.18.200.33:443 127.0.0.1:443
TCP 00:39 SYN_RECV 172.18.200.39:2838 172.18.200.33:21 127.0.0.1:21
TCP 00:38 SYN_RECV 172.18.200.39:2834 172.18.200.33:21 127.0.0.1:21
TCP 00:45 SYN_RECV 172.18.200.39:2858 172.18.200.33:21 127.0.0.1:21
TCP 00:42 SYN_RECV 172.18.200.39:2849 172.18.200.33:21 127.0.0.1:21
TCP 00:31 SYN_RECV 172.18.200.39:2828 172.18.200.33:21 127.0.0.1:21
TCP 00:41 SYN_RECV 172.18.200.39:2846 172.18.200.33:21 127.0.0.1:21
por favor algen pode me dar uma mao.. osvalcde@gmail.com
[6] Comentário enviado por
leoreis em 23/05/2009 - 17:01h:
Prezados,
a nossa aplicação web tem uma característica de que não apenas uma conexão https é estabelecida, durante o uso da mesma, outras conexões são estabelecidas.
Dúvida: quando chegar a segunda conexao https (do mesmo usuario), o LVS irá redirecionar a conexão para o tomcat correto? Imagina, tenho 3 tomcats, todas as requisicoes de um determinado usuario devem ir para o mesmo tomcat, pois se for para um tomcat errado, o usuário não estar logado (já estamos trabalhando em uma solucao para a sessão do usuário estar disponivel em todos os nós...).
Pode me ajudar? O LVS garante o envio para o tomcat correto?
Leo
Quem puder me ajudar , segue-se me email: leo@mundociencia.com.br