O DNS Round-Robin é “bom o suficiente” para balanceamento de carga de conteúdo estático?

Question

Temos um conjunto de conteúdo estático compartilhado que exibimos entre nossos websites no link . Infelizmente, esse conteúdo não está balanceado no momento - é veiculado em um único servidor. Se esse servidor tiver problemas, todos os sites que dependem dele estarão efetivamente inativos, pois os recursos compartilhados são essenciais para bibliotecas e imagens compartilhadas de javascript.

Estamos procurando maneiras de equilibrar a carga do conteúdo estático neste servidor, para evitar a dependência de um único servidor.

Eu percebo que o DNS round-robin é, na melhor das hipóteses, uma solução de baixo custo (alguns podem até dizer ghetto ), mas não posso deixar de pensar - é round robin DNS uma solução "boa o suficiente" para balanceamento de carga básico de conteúdo estático?

Há alguma discussão sobre isso nas tags [dns] [load-balancing] e Eu li algumas ótimas postagens sobre o assunto.

Estou ciente das desvantagens comuns do balanceamento de carga DNS através de vários registros A de round-robin:

• normalmente não há pulsação ou detecção de falha com registros DNS, portanto, se um determinado servidor na rotação cair, seu registro A deve ser removido manualmente das entradas de DNS
• o tempo de vida (TTL) deve necessariamente ser definido muito baixo para que isso funcione, já que as entradas de DNS são armazenadas em cache de forma agressiva em toda a Internet
• os computadores clientes são responsáveis por ver que há vários registros A e escolher o correto

Mas, o DNS round robin é bom o bastante para começar, melhor do que nada, "enquanto pesquisamos e implementamos alternativas melhores" como forma de balanceamento de carga para nosso conteúdo estático? Ou o DNS round robin é praticamente inútil em qualquer circunstância?

    

Answer 1

Jeff, eu discordo, balanceamento de carga não implica redundância, é exatamente o oposto de fato. Quanto mais servidores você tiver, maior a probabilidade de você ter uma falha em um determinado instante. É por isso que a redundância é obrigatória ao fazer balanceamento de carga, mas infelizmente há muitas soluções que fornecem apenas balanceamento de carga sem realizar nenhuma verificação de integridade, resultando em um serviço menos confiável.

A roundrobina do DNS é excelente para aumentar a capacidade, distribuindo a carga em vários pontos (potencialmente distribuídos geograficamente). Mas não fornece failover. Você deve primeiro descrever o tipo de falha que você está tentando cobrir. Uma falha do servidor deve ser coberta localmente usando um mecanismo de controle de endereço IP padrão (VRRP, CARP, ...). Uma falha de switch é coberta por links resilientes no servidor para dois switches. Uma falha no link WAN pode ser coberta por uma configuração multi-link entre você e seu provedor, usando um protocolo de roteamento ou uma solução layer2 (por exemplo: PPP multi-link). Uma falha no site deve ser coberta pelo BGP: seus endereços IP são replicados em vários sites e você os anuncia à rede somente onde eles estiverem disponíveis.

Da sua pergunta, parece que você só precisa fornecer uma solução de failover do servidor, que é a solução mais fácil, pois não envolve nenhum hardware nem contrato com qualquer ISP. Você só precisa configurar o software apropriado em seu servidor para isso, e é de longe a solução mais barata e confiável.

Você perguntou "e se uma máquina haproxy falhar?". É o mesmo. Todas as pessoas que eu conheço que usam haproxy para balanceamento de carga e alta disponibilidade têm duas máquinas e executam o ucarp, keepalived ou heartbeat para assegurar que uma delas esteja sempre disponível.

Esperando que isso ajude!

    

Answer 2

Como balanceamento de carga, é um gueto, mas mais ou menos eficaz. Se você tivesse um servidor que estava caindo da carga e quisesse distribuí-lo para vários servidores, isso poderia ser uma boa razão para fazer isso, pelo menos temporariamente.

Existem várias críticas válidas ao DNS round-robin como "balanceamento de carga", e eu não recomendaria fazê-lo para isso senão como um band-aid de curto prazo.

Mas você diz que sua principal motivação é evitar uma dependência de servidor único. Sem alguma forma automatizada de retirar os servidores mortos da rotação, isso não é muito valioso como uma forma de evitar o tempo de inatividade. (Com uma maneira automatizada de extrair servidores da rotação e de um curto TTL, ele se transforma em failover do gueto. Manualmente, não é nem isso.)

Se um dos seus servidores de ronda robustez cair, então 50% dos seus clientes terão uma falha. Isso é melhor do que 100% de falhas com apenas um servidor, mas quase todas as outras soluções que fizeram failover real seriam melhores que isso.

Se a probabilidade de falha de um servidor for N, com dois servidores, sua probabilidade é de 2N. Sem o failover automatizado rápido , esse esquema aumenta a probabilidade de que alguns usuários tenham problemas.

Se você planeja retirar manualmente o servidor morto, estará limitado pela velocidade com que pode fazer isso e o DNS TTL. E se o servidor morre às 4 da manhã? A melhor parte do verdadeiro failover é conseguir dormir durante a noite. Você já usa o HAProxy , então você deve estar familiarizado com isso. Eu sugiro strongmente usá-lo, já que o HAProxy foi projetado exatamente para essa situação.

    

Answer 3

O round robin DNS não é o que as pessoas pensam que é. Como um autor de software de servidor DNS (ou seja, BIND ), recebemos usuários que se perguntam por que seus round robin param de funcionar como planejado. Eles não entendem que, mesmo com um TTL de 0 segundos, haverá alguma quantidade de cache por aí, já que alguns caches colocam um tempo mínimo (geralmente 30-300 segundos), não importa o que aconteça.

Além disso, embora seus servidores AUTH possam executar round robin, não há garantia de que aqueles com os quais você se preocupa - os caches com os quais seus usuários falam - o farão. Resumindo, o round robin não garante qualquer pedido do ponto de vista do cliente, apenas o que os seus servidores de autenticação fornecem para um cache.

Se você quiser um failover real, o DNS é apenas um passo. Não é uma má idéia listar mais de um endereço IP para dois clusters diferentes, mas eu usaria outra tecnologia (como o anycast simples) para fazer o balanceamento de carga real. Pessoalmente, eu desprezo o hardware de balanceamento de carga de hardware que muck com DNS, pois geralmente ele erra. E não se esqueça de que o DNSSEC está chegando, então, se você escolher algo nessa área, pergunte ao seu fornecedor o que acontece quando você assina sua zona.

    

Answer 4

Eu já disse isso várias vezes antes, e vou repeti-lo novamente - se a resiliência for o problema, os truques do DNS não são a resposta.

>

Os melhores sistemas de HA permitirão que seus clientes continuem usando exatamente o mesmo endereço IP para cada solicitação. Esta é a maneira única de garantir que os clientes nem notem a falha.

Portanto, a regra fundamental é que a resiliência verdadeira requer truques de nível IP roteamento . Use um appliance de balanceamento de carga ou OSPF "multi-path de custo igual" ou até VRRP.

O DNS, por outro lado, é uma tecnologia de endereçamento . Existe apenas para mapear de um namespace para outro. Ele não foi projetado para permitir mudanças dinâmicas de curto prazo para esse mapeamento e, portanto, quando você tenta fazer essas alterações, muitos clientes não os notam ou, na melhor das hipóteses, levarão muito tempo para notá-los .

Eu também diria que, como load não é um problema para você, você pode ter outro servidor pronto para ser executado como um hot standby. Se você usa round-robin idiota, você precisa alterar proativamente seus registros de DNS quando algo quebrar, então você também pode transformar proativamente o servidor hot standby em ação e não mudar seu DNS.

    

Answer 5

Li todas as respostas e uma coisa que não vi é que os navegadores da Web mais modernos experimentarão um dos endereços IP alternativos se um servidor não estiver respondendo. Se bem me lembro, o Chrome tentará vários endereços IP e continuará com o servidor que responde primeiro. Então, na minha opinião, o balanceamento do DNS Round Robin Load é sempre melhor do que nada.

BTW: vejo o DNS Round Robin mais como solução de distribuição de carga simples.

    

Answer 6

Windows Vista e amp; Windows 7 implemente o suporte ao cliente para round robin de forma diferente , pois eles fizeram backport da seleção de endereços IPv6 para o IPv4. ( RFC 3484 )

Portanto, se você tiver um número significativo de usuários do Vista, do Windows 7 e do Windows 2008, é provável que você encontre um comportamento inconsistente com o pensamento planejado em sua solução de balanceamento de carga ersatz.

    

Answer 7

Estou atrasado para este tópico, por isso a minha resposta provavelmente ficará apenas por baixo, negligenciada, farejando.

Em primeiro lugar, a resposta certa para a pergunta não é responder à pergunta, mas dizer:

1. "Você provavelmente deseja o Balanceamento de carga de rede do Windows." OU
2. "Acompanhe os horários, coloque seu conteúdo estático em algo como Cloud Arquivos ou S3 , e ter um CDN espelhá-lo em todo o mundo. "

O NLB é maduro, adequado à tarefa e muito fácil de configurar. As soluções em nuvem vêm com suas próprias vantagens e desvantagens, que estão fora do escopo desta questão.

Pergunta

is round robin DNS good enough as a starter, better than nothing, "while we research and implement better alternatives" form of load balancing for our static content?

Entre, digamos, 2 ou 3 servidores web estáticos? Sim, é melhor do que nada, porque existem provedores de DNS que integrarão o DNS Round Robin com verificações de integridade do servidor e removerá temporariamente servidores mortos dos registros DNS. Então, dessa forma, você obtém distribuição de carga decente e alguma alta disponibilidade; e tudo leva menos de 5 minutos para configurar.

Mas as advertências descritas por outras pessoas neste tópico se aplicam:

• Os navegadores atuais da Microsoft armazenam em cache os dados DNS de 30 minutos , portanto, você está vendo mais de 30 minutos de tempo de failover para um subconjunto de usuários, dependendo do estado inicial do cache do DNS.
• Quais são os usuários veja durante o failover pode ser ... estranho (você não está usando auth em conteúdo estático e certamente não forma auth, mas o link mostra algo que deve ser observado).

Outras soluções

O HAProxy é fantástico, mas como o Stack Overflow está na pilha de tecnologia da Microsoft, talvez usando o equilíbrio de carga da Microsoft & ferramentas de alta disponibilidade terão menos sobrecarga de administração. O balanceamento de carga de rede cuida de uma parte do problema, e a Microsoft na verdade tem um proxy reverso / load balancer HTTP L7 agora.

Eu nunca usei ARR sozinho, mas dado que está em seu segundo grande lançamento, e vindo da Microsoft, eu suponho que ele foi testado bem o suficiente. Ele tem fácil de entender os documentos , aqui está um sobre como eles vêem < href="http://learn.iis.net/page.aspx/484/configure-3-tier-deployment-architecture-using-application-request-routing/"> distribuição de conteúdo estático e dinâmico em webnodes, e aqui está uma parte sobre como usar ARR com NLB para obter distribuição de carga e alta disponibilidade.

    

Answer 8

É notável como muitos dos contribuintes estão ajudando a contribuir com des-informações sobre o DNS Round Robin como um mecanismo de expansão de carga e resiliência. Geralmente funciona, mas você precisa entender como isso funciona e evitar os erros causados por toda essa desinformação.

1) O TTL nos registros DNS usados para Round Robin deve ser curto - mas NÃO ZERO. Ter o TTL a zero quebra a principal maneira de fornecer resiliência.

2) O DNS RR se espalha, mas não equilibra a carga, ele se espalha porque, em uma grande base de clientes, eles tendem a consultar o servidor DNS de forma independente e acabam com diferentes entradas DNS de primeira escolha. Essas diferentes primeiras escolhas significam que os clientes são atendidos por diferentes servidores e a carga é distribuída. Mas tudo depende de qual dispositivo está fazendo a consulta do DNS e por quanto tempo ele mantém o resultado. Um exemplo comum é que todos os clientes por trás de um proxy corporativo (que realiza a consulta DNS para eles) acabarão tendo como alvo um único servidor. A carga está espalhada - mas não está equilibrada de maneira uniforme.

3) O DNS RR fornece resiliência, desde que o software cliente o implemente adequadamente (e tanto o TTL quanto o período de atenção dos usuários não sejam muito curtos). Isso ocorre porque o DNS round robin fornece uma lista ordenada de endereços IP do servidor, e o software cliente deve tentar contatar cada um deles por sua vez, até encontrar um servidor que aceite a conexão.

Portanto, se o primeiro servidor de escolha estiver inativo, a conexão TCP / IP do cliente expira, e nem o TTL nem o período de atenção expiraram, o software cliente faz outra tentativa de conexão com a segunda entrada na lista. até que o TTL expire ou chegue ao final da lista (ou o usuário desiste com repugnância).

