- This event has passed.
SSUG::Digital: 001 – What is new in Spectrum Scale 5.0.5?
18th June 2020 @ 16:00 - 17:30 BST
At each of our user group events, we pretty much always start off with “What’s new in XXX release?” and with Spectrum Scale 5.0.5 having just been release, we’re doing the same with the new series of SSUG::Digital events.
Blog Post: What is new in Spectrum Scale 5.0.5?
Q: How would one go about obtaining an IBM Contact?
A: Do you have an IBM Sales rep already? That would be the first person to contact. If you purchased through a business partner, that is your first point of contact.
Q: Will EUS releases going to be consumed preferentially by the ESS code distributions? Maybe would make it easier to coordinate Spectrum Scale and ESS code levels when we need to update Spectrum Scale.
A: That’s the intention. Of course, based on exact timing of releases and ESS needs for new functions, it might not work out in all cases.
Q: Regarding Thin Provisioning support: Are there any test cycle for other vendors like Hitachi already happening?
A: Contact IBM to discuss the specific vendor requirements. If you have a specific piece of hardware you want to see supported, file an RFE.
Q: Does the support of compression mean that you will also support the FCM Modules in an ESS 3000 or in storages like the IBM Flash Systems 9000/7000/5000?
A: It is under evaluation to support FCM Modules of IBM Flash Systems and future ESS models with future Spectrum Scale releases.
Q: Any estimate on performance differences between Spectrum Scale 4.2.3 and Spectrum Scale 5.0.5?
A: There are incremental performance improvements in every Spectrum Scale releases. There is a significant performance jump from Spectrum Scale 4.2.3 to Spectrum Scale 5.0.0 to meet the performance commitments for CORAL. Some performance improvements have been covered at previous User Group Meetings and are available on (https://www.spectrumscaleug.org/presentations). It is also planned to provide a performance update in a future Expert Talk.
Q: Are there plans to set the all-to-all daemon connections to defaults?
A: No as default at the moment. See Expert Talk 004 “Performance Update” for more details:
Q: Is all-to-all connection establishment limited to the nodes inside a cluster or does it include all nodes from remote clusters that are already connected to a FS?
A: Local and remote.
Q: ”cp –preserver=xattr” feature is it something that 5.0.5 will enable for copies to “5.0.5”? Aka migrating data from 4.X to 5.X, or only from 5.0.5 to future versions?
A: You can copy files from Spectrum Scale 5.0.5 to previous and further version preserving extended attributes. You cannot copy the extended attributes from previous versions of Spectrum Scale to Spectrum Scale 5.0.5.
Q: Is the “cp –preserve…” a function of the RHEL release, or is there a version of cp included with Spectrum Scale?
A: The system calls listxattr, getxattr, and setxattr were extended to retrieve ACLs as extended attributes.
Q: So, then the version of the Spectrum Scale filesystem doesn’t matter, just the version of RHEL? (for the cp question).
A: Those system calls are extended by Spectrum Scale Scale at the VFS layer, so it would depend on the version of Spectrum Scale (and kernel extensions).
Q: Are there any plans for Scale Protocols to support SMB transparent failover?
A: As functionality is introduced into Samba code base, IBM look into how they can pick support up for that. It’s a topic being discussed in the Samba community for this type of failover. However, it’s known to be a hard problem.
Q: Any news on NFS4.1 support?
A: It is in plan to support it later this year (subject to IBM plan commitment disclaimer).
Q: On Spectrum Scale 4.2.3 and RHEL 7, we’ve had problems with the Ganesha daemon using steadily more memory over time, requiring us to failover / stop / start / failback periodically. Has Ganesha’s memory requirements been reduced in Spectrum Scale 5.0.5, or is there better visibility into what is driving memory usage?
A: This issue was traced back to a C library memory allocation fragmentation issue. There was a fix put into the Ganesha code to force the release of this unused fragmented memory. This fix was made available last year in the 5.0.x release stream.
Q: Hallo All, what is now the strategy to support object protocols like S3. It is missing the currency.
A: We have renewed focus on Object protocol. We plan to support the Train release in the fall release. Going forward we will try to update the Swift/S3 version once a year to make sure it stays current (subject to IBM plan commitment disclaimer). If you have specific interest in S3 applications, please contact us as we would like to hear about your requirements and use cases.
Q: We are working on a deployment of CSI 1.1.0. When is snapshot support happening.?
A: Snapshot support is planned to be available in a CSI driver update coming in late 3Q early 4Q 2020 (subject to IBM plan commitment disclaimer).
Q: Are there any news about the restriction of GUI HA with CSI?
A: This is a high priority requirement for the fall release. It’s not officially committed yet, but we are definitely trying to squeeze it in (subject to IBM plan commitment disclaimer).
User group host: Simon Thompson
|Speaker Name||Photo||Bio||Social connections|
|Chris Maestas||Chris is an Executive Architect for IBM File and Object Storage Solutions with over 20 years of experience deploying and designing IT systems for clients in various spaces. He has experience scaling performance and availability with a variety of file systems technologies. He has developed benchmark frameworks to test out systems for reliability and validate research performance data. He also has led global enablement sessions online and face to face where discussing how best to position mature technologies like Spectrum Scale with emerging technologies in Cloud, Object, Container or AI spaces.||Twitter: @cdmaestas
|Mathias Dietz||Mathias works in the Spectrum Scale development team in Kelsterbach (Germany) as a software architect responsible for Reliability, Availability and Serviceability (RAS). Part of his role is to drive reliability improvement into Spectrum Scale and improve Health & Performance monitoring, Proactive Services and CES failover.|
|Ismael Solis Moreno||Ismael works in the Spectrum Scale development team in Guadalajara Mexico as a data scientist and performance analyst. He is responsible for evaluating Spectrum Scale new features and releases performance. Part of his role is to analyze datasets to identify points of performance improvement providing insights to the development teams.||LinkedIn: https://www.linkedin.com/in/ismaelsm|