Various environments and setup options - IBM/ibm-spectrum-scale-bridge-for-grafana GitHub Wiki
IBM Storage Scale can run in many different environments, and the way you collect and visualize its performance data depends on where the cluster runs and which monitoring tools you already have. This page gives an overview of the common deployment variants and helps you choose the right setup path before you start with the installation.
/gifs/pm_data_collection_with_grafana_bridge.gif
Building blocks
| Component | Role |
|---|---|
| IBM Storage Scale performance monitoring (ZiMon) | Sensors on each node collect performance data. The pmcollector stores it. |
| IBM Storage Scale bridge for Grafana (grafana-bridge) | Reads metadata and performance data from the pmcollector and exposes it over HTTP/HTTPS. It offers an OpenTSDB-compatible API for Grafana and a Prometheus exporter endpoint. |
| Prometheus | Scrapes the metrics endpoints and stores the data for long-term analysis. |
| Grafana | Web-based dashboards. It can read directly from the bridge (OpenTSDB data source) or from Prometheus. |
Supported environment variants
The graph above shows the main variants. Storage Scale is shown with the IBM logo, and the arrows show how the performance data reaches the dashboards.
1. Classic IBM Storage Scale cluster (bare metal)
Storage Scale runs directly on physical servers. The grafana-bridge is installed on a node running the pmcollector (see Setup the grafana bridge on a classic IBM Storage Scale cluster). Two ways to consume the data:
- Grafana directly on the bridge. Grafana queries the bridge through the OpenTSDB API. This is the simplest setup and does not need any additional database.
- Prometheus in between. Prometheus scrapes the bridge's exporter endpoint, and Grafana uses Prometheus as its data source. Choose this if you need long-term storage, alerting, or want to combine several clusters (see Setup Prometheus).
2. Containerized grafana-bridge
For a classic cluster you can run the bridge in a Docker container instead of installing it on the cluster node. The container connects to the pmcollector of the Storage Scale cluster and serves the same endpoints as a regular installation. See Running the grafana bridge in a docker container.
3. Storage Scale on virtual machines
Storage Scale clusters can run on virtual machines, for example with VMs hosted on a hypervisor, or with a mixture of physical and virtual nodes. From the monitoring point of view this is the same as a classic cluster. The bridge runs next to the pmcollector and Grafana (or Prometheus) connects to it over the network.
4. IBM Storage Scale container native (CNSA) on OpenShift/Kubernetes
In a Kubernetes or OpenShift environment, Storage Scale is deployed as containers and provides persistent volumes (PVs) to the application workload. The cluster's own monitoring stack (Prometheus) scrapes the Storage Scale metrics. You can then:
- use the OpenShift console dashboards (left side of the graph), or
- connect an external or in-cluster Grafana (right side of the graph) to the cluster Prometheus.
See Setup Grafana for monitoring a CNSA cluster in a k8s OCP environment and Setup Openshift Monitoring Stack for monitoring IBM Storage Scale container native project.
5. Mixed and multi-cluster environments
A single Grafana instance can combine data from several sources, for example classic clusters, VMs, and a CNSA cluster running in the cloud. This is typically done by letting one Prometheus scrape the bridge of each cluster and adding it, or the OpenShift Prometheus, as data sources in Grafana. For an architecture overview of several clusters feeding one Prometheus, and of a tenant's view of an ESS, see Exposing IBM Storage Scale metrics to Prometheus and Grafana: multiple clusters and multitenancy. For storage and client (remote-mount) clusters, see Monitor multi-tenant environments from the provider side. For cloud and mixed setups, see How to setup Grafana instance to monitor multiple IBM Storage Scale clusters running in a cloud or mixed environment.
What can be monitored
Independent of the variant, the same kinds of data are available wherever the ZiMon sensors are enabled:
- file system, pool, and disk throughput, IOPS, and latency
- NSD server and client node activity (GPFS, network, CPU, memory, load)
- protocol services such as NFS, SMB, and object
- AFM, cluster health states, and ESS hardware metrics, depending on the enabled sensors
See the Use cases section for dashboard examples.
Choosing a setup
| Your situation | Suggested setup |
|---|---|
| One classic cluster, quick visualization | Bridge on the pmcollector node, Grafana with the OpenTSDB data source |
| Long-term storage, alerting, or several clusters | Bridge per cluster, a Prometheus server, Grafana using Prometheus as the data source |
| Bridge should not run on the cluster node | Bridge in a Docker container |
| CNSA on OpenShift | OpenShift monitoring stack, optionally with Grafana |
| Mixed (classic + CNSA + VMs) | Prometheus for classic clusters and the OpenShift Prometheus as separate Grafana data sources |
When you have decided on a setup, continue with the matching topic under Installation in the sidebar.