Linux下RAID卡與電池充放電優化簡述

介紹

我們的生產伺服器經常會做RAID儲存，但是單單做了RAID就能保證效能高效和資料安全嗎？答案是否定的，我們一般建議使用帶電池保護的RAID卡，這樣既能保證效能有能保證資料安全，但是也需要經常對電池進行維護；由於成本原因一般的RAID卡會使用鋰電池，因為鋰電池有較強的惰性，它在非充電狀態下會緩慢地自放電（電池特性），一段時間後電量就會和剛充滿電時不同，為了能夠及時校準電量避免電池因為自放電而導致電量不明確，於是陣列卡控制器會對電池進行週期性地充放電操作（Relearn），以此保證電量的準確性，同時還可以判斷電池是否故障或者老化。

檢視RAID卡電池情況

MegaCli64 -AdpBbuCmd -GetBbuStatus -aAll

如果返回如下錯誤那麼可能是RAID卡BUU電池有問題或者沒有電池保護功能：

Adapter 0: Get BBU Status Failed.
FW error description:
The required hardware component is not present.
Exit Code: 0x22

檢視當前RAID卡快取策略

MegaCli64 -LDinfo -Lall -aAllDefault Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU

Current Cache Policy: WriteThrough, ReadAheadNone, Direct, No Write Cache if Bad BBU

第一部分：

WriteBack:寫快取策略

WriteThrough:直接寫入磁碟，不適用RAID卡快取。

第二部分：

ReadAheadNone:不開啟預讀

ReadAhead:開啟預讀，在讀操作的時候，預先把後面順序的資料載入raid卡快取，在順序讀的環境中能提供很好的效能，但是在隨機讀的環境中反而降低讀的效能（適合檔案系統，不適合資料庫系統）

ReadAdaptive:自適應預讀，在快取和I/O空閒時選擇預讀，預設策略。

第三部分：

Direct:讀操作不快取到RAID卡快取。

Cached:讀操作快取到RAID卡快取。

第四部分：如果BBU(電池)出現問題是否啟用Write Cache

No Write Cache if Bad BBU:如果BBU出現問題不使用Write Cache，從WriteBack自動切換到WriteThrough，預設設定。

Write Cache OK if Bad BBU: 如果BBU出現問題仍啟用Write Cache,這種設定是非常不安全的，除非是有UPS或者雙電源的情況下。

RAID卡策略更改

修改WriteBack：

MegaCli64 -LDSetProp -WB -Lall -aAll修改WriteThrough:

MegaCli64 -LDSetProp -WT -Lall -aAll修改No Write Cache if Bad BBU:

MegaCli64 -LDSetProp -NoCachedBadBBU -Lall -aAll修改Write Cache OK if Bad BBU:

MegaCli64 -LDSetProp -CachedBadBBU -Lall -aAll4.其它相關命令

檢視機器型號    # dmidecode | grep"Product"

檢視廠商    # dmidecode| grep "Manufacturer"

檢視序列號    # dmidecode | grep "Serial Number"

檢視CPU資訊    # dmidecode | grep "CPU"

檢視CPU個數    # dmidecode | grep "Socket Designation: CPU" |wc –l

檢視出廠日期    # dmidecode | grep"Date"

檢視充電狀態    # MegaCli64 -AdpBbuCmd-GetBbuStatus -aALL |grep "Charger Status"

顯示BBU狀態資訊    # MegaCli64 -AdpBbuCmd-GetBbuStatus –aALL

顯示BBU容量資訊    # MegaCli64 -AdpBbuCmd-GetBbuCapacityInfo –aALL

顯示BBU設計引數    # MegaCli64 -AdpBbuCmd-GetBbuDesignInfo –aALL

顯示當前BBU屬性    # MegaCli64 -AdpBbuCmd-GetBbuProperties –aALL

檢視充電進度百分比    # MegaCli64 -AdpBbuCmd-GetBbuStatus -aALL |grep "Relative State of Charge"

查詢Raid陣列數    # MegaCli64 -cfgdsply -aALL|grep "Number of DISK GROUPS:"

顯示Raid卡型號，Raid設定，Disk相關資訊      # MegaCli64-cfgdsply –aALL

顯示所有物理資訊    # MegaCli64 -PDList-aALL

顯示所有邏輯磁碟組資訊    # MegaCli64 -LDInfo -LALL–aAll

檢視物理磁碟重建進度(重要)    # MegaCli64 -PDRbld-ShowProg -PhysDrv [1:5] -a0

檢視介面卡個數    #MegaCli64 –adpCount

檢視介面卡時間    #MegaCli64 -AdpGetTime–aALL

顯示所有介面卡資訊    #MegaCli64 -AdpAllInfo–aAll

檢視Cache 策略設定    # MegaCli64 -cfgdsply -aALL|grep Polic

RAID卡電池充放電

磁碟陣列是伺服器上歷史悠久的一項技術，它能夠通過不同的陣列模式合理利用空間和效能配比出價效比極高的磁碟陣列，被絕大部分的伺服器OEM廠商所廣泛採用。其中以LSI公司的MegaRAID SAS產品為主，廣泛用於各品牌（除惠普外）的x86伺服器。

