評估K8s可用的最常見的存儲解決方案
如果你正在運行K8s，其中最大的難題之一是如何為k8s集群選擇正確的存儲技術，你可能會考慮使用通過動態(tài)預配置的塊存儲卷。實際上，這很大程度上取決于您要運行的工作負載的類型。本篇文章的目標主要是評估K8s可用的最常見的存儲解決方案，并進行基本性能測試。
目前CNCF的存儲格局和解決方案已經(jīng)更新，它已從2019年的30個解決方案增長到目前的45個解決方案，還進行了公共云集成的管理擴展，例如AWS EBS，Google永久磁盤或Azure磁盤存儲。一些新解決方案像Alluxio一樣，更側重于分布式文件系統(tǒng)或對象存儲。
本文的目標是采用K8s可用的最常見的存儲解決方案，并準備基本的性能比較。文章使用以下后端在Azure AKS上執(zhí)行所有測試：
-
AKS native storage class — Azure native premium
-
AWS cloud volume mapped into instance — Azure hostPath with attached Azure managed disk
-
OpenEBS with cStor backend
-
OpenEBS MayaStor
-
Portworx
-
Gluster managed by Heketi
-
Ceph managed by Rook
-
Longhorn
相比于19年的存儲方案，GlusterFS Heketi在性能結果上排名倒數(shù)第二，它的改進為零，并且大多數(shù)情況下是一個沉寂的項目（Heketi作為REST協(xié)調(diào)器而不是GlusterFS本身）。如果查看它們的官方GitHub，您會發(fā)現(xiàn)他們近乎將其置于維護模式，并且云本地存儲功能沒有任何更新。
另外根據(jù)GIGAOM 2020報告， PortWorx仍然是K8s的頂級商業(yè)存儲解決方案。但是，從性能的角度來看，版本2.0和2.5之間的發(fā)行說明中并沒有重大的技術或體系結構更改。最好的開源存儲，是通過Rook精心策劃的CEPH，他發(fā)布了2個新版本，并推出了一個新的CEPH版本，稱為Octopus。Octopus對緩存機制進行了一些優(yōu)化，并使用了更現(xiàn)代的內(nèi)核接口。今年唯一的主要體系結構更改發(fā)生在OpenEBS中，它引入了一個稱為MayaStor的新后端。這個后端看起來非常有前途。這些k8s常用的解決方案性能到底怎么樣了？我們一起來看下。
本機Azure存儲
之所以選擇該存儲類，是為了獲得所有測試的基準。此存儲類應提供最佳性能。Azure動態(tài)創(chuàng)建托管磁盤，并將其映射到具有k8s作為Pod卷的VM。
無需使用任何特殊功能。當您配置新的AKS群集時，將自動預定義2個存儲類，分別稱為“默認”和“高級托管”。高級類對卷使用基于SSD的高性能和低延遲磁盤。
優(yōu)點
-
AKS上的默認設置無需執(zhí)行任何操作。
缺點
-
故障轉移情況下非常慢，有時需要將近10分鐘才能將卷重新連接到其他節(jié)點上的Pod。
$ kubectl get storageclassesNAME PROVISIONER AGEdefault (default) kubernetes.io/azure-disk 8mmanaged-premium kubernetes.io/azure-disk 8m$ kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEdbench-pv-claim Bound pvc-e7bd34a4-1dbd-11e9-8726-ae508476e8ad 1000Gi RWO managed-premium 10s$ kubectl get poNAME READY STATUS RESTARTS AGEdbench-w7nqf0/1ContainerCreating029s
OpenEBS
OpenEBS代表了新的容器附加存儲（CAS）概念，其中是單個基于微服務的存儲控制器和多個基于微服務的存儲副本。它與Portworx一起屬于云本機存儲類別。
它是完全開源的，目前提供2個后端，分別是Jiva和cStor。我從Jiva開始，然后切換到cStor。cStor進行了一些改進，因為控制器及其副本部署在單個名稱空間（安裝openebs的名稱空間）中，或者它使用原始磁盤而不是格式化分區(qū)。每個k8s卷都有其自己的存儲控制器，該存儲可以在節(jié)點上可用存儲容量的允許范圍內(nèi)進行擴展。
如何在AKS上獲取它？在AKS上安裝其實非常容易。
1.我必須連接到所有k8s節(jié)點的控制臺并安裝iSCSI，因為它使用iSCSI協(xié)議在Pod和存儲控制器與k8s節(jié)點之間進行連接。
apt-get updateapt install -y open-iscsi
2.然后，我將單個YAML定義應用于我的k8s集群
kubectl apply -f https://openebs.github.io/charts/openebs-operator-0.8.0.yaml
3.下一步，OpenEBS控制器在底層節(jié)點發(fā)現(xiàn)了我所有的磁盤。但是我必須手動確定附加的AWS托管磁盤。
kubectl get diskNAME AGEdisk-184d99015253054c48c4aa3f17d137b1 5mdisk-2f6bced7ba9b2be230ca5138fd0b07f1 5mdisk-806d3e77dd2e38f188fdaf9c46020bdc 5m
4.然后，將這些磁盤添加到標準StorageClass引用的自定義k8s資源StoragePoolClaim中。
---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:name: openebs-customannotations:: cstor: |name: StoragePoolClaimvalue: "cstor-disk"provisioner: openebs.io/provisioner-iscsi---apiVersion: openebs.io/v1alpha1kind: StoragePoolClaimmetadata:name: cstor-diskspec:name: cstor-disktype: diskmaxPools: 3poolSpec:poolType: stripeddisks:diskList:disk-2f6bced7ba9b2be230ca5138fd0b07f1disk-806d3e77dd2e38f188fdaf9c46020bdcdisk-184d99015253054c48c4aa3f17d137b1
完成這些步驟后，我便能夠通過k8s PVC動態(tài)配置新卷。
優(yōu)點
-
開源的
-
Maya在資源使用可視化方面做得很好。您可以輕松地在k8s集群中部署多個服務，并輕松設置監(jiān)視和日志記錄以收集集群的所有重要方面。這是調(diào)試的理想工具。
-
總的來說，CAS概念–我非常喜歡容器存儲背后的想法，并且我相信會有未來。
-
OpenEBS背后的社區(qū)—我能夠在幾分鐘內(nèi)解決任何問題。Slack上的團隊非常有幫助。
缺點
-
不成熟-OpenEBS是一個相當新的項目，尚未達到穩(wěn)定版本。核心團隊仍在進行后端優(yōu)化，這將在接下來的幾個月中顯著提高性能。
-
Kubelet和存儲控制器之間的iSCSI連接由k8s服務實現(xiàn)，這在某些覆蓋網(wǎng)絡CNI插件（例如Tungsten Fabric）中可能是一個問題。
-
需要在Kubernetes節(jié)點上安裝其他軟件（iSCSI），這使其在托管Kubernetes集群的情況下不切實際。
注意：OpenEBS團隊在文檔中調(diào)整了相關的測試用例場景
https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench
Portworx
Portworx是為k8s設計的另一種容器本機存儲，專注于高度分布式的環(huán)境。它是一個主機可尋址的存儲，其中每個卷都直接映射到其連接的主機。它提供基于應用程序I/O類型的自動調(diào)整。那里有更多信息。不幸的是，它是本篇文章中唯一的不開源的存儲解決方案。但是，它免費提供3個節(jié)點試用版。
如何在AKS上安裝它？在AKS上安裝也非常容易。我使用了可在其網(wǎng)站上找到的Kubernetes spec生成器。
1.首選，我選擇了Portworx托管的etcd來簡化設置，并填充了k8s 1.11.4版本。
2.我必須將數(shù)據(jù)網(wǎng)絡接口修改為azure0，因為我使用的是具有高級聯(lián)網(wǎng)功能的Azure cni。否則，Portworx將使用來自docker bridge的IP地址而不是VM接口。
3.最后一步，網(wǎng)站生成器向我提供了渲染的k8s YAML清單以應用于我的集群。
4.引導后，我在每個k8s節(jié)點上運行了Portworx Pod
root@aks-agentpool-20273348-0:~# kubectl get pods -o wide -n kube-system -l name=portworxNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODEportworx-g9csq 1/1 Running 0 14m 10.0.1.66 aks-agentpool-20273348-2 <none>portworx-nt2lq 1/1 Running 0 14m 10.0.1.4 aks-agentpool-20273348-0 <none>portworx-wcjnx 1/1 Running 0 14m 10.0.1.35 aks-agentpool-20273348-1 <none>
我創(chuàng)建了具有高優(yōu)先級和3個副本的Storage Class，然后可以配置k8s pvc。
優(yōu)點
-
易于部署-具有詳細配置的網(wǎng)站配置器。
-
AKS集群的配置器，不需要任何其他步驟，如ceph或glusterfs。
-
云原生存儲，它可以在硬件集群和公共云上運行。
-
存儲感知的服務等級（COS）和應用感知的I/O調(diào)整
缺點
-
閉源，專有供應商解決方案。
GlusterFS Heketi
GlusterFS是眾所周知的開源存儲解決方案。它沿用Ceph，這是RedHat支持的傳統(tǒng)開源存儲之一。Heketi是用于GlusterFS的RESTful卷管理接口。它提供了一種釋放動態(tài)配置的GlusterFS卷功能的便捷方法。如果沒有此訪問權限，則必須手動創(chuàng)建GlusterFS卷并將其映射到k8s pv。
如何在AKS上安裝它？我使用了默認的Heketi快速入門指南。
-
首先，我基于示例一創(chuàng)建了一個拓撲文件，其中包含磁盤和主機名。
https://github.com/gluster/gluster-kubernetes/blob/master/deploy/topology.json.sample
2.由于Heketi主要是在基于RHEL的操作系統(tǒng)上開發(fā)和測試的，因此我在使用Ubuntu主機的AKS上遇到了一個問題，該內(nèi)核路徑錯誤。這是解決此問題的PR。
https://github.com/gluster/gluster-kubernetes/pull/557
+++ b/deploy/kube-templates/glusterfs-daemonset.yaml@@ -67,7 +67,7 @@ spec:mountPath: "/etc/ssl"readOnly: true- name: kernel-modules- mountPath: "/usr/lib/modules"+ mountPath: "/lib/modules"readOnly: truesecurityContext:capabilities: {}@@ -131,4 +131,4 @@ spec:path: "/etc/ssl"- name: kernel-moduleshostPath:- path: "/usr/lib/modules"+ path: "/lib/modules"
3.我遇到的AKS的另一個問題是非空磁盤，因此我使用了擦拭來清理glusterfs的磁盤。該磁盤以前沒有用于其他任何用途。
wipefs -a /dev/sdc/dev/sdc: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31
4.最后一步，我運行命令gk-deploy -g -t topology.json，該命令在由heketi控制器控制的每個節(jié)點上部署了glusterfs pod。
root@aks-agentpool-20273348-0:~# kubectl get po -o wideNAME READY STATUS RESTARTS IP NODE NOMINATED NODEglusterfs-fgc8f 1/1 Running 0 10.0.1.35 aks-agentpool-20273348-1glusterfs-g8ht6 1/1 Running 0 10.0.1.4 aks-agentpool-20273348-0glusterfs-wpzzp 1/1 Running 0 10.0.1.66 aks-agentpool-20273348-2heketi-86f98754c-n8qfb 1/1 Running 0 10.0.1.69 aks-agentpool-20273348-2
然后，我面臨著動態(tài)配置的問題。Heketi restURL對k8s控制平面不可用。我嘗試了kube dns記錄，pod IP和svc IP。兩者都不起作用。因此，我不得不通過Heketi CLI手動創(chuàng)建卷。
root@aks-agentpool-20273348-0:~# export HEKETI_CLI_SERVER=http://10.0.1.69:8080root@aks-agentpool-20273348-0:~# heketi-cli volume create --size=10 --persistent-volume --persistent-volume-endpoint=heketi-storage-endpoints | kubectl create -f -persistentvolume/glusterfs-efb3b155 createdroot@aks-agentpool-20273348-0:~# kubectl get pvNAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGEglusterfs-efb3b155 10Gi RWX Retain Available 19s
然后，必須為我的dbench工具將現(xiàn)有的PV映射到PVC。
kind: PersistentVolumeClaimapiVersion: v1metadata:name: glusterfs-efb3b155spec:accessModes:ReadWriteManystorageClassName: ""resources:requests:storage: 10GivolumeName: glusterfs-efb3b155kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEBound glusterfs-efb3b155 10Gi RWX 36m
從k8s上的Heketi Gluster安裝獲得更多輸出。
gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849Volume Name: vol_efb3b15529aa9aba889d7900f0ce9849Type: ReplicateVolume ID: 96fde36b-e389-4dbe-887b-baae32789436Status: StartedSnapshot Count: 0Number of Bricks: 1 x 3 = 3Transport-type: tcpBricks:Brick1: 10.0.1.66:/var/lib/heketi/mounts/vg_5413895eade683e1ca035760c1e0ffd0/brick_cd7c419bc4f4ff38bbc100c6d7b93605/brickBrick2: 10.0.1.35:/var/lib/heketi/mounts/vg_3277c6764dbce56b5a01426088901f6d/brick_6cbd74e9bed4758110c67cfe4d4edb53/brickBrick3: 10.0.1.4:/var/lib/heketi/mounts/vg_29d6152eeafc57a707bef56f091afe44/brick_4856d63b721d794e7a4cbb4a6f048d96/brickOptions Reconfigured:transport.address-family: inetnfs.disable: onperformance.client-io-threads: offkubectl get svcNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEheketi ClusterIP 192.168.101.758080/TCP 5h heketi-storage-endpoints ClusterIP 192.168.103.661/TCP 5h root@aks-agentpool-20273348-0:~# kubectl get endpointsNAME ENDPOINTS AGEheketi 10.0.1.69:8080 5hheketi-storage-endpoints 10.0.1.35:1,10.0.1.4:1,10.0.1.66:1 5hkubernetes 172.31.22.152:443 1droot@aks-agentpool-20273348-0:~# kubectl get endpoints heketi-storage-endpoints -o yamlapiVersion: v1kind: Endpointsmetadata:creationTimestamp: 2019-01-29T15:14:28Zname: heketi-storage-endpointsnamespace: defaultresourceVersion: "142212"selfLink: /api/v1/namespaces/default/endpoints/heketi-storage-endpointsuid: 91f802eb-23d8-11e9-bfcb-a23b1ec87092subsets:- addresses:- ip: 10.0.1.35- ip: 10.0.1.4- ip: 10.0.1.66ports:- port: 1protocol: TCP
優(yōu)點
-
成熟的存儲解決方案
-
比Ceph更輕
缺點
-
Heketi不是為公共管理的k8設計的。它與HW群集配合使用，安裝更容易。
-
并非真正為“結構化數(shù)據(jù)”設計的，如SQL數(shù)據(jù)庫。但是，您可以使用Gluster備份和還原數(shù)據(jù)庫。
Ceph Rook
OpenStack私有云常見和Ceph進行搭配。它始終需要設計特定的硬件配置，根據(jù)數(shù)據(jù)類型生成pg組，配置日志SSD分區(qū)（在bluestore之前）并定義Crush Map。因此，當我第一次聽說在3節(jié)點k8s集群中使用Ceph時，我不敢相信它實際上可以工作。但是，Rook編排工具給我留下了深刻的印象，該工具為我完成了所有痛苦的步驟，并且與k8s編排一起提供了一種非常簡單的方法來處理整個存儲集群的安裝。
如何在AKS上安裝它?在默認安裝中，Rook不需要任何特殊步驟，并且如果您不希望使用高級配置，它會非常平滑。
1.我使用了Ceph快速入門指南
https://github.com/rook/rook/blob/master/Documentation/ceph-quickstart.md#ceph-storage-quickstart
2.我必須配置特定于AKS的FLEXVOLUME_DIR_PATH，因為它們使用/etc/kubernetes/volumeplugins/ 而不是默認的Ubuntu /usr/libexec。沒有此更改，kubelet無法安裝pvc 。
diff --git a/cluster/examples/kubernetes/ceph/operator.yaml b/cluster/examples/kubernetes/ceph/operator.yamlindex 73cde2e..33f45c8 100755--- a/cluster/examples/kubernetes/ceph/operator.yaml+++ b/cluster/examples/kubernetes/ceph/operator.yaml@@ -431,8 +431,8 @@ spec:# - name: AGENT_MOUNT_SECURITY_MODE# value: "Any"# Set the path where the Rook agent can find the flex volumes- # - name: FLEXVOLUME_DIR_PATH- # value: "" + - name: FLEXVOLUME_DIR_PATH+ value: "/etc/kubernetes/volumeplugins"# Set the path where kernel modules can be found# - name: LIB_MODULES_DIR_PATH# value: ""
3.然后，我必須指定要在deviceFilter中使用的設備。我的附加磁盤始終位于/dev/sdc上
diff --git a/cluster/examples/kubernetes/ceph/cluster.yaml b/cluster/examples/kubernetes/ceph/cluster.yamlindex 48cfeeb..0c91c48 100755a/cluster/examples/kubernetes/ceph/cluster.yamlb/cluster/examples/kubernetes/ceph/cluster.yaml-227,7 +227,7 @@ spec:storage: # cluster level storage configuration and selectionuseAllNodes: trueuseAllDevices: falsedeviceFilter:deviceFilter: "^sdc"location:config:
4.安裝后，我使用以下配置創(chuàng)建了Ceph塊池和存儲類
apiVersion: ceph.rook.io/v1kind: CephBlockPoolmetadata:name: replicapoolnamespace: rook-cephspec:failureDomain: hostreplicated:size: 3---apiVersion: storage.k8s.io/v1kind: StorageClassmetadata:name: rook-ceph-blockprovisioner: ceph.rook.io/blockparameters:blockPool: replicapoolclusterNamespace: rook-cephfstype: xfsreclaimPolicy: Retain
5。最后，我通過以下部署工具檢查狀態(tài)：https://github.com/rook/rook/blob/master/Documentation/ceph-toolbox.md
ceph statuscluster:id: bee70a10-dce1-4725-9285-b9ec5d0c3a5ehealth: HEALTH_OKservices:mon: 3 daemons, quorum c,b,amgr: a(active)osd: 3 osds: 3 up, 3 indata:pools: 0 pools, 0 pgsobjects: 0 objects, 0 Busage: 3.0 GiB used, 3.0 TiB / 3.0 TiB availpgs:[root@aks-agentpool-27654233-0 /]#[root@aks-agentpool-27654233-0 /]#[root@aks-agentpool-27654233-0 /]# ceph osd status+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+| id | host | used | avail | wr ops | wr data | rd ops | rd data | state |+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+| 0 | aks-agentpool-27654233-0 | 1025M | 1021G | 0 | 0 | 0 | 0 | exists,up || 1 | aks-agentpool-27654233-1 | 1025M | 1021G | 0 | 0 | 0 | 0 | exists,up || 2 | aks-agentpool-27654233-2 | 1025M | 1021G | 0 | 0 | 0 | 0 | exists,up |+----+--------------------------+-------+-------+--------+---------+--------+---------+-----------+
優(yōu)點
-
在大型生產(chǎn)環(huán)境中運行的強大存儲
-
Rook使生命周期管理變得更加簡單。
缺點
-
復雜且更重，甚至不適合在公共云中運行。最好只在配置正確的硬件群集上運行。
Longhorn
Longhorn是Rancher開發(fā)的用于K8s的云原生分布式塊存儲。它主要是為微服務用例設計的。它為每個塊設備卷創(chuàng)建一個專用的存儲控制器，并跨存儲在多個節(jié)點上的多個副本同步復制該卷。Longhorn在附加了卷的節(jié)點上創(chuàng)建了Longhorn Engine，并在復制了卷的節(jié)點上創(chuàng)建了副本。與其他存儲方案類似，整個控制平面正常運行，而數(shù)據(jù)平面由K8s編排。它是完全開源的。有趣的是，OpenEBS Jiva后端實際上是基于Longhorn的，或者至少最初是基于Longhorn的。主要區(qū)別在于Longhorn使用TCMU Linux驅動程序，而OpenEBS Jiva使用的是gotgt。
如何在AKS上獲取它？當然也可以輕松安裝到AKS，只需要運行一個命令，它將所有組件安裝到我的AKS集群中
$ kubectl apply -f https://raw.githubusercontent.com/longhorn/longhorn/master/deploy/longhorn.yaml$ kubectl -n longhorn-system get poNAME READY STATUS RESTARTS AGEcsi-attacher-7965bb8b59-c4g2c 1/1 Running 0 116scsi-attacher-7965bb8b59-jqk9t 1/1 Running 0 116scsi-attacher-7965bb8b59-qrxl6 1/1 Running 0 116scsi-provisioner-5896666d9b-9lss2 1/1 Running 0 115scsi-provisioner-5896666d9b-v7wwd 1/1 Running 0 115scsi-provisioner-5896666d9b-vsq6v 1/1 Running 0 115scsi-resizer-98674fffd-27wgb 1/1 Running 0 115scsi-resizer-98674fffd-q6scx 1/1 Running 0 115scsi-resizer-98674fffd-rr7qc 1/1 Running 0 115sengine-image-ei-ee18f965-5npvk 1/1 Running 0 2m44sengine-image-ei-ee18f965-9lp7w 1/1 Running 0 2m44sengine-image-ei-ee18f965-h7b4x 1/1 Running 0 2m44sinstance-manager-e-27146777 1/1 Running 0 2m42sinstance-manager-e-58362831 1/1 Running 0 2m40sinstance-manager-e-6043871c 1/1 Running 0 2m43sinstance-manager-r-5cdb90bf 1/1 Running 0 2m40sinstance-manager-r-cb47162a 1/1 Running 0 2m41sinstance-manager-r-edd5778b 1/1 Running 0 2m42slonghorn-csi-plugin-7xzw9 2/2 Running 0 115slonghorn-csi-plugin-m8cp4 2/2 Running 0 115slonghorn-csi-plugin-wzgp8 2/2 Running 0 115slonghorn-driver-deployer-699db744fd-8j6q6 1/1 Running 0 3m8slonghorn-manager-c5647 1/1 Running 1 3m10slonghorn-manager-dlsmc 1/1 Running 0 3m10slonghorn-manager-jrnfx 1/1 Running 1 3m10slonghorn-ui-64bd57fb9d-qjmsl 1/1 Running 0 3m9s
2.將帶有ext4文件系統(tǒng)的/dev/sdc1掛載到/var/lib/longhorn，這是卷存儲的默認路徑。最好在Longhorn安裝之前將磁盤安裝到那里。
Longhorn中節(jié)點磁盤配置的屏幕截圖
3.最后一步是創(chuàng)建一個具有3個副本定義的默認存儲類。
# kubectl create -f https://raw.githubusercontent.com/longhorn/longhorn/master/examples/storageclass.yamlkind: StorageClassapiVersion: storage.k8s.io/v1metadata:name: longhornprovisioner: driver.longhorn.ioallowVolumeExpansion: trueparameters:numberOfReplicas: "3"staleReplicaTimeout: "2880" # 48 hours in minutesfromBackup: ""
優(yōu)點
-
開源的
-
云原生存儲，它可以在硬件集群和公共云上運行。
-
易于部署，它只需要一個命令，并且“開箱即用”。
-
自動卷備份/還原到S3
缺點
-
它使用標準文件系統(tǒng)（ext4或xfs）到/var/lib/longhorn的掛載點。每個卷就像一個磁盤文件。它可以隨著許多控制器副本進行擴展，從而帶來額外的網(wǎng)絡開銷。類似于我為OpenEBS Jiva描述的內(nèi)容。
-
卷的掛載有時會花費很長時間（幾分鐘），并且會顯示最終從中恢復的錯誤。
OpenEBS MayaStor
上文有介紹OpenEBS使用cStor的方案，其性能結果確實很差。但是一年半后的時間，OpenEBS團隊引入了一個名為MayStor的新后端。
這是用Rust編寫的云原生聲明性數(shù)據(jù)平面，由2個組件組成：
-
以CSI概念和數(shù)據(jù)平面實現(xiàn)的控制平面。與以前的后端相比，主要區(qū)別在于利用NVMe而不是NVMe-oF，這有望為存儲敏感型工作負載提供更好的IOPS和延遲價值。
-
這種存儲設計的另一個優(yōu)點是，它在主機用戶空間中完全用盡了內(nèi)核，并消除了由不同Linux發(fā)行版中可用的各種內(nèi)核引起的差異。它根本不依賴于內(nèi)核進行訪問。下面的鏈接中，詳細介紹了MayStor的設計說明。
https://blog.mayadata.io/openebs/mayastor-crossing-the-chasm-to-nvmf-infinity-and-beyond
如何在AKS上獲取它？在AKS上進行安裝也非常簡單，我遵循了他們的快速入門指南。
-
我必須在AKS群集中的每個節(jié)點上用512個數(shù)字配置2MB的大頁面。
echo 512 | sudo tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages
但是我決定通過下面的k8s daemonset強制執(zhí)行它們，而不是通過ssh進入我的每個實例。
apiVersion: apps/v1kind: DaemonSetmetadata:name: hugepages-ensurenamespace: mayastorlabels:app: hugepages-ensurespec:selector:matchLabels:name: hugepages-ensureupdateStrategy:type: OnDeletetemplate:metadata:name: hugepages-ensurelabels:name: hugepages-ensureapp: hugepages-ensurespec:containers:name: shellimage: busybox:latestimagePullPolicy: IfNotPresentcommand:/bin/shargs:-c"while true; do echo 512 | tee /sys/kernel/mm/hugepages/hugepages-2048kB/nr_hugepages;grep HugePages /proc/meminfo; sleep 6000; done"volumeMounts:mountPath: /host-rootname: host-rootsecurityContext:privileged: truednsPolicy: ClusterFirstWithHostNethostNetwork: truevolumes:name: host-roothostPath:path: /
2.我必須標記我的存儲節(jié)點VM。
kubectl label node aks-agentpool-13651304-0 openebs.io/engine=mayastorlabeledkubectl label node aks-agentpool-13651304-1 openebs.io/engine=mayastorlabeledkubectl label node aks-agentpool-13651304-2 openebs.io/engine=mayastorlabeled
3.然后，我應用了MayaStor存儲庫中指定的所有清單。
https://github.com/openebs/Mayastor/tree/develop/deploy
kubectl create -f nats-deployment.yamlkubectl create -f csi-daemonset.yamlkubectl create -f mayastorpoolcrd.yamlkubectl create -f moac-rbac.yamlkubectl create -f moac-deployment.yamlkubectl create -f mayastor-daemonset.yamlkubectl get po -n mayastorNAME READY STATUS RESTARTS AGEhugepages-ensure-5dr26 1/1 Running 0 47hhugepages-ensure-tpth6 1/1 Running 0 47hhugepages-ensure-z9mmh 1/1 Running 0 47hmayastor-csi-7rf2l 2/2 Running 0 47hmayastor-csi-hbqlb 2/2 Running 0 47hmayastor-csi-jdw7k 2/2 Running 0 47hmayastor-g9gnl 1/1 Running 7 47hmayastor-j7j4q 1/1 Running 4 47hmayastor-kws9r 1/1 Running 4 47hmoac-7d487fd5b5-hfvhq 3/3 Running 0 41hnats-b4cbb6c96-8drv4 1/1 Running 0 47h
4.當所有內(nèi)容都在運行時，您可以開始創(chuàng)建用于卷置備的存儲池。在我的情況下，我創(chuàng)建了3個存儲池，每個節(jié)點有一個磁盤。
cat <apiVersion: openebs.io/v1alpha1kind: MayastorPoolmetadata:name: pool-on-node-1namespace: mayastorspec:disks:/dev/sdcnode: aks-agentpool-13651304-1EOFkubectl -n mayastor get MayastorPoolNAME NODE STATE AGEaks-agentpool-13651304-0 online 40haks-agentpool-13651304-1 online 46haks-agentpool-13651304-2 online 46h
5.在繼續(xù)進行StorageClass定義之前，檢查每個存儲池的狀態(tài)很重要。狀態(tài)必須可見。
kubectl -n mayastor describe msp pool-on-node-1Name: pool-on-node-1Namespace: mayastorLabels:API Version: openebs.io/v1alpha1Kind: MayastorPoolMetadata:Creation Timestamp: 2020-08-19T0852ZGeneration: 1Resource Version: 45513Self Link: /apis/openebs.io/v1alpha1/namespaces/mayastor/mayastorpools/pool-on-node-1UID: 5330a0be-bebe-445a-9285-856511e318dcSpec:Disks:/dev/sdcNode: aks-agentpool-13651304-1Status:Capacity: 1098433691648Disks:aio:///dev/sdcReason:State: onlineUsed: 1073741824Events:
6.該過程的最后一步是StorageClass定義，在其中，我配置了3個副本以具有與之前的存儲解決方案相同的測試環(huán)境。
cat <kind: StorageClassapiVersion: storage.k8s.io/v1metadata:name: mayastorparameters:repl: '3'protocol: 'iscsi'provisioner: io.openebs.csi-mayastorEOF
完成這些步驟后，我便能夠通過K8s PVC動態(tài)預配新卷。
優(yōu)點
-
具有強大社區(qū)支持的開源
-
云原生存儲，它可以在硬件集群和公共云上運行。
-
與僅具有一個隊列的SCSI相比，NVMe的使用旨在實現(xiàn)高度并行性，并且可以具有64K隊列。
-
它使用NVMe-oF作為傳輸方式，可以在各種傳輸方式（nvmf，uring，pcie）上工作，并且完全在用戶空間（目標用戶和發(fā)起者）中完成。在用戶空間中運行可以避免進行大量的系統(tǒng)調(diào)用，避免后期崩潰/崩潰等。而且它與內(nèi)核無關，因此跨云或物理環(huán)境的linux類型之間沒有區(qū)別。
缺點
-
早期版本-OpenEBS MayaStor的版本為0.3，因此它仍然存在一些限制和穩(wěn)定性問題。但是，它們走在正確的軌道上，并且在幾個月后，它可能是在K8中存儲的首選。
-
需要在Kubernetes節(jié)點上支持2MB的大頁面。但是，與1GB的大頁面相比，幾乎在所有物理或虛擬環(huán)境中都可用。
性能測試結果
重要說明：單個存儲性能測試的結果無法單獨評估，但必須將測量結果相互比較。這里多種執(zhí)行比較測試的方法是相對比較簡單的。
為了進行驗證，我使用了與Azure AKS 3節(jié)點群集和每個實例均附有1TB高級SSD托管磁盤的完全相同的實驗室。
為了運行測試，我決定使用稱為Dbench的負載測試器。這是Pod的K8s部署清單，在其中運行FIO，這是帶有8個測試用例的Flexible IO Tester。在Docker映像的入口點中指定了測試：
-
隨機讀寫帶寬
-
隨機讀寫IOPS
-
讀寫延遲
-
順序讀/寫
-
混合讀/寫IOPS
首先，我運行了Azure PVC測試以獲得與去年進行比較的基準。結果幾乎相同，因此我們可以假設條件保持不變，并且使用相同的存儲版本將獲得相同的數(shù)量?？蓮膆ttps://gist.github.com/pupapaik/76c5b7f124dbb69080840f01bf71f924獲得來自2019年所有測試的更新的完整測試輸出以及新的MayStor和Longhorn測試
隨機讀寫帶寬
隨機讀取測試表明，GlusterFS，Ceph和Portworx的讀取性能比Azure本地磁盤上的主機路徑好幾倍。OpenEBS和Longhorn的性能幾乎是本地磁盤的兩倍。原因是讀取緩存。對于OpenEBS，寫入速度最快，但是Longhorn和GlusterFS的值也幾乎與本地磁盤相同。
隨機讀寫IOPS
Portworx和OpenEBS在隨機IOPS測試中表現(xiàn)出最好的結果。這次，OpenEBS在寫入方面的IOPS比本地Azure PVC更好，這在技術上幾乎是不可能的。它很可能與在測試用例運行的不同時間處的Azure存儲負載有關。
讀寫延遲
延遲讀取獲勝者與上次相同。LongHorn和OpenEBS幾乎是PortWorx的兩倍。這仍然不錯，因為本機Azure pvc比大多數(shù)其他經(jīng)過測試的存儲要慢。但是，在OpenEBS和Longhorn上寫入期間的延遲更好。GlusterFS仍然比其他存儲要好。
順序讀/寫
順序讀/寫測試顯示的結果與隨機測試相似，但是Ceph的讀性能比GlusterFS高2倍。寫入結果幾乎都處于同一水平，OpenEBS和Longhorn達到了相同的水平。
混合讀/寫IOPS
最后一個測試用例驗證了混合讀寫IOPS，在讀寫方面，OpenEBS交付的速度幾乎是PortWorx或Longhorn的兩倍。
結論
該文章驗證了一個開放源代碼項目在一年內(nèi)可以有多大的變化！作為演示，讓我們看一下在完全相同的環(huán)境下，OpenEBS cStor和OpenEBS MayaStor的IOPS的比較。
OpenEBS cStor和MayaStor之間的混合讀寫IOPS比較
在選擇存儲空間時，請僅將結果作為標準之一，不要僅根據(jù)文章做出最終判斷。我們可以從上述的測試中得出以下結論：
-
Portworx和OpenEBS是AKS上最快的容器存儲。
-
圍繞NVMe的穩(wěn)健設計，OpenEBS似乎已成為最好的開源容器存儲選項之一。
-
對于硬件集群，Ceph是最好的開源后端存儲。對于公共云而言，操作過于復雜，最終與默認的云存儲類相比并沒有增加太多價值。
-
對于簡單的塊存儲用例，Longhorn絕對是有效的選擇，它與OpenEBS Jiva后端非常相似。
當然，以上只是評測容器存儲選項的一種方法。存儲評測應該還包括縮放和穩(wěn)定性等。后期將密切關注CNCF存儲領域中其他正在發(fā)展的項目，并從性能測試和擴展中帶來跟多有趣的更新。
參考鏈接
1.https://medium.com/volterra-io/kubernetes-storage-performance-comparison-9e993cb27271
2.https://medium.com/volterra-io/kubernetes-storage-performance-comparison-v2-2020-updated-1c0b69f0dcf4
責任編輯：xj
原文標題：K8s最常見的存儲解決方案之性能評測
文章出處：【微信公眾號：存儲社區(qū)】歡迎添加關注！文章轉載請注明出處。
-
分布式
+關注
關注
1文章
1093瀏覽量
76579 -
儲存
+關注
關注
3文章
203瀏覽量
23090
原文標題：K8s最常見的存儲解決方案之性能評測
文章出處：【微信號：TopStorage，微信公眾號：存儲加速器】歡迎添加關注！文章轉載請注明出處。
發(fā)布評論請先 登錄
工商網(wǎng)監(jiān)
評論