Nikola Savic wrote:
Digimer wrote:
First, it will rejoin the other DRBD members. These members will have a
"dirty block" list in memory which will allow them to quickly bring the
recovered server back into sync. During this time, you can bring that
node online (ie: set it primary and start accessing it via GFS2).
However, note that it can not be the sole primary device until it is
fully sync'ed.
If I understand you well, even before sync is completely done DRBD
will take care of reading and writing of dirty blocks on problematic
node that got back online? Let's say that node was down for longer time
and that synchronization can take few minutes, maybe more. If all
services start working before sync is complete, it can happen that web
applications tries to write into or read from dirty block(s). Will DRBD
take care of that? If not, is there way to suspend startup of services
(web server and similar) until sync is done?
DRBD and GFS will take care of that for you. DRBD directs reads to nodes
that are up to date until everything is in sync.
Make sure that in drbd.conf you put in a stonith parameter pointing at
your fencing agent with suitable parameters, and set the timeout to
slightly less than what you have it set in cluster.conf. That will
ensure that you are protected from the race condition where DRBD might
drop out but the node starts heartbeating between then and when the
fencing timeout occurs.
Oh, and if you are going to use DRBD there is no reason to use LVM.
Gordan
--
Linux-cluster mailing list
Linux-cluster@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/linux-cluster
