OpenStack東京峰會於2015年10月27日~30日舉行，非常幸運和榮幸我能夠代表企事錄（QSLab）及合作夥伴希捷在峰會上做分享。關於會議的報導，已經很多了，也不用企事錄再贅述，我這次想站在一個分享者的角度來聊一聊。
我分享的主題是和對象存儲相關的，包括兩個方面的內容：1. 將OpenStack Swift和Ceph的對象存儲功能進行比較——這部分可以說是老生常談了，所以我並沒有重複以往已經有人做過的事情，而是對以前比較具有代表性的工作做了一個總結，並做補充；2. 討論如何結合實際用戶的實際應用場景來進行對象存儲系統的測試與評價，並以一個基於希捷Kinetic硬碟的Swift POC環境為例，給出了測試結果。
由於N久沒有站在臺上講英語了，所以當時還是有點擔心。直到講完以後，兩個歪果仁在提問的時候先說了一句「This is the best presentation I』ve seen these two days」，我才知道這次沒有給中國人丟臉，遂放下心來。
我分享的第一部分是關於Swift和Ceph用於對象存儲服務的比較
Swift和Ceph的對比，在OpenStack社區裡不是什麼新鮮話題了，而且一直有比較高的關注度，如果我們Google一下相關內容，能得到很多搜索結果。Swift是OpenStack最初的兩個項目之一，其的核心功能的代碼經過了五年的發展，現在非常穩定，實際使用中，Swift的運維也很簡單；而由於OpenStack的Nova、Cinder和Glance三個核心項目都支持用Ceph做後端，所以，Ceph對OpenStack用戶非常有吸引力。
Swift和Ceph沒有絕對的誰好誰壞，更多的是要看應用場景，溫哥華峰會上來自Mirantis的Christian Huebner也曾經說過，對Ceph和Swift進行選擇的依據應當是看要解決什麼問題，而不要泛泛地爭辯技術的優劣，他用了「No Religious War」來形容。在我的分享中，我用下面這頁片子總結了一些在構建對象存儲系統時，常需要考慮的因素。
如果您希望擁有對象自動過期、版本控制等等一些我們稱之為「Advanced Object Storage Features」的功能，那麼您應當選用Swift，因為這些功能是Ceph沒有的。更重要的是Swift是如何實現這些功能的——Swift通過一種叫做Middleware的東西，這裡的Middleware不是我們平常說的「中間件」，而是WSGI框架中的一種概念。這是一種類似插件的東西，使用起來非常方便，通過在一個配置文件中，指定一個pipeline中使用哪些middleware，以及這些middleware使用的先後順序，就可以給一個Web服務賦予各種不同的功能。另一方面，因為WSGI Middleware接口也很簡潔，所以用戶如果想編程實現自己的Middleware，也很方便，所以用戶可以很方便地通過Middleware來對Swift的功能進行定製，實現刪重、壓縮、殺毒、不良信息掃描等功能，這是Ceph所不具備的。
Ceph的主要優勢在於統一存儲，這樣，我們只需要搭建一個集群就可以提供塊存儲、對象存儲和文件系統服務。由此衍生的一個優勢是，如果我們手頭上的資源有限，比如，我們只有不到十臺伺服器，我們要為虛擬化提供支持，例如做Nova和Cinder的後端，我們又想提供對象存儲服務。那麼Ceph是一個不錯的選擇，因為要實現一個生產中可用的穩定的分布式存儲系統，通常需要四個或者更多的節點，當伺服器數量有限的時候，我們可能不希望把資源分散到兩個集群中，這時候用Ceph，就可以通過一個集群提供多種類型的存儲服務。
如果我們希望跨多個數據中心構建存儲系統，那麼通過Swift可以比較容易實現，但是Ceph目前尚不能實現真正的多域部署（Multi-Region Deployment）。跨數據中心部署可以在異地共享數據，並且通過Swift提供的Write affinity和 Read affinity特性，得到較低的訪問延遲；同時也起到了災備的作用。但是要注意Swift所採用的是最終一致性模型，這一方面讓Swift能夠很容易實現跨域部署，另一方面也造成數據更新後，某些客戶端可能不能立即讀到最新的版本。所以，如果要求「立即一致性」或者「強一致性」的話，最好是選用Ceph。
另外需要澄清的一個事情是，很多人認為Swift不適用於來存大對象，而Ceph不適用於來存小對象，這實際上是一個誤區，Swift和Ceph對大對象和小對象的存儲都提供一些Features加以支持，更重要的是要正確地使用這些Features和對集群進行調優（Tuning）。
Swift通過一個被稱為「Dynamic Large Objects」的Feature能夠好地支持大文件的存儲，這在OpenStack官方文檔中進行了很詳細的闡述（ http://docs.openstack.org/developer/swift/overview_large_objects.html ），官方的Swift客戶端和Glance中正式通過改Feature實現大對象上傳和下載的。我們實際測試結果，採用正確的方法向Swift集群上傳大文件時，Porxy節點上連接到Storage節點的萬兆網絡接口能夠基本上達到極限。而對於Ceph存儲小文件來說，同樣，Zurich University of Applied Sciences的雲計算實驗室給出的一份測試報告表明，在他們的實驗環境中，用Ceph存儲小對象，讀寫性能的測試結果很好。但是需要注意的是，Zurich University of Applied Sciences的測試場景中的Ceph集群比較小，而且負載中沒有頻繁刪除小對象的情況。
我分享的第二部分是如何站在用戶的角度進行對象存儲的測試與評估
既然說到比較，就離不開測試與評估，正確的測評方法比最終的結果往往更為重要。目前測對象存儲常用的一些benchmark tools，如COSbench和SSbench都能告訴你一個對象存儲系統的極限在哪裡，這對於系統的設計者和實施方來說非常有用。但是站在用戶的角度來說，基於HTTP的對象存儲是一種新型的存儲形態，對象存儲服務每秒鐘能夠響應的請求數量和吞吐率與傳統存儲的IOPS及傳輸速率的本質是不一樣的，當用戶在評價一個對象存儲系統或者服務對業務的幫助時，以往的經驗不再起作用了，所以，我們（希捷和企事錄的工程師）根據對象存儲在真實應用中的負載進行建模，並對基於Kinetic的Swift對象存儲方案進行了實際評測。
對象存儲在過去十年內吸引了巨大的投資，其背後的主要的推動力量是網際網路應用和移動計算的發展，無獨有偶，在此次峰會上，關於Swift的另一個演講也表達了類似的觀點。
網際網路應用中使用對象存儲的典型場景有：電商的商品圖像的存儲、社交軟體中用戶上傳的圖像和短視頻、在線辦公系統中的文檔存儲等，對於這些場景來說，服務的可用性和訪問延遲比每秒鐘最多響應多少次請求更加重要。對於對象存儲來說，訪問延遲即為從發出讀/寫請求到一個對象完全讀取/寫入所需要的時間。
而對於網際網路應用來說，真實世界中訪問請求的到達不是均勻地，而是服從泊松分布，單位之間內到達的請求數是一個隨機變量，如下圖所示
這個隨機變量的數學表達式為：
其中，λ是單位時間內達到請求數的平均值，即X的數學期望。這個值在真實的應用場景中，實際上是由用戶所需要面對的負載決定的，例如，我們以「秒」為單位時間，假設某網際網路應用A，用戶數量為10萬，日活躍用戶比例為30%，如果這些用戶當天平均是用該應用的次數為30次，每次會讀取50個對象，其中80%的負載發生在一天的兩個小時之內，則訪問高峰期每秒鐘讀請求次數為：
所以，從該用戶的角度來說，測評的重點應當是，平均負載為每秒500次讀請求的情況下，最大的響應延遲和平均響應延遲。
我們的測試環境使用了基於Kinetic的Swift方案。Kinetic是一個由希捷提出的基於乙太網硬碟和開源軟體的開放存儲方案，目前已經發展為Linux基金會的一個項目——Kinetic Open Storage Project（KOSP），一些存儲領域的大廠紛紛加入。基於Kinetic構建對象存儲系統，可以有效減少存儲伺服器的使用，提高存儲密度並降低成本；同時由於每個硬碟都是一個IP設備直接接入乙太網，所以能夠有效降低分布式存儲系統運維的難度。
如下圖所示，希捷提供的基於Kinetic的Swift對象存儲方案與傳統的完全基於x86伺服器的Swift方案不同的地方在於，傳統方案中要使用x86伺服器來運行Object Server，但是在基於Kinetic的Swift中，修改後的Object Server服務進程可以和Proxy Server部署在相同的節點上，因為Object Server不在本地存儲對象數據，而是將對象數據通過網絡保存在Kinetic硬碟上。
我們搭建的測試環境如下圖所示，由於這只是一個初步的測試環境，所以我們只使用了一臺Kinetic設備，內含12塊4TB Kinetic硬碟。另外使用了一臺x86伺服器運行Swift的Proxy Server、Account Server、Container Server和修改的Object Server，稱為PACO Node。我們使用的Load Generator可以根據泊松分布模型模擬實際的網際網路訪問負載，因為這是一個初步的實驗環境，我們將Load Generator運行在PACO Node上。
測試結果表明，當對象大小為1MB時，每秒平均500次讀請求的負載下，該對象存儲方案最大的請求-響應延遲為579.6 ms，平均延遲為66.3 ms。一般來說，這個延遲對於網際網路用戶來說是可接受的，所以可以認為該方案在性能上能夠滿足網際網路應用A的需求。
需要說明的是，這只是一個初步的測評，實際上一個對象存儲系統的負載往往是混合的，操作不可能只有讀或者寫，對象的大小也不可能是相同的，這些都將會在我們後續的工作中完善。
另外關於東京峰會，我有幾點感受：
雖然每個Track都有Chair，但是他們並不一定在各個分會場擔任主持人，完全看自願。這個很有意思，我參加過許多會議，一個人只要做了Chair，基本上這一天在會上別的活動就甭想參與了，因為他要在這個會場上做主持人幫各個演講者穿針引線。主持這個事情對於大會報告Keyonte來說，沒有什麼問題，因為Keynote期間一般也不會有其他活動了，但是對於分會來說，由於各個Track往往是並行進行的，如果Track Chairs還要在各自的Track上盯著走不開，就限制了他們在會議中的參與度。而事實上，Chair們一般是各個領域方向中的牛人，把他們解放出來，讓他們多參與會議中的活動，對於會議本身質量的提高也是很有幫助的。這有個潛在的要求是聽眾和演講者都能夠非常守時，演講者要控制好時間不能拖延，聽眾要在該開始下一個session的時候準時或者提前一點到達會場。
會議錄製剪輯非常專業。整個錄製過程對演講者來說是透明的，攝像機放在那裡無人值守，上線以後的視頻中基本沒看到過有什麼問題；Speaker都用自己的筆記本演示，也無需向主辦方提供任何PPT或者Keynote等膠片的文件，通過類似錄屏的方式進行，所有演示動畫、插入的視頻和live demo的內容悉數保留；任一天的所有session，都會在第二天完成後期製作並可以在YouTube上看到，錄音和圖像的質量都非常高。國內大大小小的會議，嘗試錄像的不少，但是目前我還沒看到能做到這個水平的。比如有的會議錄像喜歡給演講者特寫，或者在膠片和演講者之間切換。給特寫的用途並不大，觀眾要看清楚的是演講者的手勢以及他在幹什麼，比如是在做live demo還是在講膠片，至於在膠片和演講者之間的切換，這個是要儘量避免的，因為幻燈片的動畫和演講者的手勢裡可能都包含了希望傳遞給觀眾的信息；還有的會議錄像以後為了製作後期，要求提供PPT，我一直比較反感這個要求，因為我不用盜版，又不覺得微軟的產品值那個錢，所以我不用PowerPoint，而如果我把Keynote做的膠片轉成PPT格式，大部分動畫都會丟失。
聽眾的質量非常高，在提問環節還討論了關於如何基於Kinetic硬碟實現Ceph的一些技術細節問題，直到晚宴上還有一個老外找到我，問了一些非常專業的問題。OpenStack Summit是一個非常適合做深入技術交流的場合，企事錄今後會多參與類似的活動，也非常歡迎廠商來一起合作。
專注於企業級產品、技術的傳播推廣，加速促進新產品、新解決方案的落地實施。企事錄公眾號為您分析介紹企業IT、網際網路基礎設施及架構方面值得關注的技術趨勢，歡迎大家關注！
長按，選擇「識別圖中二維碼」