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

Sat Oct 4 19:20:02 -03 2014

Complementando, outra alternativa é copiar uma técnica de CDN, rodando um
servidor DNS anycast, de forma que o DNS responda com IPs diferentes caso
um cliente acesse primeiro em SP ou em BH. Mas aí eu preciso ter servidores
rodando simultaneamente nas duas cidades, o que não é suportado por algumas
aplicações existentes , e que eu não posso reescrever...

Carlos Ribeiro
Em 04/10/2014 19:15, "Carlos Ribeiro" <cribeiro at telbrax.com.br> escreveu:

> 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
>>
>