摘要

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

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

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

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

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

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

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

存儲

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

Azure 原生 StorageClass

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

這個方案很方便，什么多余的步驟都不需要。創(chuàng)建一個新的 AKS 集群之后，就自動提供了兩個預定義的 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)點

AKS 開箱即用。

缺點

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

OpenEBS

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

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

在 AKS 上運行

在 AKS 上的安裝非常容易。

1. 連接到所有 K8s 節(jié)點上，安裝 iSCSI，這是因為他需要使用 iSCSI 協(xié)議在 K8s 節(jié)點之間進行 Pod 和控制器的連接。apt-get update apt install -y open-iscsi
2. 使用一個 YAML 定義在 K8s 集群上完成部署：kubectl apply -f https://openebs.github.io/charts/openebs-operator-0.8.0.yaml
3. 下一步，OpenEBS 控制器發(fā)現(xiàn)了節(jié)點中的所有磁盤。但是我必須手工標識出我附加的 AWS 托管磁盤。$ kubectl get disk NAME AGE disk-184d99015253054c48c4aa3f17d137b15m disk-2f6bced7ba9b2be230ca5138fd0b07f15m disk-806d3e77dd2e38f188fdaf9c46020bdc5m
4. 然后把這些磁盤加入 StoragePoolClaim，這個對象會在 StorageClass 中進行引用：--- 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)點

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

缺點

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

注：OpenEBS 團隊對我的案例場景進行了調(diào)整：

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

Portworx

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

在 AKS 上運行

在 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)建一個 StorageClass，定義高優(yōu)先級，以及三個副本：

 

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)點

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

缺點

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

GlusterFS Heketi

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

在 AKS 上運行

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

1. 參照 樣例 ，創(chuàng)建一個包含磁盤和主機名的拓撲文件。
2. Heketi 主要的開發(fā)和測試都在基于 RHEL 的操作系統(tǒng)上，我在 AKS 上使用 Ubuntu 主機時，出現(xiàn)了內(nèi)核模塊路徑錯誤的問題，我提交了一個 PR 來修正這個問題。~~~ +++ 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)境中遇到的另一個問題是一個非空磁盤，所以我用 wipefs 為 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 ，會在每個節(jié)點上運行 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，加載給測試 工具 進行測試。

 

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)點

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

缺點

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

Ceph Rook

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

在 AKS 上運行

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

1. 我使用的是 Ceph 快速入門指南
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.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 中指定要使用的設備，這里是 /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)建一個 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. 最后使用部署 工具 進行檢查。

 

$ 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)點

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

缺點

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

AKS 測試環(huán)境

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

 

 

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

 

 

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

 

 

性能結(jié)果

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

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

• 隨機讀寫帶寬。
• 隨機讀寫 IOPS。
• 讀寫延遲。
• 順序讀寫。
• 混合讀寫 IOPS。

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

隨機讀寫帶寬

隨機讀寫測試表明，GlusterFS、Ceph 以及 Portworx 的讀取性能比 AWS 本地盤的 hostPath 快了幾倍。讀緩存是罪魁禍首。GlusterFS 和 Portworx 的寫入更快，其效率直逼本地磁盤。

 

 

 

 

隨機讀寫 IOPS

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

 

 

 

 

讀寫延遲

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

 

 

 

 

順序讀寫

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

 

 

 

 

混合讀寫 IOPS

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

 

 

 

 

結(jié)論

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

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

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

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