幾種磁碟讀寫效能相關的伺服器磁碟使用原則與壓測方法

幾種磁碟讀寫效能相關的伺服器磁碟使用原則與壓測方法
1、關於磁碟RAID在以往工作中因為各種緣由，也使用過多種的磁碟高可用配置策略。談磁碟高可用，大多數時候就是在談資料冗餘保護配置RAID。但當和實際業務結合起來時，保障業務應用的讀寫效能需求才是第一位重要的，有時不得不要略犧牲一些磁碟高可用設計。眾所周知的，常用RAID層級有0，1，5，6 。RAID0，只做條帶化，直接把資料切分成多段，然後分別寫入到多個磁碟中去。因此RAID0具有所有RAID層級中最高的儲存效能，寫懲罰為1，即只需一次寫操作. 同時也不提供任何資料保護能力，一塊盤損壞了等於全部磁碟中的資料丟失。RAID1，磁碟鏡像，寫懲罰為2，也就是說每一個寫操作，都要同時向兩塊磁碟寫入成功後才能結束。雖然如此，但RAID1仍然是兼顧效能與高可用的一個解決方案。RAID5，交叉地存取資料及同位資訊於所有磁碟上，至少需要3塊或以上數量的磁碟且會損失一塊磁碟大小的儲存容量，較適合小資料區塊的隨機讀寫。RAID5的寫懲罰是4，即每一次寫操作,將產生四個實際的讀/寫操作, 其中兩次讀舊的資料及奇偶資訊, 兩次寫新的資料及奇偶資訊。RAID6，與RAID 5相比,增加了第二個獨立的同位資訊塊，需要讀取兩次校正位和寫入兩次校正位。兩個獨立的奇偶系統使用不同的演算法, 資料的可靠性非常高。 即使兩塊磁碟同時失效,也不會影響資料的使用。RAID6的寫懲罰是6 。實際使用中，如果資料很重要，往往還要再額外設定一塊“熱備盤”。當然這個熱備盤對RAID0是不適用的。大家看到RAID6的寫懲罰實在是太高了，可能會認為毫無用處，但在特定的使用情境中確實也有RAID6的身影出沒。我接觸的一款NetApp nas裝置，廠商著力推薦的就是使用RAID6，必竟是可以通過各種手段提高存放裝置的寫能力，但在資料保護層級上，其它RAID層級最多隻能提供同時損壞一塊磁碟的能力。而對於RAID0，毫無資料保護可言，卻也有它的用武之地，比如用作CDN加速業務的主機，主機上的資料實際上是可以“丟失”的，因為只是一份緩衝加速資料。同一時間，除了來源站點，還有眾多的CDN加速節點上也有同樣的資料。2、關於物理主機的磁碟分割策略與RAID配置策略無外乎是兩種策略，一是使用獨立的磁碟作為主機系統硬碟專用；二是不區分系統硬碟、資料盤，系統磁碟分割和資料分區混用。這兩種策略，其實是無關誰優誰劣的，因為對於各種實際業務使用情境，只有最適用的，沒有最佳的解決辦法。（1）對於企業級伺服器裝置來說，不可能只配置一塊磁碟。配置多塊磁碟時，除極個別使用情境之外，如運行hadoop，都需要配置磁碟RAID保護。（2）凡是對磁碟讀寫效能敏感的業務應用，建議採用RAID1或RAID10；（3）在有條件的情況下，建議系統硬碟和資料盤分離，比如另有資料存放區陣列、NAS或是分布式儲存系統，為系統硬碟直接使用兩塊中高效能的磁碟配置為RAID1使用；（4）即便是運行hadoop這種分布式系統的datanode節點，也不要讓系統硬碟直接使用一塊磁碟去跑，雖然掛掉一台datanode節點主機不會影響hadoop平台繼續正常運轉，但下線、修複、重新設定上線並加入叢集平台太浪費時間了；（5）在磁碟資源條件比較緊張時，可以直接採取不區分系統硬碟、資料盤的策略，所有磁碟配置為一個RAID10，有時一台主機上的應用程式和資料需要全部基於本地磁碟進行讀寫且讀寫很頻繁，這種情況下再單獨為系統硬碟划出兩塊磁碟跑系統顯得過於奢侈了，必竟保證為業務應用提供足夠的磁碟IO能力才是第一位重要的；（6）磁碟容量越大，這裡指的主要是傳統的機械磁碟，意味著磁碟的IOPS能力越低，比如一塊300GB 10K轉速的磁碟的IOPS能力大約要比一塊600GB 10K轉速的磁碟高出1/3 ，所以在磁碟效能和容量的選擇上需要預先做好技術分析，避免容量夠了，效能又不達標了，尤其是對於要在本地運行mysql資料庫的情況來說，會對磁碟IO效能更加敏感；（7）為swap分區設定合理的空間，尤其是在實體記憶體緊張的情況下，至少可以避免因記憶體溢出引發的當機；（8）在同一個RAID磁碟分組中的物理磁碟數量越多，意味著RAID後得到的邏輯磁碟所具有的IOPS能力越大，這是因為資料是被切分成多塊後分別分布儲存到一組磁碟中的；（9）是否設定熱備盤要看團隊的營運能力而定，如果已經做到每天自動檢查物理磁碟是否發生故障，且在一塊磁碟出現壞塊後能夠在較短時間內更換受損磁碟，那麼就沒有必要使用熱備盤。對於一個只能掛載8塊或12塊磁碟的主機或小型存放裝置陣列而言，如果設定一塊盤作為熱備盤，對於資料庫業務應用來說就只能基於6塊或10塊磁碟配置RAID10，這不但降低了儲存容量，也同時降低了總的IOPS能力。3、關於IOPS測試資料下面是一個很籠統的估算公式：物理磁碟總的IOPS = 物理磁碟的IOPS × 磁碟數目可用的IOPS = （物理磁碟總的IOPS × 寫百分比 ÷ RAID寫懲罰） + （物理磁碟總的IOPS × 讀百分比）對於公司線上生產環境中主機或存放裝置的磁碟高可用配置策略的調整，需要特別謹慎，需要有直接的、準確的iops測試資料作為支援，才能調整或改變一直沿用的儲存管理原則。我們一般使用fio來測試磁碟的IOPS能力。如果是運行mysql資料庫應用，建議另外使用tpcc測試資料庫的處理能力。在一個主機或系統上線前，應該測試和收集它的磁碟IOPS讀寫能力資料；在準備使用一個新的磁碟組態管理策略時，也需要先測試其IOPS資料作為依據。下面是幾組測試方法和參數fio測試磁碟/dev/sdb1隨機讀：fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randread -ioengine=psync -bs=16k -size=200G -numjobs=10 -runtime=300 -group_reporting -name=mytestfio測試磁碟/dev/sdb1 隨機寫：fio -filename=/dev/sdb1 -direct=1 -iodepth 1 -thread -rw=randwrite -ioengine=psync -bs=16k -size=200G -numjobs=30 -runtime=300 -group_reporting -name=mytest測試參數說明：
filename=/dev/sdb1 測試檔案名稱，通常選擇需要測試的盤的data目錄。
direct=1 測試過程繞過機器內建的buffer。使測試結果更真實。rw=randwrite 測試隨機寫的I/Orw=randread 測試隨機讀的I/Obs=16k 單次io的塊檔案大小為16kbsrange=512-2048 同上，提定資料區塊的大小範圍size=200g 本次的測試檔案大小為200g，以每次16k的io進行測試。numjobs=10 本次的測試線程為10.runtime=300 測試時間為300秒。ioengine=psync io引擎使用pync方式group_reporting 關於顯示結果的，匯總每個進程的資訊。測試報告解析說明：

