這是伺服器硬體領域很常見的一個神話。 在實踐中，許多事情都需要超融合解決方案（當一切都合而為一時）。 從歷史上看，第一個架構是由亞馬遜和谷歌為其服務開發的。 當時的想法是用相同的節點創建一個計算場，每個節點都有自己的磁碟。 所有這些都由一些系統形成軟體（管理程式）統一起來，並被劃分為虛擬機器。 主要目標是為一個節點提供最少的服務，並在擴展時將出現的問題最少：只需購買另外一千或兩台相同的伺服器並在附近連接它們即可。 在實踐中，這些都是孤立的情況，而且更多時候我們談論的是較少數量的節點和略有不同的架構。
但優點仍然是一樣的——令人難以置信的輕鬆擴展和管理。 缺點是不同的任務消耗資源不同，有的地方本地磁碟很多，有的地方RAM很少，等等，也就是對於不同類型的任務，資源利用率會降低。
事實證明，為了方便設置，您需要多支付 10-15% 的費用。 這就是引發標題中神話的原因。 我們花了很長時間尋找該技術的最佳應用場景，最終我們找到了。 事實上，思科沒有自己的儲存系統，但他們想要一個完整的伺服器市場。 他們製作了 Cisco Hyperflex - 一種在節點上提供本地儲存的解決方案。
這突然被證明是備份資料中心（災難復原）的一個非常好的解決方案。 我現在就告訴你原因和方法。 我將向您展示集群測試。
需要的地方
超融合是：
- 將磁碟傳輸到計算節點。
- 儲存子系統與虛擬化子系統完全整合。
- 與網路子系統的傳輸/整合。
這一組合使您可以在虛擬化層級實現許多儲存系統功能，並且全部透過一個控制視窗實現。
在我們公司，設計冗餘資料中心的專案需求量很大，由於具有大量開箱即用的複製選項（最多可達城域叢集），因此通常會選擇超融合解決方案。
就備份資料中心而言，我們通常談論的是位於城市另一端或完全位於另一個城市的站點上的遠端設施。 它允許您在主資料中心發生部分或完全故障時恢復關鍵系統。 銷售資料不斷地在那裡複製，這種複製可以在應用程式層級或在區塊裝置（儲存）層級。
因此，現在我將討論系統設計和測試，然後討論一些儲蓄資料的實際應用情境。
測試
我們的實例由四台伺服器組成，每台伺服器都有 10 個 960 GB 的 SSD 硬碟。 有專門的磁碟用於快取寫入操作和儲存業務虛擬機器。 解決方案本身是第四個版本。 第一個坦率地說是粗糙的（從評論來看），第二個是潮濕的，第三個已經相當穩定，而這個可以稱為公眾測試結束後的發布。 在測試過程中我沒有發現任何問題，一切都像時鐘一樣工作。
v4 中的變化修復了一系列錯誤。
最初，該平台只能與 VMware ESXi 虛擬機器管理程式搭配使用，並支援少量節點。 此外，部署過程並不總是成功結束，某些步驟必須重新啟動，從舊版本更新存在問題，GUI中的資料並不總是正確顯示（儘管我仍然對效能圖的顯示不滿意） ），有時在與虛擬化的介面上會出現問題。
現在所有童年問題都已修正，HyperFlex 可以處理 ESXi 和 Hyper-V，此外還可以：
- 建立延伸集群。
- 在不使用 Fabric Interconnect 的情況下為辦公室創建一個集群，從兩個到四個節點（我們只購買伺服器）。
- 能夠與外部儲存系統配合使用。
- 支援容器和 Kubernetes。
- 建立可用區。
- 如果內建功能不令人滿意，則與 VMware SRM 整合。
該架構與其主要競爭對手的解決方案沒有太大區別；他們沒有創造自行車。 它全部運行在 VMware 或 Hyper-V 虛擬化平台上。 此硬體託管在專有的 Cisco UCS 伺服器上。 有些人討厭這個平台，因為初始設定相對複雜，有很多按鈕，模板和依賴關係的不平凡的系統，但有些人已經學習了 Zen，受到這個想法的啟發，不再想要與其他伺服器一起工作。
我們將考慮針對VMware的解決方案，因為該解決方案最初是為其創建的並且具有更多功能；在此過程中添加了Hyper-V，以便跟上競爭對手並滿足市場期望。
有一個裝滿磁碟的伺服器叢集。 有用於資料儲存的磁碟（SSD 或 HDD - 根據您的喜好和需求），有一個 SSD 磁碟用於快取。 當寫入資料到資料儲存時，資料會保存在快取層（服務虛擬機器的專用SSD磁碟和RAM）。 同時，資料塊被傳送到叢集中的節點（節點數量取決於叢集複製因子）。 所有節點確認記錄成功後，記錄確認訊息將傳送至虛擬機器管理程序，然後傳送至虛擬機器。 記錄的資料在背景進行重複資料刪除、壓縮並寫入儲存磁碟。 同時，大塊總是順序寫入儲存磁碟，減少了儲存磁碟的負載。
重複資料刪除和壓縮始終啟用且無法停用。 資料直接從儲存磁碟或RAM 快取中讀取。 如果使用混合配置，讀取也會快取在 SSD 上。
資料不依賴虛擬機器的當前位置，並且在節點之間均勻分佈。 這種方法允許您平等地載入所有磁碟和網路介面。 有一個明顯的缺點：我們無法盡可能減少讀取延遲，因為無法保證本地資料的可用性。 但我認為，與所獲得的好處相比，這只是一個小小的犧牲。 此外，網路延遲已經達到了幾乎不會影響整體結果的程度。
在每個儲存節點上建立一個特殊的服務VM Cisco HyperFlex資料平台控制器，負責磁碟子系統的整個操作邏輯。 在我們的服務虛擬機器配置中，分配了 72 個 vCPU 和 28 GB RAM，這並不算少。 讓我提醒您一下，主機本身有 512 個實體核心和 XNUMX GB RAM。
業務虛擬機透過將SAS控制器轉送給虛擬機，直接存取實體磁碟。 與虛擬機器管理程式的通訊透過特殊模組 IOVisor 進行，該模組會攔截 I/O 操作，並使用允許您向虛擬機器管理程式 API 發送命令的代理程式。 該代理負責使用 HyperFlex 快照和克隆。
磁碟資源作為 NFS 或 SMB 共用安裝在虛擬機器管理程式中（根據虛擬機器管理程式的類型，猜猜哪一個在哪裡）。 在底層，這是一個分散式檔案系統，可讓您新增成熟的成熟儲存系統的功能：精簡磁碟區分配、壓縮和重複資料刪除、使用寫入時重定向技術的快照、同步/非同步複製。
服務VM提供HyperFlex子系統WEB管理介面的存取。 與 vCenter 集成，大多數日常任務都可以從中執行，但例如，如果您已經切換到快速 HTML5 界面，或者使用成熟的 Flash 用戶端，則可以更方便地從單獨的網絡攝像頭中剪切數據存儲完全集成。 在服務網路攝影機中，您可以查看系統的效能和詳細狀態。
叢集中還有另一種類型的節點—計算節點。 這些伺服器可以是沒有內建磁碟的機架式或刀鋒式伺服器。 這些伺服器可以運行虛擬機，其資料儲存在帶有磁碟的伺服器上。 從資料存取的角度來看，節點類型之間沒有區別，因為架構涉及資料物理位置的抽象化。 計算節點與儲存節點的最大比例為2:1。
使用運算節點可以提高擴展叢集資源時的靈活性：如果我們只需要 CPU/RAM，則無需購買具有磁碟的額外節點。 此外，我們還可以添加刀片籠並節省伺服器的機架佈局。
因此，我們擁有一個具有以下功能的超融合平台：
- 叢集中最多 64 個節點（最多 32 個儲存節點）。
- 叢集中的最小節點數為三個（邊緣叢集為兩個）。
- 資料冗餘機制：複製因子2和3的鏡像。
- 地鐵集群。
- 非同步虛擬機器複製到另一個 HyperFlex 叢集。
- 將虛擬機器切換到遠端資料中心的編排。
- 使用寫入時重新導向技術的本機快照。
- 在複製因子 1 且不進行重複資料刪除的情況下，可用空間高達 3 PB。 我們不考慮複製因子 2，因為這不是嚴肅銷售的選擇。
另一個巨大的優點是易於管理和部署。 設定 UCS 伺服器的所有複雜性均由思科工程師準備的專用虛擬機器處理。
測試台配置：
- 2 個 Cisco UCS Fabric Interconnect 6248UP 作為管理叢集和網路元件（48 個連接埠在乙太網路 10G/FC 16G 模式下運作）。
- 四台 Cisco UCS HXAF240 M4 伺服器。
伺服器特色：
中央處理器
2 個英特爾® 至強® E5-2690 v4
內存
16 個 32GB DDR4-2400-MHz RDIMM/PC4-19200/雙列/x4/1.2v
網絡
UCSC-MLOM-CSC-02（維多利亞州 1227）。 2 個 10G 乙太網路端口
儲存主機卡
思科 12G 模組化 SAS 直通控制器
儲存磁碟
1 個 SSD Intel S3520 120 GB、1 個 SSD 三星 MZ-IES800D、10 個 SSD 三星 PM863a 960 GB
更多配置選項除了選定的硬體之外，目前還提供以下選項：
- HXAF240c M5。
- 一到兩台 CPU，範圍從 Intel Silver 4110 到 Intel Platinum I8260Y。 第二代可用。
- 24 個記憶體插槽，從 16 GB RDIMM 2600 到 128 GB LRDIMM 2933。
- 6至23個資料盤、XNUMX個快取碟、XNUMX個系統碟和XNUMX個啟動磁碟。
容量驅動
- HX-SD960G61X-EV 960GB 2.5 吋企業級 6G SATA SSD（1 倍耐用性）SAS 960 GB。
- HX-SD38T61X-EV 3.8TB 2.5 吋企業級 6G SATA SSD（1 倍耐用性）SAS 3.8 TB。
- 快取驅動器
- HX-NVMEXPB-I375 375GB 2.5 吋英特爾傲騰驅動器，極致性能和耐用性。
- HX-NVMEHW-H1600* 1.6TB 2.5 吋入門級性能。 NVMe SSD（3 倍耐用性）NVMe 1.6 TB。
- HX-SD400G12TX-EP 400GB 2.5 吋入門級性能。 12G SAS SSD（10 倍耐用性）SAS 400 GB。
- HX-SD800GBENK9** 800GB 2.5 吋入門級性能。 12G SAS SED SSD（10 倍耐用性）SAS 800 GB。
- HX-SD16T123X-EP 1.6TB 2.5 吋企業級效能 12G SAS SSD（3 倍耐用性）。
系統/日誌驅動器
- HX-SD240GM1X-EV 240GB 2.5 吋企業級 6G SATA SSD（需升級）。
引導驅動器
- HX-M2-240GB 240GB SATA M.2 固態硬碟 SATA 240 GB。
透過 40G、25G 或 10G 乙太網路連接埠連接到網路。
FI 可以是 HX-FI-6332 (40G)、HX-FI-6332-16UP (40G)、HX-FI-6454 (40G/100G)。
測試本身
為了測試磁碟子系統，我使用了 HCIBench 2.2.1。 這是一個免費實用程序，可讓您自動從多個虛擬機器建立負載。 負載本身是由通常的fio產生的。
我們的叢集由四個節點組成，複製因子為3，所有磁碟都是快閃記憶體。
為了進行測試，我創建了四個資料儲存和八個虛擬機器。 對於寫入測試，假設快取磁碟未滿。
測試結果如下：
100% 讀取 100% 隨機
0% 讀取 100% 隨機
區塊/隊列深度
128
256
512
1024
2048
128
256
512
1024
2048
4K
0,59 毫秒 213804 IOPS
0,84 毫秒 303540 IOPS
1,36 毫秒 374348 IOPS
2.47 毫秒 414116 IOPS
4,86 毫秒 420180 IOPS
2,22 毫秒 57408 IOPS
3,09 毫秒 82744 IOPS
5,02 毫秒 101824 IPOS
8,75 毫秒 116912 IOPS
17,2 毫秒 118592 IOPS
8K
0,67 毫秒 188416 IOPS
0,93 毫秒 273280 IOPS
1,7 毫秒 299932 IOPS
2,72 毫秒 376,484 IOPS
5,47 毫秒 373,176 IOPS
3,1 毫秒 41148 IOPS
4,7 毫秒 54396 IOPS
7,09 毫秒 72192 IOPS
12,77 毫秒 80132 IOPS
16K
0,77 毫秒 164116 IOPS
1,12 毫秒 228328 IOPS
1,9 毫秒 268140 IOPS
3,96 毫秒 258480 IOPS
3,8 毫秒 33640 IOPS
6,97 毫秒 36696 IOPS
11,35 毫秒 45060 IOPS
32K
1,07 毫秒 119292 IOPS
1,79 毫秒 142888 IOPS
3,56 毫秒 143760 IOPS
7,17 毫秒 17810 IOPS
11,96 毫秒 21396 IOPS
64K
1,84 毫秒 69440 IOPS
3,6 毫秒 71008 IOPS
7,26 毫秒 70404 IOPS
11,37 毫秒 11248 IOPS
粗體表示生產率沒有增加，有時甚至可見下降的值。 這是因為我們受到網路/控制器/磁碟效能的限制。
- 順序讀取 4432 MB/秒。
- 順序寫入 804 MB/秒。
- 如果一個控制器發生故障（虛擬機器或主機發生故障），效能會倍增。
- 如果儲存磁碟發生故障，則回撤為 1/3。 磁碟重建佔用每個控制器5%的資源。
在小塊上，我們受到控制器（虛擬機器）效能的限制，其CPU負載為100%，當區塊增加時，我們受到連接埠頻寬的限制。 10 Gbps 不足以釋放 AllFlash 系統的潛力。 不幸的是，所提供的演示站的參數不允許我們測試 40 Gbit/s 的操作。
根據我的測試和研究架構的印象，由於在所有主機之間放置資料的演算法，我們獲得了可擴展的、可預測的效能，但這也是讀取時的限制，因為有可能從本機磁碟中擠出更多內容，這裡可以節省一個更有效率的網絡，例如可以使用 40 Gbit/s 的 FI。
此外，用於快取和重複資料刪除的一個磁碟可能是一個限制；事實上，在這個測試台中，我們可以寫入四個 SSD 磁碟。 如果能夠增加快取驅動器的數量並看到差異，那就太好了。
實際使用
要組織備份資料中心，您可以使用兩種方法（我們不考慮將備份放置在遠端站點）：
- 主動-被動。 所有應用程式都託管在主資料中心。 複製是同步或非同步的。 如果主資料中心發生故障，我們需要啟動備份資料中心。 這可以手動/腳本/編排應用程式來完成。 這裡我們會得到一個與複製頻率相稱的RPO，而RTO則取決於管理員的反應和技能以及切換計畫的開發/調試品質。
- 主動-主動。 在這種情況下，只有同步複製；資料中心的可用性由嚴格位於第三站點的仲裁/仲裁器決定。 RPO = 0，RTO可以達到0（如果應用允許）或等於虛擬化叢集中節點的故障轉移時間。 在虛擬化級別，建立需要主動-主動儲存的延伸（Metro）叢集。
通常我們看到客戶已經在主資料中心實現了具有經典儲存系統的架構，因此我們設計了另一個用於複製的架構。 正如我所提到的，思科 HyperFlex 提供非同步複製和延伸虛擬化叢集創建。 同時，我們不需要中端及更高級別的專用儲存系統，具有昂貴的複製功能和兩個儲存系統上的雙活資料存取。
場景一： 我們擁有主資料中心和備份資料中心，以及基於 VMware vSphere 的虛擬化平台。 所有生產系統都位於主資料中心，虛擬機器的複製在虛擬機器管理程式層級執行，這將避免虛擬機器在備份資料中心保持開啟。 我們使用內建工具複製資料庫和特殊應用程序，並保持虛擬機器開啟。 如果主資料中心發生故障，我們會在備份資料中心啟動系統。 我們認為我們有大約 100 個虛擬機器。 當主資料中心運作時，備用資料中心可以運行測試環境和其他系統，如果主資料中心切換，這些系統可以關閉。 我們也可以使用雙向複製。 從硬體角度來看，不會有任何改變。
在經典架構的情況下，我們將在每個資料中心安裝一個混合儲存系統，透過FibreChannel存取、分層、重複資料刪除和壓縮（但不是線上），每個站點8台伺服器、2個FibreChannel交換器和10G乙太網路。 對於經典架構中的複製和切換管理，我們可以使用VMware工具（Replication + SRM）或第三方工具，這會更便宜一些，有時也更方便。
如圖所示。
使用Cisco HyperFlex時，請取得以下架構：
對於 HyperFlex，我使用了具有大量 CPU/RAM 資源的伺服器，因為… 部分資源將分配給HyperFlex控制器VM；在CPU和記憶體方面，我甚至重新配置了HyperFlex配置，以免與Cisco合作並保證剩餘VM的資源。 但我們可以放棄光纖通道交換機，並且每個伺服器都不需要乙太網路連接埠；本地流量在 FI 內交換。
結果是每個資料中心的配置如下：
服務器
8 個 1U 伺服器（384 GB RAM、2 個英特爾金牌 6132、FC HBA）
8 個 HX240C-M5L（512 GB RAM、2 個英特爾金牌 6150、3,2 GB 固態硬碟、10 個 6 TB NL-SAS）
SHD
具有 FC 前端的混合儲存系統（20TB SSD、130TB NL-SAS）
-
區域網路
2 個乙太網路交換器 10G 12 端口
-
SAN的
2 個 FC 交換器 32/16Gb 24 端口
2 個思科 UCS FI 6332
執照
VMware Ent Plus
虛擬機器切換的複製和/或編排
VMware Ent Plus
我沒有為 Hyperflex 提供複製軟體許可證，因為我們可以開箱即用。
對於古典建築，我選擇了一家已成為優質且廉價製造商的供應商。 對於這兩個選項，我都應用了特定解決方案的標準折扣，因此我收到了實際價格。
事實證明，思科 HyperFlex 解決方案便宜了 13%。
場景一： 建立兩個活躍的資料中心。 在此場景中，我們正在 VMware 上設計一個延伸叢集。
經典架構由虛擬化伺服器、SAN（FC 協定）和兩個可以讀取和寫入它們之間延伸的磁碟區的儲存系統組成。 我們在每個儲存系統上放置了有用的儲存容量。
在 HyperFlex，我們只需建立一個在兩個網站上具有相同數量節點的延伸叢集。 在本例中，使用 2+2 的複製因子。
結果是以下配置：
古典建築
超彈性
服務器
16 個 1U 伺服器（384 GB RAM、2 個 Intel Gold 6132、FC HBA、2 個 10G NIC）
16 個 HX240C-M5L（512 GB RAM、2 個英特爾金牌 6132、1,6 TB NVMe、12 個 3,8 TB 固態硬碟、VIC 1387）
SHD
2 個全快閃儲存系統（150 TB SSD）
-
區域網路
4 個乙太網路交換器 10G 24 端口
-
SAN的
4 個 FC 交換器 32/16Gb 24 端口
4 個思科 UCS FI 6332
執照
VMware Ent Plus
VMware Ent Plus
在所有運算中，我沒有考慮網路基礎架構、資料中心成本等：對於經典架構和 HyperFlex 解決方案來說，它們是相同的。
就成本而言，HyperFlex 貴了 5%。 這裡值得注意的是，就 CPU/RAM 資源而言，我對思科有偏差，因為在配置中我均勻地填充了記憶體控制器通道。 成本稍高，但不是一個數量級，這清楚地表明超融合不一定是“富人的玩具”，但可以與構建數據中心的標準方法競爭。 那些已經擁有 Cisco UCS 伺服器及其相應基礎架構的人可能也會對此感興趣。
優點包括：無需管理 SAN 和儲存系統的成本、線上壓縮和重複資料刪除、單一支援入口點（虛擬化、伺服器，它們也是儲存系統）、節省空間（但並非在所有情況下）、簡化操作。
至於支持，您可以從一家供應商獲得—思科。 根據我使用 Cisco UCS 伺服器的經驗來看，我喜歡它；我不必在 HyperFlex 上開啟它，一切都一樣。 工程師反應迅速，不僅能解決典型問題，還能解決複雜的邊緣狀況。 有時我會向他們提出問題：“這有可能嗎，管它呢？” 或「我在這裡配置了一些東西，但它不起作用。 幫助！” - 他們會耐心地在那裡找到必要的指南並指出正確的操作；他們不會回答：“我們只解決硬體問題。”
引用
- 我的郵件 - [電子郵件保護]
來源： www.habr.com