IBM Spectrum Scale 5.0.3 has been released and here are the features now available for IBM Z:
Installation toolkit support for configuration, installation and deployment for SLES 15 on IBM Z
Storage Enabler for Containers (SEC)
IBM Storage Enabler for Containers allows IBM Spectrum Scale to be used as persistent volumes for stateful applications running in Kubernetes clusters.Â Through the IBM Storage Enabler for Containers,
Kubernetes persistent volumes (PVs) can be provisioned from IBM Spectrum Scale. Thus, IBMÂ Spectrum ScaleÂ can be accessed by containers and used with stateful microservices,
such as database applications (MongoDB, PostgreSQL etc).Â IBM Storage Enabler for Containers uses Kubernetes dynamic provisioning for creating and deleting volumes on IBM Spectrum Scale.
With Spectrum Scale 5.0.3 the following two cloud services are supported:
Transparent cloud tiering (TCT) is a feature of IBM Spectrum Scale that provides a native cloud storage tier. It allows data center administrators to free up IBM Spectrum Scale storage capacity,
by moving out cooler data to the cloud storage, reducing capital and operational expenditures. Tiering can also be used to archive an extra copy of your data using pre-migration, a function that copies data rather than moving it.
The Transparent cloud tiering feature leverages the existing ILM policy query language semantics available in IBM Spectrum Scale, and administrators can define policies to tier data to cloud storage.
Cloud data sharing is an IBM Spectrum Scale Cloud services that allows a way to set up sharing between IBM Spectrum Scale and various types of object storage, including IBM Cloud Object Storage.
Furthermore, for export of data to object storage the service can be invoked from an ILM policy to allow for periodic sharing of data based on when the policy is run.
For import, you can specify a list of files that you can use to move object storage (by using your IBM Cloud data sharing service) into the IBM Spectrum Scale cluster.
The Cloud services use the following cloud providers:
– IBM Cloud Object Storage (version 126.96.36.199, 188.8.131.52, 3.9, and 184.108.40.206)
– IBM Cloud Object Storage on IBM SoftLayer and IBM Bluemix
– OpenStack Swift with Swift version 2.13 and below
– Amazon Web Services S3
– Swift3 on OpenStack Swift version 2.13, 1.1 and above
– Microsoft Azure object storage service
Watch Folder / Clustered Watch
The Watch Folder feature provides a new method of monitoring and performing actions on file system events
inÂ IBM Spectrum Scale.Â By monitoring file accesses, the user is able to act in response to file access events.
For example, an administrator can set up a watch on an independent fileset and have every fileÂ CLOSEÂ event
within the fileset be logged into an output file.Â The log file can then be parsed periodically and allows further
processing likeÂ move the filesÂ that were closed to another data pool based on a migrationÂ policy.
Watch folder is designed to emulate Linux inotify, but it has the following significant advantages:
– It is designed for IBM Spectrum Scale, which is a distributed file system. This means that a watch that is set up on any of the IBM Spectrum Scale nodes receives file access event notifications even if the watched folder, fileset or inode space is accessed from another node.
– It is possible to watch subfolders with inode spaces and filesets by only watching the root of those constructs. In contrast, if it is needed to watch subfolders using Linux inotify, a watch would have to be installed on each of the subfolders.
A watch folder uses the Spectrum Scale C API to run as an executable C program on a node within the cluster
– utilizes message queues to receive events from multiple cluster nodes and consume events on the node runningÂ the application
– lightweight events are generated by elibigible nodes within the cluster and from remote clusters
With a clustered watch, it is possible to watch file operations across clusters using a centralized tool that has scalability and
resiliency built-in. An entire file system, fileset, or inode space can be watched. It is possible to specify all or a subset of
events (for all supported file access events refer to the Spectrum Scale knowledgecenter).
Similar to file audit logging, clustered watch captures file system activities at the IBM Spectrum Scale file
system level, generates event notifications for those activities, and streams the notifications to topics within the message
queue. Unlike file audit logging, the event notifications are then consumed by a conduit and sent to an external sink that
can be managed.
RPM and package requirements
Every node that is capable of hosting any combination of brokers, ZooKeepers, producers, and consumers
must have the following packages installed:
– GPFS Java (gpfs.java rpm/package)
– For RHEL, theÂ librdkafkaÂ package requires theÂ openssl-develÂ andÂ cyrus-sasl-develÂ packages For Ubuntu, theÂ librdkafkaÂ package requires theÂ libssl-devÂ andÂ libsasl2-devÂ packages
– librdkafkaÂ (gpfs.librdkafka rpm/package)
– Kafka (gpfs.kafka rpm/package)
OS and hardware requirements
– RHEL 7.x or Ubuntu 16.04/16.04.01
– Linux Kernel on all platforms must be greater than or equal to 31000123.
– Minimum of three Linux quorum nodes running on approved OS and hardware (ZooKeepers).
– Minimum of three nodes to act as message queue servers (brokers) running on approved OS and hardware