[gpfsug-discuss] wondering about outage free protocols upgrades

Sobey, Richard A r.sobey at imperial.ac.uk
Thu Mar 8 09:41:56 GMT 2018


Whether or not you meant it your words “that is not available today.” Implies that something is coming in the future? Would you be reliant on the Samba/CTDB development team or would you roll your own.. supposing it’s possible in the first place.

Thanks
Richard

From: gpfsug-discuss-bounces at spectrumscale.org [mailto:gpfsug-discuss-bounces at spectrumscale.org] On Behalf Of Christof Schmitt
Sent: 07 March 2018 21:54
To: gpfsug-discuss at spectrumscale.org
Subject: Re: [gpfsug-discuss] wondering about outage free protocols upgrades

The problem with the SMB upgrade is with the data shared between the protocol nodes. It is not tied to the protocol version used between SMB clients and the protocol nodes. Samba stores internal data (e.g. for the SMB state of open files) in tdb database files. ctdb then makes these tdb databases available across all protocol nodes. A concurrent upgrade for SMB would require correct handling of ctdb communications and the tdb records across multiple versions; that is not available today.

Regards,

Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ
christof.schmitt at us.ibm.com<mailto:christof.schmitt at us.ibm.com>  ||  +1-520-799-2469    (T/L: 321-2469)


----- Original message -----
From: <Greg.Lehmann at csiro.au<mailto:Greg.Lehmann at csiro.au>>
Sent by: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org>
To: <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
Cc:
Subject: Re: [gpfsug-discuss] wondering about outage free protocols upgrades
Date: Wed, Mar 7, 2018 4:35 AM


In theory it only affects SMB, but in practice if NFS depends on winbind for authorisation then it is affected too. I can understand the need for changes to happen every so often and that maybe outages will be required then.



But, I would like to see some effort to avoid doing this unnecessarily. IBM, please consider my suggestion. The message I get from the ctdb service implies it is the sticking point. Can some consideration be given to keeping the ctdb version compatible between releases?



Christof, you are saying something about the SMB service version compatibility. I am unclear as to whether you are talking about the Spectrum Scale Protocols SMB service or the default samba SMB over the wire protocol version being used to communicate between client and server. If the latter, is it possible to peg the version to the older version manually while doing the upgrade so that all nodes can be updated? You can then take an outage at a later time to update the over the wire version.



From: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org> [mailto:gpfsug-discuss-bounces at spectrumscale.org] On Behalf Of Christof Schmitt
Sent: Wednesday, 7 March 2018 4:50 AM
To: gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>
Cc: gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>
Subject: Re: [gpfsug-discuss] wondering about outage free protocols upgrades



Hi,



at this point there are no plans to support "node by node" upgrade for SMB.



Some background: The technical reason for this restriction is that the records shared between protocol nodes for the SMB service (ctdb and Samba) are not versioned and no mechanism is in place to handle different versions. Changing this would be a large development task that has not been included in any current plans.



Note that this only affects the SMB service and that the knowledge center outlines a procedure to minimize the outage, by getting half of the protocol nodes ready with the new Samba version and then only taking a brief outage when switching from the "old" to the "new" Samba version: https://www.ibm.com/support/knowledgecenter/en/STXKQY_4.2.2/com.ibm.spectrum.scale.v4r22.doc/bl1ins_updatingsmb.htm

The toolkit follows the same approach during an upgrade to minimize the outage.



We know that this is not ideal, but as mentioned above this is limited by the large effort that would be required which has to be weighed against other requirements and priorities.



Regards,

Christof Schmitt || IBM || Spectrum Scale Development || Tucson, AZ
christof.schmitt at us.ibm.com<mailto:christof.schmitt at us.ibm.com>  ||  +1-520-799-2469    (T/L: 321-2469)





----- Original message -----
From: <Greg.Lehmann at csiro.au<mailto:Greg.Lehmann at csiro.au>>
Sent by: gpfsug-discuss-bounces at spectrumscale.org<mailto:gpfsug-discuss-bounces at spectrumscale.org>
To: <gpfsug-discuss at spectrumscale.org<mailto:gpfsug-discuss at spectrumscale.org>>
Cc:
Subject: [gpfsug-discuss] wondering about outage free protocols upgrades
Date: Tue, Mar 6, 2018 10:19 AM


Hi All,

               It appears a rolling node by node upgrade of a protocols cluster is not possible. Ctdb is the sticking point as it won’t run with 2 different versions at the same time. Are there any plans to address this and make it a real Enterprise product?



Cheers,



Greg

_______________________________________________
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=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI&m=p5fg7X1tKGwi1BsYiw-wHTxmaG-PLihwHV0yTBQNaUs&s=3ZHS5vAoxeC6ikuOpTRLWNTpvgKEC3thI-qUgyU_hYo&e=




_______________________________________________
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=5Nn7eUPeYe291x8f39jKybESLKv_W_XtkTkS8fTR-NI&m=7bQRypv0JL7swEYobmepaynWFvV8HYtBa2_S1kAyirk&s=2bUeeDk-8VbtwU8KtV4RlENEcbpOr_GQJQvR_8gt-ug&e=


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20180308/6a259224/attachment-0002.htm>


More information about the gpfsug-discuss mailing list