別急！新鮮的雲硬盤讓它再涼一會

題外話

    《邪不壓正》這部電影剛上映我就去看了，做爲姜文的民國三部曲最後一部，剛上映就把《我不是藥神》擠下神壇，但我不關心票房，單純是衝着他的上部電影《讓zidan飛》的精彩劇情和臺詞，抱着美好的期待去的。

    走出電影院，我就忘了講的是啥，只記得彭于晏在老北京的屋檐上處處亂竄，整部劇情就一個少年復仇記的簡單故事，臺詞晦澀難懂、劇情跳躍、人物形象也不完整。遠遠沒有當年觀看《讓zidan飛》的驚豔體驗。

    還記得《讓zidan飛》裏姜文飾演的張麻子一出場就密集的打出7槍：

  六子:沒打中？

  張麻子：讓zidan再飛一下子

    這句話從張麻子口中說出，透出無比的自信，想表達的意思就是：別急着要結果，好事正在醞釀中。

1 背景

   言歸正傳，現現在咱們使用雲計算產品，不管虛擬機是linux，仍是windows系列的操做系統，雲硬盤掛載到雲主機，再通過文件系統格式化，是最經常使用的存儲使用場景，至關於咱們家用計算機的D盤、E盤，用來存放數據、安裝軟件等。

   對硬盤的操做，有一點能夠達成共識的是，在Linux系統下，對磁盤分區的處理，一般都是採用fdisk、mkfs的處理方式，固然大於2TB的磁盤另外，不在本次討論範圍內。

   整篇文章分如下幾小章節：

    1 、背景

    2 、現象回顧

    三、 雲硬盤掛載後，ceph後端存儲實際如何變化

    4 、centos不一樣內核下的表現

    五、 找到根本緣由

    六、 總結

2 現象回顧

  

    有幾回在格式化雲硬盤並mount後，很快執行fio測試發現和歷史數據對比性能有所降低，回過頭對ceph節點osd io進行監控時，觀察到1個現象，即執行格式化、建立文件系統後短期內磁盤會產生數分鐘寫io。

    mount雲硬盤以後，寫操做持續了5分鐘以上，時間有點久，在這個時間內，若是對雲硬盤執行大吞吐的讀寫操做，或多或少影響的實際的性能，甚至是否會影響數據持久化，不得而知，所以不得不花了些時間排查具體是什麼緣由觸發的。

3  雲硬盤掛載後，ceph後端存儲實際如何變化

      分了幾個步驟對雲硬盤從建立開始，到寫入數據的全部過程作個梳理，看看是哪些環節產生什麼樣的反映。

   （1）新建的volume無任何數據

     Cinder建立 100GB的數據盤，卷類型爲無qos，此時在rbd 的custmized-hdd池中，出現了剛剛建立的volume，經過rbd diff計算這個volume實際佔用容量爲0，無數據

   （2）雲硬盤掛載到雲主機，但不分區

     將100GB的volume經過nova volume-attach掛載到雲主機，但不安裝ext4文件系統

     此時數據盤無讀寫io，rbd 的custmized-hdd池中的volume仍然沒有數據，4個節點的osd無寫io現象

  （3）格式化雲硬盤並mount

     格式化/dev/vdb爲ext4，不掛載，此時rbd 的custmized-hdd池中的volume增長大約140MB的數據

     再將數據盤掛載到/mnt上，出現寫io，osd和雲硬盤盤都監控到有寫的吞吐，持續大約5分鐘中止，平均吞吐在5MB/S-7MB/S，產生的數據總和爲=300秒*5MB=1500MB左右

    查下存儲池該volume是否真增長這麼多數據？檢查rbd 的custmized-hdd池中的volume，仍然使用rbd diff計算這個volume實際佔用容量，發現增長了1.5GB的數據，總容量到1743B，以下圖

    再和object總數作個核對，Rbd下該卷存在498個object，以4MB一個計算總和不到1.9 GB，考慮到volume剛建立時，前期的object不滿4MB，和rbd diff計算得出基本一致，以下圖：

