摘要

本文展示了一個(gè)簡單的存儲對比，使用未經(jīng)性能優(yōu)化的多種存儲提供的存儲卷進(jìn)行測試和比較。

忽略 Azure 的原生 PVC 或 hostPath ，我們可以得出如下測試結(jié)果：

• Portworx 是 AKS 上最快的容器存儲。
• Ceph 是私有云集群上最快的開源存儲后端。對公有云來說，其操作太過復(fù)雜，這些多余的復(fù)雜性并沒有能提供更好的測試表現(xiàn)。
• OpenEBS 的概念很棒，但是其后端需要更多優(yōu)化。

如果你正在運(yùn)行 Kubernetes，你可能正在使用，或者準(zhǔn)備使用動態(tài)供給的塊存卷 ，而首當(dāng)其沖的問題就是為集群選擇合適的存儲技術(shù)。這個(gè)事情并不能用一個(gè)簡單的測試來做出簡單的回答，告訴你目前市面上比較好的技術(shù)是什么。存儲技術(shù)的選擇過程中，集群上運(yùn)行的負(fù)載類型是一個(gè)重要的輸入。對于裸金屬集群來說，需要根據(jù)實(shí)際用例進(jìn)行選擇，并集成到自己的硬件之中。公有云中的托管 K8s，例如 AKS、EKS 或者 GKE，都具有開箱可用的塊存儲能力，然而這也不見得就是很好的選擇。有很多因素需要考慮，比如說公有云的 StorageClass 的故障轉(zhuǎn)移時(shí)間太長。例如在 一個(gè)針對 AWS EBS 的故障測試中，加載了卷的 Pod 用了超過五分鐘才成功的在另一個(gè)節(jié)點(diǎn)上啟動。Portworx 或者 OpenEBS 這樣的云原生存儲產(chǎn)品，正在嘗試解決這類問題。

本文的目標(biāo)是使用最常見的 Kubernetes 存儲方案，進(jìn)行基本的性能對比。我覺得在 Azure AKS 上使用下列后端：

• AKS 原生 Storageclass：Azure native premium
• 使用 cStor 后端的 OpenEBS
• Portworx
• Heketi 管理的 Gluster
• Rook 管理的 Ceph

現(xiàn)在我們來介紹每種存儲后端，并交代一下安裝過程，然后進(jìn)入 AKS 測試環(huán)境進(jìn)行測試，最后得出結(jié)果。

存儲

這一節(jié)中介紹測試中用到的存儲方案，包含安裝過程以及該方案的優(yōu)缺點(diǎn)。

Azure 原生 StorageClass

我選擇這一方案的動機(jī)是以此作為所有測試的基線。這個(gè)方案 應(yīng)該 提供優(yōu)質(zhì)性能。Azure 動態(tài)的創(chuàng)建托管磁盤，并把它們映射到 K8s 的虛擬機(jī)中，最終成為 Pod 的存儲卷。

這個(gè)方案很方便，什么多余的步驟都不需要。創(chuàng)建一個(gè)新的 AKS 集群之后，就自動提供了兩個(gè)預(yù)定義的 StorageClass，分別是 default 和 managed-premium ，premium 使用的是基于 SSD 的高性能低延遲磁盤。

 

$ 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-w7nqf   0/1ContainerCreating029s 

優(yōu)點(diǎn)

AKS 開箱即用。

缺點(diǎn)

故障轉(zhuǎn)移非常緩慢，有時(shí)需要十分鐘以后，存儲卷才能重新掛載到不同節(jié)點(diǎn)上的 Pod 里。

OpenEBS

對我來說 OpenEBS 是個(gè)全新事物，因此我很有興趣做他的測試。他提出了一個(gè)新的 Container Attached Storage(容器掛載存儲) 概念，這是一個(gè)基于微服務(wù)的存儲控制器，以及多個(gè)基于微服務(wù)的存儲副本。他和 Portworx 同樣，屬于云原生存儲分類的成員。

它是一個(gè)完全開源的方案，目前提供兩種后端——Jiva 和 cStor。我最開始選擇的是 Jiva，后來切換到 cStor。cStor 有很多長處，例如他的控制器和副本被部署到單一的 OpenEBS 所在的命名空間之中，能夠管理原始磁盤等。每個(gè) K8s 卷都有自己的存儲控制器，能在節(jié)點(diǎn)存儲容量的許可范圍內(nèi)對存儲進(jìn)行擴(kuò)展。

在 AKS 上運(yùn)行

在 AKS 上的安裝非常容易。

1. 連接到所有 K8s 節(jié)點(diǎn)上，安裝 iSCSI，這是因?yàn)樗枰褂?iSCSI 協(xié)議在 K8s 節(jié)點(diǎn)之間進(jìn)行 Pod 和控制器的連接。apt-get update apt install -y open-iscsi
2. 使用一個(gè) YAML 定義在 K8s 集群上完成部署：kubectl apply -f https://openebs.github.io/charts/openebs-operator-0.8.0.yaml
3. 下一步，OpenEBS 控制器發(fā)現(xiàn)了節(jié)點(diǎn)中的所有磁盤。但是我必須手工標(biāo)識出我附加的 AWS 托管磁盤。$ kubectl get disk NAME AGE disk-184d99015253054c48c4aa3f17d137b15m disk-2f6bced7ba9b2be230ca5138fd0b07f15m disk-806d3e77dd2e38f188fdaf9c46020bdc5m
4. 然后把這些磁盤加入 StoragePoolClaim，這個(gè)對象會在 StorageClass 中進(jìn)行引用：--- apiVersion: storage.k8s.io/v1 kind:StorageClass metadata: name: openebs-custom annotations: openebs.io/cas-type: cstor cas.openebs.io/config - name:StoragePoolClaim value:"cstor-disk" provisioner: openebs.io/provisioner-iscsi --- apiVersion: openebs.io/v1alpha1 kind:StoragePoolClaim metadata: name: cstor-disk spec: name: cstor-disk type: disk maxPools:3 poolSpec: poolType: striped disks: diskList: - disk-2f6bced7ba9b2be230ca5138fd0b07f1 - disk-806d3e77dd2e38f188fdaf9c46020bdc - disk-184d99015253054c48c4aa3f17d137b1

完成這些步驟之后，就可以用 K8s 的 PVC 來動態(tài)的創(chuàng)建存儲卷了。

優(yōu)點(diǎn)

• 開源
• Maya 在資源使用的可視化方面做得非常好。可以在 K8s 中部署多個(gè)服務(wù)，方便的為集群的各方面數(shù)據(jù)設(shè)置監(jiān)控和日志。對于排錯工作來說，這十分重要。
• CAS 概念：我非常欣賞這一概念，我相信這是未來的趨勢。
• OpenEBS 社區(qū)：在社區(qū)中我的任何問題都能在幾分鐘內(nèi)得到解決。Slack 上的團(tuán)隊(duì)非常有幫助。

缺點(diǎn)

• 不成熟：OpenEBS 還很年輕，目前還沒有發(fā)布穩(wěn)定版。核心團(tuán)隊(duì)還在進(jìn)行后端的優(yōu)化，未來幾個(gè)月里會對性能做出很大提升。
• Kubelet 和存儲控制器之間的 iSCSI 連接是通過 K8s Service 進(jìn)行的，這在 Tungsten Fabric 之類的 CNI 插件環(huán)境中可能會出問題。
• 需要在 K8s 節(jié)點(diǎn)上安裝額外的軟件(iSCSI)，這對于托管集群來說非常不便。

注：OpenEBS 團(tuán)隊(duì)對我的案例場景進(jìn)行了調(diào)整：

https://github.com/kmova/openebs/tree/fio-perf-tests/k8s/demo/dbench

Portworx

Portworx 是另一個(gè)面向 Kubernetes 的容器原生存儲方案，它專注于高度分布式的環(huán)境。這是一個(gè)主機(jī)可尋址的存儲，每個(gè)卷都直接映射到掛在的主機(jī)上。他提供了基于應(yīng)用 I/O 類型的自動微調(diào)能力。 官方網(wǎng)站 提供了更多信息。不幸的是，它也是本文中唯一的非開源產(chǎn)品。然而它提供了 3 節(jié)點(diǎn)的免費(fèi)試用。

