對于分布式存儲的若干看法
Q: 現在領域內對于分布式存儲的應用場景是否有比較明確的分類?比如冷熱，快慢，大文件小文件之類的?
分布式存儲的應用場景相對于其存儲接口，現在流行分為三種:
1. 對象存儲: 也就是通常意義的鍵值存儲，其接口就是簡單的GET,PUT，DEL和其他擴展，如七牛、又拍，Swift，S3、
2. 塊存儲: 這種接口通常以QEMU Driver或者Kernel Module的方式存在，這種接口需要實現Linux的Block Device的接口或者QEMU提供的Block Driver接口，如Sheepdog，AWS的EBS，青云的云硬盤和阿里云的盤古系統，還有Ceph的RBD(RBD是Ceph面向塊存儲的接口)
3. 文件存儲: 通常意義是支持POSIX接口，它跟傳統的文件系統如Ext4是一個類型的，但區別在于分布式存儲提供了并行化的能力，如Ceph的 CephFS(CephFS是Ceph面向文件存儲的接口)，但是有時候又會把GFS，HDFS這種非POSIX接口的類文件存儲接口歸入此類。
按照這三種接口和其應用場景，很容易了解這三種類型的IO特點，括號里代表了它在非分布式情況下的對應:
1. 對象存儲(鍵值數據庫): 接口簡單，一個對象我們可以看成一個文件，只能全寫全讀，通常以大文件為主，要求足夠的IO帶寬。
2. 塊存儲(硬盤): 它的IO特點與傳統的硬盤是一致的，一個硬盤應該是能面向通用需求的，即能應付大文件讀寫，也能處理好小文件讀寫。但是硬盤的特點是容量大，熱點明顯。因此塊存儲主要可以應付熱點問題。另外，塊存儲要求的延遲是***的。
3. 文件存儲(文件系統): 支持文件存儲的接口的系統設計跟傳統本地文件系統如Ext4這種的特點和難點是一致的，它比塊存儲具有更豐富的接口，需要考慮目錄、文件屬性等支持，實現一個支持并行化的文件存儲應該是最困難的。但像HDFS、GFS這種自己定義標準的系統，可以通過根據實現來定義接口，會容易一點。
因此，這三種接口分別以非分布式情況下的鍵值數據庫、硬盤和文件系統的IO特點來對應即可。至于冷熱、快慢、大小文件而言更接近于業務。但是因為存儲系統是通用化實現，通常來說，需要盡量滿足各種需求，而接口定義已經一定意義上就砍去了一些需求，如對象存儲會以冷存儲更多，大文件為主。
Q: 實現思路方面是否又有一些通用的分類法?
實現上主要有兩層區別：
1. 系統的分布式設計: 主從、還是全分布式或者是兼而有之，目前現在存儲系統因為一致性的要求，以主從為主。
2. 底層的單機存儲: 一種是依賴本地文件系統的接口，如GlusterFS，Swift，Sheepdog，Ceph。一種是依賴塊接口的，目前只知道Nutanix是使用這個的(http://stevenpoitras.com/the-nutanix-bible)。***一種是依賴鍵值接口的，目前應該只有Ceph是支持(Ceph支持多種單機存儲接口)。***種依賴文件系統是因為分布式存儲系統本身已經夠復雜，實現者很難從上層一直到底層存儲都去實現，而本地文件系統已經是一個通用化并且非常成熟的實現，因此分布式存儲系統絕大部分(上述提到的都應該是)都會直接依賴本地文件系統。第二種接口目前只知道Nutanix 是支持的(傳統的存儲廠商的存儲產品一般會使用這種方式)，這種接口也就是比***種去掉了文件系統層，實現一個簡單的物理塊管理即可。第三種它的主要原因是“存儲定義”和對象存儲的普及，希望硬盤來提供簡單的鍵值接口即可，如希捷的Kinetic API(https://github.com/Seagate/Kinetic-Preview)，FusionIO的 NVMKV(https://github.com/opennvm/nvmkv)，這種接口另一方面是閃存廠商非常喜愛的，因為閃存的物理特性使得它支持鍵值接口比快接口容易得多，目前Ceph是支持這種接口，而希捷和華為最近推出了IP硬盤(http://net.zdnet.com.cn /network_security_zone/2013/1024/2993465.shtml)，聽說已經實現了Swift上的原型。
(從這里可以發現，分布式存儲系統是在傳統的單機接口上重新包裝了一層，然后實現三種類似的接口)
Q: 另外，對于不同的實現方案，分布式存儲系統的性能是可以直接測試的，但理論可用性、數據可靠性的計算方式是不同的。UOS Cloud現在是Ceph方案，你們是怎么做這個計算的?
實際上這個計算是需要依賴于存儲系統本身的，Ceph的優勢是提供了一個叫CRush算法的實現，可以輕松根據需要來規劃數據的副本數和高可用性。參考Ceph提供的模型定義(https://github.com/ceph/ceph-tools/blob/master/models /reliability/README.html)來規劃自己的。這是我的同事朱榮澤做的故障計算。這個計算只針對副本策略，并不適合使用EC(擦除碼)的情況。
硬盤發生故障的概率是符合泊松分布的。
| fit = failures in time = 1/MTTF ~= 1/MTBF = AFR/(24*365) 事件概率 Pn(λ,t) = (λt)n e-λt / n! |
我們對丟失數據是不能容忍的，所以只計算丟失數據的概率，不計算丟失每個object的概率。
| N代表OSD的個數 R代表副本數 S代表scatter width，關系著recovery時間 我們忽略Non-Recoverable Errors的概率 |
計算1年內任意R個OSD發生相關故障概率的方法是
| 1年內OSD故障的概率。 在recovery時(R-1)個OSD發生故障的概率。 以上概率相乘。假設結果是Pr |
因為任意R個OSD不一定屬于Ceph的Copy Sets，則Ceph的丟失Copy Sets的概率是：
| M = Copy Sets Number 在N個OSD中，任意R個OSD的組合數是 C(R,N) 丟失Copy Sets的概率是 Pr * M / C(R, N)。 |
最終公式是：
P = func(N, R, S, AFR)
