Re: RBD Mirror DR Testing

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, Nov 22, 2019 at 11:16 AM Vikas Rana <vrana@xxxxxxxxxxxx> wrote:
>
> Hi All,
>
> We have a XFS filesystems on Prod side and when we trying to mount the DR copy, we get superblock error
>
> root@:~# rbd-nbd map nfs/dir
> /dev/nbd0
> root@:~# mount /dev/nbd0 /mnt
> mount: /dev/nbd0: can't read superblock

Doesn't look like you are mapping at a snapshot.

>
> Any suggestions to test the DR copy any other way or if I'm doing something wrong?
>
> Thanks,
> -Vikas
>
> -----Original Message-----
> From: Jason Dillaman <jdillama@xxxxxxxxxx>
> Sent: Thursday, November 21, 2019 10:24 AM
> To: Vikas Rana <vrana@xxxxxxxxxxxx>
> Cc: dillaman <dillaman@xxxxxxxxxx>; ceph-users <ceph-users@xxxxxxxxxxxxxx>
> Subject: Re:  RBD Mirror DR Testing
>
> On Thu, Nov 21, 2019 at 10:16 AM Vikas Rana <vrana@xxxxxxxxxxxx> wrote:
> >
> > Thanks Jason.
> > We are just mounting and verifying the directory structure and make sure it looks good.
> >
> > My understanding was, in 12.2.10, we can't mount the DR snapshot as the RBD image is non-primary. Is this wrong?
>
> You have always been able to access non-primary images for read-only operations (only writes are prevented):
>
> $ rbd info test
> rbd image 'test':
> <... snip ...>
>     mirroring primary: false
>
> $ rbd device --device-type nbd map test@1
> /dev/nbd0
> $ mount /dev/nbd0 /mnt/
> mount: /mnt: WARNING: device write-protected, mounted read-only.
> $ ll /mnt/
> total 0
> -rw-r--r--. 1 root root 0 Nov 21 10:20 hello.world
>
> > Thanks,
> > -Vikas
> >
> > -----Original Message-----
> > From: Jason Dillaman <jdillama@xxxxxxxxxx>
> > Sent: Thursday, November 21, 2019 9:58 AM
> > To: Vikas Rana <vrana@xxxxxxxxxxxx>
> > Cc: ceph-users <ceph-users@xxxxxxxxxxxxxx>
> > Subject: Re:  RBD Mirror DR Testing
> >
> > On Thu, Nov 21, 2019 at 9:56 AM Jason Dillaman <jdillama@xxxxxxxxxx> wrote:
> > >
> > > On Thu, Nov 21, 2019 at 8:49 AM Vikas Rana <vrana@xxxxxxxxxxxx> wrote:
> > > >
> > > > Thanks Jason for such a quick response. We are on 12.2.10.
> > > >
> > > > Checksuming a 200TB image will take a long time.
> > >
> > > How would mounting an RBD image and scanning the image be faster?
> > > Are you only using a small percentage of the image?
> >
> > ... and of course, you can mount an RBD snapshot in read-only mode.
> >
> > > > To test the DR copy by mounting it, these are the steps I'm
> > > > planning to follow 1. Demote the Prod copy and promote the DR copy
> > > > 2. Do we have to recreate the rbd mirror relationship going from DR to primary?
> > > > 3. Mount and validate the data
> > > > 4. Demote the DR copy and promote the Prod copy 5. Revert the peer
> > > > relationship if required?
> > > >
> > > > Did I do it right or miss anything?
> > >
> > > You cannot change the peers or you will lose the relationship. If
> > > you insist on your course of action, you just need to be configured
> > > for two-way mirroring and leave it that way.
> > >
> > > >
> > > > Thanks,
> > > > -Vikas
> > > >
> > > > -----Original Message-----
> > > > From: Jason Dillaman <jdillama@xxxxxxxxxx>
> > > > Sent: Thursday, November 21, 2019 8:33 AM
> > > > To: Vikas Rana <vrana@xxxxxxxxxxxx>
> > > > Cc: ceph-users <ceph-users@xxxxxxxxxxxxxx>
> > > > Subject: Re:  RBD Mirror DR Testing
> > > >
> > > > On Thu, Nov 21, 2019 at 8:29 AM Vikas Rana <vrana@xxxxxxxxxxxx> wrote:
> > > > >
> > > > > Hi all,
> > > > >
> > > > >
> > > > >
> > > > > We have a 200TB RBD image which we are replicating using RBD mirroring.
> > > > >
> > > > > We want to test the DR copy and make sure that we have a consistent copy in case primary site is lost.
> > > > >
> > > > >
> > > > >
> > > > > We did it previously and promoted the DR copy which broken the DR copy from primary and we have to resync the whole 200TB data.
> > > > >
> > > > >
> > > > >
> > > > > Is there any correct way of doing it so we don’t have to resync all 200TB again?
> > > >
> > > > Yes, create a snapshot on the primary site and let it propagate to the non-primary site. Then you can compare checksums at the snapshot w/o having to worry about the data changing. Once you have finished, delete the snapshot on the primary site and it will propagate over to the non-primary site.
> > > >
> > > > >
> > > > >
> > > > > Can we demote current primary and then promote the DR copy and test and then revert back? Will that require the complete 200TB sync?
> > > > >
> > > >
> > > > It's only the forced-promotion that causes split-brain. If you gracefully demote from site A and promote site B, and then demote site B and promote site A, that will not require a sync. However, again, it's probably just easier to use a snapshot.
> > > >
> > > > >
> > > > > Thanks in advance for your help and suggestions.
> > > > >
> > > > >
> > > > >
> > > > > Thanks,
> > > > >
> > > > > -Vikas
> > > > >
> > > > > _______________________________________________
> > > > > ceph-users mailing list
> > > > > ceph-users@xxxxxxxxxxxxxx
> > > > > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com
> > > >
> > > >
> > > >
> > > > --
> > > > Jason
> > > >
> > > >
> > >
> > >
> > > --
> > > Jason
> >
> >
> >
> > --
> > Jason
> >
> >
>
>
> --
> Jason
>
>


-- 
Jason

_______________________________________________
ceph-users mailing list
ceph-users@xxxxxxxxxxxxxx
http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com




[Index of Archives]     [Information on CEPH]     [Linux Filesystem Development]     [Ceph Development]     [Ceph Large]     [Ceph Dev]     [Linux USB Development]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]     [xfs]


  Powered by Linux