在 AKS 上運(yùn)行

在 AKS 上的安裝同樣簡單，我用了他們 網(wǎng)站 提供的生成器。

 

azure0 

 

$ kubectl get pods -o wide -n kube-system -l name=portworxNAME             READY     STATUS    RESTARTS   AGE       IP          NODE                       NOMINATED NODEportworx-g9csq   1/1Running014m10.0.1.66   aks-agentpool-20273348-2<none>portworx-nt2lq   1/1Running014m10.0.1.4    aks-agentpool-20273348-0<none>portworx-wcjnx   1/1Running014m10.0.1.35   aks-agentpool-20273348-1<none> 

為 PVC 創(chuàng)建一個(gè) StorageClass，定義高優(yōu)先級，以及三個(gè)副本：

 

root@aks-agentpool-20273348-0:~# kubectl get storageclass -o yaml portworx-scapiVersion: storage.k8s.io/v1kind:StorageClassmetadata:  creationTimestamp:2019-01-28T21:10:28Z  name: portworx-sc  resourceVersion:"55332"  selfLink:/apis/storage.k8s.io/v1/storageclasses/portworx-sc  uid:23455e40-2341-11e9-bfcb-a23b1ec87092parameters:  priority_io: high  repl:"3"provisioner: kubernetes.io/portworx-volumereclaimPolicy:DeletevolumeBindingMode:Immediate 

優(yōu)點(diǎn)

• 部署方便：生成器包含配置細(xì)節(jié)。
• 不像 Ceph 和 Glusterfs 那樣需要進(jìn)行額外配置。
• 云原生存儲：公有云和裸金屬都可以運(yùn)行。
• 存儲級別感知和應(yīng)用感知的 I/O 微調(diào)。

缺點(diǎn)

• 閉源：商業(yè)解決方案

GlusterFS Heketi

GlusterFS 是知名的開源存儲方案，是由 Redhat 提供的開源存儲方案。 Heketi 是 GlusterFS 的 RESTful 卷管理界面。它提供了易用的方式為 GlusterFS 卷提供了動態(tài)供給的功能。如果沒有 Heketi 的輔助，就只能手工創(chuàng)建 GlusterFS 卷并映射到 K8s PV 了。關(guān)于 GlusterFS 的更多信息，請閱讀 官方文檔 。

在 AKS 上運(yùn)行

根據(jù) Heketi 的 快速入門 文檔進(jìn)行部署。

1. 參照 樣例 ，創(chuàng)建一個(gè)包含磁盤和主機(jī)名的拓?fù)湮募?/li>
2. Heketi 主要的開發(fā)和測試都在基于 RHEL 的操作系統(tǒng)上，我在 AKS 上使用 Ubuntu 主機(jī)時(shí)，出現(xiàn)了內(nèi)核模塊路徑錯誤的問題，我提交了一個(gè) PR 來修正這個(gè)問題。~~~ +++ b/deploy/kube-templates/glusterfs-daemonset.yaml @@ -67,7 +67,7 @@ spec: mountPath: “/etc/ssl” readOnly: true – name: kernel-modules name: kernel-modules hostPath: mountPath: “/usr/lib/modules” mountPath: “/lib/modules” readOnly: true securityContext: capabilities: {} @@ -131,4 +131,4 @@ spec: path: “/etc/ssl” path: “/usr/lib/modules” path: “/lib/modules” ~~~
3. 我在 AKS 環(huán)境中遇到的另一個(gè)問題是一個(gè)非空磁盤，所以我用 wipefs 為 glusterfs 進(jìn)行清理。這個(gè)磁盤并未用過。 $ wipefs -a /dev/sdc /dev/sdc: 8 bytes were erased at offset 0x00000218 (LVM2_member): 4c 56 4d 32 20 30 30 31
4. 最后運(yùn)行 gk-deploy -g -t topology.json ，會在每個(gè)節(jié)點(diǎn)上運(yùn)行 Heketi 控制器管理之下的 GlusterFS Pod。$ kubectl get po -o wide NAME READY STATUS RESTARTS IP NODE NOMINATED NODE glusterfs-fgc8f 1/1Running010.0.1.35 aks-agentpool-20273348-1 glusterfs-g8ht6 1/1Running010.0.1.4 aks-agentpool-20273348-0 glusterfs-wpzzp 1/1Running010.0.1.66 aks-agentpool-20273348-2 heketi-86f98754c-n8qfb 1/1Running010.0.1.69 aks-agentpool-20273348-2 然后我遇到了新問題。K8s 控制面無法使用 Heketi 的 restURL 。我測試了一下 kube dns 的記錄，pod IP 和 svc IP 都沒有生效。最后只能手工使用 Heketi CLI 來創(chuàng)建存儲卷。

 

$ export HEKETI_CLI_SERVER=http://10.0.1.69:8080$ heketi-cli volume create --size=10--persistent-volume --persistent-volume-endpoint=heketi-storage-endpoints | kubectl create -f -persistentvolume/glusterfs-efb3b155 created$ kubectl get pvNAME                 CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS      CLAIM     STORAGECLASS   REASON    AGEglusterfs-efb3b155   10Gi       RWX            RetainAvailable 

然后把現(xiàn)存 PV 映射為 PVC，加載給測試 工具 進(jìn)行測試。

 

kind:PersistentVolumeClaimapiVersion: v1metadata:  name: glusterfs-efb3b155spec:  accessModes:    -ReadWriteMany  storageClassName:""  resources:    requests:      storage:10Gi  volumeName: glusterfs-efb3b155 

 

$ kubectl get pvcNAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGEglusterfs-efb3b155 Bound glusterfs-efb3b155 10Gi RWX 36m 

Heketi 的更多輸出：

 

$ gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849VolumeName: vol_efb3b15529aa9aba889d7900f0ce9849Type:ReplicateVolume ID:96fde36b-e389-4dbe-887b-baae32789436Status:StartedSnapshotCount: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/brickOptionsReconfigured:transport.address-family: inetnfs.disable: onperformance.client-io-threads: off$ kubectl get svcNAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGEheketi                     ClusterIP192.168.101.75<none>8080/TCP   5hheketi-storage-endpoints   ClusterIP192.168.103.66<none>1/TCP      5h$ kubectl get endpointsNAME                       ENDPOINTS                            AGEheketi                     10.0.1.69:80805hheketi-storage-endpoints   10.0.1.35:1,10.0.1.4:1,10.0.1.66:15hkubernetes                 172.31.22.152:4431droot@aks-agentpool-20273348-0:~# kubectl get endpoints heketi-storage-endpoints -o yamlapiVersion: v1kind:Endpointsmetadata:  creationTimestamp:2019-01-29T15:14:28Z  name: heketi-storage-endpoints  namespace:default  resourceVersion:"142212"  selfLink:/api/v1/namespaces/default/endpoints/heketi-storage-endpoints  uid:91f802eb-23d8-11e9-bfcb-a23b1ec87092subsets:- addresses:  - ip:10.0.1.35  - ip:10.0.1.4  - ip:10.0.1.66  ports:  - port:1    protocol: TCP 

優(yōu)點(diǎn)

• 久經(jīng)考驗(yàn)的存儲方案。
• 比 Ceph 輕量。

缺點(diǎn)

• Heketi 在公有云上表現(xiàn)不佳。在私有云上表現(xiàn)良好，安裝會方便一些。
• 并非為結(jié)構(gòu)化數(shù)據(jù)設(shè)計(jì)，例如 SQL 數(shù)據(jù)庫。然而可以使用 GlusterFS 為 數(shù)據(jù)庫 提供備份和恢復(fù)支持。

Ceph Rook

我在 OpenStack 私有云上嘗試過安裝和運(yùn)行 Ceph。它需要為特定硬件定制參數(shù)，根據(jù)數(shù)據(jù)類型設(shè)計(jì) pg 組、SSD 分區(qū)和 CRUSH 圖等。所以第一次聽說在 3 節(jié)點(diǎn)的 K8s 集群上運(yùn)行 Ceph 的時(shí)候，我不太相信它能工作。結(jié)果 Rook 的編排工具讓我印象深刻，它把所有的步驟和 K8s 的編排能力結(jié)合在一起，讓安裝變得非常簡便。

在 AKS 上運(yùn)行

Rook 的缺省安裝無需任何特定步驟，如果沒什么高級配置，會非常簡單。

1. 我使用的是 Ceph 快速入門指南
2. 為 AKS 配置 FLEXVOLUME_DIR_PATH ，這是因?yàn)樗枰?/etc/kubernetes/volumeplugins/ ，而不是 Ubuntu 中缺省的 /usr/libexec ，沒有這個(gè)步驟，Kubelet 就 無法加載 PVC 了。~~~ diff –git a/cluster/examples/kubernetes/ceph/operator.yaml b/cluster/examples/kubernetes/ceph/operator.yaml index 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_PATHvalue: “/etc/kubernetes/volumeplugins” # Set the path where kernel modules can be found # – name: LIB_MODULES_DIR_PATH # value: ““ ~~~
3. 還要在 deviceFilter 中指定要使用的設(shè)備，這里是 /dev/sdc 。~~~ diff –git a/cluster/examples/kubernetes/ceph/cluster.yaml b/cluster/examples/kubernetes/ceph/cluster.yaml index 48cfeeb..0c91c48 100755 — a/cluster/examples/kubernetes/ceph/cluster.yaml +++ b/cluster/examples/kubernetes/ceph/cluster.yaml @@ -227,7 +227,7 @@ spec: storage: # cluster level storage configuration and selection useAllNodes: true useAllDevices: false deviceFilter:deviceFilter: “^sdc” location: config: ~~~
4. 安裝之后，創(chuàng)建一個(gè) Ceph block pool，以及 StorageClass，使用如下配置。apiVersion: ceph.rook.io/v1 kind:CephBlockPool metadata: name: replicapool namespace: rook-ceph spec: failureDomain: host replicated: size:3--- apiVersion: storage.k8s.io/v1 kind:StorageClass metadata: name: rook-ceph-block provisioner: ceph.rook.io/block parameters: blockPool: replicapool clusterNamespace: rook-ceph fstype: xfs reclaimPolicy:Retain
5. 最后使用部署 工具 進(jìn)行檢查。

 

$ gluster volume info vol_efb3b15529aa9aba889d7900f0ce9849VolumeName: vol_efb3b15529aa9aba889d7900f0ce9849Type:ReplicateVolume ID:96fde36b-e389-4dbe-887b-baae32789436Status:StartedSnapshotCount: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/brickOptionsReconfigured:transport.address-family: inetnfs.disable: onperformance.client-io-threads: off$ kubectl get svcNAME                       TYPE        CLUSTER-IP       EXTERNAL-IP   PORT(S)    AGEheketi                     ClusterIP192.168.101.75<none>8080/TCP   5hheketi-storage-endpoints   ClusterIP192.168.103.66<none>1/TCP      5h$ kubectl get endpointsNAME                       ENDPOINTS                            AGEheketi                     10.0.1.69:80805hheketi-storage-endpoints   10.0.1.35:1,10.0.1.4:1,10.0.1.66:15hkubernetes                 172.31.22.152:4431droot@aks-agentpool-20273348-0:~# kubectl get endpoints heketi-storage-endpoints -o yamlapiVersion: v1kind:Endpointsmetadata:  creationTimestamp:2019-01-29T15:14:28Z  name: heketi-storage-endpoints  namespace:default  resourceVersion:"142212"  selfLink:/api/v1/namespaces/default/endpoints/heketi-storage-endpoints  uid:91f802eb-23d8-11e9-bfcb-a23b1ec87092subsets:- addresses:  - ip:10.0.1.35  - ip:10.0.1.4  - ip:10.0.1.66  ports:  - port:1    protocol: TCP 

優(yōu)點(diǎn)

• 在大型生產(chǎn)環(huán)境上的健壯存儲系統(tǒng)。
• Rook 很好的簡化了生命周期管理。

缺點(diǎn)

• 復(fù)雜：更加重量級，也不太適合在公有云上運(yùn)行。在私有云上的運(yùn)行可能更加合適。

AKS 測試環(huán)境

