Remus and blktap2

Remus and blktap2

[Wei Liu]

Hi Shriram and Hongyang

I have a question regarding REMUS block replication support. Does it
require blktap2 to function? The README.remus file only mention DRDB so
I'm not sure how blktap2 fit into the picture.

Thanks
Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Remus and blktap2

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 1029 bytes --]

Blktap2 was the first disk backend implementation. I moved Remus to DRBD
because it had disk resynchronization support. For eg, when primary fails,
backup takes over. When primary comes back online, DRBD would automatically
resynchronize new changes from the backup disk to the primary disk and will
continue to keep them synchronized.
At this stage, you have the option of starting Remus replication from
backup to primary, or, migrating the VM back to the primary host and doing
the primary to backup replication.

The DRBD support (last I remember) is quite out of date, because the Remus
DRBD kernel module I wrote relies on an older kernel version (3.4?) and
older DRBD code base (8.1 I think).

On Fri, Apr 22, 2016 at 12:13 PM Wei Liu <wei.liu2@citrix.com> wrote:

> Hi Shriram and Hongyang
>
> I have a question regarding REMUS block replication support. Does it
> require blktap2 to function? The README.remus file only mention DRDB so
> I'm not sure how blktap2 fit into the picture.
>
> Thanks
> Wei.
>
> --

~shriram

[-- Attachment #1.2: Type: text/html, Size: 1372 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Remus and blktap2

[Wei Liu]

On Fri, Apr 22, 2016 at 06:07:46PM +0000, Shriram Rajagopalan wrote:
> Blktap2 was the first disk backend implementation. I moved Remus to DRBD
> because it had disk resynchronization support. For eg, when primary fails,
> backup takes over. When primary comes back online, DRBD would automatically
> resynchronize new changes from the backup disk to the primary disk and will
> continue to keep them synchronized.
> At this stage, you have the option of starting Remus replication from
> backup to primary, or, migrating the VM back to the primary host and doing
> the primary to backup replication.
> 
> The DRBD support (last I remember) is quite out of date, because the Remus
> DRBD kernel module I wrote relies on an older kernel version (3.4?) and
> older DRBD code base (8.1 I think).
> 

I should have given more context. We may want to remove blktap2 from
xen.git in the future. Will that break remus?

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Remus and blktap2

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 1067 bytes --]

I don't think so.

On Fri, Apr 22, 2016 at 2:12 PM Wei Liu <wei.liu2@citrix.com> wrote:

> On Fri, Apr 22, 2016 at 06:07:46PM +0000, Shriram Rajagopalan wrote:
> > Blktap2 was the first disk backend implementation. I moved Remus to DRBD
> > because it had disk resynchronization support. For eg, when primary
> fails,
> > backup takes over. When primary comes back online, DRBD would
> automatically
> > resynchronize new changes from the backup disk to the primary disk and
> will
> > continue to keep them synchronized.
> > At this stage, you have the option of starting Remus replication from
> > backup to primary, or, migrating the VM back to the primary host and
> doing
> > the primary to backup replication.
> >
> > The DRBD support (last I remember) is quite out of date, because the
> Remus
> > DRBD kernel module I wrote relies on an older kernel version (3.4?) and
> > older DRBD code base (8.1 I think).
> >
>
> I should have given more context. We may want to remove blktap2 from
> xen.git in the future. Will that break remus?
>
> Wei.
>
-- 

~shriram

[-- Attachment #1.2: Type: text/html, Size: 1456 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Remus and blktap2

[Wei Liu]

On Fri, Apr 22, 2016 at 06:20:36PM +0000, Shriram Rajagopalan wrote:
> I don't think so.
> 

Thanks for confirming!

Wei.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Remus and blktap2

[Pasi Kärkkäinen]

Hi,

On Fri, Apr 22, 2016 at 06:07:46PM +0000, Shriram Rajagopalan wrote:
>    Blktap2 was the first disk backend implementation. I moved Remus to DRBD
>    because it had disk resynchronization support. For eg, when primary fails,
>    backup takes over. When primary comes back online, DRBD would
>    automatically resynchronize new changes from the backup disk to the
>    primary disk and will continue to keep them synchronized.
>    At this stage, you have the option of starting Remus replication from
>    backup to primary, or, migrating the VM back to the primary host and doing
>    the primary to backup replication.
> 
>    The DRBD support (last I remember) is quite out of date, because the Remus
>    DRBD kernel module I wrote relies on an older kernel version (3.4?) and
>    older DRBD code base (8.1 I think).
>

Are there plans to get the Remus DRBD module upstreamed? Or working with recent DRBD versions? 


Thanks,

-- Pasi


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

Re: Remus and blktap2

[Shriram Rajagopalan]

[-- Attachment #1.1: Type: text/plain, Size: 2092 bytes --]

I tried to upstream the DRBD code few years ago, but the maintainers were
not willing to accept the patch, stating that stating that I had not proved
that the entire Remus system implementation (memory and disk replication)
was tolerant to all forms of system errors and maintain consistency of the
disk.
Not sure why this mattered to them, as the checkpoint based disk
replication protocol could be used independent of Remus for any other
system, just like the way companies like Yelp are using the Remus' plug
qdisc for controlling their application interaction with network, without
using any other part of Remus. Sigh

The only reason to stick to DRBD is because of its resynchronization
capabilities. If that is not needed, a Remus style disk replication can be
done using Qemu's disk backends. I am out of sync with the current status
of disk backends that Qemu offers and Xen supports. So I apologize in
advance for any factual inaccuracies.

On Sat, Apr 23, 2016 at 7:35 AM Pasi Kärkkäinen <pasik@iki.fi> wrote:

> Hi,
>
> On Fri, Apr 22, 2016 at 06:07:46PM +0000, Shriram Rajagopalan wrote:
> >    Blktap2 was the first disk backend implementation. I moved Remus to
> DRBD
> >    because it had disk resynchronization support. For eg, when primary
> fails,
> >    backup takes over. When primary comes back online, DRBD would
> >    automatically resynchronize new changes from the backup disk to the
> >    primary disk and will continue to keep them synchronized.
> >    At this stage, you have the option of starting Remus replication from
> >    backup to primary, or, migrating the VM back to the primary host and
> doing
> >    the primary to backup replication.
> >
> >    The DRBD support (last I remember) is quite out of date, because the
> Remus
> >    DRBD kernel module I wrote relies on an older kernel version (3.4?)
> and
> >    older DRBD code base (8.1 I think).
> >
>
> Are there plans to get the Remus DRBD module upstreamed? Or working with
> recent DRBD versions?
>
>
> Thanks,
>
> -- Pasi
>
> --

~shriram

[-- Attachment #1.2: Type: text/html, Size: 2478 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel