Re: Failover Kernel

[Tarkan Erimer <tarkan.erimer@turknet.net.tr>]

Willy Tarreau wrote:
> You forgot the most important thing : these two kernels will run on
> the same machine. I'm not even considering how you intend to schedule
> them. However, when a kernel crashes, it's often because of a hard
>   
A similar way as "kdump" did. Just putting a backup kernel into the 
memory and receiving keepalives by primary kernel. In normal conditions, 
backup kernel just will sit in its place, will monitor the status of 
primary kernel (alive or crashed) and will do nothing else more. So, no 
scheduling is required.
> error : bug in a driver, memory corruption, etc...  You cannot sanely
> recover from that. If the driver which crashed started to initiate a
> multi-word command to the device, in a lot of situations you'll need
> a reset to restore it in a known state. Memory corruption is even
> worse, as you cannot even trust the backup kernel.
>
>   
Hardware related issues are exceptions. If there could be a journal; 
maybe, it could be possible to recover sanely where the primary left. Of 
course, it's clear that this system will not work for all the scenarios 
(like bad hardware etc.).
> I'm currently using a backup kernel in our products, and do it with
> the boot loader. Some BIOSes allow you to start a watchdog timer on
> boot. Grub tries to load the first image, otherwise the second one.
> If either image crashes during boot, the hardware watchdog triggers
> and the machine reboots to the other image. That's extremely reliable,
> and relatively simple.
>  
> And using this method, you don't have any compatibility problems between
> your primary and secondary kernels.
>   
Yep, it's very simple way. But the problem is that, as you mentioned, 
watchdog is not supported on all the hardwares. If possible to 
implement, it will be platform/hardware independent system.