Uma longa lista de servidores quebrados (sua falha) e grandes limites de nova tentativa de conexão TCP / IP (Configuração incorreta da configuração do cliente) podem ocorrer por um longo período antes que o Cliente realmente encontre um servidor em funcionamento. Um TTL muito curto significa que ele nunca chega ao fim da lista e, em vez disso, emite uma nova consulta DNS e recebe uma nova lista (esperamos que em uma ordem diferente).

Às vezes, o cliente fica sem sorte e a nova lista ainda começa com servidores quebrados. Para dar ao sistema a melhor chance de fornecer resiliência ao cliente, você deve garantir que o TTL seja maior do que a atenção típica e que o cliente chegue ao final da lista.

Quando o cliente encontrar um servidor de trabalho, ele deverá se lembrar dele e, quando precisar fazer a próxima conexão, ele não deverá repetir a pesquisa (a menos que o TTL tenha expirado). Um TTL mais longo reduz a frequência com que os usuários experimentam um atraso enquanto o cliente procura por um servidor em funcionamento - proporcionando uma experiência melhor.

4) O DNS TTL entra em cena, quando você deseja alterar manualmente os registros DNS (por exemplo, para remover um servidor quebrado a longo prazo), um TTL curto permite que essa alteração se propague rapidamente (depois de fazer isso) ), então considere o equilíbrio entre quanto tempo levará até você saber sobre o problema, e faça essa alteração manual - e o fato de que os clientes normais só terão que fazer uma nova busca por um servidor em funcionamento quando o TTL expirar.

O round robin DNS tem dois recursos excelentes que o tornam muito econômico em uma ampla variedade de cenários - primeiro é grátis e, em segundo lugar, é quase tão disperso geograficamente quanto sua base de clientes.

Não introduz uma nova 'unidade de falha' que todos os outros sistemas 'inteligentes' fazem. Não há componentes adicionados que possam experimentar uma falha comum e simultânea em toda uma carga de elementos interligados.

Os sistemas 'inteligentes' são ótimos e introduzem mecanismos maravilhosos para coordenar e fornecer um mecanismo de balanceamento e failover contínuos, mas em última análise, os métodos que eles usam para fornecer essa experiência perfeita são o calcanhar de Aquiles - a coisa complicada adicional que pode dar errado, e quando isso acontecer, fornecerá uma experiência perfeita de falha em todo o sistema.

Portanto, o round robin DNS é definitivamente "bom o suficiente" para o primeiro passo além de um único servidor que hospeda todo o seu conteúdo estático em um só lugar.

    

Answer 9

Eu não acho que seja uma solução boa o suficiente, porque digamos que você tenha dois servidores agora e faça um round robin usando o DNS para o endereço IP de cada servidor. Quando um servidor fica inativo, os servidores DNS não sabem que ele caiu e continuarão a servir esse endereço IP, como parte do processo RR. Em seguida, 50% do seu público terá um site corrompido sem imagens ou javascript.

Talvez seja mais fácil apontar para um endereço IP comum tratado pelo Windows NLB que representa dois servidores. A menos que você esteja usando um servidor Linux para o seu conteúdo estático, se eu me lembro de ler isso em algum lugar?

    

Answer 10

O balanceamento de carga Round-robin só funciona quando você também está no controle da zona DNS, de modo que você possa alterar a lista de servidores e enviá-la aos mestres de zona em tempo hábil.

Como mencionado em uma das outras respostas, o mal oculto do round-robin é o cache DNS, que pode acontecer em qualquer lugar entre seus servidores e o cliente, o que anula completamente o pequeno benefício dessa solução. Mesmo com o TTL do DNS configurado para um valor muito baixo, você tem pouco controle sobre por quanto tempo o ISP ou até mesmo o cache DNS do cliente manterá o endereço IP agora inativo ativo.

É uma melhoria em relação a um SPOF, com certeza, mas apenas marginal. Gostaria de dar uma olhada em quem já está hospedando seu servidor e ver o que eles têm a oferecer, muitos têm algum tipo de serviço básico de balanceamento de carga que podem oferecer.

Você pode também ter um único servidor com o conteúdo estático duplicado no S3 e alternar para o CNAME do S3 quando o seu principal for desativado. Você terminará com o mesmo atraso, mas sem o custo de vários servidores.

    

Answer 11

Isso realmente depende do que você está falando e de quantos servidores você está girando. Uma vez tive um site que funcionava em vários servidores, e usei DNS round robin nisso devido principalmente ao meu novato na época, e realmente não era um grande problema. Não foi um grande problema porque não caiu. Era um sistema não-complicado, realmente estúpido, por isso se manteve, e tinha um nível de tráfego bastante constante. Se ele caiu do tráfego, foi durante o dia e algo que eu poderia facilmente cuidar. Eu diria que seu conteúdo estático é qualificado como simples o suficiente para não causar falhas sozinho.

Fora da falha de hardware, etc., quão estável foi o seu servidor? Como "spikey" é o seu tráfego neste conteúdo? Assumindo o Apache ou algo assim e um tráfego relativamente plano, não vai cair muito, e eu diria que o round-robin é "bom o suficiente".

Tenho certeza de que vou votar porque não estou pregando uma solução de 100% de AASI, mas não foi isso que você pediu. Tudo se resume ao que você está disposto a aceitar como solução versus esforço gasto.

    

Answer 12

Se você estava usando o RR DNS para balanceamento de carga, tudo bem, mas você não está. Você está usando isso para ativar um servidor redundante e, nesse caso, não está bem.

Como um post anterior dizia, você precisa de algo para detectar o batimento cardíaco e parar de bater nele até que ele volte.

A boa notícia é que o heartbeat está disponível muito barato, seja em switches ou no Windows.

Não sei sobre outros sistemas operacionais, mas presumo que esteja lá também.

    

Answer 13

Sugiro que você atribua um endereço IP adicional a cada um dos seus servidores (além do IP estático que você usa, por exemplo, ssh) e leve isso para o pool de DNS. E então você usa algum software para alternar esses endereços IP no caso de um servidor falhar. O Heartbeat ou o CARP podem fazer isso, por exemplo, mas existem outras soluções por aí.

Isso tem a vantagem de que, para os clientes do seu serviço, nada precisa mudar na configuração e você não precisa se preocupar com o armazenamento em cache do DNS ou com o TTL, mas ainda pode aproveitar o round-robin do DNS " balanceamento de carga ".

    

Answer 14

Provavelmente fará o trabalho, especialmente se você puder ter vários IPs em suas caixas estáticas. ter um IP "de conteúdo estático" e um IP de "gerenciar máquina". Se uma caixa for desativada, você poderá usar uma solução HA existente ou uma intervenção manual para colocar o IP da máquina com falha em um dos outros "membros do cluster" ou em uma máquina completamente nova (dependendo de quão rápido seria para colocar isso em funcionamento).

No entanto, essa solução terá alguns pequenos problemas. O balanceamento de carga não será em qualquer lugar perto da perfeição e, se você depender de intervenção manual, poderá ter interrupções para alguns visitantes.

Um balanceador de carga de hardware provavelmente pode fazer um trabalho melhor, compartilhando a carga e fornecendo "tempo de atividade de cluster" do que o round-robin DNS. Por outro lado, esse é um (ou dois, desde que você tenha os LBs em um cluster de HA) peças de hardware que precisarão de compra, energia e refrigeração e (possivelmente) algum tempo para se familiarizarem (se você ainda não tiver tem balanceadores de carga dedicados).

    

Answer 15

Para responder de forma sucinta à pergunta (o DNS é bom o bastante como inicial, melhor que nada ", enquanto pesquisamos e implementamos alternativas melhores" forma de balanceamento de carga para nosso conteúdo estático?), eu diria que > é melhor que nada, mas você definitivamente deve continuar pesquisando outras formas de balanceamento de carga.

    

Answer 16

Ao pesquisar o Balanceamento de carga do Windows há alguns anos, vi um documento que afirmava que o Web farm da Microsoft estava configurado como vários grupos de balanceamento de carga, com round-robin de DNS entre eles. Como você pode ter vários servidores DNS respondendo em cada namespace e como o balanceamento de carga da Microsoft é autocorretivo, isso fornece redundância e balanceamento de carga.

Desvantagem: você precisa de pelo menos 4 servidores (2 servidores x 2 grupos).

Respondendo ao comentário de Jeff sobre a resposta de Schof, existe uma maneira de rodar o DNS entre os servidores HAProxy?

    

Answer 17

Eu sempre usei DNS Round-Robin, com TTL longo, como balanceador de carga. Funciona muito bem para serviços HTTP / HTTPS com navegadores .

Realmente enfatizo com navegadores , pois a maioria dos navegadores implementa algum tipo de "nova tentativa em outro IP", mas não sei como seriam as outras bibliotecas ou softwares a solução IP múltipla.

