Estou trabalhando em um sistema cliente-servidor no qual todos os clientes enviam atualmente suas transações para essencialmente um único endereço IP da costa oeste para alcançar o que é chamado de aplicativo "gateway". O gateway faz alguma contabilidade e despacha cada transação para qualquer um dos vários servidores de banco de dados para processamento final. Os servidores retornam seus resultados diretamente ao cliente (não retornam pelo gateway).
O plano é adicionar um segundo gateway na costa leste, para redundância e failover. Ele normalmente só estará em stand-by, projetado para assumir o controle e se tornar o gateway real caso o gateway de trabalho falhe, essencialmente a configuração clássica ilustrado aqui .
Alguns participantes argumentam que ter apenas um gateway de espera é insuficiente, e também devemos implementar um segundo ponto de parada, digamos, no centro-oeste. Outros argumentam que o custo extra, a complexidade e a gestão de dois stand-bys são desnecessários, e que a indisponibilidade simultânea de gateways em ambas as costas é tão improvável que não é uma preocupação.
O que é considerado melhor prática? Quanta redundância (em termos de pontos de acesso fisicamente separados disponíveis para clientes) é tipicamente considerada nominal? As falhas duplas são comuns o suficiente para que ter apenas um stand-by seja freqüentemente lamentado?
EDITAR: Com relação ao "cálculo" de custo x benefício para a quantidade de redundância que preciso ou desejo, acho que é melhor reformular minha pergunta como:
Onde as estatísticas indicam a frequência com que uma coleção de endereços IP geograficamente separada é simultaneamente inacessível?
Em outras palavras, uma tabela como
On average, 1 west coast IP + 1 east cost IP
are simultaneously unreachable 1 day/year.
On average, 1 west IP + 1 east IP + 1 southern IP
are simultaneously unreachable 1 hr/year.
On average, 1 west IP + 1 east IP + 1 southern IP + 1 northern IP
are simultaneously unreachable 1 minute/year.
etc.
torna bastante fácil escolher a quantidade de redundância desejada, porque há uma base real a partir da qual calcular custos versus desempenho. (Eu acho que "simultaneamente inalcançável" tem que significar "para um número substancial de clientes espalhados aleatoriamente pelo país", já que um único cliente pode ser incapaz de acessar qualquer servidor, independentemente de quantos existirem devido à própria falha da rede local.)
No entanto, sem essa tabela, qualquer cálculo de redundância versus desempenho seria apenas adivinhação. Portanto: existem fontes de dados de disponibilidade da vida real em que esses cálculos podem ser baseados? Ou todos adivinham o que precisam e expandem conforme necessário, uma vez que descobrem que adivinharam baixo ou cortar de volta se eles adivinharam alto?
Parece que as empresas que oferecem produtos tolerantes a falhas desejam coletar e promover esses dados. Por outro lado, talvez os dados mostrem que 99,99% dos clientes tolerantes a falhas realmente não precisam de muita redundância. Por exemplo, se eu puder ir por um ano inteiro e meus endereços IP leste e oeste nunca estiverem simultaneamente inacessíveis, não vou me preocupar em adicionar um IP do meio-oeste.
Também percebo que há uma distinção entre um endereço IP inacessível devido a forças externas ao meu site e um endereço IP que está inativo porque meu site falhou internamente. Falhas internas (do meu lado do endereço IP) são relativamente fáceis de lidar. Falhas externas (no lado do cliente do endereço IP, como a Califórnia ficar off-line devido a terremotos, ou Nova York ficar off-line durante um furacão) só posso lidar com endereços IP extras em algum outro local geográfico. Essa é a probabilidade que espero quantificar. Por enquanto, estou inclinado para o acampamento que afirma que a probabilidade de endereços IP leste e oeste serem simultaneamente inacessíveis é muito pequena para se preocupar.