14 May
2020
14 May
'20
11:21 p.m.
Hi list,
Thanks again for pointing me towards rbd-mirror!
I've read documentation, old mailing list posts, blog posts and some
additional guides. Seems like the tool to help me through my data migration.
Given one-way synchronisation and image-based (so, not pool based)
configuration, it's still unclear to me how the mirroring will cope with
an existing target pool, already consisting of (a lot of) images.
Has someone done this already? It feels quite scary with doom scenario's
like "cleaning up" the target pool and such in mind...
To sum up: my goal is to mirror clusterA/somepool with some specific
images to clusterB/someotherpool where already other images reside. The
mirrored images should be kept in sync and the other images should be
left alone completely.
Cheers,
Kees
--
https://nefos.nl/contact
Nefos IT bv
Ambachtsweg 25 (industrienummer 4217)
5627 BZ Eindhoven
Nederland
KvK 66494931
/Aanwezig op maandag, dinsdag, woensdag en vrijdag/
15 May
15 May
12:05 a.m.
As a matter of my experience, rbd-mirror only copy the images with
journaling feature of clusterA to clusterB. It doesn't influence the other
images in the pool of clusterB. You'd better have a test on it.
Kees Meijs | Nefos <kees(a)nefos.nl> 于2020年5月14日周四 下午10:22写道：
Hi list,
Thanks again for pointing me towards rbd-mirror!
I've read documentation, old mailing list posts, blog posts and some
additional guides. Seems like the tool to help me through my data
migration.
Given one-way synchronisation and image-based (so, not pool based)
configuration, it's still unclear to me how the mirroring will cope with
an existing target pool, already consisting of (a lot of) images.
Has someone done this already? It feels quite scary with doom scenario's
like "cleaning up" the target pool and such in mind...
To sum up: my goal is to mirror clusterA/somepool with some specific
images to clusterB/someotherpool where already other images reside. The
mirrored images should be kept in sync and the other images should be
left alone completely.
Cheers,
Kees
--
https://nefos.nl/contact
Nefos IT bv
Ambachtsweg 25 (industrienummer 4217)
5627 BZ Eindhoven
Nederland
KvK 66494931
/Aanwezig op maandag, dinsdag, woensdag en vrijdag/
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
12:14 a.m.
The pool names in both clusters have to be identical in addition to
the required journal feature. It’s probably an advantage if the
existing pool in the second cluster has a different name. In that case
you can set up the mirror for a new pool without affecting the other
pool and after mirroring has completed move the images into the
destination pool.
Zitat von Zhenshi Zhou <deaderzzs(a)gmail.com>om>:
As a matter of my experience, rbd-mirror only copy the
images with
journaling feature of clusterA to clusterB. It doesn't influence the other
images in the pool of clusterB. You'd better have a test on it.
Kees Meijs | Nefos <kees(a)nefos.nl> 于2020年5月14日周四 下午10:22写道：
--
Eugen Block voice : +49 40 5595175
NDE Netzdesign und -entwicklung AG fax : +49 40 5595177
Postfach 61 03 15 e-mail : username(a)nde.ag
D-22423 Hamburg
Vertretungsberechtigter Vorstand: Jens-U. Mozdzen
Vorsitzende des Aufsichtsrats: Angelika Torlée-Mozdzen
Sitz und Registergericht: Hamburg, HRB 90934
USt-IdNr: DE 814 013 983
Hi list,
Thanks again for pointing me towards rbd-mirror!
I've read documentation, old mailing list posts, blog posts and some
additional guides. Seems like the tool to help me through my data
migration.
Given one-way synchronisation and image-based (so, not pool based)
configuration, it's still unclear to me how the mirroring will cope with
an existing target pool, already consisting of (a lot of) images.
Has someone done this already? It feels quite scary with doom scenario's
like "cleaning up" the target pool and such in mind...
To sum up: my goal is to mirror clusterA/somepool with some specific
images to clusterB/someotherpool where already other images reside. The
mirrored images should be kept in sync and the other images should be
left alone completely.
Cheers,
Kees
--
https://nefos.nl/contact
Nefos IT bv
Ambachtsweg 25 (industrienummer 4217)
5627 BZ Eindhoven
Nederland
KvK 66494931
/Aanwezig op maandag, dinsdag, woensdag en vrijdag/
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io 
12:41 a.m.
When you set up the rbd-mirror daemons with each others’ configs, and initiate mirroring
of a volume, the destination will create the volume in the destination cluster and pull
over data.
Hopefully you’re creating unique volume names so there won’t be conflicts, but that said
if the destination has a collision, it won’t be overwritten.
Hi list,
Thanks again for pointing me towards rbd-mirror!
I've read documentation, old mailing list posts, blog posts and some
additional guides. Seems like the tool to help me through my data migration.
Given one-way synchronisation and image-based (so, not pool based)
configuration, it's still unclear to me how the mirroring will cope with
an existing target pool, already consisting of (a lot of) images.
Has someone done this already? It feels quite scary with doom scenario's
like "cleaning up" the target pool and such in mind...
To sum up: my goal is to mirror clusterA/somepool with some specific
images to clusterB/someotherpool where already other images reside. The
mirrored images should be kept in sync and the other images should be
left alone completely.
Cheers,
Kees
--
https://nefos.nl/contact
Nefos IT bv
Ambachtsweg 25 (industrienummer 4217)
5627 BZ Eindhoven
Nederland
KvK 66494931
/Aanwezig op maandag, dinsdag, woensdag en vrijdag/
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
1:46 a.m.
Hi Anthony,
A one-way mirror suits fine in my case (the old cluster will be
dismantled in mean time) so I guess a single rbd-mirror daemon should
suffice.
The pool consists of OpenStack Cinder volumes containing a UUID (i.e.
volume-ca69183a-9601-11ea-8e82-63973ea94e82 and such). The change of
conflicts is near to zero.
My main concern is pulling images into a non-empty pool. It would be
(very) bad if rbd-mirror tries to be smart and removes images that don't
exist in the source pool.
Regards and thanks again,
Kees
On 14-05-2020 17:41, Anthony D'Atri wrote:
When you set up the rbd-mirror daemons with each
others’ configs, and initiate mirroring of a volume, the destination will create the
volume in the destination cluster and pull over data.
Hopefully you’re creating unique volume names so there won’t be conflicts, but that said
if the destination has a collision, it won’t be overwritten.
3:11 a.m.
On Thu, May 14, 2020 at 12:47 PM Kees Meijs | Nefos <kees(a)nefos.nl> wrote:
Hi Anthony,
A one-way mirror suits fine in my case (the old cluster will be
dismantled in mean time) so I guess a single rbd-mirror daemon should
suffice.
The pool consists of OpenStack Cinder volumes containing a UUID (i.e.
volume-ca69183a-9601-11ea-8e82-63973ea94e82 and such). The change of
conflicts is near to zero.
My main concern is pulling images into a non-empty pool. It would be
(very) bad if rbd-mirror tries to be smart and removes images that don't
exist in the source pool.
rbd-mirror can only remove images that (1) have mirroring enabled and (2)
are not split-brained with its peer. It's totally fine to only mirror a
subset of images within a pool and it's fine to only mirror one-way.
Regards and thanks again,
Kees
On 14-05-2020 17:41, Anthony D'Atri wrote:
_______________________________________________
ceph-users mailing list -- ceph-users(a)ceph.io
To unsubscribe send an email to ceph-users-leave(a)ceph.io
--
Jason
When you set up the rbd-mirror daemons with each
others’ configs, and
initiate mirroring of a volume, the destination will create
the volume in
the destination cluster and pull over data.
Hopefully you’re creating unique volume names so there won’t be
conflicts, but
that said if the destination has a collision, it won’t be
overwritten.
4:13 a.m.
Thanks for clearing that up, Jason.
K.
On 14-05-2020 20:11, Jason Dillaman wrote:
rbd-mirror can only remove images that (1) have
mirroring enabled and
(2) are not split-brained with its peer. It's totally fine to only
mirror a subset of images within a pool and it's fine to only mirror
one-way.
4:45 a.m.
Understandable concern.
FWIW I’ve used rbd-mirror to move thousands of volumes between clusters with zero
clobbers.
—aad
On May 14, 2020, at 9:46 AM, Kees Meijs | Nefos
<kees(a)nefos.nl> wrote:
My main concern is pulling images into a non-empty pool. It would be
(very) bad if rbd-mirror tries to be smart and removes images that don't
exist in the source pool.
1436
days inactive
1436
days old
7 comments
5 participants
participants (5)
-
Anthony D'Atri -
Eugen Block -
Jason Dillaman -
Kees Meijs | Nefos -
Zhenshi Zhou