RE: [Xen-API] cross-pool migrate, with any kind of storage (shared or local)

[George Shuklin <george.shuklin@xxxxxxxxx>]

Good day.

I can say one more (may be not really important?) thing about DRBD: in
future it can become base for some kind of solution for storage fault
protection.

If DRBD link is set between two VDI (on two hosts linked to two
different storages) and one of storage is faulty, the operation can
continue in so called 'diskless mode' when data is requesting from
'remote' host, so the end user of /dev/drbd will saw nothing (maybe
slowdown a little).

(I don't say let's do this, but initial drbd support for migration
purposes will allow to implement it without big changes).

And there is third bonus: Special solution for small enterprise pools
with few hosts: live migration between hosts without dedicated storage
with speed of normal 'live migration'.

If two nodes do DRBD on their local disks, they both have local actual
copy of VDI content and this allows to migrate machine from host to host
without long 'disk-copy' time and without use of external dedicated
storage. 

I do believe DRBD can be really useful for such cool things and it
almost cost nothing in StandAlone mode.

Actually, we do have almost every dedicated storage (in product
environment) with DRBD in StandAlone mode: this allow live replication
of whole storage without interrupting anything. And costs of StandAlone
DRBD almost seamless.


Ð ÐÑÐ, 13/07/2011 Ð 17:14 +0100, Dave Scott ÐÐÑÐÑ:
> Hi Marco,
> 
> > Hello Dave:
> > 
> > Great initiative this news. What about implement this to shared
> > storage protocol like NFS for example? There are some plan to do that
> > or the iscsi protocol will be the unique way to implement cross-pool
> > migration?
> 
> My initial thought was to use iscsi internally for the storage migration -- 
> it would be invisible from the user and would work even if the disks were 
> actually on NFS (or any other storage type).
>  
> However it looks like DRBD might be simpler, since it's already capable of 
> tracking writes and building a storage mirror. I'll check that out first.
> 
> Cheers,
> Dave
> 
> > 
> > Cheers,
> > 
> > On Wed, Jul 13, 2011 at 11:22 AM, Dave Scott <Dave.Scott@xxxxxxxxxxxxx>
> > wrote:
> > > And my mail client sent this before I'd written the last line which
> > is
> > >
> > > "Any comments are welcome!"
> > >
> > > Thanks,
> > > Dave
> > >
> > >> -----Original Message-----
> > >> From: xen-api-bounces@xxxxxxxxxxxxxxxxxxx [mailto:xen-api-
> > >> bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of Dave Scott
> > >> Sent: 13 July 2011 15:22
> > >> To: xen-api@xxxxxxxxxxxxxxxxxxx
> > >> Subject: [Xen-API] cross-pool migrate, with any kind of storage
> > (shared
> > >> or local)
> > >>
> > >> Hi,
> > >>
> > >> I've created a page on the wiki describing a new migration protocol
> > for
> > >> xapi. The plan is to make migrate work both within a pool and across
> > >> pools, and to work with and without storage i.e. transparently
> > migrate
> > >> storage if necessary.
> > >>
> > >> The page is here:
> > >>
> > >> http://wiki.xensource.com/xenwiki/CrossPoolMigration
> > >>
> > >> The rough idea is to:
> > >> 1. use an iSCSI target to export disks from the receiver to the
> > >> transmitter
> > >> 2. use tapdisk's log dirty mode to build a continuous disk copy
> > program
> > >> -- perhaps we should go the full way and use the tapdisk block
> > mirror
> > >> code to establish a full storage mirror?
> > >> 3. use the VM metadata export/import to move the VM metadata between
> > >> pools
> > >>
> > >> I'd also like to
> > >> * make the migration code unit-testable (so I can test the failure
> > >> paths easily)
> > >> * make the code more robust to host failures by host heartbeating
> > >> * make migrate properly cancellable
> > >>
> > >> I've started making a prototype-- so far I've written a simple
> > python
> > >> wrapper around the iscsi target daemon:
> > >>
> > >> https://github.com/djs55/iscsi-target-manager
> > >>
> > >> _______________________________________________
> > >> xen-api mailing list
> > >> xen-api@xxxxxxxxxxxxxxxxxxx
> > >> http://lists.xensource.com/mailman/listinfo/xen-api
> > >
> > > _______________________________________________
> > > xen-api mailing list
> > > xen-api@xxxxxxxxxxxxxxxxxxx
> > > http://lists.xensource.com/mailman/listinfo/xen-api
> > >
> > 
> > 
> > 
> > --
> > Marco Sinhoreli
> _______________________________________________
> xen-api mailing list
> xen-api@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/mailman/listinfo/xen-api



_______________________________________________
xen-api mailing list
xen-api@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/mailman/listinfo/xen-api