io= 執行了多少M的IO

bw= 平均IO頻寬

iops=IOPS

runt= 線程已耗用時間

slat提交延遲

clat完成延遲

lat回應時間

bw頻寬

cpu利用率

IOdepths=io隊列

IOsubmit=單個IO提交要提交的IO數

IOcomplete= Liketheabovesubmitnumber,butforcompletionsinstead.

IOissued= Thenumberofread/writerequestsissued,andhowmany

ofthemwereshort.

IOlatencies=IO完延遲的分布4、關於TPCC測試tpcc測試方法和工具請自行在網上檢索即可。該工具的使用也比較簡單。對於運行mysql資料庫應用的系統，建議在上線前先對該資料庫執行幾次TPCC測試，收集和存放好測試結果資料。用於日後的維護、最佳化工作，作為參考。尤其是在對運行資料庫應用的主機、儲存或資料庫軟體版本做出調整後，建議都重新做一下TPCC壓測。以證實該次調優是否達到了設計意圖。對於系統管理員或資料庫DBA來說，瞭解自己的系統效能上限是多少是很重要的。以下給出一組測試資料，供大家參考。一套mysql 資料庫的DRBD雙機高可用系統。雙物理主機的配置相同，均為：cpu E5-2620 v4 @ 2.10GHz ， 記憶體64GB，磁碟8*600 RAID10 。雙機上各劃1.2TB磁碟分割配置為DRBD網際網路共用磁碟。雙機間使用千兆網路連接。預裝載500個倉庫的壓測資料。壓測30分鐘：./tpcc_start -h192.168.110.48 -uroot -p123456 -d tpcc -w 500 -c 256 -r 300 -l 1800 -f ./tpcc_mysql_256_20170226.log壓測通過，結果如下：<Raw Results> [0] sc:293979 lt:2672 rt:0 fl:0 [1] sc:296648 lt:47 rt:0 fl:0 [2] sc:29656 lt:7 rt:0 fl:0 [3] sc:29633 lt:0 rt:0 fl:0 [4] sc:29683 lt:0 rt:0 fl:0in 1800 sec.<Raw Results2(sum ver.)> [0] sc:293982 lt:2672 rt:0 fl:0 [1] sc:296660 lt:47 rt:0 fl:0 [2] sc:29656 lt:7 rt:0 fl:0 [3] sc:29634 lt:0 rt:0 fl:0 [4] sc:29683 lt:0 rt:0 fl:0<Constraint Check> (all must be [OK])[transaction percentage] Payment: 43.48% (>=43.0%) [OK] Order-Status: 4.35% (>= 4.0%) [OK] Delivery: 4.34% (>= 4.0%) [OK] Stock-Level: 4.35% (>= 4.0%) [OK][response time (at least 90% passed)] New-Order: 99.10% [OK] Payment: 99.98% [OK] Order-Status: 99.98% [OK] Delivery: 100.00% [OK] Stock-Level: 100.00% [OK]<TpmC> 9888.366 TpmC

壓測過程輸出解讀見下：

--以逗號分隔，共6列--第一列，第N次10秒--第二列，總成功執行壓測的次數(總延遲執行壓測的次數):90%事務的回應時間|本輪測試最大回應時間--第三列，新訂單業務成功執行次數(延遲執行次數):90%事務的回應時間|本輪測試最大回應時間--第四列，支付業務的結果，後面幾個的意義同上--第五列，發貨業務的結果，後面幾個的意義同上--第六列，庫存業務的結果，後面幾個的意義同上

-- 第一次粗略結果統計

[0]sc:100589lt:0rt:0fl:0--New-Order，新訂單業務成功(success,簡寫sc)次數，延遲(late,簡寫lt)次數，重試(retry,簡寫rt)次數，失敗(failure,簡寫fl)次數[1]sc:100552lt:0rt:0fl:0--Payment，支付業務統計，其他同上[2]sc:10059lt:0rt:0fl:0--Order-Status，訂單狀態業務統計，其他同上[3]sc:10057lt:0rt:0fl:0--Delivery，發貨業務統計，其他同上[4]sc:10058lt:0rt:0fl:0--Stock-Level，庫存業務統計，其他同上

測試結果統計分析

(allmustbe[OK])--下面所有商務邏輯結果都必須為OK才行[transactionpercentage]Payment:43.47%(>=43.0%)[OK]--支付成功次數(上述統計結果中sc+lt)必須大於43.0%，否則結果為NG，而不是OKOrder-Status:4.35%(>=4.0%)[OK]--訂單狀態，其他同上Delivery:4.35%(>=4.0%)[OK]--發貨，其他同上Stock-Level:4.35%(>=4.0%)[OK]--庫存，其他同上[responsetime(atleast90%passed)]--響應耗時指標必須超過90%通過才行New-Order:100.00%[OK]--下面幾個響應耗時指標全部100%通過Payment:100.00%[OK]Order-Status:100.00%[OK]Delivery:100.00%[OK]Stock-Level:100.00%[OK]

以及最終的tpcc測試結果

9888.366TpmC--TpmC結果值，即每分鐘的事務數測試後，再次壓測前需要做的清理工作：#sync --將髒資料重新整理到磁碟#echo3>/proc/sys/vm/drop_caches --清除OSCache#swapoff-a&&swapon-a或者重啟整個OS。