看完雲硬盤掛載到虛擬機後，ceph底層存儲的一系列表現，咱們不妨停下來思考一下，整理思路：

    （1）Mount雲硬盤以後，寫操做持續了5分鐘，是實實在在的在存儲池下產生數據的，這一點獲得證明

    （2）由於我使用的centos7.2系統，mount後會產生寫操做，是否是linux的特性，須要在centos6.5上再證明一下

4 centos不一樣內核下的表現

     增長在cenots6.5下執行一樣的掛載雲硬盤、格式化和mount操做的測試場景，看是否存在一樣的數分鐘持續寫情形。

    （1）排查mkfs的差別

    cenots6.5的vm格式化100GB雲硬盤並mount，前期準確過程略，從mkfs開始，cenots6.5在mkfs過程當中，當執行到Writing superblocks and filesystem accounting information，明顯要比cenots7.2要慢不少，cenots7.2執行這個操做是1秒左右，而cenots6.5須要40秒以上。

    （2）驗證mount後的雲硬盤讀寫

    使用cenots6.5建立vm，掛載100GB數據盤並mount後，也存在寫io，但時間很短，大約十秒的時間

瞭解了不一樣內核的os在執行格式化文件系統的差別，咱們再次停下來思考一下，整理思路：

   （1）從上面的「排查過程二」下的第（2）步驟，初步得出一個是mkfs時一塊兒寫入io，一個是mount後再寫入 ，應該是在Writing superblocks and filesystem accounting information過程當中存在的差別

   （2）Centos7.二、Centos6.5在mount雲硬盤後存在寫io的差別，有點奇怪了，須要排查下是哪一個進程在寫

5 根本緣由浮出水面

          經過iotop查詢vm中進程的讀寫io實時數據，排查下Centos7.二、Centos6.5的差別到底在哪。

     前期準備再也不反覆描述，咱們直接觀察兩個階段的寫狀況，一個是mkfs過程，一個是mount後

   （1）找到Centos7.2是哪一個進程在寫

    由於Centos7.2的Mkfs秒級操做，iotop顯示mkfs時寫實時吞吐爲54MB/S，再從雲硬盤mount後開始，在vm中執行iotop後發現Centos7.2 上只有ext4lazyinit進程存在io寫，實時吞吐爲7MB/S，以下圖

    （2）找到Centos6.5是哪一個進程在寫

      Centos6.5是在mkfs時有點慢，在vm中執行iotop後發現Centos6.5 上是mkfs進程存在io寫，實時吞吐爲58MB/S，以下圖

      很明顯，Centos7.二、Centos6.5在mkfs、mount雲硬盤過程存在寫io的差別

       ext4lazyinit，直譯爲ext4惰性初始化，經過調研在cenots7之後，內核3.10以後，操做系統對格式化分區是經過ext4lazyinit實現，好處就是能迅速的建立文件系統，會把文件系統初始化的工做推遲到掛載後進行。

    這樣一來對於用戶感官來講，格式化雲硬盤速度很是快，體驗很棒。但這樣的狀況，就須要再mount以後，最好是等待數分鐘以後再操做硬盤分區。

總結

       前文說到在cenots7之後，內核3.10以後，在格式化分區上流程的變動，帶來用戶體驗的優化。

    須要注意的是，文件系統惰性初始化時間是根據雲環境的網絡、磁盤qos綜合衡量，並不固定。而且對於操做系統的使用者來講屬於黑箱，你惟一能作的，就是讓磁盤冷靜會，特別是性能評估，就須要在mount以後等待數分鐘後再執行，防止數據的不許確。

    值得一提的是，在cenots7更新以後，帶來一些新的特性，對應其餘性能上也會帶來提高，以下表中：

      Systemd的做用其實不新鮮了，早在2015年時我在中科院軟件研究所從事國產操做系統研發時就實際應用過。

    以往在linux各類發行版本中，採用這種方式的並很少，linux各類服務器版本給用戶帶來的性能提高並不明顯，但若是加載到centos桌面版，會有明顯的感官，從啓動系統到完成桌面加載的時間變快了，誰不但願打開系統的時間越短越好呢，但也有弊端，增長了xorg崩潰的風險。    更高性能的KVM內核虛擬化支持，減小了雲平臺上層到底層的io鏈路，理論上應該能對虛擬化資源的響應帶來性能優化，目前尚未對此作過比較，後續再跟蹤。