我用 3 個(gè)虛擬機(jī)創(chuàng)建了基本的 Azure AKS 集群。為了連接到 Premium SSD 上，我只能使用 type E 以上級別的虛擬機(jī)。因此我選擇了 Standard_E2s_v3 ，其上配備了 2 vCPU 以及 16GB 的內(nèi)存。

 

 

在 AKS 集群所在的資源足中，可以看到所有的虛擬機(jī)、網(wǎng)絡(luò)接口等資源。在這里創(chuàng)建 3 個(gè) 1TB 的 Premium SSD 存儲，并手工掛載到每個(gè)虛擬機(jī)上。

 

 

這樣在每個(gè)實(shí)例上，我都有 1TB 的空磁盤。Azure 的頁面上，根據(jù)我們選擇的虛擬機(jī)和磁盤尺寸來看，性能應(yīng)該有 5000 IOPS 以及 200MB/s 的吞吐量。最后一節(jié)會顯示我們的真實(shí)結(jié)果。

 

 

性能結(jié)果

注意：每種存儲的結(jié)果并不能作為獨(dú)立的評估結(jié)果，但是其比較情況是可以參考的。有很多種對比測試的方法，這是最簡單的一種。

為了運(yùn)行測試，我決定使用現(xiàn)成的測試工具 Dbench ，它是一個(gè) k8s 的 YAML 文件，會使用 FIO 運(yùn)行 8 個(gè)測試用例。可以在 Dockerfile 中 指定不同測試 ：

• 隨機(jī)讀寫帶寬。
• 隨機(jī)讀寫 IOPS。
• 讀寫延遲。
• 順序讀寫。
• 混合讀寫 IOPS。

所有測試的結(jié)果可以在 Github 上找到。

隨機(jī)讀寫帶寬

隨機(jī)讀寫測試表明，GlusterFS、Ceph 以及 Portworx 的讀取性能比 AWS 本地盤的 hostPath 快了幾倍。讀緩存是罪魁禍?zhǔn)住lusterFS 和 Portworx 的寫入更快，其效率直逼本地磁盤。

 

 

 

 

隨機(jī)讀寫 IOPS

隨機(jī) IOPS 測試中，Portworx 和 Ceph 表現(xiàn)較好。Portworx 在寫入方面獲得了接近 Azure 原生 PVC 的 IOPS。

 

 

 

 

讀寫延遲

延遲測試的結(jié)果比較有趣，Azure 原生 PVC 比多數(shù)其它存儲都差。Portworx 和 Ceph 表現(xiàn)較好。寫入方面，GlusterFS 要優(yōu)于 Ceph。OpenEBS 的延遲相對來說非常的高。

 

 

 

 

順序讀寫

順序讀寫的結(jié)果和前面的隨機(jī)測試差不多，然而 Cpeh 在讀取方面比 GlusterFS 快了一倍多。寫入結(jié)果基本一致，只有 OpenEBS 表現(xiàn)奇差。

 

 

 

 

混合讀寫 IOPS

最后一個(gè)測試用例檢查的是混合讀寫情況下的 IOPS，Portworx 和 Ceph 都給出了優(yōu)于 Azure 原生 PVC 的結(jié)果。

 

 

 

 

結(jié)論

本文展示了一個(gè)簡單的存儲對比，使用未經(jīng)性能優(yōu)化的多種存儲提供的存儲卷進(jìn)行測試和比較。建議關(guān)注本文所述方法，不建議直接采用結(jié)果進(jìn)行判斷。

忽略 Azure 的原生 PVC 或 hostPath ，我們可以得出如下測試結(jié)果：

• Portworx 是 AKS 上最快的容器存儲。
• Ceph 是私有云集群上最快的開源存儲后端。對公有云來說，其操作太過復(fù)雜，這些多余的復(fù)雜性并沒有能提供更好的測試表現(xiàn)。
• OpenEBS 的概念很棒，但是其后端需要更多優(yōu)化。

調(diào)整性能數(shù)據(jù)的測試規(guī)模應(yīng)該會很有意思。另外值得關(guān)注的對比就是 CPU 和內(nèi)存的消耗。我會持續(xù)關(guān)注，并分享更多。