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

Sat Oct 4 19:15:38 -03 2014

Fabiano,

Valeu pelas respostas, a idéia é discutir mesmo.

O que complica o cenário é um requisito que eu não coloquei no primeiro
e-mail para não estender demais a explicação...

No caso deste cliente, existe já uma extensão L2 entre sites. Um fica em
BH, o outro em SP. Porém, existem duas saídas de Internet distintas, uma
cada cidade. Existe um requisito adicional segundo o qual os servidores tem
que acessíveis pelas duas saídas. Até aí parece simples, mas devido ao
firewall estar no meio do caminho, e como tem um firewall em cada site, eu
preciso garantir que o tráfego que entra em SP sai em SP, independente de
ele ter sido atendido (via link L2) pelo servidor que está em BH.

Como comentei, tem outras soluções, cada uma com seus prós e contras...
essa é apenas uma delas, se der certo (parece que vai), tem vantagens
interessantes em termos gerais.

Carlos Ribeiro
Em 04/10/2014 18:52, "Fabiano Siqueira" <fabiano.siqueira at me.com> escreveu:

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