Alternativas para o DNS round robin

Question

Desculpe por não estar claro anteriormente.

Temos uma instância do servidor virtualizado vmware que é nosso principal servidor de produção. Eu armazeno uma série de aplicativos baseados na web em quase cem domínios únicos de primeiro nível. Para servir páginas da web, usamos uma pilha LAMP. Este servidor está executando nossos servidores dns primários e secundários (em dois endereços IP diferentes daqueles usados para servir conteúdo da web). E finalmente nós também hospedamos nossos e-mails (pop e smtp) usando o exim (eu acredito).

Recentemente, tivemos problemas fazendo com que nosso fs raiz se tornasse somente leitura, impedindo as conexões do apache2 ou mysql e impedindo o recebimento de emails. Essencialmente, reduzindo a presença na web e e-mail para muitos milhares de clientes. A natureza da questão (ainda indeterminada sob controle) não afetou o bind, então o dns ainda estava resolvendo bem.

Desde então, começamos a espelhar os sites de produção e os bancos de dados mysql associados em um servidor secundário. Este servidor está completamente pronto para produção.

A minha pergunta é , quais são os métodos recomendados para um failover no caso de o apache no nosso servidor de produção principal falhar (por qualquer motivo) para rapidamente, se não automaticamente, começar a encaminhar o tráfego sem problemas quanto possível ao secundário.

O round-robining de DNS é indesejável para nós, já que não desejamos carregar dois servidores, na verdade, queremos que o secundário receba somente solicitações http, caso o servidor principal não seja responsivo. Isso se deve em parte ao fato de que nosso processo de espelhamento é unidirecional e as alterações no servidor secundário seriam refletidas no servidor principal e até mesmo perdidas.

    

Answer 1

O round robin de DNS não é recomendado porque:

1- Servidores diferentes podem não estar expostos à mesma quantidade de solicitações. Então, eles serão carregados de maneira desigual.

2- O balanceamento de carga de DNS não leva em conta a disponibilidade do servidor. O registro de DNs do servidor permanecerá e poderá ser usado em caso de falha.

3- O armazenamento em cache do DNS irá piorar ainda mais. Você não tem controle sobre os caches DNS de seus clientes e de qualquer servidor DNS intermediário entre eles. Se você planeja fazer seu samller de valor TTL, ele pode não funcionar como esperado. Veja este post . A resposta aceita diz que Many DNS server do not honor your TTL .

A solução recomendada é instalar um balanceador de carga como o HAProxy junto com uma solução de alta disponibilidade, como heartbeat. Essa configuração deve ser instalada em duas máquinas. Se um cair, o outro assumirá o VIP (por pulsação). A máquina em execução cuidará de verificar a integridade dos servidores de backend e distribuir a carga (por haproxy).

EDITAR:

Se você quiser que os servidores funcionem no modo ativo-passivo, você não precisa de um balanceador de carga. Você pode instalar heartbeat com marcapasso para monitorar os recursos do sistema, como apache, mysql, etc. O cluster pode ser configurado para manter apenas um servidor ativo.

    

Answer 2

Instale o nginx na frente do Apache. Se um servidor Apache estiver inativo, o nginx irá excluí-lo e fornecer dados de outros "trabalhadores".

Então, a configuração deve ser assim

nginx - > trabalhador # 1 (Apache), trabalhador # 2, trabalhador # 3 etc.

É claro que o nginx deve ser instalado na caixa dedicada. Um problema que você tem que resolver - e se o nginx estiver indisponível, mas ...

site nginx: link

    

Answer 3

O Linux Virtual Server é um servidor altamente escalável e altamente disponível, construído em um cluster de servidores reais, com o balanceador de carga. / p>

O UCARP permite que alguns hosts compartilhem endereços IP virtuais comuns para fornecer failover automático

    

Answer 4

Pelo que entendi, você está procurando uma solução de alta disponibilidade, ou seja, quando um servidor fica inativo, outro servidor pode assumir o controle.

O que a ThomK sugeriu é uma maneira de fazer isso, exceto que o único ponto de falha será a caixa nginx. Outra coisa que você pode ver é usar o HAProxy (ou até mesmo o nginx), mas com algum tipo de failover baseado em IP.

Você pode ter um monte de ideias em em outro lugar .

    

Answer 5

Para redundância em um único site, em um único feed de Internet, você deseja colocar o hardware em cluster em seu front end, com uma caixa de espera pronta para assumir o endereço IP de uma caixa com falha. Mas você estará fora de ação se seu ISP falhar ou seu site perder poder ou sofrer algum outro problema.

Se você quiser proteção contra a perda de um site inteiro ou a perda do seu ISP, existem apenas duas opções. Uma delas é obter seu próprio número de sistema autônomo BGP e executar suas próprias rotas BGP, com peering (bem, tráfego pago) com vários ISPs diferentes. O menor netblock que você pode fazer isso é um / 24, então você precisa ter um netblock pelo menos tão grande. Você pode, então, anunciar rotas diferentes para um site diferente se o site principal ficar inativo.

Sua outra opção, como você sugere, é o DNS round robin. Algumas pessoas desacreditam isso em termos teóricos, e há problemas com clientes Windows Vista selecionando endereços não aleatoriamente, mas ele deve funcionar bem para redundância, com a caixa de backup apenas invertendo o tráfego de proxy de volta para a caixa principal a menos que a caixa principal / site / feed da Internet cai.

    

Answer 6

After some research it turns out DNS round robining ... isn't desirable or recommended for this service.

Realmente? Eu ficaria muito interessado em ver os artigos descrevendo isso.

Você não mencionou em que sistema operacional este é executado - o que tem muita relevância na forma como o clustering é implementado, nem o software que você usa atualmente para o DNS / como é fácil mudar isso.

Se você puder evitar isso, recomendo usar um cluster de tipo replicado em vez de um cluster de armazenamento compartilhado, principalmente onde os dados não estão sendo alterados com frequência.

O Bind já fornece a replicação mestre / escravo para distribuir os dados por várias plataformas - por isso, é apenas uma questão de descobrir uma maneira de rotear as solicitações para um servidor disponível.

Similarmente para o MySQL.

Implementar o mesmo para os arquivos do seu servidor web é simples usando o rsync.

Enquanto o failover round-robin é um pouco lento em comparação com outros métodos - é MASSIVELY mais robusto, mais simples de administrar e mais barato do que outras abordagens. Sem conhecer suas razões para o diskliking round-robin, é difícil sugerir algo que possa ser mais aceitável. (Os caras que escreveram o HA-Proxy recomendam usar pelo menos dois servidores proxy com round-robin na frente de um cluster de HA).

Eu sugiro que você use (pelo menos internamente) endereços virtuais do servidor master e slave - isso simplifica o negócio de promover o slave. Você pode até querer usar endereços virtuais para cada nó de serviço / cluster. Isso facilita a configuração de uma pulsação associada ao failover de endereço - isso não será mais rápido do que o round robin, mas terá benefícios marginais durante o serviço reduzido - desde que implementado corretamente e que você possa resolver problemas cerebrais divididos.