BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//Spectrum Scale User Group - ECPv6.15.10//NONSGML v1.0//EN
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALNAME:Spectrum Scale User Group
X-ORIGINAL-URL:https://www.spectrumscaleug.org
X-WR-CALDESC:Events for Spectrum Scale User Group
REFRESH-INTERVAL;VALUE=DURATION:PT1H
X-Robots-Tag:noindex
X-PUBLISHED-TTL:PT1H
BEGIN:VTIMEZONE
TZID:Europe/London
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:20190331T010000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:20191027T010000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:20200329T010000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:20201025T010000
END:STANDARD
BEGIN:DAYLIGHT
TZOFFSETFROM:+0000
TZOFFSETTO:+0100
TZNAME:BST
DTSTART:20210328T010000
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:+0100
TZOFFSETTO:+0000
TZNAME:GMT
DTSTART:20211031T010000
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20201006T160000
DTEND;TZID=Europe/London:20201006T170000
DTSTAMP:20260407T085558
CREATED:20200921T123555Z
LAST-MODIFIED:20220128T180818Z
UID:2011-1602000000-1602003600@www.spectrumscaleug.org
SUMMARY:SSUG::Digital: 006 - Persistent Storage for Kubernetes and OpenShift environments
DESCRIPTION:This episode will discuss the Spectrum Scale Container Storage Interface (CSI). CSI is a standard for exposing arbitrary block and file storage systems to containerized workloads on container orchestration systems like Kubernetes and OpenShift. Spectrum Scale CSI provides your containers fast access to files stored in Spectrum Scale with capabilities such as dynamic provisioning of volumes and read-write-many access. \n        \n        \n            \n                \n                    \n                \n               \n            \n        \n        \n  \n \nDownload slides here \nEpisode 2:  Best Practices for building a stretched cluster \nQ&A\nQ: ­This slide (titled Spectrum Scale CSI Driver – Architecture) shows CPU architecture is x86­\nA: ­Yes\, with Spectrum Scale CSI Driver 2.0.0 only x86 is supported. The support for other architectures (IBM Power and IBM Z) will be provided in upcoming releases­ (IBM usual roadmap disclaimers apply). \nQ: ­Is the management of storage class available via Ansible?­\nA: ­Setting up a storage class is a one-time operation. While it might be done using Ansible (and Kubernetes integration modules)\, clients usually do the management using the Kubernetes or Openshift CLI or GUI.­ \nQ: ­Will the slides be provided post this presentation?\nA: ­Yes. You will find the chart decks\, recordings\, Q&A and related information for all past talks including this one at https://www.spectrumscaleug.org/experttalks/. \nQ:  Once you have CSI driver support for non x86_64 platforms\, will the Spectrum Scale cluster be able to be heterogeneous (AIX\, Linux\, x86_64 and ppc64le)? Will this cluster support AIX NSD only nodes?­\nA: ­ In the first release for non x86_64 platforms\, all worker nodes that have Spectrum Scale client installed need to  be of same CPU architecture and the same operating system. If there are AIX NSD nodes\, those must be outside of Kubernetes cluster.­ AIX NSD only nodes might be integrated by remote mounting the storage cluster to a client Spectrum Scale cluster that runs the Kubernetes workload. \nQ: ­Is Network Load Balancer a per-requisite must have for the CSI deployment?­\nA: ­No it isn’t.­ \nQ: ­ Is there a possibility to have Spectrum Scale clients installed within containers?\n ­A: ­We are working on a capability called Container Native Spectrum Scale (CNSS) where Spectrum Scale will run inside a container.  The initial release is planned for December 2020.  (Disclaimer: All dates are subject to change; IBM usual roadmap disclaimers apply)­ \nQ: Do we need to have an x86 “only” Spectrum Scale/OpenShift cluster and a ppc64le “only” Spectrum Scale/OpenShift cluster?\nA: ­The requirement of same CPU architecture and same operating system is only for Spectrum Scale Client node which are part of Kubernetes/ Openshift cluster. NSD server can be of other platform (as per Spectrum Scale support matrix at https://www.ibm.com/support/knowledgecenter/STXKQY/gpfsclustersfaq.html) \nQ: ­ Any plans for ability to self-provision Spectrum Scale clusters with containers?­\nA: ­Container Native Spectrum Scale (CNSS) will have an Operator that will deploy and configure a Spectrum Scale cluster automatically.  It will also remote mount the filesystem from a Spectrum Scale Storage Cluster. \nQ: ­One of the issues that we are trying to solve is to isolate Spectrum Scale IO with respect to each tenant/application/user on a single server just like how we can isolate cpu/network with cgroups. Would spectrum scale on containers help us in isolating or qos with storage IO?­\nA: ­Running Spectrum Scale in a container or CSI by itself will not address QoS.  A new fileset based QoS capability\, with CSI\, will be able to handle this in a future release­. (Disclaimer: All dates are subject to change; IBM usual roadmap disclaimers apply) \nQ: ­Does OpenStack have to be managed via the web gui. Can it be controlled via a CLI?­\nA: ­You are free to use either CLI or GUI.­­­ \nUser group host: Bill Anderson\nSpeakers:\n\n\n\n\n	Speaker NamePhotoBio\n\n\n\n\n	Smita RautSmita Raut is a Senior Software Engineer with IBM Storage Labs in Pune\, India. She works with the IBM Spectrum Scale development team as the architect for persistent storage for containers. In her nine years with IBM\, she has lead the development on various projects\, including Object protocol for IBM Spectrum Scale and enablement of IBM Spectrum Scale on public cloud. She is an active technical blogger and has published several blogs on object protocol and container storage interface driver.\n\n\n	Harald SeippHarald Seipp is a Senior Technical Staff Member with IBM Systems in Germany. He is the founder and Technical Leader of the Center of Excellence for Cloud Storage as part of the EMEA Storage Competence Center. He is providing guidance to worldwide IBM teams across organizations\, and works with customers and IBM Business Partners across EMEA to create and implement complex storage cloud architectures. His more than 25 years of technology experience includes previous job roles as Software Developer\, Software Development Leader\, Lead Developer\, and Architect for successful software products\, and co-inventor of an IBM storage product. He holds various patents on storage and networking technology.\n\n\n	Renar GrunenbergRenar Grunenberg is since 27 years at HuK-Coburg. He leads the backup and storage team and is responsible for all the storage and backup stuff in his department and company. Renar has 15 years experience with Spectrum Scale including CES\, CSI\, ESS and normal core function. In this episode Renar will discuss a use case for Kafka self-service with K8s and Spectrum Scale CSI.\n\n\n	Simon ThompsonSimon Thompson is the Research Computing Infrastructure Architect within Advanced Research Computing at the University of Birmingham. He oversees the infrastructure and systems team\, running the University's HPC and research data systems. This involves experimenting (and breaking) new technology. Simon is also chair of the Spectrum Scale user group in the UK.
URL:https://www.spectrumscaleug.org/event/ssugdigital-persistent-storage-for-containers-with-spectrum-scale/
LOCATION:Digital Event
CATEGORIES:Expert Talks
END:VEVENT
BEGIN:VEVENT
DTSTART;TZID=Europe/London:20201021T160000
DTEND;TZID=Europe/London:20201021T170000
DTSTAMP:20260407T085558
CREATED:20200921T123915Z
LAST-MODIFIED:20220128T181136Z
UID:2014-1603296000-1603299600@www.spectrumscaleug.org
SUMMARY:SSUG::Digital: 007 - Manage the lifecycle of your files using the policy engine
DESCRIPTION:This episode will provide a comprehensive introduction to the IBM Spectrum Scale policy engine. It highlights the underlying architecture and how policies are executed in a IBM Spectrum Scale cluster. This episode also discusses example rules and policies facilitating Information Lifecycle Management accompanied with practical tips. \n        \n        \n            \n                \n                    \n                \n               \n            \n        \n        \n  \nDownload slides here \nReferences\n\nWhitepaper: IBM Spectrum Scale ILM and Archiving Policies – A practical Guide\nSpectrum Scale ILM policy examples and scripts\nApache Tika\n\nQ&A\nQ: ­Which type of nodes participate in policy execution?\nA: Depends on the nodes specified with the -N option of the mmapplypolicy command. If the -N option is not specified\, then the command runs parallel instances of the policy code on the nodes that are specified by the defaultHelperNodes attribute of the mmchconfig command. If -N is specified then the command runs parallel instances on the nodes or node class specified with the -N option. For more information see the IBM Spectrum Scale knowledge center: https://www.ibm.com/support/knowledgecenter/STXKQY_5.0.5/com.ibm.spectrum.scale.v5r05.doc/bl1adm_mmapplypolicy.htm \nQ: ­Can I somehow identify the type of a file via the policy engine\, e.g. via the magicbyte? Or do I have to rely on the file extension?­\nA: The policy engine does not allow access to the data – only the file’s metadata including extended attributes­ can be evaluated by the policy engine. To identify the type of a file with the policy engine an EXTERNAL LIST rule can be used along with an external script that determines the type of files. \nQ: ­Will the external tool process the filelist in parallel on all nodes\, which are used to generate the filelist?\nA: Yes\, if an external tool or interface script is defined in an EXTERNAL POOL rule then this script is executed on all nodes that are specified with the -N option of the mmapplypolicy command. This assumes that all node specified with the -N option have access to the interface script. If this is not the case\, then the policy run fails. You can control the number of instances of the external tool pool with the option -m and the number of files passed to one instance of the external pool with the option -B of the mmapplypolicy command. \nQ: Are they any limitations or recommendations around length of rules in policy files? For example\, we have ~750 filesets we want to place data on a specific pool. Should we just have one rule\, or many rules for this?\nA: Placement policies will be stored in a single file. The challenge is not so much the length of the file but the number of placement rules contained in the policy files. Whenever a file is created the policy engine must walk through all rules to find a match. If there are many rules\, this will delay the file creation. Therefore I recommend to keep the number of placement rules low. For example\, you could organize the placement policies by storage pools. There is a limit of eight storage pools\, thus this would lead to maximal eight placement rules. In each rule you can use the FILESET statement to specify multiple filesets to be placed on a pool. \nUser group host: Bob Oesterlin\nSpeakers:\n\n\n\n\n	Speaker NamePhotoBio\n\n\n\n\n	Nils HausteinNils Haustein is Senior Technical Staff Member with IBM Systems. He is responsible for design and implementation of backup\, archiving\, file and object storage solutions. Nils provides guidance to IBM teams and consults with clients and business partners world wide. Nils has co-authored the book "Storage Networks explained". As leading IBM Master Inventor he has created more than 170 patents and is a respected mentor for the technical community world wide.
URL:https://www.spectrumscaleug.org/event/ssugdigital-spectrum-scale-ilm-policy-engine/
LOCATION:Digital Event
CATEGORIES:Expert Talks
END:VEVENT
END:VCALENDAR