The KumoScale control plane is implemented as a collection of containerized processes which are deployed and monitored by a small Kubernetes® cluster. For failure tolerance, this management cluster should consist of a minimum of three bare metal systems or virtual machines, ideally located in separate fault domains.
All KumoScale control plane services are resilient to failure or partition of the systems on which they run. The system metadata and state is stored redundantly in KumoScale storage nodes, so control plane services can restore their state and continue operating if it becomes necessary for the Kubernetes master to restart them in a healthy node.
For more information about installation and deployment visit KumoScale Management Cluster .
KumoScale Management Services Implementation
The KumoScale Provisioner Service provides a powerful abstraction between the data center’s orchestration or provisioning framework and the KumoScale storage infrastructure.
The Provisioner Service’s main task is to accept requests for volumes (along with a storage class specification detailing the volume’s requirements) and return the logical identity and network location where the requested volume can be accessed. Behind the scenes, the Provisioner implements sophisticated logic for determining the best Storage Node on which to provision the volume, and how it should be mapped to the physical SSDs in that node to achieve the specified requirements. The provisioning process takes into account a variety of factors to arrive at an optimal decision. Some of these are: Resilience requirements; QoS requirements; capacity, and IOPs and bandwidth utilization at the drive and node level.
KumoScale software supplies a rich telemetry feed, containing granular time-series measurements of workload offered and performance delivered. Telemetry data is tagged so that workload and performance can be analyzed on a per-volume, per-interface, per-drive, or per storage class (user application) basis. The KumoScale telemetry provider is built to allow simple adaptation to any user framework – either push or pull model.
Similarly, KumoScale technology provides a stream of log information that records all volume provisioning and drive mapping changes, changes in the hardware or software configuration, and periodically records system state and health. Along with telemetry time series, this log stream allows users to correlate point-in-time events with resulting changes in I/O rates or performance.
The modern cloud data center is no longer the province of proprietary “panes of glass” – instead, all infrastructure must be monitored and controlled together. KumoScale telemetry and logging interfaces are designed to be easily adapted to the frameworks of your choice. Telemetry integration is currently available for open source frameworks Graphite® & Prometheus®. Logging in the popular Syslog format is available.
KumoScale software operates under three primary control frameworks. They are:
The Container Storage Interface (CSI) is an open source API developed under the Cloud Native Computing Foundation. CSI provides a uniform way for storage providers to make block storage accessible to cloud orchestration frameworks in a standardized way, while still allowing great flexibility in terms of the requirements applications can place on their storage resources. It has been adopted by Kubernetes orchestration (as of v 1.13), Apache® Mesos® orchestration (v 1.5), and others, and is supported by a growing list of storage array providers. A number of aspects of the KumoScale API are modeled after CSI constructs and are carried over to the other supported environments.
In particular, a concept that plays a central role in KumoScale operations is the Storage Class and the Storage Class Specification. The Storage Class Spec is a named set of key-value pairs which is passed along with a volume request, and is used to communicate requirements for that volume to KumoScale in a compact and uniform way. In CSI the Storage Class is limited to capacity and a few other simple metrics. KumoScale has extended it to provide a convenient way for users to identify the application associated with each volume requested, and the associated performance (QoS) requirements, quotas, owners/access rights, data protection needs, and more. This application-centric labeling is then carried through all of KumoScale’s management and reporting, so that users see performance data filtered and expressed in the ways that matter to them.
The KumoScale Analytics Service monitors telemetry and log data for I/O activity across all Storage Nodes. It tracks the volume map, wear state and performance profile of each SSD, and scores the Quality of Service delivered by each Storage Node to each storage class over time. The service then uses sophisticated analytic performance and actuarial wear models to compute optimal mapping of user workloads to drives. The service commands Storage Nodes to migrate volumes when appropriate, and provides guidance to the Provisioner Service on how to provision new volumes.
The analytics service also plays an important role in KumoScale support. When helping customers troubleshoot infrastructure problems or plan for future growth, the Analytics Service can provide KIOXIA support engineers with a detailed historical view of system operation and performance.
The KumoScale GUI Service is an optional, browser-based management utility which enables quick and easy installation, configuration and control of KumoScale appliances at small scale. It is primarily useful for proof-of-concept or demonstration scenarios, when integration with automation tools hasn’t yet been completed. The GUI Server is a stand-alone Java application. It works via the KumoScale REST API to configure and monitor Storage Nodes and renders an interactive control panel via a web browser.