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

Re: [Xen-users] Xen and iSCSI


Am Montag, 30. Januar 2006 07:55 schrieb Pasi Kärkkäinen:
> On Mon, Jan 30, 2006 at 12:47:50AM +0100, Markus Hochholdinger wrote:
> > Am Sonntag, 29. Januar 2006 22:04 schrieb Pasi Kärkkäinen:
> > > In fact, even better would be to do the RAID in the storage arrays /
> > > servers (=iSCSI targets), and provide multiple paths to the targets..
> > > using separate network (switch) for both paths.
> > > In the dom0 you would only set up multipath device to the shared RAID
> > > array (over iSCSI), and then create CLVM on top of that. No need to do
> > > the RAID in dom0 :)
> > and if the backplane of the storage server dies? Or just the hard disk
> > controller in the storage? I'd like to have no signle point of failure
> > :-)
> Well, make them double.
> Use two target boxes, use DRBD or similar to sync the data between the
> boxes, and hearbeat to do failover (high-availability) between the boxes
> (iSCSI targets).

slowly i'm getting it :-) The Idea to make the raid stuff outside domU is very 
good and even better is to make the raid stuff on the storage servers 
So drbd is the right approach. But what i dislike is this heartbeat thing. 
Have you read the drbd docs? As long as i can see there could be some damage 
to the storage. If drdb splits (master disconnect from slave) it is possible 
that both gnbd servers get master and when reconnecting you have a big 
problem. Or I am wrong?
OK, for us this scenario can hardly appear but it is possible (heartbeat 
fails, both drbd servers get master, gnbd client writes to one master, then 
the connection to this master fails and gnbd client writes to the other 
"master" => lose of date integrity).

So my summery on this (improvements are welcome):
 * (storage1,drbd/gnbd/multipath) <=> (multipath/gnbd,dom0) <=> domU
   (storage2,drbd/gnbd/multipath) </
     + traffic the real bytes over only one san. lesser cpu load for io on
     + redundancy over direct connection between san1 and san2.
     - need heartbeat, need cluster things, complicated (for me!?)
     - possible failure scenario
 * (storage1,gnbd) <=> (gnbd,dom0) <=> (domU,raid1)
   (storage1,gnbd) <=> (gnbd,dom0) </
     + no heartbeat needed, failures are handled by the raid1 in domU
     + raid1 is well proved
     - twice the raffic, one time in san1 and one time in san2.
     - double the cpu load for io on dom0
     - domU has to do raid1 (more cpu load?)

So from my point of view i will take the disadvantages of the raid1 thing to 
get a easier setup. Also these techniques (nbd resp. gnbd, raid1) are well 
proven over many years.

When the load gets to high on my dom0s I am also able to change to drdb.

> http://www.pcpro.co.uk/realworld/82284/san-on-the-cheap.html
> Tutorial there.

Have to register in page three :-( But as long as i read they also use drbd. 
Are there any other solutions like drbd?

> No need to have single point of failure :)

I'm not sure if this is the case!? Only major failure scenarios are covered by 
solutions with drbd. As my example above shows there could be some kind of 
data corruption. And with Murphy's Law i'll get it.
Or i'm wrong?

> And now, you only need to have multipath setup in dom0, all the RAID stuff
> is in the storage server. And all the volumes (in CLVM) are visible to all
> the xen hosts.. so you can easily migrate domU's from host to another, and
> the domU's know nothing about the underlying LVM/iSCSI/SAN/RAID.

Really, i would like to use a thing like drbd but i don't trust (understand?) 
it. The people from drbd also have no best answer (see 
http://svn.drbd.org/drbd/trunk/ROADMAP point 5). The idea is really good. 
Perhpas it would be best when the syncronisation is controlled by the host 
using the block devices (like raid1, but the data is send only one time). So 
the host is the only one accessing the block device. But this would assume 
that drbd and gnbd would go hand in hand.

Please can anybody instruct me that i'm wrong with this drbd thing?



Xen-users mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.