DNS Load Balancing vs Incremented DNS

Question

Eu não sei muito sobre administração de DNS, etc., mas sei sobre as práticas recomendadas na programação de aplicativos.

Atualmente, na minha empresa, temos 6 servidores nomeados respectivamente:

• s1.domain.com
• s2.domain.com
• s3.domain.com
• s4.domain.com
• s5.domain.com
• s6.domain.com

Tudo bem.

No entanto, o administrador do sistema nos pediu para lidar com esse terminal aleatório em nosso aplicativo, ou seja, precisamos escolher aleatoriamente um servidor nessa lista.

Parece ruim para mim, porque sempre que precisamos adicionar um servidor, precisamos editar nosso aplicativo (mesmo que seja apenas um arquivo de configuração), mas acho que o aplicativo não deve estar ciente de tais coisas, da mesma forma que entidade deve não sabe sobre o servidor persistente.

Meu pensamento é usar um balanceamento de carga do DNS, um domínio, apontando para ip diferente

Um endpoint: mobile.domain.com

O sysadmin me disse que é ruim ou algo assim, mas estou convencido de que essa é a melhor solução, mais ela permitirá o balanceamento de carga de geolocalização mais tarde, o que é ótimo. By the way, aleatoriamente escolher um servidor de uma lista não vai impedir o desligamento do servidor, pois aleatória é, não apenas aleatória, e não parece eficiente para mim.

Obrigado pelo seu feedback, se tiver argumentos pro & contras eu posso usar:)

    

Answer 1

O round robin de DNS é geralmente aceito como uma solução de custo muito baixo para o balanceamento de carga. É verdade que requer alterações manuais no DNS, no caso de um servidor ficar indisponível. Também é verdade que as alterações do DNS precisam de tempo para se propagar (e isso depende de resolvedores intermediários).

Por outro lado, é muito barato, comparado ao custo de um balanceador de carga adequado. Há também a questão da complexidade. Existem soluções de software livre para balanceamento de carga, mas elas não são simples de configurar e, se algo der errado, você (ou seus administradores de sistemas) precisam ter o conhecimento necessário para solucioná-lo. Atualizar uma zona DNS é algo relativamente simples de fazer.

A menos que você tenha uma situação em que a disponibilidade do serviço seja absolutamente crucial ou a falha de solicitações (devido a atrasos do DNS) resulte em perda grave de receita, sua melhor opção é o round robin do DNS.

Para responder à pergunta de que tipo de balanceamento de carga você precisa, é necessário estabelecer o custo de solicitações com falha.

Em qualquer caso, as mudanças no aplicativo, seja ele código ou arquivos de configuração, não são uma boa ideia, já que isso introduz atrasos ainda maiores (na propagação das alterações do aplicativo).

    

Answer 2

Eu acho que o seu Sysadmin estava tentando dizer foi que usar o DNS para balanceamento de carga não é ruim, mas é inconveniente. Você pode adicionar 6 IP ao DNS para um domínio específico, mas fica difícil gerenciar o cluster. Se você quiser tirar uma das máquinas da rotação, você teria que editar seu registro DNS e esperar que ele se propagasse. Isso pode ser feito definindo um TTL mais baixo, mas você não pode contabilizar quaisquer resolvedores intermediários que não seguem o protocolo DNS.

É mais conveniente ter um balanceador de carga e apontar o domínio para o LB e os 6 servidores atrás dele. Ele permite adicionar / remover servidores porque você não precisa se preocupar com o tempo de propagação do DNS.

    

Answer 3

Embora o que Sameer e Wolfgangsz digam seja verdade para round-robin, eles minimizaram os problemas com o que é realmente um mecanismo inútil , e perdeu vários problemas que causarão dor, incluindo o DNS-client e resolução de caching DNS-proxy e falta de garantias de preservação de pedidos na jornada do servidor DNS de conteúdo para o cliente DNS.

Como mencionado , SRV dos registros de recursos abordam todos esses problemas. Você obtém uma prioridade e uma ponderação, que o armazenamento em cache em servidores DNS proxy não destrói. Os administradores podem, com eles, fazer coisas que você provavelmente acabará querendo fazer no futuro, como configurar grupos de servidores substitutos e principais, especificar a ordem de fallback e controlar pesos em um único grupo de servidores. Escrever o código do cliente para escolher o servidor para conversar usando os pesos e prioridades determinados também não é muito difícil.

Dependendo de quem vai usar seus aplicativos, apenas você ou o mundo como um todo, talvez seja necessário registrar seu nome de protocolo (usado nos nomes de domínio de registro de recurso SRV ) com registros como este . Como você pode ver, outras pessoas já têm.

Como Sameer também disse, um balanceador de carga real é outra alternativa, também preferível, ao shuffling de round-robin inútil.