Estratégia de failover da Internet durante a hospedagem de serviços com um staticip

0

Dado que você tem duas redes com ics estáticas:

rede A.) 66.xxx.xxx.9 (para alcançar esta entrada de DNS da rede é myservice.mydomain.com)

e

rede B.) 66.xxx.xxx.29 ((para acessar esta entrada de DNS da rede é myservice.backupmydomain.com))

A primeira rede que você usa normalmente e a segunda rede é uma rede de backup.

Você tem um serviço hospedado em um computador na rede.

Quando a rede A for desativada, o roteador passará para a rede B. Mas ainda será necessário encaminhar solicitações do mundo externo de A para B. Caso contrário, um cliente fora da rede baterá na porta e descobrirá que A está em baixo.

Como você encaminha automaticamente para a rede B quando a rede A está desativada se você está enviando pacotes do lado de fora? Basicamente, gostaria de fazer duas coisas quando a rede A estiver inoperante. 1.) Mude para a rede B. 2.) diga a todos os pacotes que vão para a rede A ir para a rede B.

    
por user190084 04.12.2014 / 00:30

2 respostas

0

Existem algumas soluções alternativas, mas nenhuma delas é automática / perfeita. O mais fácil é alterar a entrada do DNS quando uma das redes está inativa. Alguns provedores de DNS oferecem "verificações de saúde" que podem automatizar isso para você, mas ainda haverá tempo de inatividade enquanto os novos registros DNS se propagam.

Se você seguir esse caminho, mantenha o TTL em suas entradas DNS o mais curto possível.

Outra alternativa seria usar um balanceador de carga na nuvem. O DNS apontaria aqui, e os balanceadores de carga enviariam tráfego para os servidores apropriados dinamicamente à medida que diminuíssem. O LB é o novo ponto único de falha, mas se projetado corretamente, isso pode funcionar muito bem.

    
por 04.12.2014 / 00:37
-1

No interior da sua rede, para tráfego de saída, você pode executar um FHRP * entre seus dois roteadores. Isso exigirá que você substitua o (s) dispositivo (s), pois os hosts terão um novo gateway padrão. Você criaria ou reutilizaria um VIP [virtual ip] e atribuiria isso ao interior de ambos os roteadores.

No entanto, os protocolos, por configuração ou configurações padrão, encaminham automaticamente o tráfego com base em 'critérios' configuráveis. Geralmente você está rastreando a conectividade com um endereço de camada 3 (como o gateway padrão da WAN), você gostaria de consultar a documentação e o conjunto de recursos de seus roteadores.

A idéia geral é que, quando o seu FHRP, de escolha, detectar a internet, ele permite que o seu roteador "em espera" (ou ativo, se necessário) comece a responder às solicitações MAC ARP virtuais e comece a encaminhar o tráfego com o mesmo VIP compartilhado pelo roteador principal como sua origem. Mais uma vez, dependente do protocolo, mas alguns podem usar a 'preempção', que irá derrubar e reverter para a rede primária, uma vez que a condição de falha é corrigida. Alguns fornecem configurações mais granulares que podem realmente ajustar a maioria das especificações.

Além disso, com base nos seus padrões e fluxo de tráfego, você pode carregar o compartilhamento ou o saldo da sessão entre os dois circuitos para o tráfego de saída. Isso tem o benefício de ~ 100% de saída em dois circuitos (~ 50 / ~ 50 partes) - em vez de 100% em um único circuito. Isso é roteamento assimétrico e, às vezes, não é desejado. Tudo depende dos seus objetivos e layout. Um exemplo disso são os pacotes que saem do circuito de backup, recebidos pelo cliente, mas as respostas vão para o seu DNS primário. Fora um roteador, em outro. Isso pode ser um problema ou pode ser a solução para o problema.

Isso não cuida do seu requisito secundário para o DNS, mas fornece a redundância interna.

  • Protocolo de redundância de primeiro salto (VRRP / GLBP / HSRP / CARP / NSRP, etc.)
por 04.12.2014 / 03:17