Hi,
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
themselves.
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
dom0.
+ 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?
--
greetings
eMHa
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home