O problema não é exatamente com o arp, o problema é assim: O VIP tem o endereço 192.168.10.1 Os RIPs tem os endereços 192.168.10.2 e 192.168.10.3 (1 dos RIPs faz o papel do VIP, é ai que entra o heartbeat alternando o serviço entre os servidores disponíveis).
uma vez que todos os endereços estão na mesma rede o método utilizado no LVS deve ser o DR (direct routing), e nesse caso cada RIP deve ter uma interface respondendo pelo mesmo endereço do VIP ou a única maquina que receberá os pacotes será a máquina que tiver a verdadeira interface do VIP. tendo em vista que o MAC address fica armazenado na tabela ARP, a máquina cliente armazena o endereço da última máquina que respondeu pelo endereço do VIP, por isso é necessário esconder as interfaces dos RIPS que não executam o VIP. (vale ressaltar que nesse caso é recomendado usar interfaces lo, dummy, tun ou interface ethernet que não esteja em uso pois toda a interface será escondida do ARP, não só o alias). bom, isso foi o que eu entendi pelas documentações que li. []'s obs: como eu quero fazer balanceamento de carga do XDMCP (e não existe suporte pronto para esse protocolo no ldirectord), criei um pequeno servidor web em python que tem como tarefa verificar a existência do processo do kdm e se ele escuta na porta 177, sendo assim posso usar o protocolo http como método de monitoração dos hosts no ldirectord. Flavio Menezes Reis wrote: > Mas foi exatamente isto que eu quis dizer anteriormente, acho que > posso não ter sido claro. É que não estou percebendo onde o problema > do arp pode afetar clusters para alta disponibilidade, pois parece-me > ser um problema inerente para clusters para balanceamento de carga. > > []´s > _______________________________________________ Linux-HA mailing list [email protected] http://listas.linuxchix.org.br/mailman/listinfo/linux-ha