為何有快取？

陣列卡核心技術包含三部分內容：1、資料條帶化；2、資料冗餘；3、快取記憶體。其中快取記憶體就是所謂的陣列卡記憶體（以下簡稱快取）：陣列卡控制器通過一系列演算法將上層應用請求過來的寫請求進行優化並快取在陣列卡記憶體裡以此提高應用的寫效能（上層應用不必等待資料實際Flush到磁碟上即可完成寫操作）。由於快取也屬於RAM的一種，因此也存在掉電丟資料的風險。一旦伺服器斷電，陣列卡記憶體中的資料就會丟失，這會給應用造成資料完整性的風險。

電池的誕生

為了保障斷電後資料的完整性，於是一種可迴圈充電式的電池被應用到陣列卡記憶體單元上。如今大部分陣列卡的記憶體單元都會外接一個可充電式的電池，以此來為斷電後的快取提供電源支援保障資料在一定時間內不丟失（這個時間通常為48小時）。待到下一次伺服器再次恢復電源後，陣列卡控制器會將快取中的資料Flush到磁碟，以避免臟資料的產生。

快取的供電方式

1、一般情況下伺服器通電時快取使用的是主機板供電； 2、伺服器斷電時陣列卡板卡電路自動將快取的供電方式由主機板切換到電池；

電池為何要進行充放電操作？

陣列卡鋰電池，我們知道鋰電池有較強的惰性，它在非充電狀態下會緩慢地自放電（電池特性），一段時間後電量就會和剛充滿電時不同，為了能夠及時校準電量避免電池因為自放電而導致電量不明確，於是陣列卡控制器會對電池進行週期性地充放電操作（Relearn），以此保證電量的準確性，同時還可以判斷電池是否故障或者老化。

電池充放電會有哪些操作？

1、控制器首先對電池進行完全放電直至零電量；

2、控制器重新對電池進行充電操作直至充滿；

3、控制器對電池的電量重新進行計算校準；

4、等待下一個充放電時間點；

為何充放電會引發效能問題？

充放電操作時由於電池電量無法提供足夠的資料保障時間，為了避免風險發生陣列卡控制器預設會將快取關閉，正是由於快取被關閉而引發了寫效能急劇下降的問題。

惠普伺服器為何沒有同類問題？

1、惠普陣列卡採用的是鎳氫電池，它沒有惰性，並且特性和鋰電池不同，它並不需要通過完全放電來校準電量。 2、當鎳氫電池由於自放電而導致電量降低時到一定程度時（比如80%），陣列卡控制器會感知到這一資訊並對電池進行娟流充電以補充失去的電量，整個過程對使用者是透明的，也不需要關閉快取，因此並不會影響IO效能。

是否存在可充電式電池的替代方案？

有！快閃記憶體式電容方案不但可以替代電池提供幾乎無限的保護資料時間，並且控制器也不會因為充放電而關閉快取。快閃記憶體式電容能夠在伺服器斷電時，由高容量電容向陣列卡提供短暫的供電（大約幾分鐘），隨後陣列卡控制器會將快取中的資料全部複製到同等容量的快閃記憶體媒介上。因為快閃記憶體是非易失性記憶體，因此可以人為幾乎是無限時間的資料保護。待下一次伺服器正常通電開機，陣列卡控制器在初始化階段會將快閃記憶體中的髒資料重新Flush到磁碟上。

快閃記憶體式電容方案也不是絕對非常完美的，缺點也顯而易見，就是成本太高！

為何採用可充電式電池？

1、基於可充電式電池的快取單元價格低廉，比基於快閃記憶體式電容的快取單元要便宜許多； 2、可充電式電池可以通過迴圈充電已經能夠滿足一定的資料保護時間。

說到底還是因為成本！

陣列卡自動充放電帶來的運維問題？

1、電池壽命有限，更換週期通常是2-3年，更換需要停機操作，增加運維工作量；

2、電池自動充放電時會強制關閉快取影響陣列效能，給業務造成很大影響，給運維帶來壓力；

3、由於電池問題引發的問題和故障數不勝數，增加運維團隊的工作量。

為何放棄陣列卡自動充放電功能？

1、xiaomi伺服器都是雙電方案，單電源故障更換操作可線上完成；

2、綁線規範使得電源和插頭之間不會出現鬆動脫離的情況，更加減少了掉電的風險；

3、單個電源的月故障率遠遠低於磁碟、記憶體、陣列卡，雙電同時故障概率極其低（大約為百萬分之1.5552）；

解決方案：

1、快取單元的供電方案更換成快閃記憶體式電容；

2、快取設定為WT（寫快取開啟）和CachedBadBBU（強制寫快取開啟），AutoLearn仍舊進行只是該過程進行階段快取不會被關閉； （推薦）

3、擔心AutoLearn期間電池的資料保護時間不夠的話，也可以選擇不強制開啟寫快取，僅在業務低峰期通過MegaCli工具人為進行電池Relearn操作；

本文永久更新連結地址：https://www.linuxidc.com/Linux/2018-05/152457.htm