Hi,

I'm not going to compare both solutions. I'm creating a cluster with 3 nodes - 
two active and a passive. Two special applications are going to work on both 
active nodes. If either of them fails it will be 'migrated' to the standby 
node. Those applications use heavily the storage device. For that purpose the 
storage device must be shared on all three machines. Each application uses its 
own part of that device (different folder or different partition). They does 
not access the same data.
Due to performance issues using NFS is not an option for me. What I need is 
exactly a way to export/import a block device over the network. There are the 
following alternatives for network block device:
- NBD - legacy, does not handle with the network failure
- BNBD - read only
- ENBD - works, but there are performance issues and again network failures are 
not handled properly. Works well with pure kernel, but not with RH or SUSE 
kernels. Not documented. Seems legacy as well. DM-multipath does not support 
ENBD devices.
- GNBD - This seems the best of the above. Supports fencing and multipath. This 
works well for me ...
... BUT GNBD requires rh cluster manager and works tightly with RH Cluster 
Suite. Needs all RHCS packages installed. Does not work on most Linux 
distributions. So, if I want to use GNBD (with whatever FS - ext3, gfs, ocfs2 - 
it does not matter) I'm forced to use RHCS on every node. 

I really like Heartbeat and got used to it but it is stupid to use Heartbeat on 
top of RHCS. Better use RHCS only.

So my question is, is there an NBD solution (an GNBD alternative) which works 
with Heartbeat? I couldn't find such. So no way for me to share a block device 
over the network in my Heartbeat cluster. I have to switch to RHCS...

Do you plan to implement/adopt such NBD and Global File System which will be 
manageable in Heartbeat? 

Any other ideas which can help me using Heartbeat instead of RHCS?

Very thanks in advance!

Regards,
Atanas 
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems

Reply via email to