On 06/21/10 8:08 PM, Greg Smith wrote:
> The hard part of shared storage failover is always solving the "shoot
> the other node in the head problem", to keep a down node from coming
> back once it's no longer the active one. In order to do that well,
> you really need to lock the now unavailable node from accessing the
> storage at the hardware level--"fencing"--with disabling its storage
> port being one way to handle that. Figure out how you're going to do
> that reliably in a way that's integrated into a proper cluster
> manager, and there's no reason you can't do this with PostgreSQL.
In my dev-lab tests of some clusters, I used the QLogic 5600 FC switch
that connects my motly collection of servers... I used RHCS for one
test, it supported the qlogic via telnet... I created two zone sets in
the qlogic, one for each state, with the standby host blocked from
accessing the LUN, and the cluster manager used telnet to talk to the
switch. I ran heartbeats over two seperate ethernets (one was the lab
LAN segment, the other was a private switch i have all the servers
connected to for various tests, and such). The qlogic switch also
had another zoneset for all sorts of other servers and storage which
wasn't affected by these clustering tests.
I don't like power cycling servers, so I'd prefer not to use power
switch based fencing, although I believe my blade box's management unit
is supported as a power fencing device.