Redundancia de entrada
-
Boa tarde galera, me desculpem se já existir um tópico com esse assunto, eu procurei e não achei.
La vai, já fiz o meu balanceamento de saída ta funcionando perfeito. Porem preciso de uma redundância de entrada já que os meu serviços são internos. EX: site, FTP, Email…Eu já dupliquei todas as regras do fw, ou seja tudo que tem pra um link tem para o outro.
Criei 2 DNS um para cada link.A minha ideia seria colocar os 2 dns no registro br e deixar ele fazer o balanceamento se um dns para automaticamente o registro br encaminharia para o outro dns, para funcionar bem diminuiria o ttl dos meus dns.
Alguém sabe dizer se isso vai da certo? Ou se existe alguma outra forma de fazer o mesmo sem gastar uma fortuna com os apliances tipo BIG-IP e companhia.
-
Você só vai ter isso com BGP ou alguma outra solução que receba a requisição na internet e passe para seu firewall.
A redundância de dns funciona bem para balanceamento. A decisão de usar o link A ou B via dns é do cliente, ou seja selecionado aleatoriamente.
É importante você deixar os dois links respondendo dns. Se você tiver uma falha de link sem previsão de volta, você altera o dns para responder www, ftp, etc a partir do link que esta no ar.
-
No caso eu iria deixar os dois respondendo pelos serviços.
Cada hora um receberia a requisição e caso um deles parasse o outro ficaria respondendo sozinho, sem precisar de intervenção humana.Isso não funcionaria?
-
Não 100%.
Se o cliente remoto 'escolher' o ip que esta fora, a pagina não abre.
-
Mas no caso o cliente remoto vai acessar pelo nome.
Quando for consultar os DNS o registro br vai tentar no master e vai ver que está fora e então tentará no segundo, que estará ON.O que vc acha?
-
Mas no caso o cliente remoto vai acessar pelo nome.
Quando for consultar os DNS o registro br vai tentar no master e vai ver que está fora e então tentará no segundo, que estará ON.
O que vc acha?leandruco,
Não é assim que funciona o processo de pesquisa DNS. Você não tem nenhuma garantia que o internauta vai usar o DNS Master primeiro que o Slave. Como disse o marcelloc, o cliente (sistema operacional) é quem "escolhe" qual DNS pesquisar!
Leia mais sobre isso aqui: https://antigosite.matik.com.br/?op=modload&name=News&file=article&sid=80
Abraços!
Jack -
Bom dia obrigado pelo link,
Pore o mesmo informa o que eu já havia dito"E assim na FAPESP o assunto é exatamente igual. A FAPESP na hora de cadstrar um domínio exige a indicação de um MASTER e um SLAVE pelo motivo de que um deles pode estar fora e assim o outro responde. Mas também os servidores DNS da FAPESP apenas são clientes e assim tanto faz se configuro na FAPESP como master o MEU master ou o MEU slave. Isso porque o MEY master e slave, cada um deles é capaz de responder por ele mesmo independente do outro."
Ou seja coloco o master de uma operadora e o slave de outra, caso o master venha a ficar fora do ar o slave irá funcionar.
Por que não daria certo?Se tiver os 2 UP ficam os 2 trabalhando normalmente.
-
Ou seja coloco o master de uma operadora e o slave de outra, caso o master venha a ficar fora do ar o slave irá funcionar.
Por que não daria certo?Se tiver os 2 UP ficam os 2 trabalhando normalmente.
Porque o internauta, que está usando um Windows 7 ou um Ubuntu 11.04, por exemplo, tem sua própria tabela de DNS Cache por default e não faz esta verificação (se um cair, consulta/acessa o outro). A FAPESP exige 2 DNSs para melhorar a disponibilidade sobre a autoridade dos domínios.
Em outras palavras, o usuário que está em qualquer lugar na Internet pode "insistir" em acessar o seu domínio mesmo que ele esteja down pelo link que houve acesso da última vez (porque tem armazenada internamente a resolução DNS e não vai perguntar novamente)… E ele não vai fazer uma nova consulta DNS, vai "morrer tentando". A menos que o cliente desabilite o cache DNS (o que quase ninguém faz): http://support.microsoft.com/kb/318803/pt-br
Entende?
Abraços!
Jack -
HUMMM.
Agora ficou claro.
Mas o meu pensamento não estava completamente errado né.
FU…
E então o que eu faço?
Tem alguma sugestão. Eu não intendi muito bem a dica do amigo Marcello. -
Jackl
Essa tabela de DNS, ela tem uma duração saberia dizer qual é o tempo??
Eu dei uma pesquisada parece que por padrão é 86.400 segundos ou seja 24h.Esse failover de entrada pra mim é mais importante do que a saída pois o meu site tem em media 52mil acessos por mês.
Estou desesperado por uma solução.
-
Jackl
Desculpe minha insistência porem acho que ainda há solução.
Segue linha do artigo que vc me mandou:
" Resolver descarta o registro do cache. O período de tempo é especificado na Vida útil associada ao registro de recursos DNS. "Ou seja isso é definodo pelo TTL correto?
Se eu configurar os meu DNS para te um TTL baixo as consultas vão ser realizadas com mais frequência, sendo assim mesmo que ele insista em acessar o dns down isso só vai acontecer até o tempo definido por mim no TTL do servidor DNS.Então diminuiria esse TTL para uns 10 minutos e então para esses clientes o tempo de down dos meu serviços seriam de 10Minutos no Máximo.
Diz que vai da certo!!!!
;D -
O papel do registro.br é informar onde está o servidor de dns, e não responder a requisição para você.
Com dois ips de dns configurados, o cache permanece. O TTL baixo vai ajudar a velocidade de atualização, mas se o seu dns continuar informando que o servidor web está no ip onde o link caiu, você continua com o serviço parado.
Deixe o TTL baixo e sempre que tiver uma queda sem previsão de volta ou com tempo de previsão acima do que você espera, você comenta a entrada de dns dos ips que estão fora, incrementa o serial do dns(importantíssimo) e aplica as atualizações.
Desta forma a proxima vez que o cliente perguntar quem é o servidor web, se dns responde corretamente.
exemplo visual:
com os dois links funcionando, seu dns fica configurado desta forma:
meudominio.com.br
www A 200.200.128.2
www A 189.189.189.2com um link fora, você altera o dns para responder isso
meudominio.com.br
www A 200.200.128.2
Automático, só com BGP ou alguma ferramenta que deixe o seu TTL mínimo(1 segundo por exemplo) e altere o dns sempre que um link cair.
att,
Marcello Coutinho -
Automático, só com BGP ou alguma ferramenta que deixe o seu TTL mínimo(1 segundo por exemplo) e altere o dns sempre que um link cair.
Nesta linha de raciocínio do colega marcelloc, em clientes que possuem um cenário crítico, que precisam de garantias e alta disponibilidade, pessoalmente utilizo em clientes roteadores de borda que tem estas características (na frente do pfSense, por exemplo). Se quiser mais detalhes, entre em contato em pvt!
Abraços!
Jack -
Opa Marcello,
Obrigado mais uma vez pela ajuda.Mas segue uma dúvida minha (espero que a ultima para não tomar mais o tempo de vcs): No modo que vc me falou no mesmo dns tem que ter as 2 entradas cada uma com o ip de uma operadora. Mas esse DNS ele tem que ter um IP Válido para que seja acessado externamente, se a operadora cai como ele vai ser acessado?
Por isso que eu penso em fazer 2 dns cada um com os ips de sua operadora.
Exemplo:
DNS1
www A 200.200.x.xDNS2 A 189.200.x.x
OU eu teria que ter um master e um slave, o master eu disponibilizo por um ip e o slave pelo outro mas ambos com as entradas duplicadas?
-
master e slave é melhor.
você publica uma unica configuração de dns e a altera de acordo com a necessidade.
O número serial da configuração de dns é verificado antes de qualquer alteração,
Se você tem um dns com serial maior que o outro, o de menor valor nunca terá suas informações replicadas.Outro exemplo:
meu dns tem informacao de serial 2011122101 do seu dns
em seguida seu link cai e so o segundo dns responde
meu dns faz uma nova consulta e recebe 2011121800 com serial. entre 2011122101 e 2011121800, meu dns entende que a versão local de cache é mais recente que a publicada, então mantem o cache e não altera nada.
-
Hummm..
Só recapitulando para ver se eu entendi
2 DNS um Master e outro Slave
O master publicado com ip da operadora X
E o Slave publicado com o up da operadora YNa configuração do DNS colocar os registros duplicados cada um com o up válido de uma operadora.
Caso a operadota x venha a cair, comentar as entradas do dns que contenho o ip da mesma.
Alterar o serial para que as informações possam ser atualizadas para os outros servidores.
Manter o TTL baixo.
É isso ai?
-
exatamente.
Se você for bom de script shell ou php, este procedimento pode ficar automático.
-
Blz Marcello
Fico muito grato a você e ao Jackl pela ajuda e paciência.Vou fazer os teste e posto os resultados.
Obrigado.
-
Bom dia,
marcelloc, fiz os DNS certinho
ta funcionando que é uma blz.
Alias quando é feita este tipo de configuração de 2 entradas no mesmo dns só que cada uma para um ip valido de cada operadora é o que chamamos de dns round robin. Nem precisa desabilitar um entrada caso um link caia, pois desta forma acada requisição que entra ele vai para um link, a redundância de entrada ficou bala, coloquei o ttl baixo mas ele nem demora os 2 minutos que configurei ele tenta em uma n respondeu ele vai pra outra automaticamente.Só que tem um problema…. Como de costume....
O reverso para os servidores de email....
Como tem 2 entradas para o mx ele e a cada requisição ele pega um ip e ai na hora de consultar o reverso da problema.
Consulto a primeira vez ele resolver certo, na segunda vez ele fala que o meu mx não esta respondendo para o ip correto pois resolveu pelo outro link, e assim vai alternando, uma hora da certo na outra tentativa não. E com isso meus ips está sendo cadastrado em varias black lists.Alguem ai tem alguma ideia pra me ajudar???
Segue foto do site ipok na consulta de reverso
-
Nem precisa desabilitar um entrada caso um link caia, pois desta forma acada requisição que entra ele vai para um link
No round robin, a decisão de qual ip usar é do cliente, se ele escolher o ip do link que esta fora, a pagina não vai abrir.
O reverso para os servidores de email….
Como tem 2 entradas para o mx ele e a cada requisição ele pega um ip e ai na hora de consultar o reverso da problema.
Consulto a primeira vez ele resolver certo, na segunda vez ele fala que o meu mx não esta respondendo para o ip correto pois resolveu pelo outro link, e assim vai alternando, uma hora da certo na outra tentativa não. E com isso meus ips está sendo cadastrado em varias black lists.Confere o reverso cadastrado dos dois ips, usar mais de um ip não é o problema. você define um nome de host para cada ip e cadastra dois registros mx
mx1 para ip 1 e mx2 para ip 2 -
Consulto a primeira vez ele resolver certo, na segunda vez ele fala que o meu mx não esta respondendo para o ip correto pois resolveu pelo outro link, e assim vai alternando, uma hora da certo na outra tentativa não. E com isso meus ips está sendo cadastrado em varias black lists.
Alguem ai tem alguma ideia pra me ajudar???leandruco,
Configure duas entradas PTR no seu DNS Server… cada uma apontando para o IP de um dos links!
Nota: Não confunda round robin search dns com isso que você configurou. A pesquisa DNS é sempre eleita pelo cliente!
Abraços!
Jack -
Vlw pelas dicas.
Em relação ao dns eu fiz os testes, mesmo se cliente estiver resolvendo com o dns que esta off, ao identificar isso automaticamente é direcionado para o próximo registro, eu fiz os testes aqui e funcionou perfeitamente. o tempo de para abrir a página foi em torno de 40 segundos. -
mesmo se cliente estiver resolvendo com o dns que esta off, ao identificar isso automaticamente é direcionado para o próximo registro, eu fiz os testes aqui e funcionou perfeitamente. o tempo de para abrir a página foi em torno de 40 segundos.
Retry não significa detectar automaticamente e usar o proximo.
De toda forma, você já sabe o conceito. Aplicar ou não é decisão sua ;)
-
jack
Foi exatamente isso que eu fizPara todos os serviços que são acessador externamente.
-
Ao que parece (a imagem está mto escura) estas são as entradas do tipo "A RECORD". Você precisa configurar adequadamente as entradas do tipo "PTR" quando falamos de DNS REVERSO.
Leia (conceito) mais sobre aqui: http://www.hardware.com.br/livros/linux-redes/dns-reverso.html
Abraços!
Jack -
o meu reverso é na operadora.
E ja esta cada um pra uma operadora.
Vou cadastrar o mx2 e vou fazer os testes -
o meu reverso é na operadora.
E ja esta cada um pra uma operadora.
Vou cadastrar o mx2 e vou fazer os testesSe o REVERSO é resolvido pela operadora, não deveria estar encontrando problemas. Apenas cadastre as entradas "A RECORD'' de modo que sejam compatíveis com o Reverso e pronto!
;)
Abraços!
Jack -
Pois é foi isso que fiz.
Mas como cada consulta ele sai por um ip da problema.
Pois uma hora ele vai ver que o meu mx resolve o ip da operadora 1, ná próxima consulta vai ver que o mx responde pelo ip da operadora 2 dai o reverso não vai bater.Eu cadastrei o mx2 agora e deixei o mx1 pra uma operadora e o 2 pra outra. Vamos ver o que vai dar.
-
Mas como cada consulta ele sai por um ip da problema.
Se o problema está na saída, me parece que não se trata de uma questão de DNS REVERSO, mas sim de SPF. Tens certeza que não está confundindo as coisas?
Abraços!
Jack -
Creio que não, pois o spf esta configurado certo.
"v=spf1 a:mx1.xxx.xxx.br"Se as 2 entradas estão configuradas como mx1 então não era pra dar problema.
Como vc pode ver nas imagens que eu mandei junto com o primeiro post de hoje, se eu conferir pelo site ipok, a cada consulta que faço o resultado muda alternando entre ok e erro.
-
Eu cadastrei o mx2 agora e deixei o mx1 pra uma operadora e o 2 pra outra. Vamos ver o que vai dar.
já viu o que deu?
-
Creio que não, pois o spf esta configurado certo.
"v=spf1 a:mx1.xxx.xxx.br"Certo,
Bem, então cadastrando o mx2 como uma entrada do tipo "MX" no teu DNS Server em outro "runlevel" deve resolver.
Nota: Continuo achando esta solução altamente "não profissional"! :-[
Abraços!
Jack -
Nota: Continuo achando esta solução altamente "não profissional"! :-[
[/quote]Eu assinaria uma solução destas apenas se integrado com ferramentas de monitoria(nagios ou zabix) para que em caso de falha, o dns se ajustaria ao link em funcionamento.
Conheço ferramentas pagas de alta disponibilidade que para trabalhar com redundancia de link sem BGP, configuram o dns com ttl zero para poder publicar mudanças de rota de acesso em poucos segundos apos a falha do link.
EDIT
Só para tentar me fazer entender sem passar por arrogante ou qualquer coisa do tipo.
O caminho é este, mas falta a cereja em cima do bolo.att,
Marcello Coutinho -
O caminho é este, mas falta a cereja em cima do bolo.
Cereja esta, que pode trazer grandes prejuízos (não só financeiros, mas conceituais também) quando a gente fala de uma estrutura corporativa e que dependa de alta-disponibilidade na web! ;)
Abraços!
Jack -
Opa galera parece que deu certo os testes com os reversos estão dando certo agora.
Em relação ao recurso utilizado acho que vcs mas do que ninguém sabem que as vezes temos que fazer as coisas funcionarem sem gastar dinheiro e sem muitos recurso, nesse caso não foi diferente, cotei as soluções pagas e as mesmas não foram aprovadas, sendo assim esta forma foi a melhor que pude fazer.
Em relação ao BGP conseguir um bloco de ip próprio é um parto e a empresa não se enquadra nos requisitos para o mesmo.E diga-se de passagem funcionou melhor do que eu esperava fiz os testes desligando as interfaces e o tempo de espera foi pouco.
Eu tenho uma outra rede wan fora de qualquer firewall completamente separada da minha rede pra fazer os testes, agora é sentar e esperar o link cair e ver oque dá.Mas segue ai a dica pra que quiser fazer um fail over e LB de entrada barato.
Duplicas as entradas A do dns colocando cada uma com o ip de uma operadora, depois publicar o master com o ip de uma operadora e o slave com o ip de outra operadora no registro br.Como o Marcello falou falta a cereja do bolo mas ainda sim é um bolo, de fuba mas é… kKKKKKK
Obrigado a todos pela ajuda e o tempo gasto. Vcs são 10.
-
Opa galera parece que deu certo os testes com os reversos estão dando certo agora.
Em relação ao recurso utilizado acho que vcs mas do que ninguém sabem que as vezes temos que fazer as coisas funcionarem sem gastar dinheiro e sem muitos recurso, nesse caso não foi diferente, cotei as soluções pagas e as mesmas não foram aprovadas, sendo assim esta forma foi a melhor que pude fazer.Blz leandruco… Sem querer criar qualquer polêmica ou estender esta thread, a única ressalva que faço aqui é que cabe a nós (profissionais da área), alertar de forma clara e amparados por subsídios técnicos, os gestores (quem decide sobre o $$$ nas empresas) sobre o que é o "ideal" e o que é o "realizável" pelos recursos dispensados. E qual o impacto disso no negócio (não na TI, mas no cerne do negócio mesmo - enquanto estratégia corporativa).
"Você é responsável pelo que cativas"! :-D
Em relação ao BGP conseguir um bloco de ip próprio é um parto e a empresa não se enquadra nos requisitos para o mesmo.
Sim… só se você fosse um AS (Sistema Autônomo)!
PS: Fico feliz em saber que o "realizável" funcionou pra você com o nosso pfSense. É pra isso mesmo que este fórum existe! ;)
Abraços!
Jack
