Skip to content

Commit

Permalink
Merge branch 'release-1.8.0' into feature_Openshift4.13_support
Browse files Browse the repository at this point in the history
  • Loading branch information
@shanmydell
shanmydell authored Jul 27, 2023
2 parents 50c9b81 + 6f35e2c commit 07a8c89
Show file tree
Hide file tree
Showing 3 changed files with 17 additions and 11 deletions.
3 changes: 2 additions & 1 deletion .github/CODEOWNERS
View file
Validating CODEOWNERS rules …
Original file line number Diff line number Diff line change
Expand Up @@ -17,5 +17,6 @@
# Raymond Sedlock (rsedlock1958)
# Sean Gallacher (gallacher)
# Yamunadevi Shanmugam (shanmydell)
# Sharon Toll (sharont58)

* @bharathsreekanth @chimanjain @Deepak-Ghivari @gallacher @mgandharva @mjsdell @prablr79 @rajendraindukuri @rajkumar-palani @rsedlock1958 @shanmydell
* @bharathsreekanth @chimanjain @Deepak-Ghivari @gallacher @mgandharva @mjsdell @prablr79 @rajendraindukuri @rajkumar-palani @rsedlock1958 @shanmydell @sharont58
13 changes: 7 additions & 6 deletions content/docs/observability/_index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,14 +7,14 @@ Description: >
---

