Skip to content

Commit a5d1600

Browse files
gxgllsgxglls
committed
release v1.0.4
1 parent 927e335 commit a5d1600

File tree

6 files changed

+981
-0
lines changed

6 files changed

+981
-0
lines changed

‎website/versioned_docs/version-v1.0.4/basic-concepts/basic-concepts.md

+116
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,116 @@
1+
---
2+
id: version-v1.0.4-basic-concepts
3+
title: Basic Concepts
4+
sidebar_label: Basic Concepts
5+
original_id: basic-concepts
6+
---
7+
8+
Before deploying and using IOMesh, familiarity with the following concepts is suggested.
9+
10+
[**Kubernetes**](https://kubernetes.io/)
11+
12+
A portable, extensible open source container orchestration platform for managing containerized workloads and services, facilitating both declarative configuration and automation.
13+
14+
[**Master Node**](https://kubernetes.io/docs/concepts/overview/components/#control-plane-components)
15+
16+
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.
17+
18+
**Worker Node**
19+
20+
A worker machine that runs Kubernetes node components and containerized applications. IOMesh is installed, deployed, and running on the worker node.
21+
22+
[**kubectl**](https://kubernetes.io/docs/reference/kubectl/)
23+
24+
A command line tool for communicating with the control plane of a Kubernetes cluster through the Kubernetes API.
25+
26+
**Stateful Application**
27+
28+
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.
29+
30+
**IOMesh Block Storage**
31+
32+
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.
33+
34+
**IOMesh Node**
35+
36+
A worker node in the Kubernetes cluster with a chunk pod installed.
37+
38+
**Chunk**
39+
40+
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.
41+
42+
43+
**Meta**
44+
45+
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.
46+
47+
**IOMesh CSI Driver**
48+
49+
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.
50+
51+
**IOMesh Operator**
52+
53+
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.
54+
55+
[**Namespace**](https://kubernetes.io/docs/concepts/overview/working-with-objects/namespaces/)
56+
57+
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.
58+
59+
[**StorageClass**](https://kubernetes.io/docs/concepts/storage/storage-classes/)
60+
61+
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.
62+
63+
[**Persistent Volume**](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
64+
65+
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.
66+
67+
[**Persistent Volume Claim**](https://kubernetes.io/docs/concepts/storage/persistent-volumes/)
68+
69+
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.
70+
71+
[**Volume Snapshot**](https://kubernetes.io/docs/concepts/storage/volume-snapshots/)
72+
73+
A user request for a snapshot of a volume, which is similar to a persistent volume request.
74+
75+
[**Volume Snapshot Class**](https://kubernetes.io/docs/concepts/storage/volume-snapshot-classes/)
76+
77+
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.
78+
79+
[**Volume Snapshot Content**](https://kubernetes.io/docs/concepts/storage/volume-snapshots/#volume-snapshot-contents)
80+
81+
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.
82+
83+
[**Volume Mode**](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#volume-mode)
84+
85+
An optional API parameter that describes the specific mode for a persistent volume. Kubernetes supports `Filesystem` and `Block` as `volumeModes`.
86+
87+
- `filesystem`: A volume with volume mode set to `filesystem` is mounted to a directory by the pod.
88+
- `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.
89+
90+
[**Access Mode**](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes)
91+
92+
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.
93+
94+
- `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.
95+
96+
- `ReadWriteMany`: The volume can be mounted as read-write by many nodes.
97+
98+
- `ReadOnlyMany`: The volume can be mounted as read-only by many nodes.
99+
100+
[**Helm**](https://helm.sh/)
101+
102+
A package manager for Kubernetes that helps find, share, and build Kubernetes with software. It is necessary to have Helm for IOMesh installation.
103+
104+
[**Prometheus**](https://prometheus.io/)
105+
106+
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.
107+
108+
[**Grafana**](https://grafana.com/)
109+
110+
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.
111+
112+
113+
114+
115+
116+

‎website/versioned_docs/version-v1.0.4/cluster-operations/replace-failed-disk.md

+112
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,112 @@
1+
---
2+
id: version-v1.0.4-replace-failed-disk
3+
title: Replace Disk
4+
sidebar_label: Replace Disk
5+
original_id: replace-failed-disk
6+
---
7+
8+
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.
9+
10+
**Procedure**
11+
12+
1. Get the meta leader pod name.
13+
```shell
14+
kubectl get pod -n iomesh-system -l=iomesh.com/meta-leader -o=jsonpath='{.items[0].metadata.name}'
15+
```
16+
```output
17+
iomesh-meta-0
18+
```
19+
20+
2. Access the meta leader pod.
21+
```shell
22+
kubectl exec -it iomesh-meta-0 -n iomesh-system -c iomesh-meta bash
23+
```
24+
25+
3. Run the following command multiple times to verify that there are no ongoing migration or recovery tasks in the cluster.
26+
27+
Ensure that the output value is 0. If any field has a non-zero value, you should wait for it to reach 0.
28+
29+
```shell
30+
/opt/iomesh/iomeshctl summary cluster | egrep "recovers|migrates"
31+
```
32+
```output
33+
num_ongoing_recovers: 0
34+
num_pending_recovers: 0
35+
num_ongoing_migrates: 0
36+
num_pending_migrates: 0
37+
pending_migrates_bytes: 0
38+
pending_recovers_bytes: 0
39+
pending_migrates_bytes: 0
40+
pending_recovers_bytes: 0
41+
pending_migrates_bytes: 0
42+
pending_recovers_bytes: 0
43+
pending_migrates_bytes: 0
44+
pending_recovers_bytes: 0
45+
num_ongoing_recovers: 0
46+
num_pending_recovers: 0
47+
num_ongoing_migrates: 0
48+
num_pending_migrates: 0
49+
pending_migrates_bytes: 0
50+
pending_recovers_bytes: 0
51+
```
52+
53+
4. View the disk that requires replacement. In the given example, let's assume that the disk `blockdevice-66312cce9037ae891a099ad83f44d7c9` needs to be replaced.
54+
```shell
55+
kubectl --namespace iomesh-system get bd -o wide
56+
```
57+
```output
58+
NAME NODENAME PATH FSTYPE SIZE CLAIMSTATE STATUS AGE
59+
blockdevice-41f0c2b60f5d63c677c3aca05c2981ef qtest-k8s-0 /dev/sdc 53687091200 Unclaimed Active 29h
60+
blockdevice-66312cce9037ae891a099ad83f44d7c9 qtest-k8s-1 /dev/sdc 69793218560 Claimed Active 44h
61+
blockdevice-7aff82fe93fac5153b14af3c82d68856 qtest-k8s-2 /dev/sdb 69793218560 Claimed Active 44h
62+
```
63+
64+
5. Run the following command to edit the `deviceMap` of the disk. Add the disk name to the field `exclude` under `devicemap`.
65+
66+
```shell
67+
kubectl edit iomesh iomesh -n iomesh-system
68+
```
69+
70+
```yaml
71+
# ...
72+
deviceMap:
73+
# ...
74+
dataStore:
75+
selector:
76+
matchExpressions:
77+
- key: iomesh.com/bd-driverType
78+
operator: In
79+
values:
80+
- HDD
81+
matchLabels:
82+
iomesh.com/bd-deviceType: disk
83+
exclude:
84+
- blockdevice-66312cce9037ae891a099ad83f44d7c9
85+
# ...
86+
```
87+
88+
6. Repeat Step 2 and 3 to verify that there are no ongoing migration or recovery tasks in the cluster.
89+
90+
7. Verify that the block device is in the `Unclaimed` state.
91+
```shell
92+
kubectl get bd blockdevice-66312cce9037ae891a099ad83f44d7c9 -n iomesh-system
93+
```
94+
```output
95+
NAME NODENAME PATH FSTYPE SIZE CLAIMSTATE STATUS AGE
96+
blockdevice-66312cce9037ae891a099ad83f44d7c9 qtest-k8s-1 /dev/sdc 69793218560 Unclaimed Active 44h
97+
```
98+
99+
8. Unplug the disk. Then the disk will enter the `Inactive` state.
100+
101+
Run the following commands simultaneously to remove the block device and its corresponding `blockdeviceclaim`.
102+
103+
> _NOTE:_ It is normal to see a prompt indicating that `bdc` cannot be found when running the following commands to clear it.
104+
105+
```shell
106+
kubectl patch bdc/blockdevice-66312cce9037ae891a099ad83f44d7c9 -p '{"metadata":{"finalizers":[]}}' --type=merge -n iomesh-system
107+
kubectl patch bd/blockdevice-66312cce9037ae891a099ad83f44d7c9 -p '{"metadata":{"finalizers":[]}}' --type=merge -n iomesh-system
108+
kubectl delete bdc blockdevice-66312cce9037ae891a099ad83f44d7c9 -n iomesh-system
109+
kubectl delete bd blockdevice-66312cce9037ae891a099ad83f44d7c9 -n iomesh-system
110+
```
111+
9. Plug the new disk. Refer to [Set Up IOMesh](../deploy-iomesh-cluster/setup-iomesh) for mounting steps.
112+

‎website/versioned_docs/version-v1.0.4/cluster-operations/scale-out-cluster.md

+76
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,76 @@
1+
---
2+
id: version-v1.0.4-scale-out-cluster
3+
title: Scale Out Cluster
4+
sidebar_label: Scale Out Cluster
5+
original_id: scale-out-cluster
6+
---
7+
8+
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.
9+
10+
**Prerequisite**
11+
12+
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.
13+
14+
**Procedure**
15+
16+
1. Add chunk pods.
17+
18+
>_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.
19+
20+
To increase the capacity of the IOMesh cluster, you can choose to add chunk pods by following these steps:
21+
22+
- 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.
23+
24+
```yaml
25+
chunk:
26+
replicaCount: 5 # Enter the number of chunk pods.
27+
```
28+
- Apply the modification.
29+
30+
```shell
31+
helm upgrade --namespace iomesh-system iomesh iomesh/iomesh --values iomesh.yaml
32+
```
33+
- Verify that the modification was successful.
34+
35+
```shell
36+
kubectl get pod -n iomesh-system | grep chunk
37+
```
38+
39+
If successful, you should see output like this:
40+
```output
41+
iomesh-chunk-0 3/3 Running 0 5h5m
42+
iomesh-chunk-1 3/3 Running 0 5h5m
43+
iomesh-chunk-2 3/3 Running 0 5h5m
44+
iomesh-chunk-3 3/3 Running 0 5h5m
45+
iomesh-chunk-4 3/3 Running 0 5h5m
46+
```
47+
48+
2. Add meta pods.
49+
50+
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.
51+
52+
- 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.
53+
54+
```yaml
55+
meta:
56+
replicaCount: 5 # Change the value to 5.
57+
```
58+
- Apply the modification.
59+
```shell
60+
helm upgrade --namespace iomesh-system iomesh iomesh/iomesh --values iomesh.yaml
61+
```
62+
- Verify that the modification was successful.
63+
64+
```shell
65+
kubectl get pod -n iomesh-system | grep meta
66+
```
67+
68+
If successful, you should see output like this:
69+
```output
70+
iomesh-meta-0 2/2 Running 0 5h5m
71+
iomesh-meta-1 2/2 Running 0 5h5m
72+
iomesh-meta-2 2/2 Running 0 5h5m
73+
iomesh-meta-3 2/2 Running 0 5h5m
74+
iomesh-meta-4 2/2 Running 0 5h5m
75+
```
76+

0 commit comments

Comments
 (0)