E sim eduardo, mas se comparar o fato que quando você cria uma rede 
dedicada entre os nodos, a chance de dar problema e muito pequena 
inclusive você utilizando cabo cross e placas de redes intell, e tambem 
pela questão de falta de energia que você pode ligar em nobreak distintos.
Para você resolver este problema seria você utilizar apenas uma placa de 
rede para monitorar ligada no hub que ai você não teria este problema, 
pois se falha a placa de rede o heartbeat iria reconhecer, mas se o hub 
parar da no mesmo.
Penso que isto não e problema do heartbeat, as sim de caso de estudo, 
pos imagine:
Como um servidor ira saber se o outro servidor estar no ar, sendo que a 
comunicação entre os 2 nodos caiu, por causa da placa de rede ou mesmo 
cabo cross com problemas?.
Espero ter ajudado.


Eduardo - Suporte Intranetworks escreveu:
> Gilmar,
>
>     Esse comportamento do heartbeat eu não gostei, pelo simples fato de 
> que o meu nodo master está trabalhando tranquilamente e perfeitamente, 
> maaass, se houver alguma falha de comunicação entre o nodo slave e o 
> master, o slave irá assumir, isso não é uma boa.
>
>    Eu acho que a solução seria fazer um script que evitasse esse 
> problema, com o seguinte comportamente:
>    Se o nodo slave conseguir pingar a placa de rede do nodo master (eth1 
> ligada ao switch), o nodo slave dá um stop no heartbeat, evitando-se que 
> o nodo slave assuma.
>
> Valeu!
>
> ________________________________________
> Eduardo Sachs - Suporte Intranetworks
> [EMAIL PROTECTED]
>
> Intranetworks
> Rua Marquês do Pombal 1710/805
> Porto Alegre - RS - 90540-000
> +55 51 3325-5700
>
>
>
> Gilmar Cabral escreveu:
>   
>> Eduardo e o seguinte:
>> O mon e um monitor de serviços ele não monitora se a placa de rede esta 
>> com problemas o cabo. se houver um fala na comunicação
>> o heartbeat entende que um dos nodos estão inativos pois ele envia ping 
>> de um para outro e quando para de responder a ping e onde
>> ele sobe os serviços.
>> Posso estar enganado, mas para uma falha como a de comunicação entre os 
>> servidores o heartbeat ira levandar os serviços tambem.
>>
>> Espero ter ajudado
>>
>> Eduardo Sachs escreveu:
>>   
>>     
>>> Gabriel,
>>>      Te chamei de Gabriela... me desculpe!!!
>>>
>>> Em 04/07/07, Eduardo Sachs<[EMAIL PROTECTED]> escreveu:
>>>   
>>>     
>>>       
>>>> Gabriela,
>>>>
>>>>   Sobre o MON, se a eth0 (cabo cross-over) do nodo master estiver com
>>>> problemas, o mon pode parar o heartbeat do nodo slave para não haver a
>>>> troca?
>>>>
>>>>
>>>>
>>>> Luis,
>>>>
>>>>  Sobre o ipfail, fiz alguns testes com ele e não obtive sucesso.
>>>>
>>>>  A configuração que eu fiz no ha.cf foi a seguinte:
>>>>
>>>> ping 192.168.0.1
>>>> respawn hacluster /usr/lib64/heartbeat/ipfail
>>>> apiauth ipfail gid=hacluster uid=hacluster
>>>>
>>>>  O 192.168.0.1 é o meu router.
>>>>
>>>>  Estou fazendo o correto? Ou estou ratiando com o ipfail?
>>>>
>>>>
>>>>  Eu pensei em fazer um script que faria o seguinte, quando o nodo
>>>> slave rodar o haresources, ele verifica se a placa de rede (eth1 e
>>>> eth1:0 -> (IPaddr) - ligada ao switch) do nodo master está OK, se
>>>> estiver OK, o nodo slave obrigatoriamente irá dar um STOP no serviço
>>>> do Heartbeat.
>>>>
>>>>  Mas, eu queria uma solução pronta, tipo o ipfail.
>>>>
>>>>
>>>> Valeu!
>>>>
>>>> Em 04/07/07, Luis Claudio R. Goncalves<[EMAIL PROTECTED]> escreveu:
>>>>     
>>>>       
>>>>         
>>>>> Minha sugestão é enviar os heartbeats tanto pela eth0 quanto pela eth1.
>>>>> Somente se as duas conexões falharem o nodo é consideredo inativo.
>>>>>
>>>>> No heartbeat existe um aplicativo (que usa a api do heartbeat) chamado
>>>>> ipfail, que testa conectividade para pontos definidos (ping nodes) e,
>>>>> dependendo da resposta, pede ao heartbeat para fazer um failover.
>>>>>
>>>>> Luis
>>>>>
>>>>> On Wed, Jul 04, 2007 at 09:50:21AM -0300, Gabriel Medina wrote:
>>>>> | Eduardo,
>>>>> |
>>>>> | Você pode também utilizar um script para verificar a conexao de rede, 
>>>>> algo
>>>>> | como um fping no gateway ou melhor, usar o ethtool para verificar os 
>>>>> links
>>>>> | das interfaces.
>>>>> | Você pode adotar a estratégia de usar algo como o monitor (mon) para 
>>>>> fazer
>>>>> | isso e, dependendo do que você quer, usar o mon para parar o heartbeat.
>>>>> | Espero ter ajudado.
>>>>> |
>>>>> | Abraço
>>>>> |
>>>>> | Em 04/07/07, Gilmar Cabral <[EMAIL PROTECTED]> escreveu:
>>>>> | >
>>>>> | >Bom se alguem cortar o cabo realmente você ira ter 2 servidores 
>>>>> masters.
>>>>> | >Mas você tem 3 auternativa para evitar ou ficar sabendo se deu
>>>>> | >problemas. a primeira dela e verificar os logs diariamente, a segunda e
>>>>> | >você criar um script que quando o heartbeat for levantar o serviços no
>>>>> | >haresources você coloca um script que envia uma mensagem para sua rede
>>>>> | >informando que o servidor tal esta ativo ou desativo.
>>>>> | >Imagine o seguinte o heartbeat utiliza uma rede para comunicação, ele
>>>>> | >não ira saber se o cabo pifou ou a placa de rede pifou sendo que a
>>>>> | >comunicação e feita atraves de uma rede dedicada.
>>>>> | >Espero ter ajudado.
>>>>> | >
>>>>> | >
>>>>> | >Eduardo Sachs escreveu:
>>>>> | >> Pessoal, tudo bem?
>>>>> | >>
>>>>> | >>     Vou explicar como está a minha estrutura.
>>>>> | >>
>>>>> | >>     NODO1 (eth0) <--------------------------------------> (eth0) 
>>>>> NODO2
>>>>> | >>     NODO1 (eth1) <------------SWITCH------------> (eth1) NODO2
>>>>> | >>
>>>>> | >>     Eu tenho um cabo cross-over ligado entre os dois nodos, na eth0.
>>>>> | >>     E a eth1 fica ligado direto no Switch.
>>>>> | >>
>>>>> | >>     Mas, se houver problemas na eth0, por exemplo, alguem corta o 
>>>>> cabo
>>>>> | >> da ETH0, ou, a placa de rede da eth0 estraga.
>>>>> | >>
>>>>> | >>     Vai acontecer que, o nodo slave vai assumir, mas na verade o nodo
>>>>> | >> master está funcionando perfeitamente. Vai haver uma troca
>>>>> | >> desnecessaria, o que eu faço nessa situação?
>>>>> | >>
>>>>> | >>
>>>>> | >>  Valeu!!!!!!!!!!
>>>>> | >>
>>>>> | >>
>>>>> | >
>>>>> | >_______________________________________________
>>>>> | >Linux-HA mailing list
>>>>> | >[email protected]
>>>>> | >http://listas.linuxchix.org.br/mailman/listinfo/linux-ha
>>>>> | >
>>>>> |
>>>>> |
>>>>> |
>>>>> | --
>>>>> | Gabriel Medina Pegoraro
>>>>> | [EMAIL PROTECTED]
>>>>> | [CheckBox] - www.checkbox.com.br
>>>>>
>>>>> | _______________________________________________
>>>>> | Linux-HA mailing list
>>>>> | [email protected]
>>>>> | http://listas.linuxchix.org.br/mailman/listinfo/linux-ha
>>>>>
>>>>> ---end quoted text---
>>>>>
>>>>> --
>>>>> [ Luis Claudio R. Goncalves                   lclaudio at uudg dot org ]
>>>>> [ Fingerprint:   4FDD B8C4 3C59 34BD 8BE9  2696 7203 D980 A448 C8F8    ]
>>>>> [ Linux-HA Developer - LateNite Programmer - Gospel User - Bass Player ]
>>>>> [ Fault Tolerance - Real-Time - Distributed Systems - IECLB - Is 40:31 ]
>>>>>
>>>>>
>>>>>       
>>>>>         
>>>>>           
>   

_______________________________________________
Linux-HA mailing list
[email protected]
http://listas.linuxchix.org.br/mailman/listinfo/linux-ha

Responder a