面向雲資料庫，超低延遲檔案系統PolarFS誕生了

随着國内首款Cloud Native自研資料庫POLARDB精彩亮相ICDE 2018的同時，作為其核心支撐和使能平台的PolarFS檔案系統的相關論文"PolarFS: An Ultra-low Latency and Failure Resilient Distributed File System for Shared Storage Cloud Database"也被資料庫頂級會議VLDB 2018錄用。8月，阿裡雲資料庫團隊亮相于巴西裡約召開的VLDB 2018，對整個業界起到了非常積極的影響。

VLDB(Very Large Data Base)和另外兩大資料庫會議SIGMOD、ICDE構成了資料庫領域的三個頂級會議。VLDB國際會議于1975在美國的弗雷明漢馬 (Framingham MA) 成立，是資料庫研究人員，供應商，參與者，應用開發者，以及使用者一年一度的頂級國際論壇。

VLDB主要由四個主題構成，分别為：Core Database Technology (核心資料庫技術)，Infrastructure for Information Systems (基礎設施資訊系統)，Industrial Applications and Experience (工業應用與經驗) 以及 Experiments and Analyses（實驗和分析）。

從09年至今的資料分析來看，VLDB的論文接受率總體是比較低，其中，核心資料庫主題中的論文接受率大概為16.7%；基礎設施資訊系統方面的論文接受率大約為17.9%；工業應用與經驗的論文接收比例近視為18%；而實驗和分析部分的為19%左右。由此可見，論文被VLDB接收不是件容易的事情，必須是創新性很高，貢獻很大的論文才有機會被錄用。

本文着重介紹PolarFS的系統設計與實作。

背景

如同Oracle存在與之比對的OCFS2，POLARDB作為存儲與計算分離結構的一款資料庫，PolarFS承擔着發揮POLARDB特性至關重要的角色。PolarFS是一款具有超低延遲和高可用能力的分布式檔案系統，其采用了輕量的使用者空間網絡和I／O棧建構，而棄用了對應的核心棧，目的是充分發揮RDMA和NVMe SSD等新興硬體的潛力，極大地降低分布式非易失資料通路的端到端延遲。目前，PolarFS的3副本跨節點寫入的通路總延遲已經非常接近單機本地PCIe SSD的延遲水準，成功地使得POLARDB在分布式多副本架構下仍然能夠發揮出極緻的性能。

設計初衷

針對資料庫設計分布式檔案系統會帶來以下幾點好處：

計算節點和存儲節點可以使用不同的伺服器硬體，并能獨立地進行定制。例如，計算節點不需要考慮存儲容量和記憶體容量的比例，其嚴重依賴于應用場景并且難以預測。

多個節點上的存儲資源能夠形成單一的存儲池，這能降低存儲空間碎化、節點間負載不均衡和空間浪費的風險，存儲容量和系統吞吐量也能容易地進行水準擴充。

資料庫應用的持久狀态可下移至分布式檔案系統，由分布式存儲提供較高的資料可用性和可靠性。是以資料庫的高可用處理可被簡化，也利于資料庫執行個體在計算節點上靈活快速地遷移。

此外，雲資料庫服務也會是以帶來額外的收益：

雲資料庫可以采用虛拟計算環境如KVM等部署形态，其更安全、更易擴充和更易更新管理。

一些關鍵的資料庫特性，如一寫多讀執行個體、資料庫快照等可以通過分布式檔案系統的資料共享、檢查點等技術而得以增強。

系統結構

系統元件

PolarFS系統内部主要分為兩層管理：

存儲資源的虛拟化管理，其負責為每個資料庫執行個體提供一個邏輯存儲空間。

檔案系統中繼資料的管理，其負責在該邏輯存儲空間上實作檔案管理，并負責檔案并發通路的同步和互斥。

PolarFS的系統結構如圖所示：

• libpfs是一個使用者空間檔案系統庫，負責資料庫的I/O接入。
• PolarSwitch運作在計算節點上，用于轉發資料庫的I／O請求。
• ChunkServer部署在存儲節點上，用于處理I／O請求和節點内的存儲資源分布。
• PolarCtrl是系統的控制平面，它包含了一組實作為微服務的管理者，相應地Agent代理被部署到所有的計算和存儲節點上。

在進一步介紹各部分之前，我們先來了解下PolarFS存儲資源的組織方法：

PolarFS的存儲資源管理單元分為3層：Volume、Chunk、Block。

Volume

Volume是為每個資料庫提供的獨立邏輯存儲空間，其上建立了具體檔案系統供此資料庫使用，其大小為10GB至100TB，可充分适用于典型雲資料庫執行個體的容量要求。

在Volume上存放了具體檔案系統執行個體的中繼資料。檔案系統中繼資料包括inode、directory entry和空閑資源塊等對象。由于POLARDB采用的是共享檔案存儲架構，我們在檔案層面實作了檔案系統中繼資料一緻性，在每個檔案系統中除DB建立的資料檔案之外，我們還有用于中繼資料更新的Journal檔案和一個Paxos檔案。我們将檔案系統中繼資料的更新首先記錄在Journal檔案中，并基于Paxos檔案以disk paxos算法實作多個執行個體對Journal檔案的互斥寫通路。

Chunk

每個Volume内部被劃分為多個Chunk，Chunk是資料分布的最小粒度，每個Chunk隻存放于存儲節點的單個NVMe SSD盤上，其目的是利于資料高可靠和高可用的管理。典型的Chunk大小為10GB，這遠大于其他類似的系統，例如GFS的64MB。

這樣做的優勢是能夠有效地減少Volume的第一級映射中繼資料量的大小（例如，100TB的Volume隻包含10K個映射項）。一方面，全局中繼資料的存放和管理會更容易；另一方面，這使得中繼資料可以友善地緩存在記憶體中，進而有效避免關鍵I/O路徑上的額外中繼資料通路開銷。

但這樣做的潛在問題是，當上層資料庫應用出現區域級熱點通路時，Chunk内熱點無法進一步打散，但是由于我們的每個存儲節點提供的Chunk數量往往遠大于節點數量（節點:Chunk在1:1000量級），PolarFS可支援Chunk的線上遷移，并且服務于大量資料庫執行個體，是以可以将不同執行個體的熱點以及同一執行個體跨Chunk的熱點分布到不同節點以獲得整體的負載均衡。

Block

在ChunkServer内，Chunk會被進一步劃分為多個Block，其典型大小為64KB。Blocks動态映射到Chunk 中來實作按需配置設定。Chunk至Block的映射資訊由ChunkServer自行管理和儲存，除資料Block之外，每個Chunk還包含一些額外Block用來實作Write Ahead Log。我們也将本地映射中繼資料全部緩存在ChunkServer的記憶體中，使得使用者資料的I／O通路能夠全速推進。

下面我們詳細介紹PolarFS的各個系統元件。

libpfs

libpfs是一個輕量級的使用者空間庫，PolarFS采用了編譯到資料庫的形态，替換标準的檔案系統接口，這使得全部的I／O路徑都在使用者空間中，資料處理在使用者空間完成，盡可能減少資料的拷貝。這樣做的目的是避免傳統檔案系統從核心空間至使用者空間的消息傳遞開銷，尤其資料拷貝的開銷。這對于低延遲硬體的性能發揮尤為重要。

其提供了類Posix的檔案系統接口（見下表），因而付出很小的修改代價即可完成資料庫的使用者空間化。

PolarSwitch

PolarSwitch是部署在計算節點的Daemon，它負責I/O請求映射到具體的後端節點。資料庫通過libpfs将I/O請求發送給PolarSwitch，每個請求包含了資料庫執行個體所在的Volume ID、起始偏移和長度。PolarSwitch将其劃分為對應的一到多個Chunk，并将請求發往Chunk所屬的ChunkServer完成通路。

ChunkServer

ChunkServer部署在後端存儲節點上。一個存儲節點可以有多個ChunkServer。每個ChunkServer綁定到一個CPU核，并管理一個獨立的NVMe SSD盤，是以ChunkServer之間沒有資源争搶。

ChunkServer負責Chunk内的資源映射和讀寫。每個Chunk都包括一個WAL，對Chunk的修改會先進Log再修改，保證資料的原子性和持久性。ChunkServer使用了3DXPoint SSD和普通NVMe SSD混合型WAL buffer，Log會優先存放到更快的3DXPoint SSD中。

ChunkServer會複制寫請求到對應的Chunk副本（其他ChunkServer）上，我們通過自己定義的Parallel Raft一緻性協定來保證Chunk副本之間在各類故障狀況下資料正确同步和保障已Commit資料不丢失。

PolarCtrl

PolarCtrl是PolarFS叢集的控制核心。其主要職責包括：

1. 監控ChunkServer的健康狀況，确定哪些ChunkServer有權屬于PolarFS叢集；
2. Volume建立及Chunk的布局管理（即Chunk配置設定到哪些ChunkServer）；
3. Volume至Chunk的中繼資料資訊維護；
4. 向PolarSwitch推送元資訊緩存更新；
5. 監控Volume和Chunk的I/O性能；
6. 周期性地發起副本内和副本間的CRC資料校驗。

PolarCtrl使用了一個關系資料庫雲服務用于管理上述metadata。

中心統控，局部自治的分布式管理

分布式系統的設計有兩種範式：中心化和去中心化。中心化的系統包括GFS和HDFS，其包含單中心點，負責維護中繼資料和叢集成員管理。這樣的系統實作相對簡單，但從可用性和擴充性的角度而言，單中心可能會成為全系統的瓶頸。去中心化的系統如Dynamo完全相反，節點間是對等關系，中繼資料被切分并備援放置在所有的節點上。去中心化的系統被認為更可靠，但設計和實作會更複雜。

PolarFS在這兩種設計方式上做了一定權衡，采用了中心統控，局部自治的方式：PolarCtrl是一個中心化的master，其負責管理任務，如資源管理和處理控制平面的請求如建立Volume。ChunkServer負責Chunk内部映射的管理，以及Chunk間的資料複制。當ChunkServer彼此互動時，通過ParallelRaft一緻性協定來處理故障并自動發起Leader選舉，這個過程無需PolarCtrl參與。

PolarCtrl服務由于不直接處理高并發的I／O流，其狀态更新頻率相對較低，因而可采用典型的多節點高可用架構來提供PolarCtrl服務的持續性，當PolarCtrl因崩潰恢複出現的短暫故障間隙，由于PolarSwitch的緩存以及ChunkServer資料平面的局部中繼資料管理和自主leader選舉的緣故，PolarFS能夠盡量保證絕大部分資料I／O仍能正常服務。

I/O 流程

下面我們通過一個I/O的處理來說明各元件的互動過程。

PolarFS執行寫I/O請求的過程如上圖所示：

1. POLARDB通過libpfs發送一個寫請求，經由ring buffer發送到PolarSwitch。
2. PolarSwitch根據本地緩存的中繼資料，将該請求發送至對應Chunk的主節點。
3. 新寫請求到達後，主節點上的RDMA NIC将寫請求放到一個提前分好的buffer中，并将該請求項加到請求隊列。一個I／O輪詢線程不斷輪詢這個請求隊列，一旦發現新請求到來，它就立即開始處理。
4. 請求通過SPDK寫到硬碟的日志block，并通過RDMA發向副本節點。這些操作都是異步調用，資料傳輸是并發進行的。
5. 當副本請求到達副本節點，副本節點的RDMA NIC同樣會将其放到預分buffer中并加入到複制隊列。
6. 副本節點上的I／O輪詢線程被觸發，請求通過SPDK異步地寫入Chunk的日志。
7. 當副本節點的寫請求成功回調後，會通過RDMA向主節點發送一個應答響應。
8. 主節點收到一個複制組中大多數節點的成功傳回後，主節點通過SPDK将寫請求應用到資料塊上。
9. 随後，主節點通過RDMA向PolarSwitch傳回。
10. PolarSwitch标記請求成功并通知上層的POLARDB。

資料副本一緻性模型

ParallelRaft協定設計動機

一個産品級别的分布式存儲系統需要確定所有送出的修改在各種邊界情況下均不丢失。PolarFS在Chunk層面引入一緻性協定來保證檔案系統資料的可靠性和一緻性。設計之初，從工程實作的成熟度考慮，我們選擇了Raft算法，但對于我們建構的超低延遲的高并發存儲系統而言，很快就遇到了一些坑。

Raft為了簡單性和協定的可了解性，采用了高度串行化的設計。日志在leader和follower上都不允許有空洞，其意味着所有log項會按照順序被follower确認、被leader送出并apply到所有副本上。是以當有大量并發寫請求執行時，會按順序依次送出。處于隊列尾部的請求，必需等待所有之前的請求已被持久化到硬碟并傳回後才會被送出和傳回，這增加了平均延遲也降低了吞吐量。我們發現當并發I／O深度從8升到32時，I／O吞吐量會降低一半。

Raft并不十分适用于多連接配接的在高并發環境。實際中leader和follower使用多條連接配接來傳送日志很常見。當一個連結阻塞或者變慢，log項到達follower的順序就會變亂，也即是說，一些次序靠後的log項會比次序靠前的log項先到。但是，Raft的follower必需按次序接收log項，這就意味着這些log項即使被記錄到硬碟也隻能等到前面所有缺失的log項到達後才能傳回。并且假如大多數follower都因一些缺失的項被阻塞時，leader也會出現卡頓。我們希望有一個更好的協定可以适應這樣的情形。

由于PolarFS之上運作的是Database事務處理系統，它們在資料庫邏輯層面的并行控制算法使得事務可以交錯或亂序執行的同時還能生成可串行化的結果。這些應用天然就需要容忍标準存儲語義可能出現的I／O亂序完成情況，并由應用自身進一步保證資料一緻性。是以我們可以利用這一特點，在PolarFS中依照存儲語義放開Raft一緻性協定的某些限制，進而獲得一種更适合高I／O并發能力發揮的一緻性協定。

我們在Raft的基礎上，提供了一種改進型的一緻性協定ParallelRaft。ParallelRaft的結構與Raft一緻，隻是放開了其嚴格有序化的限制。

亂序日志複制

Raft通過兩個方面保障串行化：

1. 當leader發送一個log項給follower，follower需要傳回ack來确認該log項已經被收到且記錄，同時也隐式地表明所有之前的log項均已收到且儲存完畢。
2. 當leader送出一個log項并廣播至所有follower，它也同時确認了所有之前的log項都已被送出了。ParallelRaft打破了這兩個限制，并讓這些步驟可亂序執行。

是以，ParallelRaft與Raft最根本的不同在于，當某個entry送出成功時，并不意味着之前的所有entry都已成功送出。是以我們需要保證：

1. 在這種情況下，單個存儲的狀态不會違反存儲語義的正确性；
2. 所有已送出的entry在各種邊界情況下均不會丢失；

有了這兩點，結合資料庫或其他應用普遍存在的對存儲I／O亂序完成的預設容忍能力，就可以保證它們在PolarFS上的正常運轉，并獲得PolarFS提供的資料可靠性。

ParallelRaft的亂序執行遵循如下原則：

1. 當寫入的Log項彼此的存儲範圍沒有交疊，那麼就認為Log項無沖突可以亂序執行；
2. 否則，沖突的Log項将按照寫入次序依次完成。

容易知道，依照此原則完成的I／O不會違反傳統存儲語義的正确性。

接下來我們來看log的ack-commit-apply環節是如何是以得到優化并且保持一緻性的。

• 亂序确認（ack）：當收到來自leader的一個log項後，Raft follower會在它及其所有之前的log項都持久化後，才發送ack。ParallelRaft則不同，任何log entry成功持久化後均能立即傳回，這樣就優化了系統的平均延遲。
• 亂序送出（commit）：Raft leader串行送出log項，一個log項隻有之前的所有項送出之後才能送出。而ParallelRaft的leader在一個log項的多數副本已經确認之後即可送出。這符合存儲系統的語義，例如，NVMe SSD驅動并不檢查讀寫指令的LBA來保證并行指令的次序，對指令的完成次序也沒有任何保證。
• 亂序應用（apply）：對于Raft，所有log項都按嚴格的次序apply，是以所有副本的資料檔案都是一緻的。但是，ParallelRaft由于亂序的确認和送出，各副本的log都可能在不同位置出現空洞，這裡的挑戰是，如何保證前面log項有缺失時，安全地apply一個log項？

ParallelRaft引入了一種新型的資料結構look behind buffer來解決apply中的問題。

1. ParallelRaft的每個log項都附帶有一個look behind buffer。look behind buffer存放了前N個log項修改的LBA摘要資訊。
2. look behind buffer的作用就像log空洞上架設的橋梁，N表示橋梁的寬度，也就是允許單個空洞的最大長度，N的具體取值可根據網絡連續缺失log項的機率大小，靜态地調整為合适的值，以保證log橋梁的連續性。
3. 通過look behind buffer，follower能夠知道一個log項是否沖突，也就是說是否有缺失的前序log項修改了範圍重疊的LBAs。沒有沖突的log項能被安全apply。如有沖突，它們會被加到一個pending list，待之前缺失的沖突log項apply之後，才會接着apply。

通過上述的異步ack、異步commit和異步apply，PolarFS的chunk log entry的寫入和送出避免了次序造成的額外等待時間，進而有效縮減了高并發3副本寫的平均時延。

ParallelRaft協定正确性

我們在ParallelRaft的設計中，確定了Raft協定關鍵特性不丢失，進而保障了新協定的正确性。

1. ParallelRaft協定的設計繼承了原有Raft協定的Election Safety、Leader Append-Only及Log Matching特性。
2. 沖突log會以嚴格的次序送出，是以協定的State Machine Safety特性能夠最終得以保證。
3. 我們在Leader選舉階段額外引入了一個Merge階段，填補Leader中log的空洞，能夠有效保障協定的Leader Completeness特性。

PolarFS中與POLARDB緊密相關的設計

檔案系統多副本高速寫入——資料庫單執行個體的超高TPS，資料高可靠

PolarFS設計中采用了如下技術以充分發揮I/O性能：

1. PolarFS采用了綁定CPU的單線程有限狀态機的方式處理I/O，避免了多線程I/O pipeline方式的上下文切換開銷。
2. PolarFS優化了記憶體的配置設定，采用MemoryPool減少記憶體對象構造和析構的開銷，采用巨頁來降低分頁和TLB更新的開銷。
3. PolarFS通過中心加局部自治的結構，所有中繼資料均緩存在系統各部件的記憶體中，基本完全避免了額外的中繼資料I/O。
4. PolarFS采用了全使用者空間I/O棧，包括RDMA和SPDK，避免了核心網絡棧和存儲棧的開銷。

在相同硬體環境下的對比測試，PolarFS中資料塊3副本寫入性能接近于單副本本地SSD的延遲性能。進而在保障資料可靠性的同時，極大地提升POLARDB的單執行個體TPS性能。

下圖是我們采用Sysbench對不同負載進行的初步測試比較。

1. POLARDB on PolarFS
2. Alibaba MySQL Cloud Service RDS

用例負載：OLTP，隻讀、隻寫（update : delete : insert = 2:1:1）、讀寫混合（read : write = 7:2）。資料庫測試集資料量為500GB。

可以發現POLARDB在PolarFS下取得了較好的性能，PolarFS同時支援了POLARDB的高TPS和資料的高可靠性。

檔案系統共享通路——寫多讀的資料庫QPS強擴充，資料庫執行個體的Failover

PolarFS是共享通路的分布式檔案系統，每個檔案系統執行個體都有相應的Journal檔案和與之對應的Paxos檔案。Journal檔案記錄了metadata的修改曆史，是共享執行個體之間中繼資料同步的中心。Journal檔案邏輯上是一個固定大小的循環buffer。PolarFS會根據水位來回收journal。Paxos檔案基于Disk Paxos實作了分布式互斥鎖。

由于journal對于PolarFS非常關鍵，它們的修改必需被Paxos互斥鎖保護。如果一個節點希望在journal中追加項，其必需使用DiskPaxos算法來擷取Paxos檔案中的鎖。通常，鎖的使用者會在記錄持久化後馬上釋放鎖。但是一些故障情況下使用者不釋放鎖。為此在Paxos互斥鎖上配置設定有一個租約lease。其他競争者可以重新開機競争過程。當PolarFS當節點開始同步其他節點修改的中繼資料時，它從上次掃描的位置掃描到journal末尾，将新entry更新到memory cache中。

下圖展示了檔案系統中繼資料更新和同步的過程。

1. 節點1配置設定塊201至檔案316後，請求互斥鎖，并獲得。
2. Node 1開始記錄事務至journal中。最後寫入項标記為pending tail。當所有的項記錄之後，pending tail變成journal的有效tail。
3. Node1更新superblock，記錄修改的中繼資料。與此同時，node2嘗試擷取node1擁有的互斥鎖，Node2會失敗重試。
4. Node2在Node1釋放lock後拿到鎖，但journal中node1追加的新項決定了node2的本地中繼資料是過時的。
5. Node2掃描新項後釋放lock。然後node2復原未記錄的事務并更新本地metadata。最後Node2進行事務重試。
6. Node3開始自動同步中繼資料，它隻需要load增量項并在它本地重放即可。

PolarFS的上述共享機制非常适合POLARDB一寫多讀的典型應用擴充模式。一寫多讀模式下沒有鎖争用開銷，隻讀執行個體可以通過原子I/O無鎖擷取Journal資訊，進而使得POLARDB可以提供近線性的QPS性能擴充。

由于PolarFS支援了基本的多寫一緻性保障，當可寫執行個體出現故障時，POLARDB能夠友善地将隻讀執行個體更新為可寫執行個體，而不必擔心底層存儲産生不一緻問題，因而友善地提供了資料庫執行個體Failover的功能。

檔案系統級快照——POLARDB的瞬時邏輯備份

對于百TB級超大資料庫執行個體的備份而言，資料庫快照是必須支援的功能。

PolarFS采用了自有的專利快照技術，能夠基于位于底層的多個ChunkServer的局部快照，建構Volume上的統一的檔案系統即時映像。POLARDB利用自身資料庫的日志，能夠基于此檔案系統映像快速建構出此具體時點的資料庫快照，進而有效支援資料庫備份和資料分析的需求。

可以發現，POLARDB的高性能、強擴充、輕運維等具備競争優勢的優異特性，與PolarFS的緊密協作息息相關，PolarFS發揮了強大的使能作用。

結論

PolarFS是一個專為雲資料庫而設計的分布式檔案系統，其能夠支援跨節點高可靠性同時提供極緻的性能。PolarFS采用了新興硬體和先進的優化技術，例如OS-bypass和zero-copy，使得PolarFS中資料塊3副本寫入性能接近于單副本本地SSD的延遲性能。PolarFS在使用者空間實作了POSIX相容接口，使得POLARDB等資料庫服務能夠盡量少地修改即可獲得PolarFS帶來的高性能的優勢。

可以看到，面向資料庫的專有檔案系統，是保障未來資料庫技術領先的一個不可或缺的關鍵一環。資料庫核心技術的進展及其專有檔案系統的使能，是一個相輔相成的演進過程，二者的結合也會随着當今系統技術的進步而愈加緊密。

未來我們将探索NVM和FPGA等新硬體，以期通過檔案系統與資料庫的深度結合來進一步優化POLARDB資料庫的性能。

作者：鳴嵩，弘然，明書，旭危，甯進，文義，韓逸，翊雲

感謝POLARDB團隊全體同學

論文下載下傳位址：

https://yq.aliyun.com/download/2951