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 [email protected] From: Harold Morales <[email protected]> To: gpfsug main discussion list <[email protected]> Date: 01/26/2018 12:30 PM Subject: Re: [gpfsug-discuss] storage-based replication for Spectrum Scale Sent by: [email protected] 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 <[email protected]>: 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 <[email protected]> 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=
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
