Skip to content

Commit

Permalink
release v1.0.4
Browse files Browse the repository at this point in the history
  • Loading branch information
@gxglls
gxglls committed Dec 5, 2023
1 parent 927e335 commit a5d1600
Show file tree
Hide file tree
Showing 6 changed files with 981 additions and 0 deletions.
116 changes: 116 additions & 0 deletions website/versioned_docs/version-v1.0.4/basic-concepts/basic-concepts.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,116 @@
---
id: version-v1.0.4-basic-concepts
title: Basic Concepts
sidebar_label: Basic Concepts
original_id: basic-concepts
---

Before deploying and using IOMesh, familiarity with the following concepts is suggested.

[**Kubernetes**](https://kubernetes.io/)

A portable, extensible open source container orchestration platform for managing containerized workloads and services, facilitating both declarative configuration and automation.

[**Master Node**](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components)

A node that runs the control plane components of the Kubernetes cluster and manages a set of worker nodes. Typically, a Kubernetes cluster has one, three, or five master nodes.

**Worker Node**

A worker machine that runs Kubernetes node components and containerized applications. IOMesh is installed, deployed, and running on the worker node.

[**kubectl**](https://kubernetes.io/docs/reference/kubectl/)

A command line tool for communicating with the control plane of a Kubernetes cluster through the Kubernetes API.

**Stateful Application**

Applications can be stateful or stateless. Stateful applications store data on persistent disk storage for use by the server, client, and other applications. Stateless applications do not store client data on the server when switching sessions.

**IOMesh Block Storage**

The IOMesh block storage service for ensuring distributed system consistency and data coherence, managing metadata and local disks, and implementing I/O redirection and high availability.

**IOMesh Node**

A worker node in the Kubernetes cluster with a chunk pod installed.

**Chunk**

The chunk module within each IOMesh Block Storage component that manages local disks, translates access protocols, and ensures data consistency. A chunk pod on a worker node provides storage services, and each worker node can only have one chunk pod.


**Meta**

The meta module within each IOMesh Block Storage component for metadata management, including storage object management, data replica management, access control, and ensuring data consistency. A meta pod on a worker node provides metadata management, and each worker node can only have one meta pod.

**IOMesh CSI Driver**

The CSI driver that adheres to [the CSI standard](https://github.com/container-storage-interface/spec/blob/master/spec.md) and utilizes RPC (Remote Procedure Call) to manage persistent volumes, delivering reliable and consistent storage for data applications on Kubernetes. Each Kubernetes persistent volume corresponds to an iSCSI LUN in the IOMesh cluster.

**IOMesh Operator**

The IOMesh automated operations and maintenance component, allowing for roll updating IOMesh, scaling out or down nodes, and GitOps while being responsible for automatic discovery, allocation, and management of block devices.

[**Namespace**](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)

Provides a mechanism for dividing resources in the same cluster into isolated groups that can be created on demand and managed separately within a cluster.

[**StorageClass**](https://kubernetes.io/docs/concepts/storage/storage-classes/)

Provides a way to describe the classes of storage or a template for dynamically provisioning persistent volumes and allows administrators to specify different attributes belonging to a StorageClass.

[**Persistent Volume**](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)

A piece of storage in the cluster, which can be pre-provisioned by the administrator or dynamically provisioned using StorageClass. Persistent volumes, like other types of volumes, are implemented using volume plugins, but they have a lifecycle independent of any pod using PV.

[**Persistent Volume Claim**](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)

A request for storage by a user. Conceptually similar to a pod, a pod consumes node resources while a PVC consumes PV resources; a pod can request a specific amount of resources like CPU and memory, and similarly a PVC can request a specific size of storage and access mode.

[**Volume Snapshot**](https://kubernetes.io/docs/concepts/storage/volume-snapshots/)

A user request for a snapshot of a volume, which is similar to a persistent volume request.

[**Volume Snapshot Class**](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/)

Provides a way to describe the classes of storage when provisioning a volume snapshot. It allows you to specify different attributes belonging to a VolumeSnapshot. These attributes may differ among snapshots taken from the same volume on the storage system and therefore cannot be expressed by using the same StorageClass of a PersistentVolumeClaim.

[**Volume Snapshot Content**](https://kubernetes.io/docs/concepts/storage/volume-snapshots/#volume-snapshot-contents)

A snapshot taken from a volume in the cluster that has been provisioned by an administrator. It is a resource in the cluster just like a persistent volume is a cluster resource.

[**Volume Mode**](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#volume-mode)

An optional API parameter that describes the specific mode for a persistent volume. Kubernetes supports `Filesystem` and `Block` as `volumeModes`.

- `filesystem`: A volume with volume mode set to `filesystem` is mounted to a directory by the pod.
- `block`: A volume is used as a raw block device which provides the pod the fastest possible way to access a volume, without any filesystem layer between the pod and the volume.

[**Access Mode**](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes)

A PV can be mounted on a host using any supported access mode. IOMesh supports `ReadWriteOnce`, `ReadWriteMany`, and `ReadOnlyMany` access modes; however, `ReadWriteMany` and `ReadOnlyMany` are only available for PVs that use `block` as the volume mode.

- `ReadWriteOnce`: The volume can be mounted as read-write by a single node. `ReadWriteOnce` still can allow multiple pods to access the volume when the pods are running on the same node.

- `ReadWriteMany`: The volume can be mounted as read-write by many nodes.

- `ReadOnlyMany`: The volume can be mounted as read-only by many nodes.

[**Helm**](https://helm.sh/)

A package manager for Kubernetes that helps find, share, and build Kubernetes with software. It is necessary to have Helm for IOMesh installation.

[**Prometheus**](https://prometheus.io/)

An open source system monitoring and alerting toolkit that can be integrated with IOMesh to help you monitor IOMesh storage metrics in real-time and receive immediate alerts.

[**Grafana**](https://grafana.com/)

A web application that offers real-time charts, graphs, and alerts when connected to supported data sources. It is open source and can import IOMesh dashboard template and alerting rules, allowing you to visualize IOMesh storage metrics.






112 changes: 112 additions & 0 deletions website/versioned_docs/version-v1.0.4/cluster-operations/replace-failed-disk.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,112 @@
---
id: version-v1.0.4-replace-failed-disk
title: Replace Disk
sidebar_label: Replace Disk
original_id: replace-failed-disk
---

The IOMesh Dashboard displays the health status of physical disks for easy monitoring. If any disk is indicated as `Unhealthy`, `Failing`, or `S.M.A.R.T not passed`, you should replace it with a new disk as soon as possible.

**Procedure**

1. Get the meta leader pod name.
```shell
kubectl get pod -n iomesh-system -l=iomesh.com/meta-leader -o=jsonpath='{.items[0].metadata.name}'
```
```output
iomesh-meta-0
```

2. Access the meta leader pod.
```shell
kubectl exec -it iomesh-meta-0 -n iomesh-system -c iomesh-meta bash
```

3. Run the following command multiple times to verify that there are no ongoing migration or recovery tasks in the cluster.

Ensure that the output value is 0. If any field has a non-zero value, you should wait for it to reach 0.

```shell
/opt/iomesh/iomeshctl summary cluster | egrep "recovers|migrates"
```
```output
num_ongoing_recovers: 0
num_pending_recovers: 0
num_ongoing_migrates: 0
num_pending_migrates: 0
pending_migrates_bytes: 0
pending_recovers_bytes: 0
pending_migrates_bytes: 0
pending_recovers_bytes: 0
pending_migrates_bytes: 0
pending_recovers_bytes: 0
pending_migrates_bytes: 0
pending_recovers_bytes: 0
num_ongoing_recovers: 0
num_pending_recovers: 0
num_ongoing_migrates: 0
num_pending_migrates: 0
pending_migrates_bytes: 0
pending_recovers_bytes: 0
```

4. View the disk that requires replacement. In the given example, let's assume that the disk `blockdevice-66312cce9037ae891a099ad83f44d7c9` needs to be replaced.
```shell
kubectl --namespace iomesh-system get bd -o wide
```
```output
NAME NODENAME PATH FSTYPE SIZE CLAIMSTATE STATUS AGE
blockdevice-41f0c2b60f5d63c677c3aca05c2981ef qtest-k8s-0 /dev/sdc 53687091200 Unclaimed Active 29h
blockdevice-66312cce9037ae891a099ad83f44d7c9 qtest-k8s-1 /dev/sdc 69793218560 Claimed Active 44h
blockdevice-7aff82fe93fac5153b14af3c82d68856 qtest-k8s-2 /dev/sdb 69793218560 Claimed Active 44h
```
5. Run the following command to edit the `deviceMap` of the disk. Add the disk name to the field `exclude` under `devicemap`.
```shell
kubectl edit iomesh iomesh -n iomesh-system
```
```yaml
# ...
deviceMap:
# ...
dataStore:
selector:
matchExpressions:
- key: iomesh.com/bd-driverType
operator: In
values:
- HDD
matchLabels:
iomesh.com/bd-deviceType: disk
exclude:
- blockdevice-66312cce9037ae891a099ad83f44d7c9
# ...
```
6. Repeat Step 2 and 3 to verify that there are no ongoing migration or recovery tasks in the cluster.
7. Verify that the block device is in the `Unclaimed` state.
```shell
kubectl get bd blockdevice-66312cce9037ae891a099ad83f44d7c9 -n iomesh-system
```
```output
NAME NODENAME PATH FSTYPE SIZE CLAIMSTATE STATUS AGE
blockdevice-66312cce9037ae891a099ad83f44d7c9 qtest-k8s-1 /dev/sdc 69793218560 Unclaimed Active 44h
```
8. Unplug the disk. Then the disk will enter the `Inactive` state.
Run the following commands simultaneously to remove the block device and its corresponding `blockdeviceclaim`.
> _NOTE:_ It is normal to see a prompt indicating that `bdc` cannot be found when running the following commands to clear it.
```shell
kubectl patch bdc/blockdevice-66312cce9037ae891a099ad83f44d7c9 -p '{"metadata":{"finalizers":[]}}' --type=merge -n iomesh-system
kubectl patch bd/blockdevice-66312cce9037ae891a099ad83f44d7c9 -p '{"metadata":{"finalizers":[]}}' --type=merge -n iomesh-system
kubectl delete bdc blockdevice-66312cce9037ae891a099ad83f44d7c9 -n iomesh-system
kubectl delete bd blockdevice-66312cce9037ae891a099ad83f44d7c9 -n iomesh-system
```
9. Plug the new disk. Refer to [Set Up IOMesh](../deploy-iomesh-cluster/setup-iomesh) for mounting steps.
76 changes: 76 additions & 0 deletions website/versioned_docs/version-v1.0.4/cluster-operations/scale-out-cluster.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,76 @@
---
id: version-v1.0.4-scale-out-cluster
title: Scale Out Cluster
sidebar_label: Scale Out Cluster
original_id: scale-out-cluster
---

If you have the IOMesh Enterprise edition, you can scale out the cluster online without interrupting its operation. However, scaling out is not possible with the Community edition that only allows a maximum of three meta or chunk pods. When scaling out the cluster, you can choose to add chunk pods, meta pods, or both at the same time.

**Prerequisite**

Ensure an adequate number of worker nodes in the Kubernetes cluster. Each worker node can accommodate only one chunk pod and one meta pod. Therefore, if there are insufficient worker nodes, add them to the Kubernetes cluster before scaling out.

**Procedure**

1. Add chunk pods.

>_NOTE_: A single IOMesh cluster should have a minimum of three chunk pods. The maximum number of chunk pods is determined jointly by the total number of worker nodes in the Kubernetes cluster and the node count specified in the IOMesh license, with a maximum of 255 for the Enterprise edition.
To increase the capacity of the IOMesh cluster, you can choose to add chunk pods by following these steps:

- Locate `chunk` in `iomesh.yaml`, the default configuration file exported during IOMesh installation. Then modify the value of `replicaCount`, which represents the total number of chunk pods.

```yaml
chunk:
replicaCount: 5 # Enter the number of chunk pods.
```
- Apply the modification.
```shell
helm upgrade --namespace iomesh-system iomesh iomesh/iomesh --values iomesh.yaml
```
- Verify that the modification was successful.

```shell
kubectl get pod -n iomesh-system | grep chunk
```

If successful, you should see output like this:
```output
iomesh-chunk-0 3/3 Running 0 5h5m
iomesh-chunk-1 3/3 Running 0 5h5m
iomesh-chunk-2 3/3 Running 0 5h5m
iomesh-chunk-3 3/3 Running 0 5h5m
iomesh-chunk-4 3/3 Running 0 5h5m
```

2. Add meta pods.

An optional step. When deploying IOMesh, three meta pods are created in the IOMesh cluster by default. If the number of IOMesh nodes in the Kubernetes cluster is equal to or greater than five, it's recommended to increase the number of meta pods from three to five. Note that the number of supported meta pods in the IOMesh cluster should be either three or five.

- Locate `meta` in `iomesh.yaml`, the default configuration file exported during IOMesh installation. Then modify the value of `replicaCount`, which represents the number of meta pods.

```yaml
meta:
replicaCount: 5 # Change the value to 5.
```
- Apply the modification.
```shell
helm upgrade --namespace iomesh-system iomesh iomesh/iomesh --values iomesh.yaml
```
- Verify that the modification was successful.

```shell
kubectl get pod -n iomesh-system | grep meta
```

If successful, you should see output like this:
```output
iomesh-meta-0 2/2 Running 0 5h5m
iomesh-meta-1 2/2 Running 0 5h5m
iomesh-meta-2 2/2 Running 0 5h5m
iomesh-meta-3 2/2 Running 0 5h5m
iomesh-meta-4 2/2 Running 0 5h5m
```

Loading

0 comments on commit a5d1600

Please sign in to comment.