[EMAIL PROTECTED] wrote on 02/13/2008 11:18:34 AM: > I have read a few tutorials now. Some mention turning off highly > available services and some do not mention it. I am making 'sshd' and > 'httpd' highly available on my ha cluster. Once I have everything > configured one tutorial said to make sure that your services AND > heartbeat are configured NOT to start at boot time on both servers. I > understand this during the testing aspect but when this is ready to go > live I believe this is the way it should be: > > server1 (primary) > /etc/init.d/heartbeat (start at boot) > /etc/init.d/sshd (does not start at boot ?? ) > /etc/init.d/httpd ( does not start at boot ??) > > server2 (secondary) > /etc/init.d/heartbeat (start at boot) > /etc/init.d/sshd ( does not start at boot ) > /etc/init.d/httpd ( does not start at boot ) > > Could someone please look at my above assumptions and correct me if > I am wrong. > > I also assume that if server1 went down and server 2 became primary > that is a building wide power outage occurred that when power was > restored that server2 would still know it was primary. >
First off you don't want to make sshd an HA service or you will not be able to ssh to any node that is not the primary node. SSHD should be running on all servers at all times. We start heartbeat at boot on all of our clusters and I can't see a reason why you would not. You, of course, cannot start the services which you are making HA as they are started by heartbeat when it runs. In any failover the nodes do know their roles when they come because they talk to the cluster. How this is handled depends on your configuration. I would advise using v2 configs and letting heartbeat manage the resources. We have both v1 and v2 in our environment and while v2 is insane to set up and get working just right it is worth it in the long run. The short answer is that, in your scenario, server2 would indeed know that it is primary. _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
