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

Fabiano Siqueira fabiano.siqueira at me.com
Fri Oct 3 17:44:24 -03 2014


Nesse caso poderia estar usando Cisco OTV, HP IVE ou VXLAN.
Acredito que essas tecnologia são os melhores mundo para Data Center Interconnect (DCI).

Fabiano Siqueira

On 03/10/2014, at 17:03, Carlos Ribeiro <cribeiro at telbrax.com.br> wrote:

> 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
> --
> gter list    https://eng.registro.br/mailman/listinfo/gter




More information about the gter mailing list