kvm 分布式存储分布式存储块存储

转载

数码精灵abc 2024-03-25 10:49:37

文章标签 kvm 分布式存储 kubernetes 云原生存储云存储 Longhorn 文章分类 运维

导读

前一段时间研究了一下分布式块存储Longhorn这个项目，Longhorn是完全基于K8s实现的分布式块存储，最大的特性就是他通过以微服务的方式（engine_instance+replicas）来提供存储服务，所以可用性极高。但本质还是通过iscsi把存储目录映射为一个盘挂到节点上然后再mount给容器使用，所以运行效率本身不太高，看到网上说的要比nfs可能要好一点，但是肯定是比不上本地磁盘hostpath的。下面的内容大多数来源于Longhorn的官方文档，进行了一些翻译及自己的理解，跟大家一起学习。

一、 longhorn项目介绍

1.longhorn是什么

Longhorn 是用于 Kubernetes 的轻量级、可靠且功能强大的分布式块存储系统。

Longhorn使用容器(containers)和微服务(microservices)实现分布式块存储。

Longhorn 为每个块设备卷(device volume)创建一个专用的存储控制器(storage controller)，并跨存储在多个节点上的多个副本同步复制该卷。
存储控制器(storage controller)和副本(replicas)本身是使用 Kubernetes 编排的。

2.longhorn支持架构

AMD64
ARM64 (实验性的)

3.longhorn的特性

1.使用 Longhorn 卷作为 Kubernetes 集群中分布式有状态应用程序的持久存储
2.将块存储划分为 Longhorn 卷，这样无论是否有云提供商，都可以使用 Kubernetes卷
3.跨多个节点和数据中心复制块存储以提高可用性
4.将备份数据存储在 NFS 或 AWS S3 等外部存储上
5.创建跨集群灾难恢复卷，以便可以从第二个 Kubernetes 集群的备份中快速恢复来自主 Kubernetes 集群的数据
6.安排卷的定期快照，并安排定期备份到 NFS 或 S3 兼容的辅助存储
7.从备份恢复卷
8.在不中断持久卷的情况下升级 Longhorn

4.longhorn的设计

Longhorn 设计有两层：数据平面(data plane)和控制平面(control plane)。
Longhorn Engine 是存储控制器对应数据平面，Longhorn Manager 对应控制平面。

(1) Longhorn Manager 和 Longhorn Engine

Longhorn Manager Pod 作为 Kubernetes DaemonSet 在 Longhorn 集群中的每个节点上运行。它负责在 Kubernetes 集群中创建和管理卷，并处理来自 UI 或 Kubernetes 卷插件的 API 调用。
Longhorn Manager 与 Kubernetes API 服务器通信以创建新的 Longhorn 卷 CRD。然后 Longhorn Manager监测api-server的响应，当监测到k8s apiserver创建了一个新的 Longhorn volume CRD时，Longhorn Manager就创建一个新的卷。
当Longhorn Manager被要求创建一个卷时，它会在该卷所连接的节点上创建一个Longhorn Engine实例，并在每个将放置副本的节点上创建一个副本。副本应放置在不同的主机上以确保最大的可用性。
副本的多条数据路径确保了Longhorn卷的高可用性。即使某个副本或引擎出现问题，也不会影响所有副本或 Pod 对卷的访问，Pod 仍将正常运行。
Longhorn Engine始终在与使用Longhorn volume的 Pod 相同的节点中运行。它跨存储在多个节点上的多个副本同步复制卷。
引擎(Engine)和副本(replicas)使用 Kubernetes进行编排。

在下图中，

kvm 分布式存储分布式存储块存储_kvm 分布式存储

Longhorn volumes 有三个实例。

每个卷都有一个专用控制器，称为 Longhorn Engine 并作为 Linux 进程运行。
每个 Longhorn 卷有两个副本(replica)，每个副本是一个 Linux 进程。
图中的箭头表示卷(volume)、控制器实例(controller instance)、副本实例(replica instances)和磁盘之间的读/写数据流。
通过为每个卷创建单独的 Longhorn Engine，如果一个控制器出现故障，其他卷的功能不会受到影响。

(2) 基于微服务的设计的优势
在 Longhorn中，每个 Engine只需要服务一个卷，简化了存储控制器的设计。由于控制器软件的故障域与单个卷隔离，因此控制器崩溃只会影响一个卷。

Longhorn Engine 足够简单和轻便，因此我们可以创建多达 100,000 个独立的引擎。 Kubernetes 调度这些独立的引擎，从一组共享的磁盘中提取资源，并与 Longhorn 合作形成一个弹性的分布式块存储系统。

因为每个卷都有自己的控制器，所以每个卷的控制器和副本实例也可以升级，而不会导致 IO 操作明显中断。

Longhorn 可以创建一个长时间运行的作业(long-running job)来协调所有实时卷的升级，而不会中断系统的持续运行。为确保升级不会导致不可预见的问题，Longhorn 可以选择升级一小部分卷，并在升级过程中出现问题时回滚到旧版本。

(3) CSI Driver

