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 能力，敬請期待！

	Vendor 1	Vendor 2	Vendor 3	阿里雲
雲盤協議	SCSI	SCSI	NVMe	NVMe
多重掛載	✓	✓	✓	✓
IO Fencing	✓	✓	×	✓
資料永續性	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

表2：主流雲計算廠商的塊儲存概覽

原文連結：http://click.aliyun.com/m/1000303901/