[gpfsug-discuss] Underlying LUN mirroring NSD impact

[valdis.kletnieks at vt.edu]

On Wed, 14 Mar 2018 15:36:32 -0000, Mark Bush said:

> Is it possible (albeit not advisable) to mirror LUNs that are NSD's to
> another storage array in another site basically for DR purposes?  Once it's
> mirrored to a new cluster elsewhere what would be the step to get the
> filesystem back up and running.  I know that AFM-DR is meant for this but in
> this case my client only has Standard edition and has mirroring software
> purchased with the underlying disk array.

> Is this even doable?

We had a discussion on the list about this recently.  The upshot is that it's
sort of doable, but depends on what failure modes you're trying to protect
against.  The basic problem is that if you're doing mirroring at the array
level, there's a certain amount of skew delay where GPFS has written stuff on
the local disk and it hasn't been copied to the remote disk (basically the same
reason why running fsck on a mounted disk partition can be problematic).

There's also issues if things are scribbling on the local file system and generating
enough traffic to saturate the network link you're doing the mirroring over, for
a long enough time to overwhelm the mirroring mechanism (both sync and
async mirroring have their good and bad sides in that scenario)

We're using a stretch cluster with GPFS replication to storage about 95 cable
miles away - that has the advantage that then GPFS knows there's a remote
replica and can take more steps to make sure the remote copy is consistent. In
particular, if it knows there's replication that needs to be done and it's
getting backlogged, it can present a slow-down to the local writers and ensure
that the remote set of disks don't fall too far behind....

(There's some funkyness having to do with quorum - it's *really* hard to set up
so you have both protection against split-brain and the ability to start up the
remote site stand-alone - mostly because from the remote point of view,
starting up stand-alone after the main site fails looks identical to split-brain)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 486 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180315/6eef0d0a/attachment-0002.sig>