[GTER] Configuração de strong x weak host model para servidores
Carlos Ribeiro
cribeiro at telbrax.com.br
Fri Oct 3 21:30:32 -03 2014
Cássio,
Valeu, vou dar uma lida. Foi fácil de mexer, teve algum efeito colateral,
ou funcionou de primeira?
Carlos Ribeiro
Em 03/10/2014 20:34, "Cassio Lange" <cassio at cassio.eng.br> escreveu:
> Carlos,
>
> Utilizei "weak host" em servidores Exchange atrás de um balanceador de
> carga, para que a resposta fosse diretamente do servidor para o cliente, ou
> seja não retornassem pelo balanceador de carga.
>
> Este é o cenário.
>
>
> http://support.citrix.com/proddocs/topic/netscaler-load-balancing-93/ns-lb-usecases-dsrmode-con.html
>
> Abraços
>
> 2014-10-03 17:03 GMT-03:00 Carlos Ribeiro <cribeiro at telbrax.com.br>:
>
> > 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
> >
> --
> gter list https://eng.registro.br/mailman/listinfo/gter
More information about the gter
mailing list