Vamos lá:
Em 14/11/06, Marcello Costa<[EMAIL PROTECTED]> escreveu:
> O *FOCO* do CARP é prover redundancia de IP , fazer isso para webserver
> *na minha modesta opinião* é guambiarra
Falou tudo !
Camada de rede é diferente da camada de aplicação.
Você afirma que o CARP trabalha na camada de rede (IP). Ora, se carp
provê conectvidade e redunância numa camada mais baixa e seguindo o
modelo OSI de interoperabilidade uma camada apenas entrega o payload
pra outra, como se pode afirmar que usar carp pra webserver é
gambiarra, sendo que o HTTP é na camada de aplicação ?
Sendo assim, firewalls são gambiarras rodando em nível de kernel !
Acho que você está confundindo CARP com PFSYNC que são duas coisas
complementares, mas completamente distintas.
A função do carp é prover um endereço redundância de hosts. Ponto.
Pfsync é quem faz o sincronismo da tabela de estado de conexões do
firewall. O pfsync pode perfeitamente funcionar semo carp, embora sem
muita utilidade, e vice versa.
Veja mina situação
|-----SERVER1-----
|
CLI--------->1.2.3.4 | VARIOS APACHES
AQUI ATRAS
|
|-----SERVER2-----
O endereço 1.2.3.4 é o endereço virtual (carp) do SERVER1 e do SERVER2
(usando pound). Existe uma entrada no DNS que aponta pra esse
endereço, ou seja, www.meuservidorweb.com.br aponta para 1.2.3.4.
Esses dois hosts tem, além da interface carp, outro endereço real,
pois o carp precisa saber pra quem realmente passar o pedido para que
ele seja processado.
Independentemente se ele seja um pocote com um cabeçalho HTTP ou uma
requisição RPC. Pra ele o que importa é saber quem é o carp device
master e passar o pedido pra ele. O que o master vai fazer, não
interessa pro carp.
> simples
>
> coloque dois servers apache rodando , sincronize com que quiser , poder
> nfs , rsync, etc ...
>
> basta colocar no dns
>
> 192.168.0.10 -> web01.dominio
>
>
> 192.168.0.11 -> web02.dominio
>
> dominio alias -> web01,web02
>
> não precisou de nadinha , se um cair o outro responde ....
>
> nem precisa se preocupar com session etc ...
>
> mas vc quer usar algo , ok
Mas é justamente isso que eu já tenho.
Além disso, o balanceamento de carga do DNS também é round robin, e eu
acabo recaindo no mesmo problema.
O que eu não quero é deixar uma máquina ociosa. Logo, um cluster
ativo/ativo ao invés de um ativo/passivo. Por isso a preucupação com
as sessions.
Veja bem, esses dois hosts são dois pounds, como disse anteriormente.
São eles quem tem que prover a redundância, se eu fizer redundância
com os apaches que estão atrás deles, teria que comprar um host extra,
ou na melhor das hipóteses usar um virtualizador da vida, para cada um
que tivesse.
--
No stupid signatures here.
-------------------------
Histórico: http://www.fug.com.br/historico/html/freebsd/
Sair da lista: https://www.fug.com.br/mailman/listinfo/freebsd
