[GTER] Configuração de strong x weak host model para servidores

Fri Oct 3 17:03:03 -03 2014

Douglas,

Infelizmente, acredite em mim; não é questão de volume de tráfego. É um
ambiente de redundância legado e extremamente complicado, que eu não posso
redesenhar do zero.

Resumindo, estou analisando possíveis melhorias para uma solução de alta
disponibilidade envolvendo sites redundantes em estados diferentes. Não dá
para usar agregação por causa disso. Os servidores podem estar rodando em
qualquer um dos datacenters, e podem acessados diretamente por clientes
externos por qualquer um links. Se eu usar solução L2, ou deixar com o weak
model, vou ter tráfego assimétrico; ou pior ainda, vou dar volta entre os
dois datacenters prejudicando a performance.

Para ter maior controle de tráfego, e evitar o famoso "trombone" (tráfego
que entra um site, passeia no outro e volta para o site origem), estou
avaliando a possibilidade de fazer a solução de continuidade funcionar em
cima de L3.

O uso de duas interfaces de rede em cada servidor, com IPs distintos, com
strong model, permite garantir maior controle sobre o roteamento com o
maior nível de disponibilidade possível. Em cima disso ainda tem monte de
coisa: DNS round robin, firewall de alta disponibilidade, storage
replicado, etc.

Infelizmente não posso dar muito mais detalhes sem autorização cliente, mas
acreditem: não é um caso trivial :-)

Carlos Ribeiro
Em 03/10/2014 16:28, "Douglas Fischer" <fischerdouglas at gmail.com> escreveu:

> Na correria,
> confesso que lí muito rapidamente seu texto.
> Mas creio que a melhor forma de garantir que estejas usando o "StrongModel"
> é não ter duas interfaces de rede Layer3 em um mesmo servidor.
>
> Não consigo entender a função de um servidor operar em mais de uma rede.
> Para isso existem os roteadores...
> Use o servidor em uma rede só, e roteie o acesso a ele.
>
> "A demanda de trafego de rede é muito grande?"
> Use Link Aggregation, use Switch Router.
>
>
>
>
> Maaaaas, se realmente pretendes usar duas sub-redes distintas em um mesmo
> server.
> Sugiro que uses VRF nos servidores.
> Se não me engano, no linux o nome disso é network namespace.
>
>
>
> Em 3 de outubro de 2014 15:09, Carlos Ribeiro <cribeiro at telbrax.com.br>
> escreveu:
>
> > Prezados,
> >
> > Como parte de um trabalho para um cliente, estou pesquisando o suporte a
> > tipos diferentes de "host model" para servidores. É um tema interessante
> e
> > para o qual existe relativamente pouca informação e troca de experiência.
> >
> > Basicamente, em um servidor com várias interfaces, existem dois modos
> > primários de comunicação:
> >
> > - No "weak model" o servidor pode enviar e receber pacotes com o IP de
> > qualquer uma das interfaces existentes em todas as interfaces. Este é o
> > comportamento default do Linux e das versões antigas do Windows.
> >
> > - No "strong model" o servidor só pode receber (ou enviar) pacotes se o
> IP
> > de destino (ou origem) estiver na subrede correta para uma determinada
> > interface. Este é o comportamento default do BSD e das versões mais novas
> > (depois do Vista) do Windows.
> >
> > O problema é que muitos servidores operam com o "weak model" e podem
> criar
> > assimetria de tráfego, criando problemas com o firewall, por exemplo.
> >
> > Minhas perguntas no estilo "TLDR" são:
> >
> > 1) Alguém já precisou reconfigurar os servidores para mudar o modo de
> > operação da pilha TCP?
> >
> > 2) Em um ambiente híbrido, com servidores de diversos tipos (Windows
> 2003,
> > Windows 2008, Linux OpenSUSE e RedHat, etc.), há como garantir que todos
> os
> > servidores estejam usando obrigatoriamente o "strong model"? Seria essa
> uma
> > recomendação razoável?
> >
> > Agora para quem quiser detalhes... seguem mais comentários e explicações.
> >
> > ==========================================
> >
> > OBSERVAÇÃO IMPORTANTE
> >
> > O uso do "weak model" ou do "strong model" é uma propriedade da pilha TCP
> > de um sistema operacional, em alguns casos pode ser configurado, mas é um
> > comportamento intrínseco de cada host. A RFC1122 estabelece as definições
> > básicas para IPv4; a RFC3484 trata da extensão para IPv6, que segue
> > critérios semelhantes; e finalmente, a RFC6419 trata das "práticas
> atuais"
> > para cada sistema operacional.
> >
> > WEAK MODEL
> >
> > Para entender o impacto do "weak model", suponha a configuração:
> >
> > - Servidor Linux "genérico" (opera em 'weak mode' por default)
> > - eth0: 10.0.1.1/24
> > - eth1: 10.0.2.1/24
> >
> > Se o servidor estiver configurado em "weak mode", e um pacote destinado
> ao
> > IP 10.0.2.1 chegar na interface eth0, o mesmo será recebido e encaminhado
> > internamente para a interface lógica correta.
> >
> > No caso do recebimento de pacotes, este comportamento é necessário em
> > alguns casos mas deixa o sistema vulnerável, e neste caso pode ser
> aplicado
> > um filtro, que é configurado por default em algumas distribuições.
> >
> > No caso do envio de pacotes, o "weak model" é mais complicado e pode
> causar
> > problemas de tráfego assimétrico. Suponha o seguinte cenário:
> >
> > - eth0: 10.0.1.1/24
> > - eth1: 10.0.2.1/24
> > - servidor web configurado no endereço da eth1 (10.0.2.1:80)
> > - duas saídas para a Internet (ex: dois "upstreams" diferentes), um em
> cada
> > rede
> > - rota default para 10.0.1.254 (ou seja, o gateway fica na rede da eth0)
> >
> > Quando um cliente externo tentar acessar a página web, o servidor
> > provavelmente receberá os pacotes pela eth1. Porém, assumindo a
> > configuração default de "weak model", o pacote de resposta será enviado
> > pela eth0**, criando a assimetria. Essa assimetria nem sempre causa
> > impacto, mas em certos casos - por exemplo, se houver um firewall
> stateful
> > no caminho - irá quebrar as coisas.
> >
> > Obs: No caso do Linux, há um flag (SO_BINDTODEVICE) que força o envio dos
> > pacotes pela mesma interface onde o socket foi inicialmente aberto, que
> > "resolve" o problema. Mas eu não sei qual é a prática para servidores Web
> > hoje em dia, se é que existe uma; e além do mais, esse flag não é
> suportado
> > em outros OSs.
> >
> > STRONG MODEL
> >
> > No "strong model", se repetirmos o mesmo cenário do servidor web acima, o
> > pacote sempre sairá pela interface "certa", mesmo que a rota default
> esteja
> > configurada para a interface eth0. Não haverá assimetria de tráfego.
> >
> > CONFIGURAÇÕES DEFAULT
> >
> > - No Windows server 2003 e XP, o default é weak model.
> > - No Windows Vista para cima, e no Windows 2008 para cima, o default é
> > strong model, mas pode ser configurado como weak model.
> > - No BSD, o default é strong model.
> > - No Linux, o default é weak model, mas pode ser configurado como strong
> > model (apesar de ser difícil descobrir como :-/)
> >
> > *Carlos Ribeiro*
> > *Sócio*
> > Cel: +55 (31) 9303-3366
> > Tel: +55 (31) 3305-5620
> > Geral: +55 (31) 3305-5600
> > cribeiro at telbrax.com.br
> > www.telbrax.com.br
> > --
> > gter list    https://eng.registro.br/mailman/listinfo/gter
>
>
>
>
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter