Skip to content

Commit

Permalink
release v1.0.2
Browse files Browse the repository at this point in the history
  • Loading branch information
@gxglls
gxglls committed Oct 20, 2023
1 parent 630d15b commit 17b5b21
Show file tree
Hide file tree
Showing 5 changed files with 324 additions and 0 deletions.
116 changes: 116 additions & 0 deletions website/versioned_docs/version-v1.0.2/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.2-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 self-developed 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.






77 changes: 77 additions & 0 deletions website/versioned_docs/version-v1.0.2/cluster-operations/scale-down-cluster.md
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,77 @@
---
id: version-v1.0.2-scale-down-cluster
title: Scale Down Cluster
sidebar_label: Scale Down Cluster
original_id: scale-down-cluster
---

You can scale down the IOMesh cluster by removing chunk pods in the Kubernetes worker nodes.

**Precautions**
- You can only delete chunk pods. Deleting meta pods is not supported.
- You can only remove one chunk pod at a time.
- Each chunk pod is created sequentially and given a unique number by `StatefulSet`, and you should remove them in reverse creation order. For example, if there are 5 chunk pods `iomesh-chunk-0`, `iomesh-chunk-1`, `iomesh-chunk-2`, `iomesh-chunk-3`, `iomesh-chunk-4`, deletion should start with `iomesh-chunk-4`.


**Procedure**

The following example reduces the number of chunk pods by removing `iomesh-chunk-2` on the node `k8s-worker-2`.

1. Run the `ip a` command on the `k8s-worker-2` node to obtain the unique IP within the data CIDR. Assume the IP is `192.168.29.23`.

2. Run the following command. Locate the `status.summary.chunkSummary.chunks` field and find the ID of `chunks` whose IP is `192.168.29.23`.
```shell
kubectl get iomesh iomesh -n iomesh-system -o yaml
```
```yaml
chunks:
- id: 2 # The chunk ID.
ip: 192.168.29.23
```

3. 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
```
4. Access the meta leader pod.
```shell
kubectl exec -it iomesh-meta-0 -n iomesh-system -c iomesh-meta bash
```

5. Perform `chunk unregister`. Replace <chunk_id> with the chunk ID obtained from Step 2.

Depending on the size of the data in the chunk, executing this command can take from a few minutes to several hours.
```
/opt/iomesh/iomeshctl chunk unregister <chunk_id>
```

6. Find `chunk` in `iomesh.yaml`, the default configuration file exported during IOMesh installation, and then edit `replicaCount`.
```yaml
chunk:
replicaCount: 3 # Reduce the value to 2.
```

7. Apply the modification.

```shell
helm upgrade --namespace iomesh-system iomesh iomesh/iomesh --values iomesh.yaml
```

8. Verify that the number of chunk pods is reduced.

```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
```

9. Run the following command. Then locate the `status.summary.chunkSummary.chunks` field to verify that the chunk was removed.
```shell
kubectl get iomesh iomesh -n iomesh-system -o yaml
```
76 changes: 76 additions & 0 deletions website/versioned_docs/version-v1.0.2/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.2-scale-out-cluster
title: Scale Out Cluster
sidebar_label: Scale Out Cluster
original_id: scale-out-cluster
---

If you have the Enterprise Edition of IOMesh software, you can scale it out online without disrupting the cluster's operation. However, scaling out is not possible with the Community Edition, which limits the number of meta or chunk pods to three. During scaling out, you can choose to add chunk pods, meta pods, or both simultaneously.

**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:

- Find `chunk` in `iomesh.yaml`, the default configuration file exported during IOMesh installation, and then edit `replicaCount`. The value of `replicaCount` is the total number of chunk pods after scaling out.

```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.

- Find `meta` in `iomesh.yaml`, the default configuration file exported during IOMesh installation, and then edit `replicaCount`.

```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
```

54 changes: 54 additions & 0 deletions website/versioned_sidebars/version-v1.0.2-sidebars.json
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,54 @@
{
"version-v1.0.2-docs": {
"About IOMesh": [
"version-v1.0.2-introduction/introduction",
"version-v1.0.2-basic-concepts/basic-concepts"
],
"Deploy IOMesh": [
"version-v1.0.2-deploy-iomesh-cluster/prerequisites",
"version-v1.0.2-deploy-iomesh-cluster/install-iomesh",
"version-v1.0.2-deploy-iomesh-cluster/setup-iomesh",
"version-v1.0.2-deploy-iomesh-cluster/activate-license"
],
"Volume Operations": [
"version-v1.0.2-volume-operations/create-storageclass",
"version-v1.0.2-volume-operations/create-pv",
"version-v1.0.2-volume-operations/authenticate-pv",
"version-v1.0.2-volume-operations/expand-pv",
"version-v1.0.2-volume-operations/clone-pv"
],
"VolumeSnapshot Operations": [
"version-v1.0.2-volumesnapshot-operations/create-snapshotclass",
"version-v1.0.2-volumesnapshot-operations/create-volumesnapshot",
"version-v1.0.2-volumesnapshot-operations/restore-volumesnapshot"
],
"Deploy Stateful Applications": [
"version-v1.0.2-stateful-applications/iomesh-for-mysql",
"version-v1.0.2-stateful-applications/iomesh-for-mongodb"
],
"Cluster Operations": [
"version-v1.0.2-cluster-operations/scale-out-cluster",
"version-v1.0.2-cluster-operations/scale-down-cluster",
"version-v1.0.2-cluster-operations/upgrade-cluster",
"version-v1.0.2-cluster-operations/uninstall-cluster",
"version-v1.0.2-cluster-operations/manage-license",
"version-v1.0.2-cluster-operations/replace-failed-disk"
],
"Monitor IOMesh": [
"version-v1.0.2-monitor-iomesh/install-iomesh-dashboard",
"version-v1.0.2-monitor-iomesh/monitoring-iomesh"
],
"Advanced Functions": [
"version-v1.0.2-advanced-functions/manage-multiple-cluster",
"version-v1.0.2-advanced-functions/localpv-manager",
"version-v1.0.2-advanced-functions/external-storage"
],
"Appendices": [
"version-v1.0.2-appendices/release-notes",
"version-v1.0.2-appendices/downloads",
"version-v1.0.2-appendices/setup-worker-node",
"version-v1.0.2-appendices/iomesh-metrics",
"version-v1.0.2-appendices/faq"
]
}
}
1 change: 1 addition & 0 deletions website/versions.json
View file
Original file line number Diff line number Diff line change
@@ -1,4 +1,5 @@
[
"v1.0.2",
"v1.0.1",
"v1.0.0",
"v0.11.1",
Expand Down

0 comments on commit 17b5b21

Please sign in to comment.