[gpfsug-discuss] translating /dev device into nsd name

Jan-Frode Myklebust janfrode at tanso.net
Mon Dec 19 16:25:50 GMT 2016


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 <
Kevin.Buterbaugh at vanderbilt.edu>:

> 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 <kenh at us.ibm.com> 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:* *kenh at us.ibm.com* <kenh at us.ibm.com>
> <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" <daniel.kidger at uk.ibm.com>
> To:        "gpfsug main discussion list" <gpfsug-discuss at spectrumscale.org
> >
> Cc:        "gpfsug main discussion list" <gpfsug-discuss at spectrumscale.org
> >
> Date:        12/19/2016 06:42 AM
> Subject:        Re: [gpfsug-discuss] translating /dev device into nsd name
> Sent by:        gpfsug-discuss-bounces at spectrumscale.org
> ------------------------------
>
>
>
> *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, Valdis.Kletnieks at vt.edu wrote:
>
> From: Valdis.Kletnieks at vt.edu
> To: gpfsug-discuss at spectrumscale.org
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20161219/215d8549/attachment.htm>


More information about the gpfsug-discuss mailing list