Suspending the node doesn't stop the services though, we've done a bunch of
testing by connecting to the "real" IP on the box we wanted to test and that
works fine.
OK, so you end up connecting to shares like \\192.168.1.20\sharename, but its
perfectly fine for testing purposes.
In our
Oh? Nice to know - thanks - will try that method next.
From: gpfsug-discuss-boun...@spectrumscale.org
[mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Simon Thompson
(IT Research Support)
Sent: 13 June 2017 09:28
To: gpfsug main discussion list
Or this ☺
From: gpfsug-discuss-boun...@spectrumscale.org
[mailto:gpfsug-discuss-boun...@spectrumscale.org] On Behalf Of Jan-Frode
Myklebust
Sent: 13 June 2017 05:42
To: gpfsug main discussion list
Subject: Re: [gpfsug-discuss] 'mmces address move' weirdness?
Yes, suspending the node would do it, but in the case where you want to remove
a node from service but keep it running for testing it's not ideal.
I think you can set the IP address balancing policy to none which might do what
we want.
From: gpfsug-discuss-boun...@spectrumscale.org
I am investigating setting up Quality of Service parameters on an Infiniband
fabric.
The specific goal is to reduce the bandwidth which certain servers can use,
ie if there are untested or development codes running on these servers in our
cluster then they cannot
adversely affect production
Having the bad manners to answer my own question:
Example
If you define a service level of 2 for GPFS in the InfiniBand
subnet manager set verbsRdmaQpRtrSl to 2.
mmchconfig verbsRdmaQpRtrSl=2
I guess though that I still need the service ID to set the Service Level in
qos-policy.conf
From:
?I see both of these, but only the mmnfs command is documented. Is one a
wrapper of the other?
SHAUN ANDERSON
STORAGE ARCHITECT
O 208.577.2112
M 214.263.7014
NOTICE: This email message and any attachments here to may contain confidential
information. Any unauthorized review, use,