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

Fabiano Siqueira fabiano.siqueira at me.com
Sat Oct 4 00:10:41 -03 2014


Eu entendo Carlos, é que eu acho sempre a melhor solução estender o L2 do que trabalhar com GSLB.
Por isso coloquei a VXLAN como uma solução que pode simplificar, usando qualquer meio L3 entre os DC.

Fabiano Siqueira

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

> Fabiano,
> 
> Já fiz projeto com FabricPath, MPLS e OTV, infelizmente não é aplicável
> neste cenário. A rede está montada e envolve serviços de datacenter de
> terceiros. A solução precisa necessariamente usar os equipamentos
> existentes.
> 
> Na verdade, essa envolvendo a configuração correta do host model nos
> servidores é uma entre três opções. Postei aqui porque achei o tema
> interessante, até pela pouca discussão, e queria ouvir as experiências do
> grupo.
> 
> Carlos Ribeiro
> Em 03/10/2014 20:35, "Fabiano Siqueira" <fabiano.siqueira at me.com> escreveu:
> 
>> 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
>>>>> 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
>> 
>> --
>> 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