Note: "permalinks" may not be as permanent as we would like,
direct links of old sources may well be a few messages off.
ha at buglecreek.com wrote: > I have the following: > Two node cluster each running Fedora release 8 Kernel 2.6.23.8-63.fc8 > Heartbeat-2.1.2-2.fc8 (RPM) > drbd-8.0.8 - Installed from source > drbdlinks-1.09-1 (RPM) > > We use this cluster for our intranet server and the drbd resource has > both apache and mysql installed on it. We are required to upgrade our > kernel due to local security policy. This will be done via a standard > yum update. Reading through the drbd docs I see the following: "Note > that any kernel upgrade will require you to rebuild and reinstall the > DRBD kernel module to match the new kernel." I did not do the original > install of this cluster, so I'm a little vague on how to proceed. I am > not clear on what has to be done to upgrade the km. Do I stop heratbeat > on both systems, upgrade the kernel, recompile the drbd software and > start heartbeat again? Repeat on other node. V1 (haresources) or V2 (cib.xml) cluster? > Also, does anything have to be unmounted for all this not to break > something? Since this is a heavily used server, I > would hate to render the service unusable due to this upgrade? Any > insight would be appreciated. This will propably help you: http://lists.linbit.com/pipermail/drbd-user/2008-March/008915.html Understood that procedure, taking heartbeat into account I'd go like this: Assumed start situation: A: primary B: secondary B: * stop heartbeat * make sure heartbeat does NOT start during boot * install new kernel + kernel sources * build drbd module against that source * reboot into the new kernel * load drbd module, connect drbd resources manually, let them sync, see * if that works as expected now depending on R1 or R2 clusters: * R1: ** start heartbeat * R2: ** /etc/init.d/drbd stop (disconnect resources and unload drbd module) ** start heartbeat independent of version: * re-insert (if it was inserted before) heartbeat into the boot process Now force a failover by migrating the resource, making A standby or just shutdown heartbeat on A. Now your resources should run on B and situation should be A: secondary (or offline depending on what you did) B: primary * Then repeat steps on node A. Comments, improvements appreciated. This should go into the docs somewhere when it's considered safe and "correct". Regards Dominik