Pergunta de configuração de alta disponibilidade global

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

Atualmente, estamos usando o mecanismo de failover de DNS com um servidor de backup localizado em um data center diferente (na verdade, continente diferente). Ou seja, monitoramos nosso servidor de aplicativos a partir de 3 locais separados e, assim que for detectado como inativo, alteramos o registro A para apontar para o IP do servidor de backup. Isso funciona bem para a maioria dos navegadores (como nosso TTL é de 2 minutos), mas o IE armazena em cache o DNS por 30 minutos, o que pode ser um grande negócio. Consulte esta publicação recente visualwebsiteoptimizer.com/split-testing-blog/maximum-theoretical-downtime-for-a-website-30-minutes/

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

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

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

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

Se você tem o orçamento para fazer isso, então o que você quer são dois datacenters, vários trânsitos de IP para cada um, um par de roteadores de borda fazendo sessões de BGP para seus provedores de transporte público, anunciando seus endereços IP na Internet global.

Essa é a única maneira de realizar um failover verdadeiro. 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á procurando um custo bastante alto inicialmente para obter essa configuração.
Então, você precisa configurar a rede por trás de tudo isso e pode considerar algum tipo de conectividade da Camada 2 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 site principal.

Melhores práticas de BGP com hospedagem múltipla / vários locais e a melhor maneira de melhorar a resiliência? são perguntas que eu fiz sobre questões semelhantes.

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

Você também deve examinar os outros pontos de falha na sua rede. Verifique se todos os servidores têm 2 NICs (conectadas a 2 comutadores separados), 2 PSUs e se o seu serviço é composto por vários servidores back-end, como pares redundantes ou clusters com balanceamento de carga.

Basicamente, o "balanceamento de carga" do DNS por meio de vários registros A é apenas "compartilhamento de carga", pois o servidor DNS não tem noção de quanta 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 armazenamento em cache e vinculação de DNS. Isso é menos barato, mas um pouco melhor.

Uma rede roteada BGP, apoiada por uma infraestrutura sólida, é o IMHO, a única maneira de garantir realmente um bom tempo de atividade. Você pode 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. Isso não é de forma alguma uma opção barata, ou algo a ser empreendido de ânimo leve, mas é uma solução muito gratificante e leva você à Internet como um provedor, em vez de apenas um consumidor.

OK, isso foi perguntado há um tempo atrás, mas eu estou vendo isso agora.

o snippet de código é JavaScript externo (na parte superior do código do site). Antes de mostrar o site de um cliente, o navegador de um visitante entra em contato com o servidor de aplicativos.

Você deve:

1. Coloque seu arquivo Javascript em uma rede de entrega de conteúdo profissional e boa, ou seja, compre uma veiculação HTTP (S) altamente disponível do Javascript de alguém que já tenha esse conhecimento.
2. Programe seu Javascript para que haja um bom estado de fallback, ou seja, se o servidor do aplicativo não responder rapidamente, o usuário final verá uma página normal e não modificada.

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

Você não deve basear seu serviço em truques de roteamento BGP, a menos que tenha ou obtenha o know-how para fazê-lo. Cenários complexos de roteamento BGP são decididamente não triviais de implementar; não faça isso você mesmo se 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 com estado total não são. Portanto, em vez de focar nos servidores e no DNS, observe onde o aplicativo mantém o estado . Comece otimizando lá e, possivelmente, solicitando conselhos sobre algoritmos no Stack Overflow. Você poderia implementar uma noção de transações e tentar novamente o servidor inteligente no seu arquivo Javascript fx?

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

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

O serviço dns geodns / failover em http://edgedirector.com pode fazer isso

divulgação: estou associado ao link acima, deparei-me aqui pesquisando um artigo sobre a aplicação de truques estúpidos de DNS para dividir testes.