Espelhos de nó - ou é balanceamento de carga ou proxy reverso?

Question

Se você tem uma solução, de preferência de código aberto, é claro (!), eu estaria interessado em saber, mas na verdade estou querendo saber a terminologia correta.

O dispositivo em que estou pensando é um tradutor de endereço (como o NAT) que recebe a solicitação de uma URL e a responde de seu cache ou de uma das possíveis máquinas servidoras.

Se houver uma gravação (uma solicitação POST), esse dispositivo a enviará a todos os servidores.

Assim, todos os servidores podem estar no mesmo estado, sem necessidade de sincronização. Se um nó falhar, o (s) nó (s) restante (s) estará (ão) no mesmo estado, então poderá responder com pedidos.

Então, como um diagrama:

Client -> read -> device -> Server A/B (load balancing) or from cache


                                     ->  Server A
Client -> write (POST url) -> device ->  Server B
                                     ->  Server N

Todos os servidores recebem as mesmas gravações para que os servidores A, B, ... N estejam exatamente no mesmo estado (se estiverem em execução).

Qualquer servidor ou cache pode responder a uma leitura.

As perguntas:

• Como este dispositivo é chamado?
• É fácil configurar com o Apache / Squid? - se sim, onde está o guia de um idiota?
• Isso faz com que o dispositivo em si, o SPOF (ponto único de falha), como você configura então você tem dois dispositivos independentes fazendo isso para que, se um falhar, o outro assumirá sem problemas?

Answer 1

A solução comercial, proprietária e um pouco cara: troca de conteúdo CISCO
A CISCO tem uma linha de produtos denominada Content Service Switches (seus serviços de conteúdo) (os seus serviços são: CSS série 11500 ). Com base na sua pergunta, isso chega perto do que você está procurando. Os termos que eles usam (e você pode usá-los no Google para produtos semelhantes) são "troca de conteúdo" ou "alternância de aplicativos".

(não usei esses dispositivos na vida real nem sou afiliado de alguma forma à Cisco)

Projeto de alta disponibilidade principes: Mantenha-o simples
Na minha opinião, há um ponto fraco em seu diagrama e essa é a gravação ( POST ) para todos os servidores. Você confia no "dispositivo" para sincronizar todas as instâncias do servidor (Apache, pastas NSF, banco de dados, etc.). Isso introduz um novo SPoF (o próprio dispositivo, como você já percebeu) e adiciona a complexidade da sincronização. Se um dos servidores estiver (temporariamente) indisponível, quem é responsável pela nova sincronização? O servidor em si ou o "dispositivo"?

Um padrão melhor é colocar a responsabilidade de failover / alta disponibilidade dentro da própria infraestrutura:

• em um nível de hardware (RAID, hardware redundante, vários caminhos de rede, etc.),
• no nível do sistema operacional (no Linux: Heartbeat : a camada de mensagens do cluster, Pacemaker : o gerenciador de recursos do cluster e Cluster Glue : as ferramentas de gerenciamento de cluster) e
• no nível do aplicativo. Por exemplo, o Apache tinha várias opções, como Camel , todas as plataformas de banco de dados vêm com opções de clustering e NSF .

Alto servidor LAMP de failover disponível
Eu acho que para um MediaWiki a solução geral é construir um LAMP de failover de alta disponibilidade. Se você usa o Google nesses termos, muitas soluções são exibidas, como descrito neste artigo e um ótimo esquema de uma alta configuração de LAMP disponível aqui em serverfault .