[GTER] Appliances de DNS recursivo para Rede.

[Ricardo Rodrigues]

Olá Guilherme,

Meu ponto é que, pra responder à pergunta "qual tamanho de cache eu devo
usar?", sugiro que este tamanho seja definido olhando o hit ratio. A partir
de determinado tamanho, o ganho de hit ratio com aumento de memória é
mínimo.

Em produção, temos hit ratio superior a 95% com menos de 1 GB de memória
RAM.

Abs,
Ricardo

Em 19 de agosto de 2016 10:40, Guilherme Domingues <
guilherme.domingues.oliveira at gmail.com> escreveu:

> Ricardo e Evaldo, concordo com todos pontos citados.
>
> A questão de hit ratio não está ligado a um número mágico de memória. Mas a
> demanda de queries que elencam a proporção de hit ratio, e que
> consequentemente todos os fatores de capacidade nos servidores/appliances
> serão promovidos.
>
> Em bancada não obtive resultados suficientes de hit ratio, enquanto não
> "povuei" os 12Gbytes de um servidor em homologação.
>
> Em produção estou com 88% de hit ratio sem sobrescrever o TTL de nenhuma
> zona. Mas claro que este fator de hit ratio varia de acordo com o ambiente.
>
>
>
> LPI 201
> LPI000161013
> https://cs.lpi.org/caf/Xamman/certification/process_verify
> code verification:  v8bwxqzja7
> Linux ID #425752
> ---
> "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
> original."  Albert Einstein
>
> 2016-08-19 10:24 GMT-03:00 Guilherme Domingues <
> guilherme.domingues.oliveira at gmail.com>:
>
> > Rafael, usei este template:
> > https://github.com/Rikbruggink/Zabbix-templates/
> > tree/master/2.0/DNS/Unbound%20Recursor
> >
> > Jonatas, montei meu ambiente em anycast em Linux.
> >
> >
> >
> >
> >
> > LPI 201
> > LPI000161013
> > https://cs.lpi.org/caf/Xamman/certification/process_verify
> > code verification:  v8bwxqzja7
> > Linux ID #425752
> > ---
> > "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
> > original."  Albert Einstein
> >
> > 2016-08-19 5:19 GMT-03:00 Evaldo Gardenal via gter <gter at eng.registro.br
> >:
> >
> >> Senhores
> >>
> >> Sugiro levar em conta os seguintes fatores para planejar um novo serviço
> >> de
> >> DNS (Caching Resolver):
> >> - Latência e perda de pacotes são seus inimigos. Minimize.
> >>   * Virtualização, dependendo da tecnologia, prioritização e carga do
> >> host,
> >> pode influenciar negativamente ambos.
> >>   * Instalações regionais e próximas aos usuários podem propiciar ganho
> >> substancial
> >> - rfc7871 EDNS Client Subnet melhora em muito o controle de trafego para
> >> CDNs que utilizam DNS para distribuição de carga. Prefira implementar um
> >> serviço que suporte essa extensão.
> >> - Dimensionamento apropriado do cache para maximizar hit-ratio. Quanto
> >> mais
> >> eficiente seu cache, mais rápido os usuarios recebem resposta, evitando
> >> consulta upstream.
> >> - DNS é um dos principais fatores no tempo para o primeiro byte, já que
> >> avanços significativos ocorreram com HTTP/2 e QUIC.
> >>   * Isso afeta a percepção de *velocidade* para os seus usuários, uma
> vez
> >> que diferença em largura de banda pode não ser perceptível ao carregar
> >> conteudo pequeno.
> >>
> >>
> >> On Thu, Aug 18, 2016 at 5:47 PM Guilherme Domingues <
> >> guilherme.domingues.oliveira at gmail.com> wrote:
> >>
> >> > Fernando, não há um número mágico. Mas pode começar com duas vm's com
> >> > 4Gbytes e o teto do Unbound bem configurado com o link passado.
> >> >
> >> > Outra dica no momento de configurar deixe uma margem para rotação
> >> correta
> >> > do Unbound, algo de 80% na soma total da VM. Por aqui estou usando
> >> template
> >> > do Unbound no zabbix e me ajudou bastante no ajuste fino.
> >> >
> >> >
> >> >
> >> >
> >> > LPI 201
> >> > LPI000161013
> >> > https://cs.lpi.org/caf/Xamman/certification/process_verify
> >> > code verification:  v8bwxqzja7
> >> > Linux ID #425752
> >> > ---
> >> > "A mente que se abre a uma nova idéia jamais voltará ao seu tamanho
> >> > original."  Albert Einstein
> >> >
> >> > 2016-08-17 18:21 GMT-03:00 Marcelo Gardini do Amaral <
> >> mgardini at gmail.com>:
> >> >
> >> > > Jonatas,
> >> > >
> >> > > por curiosidade: você pode dizer quantas consultas por segundo (ou
> >> > > outra unidade de tempo)
> >> > > seu servidor de DNS recursivo recebe em um rede de 10k usuários?
> >> > >
> >> > > []'s
> >> > > Gardini
> >> > >
> >> > >
> >> > >
> >> > > 2016-08-17 14:42 GMT-03:00 Fernando Frediani <fhfrediani at gmail.com
> >:
> >> > > > Obrigado pelas referências Guilherme.
> >> > > >
> >> > > > Minha dúvida é quando é muito memória  pra um servidor DNS
> >> Recursivo.
> >> > > > Imagibei que alguns poucos GB de RAM ja seria o bastante para
> >> armazenar
> >> > > > muita informação em cache mesmo para um recursivo de uso médio pra
> >> > alto.
> >> > > >
> >> > > > Fernando
> >> > > >
> >> > > > On 17 Aug 2016 13:00, "Guilherme Domingues" <
> >> > > > guilherme.domingues.oliveira at gmail.com> wrote:
> >> > > >
> >> > > >> Fernando, utilizo mais memória para aumentar o teto de cache de
> >> rrsets
> >> > > do
> >> > > >> UNBOUND, aumentado a possibilidade de hits locais para meus
> >> usuários.
> >> > > >>
> >> > > >> Danton, segue um guia oficial:
> >> > > >> https://www.unbound.net/documentation/howto_optimise.html. A
> >> respeito
> >> > > de
> >> > > >> benchmark, em bancada utilizei uma destas ferramentas:
> >> > > >> https://www.grc.com/dns/benchmark.htm
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> LPI 201
> >> > > >> LPI000161013
> >> > > >> https://cs.lpi.org/caf/Xamman/certification/process_verify
> >> > > >> code verification:  v8bwxqzja7
> >> > > >> Linux ID #425752
> >> > > >> ---
> >> > > >> "A mente que se abre a uma nova idéia jamais voltará ao seu
> tamanho
> >> > > >> original."  Albert Einstein
> >> > > >>
> >> > > >> 2016-08-17 12:08 GMT-03:00 Fernando Frediani <
> fhfrediani at gmail.com
> >> >:
> >> > > >>
> >> > > >> > Por que bastante memória para um servidor DNS recursivo ?
> >> > > >> >
> >> > > >> > Fernando
> >> > > >> >
> >> > > >> > 2016-08-17 11:43 GMT-03:00 Guilherme Domingues <
> >> > > >> > guilherme.domingues.oliveira at gmail.com>:
> >> > > >> >
> >> > > >> > > Recomendo DNS próprio mesmo virtualizado, pórem com bastante
> >> > > mémoria e
> >> > > >> o
> >> > > >> > > tunning de performace para o kernel e o Unbound.
> >> > > >> > >
> >> > > >> > > LPI 201
> >> > > >> > > LPI000161013
> >> > > >> > > https://cs.lpi.org/caf/Xamman/certification/process_verify
> >> > > >> > > code verification:  v8bwxqzja7
> >> > > >> > > Linux ID #425752
> >> > > >> > > ---
> >> > > >> > > "A mente que se abre a uma nova idéia jamais voltará ao seu
> >> > tamanho
> >> > > >> > > original."  Albert Einstein
> >> > > >> > >
> >> > > >> > > 2016-08-17 11:34 GMT-03:00 Rubens Kuhl <rubensk at gmail.com>:
> >> > > >> > >
> >> > > >> > > > 2016-08-17 9:17 GMT-03:00 Jonatas M. Victor <
> >> > jonatasmv at gmail.com
> >> > > >:
> >> > > >> > > >
> >> > > >> > > > > Srs,
> >> > > >> > > > >
> >> > > >> > > > >    Até hoje sempre montei meus DNS. Mas devido ao
> >> crescimento
> >> > e
> >> > > a
> >> > > >> > > > automação
> >> > > >> > > > > estou procurando appliances prontos para atender pedaços
> de
> >> > rede
> >> > > >> com
> >> > > >> > > até
> >> > > >> > > > > 10k de usuários. Alguém já viu algum equipamento assim?
> >> > > >> > > > >
> >> > > >> > > >
> >> > > >> > > > Se forem 10k usuários de conectividade Internet, continue
> >> > montando
> >> > > >> seus
> >> > > >> > > > DNS...
> >> > > >> > > > ... se for ambiente corporativo, algum DDI possivelmente
> >> > > integrado a
> >> > > >> > IPAM
> >> > > >> > > > pode ser legal. Infoblox, Appliansys etc.
> >> > > >> > > >
> >> > > >> > > >
> >> > > >> > > > Rubens
> >> > > >> > > > --
> >> > > >> > > > 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
> >> > >
> >> > >
> >> > >
> >> > > --
> >> > > Marcelo Gardini do Amaral
> >> > > www.spin.blog.br
> >> > >
> >> > > --
> >> > > $>cd /pub
> >> > > $>more beer
> >> > > --
> >> > > 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
>