[gpfsug-discuss] storage-based replication for Spectrum Scale
Glen Corneau
gcorneau at us.ibm.com
Fri Jan 26 20:21:15 GMT 2018
Scale will walk across all discovered disks upon start time and attempt to
read the NSD identifiers from the disks. Once it finds them, it makes a
local map file that correlates the NSD id and the hdiskX identifier. The
names do not have to be the same as either the source cluster or even from
node-to-node.
The main thing to keep in mind is to keep the file system definitions in
sync between the source and destination clusters. The "syncFSconfig" user
exit is the best way to do it because it's automatic. You generally
shouldn't be shuffling the mmsdrfs file between sites, that's what the
"mmfsctl syncFSconfig" does for you, on a per-file system basis.
GPFS+AIX customers have been using this kind of storage replication for
over 10 years, it's business as usual.
------------------
Glen Corneau
Power Systems
Washington Systems Center
gcorneau at us.ibm.com
From: Harold Morales <hmorales at optimizeit.co>
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date: 01/26/2018 12:30 PM
Subject: Re: [gpfsug-discuss] storage-based replication for
Spectrum Scale
Sent by: gpfsug-discuss-bounces at spectrumscale.org
Hi Alex, This set up seems close to what I am trying to achieve.
With regards to this kind of replication: any prereqs need to be met in
the target environment for this to work? for example, should disk devices
naming on AIX be the same as in the source environment? when importing the
mmsdrfs file, how is Scale going to know which disks should it assign to
the cluster? by their hdisk name alone?
Thanks again,
2018-01-24 2:30 GMT-05:00 Alex Levin <alevin at gmail.com>:
Hi,
We are using a similar type of replication.
I assume the site B is the cold site prepared for DR
The storage layer is EMC VMAX and the LUNs are replicated with SRDF.
All LUNs ( NSDs ) of the gpfs filesystem are in the same VMAX replication
group to ensure consistency.
The cluster name, IP addresses , hostnames of the cluster nodes are
different on another site - it can be a pre-configured cluster without
gpfs filesystems or with another filesystem.
Same names and addresses shouldn't be a problem.
Additionally to the replicated LUNs/NSDs you need to deliver copy
of /var/mmfs/gen/mmsdrfs file from A to B site.
There is no need to replicate it in real-time, only after the change of
the cluster configuration.
To activate site B - present replicated LUNs to the nodes in the DR
cluster and run mmimportfs as "mmimportfs fs_name -i copy_of_mmsdrfs"
Tested with multiples LUNs and filesystems on various workloads - seems
to be working
--Alex
On Wed, Jan 24, 2018 at 1:33 AM, Harold Morales <hmorales at optimizeit.co>
wrote:
Thanks for answering.
Essentially, the idea being explored is to replicate LUNs between
identical storage hardware (HP 3PAR volumesrein) on both sites. There is
an IP connection between storage boxes but not between servers on both
sites, there is a dark fiber connecting both sites. Here they dont want to
explore the idea of a scaled-based.
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
http://gpfsug.org/mailman/listinfo/gpfsug-discuss
_______________________________________________
gpfsug-discuss mailing list
gpfsug-discuss at spectrumscale.org
https://urldefense.proofpoint.com/v2/url?u=http-3A__gpfsug.org_mailman_listinfo_gpfsug-2Ddiscuss&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=d-vphLEe_UlGazP6RdYAyyAA3Qv5S9IRVNuO1i9vjJc&m=VbfWaftYSVjx8fMb2vHGBi6XUhDJOsKf_dKOX3J8s1A&s=p2mGvPrlPLO1oyEh-GeVJiVS49opBwwCFs-FKQrQ7rc&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180126/e291af63/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 26117 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180126/e291af63/attachment-0002.jpe>
More information about the gpfsug-discuss
mailing list