Longhorn CSI driver 获取块设备(block device)，对其进行格式化，然后将其挂载到节点上。然后 kubelet 将设备绑定挂载到 Kubernetes Pod 中。这允许 Pod 访问 Longhorn volume。

所需的 Kubernetes CSI 驱动程序镜像将由 longhorn driver deployer 自动部署。

(4) CSI Plugin

Longhorn 通过 CSI Plugin 在 Kubernetes 中进行管理。这允许轻松安装 Longhorn 插件。

Kubernetes CSI plugin 调用 Longhorn 创建卷，为 Kubernetes 工作负载创建持久数据(persistent data)。 CSI plugin 使您能够创建(create)、删除(delete)、附加(attach)、分离(detach)、挂载(mount)卷，并对卷进行快照。Longhorn 提供的所有其他功能都是通过 Longhorn UI 实现的。

Kubernetes 集群内部使用 CSI interface 与 Longhorn CSI plugin 进行通信。Longhorn CSI plugin 使用 Longhorn API 与 Longhorn Manager 通信。

(5) Longhorn UI

Longhorn UI 通过 Longhorn API 与 Longhorn Manager 进行交互，并作为 Kubernetes 的补充。通过 Longhorn 界面可以管理快照(snapshots)、备份(backups)、节点(nodes)和磁盘(disks)。

二、longhorn部署

1.环境要求：

与 Kubernetes 兼容的容器运行时（Docker v1.13+、containerd v1.3.7+ 等）
Kubernetes v1.16+.
推荐 Kubernetes v1.17+
open-iscsi 已安装，并且 iscsid 守护程序正在所有节点上运行。这是必要的，因为 Longhorn 依赖主机上的 iscsiadm 为 Kubernetes 提供持久卷。
RWX support 要求每个节点都安装 NFSv4 client。
主机文件系统支持 file extents 功能来存储数据。

官方提供了一个环境检测脚本

curl -sSfL https://raw.githubusercontent.com/longhorn/longhorn/v1.2.2/scripts/environment_check.sh | bash

2.部署方式：

可以通过单独的yaml文件部署全部组件，也可以通过helm chart一键完成。

kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.2/deploy/longhorn.yaml

root@master1:~# kubectl get crd |grep longhorn
backingimagedatasources.longhorn.io          2021-12-23T08:16:00Z
backingimagemanagers.longhorn.io             2021-12-23T08:16:00Z
backingimages.longhorn.io                    2021-12-23T08:16:00Z
backups.longhorn.io                          2021-12-23T08:16:00Z
backuptargets.longhorn.io                    2021-12-23T08:16:00Z
backupvolumes.longhorn.io                    2021-12-23T08:16:00Z
engineimages.longhorn.io                     2021-12-23T08:15:59Z
engines.longhorn.io                          2021-12-23T08:15:59Z
instancemanagers.longhorn.io                 2021-12-23T08:15:59Z
nodes.longhorn.io                            2021-12-23T08:15:59Z
recurringjobs.longhorn.io                    2021-12-23T08:16:00Z
replicas.longhorn.io                         2021-12-23T08:15:59Z
settings.longhorn.io                         2021-12-23T08:15:59Z
sharemanagers.longhorn.io                    2021-12-23T08:15:59Z
volumes.longhorn.io                          2021-12-23T08:15:59Z

root@master1:~# kubectl get pod -n longhorn-system 
NAME                                      READY   STATUS    RESTARTS   AGE
csi-attacher-854f8c65f7-8z8km             1/1     Running   0          112m
csi-attacher-854f8c65f7-fb4rl             1/1     Running   0          112m
csi-attacher-854f8c65f7-k62gk             1/1     Running   0          112m
csi-provisioner-5f68999455-d9q77          1/1     Running   0          112m
csi-provisioner-5f68999455-dnb7d          1/1     Running   0          112m
csi-provisioner-5f68999455-rn8jw          1/1     Running   1          112m
csi-resizer-9d8f9ffcd-6w864               1/1     Running   0          112m
csi-resizer-9d8f9ffcd-clhqg               1/1     Running   1          112m
csi-resizer-9d8f9ffcd-xhzbd               1/1     Running   0          112m
csi-snapshotter-5b9f69f5db-7466v          1/1     Running   0          112m
csi-snapshotter-5b9f69f5db-pcjzr          1/1     Running   0          112m
csi-snapshotter-5b9f69f5db-zqdfg          1/1     Running   1          112m
engine-image-ei-9c4e77c5-qn2hv            1/1     Running   0          143m
engine-image-ei-9c4e77c5-s7wzq            1/1     Running   0          143m
instance-manager-e-30384430               1/1     Running   0          22m
instance-manager-e-34d95857               1/1     Running   0          22m
instance-manager-e-631e4e7f               1/1     Running   0          22m
instance-manager-e-c9bdc485               1/1     Running   0          14m
instance-manager-e-e5674086               1/1     Running   0          22m
instance-manager-r-1b468bc2               1/1     Running   0          22m
instance-manager-r-1e3b38c4               1/1     Running   0          22m
instance-manager-r-42080294               1/1     Running   0          22m
instance-manager-r-6200bc5f               1/1     Running   0          14m
longhorn-csi-plugin-56g84                 2/2     Running   0          112m
longhorn-csi-plugin-jcftf                 2/2     Running   0          112m
longhorn-driver-deployer-6d959bb8-4ntd6   1/1     Running   0          129m
longhorn-manager-c5ljt                    1/1     Running   1          143m
longhorn-manager-ghcml                    1/1     Running   1          143m
longhorn-manager-lh5wt                    1/1     Running   0          143m
longhorn-manager-vs8lp                    1/1     Running   1          143m
longhorn-manager-zxxl9                    1/1     Running   0          143m
longhorn-ui-67c8476986-pzw4f              1/1     Running   0          143m