Quando o navegador não obtiver resposta de um servidor, ele chamará automaticamente o próximo IP e, em seguida, ficará com ele (até que esteja inativo ... e tente outro).

Em 2007, fiz o seguinte teste:

• adicione um iframe no meu site, apontando para uma entrada do Round-Robin, como http://roundrobin.test:10080/ping.php
• a página era servida por 3 soquetes PHP, ouvindo em 3 IPs diferentes, todos na porta 10080 (eu não tinha condições de testar na porta 80, já que meu site estava sendo executado)
• um soquete (digamos A ) estava lá para verificar se o navegador poderia se conectar na porta 10080 (como muitas empresas permitem somente portas padrão)
• outros dois sockets (digamos B e C ) podem ser ativados ou desativados na hora.

Eu deixei correr uma hora, tinha muitos dados. Os resultados foram que, para 99,5% dos hits no socket A , eu tive um hit em qualquer socket B ou C (eu não desativei ambos ao mesmo tempo, é claro). Os navegadores eram: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Portanto, mesmo os navegadores não compatíveis com o produto estavam lidando bem!

Até hoje, nunca testei novamente, mas talvez eu configure um novo teste um dia ou libere o código no github para que outros possam testá-lo.

Nota importante: mesmo se estiver a funcionar na maior parte do tempo, não elimina o facto de algumas solicitações falharem . Eu também o uso para solicitações POST, já que meu aplicativo retornará uma mensagem de erro caso isso não funcione, para que o usuário possa enviar os dados novamente, e provavelmente o navegador usará outro IP nesse caso e o save funcionará . E para conteúdo estático, está funcionando muito bem.

Portanto, se você estiver trabalhando com navegadores, use o DNS Round-Robin, para conteúdo estático ou dinâmico. Os servidores também podem ficar no meio de uma transação e, mesmo com o melhor balanceador de carga, você não pode lidar com esse caso. Para conteúdo dinâmico, você precisa tornar suas sessões / banco de dados / arquivos síncronos, senão você não conseguirá lidar com isso (mas isso também é verdade com um balanceador de carga real).

Nota adicional: você pode testar o comportamento em seu próprio IP usando iptables . Por exemplo, antes da sua regra de firewall para o tráfego HTTP, adicione:

iptables -A INPUT -p tcp --dport 80 --source 12.34.56.78 -j REJECT

(onde 12.34.56.78 é obviamente seu IP)

Não use DROP , pois ele deixa a porta filtrada , e seu navegador esperará até o tempo limite. Então, agora, você pode ativar ou desativar um servidor ou outro. O teste mais óbvio é desabilitar o servidor A, carregar a página, habilitar o servidor A e desabilitar o servidor B. Quando você carregar a página novamente, verá uma pequena espera no navegador, então ela será carregada do servidor. Um novamente. No Chrome, você pode confirmar o IP do servidor observando a solicitação no painel da rede. Na guia General de Headers , você verá um cabeçalho falso chamado Remote Address: . Este é o IP de onde você obteve uma resposta.

Então, se você precisa entrar no modo de manutenção em um servidor, basta desabilitar o tráfego HTTP / HTTPS com uma regra iptables REJECT , todos os pedidos irão para outros servidores (com uma pequena espera, quase não perceptível para usuários).

    

Answer 18

Ele tem um uso muito marginal, o suficiente para você passar enquanto você coloca uma solução real no lugar. Como você diz, os TTLs precisam ser definidos bem baixos. Isso tem o benefício de extrair uma máquina problemática do DNS enquanto está tendo problemas. Digamos que você tenha SvrA, SvrB e SvrC distribuindo seu conteúdo e o SvrA seja desativado. Você o retira do DNS e, após o curto período de tempo definido pelo seu TTL baixo, os resolvedores descobrirão que um servidor diferente (SvrB ou SvrC) está ativo. Você coloca o SvrA de volta online e o coloca de volta no DNS. Um curto período de inatividade para algumas pessoas, nenhuma para os outros. Não é ótimo, mas viável. Quanto mais servidores estáticos você colocar no mix, menos chances você terá de ter grupos majoritários de usuários.

Você certamente não obterá a verdadeira distribuição balanceada que uma solução real de balanceamento de carga fornecerá devido à topologia da Internet. Eu ainda assisto a carga em todos os servidores envolvidos.