[gpfsug-discuss] Compatibility question
Steven Daniels
sadaniel at us.ibm.com
Fri Nov 22 17:01:09 GMT 2019
Felipe,
You are correct. The code is restricted to 4.2.2 or higher. If there is an
ESS storage cluster in the environment then the recommendation I was told
is 4.2.3.7 or higher.
Luke,
If your clients are in the same cluster then you need to be careful with
the setting to minReleaseLevel, Exactly as it sounds, it will restrict
membership to this level or higher.
I have a client running with filesystem version 3.5.0.7 in several
clusters.
We just recently upgraded their ESS systems to the current release so I
can verify that the file system format will carry fine.
If you have ESS at 5.3.3 or higher, then the GNR recommendation is 4.2.3.7
or higher for the clients (my client can't go to v5 due to the RHEL
version requirement) and they must be in a remote cluster.
In my case we upgraded an ESS storage cluster to 4.1.1 to 5.0.3.3 (ESS
v5.3.4.1) and for GNR we had to update this cluster to LATEST for
minReleaseLevel which is 5.0.3.
The client cluster is running 4.2.3.18 which is as Felipe says is N-1 and
minReleaseLevel is set to 4.2.3.7
This client cluster also mounts from another storage cluster which is
constrained to run at 4.1.1-8. This makes the client cluster at N+1 from
its relationship with this cluster.
All three clusters have minReleaseLevel set to LATEST (4.1.0,
4.2.3.7,5.0.3 , respectively).
These changes would not work in a single cluster as all nodes would be
restricted to the 4.1.0 or higher and the ESS would not be able to
co-exist since it requires the 5.0 level.
We have updated the file systems in the 4.1.1-8 cluster from 3.5.0.7 to
4.1.1 and we updated the ESS filesystems from 3.5.0.7 to 5.0.3 (compat
mode)
The changes all went well.
Hopefully this helps you understand the nuance that is whether the clients
and NSDs are in a single cluster or different clusters. The rules are
slightly but importantly different.
Also, when updating the filesystem versions make sure you use the "compat"
flag if you have any remote clusters. If we would have run this with the
"full" flag on the ESS storage cluster, it would have prevented the
4.2.3.18 client cluster from mounting its file systems.
thanks,
Steve
Steven A. Daniels
Cross-brand Client Architect
Senior Certified IT Specialist
National Programs
Fax and Voice: 3038101229
sadaniel at us.ibm.com
http://www.ibm.com
From: "Felipe Knop" <knop at us.ibm.com>
To: gpfsug-discuss at spectrumscale.org
Cc: gpfsug-discuss at spectrumscale.org
Date: 11/21/2019 09:49 PM
Subject: [EXTERNAL] Re: [gpfsug-discuss] Compatibility question
Sent by: gpfsug-discuss-bounces at spectrumscale.org
George,
Coexistence either in the same cluster or across remote clusters is only
supported with versions "N" and "N-1". 5.0.3 and 3.5 are "N" and "N-3",
and this is not supported. If I recall, there is even logic in place that
will prevent 5.x nodes from accepting connections from nodes running below
4.2 .
Felipe
----
Felipe Knop knop at us.ibm.com
GPFS Development and Security
IBM Systems
IBM Building 008
2455 South Rd, Poughkeepsie, NY 12601
(845) 433-9314 T/L 293-9314
----- Original message -----
From: Luke Raimbach <luke.raimbach at googlemail.com>
Sent by: gpfsug-discuss-bounces at spectrumscale.org
To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Cc:
Subject: [EXTERNAL] Re: [gpfsug-discuss] Compatibility question
Date: Thu, Nov 21, 2019 8:12 PM
That would make my eyes water and maybe fall out. Yours might too of you
try it.
Be very careful with v3 upgrades, especially going up to v5 directly.
You will certainly run into RPC incompatibility problems with the v3 and
v5 nodes running concurrently. Staying within the supported envelope of
"one major version" difference will ease the raising of support tickets
with IBM if you run into problems.
Why can't you upgrade the clients?
On Thu, 21 Nov 2019, 18:24 George Terry, <gterryc at vmsupport.com> wrote:
Hello,
I have a question about compatibility between two different versions. I
have a cluster with 6 gpfs nodes. 2 of them are NSD servers the other 4
are clientes nodes. I will upgrade the NSD servers from 3.5.0 to 5.0.3.
Due to application's issues I cannot update the client nodes. So, my
question is, can i have a cluster with client nodes with 3.5.0.7 version
and the NSD nodes in 5.0.3 version with de filesystem in 3.5.0.7 (13.23)
version?
Thanks for the support.
George
_______________________________________________
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=6mf8yZ-lDnfsy3mVONFq1RV1ypXT67SthQnq3D6Ym4Q&m=sHhNGNTp4CJIVbXT4t8ZvNT_mETKfXBn7XTvNDAYF7s&s=9ialbzpuZMc8DZzXtU_nqjgQ9BPsHP3DQdpHa0nKQuc&e=
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20191122/52fd3c62/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: image/jpeg
Size: 4919 bytes
Desc: not available
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20191122/52fd3c62/attachment.jpe>
More information about the gpfsug-discuss
mailing list