Eu sei como dimensionar meu software, mas como evitar tempo de inatividade devido a falhas de rede? [duplicado]

Question

Estamos executando sites LAMP bastante grandes, que se adaptam bem ao software. Usamos balanceadores de carga redundantes na frente de um monte de servidores web usando o MySQL através de um proxy em master-slave-slave-slave.

Estamos usando um provedor americano muito grande. Eles não são muito baratos, mas também não são os mais caros.

Na semana passada houve um DDOS muito grande em sua rede e nosso cluster foi afetado; Perdemos a rede um pouco, resultando em tempo de inatividade.

Qual é o procedimento padrão para usar 2 fornecedores (por exemplo, um na UE e um nos EUA)? Eu sei como fazer a replicação de software etc sábio.

Eu estou querendo saber sobre a forma como os dados são enviados para a rede da UE quando o dos EUA está em baixo; DNS é a única escolha para isso? E se sim, como configurar isso? Porque a troca de DNS quando o servidor está inoperante parece muito lento, exceto quando TTL = 0, o que significa que estaríamos usando o DNS como um sistema de failover. Eu entendo (a partir do Serverfault, por exemplo), que este não é o método preferido de trabalho.

Então, qual é o método preferido para resolver isso com quase 100% de tempo de atividade (nosso cluster já tem isso, mas a rede não). Caindo como 1000 pedidos seria bom, mas mais é ruim e nunca deve acontecer.

    

Answer 1

Supondo que eu entendi sua pergunta corretamente, você deseja que seu cliente faça failover para um centro de dados secundário se o principal estiver inativo por qualquer motivo. Um produto que pode lidar com isso é o Gerenciador de Tráfego Global do BIG-IP da f5 Networks. Essencialmente, ele atualizará imediatamente seu DNS quando uma interrupção for detectada para iniciar o redirecionamento de clientes para a rede secundária.

Outra opção pode ser usar algo como Anycast para transmitir as rotas para seus data centers.

Para adicionar essa pergunta, operamos em vários data centers e, no final, decidimos que a melhor rota era para um engenheiro mover manualmente os ponteiros DNS para a disposição alternativa, dependendo do motivo da interrupção. Na pior das hipóteses, podemos estar perdendo uma hora se um data center estiver completamente offline. No entanto, isso é pesado contra o impacto do cliente quando temos que mudar de data center (a atividade recente não estará disponível no local alternativo).

Uma opção final é não confiar no seu data center para fornecer conectividade IP e largura de banda. Em vez disso, fale com um provedor global de IP, como a Global Crossing ou o Level 3, e deixe-os lidar com o roteamento de seu tráfego de entrada para um dos data centers. O risco é que você esteja trabalhando com um único provedor, mas o benefício é que eles podem ser muito mais flexíveis em suas opções de roteamento (você pode utilizar MPLS em sua rede para sua replicação de back-end e também usar a mesma conexão para público). Conectividade de MI).

    

Answer 2

Essencialmente, existem duas opções de tecnologia disponíveis para isso (que eu saiba):

• Como o OP apontou, faça o failover para outro controlador de domínio atualizando o DNS para que os registros apontem para endereços no datacenter operacional.
• IP Anycast , ou seja, o DNS publica um endereço IP, e esse endereço IP é anycasted e está em uso em ambos os datacenters, levando os clientes roteadores para escolher o datacenter mais próximo. Observe que, se um datacenter falhar, o cliente "mais próximo" desse controlador de domínio ainda terá uma interrupção breve, até que as rotas BGP sejam reajustadas.

Because switching DNS when the server is down seems too slow except when TTL = 0

Você pode definir o TTL para zero, mas não espere que todas as redes obedeçam a sua configuração. Na prática, cerca de 10 minutos é o valor mais baixo para o TTL. E, claro, isso implica que o failover baseado em DNS levará entre 0 e 10 minutos para cada cliente, dependendo do seu TTL em seu cache.

Dropping like 1000 requests would be fine, but more is bad and should never happen.

Para o melhor do meu conhecimento, isso está simplesmente fora do que é tecnicamente possível hoje. Mesmo os maiores sites usam tecnologia baseada em DNS ou anycast, e tentam manter seus datacenters próximos de 100% de tempo de atividade, porque não há como obter um failover instantâneo no nível global da Internet.

Dentro de uma LAN, você pode usar algo como o VMWare VMotion para alternar muito rápido, mas isso é por conta própria, LAN controlada de ponta a ponta.

Minha opinião é que o balanceamento de carga global é impraticável, exceto pelos grandes sites com muita experiência técnica:

• Muitos dispositivos de balanceamento de carga têm distribuição geográfica como um bulletpoint de recurso, mas se o DC inteiro estiver inativo, o balanceador de carga também será desativado? ( Edit: Acabei de reler a resposta do DLux , e acho que entendo isso agora ... Você tem dois balanceadores de carga, coloque um em cada CD. Eles estabelecem um batimento cardíaco entre eles. LB no CD ao vivo percebe que seu colega no DC falecido caiu da rede, então o Live LB atualiza o DNS para facilitar o failover.)
• O uso do Anycast é algo que eu pessoalmente não tentaria - a tecnologia existe e está operacional, mas e se houver um problema de roteamento estranho e raro? Solucionar problemas de rede já é bastante difícil, "" otimizar "" no BGP deve ser deixado a verdadeiros especialistas.
• Então, o que resta é o failover baseado em DNS, preferencialmente usando um provedor de DNS replicado globalmente que forneça o DNS do split horizon como um serviço. Isso funcionará e a implantação é bastante direta. No entanto, ele não atende à meta de OP de failover quase instantâneo.

Isenção de responsabilidade, gostaria de receber informações / correções de um verdadeiro especialista que colocou em campo sistemas globalmente redundantes muitas vezes antes ...: -)

    

Answer 3

Você também pode pesquisar uma rede de distribuição de conteúdo (por exemplo, Akamai). O descarregamento de conteúdo estático e o armazenamento em cache de conteúdo dinâmico no CDN podem reduzir significativamente a carga em seu cluster.

O Akamai em particular é muito caro, mas existem outras alternativas mais baratas.