3.验证部署

官方提供了sc，pvc等资源。

kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.2/examples/storageclass.yaml

kind: StorageClass
apiVersion: storage.k8s.io/v1
metadata:
  name: longhorn
provisioner: driver.longhorn.io
allowVolumeExpansion: true
parameters:
  numberOfReplicas: "3"
  staleReplicaTimeout: "2880" # 48 hours in minutes
  fromBackup: ""
#  diskSelector: "ssd,fast"
#  nodeSelector: "storage,fast"
#  recurringJobSelector: '[
#   {
#     "name":"snap",
#     "isGroup":true,
#   },
#   {
#     "name":"backup",
#     "isGroup":false,
#   }
#  ]'

kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/v1.2.2/examples/pod_with_pvc.yaml

pvc

apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: longhorn-volv-pvc
spec:
  accessModes:
    - ReadWriteOnce
  storageClassName: longhorn
  resources:
    requests:
      storage: 2Gi

4.longhorn配置

apiVersion: v1
kind: ConfigMap
metadata:
  name: longhorn-default-setting
  namespace: longhorn-system
data:
  default-setting.yaml: |-
    backup-target:
    backup-target-credential-secret:
    allow-recurring-job-while-volume-detached:
    create-default-disk-labeled-nodes:
    default-data-path:
    replica-soft-anti-affinity:
    replica-auto-balance:
    storage-over-provisioning-percentage:
    storage-minimal-available-percentage:
    upgrade-checker:
    default-replica-count:
    default-data-locality:
    default-longhorn-static-storage-class:
    backupstore-poll-interval:
    taint-toleration:
    system-managed-components-node-selector:
    priority-class:
    auto-salvage:
    auto-delete-pod-when-volume-detached-unexpectedly:
    disable-scheduling-on-cordoned-node:
    replica-zone-soft-anti-affinity:
    node-down-pod-deletion-policy:
    allow-node-drain-with-last-healthy-replica:
    mkfs-ext4-parameters:
    disable-replica-rebuild:
    replica-replenishment-wait-interval:
    concurrent-replica-rebuild-per-node-limit:
    disable-revision-counter:
    system-managed-pods-image-pull-policy:
    allow-volume-creation-with-degraded-availability:
    auto-cleanup-system-generated-snapshot:
    concurrent-automatic-engine-upgrade-per-node-limit:
    backing-image-cleanup-wait-interval:
    backing-image-recovery-wait-interval:
    guaranteed-engine-manager-cpu:
    guaranteed-replica-manager-cpu:

longhorn的配置可能在部署时修改longhorn-default-setting的configmap来进行修改。

默认replica存放在/var/lib/longhorn/replicas目录下

可以通过修改configmap里的default-data-path修改

如果想要不同节点配置不同的replica路径，可以通过修改参数create-default-disk-labeled-nodes: true，同时给节点加label

node.longhorn.io/create-default-disk: 'config'

并配置节点的annotation

node.longhorn.io/default-disks-config: '[ { "path":"/var/lib/longhorn", "allowScheduling":true
  }, { "name":"fast-ssd-disk", "path":"/mnt/extra", "allowScheduling":false, "storageReserved":10485760,
  "tags":[ "ssd", "fast" ] }]'

如果添加任何其他磁盘，您需要：

1.将主机上的磁盘挂载到某个目录。
2.将挂载磁盘的路径添加到节点的磁盘列表中。

三、优缺点

1.优点

对于每个longhornvolume提供一个控制器，简化了存储控制器的设计，减小控制面的体积。
同时由于控制器软件的故障域与单个卷隔离，因此控制器崩溃只会影响一个卷。

k8s原生支持，部署使用方便(kubectl，helm)

微服务的存储控制器高可用

支持定时备份跟快照，支持远端备份(NFS,S3)

longhorn-ui，可以方便查看所有资源情况，方便设置

2.缺点

不能直接管理裸盘，位于底层文件系统之上，性能不如本地盘。

本文章为转载内容，我们尊重原作者对文章享有的著作权。如有内容错误或侵权问题，欢迎原作者联系我们进行内容更正或删除文章。

上一篇：centos 7 安装vnc图形设置分辨率 centos7.6配置vnc

下一篇：todesk传送文件报错 todesk文件传输慢

提问和评论都可以，用心的回复会被更多人看到评论

发布评论

相关文章

官方博客	全部文章	热门标签	班级博客
了解我们	网站地图	意见反馈

鸿蒙开发者社区	51CTO学堂
51CTO	软考资讯