兩年前，我們在 KubeCon 2017 上首次認識 Diamanti，他們的願景給我們留下了深刻印象：提供專為微服務和雲原生環境構建的裸機容器平台，並針對 Kubernetes 或基本上是超融合進行了優化Kubernetes 的基礎設施設備。 我們認為這是一個有趣的遊戲，去年在 KubeCon 2018 上，我們開始與他們討論與我們合作以了解 Kubernetes 上的存儲以及如何以有條不紊的方式測試和量化 Kubernetes 存儲，以便我們可以開始測試和記錄Kubernetes 存儲性能。
兩年前，我們在 KubeCon 2017 上首次認識 Diamanti，他們的願景給我們留下了深刻印象：提供專為微服務和雲原生環境構建的裸機容器平台，並針對 Kubernetes 或基本上是超融合進行了優化Kubernetes 的基礎設施設備。 我們認為這是一個有趣的遊戲，去年在 KubeCon 2018 上，我們開始與他們討論與我們合作以了解 Kubernetes 上的存儲以及如何以有條不紊的方式測試和量化 Kubernetes 存儲，以便我們可以開始測試和記錄Kubernetes 存儲性能。
Diamanti 與 Diamanti 合作非常愉快，並且能夠為我們提供創建測試方法所需的對 Kubernetes 和 Kubernetes 存儲的深刻理解。 Diamanti 由前 VMware、VERITAS 和 Cisco 工程師創立，由高盛和其他知名風險投資公司資助，這令人印象深刻，但更令人印象深刻的是 Diamanti 一直是存儲和網絡標準（即 FlexVolume/CSI）的主要貢獻者和 CNI）已被上游 Kubernetes 代碼接受。
企業業務正在以光速發展，公司正試圖通過新技術跟上這種發展的步伐，以加快其整個應用程序的生產週期。 容器是旨在加速應用程序開發和部署的技術，但在遺留基礎設施上構建它們可能很複雜，並且很快成為構建功能齊全的容器堆棧的相當大的障礙。 容器與傳統存儲和網絡基礎設施不兼容，因此構建容器環境的自己動手 (DIY) 方法對 IT 具有挑戰性、成本高且節奏緩慢。 Diamanti Enterprise Kubernetes Platform 旨在為基礎設施架構師、IT 運維人員和應用程序所有者提供大規模運行有狀態容器化應用程序所需的速度、簡單性、效率和控制力。
Diamanti Enterprise Kubernetes Platform 是一個裸機容器平台，專注於快速啟動和運行的網絡和存儲方面，尤其適用於大型企業。 通過完全集成開源 Docker 和 Kubernetes，以及專用硬件和對整個堆棧的完整支持，Diamanti Enterprise Kubernetes Platform 是一個可以在幾分鐘內部署的完整容器解決方案。 Diamanti 表示在其企業 Kubernetes 平台上具有無與倫比的性能和利用率； 這種性能的秘訣在於使用專為 Kubernetes 容器使用網絡和存儲資源的方式而設計的獨特超融合架構。
Diamanti D10 規格
| 網絡 | 4×10 GbE 通過單個 QSFP+ 連接（每個節點） |
| 儲存應用 | |
| 資料存儲 | 4 TB 配置（每個節點 4 個 1000 GB NVMe SSD） 8 TB 配置（每個節點 4 個 2000 GB NVMe SSD） 32 TB 配置（每個節點 4 個 8000 GB NVMe SSD） |
| 主機操作系統和 Docker 鏡像存儲 | 960 GB（每個節點 2 個 480 GB SATA SSD） |
| 計算 | |
| 中央處理器 | 2 個 Intel Xeon 處理器，20 / 32 / 44 核（每個節點） |
| 內存 | 192 GB / 384 GB / 768 GB（每個節點 |
| 物理 | |
| 外形 | 1U |
| 尺寸和重量（每個節點） | 17.25″W x 28″D x 1.72″H / 52 磅。 43.8cm x 71.1cm x 4.4cm / 24 公斤 |
| 電力 | 雙冗餘 110/220V 電源 |
| 環境建議 | 工作溫度：50°C至95°C（10°F至35°F） |
構建和設計
Diamanti 設備是 Diamanti 容器堆棧解決方案的物理硬件。 該設備以最小的三節點集群提供，其中每個節點都是一個 1U 機架，提供高達 32TB 的數據存儲容量和 960GB 的主機操作系統和 Docker 映像存儲。
節點的正面顯示了一個鋁製格柵，專為高效氣流而設計，中間是公司的原木，左上角是一個鎖定機構。 在正面的右上角，是提供電源開關的控制面板，以及用於顯示系統運行狀況的 LED 指示燈。 卸下鋁製格柵將顯示驅動器插槽位置，還有一個 VGA 和兩個 USB 端口。
移動到設備的後部，我們可以看到設備的端口。 這裡我們重點介紹左邊的兩個獨立電源和一個通風系統； 中間/右側是兩個管理端口，一個用於連接高性能和低延遲節點的 10GbE 端口，一個 QSFP+ 端口（用於 4x10G SFP+），以及 4 個用於連接鍵盤和其他外圍設備的 USB 端口。
管理
該設備附帶預集成的完整軟件堆棧，包括操作系統、Docker、Kubernetes 和其他容器融合服務。 它通過瀏覽器、CLI 或 REST API 和 Diamanti OS 提供儀表板和報告功能。 Diamanti 企業 Kubernetes 平台通過了 K8s 認證； CNCF 組織設計的認證。
對於管理，我們期待 Diamanti 控制台。 打開它，我們直接進入儀表板，其中包含易於快速閱讀的基本信息。 在這裡我們可以看到有多少節點在運行，有多少容器，有多少 Pod。 CPU、存儲、內存和網絡的使用情況也很容易在左側的百分比中看到。 右邊是以 Kbps 為單位的帶寬。
下一個主要選項卡是創建應用程序。 一旦用戶創建了他們想要創建的應用程序，子選項卡就會顯示帶有一個小 Kubernetes 圖標的 Deploy。 用戶需要從這裡輸入名稱、圖像、環境、端口、卷安裝以及 CPU 和內存量等信息。
下一個主要選項卡是應用程序。 主選項卡下方是子選項卡：Pod、Replications Controllers、Replica Sets、Stateful Sets、Daemon Sets、Deployments 和 Jobs。 Pod 為用戶提供了所選 Pod 的健康狀況以及歸屬計算、網絡和存儲的簡要摘要。
Stateful Sets 子選項卡使用戶能夠深入了解集合併在需要時導出它們。 在這裡，我們會看到一些基本信息，例如名稱、命名空間、所需號碼、當前號碼、準備就緒的號碼、年齡以及採取什麼行動的選項。
用戶還可以深入查看 Pod 日誌以查看活動和任何潛在問題。
下一個主要選項卡是 K8S 配置。 用戶可以在這裡管理 Kubernetes 相關的應用程序配置，如服務帳戶、查看 Secrets、Config Maps 和創建命名空間。
從節點管理選項卡，用戶可以查看、添加或刪除節點以及監控節點資源利用率。 同樣，用戶可以在這裡監控給定節點和資源的整體健康狀況：計算、網絡和存儲。
正如該選項卡的名稱所暗示的那樣，存儲管理使用戶能夠查看存儲的所有內容，包括卷、快照、驅動器、持久卷、持久卷聲明、存儲類和備份。 在 Volumes 子選項卡下，我們可以創建新卷或查看現有捲的摘要，包括其運行狀況、存儲吞吐量和使用情況。
Drives 子選項卡允許用戶查看物理驅動器利用的信息，例如驅動器所在的插槽、其 S/N、原始容量、可用容量、分配的容量、其固件以及它所處的狀態。驅動器可以從此子選項卡進行格式化。
Persistent Volumes 子選項卡允許用戶創建或導出持久卷，並提供諸如其名稱、類型容量、訪問、回收、狀態、聲明、存儲可用性、年齡和操作列表（包括編輯、導出和刪除）等信息。刪除。
Persistent Volume Claims 對 PVC 的作用與上述相同。
我們的下一個主要選項卡是網絡管理選項卡。 用戶可以在這裡創建、刪除、編輯或導出網絡。 這裡我們給出了名稱、組、是否為默認網絡、主機網絡、其子網、網關、起始地址、結束地址和 IP 地址等信息。
用戶管理相當簡單。 管理員可以在這裡創建用戶和組，並設置各種訪問控制策略。
高級設置允許管理員創建和調整集群和性能層。
雖然我們通常會逐步介紹各種管理功能，讓讀者大致了解他們逐步了解某些內容時會發生什麼，但我們這次做的事情有點不同。 我們還運行了我們的基準測試，以便我們可以看到 GUI 在其上運行更重的工作負載時的效果。 對於這些基準中的每一個，我們都將位於“節點管理”選項卡中。
通過我們的基本（隨機和順序）測試，您可以輕鬆地看到右側的計算和性能指標。
我們的 SQL 測試對計算和網絡造成的損失相當小，而存儲達到近 1 萬次 IOPS。
最後，我們給出了一個示例，說明在我們的 Oracle 測試運行時會發生什麼。
性能
VDBench 工作負載分析
在對存儲陣列進行基準測試時，應用程序測試是最好的，綜合測試排在第二位。 雖然不能完美代表實際工作負載，但綜合測試確實有助於為具有可重複性因素的存儲設備建立基線，從而可以輕鬆地在競爭解決方案之間進行同類比較。 這些工作負載提供了一系列不同的測試配置文件，包括“四個角”測試和常見的數據庫傳輸大小測試，以及來自不同 VDI 環境的跟踪捕獲。 所有這些測試都利用通用的 Vdbench 工作負載生成器和腳本引擎來自動化和捕獲大型計算測試集群的結果。 這使我們能夠在各種存儲設備上重複相同的工作負載，包括閃存陣列和單個存儲設備。
簡介：
- 4K 隨機讀取：100% 讀取，128 個線程，0-120% 重複率
- 4K 隨機寫入：100% 寫入，64 線程，0-120% iorate
- 64K 順序讀取：100% 讀取，16 線程，0-120% 迭代
- 64K 順序寫入：100% 寫入，8 個線程，0-120% 迭代
- 綜合數據庫：SQL 和 Oracle
在我們所有的 VDBench 測試中，我們基於一次運行 3、6、9 或 12 個 Vdbench pod 的不同部署測試了 Diamanti 設備，以突破設備的極限。 從隨機 4K 讀取性能開始，所有 Vdbench pod 都以 120μs 的延遲啟動； IO 性能介於 3 個 pod 的 95,863 IOPS 和 12 個 pod 的 269,208 IOPS 之間。 查看峰值性能，所有配置都保持在 600μs 延遲以下。 使用 3 個 Vdbench pod，我們在 947,619μs 的延遲下看到了 370 IOPS 的峰值； 6 個 pod，峰值 1,745,344 IOPS，延遲 436μs； 有 9 個 pod，峰值為 2,492019 IOPS，延遲為 447μs； 最後一個部署是 12 個 pod，峰值為 2,753,170 IOPS，延遲為 554μs。
查看 4K 寫入性能，所有測試部署在 300 微秒的延遲下開始，但在達到最大性能時迅速增加到 26 毫秒到 28 毫秒。 性能在 3 個 pod 時達到 13,719 IOPS 的峰值； 6 個 pod，27,747 IOPS； 9 個 pod，42,805 IOPS； 12 個 pod，58,559 IOPS。 在添加更多 pod 時表現出穩定的性能提升。
切換到順序工作負載，我們查看設備的 64K 讀取性能，這裡的 3 pod 部署以 14,560 IOPS 或 910MB/s 開始，延遲為 297μs。 所有其他部署開始時接近 18,000 IOPS 或 1.1GB/s，延遲為 227μs。 關於部署的峰值性能，3 pod 部署在 143,431μs 的延遲下繼續達到 9 IOPS 或 327GB/s 的峰值。 所有其他部署的峰值性能幾乎相同，均為 179,000 IOPS 或 11.1GB/s，12 個 pod 部署是唯一通過 1ms 延遲標記的部署。
在 64K 順序寫入中，Vdbench 的所有部署都以接近 350μs 的延遲開始。 部署達到峰值如下：3 個 pod，9,693 IOPS 或 606MB/s，延遲為 4.9ms； 6 個 pod，22,202 IOPS 或 1.39GB/s，延遲為 4.3ms； 9 個 pod，30,475 IOPS 或 1.9GB/s，延遲為 4.7 毫秒； 最後，12 個 pod 達到 32,052 IOPS 或 2.4GB/s 的峰值，延遲為 4.9ms。
我們的下一組測試是我們的 SQL 工作負載：SQL、SQL 90-10 和 SQL 80-20。 對於 SQL，所有部署都在 180 微秒的延遲下啟動。 3 個 pod 以 26,291 IOPS 開始，並以 261,573 IOPS 達到峰值，延遲為 366μs。 6 個 pod 開始時為 57,061 IOPS，峰值為 570,642 IOPS，延遲為 336μs。 9 個 pod 以 86,197 IOPS 開始，峰值為 885,269 IOPS，延遲為 332μs。 12 個 pod 部署以 101,753 IOPS 開始，並以 1,106,860 IOPS 達到峰值，延遲為 346μs。
對於 SQL 90-10，所有部署都以接近 200 微秒的延遲開始。 3 pod 部署開始時為 10,753 IOPS，峰值為 105,877 IOPS，延遲為 904μs。 6 個 pod 開始時為 49,361 IOPS，峰值為 245,158 IOPS，延遲為 782μs。 9 個 pod 以 80,157 IOPS 開始，峰值為 401,444 IOPS，延遲為 716μs。 12 個 pod 部署開始時的 IOPS 為 55,748，峰值為 554,685 IOPS，延遲為 690μs。
對於我們最後的 SQL 測試，80-20，我們看到 Vdbench 部署也開始非常接近 200μs 延遲。 部署達到峰值如下：3 個 pod 部署為 57,944 IOPS，延遲為 1.6 毫秒； 6 個 pod 的峰值為 132,384 IOPS，延遲為 1.4 毫秒； 9 個 pod 217,273 IOPS，延遲為 1.3ms； 12 個 pod 部署達到 305,426 IOPS 的峰值，延遲為 1.2 毫秒。
接下來是我們的 Oracle 工作負載：Oracle、Oracle 90-10 和 Oracle 80-20。 使用 Oracle，所有部署都在 210 微秒內啟動。 在這裡，我們看到了部署的峰值性能。 3 個 pod 達到 54,844 IOPS 的峰值，延遲為 2.2 毫秒。 6 個 pod 的峰值為 125,633 IOPS，延遲為 1.9 毫秒。 9 個 pod 的峰值為 206,024 IOPS，延遲為 1.7 毫秒。 12 個 pod 部署達到 290,313 IOPS 的峰值，延遲為 1.6 毫秒。
在 Oracle 90-10 中，部署啟動時間不到 200 微秒。 3 個 pod 部署達到 106,182 IOPS 的峰值，延遲為 620μs。 6 個 pod 的峰值為 243,383 IOPS，延遲為 541μs。 9 個 pod 的峰值為 393,727 IOPS，延遲為 502μs。 最後，12 個 pod 部署達到 544,584 IOPS 的峰值，延遲為 483μs。
對於 Oracle 80-20，我們又一次看到所有部署以 210 微秒的延遲開始。 查看部署的峰值性能，我們看到 3 個 pod 的峰值為 58,037 IOPS，延遲為 1.1 毫秒； 6 個 pod 的峰值為 132,911 IOPS，延遲為 991μs； 9 個 pod 的峰值為 215,817 IOPS，延遲為 915μs； 最後，12 個 pod 部署達到 304,391 IOPS 的峰值，延遲為 865μs。
結論
Kubernetes 已被較小的公司所接受，現在正在成熟為大多數（如果不是所有）財富 500 強公司正在關注的一項技術，並且一些更具前瞻性的公司已開始實施。 Kubernetes 僅出現了 5 年，但已經通過了技術採用曲線上的創新者階段，穩固地處於早期採用者的陣營中。 這種在技術採用曲線上的定位很重要，因為 Kubernetes 社區已經找到了讓 Kubernetes 運行的方法，現在正專注於讓它運行良好，我們希望這樣的測試將幫助 Kubernetes 消費者決定與哪些供應商合作並通過給供應商一個標準來幫助他們進行比較。
Diamanti 使用 D10 容器設備構建了一個引人注目的 Kubernetes 解決方案，提供了一個信息豐富且易於使用的管理界面和一個用於託管容器的非常快速的後端存儲平台。 由於這仍然是一個新興領域，市場上沒有很多完全充實的解決方案，但從我們所看到的情況來看，D10 能夠達到我們傳統上從存儲或 HCI 解決方案。 性能通常非常出色，從我們的集群測試 2.7 到 4 個 pod 中提供超過 3 萬 IOPs 12K 隨機讀取。 從延遲的角度來看，我們開始時剛好超過 100 微秒，最高時為 600 微秒。 在存儲方面，它的性能令人難以置信，而且來自一個非常令人難以置信的新興技術平台。 從寫入的角度來看，該設備提供 50k IOPS 4K 隨機，這似乎是唯一的弱點，但公司應該能夠通過軟件甚至存儲介質解決這個問題。 連續帶寬提供超過 11GB/s 的讀取速度，同樣非常強大且可用的性能，峰值寫入速度為 2.4GB/s。
總的來說，對於在其環境中部署 Kubernetes 的客戶，Diamanti D10 容器設備從託管和存儲的角度為那些希望認真研究快速和鬆散的容器市場的人提供了一個很好的交鑰匙方法。 公平地說，這並不適合所有人，集群的目標非常具體。 但是，如果您符合該目標，Diamanti 提供的正是這些客戶想要的，它就是專門為這些類型的新興容器工作負載而構建的。 雖然完全有可能利用適用於 VMware 的 PKS 或更專注於企業的替代解決方案，但 Diamanti 提供了一個複雜性較低的系統，並且與傳統企業堆棧相比應該具有成本優勢。 由於解決方案的完整性（它具有用於更改的良好 GUI）和非常出色的性能配置文件，我們確定 D10 是當之無愧的 StorageReview 編輯選擇獎得主。
