Res: anyone aware of a high availability setup that relies on fully redundant install?

[Daniel]

‎This depends on environment proposes. It,s aways a good thing to have a recovery boot option that can boot a minimum shell to dignoses whats going wrong but a full instalation for that is even useful?? IMHO is not a good idea, since you will have to maintain two instalations per hardware. 
‎
You may be looking for something like update rollback.  I know that yum does this and that smart package manager has this feature two, but I never tested it neither one :)

Other option is rely on filesystem for such thing. btrfs has some nice snapshot features, you may want to take a look. 

For recovery boot option you can have a network boot, loading a complete distinct kernel and rootfs that can be chrooted to in drive instalation for recovery when everything goes wrong. Also, the "remote system" can be maintained independently of host instalation. With RO rootfs you can even boot multiple machines with same kernel/rootfs simultaneously, and maintain one recovery installation for multiple "host machines". The better aproach depends on your enviroment, what you have avaible for recovery and how you want to proceed when something goes wrong.

Regards
‎
Enviado do meu smartphone BlackBerry 10.
  Mensagem original  
De: Robert P. J. Day
Enviada: domingo, 17 de abril de 2016 11:48
Para: Kernel Newbies
Assunto: anyone aware of a high availability setup that relies on fully redundant install?


i figure this is as good a place as any to ask ... is anyone here
aware of anyone using a linux config and install that, for the
purposes of reliability or high availability or whatever you want to
call it, relies on a second, completely independent installation of
linux on the same hard drive?

i was having a discussion about the reliability of upgrading linux
(any combination of kernel, basic rootfs and/or proprietary apps), and
one approach that was suggested (not by me) was to have two entirely
independent installations on the same hard drive so that, when one
"upgraded" the system, the newer content was installed in the other
partition and the system rebooted to that newer content, the rationale
being that, if the upgraded system didn't work, one could revert back
to the original install.

the history of this particular approach lies in the fact that the
original S/W running on the system in question was an embedded app
programmed right on bare metal, so the entire app was basically a
monolithic combination of boot loader, kernel and all the apps. in
that case, i can certainly see how one wanted a reliable way to revert
back to a known working system if the new S/W had flaws. but i don't
think that logic holds with a linux installation.

the major concern seems to be a fear that, if one upgrades the
kernel even a little bit, user space apps might suddenly stop working
because of some new incompatibility introduced by that upgrade. i'm
well aware of gregkh's piece on kernel stable API nonsense:

https://www.kernel.org/doc/Documentation/stable_api_nonsense.txt

so i'm not overly worried, but folks in the discussion coming from the
embedded programming space are using their experiences from that space
to argue that a fully redundant install is the safest approach just in
case something goes wrong with an upgrade.

not surprisingly, my position is that this is not something they
need to worry about a whole lot but, for the sake of fairness, i
thought i'd look around to see if any linux folks *are* using that
approach.

anyone? thoughts?

rday

-- 

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

Twitter: http://twitter.com/rpjday
LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================



_______________________________________________
Kernelnewbies mailing list
Kernelnewbies at kernelnewbies.org
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies