在上一篇文章中，強調了區分系統存儲介質訪問方式的重要性，接下來，需要考慮的問題就是IO請求所經過的網絡路徑。

所謂IO請求路徑，通常包括幾個部分：接收外部(如虛擬機的)IO請求、尋址即將外部IO請求轉換為(ServerSAN)系統內部請求、將內部IO請求發至相應的存儲節點以實現數據訪問。

在一個ServerSAN系統中，通常會由客戶端塊設備驅動來負責接收外部IO請求，其處理方式亦尋址方式有多種：有些需要查詢元數據庫(Metadata Store，用于存放內部數據塊的元數據，包括數據塊在哪個存儲節點上的信息);有的則利用Consistent Hashing的方法，直接計算出IO請求對應的內部存儲地址，從而達到省略查詢元數據庫的目的。

此外，將內部請求發送到存儲節點也有多種方式：以副本為3份的寫請求為例，有的是將數據依次寫入3個存儲節點，如此就涉及3個網絡跳轉;也有的是將數據先寫入主節點(Primary)，再由主節點發給另外兩個從節點，如此需要兩個網絡跳轉。另外一種方式是同時廣播給3個存儲節點，如此只涉及一個網絡跳轉。

圖 1擁有最長網絡路徑的系統

以Sheepdog Storage系統為例，一個IO請求需要通過QEMU block driver，Gateway，存儲節點3個網絡跳轉，即網絡路徑為3。以Ceph為例，一個IO請求需要通過RBD(客戶端驅動)，主OSD(存儲節點)，從OSD共3個網絡跳轉，即網絡路徑為3。

圖 2擁有最短網絡路徑的系統

目前為止，我們見到的分布式存儲系統里***的I/O路徑為2：客戶端驅動和存儲節點;其中尋址功能被合并到客戶端驅動，并且尋址不需要查詢元數據庫。客戶端驅動直接廣播到所有的存儲節點上。

同樣的，就像上篇文章提到，有沒有一個判斷ServerSAN系統I/O路徑的簡單方法呢?

不幸地是，我們很難通過一個系統的外部表象來判斷這個系統的I/O路徑是多少，是否***?我也沒有想出一個簡單的方法。但就像判斷直接和間接訪問裸設備一樣，判斷系統的I/O路徑對于判斷系統的水平也是非常重要的。

盡管沒有一個簡單的方法，但在實際的選型過程中，I/O路徑應該成為一個考察的重點，用戶應該要求供應商介紹其系統架構，以及外部I/O、內部I/O請求的方法，一旦我們得知系統不是內直接尋址或不是將數據一次性廣播給所有的副本節點，我們就可以得出如此的判斷：該系統的I/O路徑極有可能不是極有可能***的。

(未完待續)

作者簡介：陳靚，1999年北京航空航天大學碩士畢業，2002年考入美國俄亥俄州立大學學習計算機科學，2006年獲得該校博士學位。此后入職美國Amazon，于AWS Storage Team(云計算核心存儲團隊)工作，長達7年之久，曾經擔任系統架構師和研發團隊帶頭人，負責設計和實現了著名的AWS Glacier系統結構;2011年加入AWS S3團隊，負責對AWS S3 的Volume子系統新版本的研發。2013年，接受南京市政府321計劃的感召，選擇歸國創業，創辦了南京鵬云網絡科技有限公司，致力于私有云存儲產品的研發。2015年入選中組部“國家千人計劃”專家人才。