This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [Xen-users] Xen clustering

To: Xen-users@xxxxxxxxxxxxxxxxxxx, mshoosh@xxxxxxxxxxxxxxx
Subject: Re: [Xen-users] Xen clustering
From: "Sebastian Reitenbach" <sebastia@xxxxxxxxxxxxxxxxxxxx>
Date: Fri, 02 Nov 2007 12:03:02 +0100
Delivery-date: Fri, 02 Nov 2007 04:03:48 -0700
Envelope-to: www-data@xxxxxxxxxxxxxxxxxx
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/cgi-bin/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
Organization: L00 bugdead prods.
Reply-to: Sebastian Reitenbach <sebastia@xxxxxxxxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx

sadegh <mshoosh@xxxxxxxxxxxxxxx> wrote: 
> Nico Kadel-Garcia wrote:
> > sadegh wrote:
> >>
> >> Hi All,
> >>    well , if  we  say  FailOver mechanism is stop one and restart 
> >> another node it is true but if FailOver definition is  Migration from 
> >> one node to another.
> >> What is your idea about it?
> > Slow down a moment. Failover means different things to different 
> > people. A full so-called "High Availability" solution, where each 
> > individual component can fail but the rest automatically switch the 
> > resources they're using, is useful sometimes but seriously expensive 
> > to implement, and the switchover mechanisms themselves create their 
> > own uncertainties.
> Yes , i mean if we can freeze all of a context  (context of processes of 
> OS on a VM) on the shared storage for Live-Migration  because of  VMM is 
> here then  if  some fault occurs migration to other host is practicable 
> is it?
> >> increasing redundant hardwares is it?
> > It's part of an integrated solution. The redundant hardware has to be 
> > cross-wired in usable failover setups for individual setups. Xen can 
> > be a very useful component for this, because the potentially more 
> > reliable centralized storage system can be made extremely robust and 
> > the servers swap domains as necessary to other working hardware.
> migrating to another non-utilized host (with some mechanisms) decreasing 
> redundancy not all redundancy is it?
> >> and if we have proactive fault detection mechanism we can do it.
> > Yes, but there are limits to this. Janitors blow fuses: cage monkeys 
> > accidentally crimp fiber, or disconnect idle connections. And hard 
> > drives fail without any warning whatsoever, even a few at a time. 
> > There's a white paper from Google on this I highly recommend, where 
> > roughly 30% of the drives fail without any SMART detection at all.
> hmmm. yes.
> >> some related works exist.
> >> My thesis is about this subject "Improving Survivability of  HA 
> >> Clusters" (that Mission-Critical apps. runs on...)
> >> if any body help me to Hacking Xen, heartbeat and implementing some 
> >> other tools and compare results we can  publishing some Papers about 
> >> this and have friendly work group!
> >> I am ready to contribute and very appreciate.
> >> Best Regards
> >> Sadegh
> > Ohhhh. Cool. It's not clear how much you need Xen for this, as much as 
> > integration of Xen with the available approaches.
> i think the above words is clear
> thank you
I am just sitting here, try to update the Xen OCF script from linux-ha, to 
add some xm mem-set statements to start, stop, migrate_, ... functions.

I'll see how far I get today, but you can contact me offlist if you want to 
get my updated script for tests.


Xen-users mailing list

<Prev in Thread] Current Thread [Next in Thread>