O DNS Round-Robin é "bom o suficiente" para balancear a carga de conteúdo estático?

Temos um conjunto de conteúdo estático compartilhado que servimos entre nossos sites em http://sstatic.net . Infelizmente, atualmente, este conteúdo não possui balanceamento de carga - ele é veiculado em um único servidor. Se esse servidor tiver problemas, todos os sites que dependem dele ficarão inoperantes porque os recursos compartilhados são imagens e bibliotecas javascript compartilhadas essenciais.

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

Sei que o DNS round-robin é, na melhor das hipóteses, uma solução de baixo custo (alguns podem até dizer gueto ), mas não consigo deixar de pensar: o DNS round-robin é uma solução "suficientemente boa" para o 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 tópico.

Estou ciente das desvantagens comuns do balanceamento de carga DNS por meio de vários registros round-robin A:

• normalmente não há pulsação ou detecção de falha nos registros DNS; portanto, se um determinado servidor na rotação diminuir, seu registro A deverá ser manualmente removido das entradas DNS
• o tempo de vida (TTL) deve necessariamente ser definido como bastante baixo para que isso funcione, pois as entradas DNS são armazenadas em cache de forma agressiva na Internet
• os computadores clientes são responsáveis ​​por verificar a existência de vários registros A e selecionar o correto

Mas, o DNS de rodízio é bom o suficiente para começar, melhor do que nada ", enquanto pesquisamos e implementamos alternativas melhores" da forma de balanceamento de carga para o nosso conteúdo estático? Ou o rodízio de DNS é praticamente inútil sob quaisquer circunstâncias?

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

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

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

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

Esperando que isso ajude!

Como balanceamento de carga, é gueto, mas mais ou menos eficaz. Se você tivesse um servidor que estava caindo do carregamento e desejasse espalhá-lo para vários servidores, talvez esse fosse um bom motivo para fazê-lo, pelo menos temporariamente.

Há várias críticas válidas ao DNS de rodízio como "balanceamento de carga" e eu não recomendaria fazer isso além de um curativo de curto prazo.

Mas você diz que sua principal motivação é evitar uma dependência de servidor único. Sem uma maneira automatizada de tirar servidores inoperantes da rotação, não é muito valiosa como forma de impedir o tempo de inatividade. (Com uma maneira automatizada de extrair servidores da rotação e de um TTL curto, torna-se failover do gueto. Manualmente, nem é isso.)

Se um dos seus dois servidores de rodízio for desativado, 50% dos seus clientes sofrerão uma falha. Isso é melhor que 100% de falha com apenas um servidor, mas quase qualquer outra solução que tenha feito failover real seria melhor que isso.

Se a probabilidade de falha de um servidor for N, com dois servidores sua probabilidade será 2N. Sem failover rápido e automatizado, esse esquema aumenta a probabilidade de alguns de seus usuários sofrerem falhas.

Se você planeja desativar manualmente o servidor morto, fica limitado pela velocidade com que pode fazer isso e pelo TTL do DNS. E se o servidor morrer às 4 da manhã? A melhor parte do verdadeiro failover é dormir a noite toda. Você já usa o HAProxy , por isso deve estar familiarizado com ele. Eu sugiro fortemente usá-lo, pois o HAProxy foi projetado exatamente para esta situação.

O round robin DNS não é o que as pessoas pensam. Como autor do software de servidor DNS ( BIND ), temos usuários que se perguntam por que o round robin para de funcionar conforme o planejado. Eles não entendem que, mesmo com um TTL de 0 segundos, haverá uma certa quantidade de cache por aí, pois alguns caches colocam um tempo mínimo (geralmente de 30 a 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 você se preocupe - os caches com os quais os usuários falam - desejar. Em resumo, o round robin não garante nenhuma solicitação do ponto de vista do cliente, apenas o que seus servidores de autenticação fornecem a um cache.

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

Eu já disse isso várias vezes antes e repetirei - se a resiliência for o problema, os truques de DNS não serão a resposta .

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

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

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

Eu diria também que, como o carregamento não é um problema para você, é melhor que você tenha outro servidor pronto para executar como um modo de espera quente. Se você usar o round-robin burro, precisará alterar proativamente seus registros DNS quando algo quebrar, para que você também possa ativar proativamente o servidor de espera ativa em ação e não alterar seu DNS.

Eu li todas as respostas e uma coisa que eu não vi é que os navegadores mais modernos tentam 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 responder primeiro. Então, na minha opinião, o DNS Round Robin Load balancing é sempre melhor que nada.

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

Estou atrasado para esta discussão, então minha resposta provavelmente ficará apenas no fundo, negligenciada e cheirada.

Primeiro, 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 Files ou S3 e faça com que uma CDN espelhe isso em todo o mundo".

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

Pergunta, questão

o DNS round robin é bom o suficiente para começar, melhor do que nada ", enquanto pesquisamos e implementamos alternativas melhores" da forma de balanceamento de carga para o nosso conteúdo estático?

Entre, digamos, 2 ou 3 servidores Web estáticos? Sim, é melhor que nada, porque há provedores de DNS que integrarão o DNS Round Robin com verificações de integridade do servidor e removerão temporariamente servidores mortos dos registros DNS. Portanto, desta forma você começa decente distribuição de carga e alguns de alta disponibilidade; e 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 por 30 minutos , para que você observe mais de 30 minutos de tempo de failover para um subconjunto de usuários, dependendo do estado inicial do cache DNS.
• O que os usuários veem durante o failover pode ser ... estranho (você não está usando a autenticação no conteúdo estático e certamente não a forma, mas o link mostra algo a ser observado).

Outras soluções

O HAProxy é fantástico, mas como o Stack Overflow está na pilha de tecnologia da Microsoft, talvez o uso das ferramentas de balanceamento de carga e alta disponibilidade da Microsoft tenha menos sobrecarga administrativa. O balanceamento de carga de rede cuida de uma parte do problema, e a Microsoft atualmente tem um proxy / balanceador de carga reverso L7 HTTP agora.

Eu nunca usei o ARR, mas, como é seu segundo grande lançamento, e vindo da Microsoft, presumo que ele tenha sido testado suficientemente bem. Ele tem documentos de fácil compreensão , aqui está um sobre como eles veem a distribuição de conteúdo estático e dinâmico em nós da web, e aqui está um artigo sobre como usar o ARR com o NLB para obter distribuição de carga e alta disponibilidade.

É notável quantos dos contribuidores estão ajudando a contribuir com informações incorretas sobre o DNS Round Robin como um mecanismo de propagação de carga e resiliência. Geralmente funciona, mas você precisa entender como 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 em zero interrompe 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, portanto, acabam com entradas DNS de primeira escolha diferentes. Essas primeiras escolhas diferentes significam que os clientes são atendidos por servidores diferentes e a carga é distribuída. Mas tudo depende de qual dispositivo está fazendo a consulta 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 executa a consulta DNS para eles) acabam tendo como alvo um único servidor. A carga é espalhada - mas não é equilibrada uniformemente.

3) O DNS RR fornece resiliência desde que o software cliente a implemente adequadamente (e o tempo de atenção do TTL e do usuário não é muito curto). Isso ocorre porque o round robin do DNS fornece uma lista ordenada de endereços IP do servidor, e o software cliente deve tentar entrar em contato com cada um deles, até encontrar um servidor que aceite a conexão.

Portanto, se o servidor de primeira escolha estiver inoperante, a conexão TCP / IP do cliente atingirá o tempo limite e, desde que o TTL ou o tempo de atenção não tenham expirado, o software cliente tentará outra conexão com a segunda entrada da lista - e assim por diante até que o O TTL expira ou chega ao fim da lista (ou o usuário desiste de desgosto).

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

Às vezes, o cliente fica com azar e a nova lista ainda começa com servidores danificados. Para oferecer ao sistema a melhor chance de fornecer resiliência ao cliente, você deve garantir que o TTL seja maior que o tempo de atenção típico e que o cliente chegue ao final da lista.

Depois que o cliente encontrar um servidor em funcionamento, ele deverá se lembrar e, quando precisar fazer a próxima conexão, 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 sofrem um atraso enquanto o cliente procura por um servidor em funcionamento - proporcionando uma experiência melhor.

4) O DNS TTL se destaca quando você deseja alterar manualmente os registros DNS (por exemplo, para remover um servidor danificado a longo prazo), em seguida, um TTL curto permite que essa alteração se propague rapidamente (assim que você tiver feito isso), então considere o equilíbrio entre quanto tempo levará para você saber sobre o problema e faça essa alteração manual - e o fato de que os clientes normais precisarão apenas fazer uma nova pesquisa por um servidor em funcionamento quando o TTL expirar.

O rodízio de DNS possui dois recursos excelentes que o tornam muito econômico em uma ampla variedade de cenários - primeiro gratuito e, em segundo lugar, é quase tão geograficamente disperso 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 sofrer 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 contínuo de equilíbrio e failover, mas, em última análise, os próprios métodos que eles usam para fornecer essa experiência contínua são o calcanhar de Aquiles - a coisa mais complicada que pode dar errado, e quando isso acontecer, proporcionará uma experiência perfeita de falha no sistema.

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

O Windows Vista e o Windows 7 implementam o suporte ao cliente para round robin de maneira diferente , pois suportam a seleção de endereço IPv6 para IPv4. ( RFC 3484 )

Portanto, se você tiver um número significativo de usuários do Vista, Windows 7 e Windows 2008, provavelmente encontrará um comportamento inconsistente com o pensamento planejado na sua solução de balanceamento de carga ersatz.

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

Eu realmente me estresso com os navegadores, já que a maioria dos navegadores implementa algum tipo de "nova tentativa em outro IP", mas não sei como outras bibliotecas ou softwares lidariam com a solução de múltiplos IP.

Quando o navegador não obtém resposta de um servidor, ele automaticamente chama o próximo IP e o mantém (até ficar inoperante ... e depois tenta outro).

Em 2007, fiz o seguinte teste:

• adicione um iframe no meu site, apontando para uma entrada Round-Robin, como http://roundrobin.test:10080/ping.php
• a página era servida por 3 soquetes PHP, escutando em três IPs diferentes, todos na porta 10080 (não podia me dar ao luxo de testar na porta 80, pois meu site estava sendo executado nela)
• havia um soquete (digamos A ) para verificar se o navegador poderia se conectar à porta 10080 (quantas empresas permitem apenas portas padrão)
• outros dois soquetes (digamos B e C ) podem ser ativados ou desativados em tempo real.

Deixei correr uma hora, tinha muitos dados. Os resultados foram que, para 99,5% dos acessos no soquete A , tive um atingido no soquete B ou C (não desabilitei os dois ao mesmo tempo, é claro). Os navegadores eram: iPhone, Chrome, Opera, MSIE 6/7/8, BlackBerry, Firefox 3 / 3.5 ... Então, mesmo navegadores não tão compatíveis estavam lidando direito!

Até hoje, eu nunca o 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 que seja trabalhando a maior parte do tempo, ele não remove o fato de que alguns pedidos irá falhar. Também o uso para solicitações POST, pois meu aplicativo retornará uma mensagem de erro caso não funcione, para que o usuário possa enviar os dados novamente e, provavelmente, o navegador usará outro IP nesse caso e o salvamento funcionará . E para conteúdo estático, está funcionando muito bem.

Portanto, se você estiver trabalhando com navegadores, use o DNS Round-Robin, seja para conteúdo estático ou dinâmico, você ficará bem. Os servidores também podem ficar inativos 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 sincronizar suas sessões / banco de dados / arquivos; caso contrário, não será capaz de lidar com isso (mas isso também ocorre com um balanceador de carga real).

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

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

(onde 12.34.56.78está obviamente o seu IP)

Não use DROP, pois ela deixa a porta filtrada e seu navegador aguardará o tempo limite. Portanto, 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 e, em seguida, será carregada no servidor A de novo. No Chrome, você pode confirmar o IP do servidor observando a solicitação no painel de rede. Na Generalguia Headers, você verá um cabeçalho falso chamado Remote Address:. Este é o IP de onde você obteve uma resposta.

Portanto, se você precisar entrar no modo de manutenção em um servidor, basta desativar o tráfego HTTP / HTTPS com uma iptables REJECTregra, todas as solicitações serão encaminhadas para outros servidores (com uma pequena espera, quase imperceptível para os usuários).

Não acho que seja uma solução boa o suficiente, porque digamos que você tenha dois servidores agora e rode o robin usando DNS para o endereço IP de cada servidor. Quando um servidor fica inoperante, os servidores DNS não sabem que ele foi inoperante e continuarão a servir esse endereço IP, como parte do processo de RR. Em seguida, 50% do seu público-alvo obterão um site danificado, sem javascript ou imagens.

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

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

