Linux Virtual IP Options

3

Parece haver muitas opções no Linux para fornecer um IP virtual para failover entre vários hosts. Alguns que eu encontrei são batimentos cardíacos, vrrpd, carpa e keepalived.

No Linux, eu só tenho experiência com heartbeat (e usei o HSRP na Cisco). Essas várias opções têm alguma vantagem específica quando se trata de fornecer um IP virtual que será um gateway para hosts na LAN. Uma característica que gostaria de ter é a capacidade de rastrear outra interface. Por exemplo, se o IP virtual é compartilhado entre eth0 no Servidor A e eth0 no Servidor B, eu gostaria que ele fosse capaz de fazer failover para outro servidor se ele detectasse que a eth1 estava inativa. Eu também gostaria de poder definir um host preferido.

    
por Kyle Brandt 19.07.2010 / 22:23

3 respostas

2

Uma das principais vantagens que encontrei com o heartbeat foi a capacidade de personalizá-lo para ter vários pontos de monitoramento. De acordo com a configuração padrão recomendada, ele possui vários pontos de monitoramento entre o uplink serial e o monitoramento da rede.

Por exemplo, um script de recurso de heartbeat pode ser criado para monitorar um daemon e, no caso de falha do daemon, iniciar um failover.

O CARP é baseado no HSRP, que, como você identificou, monitora a interface. Isso certamente tem um lugar e eu gosto da tecnologia, mas dependendo da função do servidor, você pode achar a pulsação vantajosa.

Suponho que poderia ser argumentado que até mesmo os protocolos que não suportam isso poderiam ter um script escrito para imitar alguns dos comportamentos, que é essencialmente o que descrevi com o heartbeat.

Embora eu nunca tenha usado o keepalived, parece ser semelhante ao ldirectord, pois monitora hosts LVS e os remove do VIP em caso de falha. Eu não consideraria isso na exata mesma categoria como batimento cardíaco ou CARP.

    
por 19.07.2010 / 22:50
1

Usamos VIPs baseados em switch / balanceador de carga que usam round-robin com base em um teste de disponibilidade de serviço, como um httpget ou similar. Isso tira a carga e a responsabilidade do servidor - cada um deles acha que é o único que está respondendo. Então, para nossos clusters reais (Oracle, WebLogic, ZXTM etc.), o mesmo modelo é verdadeiro, mas o próprio aplicativo de cluster garante que os servidores estejam em contato entre si, mas os IPs voltados para o cliente ainda permanecem 'regulares'. Essencialmente, nunca encontramos um motivo para nada além de IPs "normais", mas eu estaria interessado em conhecer seu caso de uso planejado. Ah, e podemos usar o switch / LB para definir quais servidores estão dentro / fora de serviço.

    
por 19.07.2010 / 22:59
0

Failover é uma droga - você nunca sabe se funcionará até que algo falhe. Como o Chopper3, eu sempre faço o balanceamento de carga se for possível.

C.

    
por 20.07.2010 / 13:33