[Container Storage Modules](https://github.com/dell/csm) (CSM) for Observability is part of the open-source suite of Kubernetes storage enablers for Dell products.
It is an OpenTelemetry agent that collects array-level metrics for Dell storage so they can be scraped into a Prometheus database. With CSM for Observability, you will gain visibility not only on the capacity of the volumes/file shares you manage with Dell CSM CSI (Container Storage Interface) drivers but also their performance in terms of bandwidth, IOPS, and response time.

It is an OpenTelemetry agent that collects array-level metrics for Dell storage so they can be exported into a Prometheus database. With CSM for Observability, you will gain visibility not only on the capacity of the volumes/file shares you manage with Dell CSM CSI (Container Storage Interface) drivers but also their performance in terms of bandwidth, IOPS, and response time.

Thanks to pre-packaged Grafana dashboards, you will be able to go through these metrics history and see the topology between a Kubernetes PV (Persistent Volume) and its translation as a LUN or file share in the backend array. This module also allows Kubernetes admins to collect array level metrics to check the overall capacity and performance directly from the Prometheus/Grafana tools rather than interfacing directly with the storage system itself.

Metrics data is collected and pushed to the [OpenTelemetry Collector](https://github.com/open-telemetry/opentelemetry-collector), so it can be processed, and exported in a format consumable by Prometheus. SSL certificates for TLS between nodes are handled by [cert-manager](https://github.com/jetstack/cert-manager).

CSM for Observability is composed of several services, each living in its own GitHub repository, that can be installed following one of the four deployments we support [here](deployment). Contributions can be made to this repository or any of the CSM for Observability repositories listed below.
CSM for Observability is composed of several services, each residing in its own GitHub repository, that can be installed following one of the four deployments we support [here](deployment). Contributions can be made to this repository or any of the CSM for Observability repositories listed below.

{{<table "table table-striped table-bordered table-sm">}}
| Name | Repository | Description |
Expand Down Expand Up @@ -49,8 +49,8 @@ CSM for Observability provides the following capabilities:
| COP/OS | Supported Versions |
|-|-|
| Kubernetes | 1.25, 1.26, 1.27 |
| Red Hat OpenShift | 4.10, 4.11, 4.12 |
| Rancher Kubernetes Engine | yes |
| Red Hat OpenShift | 4.11, 4.12, 4.13 |
| Rancher Kubernetes Engine | yes |
| RHEL | 7.x, 8.x |
| CentOS | 7.8, 7.9 |
{{</table>}}
Expand Down Expand Up @@ -93,6 +93,7 @@ CSM for Observability provides Kubernetes administrators with the topology data
| Storage Pool | The storage pool name the volume/storage class is associated with |
| Storage System Volume Name | The name of the volume on the storage system that is associated with the persistent volume |
{{</table>}}

## TLS Encryption

CSM for Observability deployment relies on [cert-manager](https://github.com/jetstack/cert-manager) to manage SSL certificates that are used to encrypt communication between various components. When [deploying CSM for Observability](./deployment), cert-manager is installed and configured automatically. The cert-manager components listed below will be installed alongside CSM for Observability.
Expand Down
12 changes: 8 additions & 4 deletions content/docs/replication/_index.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -5,7 +5,7 @@ weight: 6
Description: >
Dell Container Storage Modules (CSM) for Replication
---
[Container Storage Modules](https://github.com/dell/csm) (CSM) for Replication is part of the open-source suite of Kubernetes storage enablers for Dell products.
[Container Storage Modules](https://github.com/dell/csm) (CSM) for Replication is part of the open-source suite of Kubernetes storage enablers for Dell products.

CSM for Replication project aims to bring Replication & Disaster Recovery capabilities of Dell Storage Arrays to Kubernetes clusters.
It helps you replicate groups of volumes using the native replication technology available on the storage array and can provide you a way to restart
Expand All @@ -32,14 +32,13 @@ CSM for Replication provides the following capabilities:
| Provides a command line utility - [repctl](tools) for configuring & managing replication related resources across multiple clusters | yes | yes | yes | yes | no |
{{</table>}}


## Supported Operating Systems/Container Orchestrator Platforms

{{<table "table table-striped table-bordered table-sm">}}
| COP/OS | PowerMax | PowerStore | PowerScale | PowerFlex |
| ----------------- | ---------------- | ---------------- | ---------------- | ---------------- |
| Kubernetes | 1.25, 1.26, 1.27 | 1.25, 1.26, 1.27 | 1.25, 1.26, 1.27 | 1.25, 1.26, 1.27 |
| Red Hat OpenShift | 4.12, 4.13 | 4.11, 4.12 | 4.11, 4.12 | 4.11, 4.12 |
| Red Hat OpenShift | 4.12, 4.13 | 4.12, 4.12 | 4.12, 4.13 | 4.12, 4.13 |
| RHEL | 7.x, 8.x, 9.0 | 7.x, 8.x | 7.x, 8.x | 7.x, 8.x |
| CentOS | 7.8, 7.9 | 7.8, 7.9 | 7.8, 7.9 | 7.8, 7.9 |
| Ubuntu | 20.04 | 20.04 | 20.04 | 20.04 |
Expand All @@ -57,6 +56,7 @@ CSM for Replication provides the following capabilities:
## Details

As on the storage arrays, all replication related Kubernetes entities are required/created in pairs -

1. Pair of Kubernetes Clusters
2. Pair of replication enabled Storage classes
3. Pair of PersistentVolumes representing the replicated pair on the storage array
Expand All @@ -66,6 +66,7 @@ You can also use a single stretched Kubernetes cluster for protecting your appli
the objects still exist in pairs.

### What it does not do

* Replicate application manifests within/across clusters.
* Stop applications before the planned/unplanned migration.
* Start applications after the migration.
Expand All @@ -75,14 +76,17 @@ the objects still exist in pairs.
* Same RDF group cannot be shared across different replication modes for PowerMax.

### QuickStart

1. Install all required components:
* Enable replication during CSI driver installation
* Install CSM Replication Controller & repctl
2. Create replication enabled storage classes
3. Create `PersistentVolumeClaim` using the replication enabled storage class

### How it works

At a high level, the following happens when you create a `PersistentVolumeClaim` object using a replication enabled storage class -

1. CSI driver creates protection group on the storage array (if required)
2. CSI driver creates the volume and adds it to the protection group. There will be a corresponding group and pair on the remote storage array
3. A `DellCSIReplicationGroup` object is created in the cluster representing the protection group on the storage array
Expand All @@ -92,8 +96,8 @@ You can refer this [page](architecture) for more details about the architecture.

Once the `DellCSIReplicationGroup` & `PersistentVolume` objects have been replicated across clusters (or within the same cluster), you
can exercise the general Disaster Recovery workflows -

1. Planned Migration to the target cluster/array
2. Unplanned Migration to the target cluster/array
3. Reprotect volumes at the target cluster/array
4. Maintenance activities like - Suspend, Resume, Establish replication

0 comments on commit 07a8c89

Please sign in to comment.