Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
On 12/01/2011 02:13 PM, Lars Ellenberg wrote: > On Thu, Dec 01, 2011 at 01:58:15PM -0500, Kushnir, Michael (NIH/NLM/LHC) [C] wrote: >> Hi Lars, >> >> I'm a bit confused by this discussion. Can you please clarify the difference? >> >> What I think you are saying is: >> >> OK: >> Dual-primary DRBD -> cluster aware something (OCFS, GFS, clvmd, etc...) -> exported via iSCSI on both nodes -> multipathed on the client > > No. > > OK: > Dual-primary DRBD (done right) -> cluster aware something (OCFS, GFS, clvmd, etc...) > > NOT OK: > -> exported via iSCSI on both nodes -> multipathed on the client > > NOT OK: > anything non-cluster-aware using it "concurrently" on both nodes. What I've done in the past, and perhaps it isn't the wisest (Lars, Florian?), is to create a Dual-primary DRBD (with fencing!), then export it as-is to my nodes using a floating/virtual IP address managed by a simple cluster. Then on the clients (all of whom are in the same cluster), I mount the iSCSI target and set it up as a clustered LVM PV/VG/LVs. If you need a normal FS, then format one or more of the LVs using a cluster-aware FS. When the primary node (the one with the floating IP) fails, all the cluster has to do is move the IP down to the backup node and it's ready to go. I suppose you could just as easily do Primary/Secondary and include the promotion of the backup to primary as part of the failover, too. In my case, knowing I had fencing in place already, I went for the "simpler" cluster config of managing an IP only. Caveat - I did not read the thread before now. If this is totally out to left field, my apologies. :) -- Digimer E-Mail: digimer at alteeve.com Freenode handle: digimer Papers and Projects: http://alteeve.com Node Assassin: http://nodeassassin.org "omg my singularity battery is dead again. stupid hawking radiation." - epitron