簡介:當前 NVMe 雲盤結合了業界最先進的軟硬體技術,在雲端儲存市場,首創性同時實現了 NVMe 協議 + 共享訪問 + IO Fencing 技術。它在 ESSD 之上獲得了高可靠、高可用、高效能,同時基於 NVMe 協議實現了豐富的企業特性,如多重掛載、IO Fencing、加密、離線擴容、原生快照、非同步複製等功能。本文詳細介紹了雲上SAN和NVMe的發展歷程,並做出了對未來的構想
7x24 高可用是怎樣煉成的?
現實世界中單點故障是常態,確保故障下業務連續性是高可用系統的核心能力,那麼在金融、保險、政務等關鍵應用中,如何保證業務 7*24 高可用?通常來講,業務系統由計算、網路、儲存組成,在雲上,網路多路徑和儲存分散式確保了穩定高可用,但要實現業務全鏈路高可用,還要解決計算和業務側單點故障。以常見的資料庫為例,單點故障導致業務停止對於使用者難以接受,那麼,當斷電、當機、硬體故障等導致例項不可服務時,如何快速恢復業務?
不同場景的解決方案有所不同,MySQL 通常搭建主從/主備架構實現業務高可用,主庫故障時切換到備庫持續對外提供服務。但例項切換後,如何保證主從庫資料的一致性?根據業務對資料丟失的容忍度,MySQL 通常採用同步或非同步方式進行資料複製,由此引入額外的問題:部分場景下導致資料缺失、同步資料影響系統效能、業務擴容要新增整套裝置並進行全量資料複製、主備切換時間較長影響業務連續性等。可以看到,為了搭建高可用系統,架構將變得複雜,且很難兼顧可用性、可靠性、擴充套件性、成本、效能等,那麼是否有更加先進的方案,兼得魚和熊掌?答案必須是:Yes!
圖1:資料庫的高可用架構
通過共享儲存,不同資料庫例項間可共享同一份資料,從而通過計算例項的快速切換獲得高可用(圖1),Oracle RAC、AWS Aurora、阿里雲 PolarDB 資料庫就是其中的代表。這裡的關鍵在於共享儲存,傳統 SAN 價格高昂,擴縮容麻煩,機頭也容易成為瓶頸,其使用門檻較高對使用者並不友好,有沒有更好、更快、更省的共享儲存,來解決使用者的痛點呢?阿里雲最近推出的 NVMe 雲盤和共享特性,將充分滿足使用者的訴求,接下來我們將重點介紹。這裡給大家丟擲一個問題,在例項切換過後,如果原庫仍在寫入資料,如何保證資料正確性?賣個關子,讀者可以先思考下。
圖2:主從切換場景的資料正確性問題
歷史前進的車輪:雲上 SAN 和NVMe
我們已步入“資料石油”的數字經濟時代,雲端計算、人工智慧、物聯網、5G 等技術的快速發展,促使資料的爆炸式增長。從 IDC 2020 年報告可以看出,全球資料規模逐年增長,2025 年將達到 175 ZB,資料將主要集中在公共雲和企業資料中心。資料的快速增長,為儲存的發展提供了新的動力和要求,讓我們回憶下塊儲存形態是如何一步步演進的。
圖3:塊儲存形態演進
DAS:儲存裝置採用直連方式(SCSI、SAS、FC 等協議)與主機連線,系統簡單、易於配置管理、費用較低,由於儲存資源無法被充分利用和共享,難以做到集中統⼀的管理和維護。
SAN:通過專用網路連線儲存陣列和業務主機,解決了統一管理和資料共享等問題,並實現高效能低延遲的資料訪問,不過 SAN 儲存價格昂貴、運維複雜、可擴充套件性差,提高了使用者的使用門檻。
全閃:底層儲存介質的革命和成本的下降,標誌著全快閃記憶體時代的到來,從此儲存效能轉移到軟體棧,迫使軟體進行大規模的變革,促進了使用者態協議、軟硬一體化、RDMA 等技術的高速發展,帶來了儲存效能的飛越。
雲盤:雲端計算的高速發展歷程中,儲存轉移到雲上,雲盤具有天生的優點:靈活、彈性、易用、易擴充套件、高可靠、大容量、低成本、免運維等,在數字化轉型歷程中成為儲存堅實的底座。
雲上 SAN:為全方面支援儲存業務,取代傳統的 SAN 儲存,雲上 SAN 應時代而生,它繼承了雲盤的諸多優勢,也具備了傳統 SAN 儲存能力,包括共享儲存、資料保護、同步/非同步複製、極速快照等特性,必將在企業儲存市場持續發光發熱。
另一端,在儲存協議的演進上,NVMe 正在成為新時代的寵兒。
圖4:儲存協議的演進
SCSI/SATA:儲存遠古時代,硬碟多為低速裝置,資料經過 SCSI 層和 SATA 匯流排傳輸資料,效能受限於儲存慢速介質,如機械硬碟,掩蓋了 SATA 單通道和 SCSI 軟體層的效能劣勢。
VirtIO-BLK/VirtIO-SCSI:伴隨著虛擬化技術和雲端計算的快速發展,VirtIO-BLK/VirtIO-SCSI 逐漸成為雲端計算的主流儲存協議,使得儲存資源的使用更加彈性、敏捷、安全、可擴充套件。
NVMe/NVMe-oF:快閃記憶體技術的發展和普及推動了新一代儲存技術革命,當儲存介質不再成為效能的攔路虎,軟體棧成為了最大的瓶頸,由此催生了 NVMe/NVMe-oF、DPDK/SPDK、使用者態網路等各種高效能輕量級協議,NVMe 協議族兼具高效能、高階特性和高擴充套件性,必將引領雲端計算新時代。
在可遇見的未來,雲上 SAN 和 NVMe 必將成為未來的潮流,這是大勢所趨。
雲盤新時代之 NVMe
快閃記憶體技術的迅速發展和普及,將效能瓶頸轉移到軟體側,對於儲存效能和功能的更多需求,將 NVMe 推上了歷史舞臺。NVMe 專門針對高效能裝置設計了資料訪問協議,相比傳統的 SCSI 協議,更加簡捷輕量,配合多佇列技術,能大幅度提升儲存效能。同時 NVMe 還提供了豐富的儲存特性,NVMe 標準自 2011 年誕生以來,通過不斷完善協議,規範了多 Namespace、Multi-Path、全鏈路資料保護 T10-DIF、Persistent Revervation 許可權控制協議、原子寫等眾多高階功能,其定義的儲存新特性將持續幫助使用者創造價值。
圖5:阿里雲 NVMe 雲盤
NVMe 的高效能和豐富特性,為企業儲存提供了堅實的基礎,加上協議本身具備的擴充套件性和成長性,成為演進 NVMe 雲盤的核心動力。NVMe 雲盤以 ESSD 為基礎,它繼承了 ESSD 的高可靠、高可用、高效能、原子寫等能力,以及 ESSD 原生快照資料保護、跨域容災、加密、秒級效能變配等企業特性,ESSD 和 NVMe 特性的融合,能有效的滿足企業級應用需求,使大部分基於 NVMe 和 SCSI 的業務無縫上雲。本文講述的共享儲存技術就是基於NVMe Persistent Reservation 標準實現,作為 NVMe 雲盤的附加功能之一,其多重掛載和 IO Fencing 技術,可以幫助使用者大幅降低儲存成本,並有效提升業務靈活性和資料可靠性,在分散式業務場景具有廣泛的應用,特別對於 Oracle RAC、SAP Hana 等高可用資料庫系統具有重要價值。
企業儲存利器:共享儲存
前面講到,共享儲存可以有效地解決資料庫高可用問題,其主要依賴的能力包括多重掛載和 IO Fencing,以資料庫為例,我們將講述它們是如何發揮作用的。
業務高可用關鍵 -- 多重掛載
多重掛載允許雲盤被同時掛載到多臺 ECS 例項上(當前最大支援 16),所有例項均可讀寫訪問該雲盤(圖6)。通過多重掛載,多個節點間共享同一份資料,能有效地降低儲存成本。當單節點發生故障時,業務可以迅速切換到健康節點,該過程無需進行資料複製,為故障快速恢復提供了原子能力,如 Oracle RAC、SAP HANA 等高可用資料庫均依賴該特性實現。需要留意的是,共享儲存提供了資料層的一致性和恢復能力,若要達到最終業務一致性,業務可能需要進行額外處理,如資料庫的日誌 replay 等。
圖6:多例項掛載
通常,單機檔案系統不適合作為多重掛載的檔案系統,為了加速檔案訪問,ext4 等檔案系統會對資料和後設資料進行快取,對於檔案的修改資訊無法及時同步到其他節點,從而導致多節點間資料的不一致。後設資料的不同步,也會導致節點間對硬碟空間訪問的衝突,從而引入資料錯。所以,多重掛載通常要配合叢集檔案系統使用,常見的有 OCFS2、GFS2、GPFS、Veritas CFS、Oracle ACFS 等,阿里雲 DBFS、PolarFS 也具備該能力。
有了多重掛載,是否就可以高枕無憂了?多重掛載並非萬能,它有自身無法解決的盲點:許可權管理。通常基於多重掛載的應用需要依賴叢集管理系統來管理許可權,如 Linux Pacemaker 等,但在某些場景下,許可權管理會失效從而導致嚴重問題。回憶下文章最開始丟擲的問題,在高可用架構下,主例項發生異常後會切換到備例項,如果主例項處於假死狀態(如網路分割槽、硬體故障等場景),它會錯誤地認為自己擁有寫入許可權,從而和備例項一起寫髒資料,如何規避該風險? 此時該輪到 IO Fencing 出場了。
資料正確性保證 -- IO Fencing
解決髒資料寫入的可選方案之一是:終止原例項的在途請求,並拒絕新請求繼續下發,確保舊資料不再寫入後切換例項。基於該思路,傳統的解決方案是 STONITH(shoot the other node in the head),即通過遠端重啟該故障機器來防止舊資料落盤。不過該方案存在兩個問題,首先,重啟流程過長,業務切換較慢,通常會導致幾十秒到分鐘級的業務停止。更嚴重的是,由於雲上 IO 路徑較長,涉及元件較多,計算例項的元件故障(如硬體、網路故障等)都有機率導致 IO 在短時間內無法恢復,所以無法 100% 保證資料的正確性。
為了從根本性解決該問題, NVMe 規範了 Persistent Reservation(PR)能力,它定義了 NVMe 雲盤的許可權配置規則,可以靈活地修改雲盤和掛載節點許可權。具體到該場景,在主庫發生故障後,從庫首先傳送 PR 命令禁止主庫的寫入許可權,拒絕主庫的所有在途請求,此時從庫可以無風險的進行資料更新(圖7)。IO Fencing 通常可以在毫秒級別協助應用完成故障切換,大幅縮短了故障恢復時間,業務的平滑遷移使上層應用基本無感知,相比於 STONITH 有了質的飛越。接下來我們進一步介紹 IO Fencing 的許可權管理技術。
圖7:IO Fencing 在故障切換下的應用
許可權管理的瑞士軍刀 -- Persistent Reservation
NVMe Persistent Reservation (PR) 協議定義了雲盤和客戶端許可權,搭配多重掛載能力,可以高效、安全、平穩地進行業務切換。在 PR 協議中,掛載節點有 3 種身份,分別是 Holder(所有者)、Registerant(註冊者)、Non-Registrant(訪客),從名字可以看出,所有者擁有云盤全部許可權,註冊者擁有部分許可權,訪客只擁有讀許可權。同時,雲盤擁有 6 種共享模式,可實現獨佔、一寫多讀、多寫能力,通過配置共享模式和角色身份,可以靈活地管理各節點許可權(表1),從而滿足豐富的業務場景需求。NVMe PR 繼承了 SCSI PR 的全部能力,所有基於 SCSI PR 的應用可以通過少量的改動即可執行在 NVMe 共享雲盤之上。
表1:NVMe Persistent Reservation許可權表
多重掛載配合 IO Fencing 能力,可以完美搭建高可用系統,除此之外,NVMe 共享盤還能提供一寫多讀能力,並廣泛應用於讀寫分離的資料庫、機器學習模型訓練、流式處理等場景。另外,映象共享、心跳探活、仲裁選主、鎖機制等技術可以通過共享雲盤輕鬆實現。
圖8:NVMe 共享盤一寫多讀應用場景
NVMe 雲盤技術揭祕
NVMe 雲盤基於計算儲存分離架構實現,依託於神龍硬體平臺實現了高效的 NVMe 虛擬化和極速 IO 路徑,以盤古2.0 儲存為底座實現了高可靠、高可用、高效能,計算儲存通過使用者態網路協議和 RDMA 互連,NVMe 雲盤是全棧高效能和高可用技術的結晶(圖9)。
圖9:NVMe 共享盤技術架構
NVMe 硬體虛擬化:以神龍 MOC 平臺打造了 NVMe 硬體虛擬化技術,通過 Send Queue(SQ) 和 Completion Queue(CQ) 進行資料流和控制流的高效互動,簡潔的 NVMe 協議加上高效的設計,配合硬體解除安裝技術,使 NVMe 虛擬化延遲降低 30%。
極速 IO 通道:基於神龍 MoC 軟硬一體化技術實現了極速 IO 通道,有效縮短了 IO 通路,進而獲得極致的效能。
使用者態協議:NVMe 使用了全新一代 Solar-RDMA 使用者態網路通訊協議,結合 Leap-CC 自研擁塞控制實現了資料可靠傳輸並降低了網路長尾延遲,基於 25G 網路的 JamboFrame 實現了高效的大包傳輸,通過資料面和控制面全面分離精簡了網路軟體棧並提升了效能,網路多路徑技術支撐了鏈路故障毫秒級恢復。
管控高可用:以盤古 2.0 分散式高可用儲存實現了 NVMe 控制中心,NVMe 控制命令不再經過管控節點,從而獲得接近 IO 的可靠性和可用性,可協助使用者實現毫秒級別的業務切換;基於 NVMe 控制中心實現了多客戶端和多伺服器間的精確流控,在亞秒級內實現對於 IO 的精確分散式流控;在分散式系統上實現了對於多節點的 IO Fencing 一致性,通過兩階段更新使雲盤分割槽之間許可權狀態保持一致,有效解決了分割槽許可權的腦裂問題。
大 IO 原子性:基於分散式系統從計算、網路、儲存端到端實現了大 IO 的原子寫能力,在 IO 不跨越相鄰 128K 邊界的條件下,確保同一資料不會部分落盤,這對於資料庫等依賴原子寫的應用場景具有重要作用,它能有效優化資料庫 double write 流程,從而大幅提升資料庫的寫入效能。
當前現狀和未來展望
可以看出,當前 NVMe 雲盤結合了業界最先進的軟硬體技術,在雲端儲存市場,首創性同時實現了 NVMe 協議 + 共享訪問 + IO Fencing 技術。它在 ESSD 之上獲得了高可靠、高可用、高效能,同時基於 NVMe 協議實現了豐富的企業特性,如多重掛載、IO Fencing、加密、離線擴容、原生快照、非同步複製等功能。
圖10:全球首次 NVMe + 共享訪問 + IO Fencing 技術融合
目前 NVMe 雲盤和 NVMe 共享盤已在邀測中,並得到了 Oracle RAC、SAP HANA 和內部資料庫團隊的初步認證,接下來它將進一步擴大公測範圍並商業化。在可預見的未來,我們會逐步圍繞 NVMe 雲盤持續演進,以更好地支援線上擴容、全鏈路資料保護 T10-DIF、雲盤多 namespace 等高階特性,從而進化出全面的雲上 SAN 能力,敬請期待!
<span class="lake-fontsize-12">Vendor 1</span> | <span class="lake-fontsize-12">Vendor 2</span> | <span class="lake-fontsize-12">Vendor 3</span> | <span class="lake-fontsize-12">阿里雲</span> | |
<span>雲盤協議</span> | SCSI | SCSI | NVMe | NVMe |
<span>多重掛載</span> | ✓ | ✓ | ✓ | ✓ |
<span>IO Fencing</span> | ✓ | ✓ | × | ✓ |
資料永續性 | N/A | 9個9 | 5個9 | 9個9 |
IO延遲 | > 300 us | 100~200 us | 100~200 us | < 100 us |
雲盤最大IOPS | 160K | 128K | 256K | 1000K |
雲盤最大吞吐 | 2GB/s | 1GB/s | 4GB/s | 4GB/s |