Conforme mencionado em uma das outras respostas, o mal oculto do round-robin é o cache do DNS, que pode acontecer em qualquer lugar entre os servidores e o cliente, o que nega completamente os pequenos benefícios desta solução. Mesmo com o DNS TTL definido para um valor muito baixo, você tem pouco controle sobre quanto tempo os ISPs ou o cache DNS do cliente manterão o endereço IP agora morto.

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

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

Isso realmente depende do que você está falando e de quantos servidores você está rodando. Certa vez, eu tinha um site que rodava em vários servidores, e usei o round round robin no DNS devido principalmente a meu novato na época, e isso realmente não era um grande problema. Não foi um grande problema porque não travou. Era um sistema realmente complicado e estúpido, portanto aguentou 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 cuidar facilmente. Eu diria que seu conteúdo estático é qualificado como simples o suficiente para não causar falhas por conta própria.

Fora da falha de hardware, etc., quão estável está o seu servidor? Qual é o nível de tráfego do seu conteúdo? Supondo que o Apache seja direto ou algo parecido e com tráfego relativamente baixo, não vai falhar muito, e eu diria que o round-robin é "bom o suficiente".

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

Se você estivesse usando RR DNS para balanceamento de carga, tudo bem, mas você não está. Você está usando-o para habilitar um servidor redundante; nesse caso, não está bem.

Como um post anterior disse, você precisa de algo para detectar os batimentos cardíacos e parar de bater até que ele volte.

A boa notícia é que os batimentos cardíacos estão disponíveis muito baratos, tanto em switches quanto no Windows.

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

Sugiro que você atribua um endereço IP adicional a cada um dos seus servidores (além do IP estático usado para, digamos, ssh) e leve-o para o pool DNS. E então você usa algum software para alternar entre esses endereços IP no caso de um servidor falhar. Os batimentos cardíacos 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 cache do DNS ou TTL, mas ainda pode tirar proveito do "balanceamento de carga" round-robin do DNS .

Provavelmente fará o trabalho, especialmente se você puder ter vários IPs em suas caixas estáticas. tenha um IP "veicular conteúdo estático" e um IP "gerenciar máquina". Se uma caixa cair, você pode usar uma solução de alta disponibilidade existente ou intervenção manual para ativar o IP da máquina com falha em um dos outros "membros do cluster" ou em uma máquina completamente nova (dependendo da velocidade que seria para colocar isso em funcionamento).

No entanto, essa solução terá alguns pequenos problemas. O balanceamento de carga não chegará nem perto da perfeição e, se você depender de intervenção manual, poderá haver 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 do cluster" do que o round-robin do DNS. Por outro lado, esse é um (ou dois, já que idealmente você tem 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 familiarizar (se você ainda não tiver balanceadores de carga dedicados).

Para responder sucintamente à pergunta (o DNS de rodízio é bom o suficiente para começar, melhor que nada ", enquanto pesquisamos e implementamos melhores formas 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.

Ao pesquisar o balanceamento de carga do Windows há vários anos, vi um documento que afirmava que o web farm da Microsoft estava configurado como vários grupos de balanceamento de carga, com rodízio de DNS entre eles. Como você pode ter vários servidores DNS respondendo em cada espaço para nome e como o balanceamento de carga da Microsoft é auto-reparável, 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?

Ele tem uso muito marginal, o suficiente para ajudá-lo enquanto você coloca uma solução real no lugar. Como você diz, os TTLs devem ser definidos muito baixos. No entanto, isso tem o benefício de extrair uma máquina problemática do DNS enquanto estiver com problemas. Digamos que você tenha SvrA, SvrB e SvrC distribuindo seu conteúdo e o SvrA será desativado. Você o retira do DNS e, após o curto período de tempo definido pelo seu TTL baixo, os resolvedores descobrirão um servidor diferente (SvrB ou SvrC) ativo. Você coloca o SvrA novamente online e o coloca novamente no DNS. Um tempo de inatividade curto para algumas pessoas, nenhum para outras. Não é ótimo, mas viável. Quanto mais servidores estáticos você colocar na mistura, menor a probabilidade de ter grupos de usuários em sua maioria.

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