From: Tarkan Erimer <tarkan.erimer@turknet.net.tr>
To: linux-kernel@vger.kernel.org
Subject: Failover Kernel
Date: Thu, 26 Feb 2009 10:58:56 +0200 [thread overview]
Message-ID: <49A659D0.2040903@turknet.net.tr> (raw)
Hi all,
I'm thinking about a kernel feature called "Failover Kernel". The basic
idea is to put 2 kernels (One is running "Primary Kernel" and the next
one is "Backup Kernel") into the memory for disaster recovery of kernel
panic'ing/crashing.
This feature's working schema could be like this :
- "Backup Kernel" could be stated and loaded into the memory via a boot
line option like : "failover_kernel=/boot/vmlinuz-2.6.26"
- Primary running kernel will send keepalives to the "Backup Kernel" to
state that it's alive.
- Primary running kernel can write a journal (like the journaled
filesystems.) about needed infos for the backup kernel to recover.
- When the primary kernel crashed and couldn't send anymore keepalives,
the backup kernel will recover from this journal to proceed to where the
primary kernel left and will become primary.
- When "Backup Kernel" became "Primary" it will load the previous one as
"Backup Kernel" again or maybe it could be left to manual. User could
decide after the disaster recovery which kernel will be load as backup
via a utility like "kexec".
- At kernel compile time, user can choose the the timing for failover
kernel. For example, "Recover After 10 MS. of inactivity (not receiving
keepalives). "
The usage scenarios of this feature could be :
- For people whose Datacenter is remote, it's a big problem when you
compiled a new kernel and rebooting into a crashing/non-booting new
kernel. You left with a completely crashed and non-functioning system.
Hard reset and manual action is required. If there could be "Failover
Kernel feature, the system will simply switch back to the "Backup
Kernel" (This backup kernel will be the known stable kernel of the
system.) and the system will proceed to work without any manual action
required.
- Your system runs fine for the last several months and one day you hit
a bug and kernel crashed/panic'ed . With "Failover Kernel", the system
will switch to the "Backup Kernel" quickly (maybe some milliseconds or
few seconds.) to recover and the system could proceed to work normally.
So,I'm not a coder and I don't know it is really possible as technically
or not. You the kernel hackers, what's your opinion about it ? Could it
be really possible ? If so, how we really can implement it ?
Many thanks for reading this long (and maybe stupid) post! :-)
Tarkan ERIMER
next reply other threads:[~2009-02-26 8:59 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-02-26 8:58 Tarkan Erimer [this message]
2009-02-26 16:03 ` Failover Kernel Willy Tarreau
2009-02-27 15:25 ` Tarkan Erimer
2009-02-26 17:02 ` Diego Calleja
2009-02-27 15:32 ` Tarkan Erimer
2009-02-27 15:50 ` Lubomir Rintel
2009-03-02 16:21 ` Tarkan Erimer
2009-03-03 3:29 ` David Newall
2009-03-04 8:29 ` Tarkan Erimer
2009-03-06 1:10 ` david
2009-03-09 12:35 ` Tarkan Erimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=49A659D0.2040903@turknet.net.tr \
--to=tarkan.erimer@turknet.net.tr \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox