Re: Anything Like Solaris' Live Upgrade?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]



On 01/28/2013 07:55 PM, Karanbir Singh wrote:
> On 01/28/2013 06:54 PM, Tim Evans wrote:
>> It creates one or more "alternate boot environment(s)," then newfs's it,
>
> This is redundant on CentOS
>
>> mounts it, copies the running system to it, then applies
>> upgrades/patches to it.  It does not touch the running environment
>
> not true, you have severe performance loss and no reliable way to
> measure the impact of what that changeset is going to bring in. Patching
> the running system, with a failback option is far better. Unless you
> dont trust the platform at all. Lack of a reasonable manageable and
> predictable packaging system can cause that lack of trust.
>
>> (except to create a housekeeping database for the multiple boot
>> environments).  The target boot environment is made bootable, and the
>
> the idea of bootable on Linux is limited to the kernel and the initrd (
> which even has a shell ). Unless you installed a kernel in the
> transactino set, there is no need to update grub, since your existing
> running boot components are still intact ( if not, you can measure and
> handle it ). If you do update the kernel, the setup will retain multiple
> copies and your last running kernel is always retained as an option to
> boot from next boot cycle
>
>> grub configuration is updated to include the second bootable
>> environment, and the /etc/fstab file on the second environment is
>> modified to reflect the disks/LV's it uses.
>
> Take a look at the yum lvm plugin, it already does most of this - with
> some assumptions on what its going to snapshot and how you want to
> handle that.
>
>> The whole idea is not to touch the running system, apply changes to the
>> alternate system, then boot to the alternate when change is done. Once
>> the reboot to the new environment is done, you can further use LU to
>> replace the un-upgraded/un-patched original environment with a copy of
>> the new one.
>
> This kind of highlights the issue here, you are attempting to look at
> this with too far a solaris process mindset. Most CentOS best-practises
> are driven towards keeping a running system up, by not breaking it or
> needing to do downtime efforts. Some packages due to their nature will
> enforce this, like glibc; but on the whole, its considered acceptable to
> patch live and keep going, with the understanding that there is a
> failover option / failback opton, rather than assume a running system
> must be taken down for a patch to be applied.
>
> There are exceptions, but most of them are niche implementation driven
> ones, on the whole CentOS is built to be patched in place. Take a look
> at the yum lvm plugin on how you can fairly-easily implement the extra
> step you mentioned ( i.e tweak fstab to boot from a diff lv / uuid ).
>

Thanks to everyone for their replies.  I suppose it's not possible in 
this forum to ask such a question and not get into religion. Kinda like 
the U.S. Congress.

No one has yet shown how a byte-for-byte, fully redundant, bootable 
disk(set) can be created and kept up to date that will allow immediate 
recovery from a catastrophic failure of the primary disk(set) with 
nothing more than a reboot.

FWIW, Solaris' problems are not technical.  Rather, they're Oracle's 
licensing and support policies that have essentially fired all its small 
system customers.

-- 
Tim Evans			|   5 Chestnut Court
Linux/UNIX Consulting		|   Owings Mills, MD 21117
http://www.tkevans.com/		|   443-394-3864
http://www.come-here.com/News/	|   tkevans@xxxxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos


[Index of Archives]     [CentOS]     [CentOS Announce]     [CentOS Development]     [CentOS ARM Devel]     [CentOS Docs]     [CentOS Virtualization]     [Carrier Grade Linux]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Linux USB]
  Powered by Linux