[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Xen-API] Alternative to Vastsky?
- To: xen-api@xxxxxxxxxxxxxxxxxxx
- From: George Shuklin <george.shuklin@xxxxxxxxx>
- Date: Wed, 20 Apr 2011 02:21:17 +0400
- Delivery-date: Tue, 19 Apr 2011 15:21:25 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=KbbMZZlhu068oqyI9lXAHpg6jH4eJt1mPmoTWEcOFRo=; b=Dew/ocG1nbwoTznxzcXXCz401oomh7mqNvkr6SyxMlDRWDd5OHdHmo3e6EHY/VTzbG aNbqjD6eHOw/OVKzk1hW8ZirizNOqqtKqqpk9EXw9A6qAs7p10mY/K5kBbvF8+T2OM7L O4O6gw/vT4faIL3TqeX7J1JMJFS+3AvPlr6F4=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=WcmTI23kTGlToatg9+rpFkxY927Q80ov+E2HpTZ1PvfelCzZNx9QWsrxoLhJasdoy8 +m3VtlRmmdOBUtmLym5SeIw0w+3qtpokZhTIpvkvSbRnWdTcXc3E5unicEM9NK1oqMuq DplKufNfWUn5jWpTY0kulsLAUBxN8/3EMPCrM=
- List-id: Discussion of API issues surrounding Xen <xen-api.lists.xensource.com>
I think we shall split this to three different scenarios:
1) local storage redundancy of local storage within terms of single host
(e.g. software RAID support, I think this require a little tweak of
installer to create RAID1 instead plain /dev/sda installation)
2) local storage redundancy within pool with limited host replication
(primary/primary DRBD between two XCP hosts, similar to current
/opt/xensource/packages/iso shared ISO SR)
3) Supports for external storage supports replication and clustering and
many other enterprise-level buzzwords.
Most interesting is third.
Right now I have plans to test iscsi over DRBD with muplipath to both
iscsi initiators (never test this, but it may be interesting),
alternative is corosync/pacemaker clustering for NFS/ISCSI + DRBD...
On 20.04.2011 02:10, Tim Titley wrote:
Has anyone considered a replacement for the vastsky storage backend
now that the project is officially dead (at least for now)?
I have been looking at Ceph ( http://ceph.newdream.net/ ). A
suggestion to someone so inclined to do something about it, may be to
use the Rados block device (RBD) and put an LVM storage group on it,
which would require modification of the current LVM storage manager
code - I assume similar to LVMOISCSI.
This would provide scalable, redundant storage at what I assume would
be reasonable performance since the data can be striped across many
Development seems reasonably active and although the project is not
officially production quality yet, it is part of the Linux kernel
which looks promising, as does the news that they will be providing
The only downside is that RBD requires a 2.6.37 kernel. For those "in
the know" - how long will it be before this kernel makes it to XCP -
considering that this vanilla kernel supposedly works in dom0 (I have
yet to get it working)?
xen-api mailing list
xen-api mailing list