Dear Leonardo, you will find a description in the Concepts, Planning, and Installation Guide in the GPFS daemon communication section, explaining how the startup mechanism works. The Administration Guide contains an explanation on MROTs specifics for the subnets usage (Chapter 17 in the 5.1.7. version) Chapter 33 focuses on remote cluster mounts and contains examples.
Basically, the node join triggers the compare and the matching, thus a client clusters node uses it's subnets configuration (including the remote clusters clustername) to initiate the connection. On the storage cluster you can also diffentiate your existing subnets for use with separate remote mounting clusters. I would recommend still to do it on both, just to be precise. Initially the idea (as can be seen in the examples in Chapter 33) was to force the daemon communication to the storage NSD servers to use the 'high speed' network, rather than the lower bandwidth common admin network. -- Mit freundlichen Grüßen / Kind regards Achim Rehor Technical Support Specialist Spectrum Scale and ESS (SME) Advisory Product Services Professional IBM Systems Storage Support - EMEA [email protected] +49-170- 4521194 IBM Deutschland GmbH -----Original Message----- From: Leonardo Sala <[email protected]> To: gpfsug main discussion list <[email protected]>, Achim Rehor <[email protected]> Subject: [EXTERNAL] Re: [gpfsug-discuss] Question about subnets parameter and remote cluster mounts Date: Wed, 03 May 2023 16:58:12 +0200 Dear Achim, thanks! My point is: in case of a remote cluster mount, e. g. CL2 mounting CL1 storage, where should I specify the subnets parameter: 1) on CL2 (client cluster) 2) on CL1 (storage cluster) 3) on both CL1 and CL2 I might have to change ZjQcmQRYFpfptBannerStart This Message Is From an External Sender This message came from outside your organization. ZjQcmQRYFpfptBannerEnd #pfptBannerzu381sx { all: revert !important; display: block !important; visibility: visible !important; opacity: 1 !important; background-color: #D0D8DC !important; max-width: none !important; max-height: none !important } .pfptPrimaryButtonzu381sx:hover, .pfptPrimaryButtonzu381sx:focus { background-color: #b4c1c7 !important; } .pfptPrimaryButtonzu381sx:active { background-color: #90a4ae !important; }Dear Achim, thanks! My point is: in case of a remote cluster mount, e.g. CL2 mounting CL1 storage, where should I specify the subnets parameter: 1) on CL2 (client cluster) 2) on CL1 (storage cluster) 3) on both CL1 and CL2 I might have to change this parameter on a production system, and as it needs a restart I would like to be sure I change it only where necessary Thanks again! cheers leo Paul Scherrer Institut Dr. Leonardo Sala Group Leader Data Analysis and Research Infrastructure Deputy Department Head a.i Science IT Infrastructure and Services department Science IT Infrastructure and Services department (AWI) WHGA/036 Forschungstrasse 111 5232 Villigen PSI Switzerland Phone: +41 56 310 3369 [email protected] www.psi.ch On 5/3/23 16:40, Achim Rehor wrote: > correct, there is no need to put client and storage into different > subnets, > and it is also not necessary to specify the subnet parameter at all, > when they share the same network. > > The subnets parameter is very helpful, though, if you are using > multiple networks, and want to use specific ones for communication with > one or the other remote cluster. > _______________________________________________ gpfsug-discuss mailing list gpfsug-discuss at gpfsug.org http://gpfsug.org/mailman/listinfo/gpfsug-discuss_gpfsug.org
