I normally do mmcrnsd without specifying any servers=, and point at the local /dev entry. Afterwards I add the servers= line and do mmchnsd.
-jf man. 19. des. 2016 kl. 16.58 skrev Buterbaugh, Kevin L < [email protected]>: > Hi Ken, > > Umm, wouldn’t that make that server the primary NSD server for all those > NSDs? Granted, you run the mmcrnsd command from one arbitrarily chosen > server, but as long as you have the proper device name for the NSD from the > NSD server you want to be primary for it, I’ve never had a problem > specifying many different servers first in the list. > > Or am I completely misunderstanding what you’re saying? Thanks... > > Kevin > > On Dec 19, 2016, at 9:30 AM, Ken Hill <[email protected]> wrote: > > Indeed. It only matters when deploying NSDs. Post-deployment, all luns > (NSDs) are labeled - and they are assembled by GPFS. > > Keep in mind: If you are deploying multiple NSDs (with multiple servers) - > you'll need to pick one server to work with... Use that server to label the > luns (mmcrnsd)... In the nsd stanza file - the server you choose will need > to be the first server in the "servers" list. > > > *Ken Hill* > Technical Sales Specialist | Software Defined Solution Sales > IBM Systems > > ------------------------------ > *Phone:*1-540-207-7270 > * E-mail:* *[email protected]* <[email protected]> > <ATT00001.png> <http://www.ibm.com/us-en/> <ATT00002.png> > <http://www-03.ibm.com/systems/platformcomputing/products/lsf/> > <ATT00003.png> > <http://www-03.ibm.com/systems/platformcomputing/products/high-performance-services/index.html> > <ATT00004.png> > <http://www-03.ibm.com/systems/platformcomputing/products/symphony/index.html> > <ATT00005.png> <http://www-03.ibm.com/systems/storage/spectrum/> > <ATT00006.png> <http://www-01.ibm.com/software/tivoli/csi/cloud-storage/> > <ATT00007.png> > <http://www-01.ibm.com/software/tivoli/csi/backup-recovery/> > <ATT00008.png> > <http://www-03.ibm.com/systems/storage/tape/ltfs/index.html> > <ATT00009.png> <http://www-03.ibm.com/systems/storage/spectrum/> > <ATT00010.png> <http://www-03.ibm.com/systems/storage/spectrum/scale/> > <ATT00011.png> > <https://www.ibm.com/marketplace/cloud/object-storage/us/en-us> > > > 2300 Dulles Station Blvd > Herndon, VA 20171-6133 > United States > > > > > > > > > > > > From: "Daniel Kidger" <[email protected]> > To: "gpfsug main discussion list" <[email protected] > > > Cc: "gpfsug main discussion list" <[email protected] > > > Date: 12/19/2016 06:42 AM > Subject: Re: [gpfsug-discuss] translating /dev device into nsd name > Sent by: [email protected] > ------------------------------ > > > > *Valdis wrote:* > > > > *Keep in mind that if you have multiple NSD servers in the cluster, there > is *no* guarantee that the names for a device will be consistent across the > servers, or across reboots. And when multipath is involved, you may have 4 > or 8 or even more names for the same device....* > > Indeed the is whole greatness about NSDs (and in passing why Lustre can be > much more tricky to safely manage.) > Once a lun is "labelled" as an NSD then that NSD name is all you need to > care about as the /dev entries can now freely change on reboot or differ > across nodes. Indeed if you connect an arbitrary node to an NSD disk via a > SAN cable, gpfs will recognise it and use it as a shortcut to that lun. > > Finally recall that in the NSD stanza file the /dev entry is only matched > for on the first of the listed NSD servers; the other NSD servers will > discover and learn which NSD this is, ignoring the /dev value in this > stanza. > > Daniel > > IBM Spectrum Storage Software > *+44 (0)7818 522266* <+44%207818%20522266> > Sent from my iPad using IBM Verse > > > ------------------------------ > On 17 Dec 2016, 21:43:00, [email protected] wrote: > > From: [email protected] > To: [email protected] > Cc: > Date: 17 Dec 2016 21:43:00 > Subject: Re: [gpfsug-discuss] translating /dev device into nsd name > > On Fri, 16 Dec 2016 23:24:34 -0500, Aaron Knister said: > > that I can then parse and map the nsd id to the nsd name. I hesitate > > calling ts* commands directly and I admit it's perhaps an irrational > > fear, but I associate the -D flag with "delete" in my head and am afraid > > that some day -D may be just that and *poof* there go my NSD descriptors. > Others have mentioned mmlsdnsd -m and -X > Keep in mind that if you have multiple NSD servers in the cluster, there > is *no* guarantee that the names for a device will be consistent across > the servers, or across reboots. And when multipath is involved, you may > have 4 or 8 or even more names for the same device.... > _______________________________________________ > gpfsug-discuss mailing list > gpfsug-discuss at spectrumscale.org > http://gpfsug.org/mailman/listinfo/gpfsug-discuss > Unless stated otherwise above: > IBM United Kingdom Limited - Registered in England and Wales with number > 741598. > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU > _______________________________________________ > 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 > http://gpfsug.org/mailman/listinfo/gpfsug-discuss >
_______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at spectrumscale.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss
