Pergunta de configuração global de alta disponibilidade

Question

Eu possuo e opero visualwebsiteoptimizer.com /. O aplicativo fornece um snippet de código que meus clientes inserem em seus sites para acompanhar determinadas métricas. Como o snippet de código é JavaScript externo (na parte superior do código do site), antes de mostrar um site do cliente, o navegador de um visitante entra em contato com o nosso servidor de aplicativos. Caso o nosso servidor de aplicativos fique inativo, o navegador continuará tentando estabelecer a conexão antes que ela atinja o tempo limite (normalmente 60 segundos). Como você pode imaginar, não podemos nos dar ao luxo de ter nosso servidor de aplicativos em baixo em qualquer cenário, pois isso afetará negativamente a experiência de não apenas os visitantes do nosso site, mas também os visitantes do site de nossos clientes!

No momento, estamos usando o mecanismo de failover do DNS com um servidor de backup localizado em um data center diferente (continente realmente diferente). Ou seja, monitoramos nosso servidor de aplicativos de três locais diferentes e, assim que é detectado, desativamos o registro A para apontar para o IP do servidor de backup. Isso funciona bem para a maioria dos navegadores (como o nosso TTL é de 2 minutos), mas o IE armazena em cache o DNS por 30 minutos, o que pode ser um assassino de acordo. Veja este post recente do nosso visualwebsiteoptimizer.com/split-testing -blog / tempo de inatividade máximo-teórico-para-um-site-30-minutos /

Então, que tipo de configuração podemos usar para garantir um failover quase instantâneo caso o data center do aplicativo sofra uma interrupção maior? Eu li aqui www.tenereillo.com/GSLBPageOfShame.htm que ter vários registros A é uma solução, mas não podemos pagar sincronização de sessão (ainda). Outra estratégia que estamos explorando é ter dois registros A, um apontando para o servidor de aplicativos e outro para um proxy reverso (localizado em um datacenter diferente) que resolve para o servidor de aplicativos principal se estiver ativo e para o servidor de backup se estiver ativo. Você acha que essa estratégia é razoável?

Só para ter a certeza das nossas prioridades, podemos manter o nosso próprio site ou aplicativo, mas não podemos deixar o site dos clientes ficar mais lento devido ao tempo de inatividade. Portanto, caso nossos servidores de aplicativos estejam inativos, não pretendemos responder com a resposta padrão do aplicativo. Mesmo uma resposta em branco será suficiente, basta que o navegador complete essa conexão HTTP (e nada mais).

Referência: eu li este tópico que foi útil serverfault.com/questions/69870/multiple-data-centers-and-http-traffic-dns-round-robin-e-only-way-to-assure

    

Answer 1

Sua situação é bastante semelhante à nossa. Queremos datacenters divididos e failover do tipo de camada de rede.

Se você tiver orçamento para isso, o que você deseja são dois datacenters, vários IP transits para cada um, um par de roteadores de borda fazendo sessões BGP para seus provedores de trânsito, anunciando seus endereços IP para a Internet global .

Esta é a única maneira de fazer o verdadeiro failover. Quando os roteadores percebem que a rota para seus servidores não é mais válida (o que você pode fazer de várias maneiras), eles param de anunciar essa rota e o tráfego vai para o outro site.

O problema é que, para um par de roteadores de borda, você está olhando para um custo bastante alto inicialmente para obter essa configuração.
Então você precisa configurar a rede por trás de tudo isso, e você pode querer considerar algum tipo de conectividade Layer2 entre seus sites como um link ponto-a-ponto para que você possa rotear o tráfego de entrada para um datacenter, diretamente para o outro em caso de falha parcial do seu site principal.

Práticas recomendadas BGP Multihomed / Multi-localização e Melhor forma de melhorar a resiliência? são perguntas que fiz sobre problemas semelhantes.

A página de vergonha do GSLB levanta alguns pontos importantes, e é por isso que, pessoalmente, eu nunca escolheria de bom grado um GSLB para fazer o trabalho de roteamento do BGP.

Você também deve olhar para os outros pontos de falha em sua rede. Certifique-se de que todos os servidores tenham 2 NICs (conectadas a 2 switches separados), 2 PSUs e que seu serviço seja composto de vários servidores de back-end, como pares redundantes ou clusters com balanceamento de carga.

Basicamente, o "balanceamento de carga" do DNS através de vários registros A é apenas "compartilhamento de carga", pois o servidor DNS não tem noção de quanto de carga há em cada servidor. Isso é barato (grátis).

Um serviço GSLB tem algum conceito de como os servidores estão carregados, e sua disponibilidade, além de oferecer maior resistência a falhas, mas ainda é atormentado pelos problemas relacionados ao cache de DNS e ao rastreio. Isso é menos barato, mas um pouco melhor.

Uma rede roteada BGP, apoiada por uma infraestrutura sólida, é IMHO, a única maneira de realmente garantir um bom tempo de atividade. Você poderia economizar algum dinheiro usando servidores de rota em vez de roteadores Cisco / Juniper / etc, mas no final do dia, você precisa gerenciar esses servidores com muito cuidado. Esta não é de forma alguma uma opção barata, ou algo a ser empreendido de ânimo leve, mas é uma solução muito gratificante, e traz você para a internet como um provedor, ao invés de apenas um consumidor.

    

Answer 2

OK, isso foi perguntado há algum tempo, mas estou vendo pela primeira vez agora.

the code snippet is external JavaScript (at the top of site code), before showing a customer website, a visitor's browser contacts our app server.

Você deve:

1. Coloque seu arquivo Javascript em uma boa e profissional Rede de Entrega de Conteúdo, ou seja, compre HTTP (S) altamente disponível que atenda ao Javascript de alguém que já tenha essa experiência.
2. Programe seu Javascript para que haja um bom estado de fallback, ou seja, se o servidor de aplicativos não responder rapidamente, o usuário final verá uma página normal e sem modificações.

Fazer qualquer outra coisa é irresponsável, na verdade. Eu suponho que você já tem isso no lugar.

Você deve não basear seu serviço em truques de roteamento BGP, a menos que você tenha ou obtenha o conhecimento para fazê-lo. Cenários complexos de roteamento BGP são decididamente não-triviais de implementar; não faça isso sozinho se você não tiver o conhecimento específico do domínio.

Sua pergunta em si é um pouco confusa. A análise de como criar um serviço altamente disponível começa com os dados do aplicativo , porque esse é o seu "estado". As partes sem estado são fáceis de tornar altamente disponíveis, as partes completas do estado não são. Então, ao invés de focar em seus servidores e DNS, veja onde seu aplicativo mantém o estado . Comece otimizando lá e, possivelmente, solicitando conselhos de algoritmo no Stack Overflow. Você poderia implementar uma noção de transações e uma nova tentativa do servidor inteligente em seu arquivo JavaScript fx?

    

Answer 3

Na verdade, o que você deseja pode ser atualizado para ajudar suas atividades de teste de divisão também se você combinar geodns e failover de dns.

O envio do grupo A para o ip 1 e do grupo B para o ip 2, mesmo se estivessem no mesmo servidor, permitiria que você separasse seus grupos de teste. Grupo A e Grupo B são de diferentes regiões geográficas. Para ser justo, no dia seguinte / semana / mês, você inverte os grupos para garantir diferenças geográficas. Apenas para ser rigoroso em sua metodologia.

O serviço geodns / failover dns no link pode fazer isso

divulgação: eu estou associado com o link acima, tropeçou aqui pesquisando um artigo sobre a aplicação de truques de dns estúpidos para dividir o teste.