背景
最近遇到有些带MegaSAS RAID卡的服务器,在业务高峰时突然IO负载飚升得很高,IO性能急剧下降,查了日志及各种设置最后才发现是RAID卡的Cache写策略由WriteBack变成WriteThrough了。更深入的原因是BBU进入了Learn Cycle周期,自动把Cache策略改为WriteThrough.
WriteBack和WriteThrough
在开始之前,我需要提到两个词: WriteBack, WriteThrough
WriteBack:进行写操作时,将数据写入RAID卡缓存,并直接返回,RAID卡控制器将在系统负载低或者Cache满了的情况下把数据写入硬盘。该设置会大大提升RAID卡写性能,绝大多数的情况下会降低系统IO负载。 数据的可靠性由RAID卡的BBU(Battery Backup Unit)进行保证。
WriteThrough: 数据写操作不使用缓存,数据直接写入磁盘。RAID卡写性能下降,在大多数情况下该设置会造成系统IO负载上升。
MegaSAS RAID卡的Cache策略
对于LSI的MegaSAS RAID卡, 默认的Cache策略是: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
如何查看RAID卡Cache策略
root@hostname:~ # ./MegaCli -LDInfo -Lall -aALLAdapter 0 -- Virtual Drive Information:Virtual Drive: 0 (Target Id: 0)Name :RAID Level : Primary-1, Secondary-0, RAID Level Qualifier-0Size : 557.861 GBMirror Data : 557.861 GBState : OptimalStrip Size : 128 KBNumber Of Drives : 2Span Depth : 1Default Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBUCurrent Cache Policy: WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBUDefault Access Policy: Read/WriteCurrent Access Policy: Read/WriteDisk Cache Policy : DisabledEncryption Type : NoneIs VD Cached: NoExit Code: 0x00
策略说明
第一段: WriteBack, WriteThrough
第二段: ReadAheadNone, ReadAdaptive, ReadAhead.
ReadAheadNone: 不开启预读。这是默认的设置
ReadAhead: 在读操作时,预先把后面顺序的数据加载入Cache,在顺序读取时,能提高性能,相反会降低随机读的性能。
ReadAdaptive: 自适应预读,当Cache memory和IO空闲时,采取顺序预读,平衡了连续读性能及随机读的性能,需要消耗一定的计算能力。
第三段: Direct, Cached.
第四段: Write Cache OK if Bad BBU, No Write Cache if Bad BBU
Write Cache OK if Bad BBU: 在BBU有问题时(如电池失效), 依旧使用Write Cache, 有一定的数据丢失风险.
No Write Cache if Bad BBU: 在BBU有问题时, 不使用Write Cache
策略自动切换的问题
由于MegaSAS RAID卡默认采用No Write Cache if Bad BBU的设置,将可能发生Write Cache策略变更的情况(由WriteBack变成WriteThrough),导致写性能下降,如果该自动变更发生在业务高峰且系统Io负载高的时候,可能会引发不可预测的问题,如卡机。以下原因将造成Write Cache策略的变更.
RAID卡进入BBU Learn Cycle: 详细介绍见下面
检测到某些电池故障,如电池容量过低等,一般是电池老化带来的影响,IBM建议一年更换一次RAID卡电池
没有安装电池, 部分服务器购买时不带电池,导致被自动设置为WriteThrough
在BBU出问题时,如何临时强制启用Write Cache?
./MegaCli -LDSetProp CachedBadBBU -Lall -aALL./MegaCli -LDSetProp WB -Lall -aALL#以下命令可以把设置修改回去./MegaCli -LDSetProp NOCachedBadBBU -Lall -aALL
BBU Learn Cycle
BBU由锂离子电池和电子控制电路组成。 锂离子电池的寿命取决于其老化程度,从出厂之后,无论它是否被充电及它的充放电次数多与少,锂离子电池的容量将慢慢的减少。这意味着一个老电池无法像新电池那么持久。 也就决定了BBU的相对充电状态(Relative State of Charge)不会等于绝对充电状态(Absolute State of Charge)。 为了记录电池的放电曲线,以便控制器了解电池的状态,例如最大和最小电压等,同时为了延长电池的寿命,默认会启用自动校准模式(AutoLearn Mode). 在learn cycle期间, raid卡控制器不会启用BBU直到它完成校准。整个过程可能需要高达12小时。这个过程中,会禁用WriteBack模式,以保证数据完整性,同时会造成性能的降低. 整个Learn Cycle分为三个步骤:
控制器把BBU电池充满电(该步骤可能是放电后充电或直接充电,如果电池刚好满电,则直接进入第二阶段)
开始校准, 对BBU电池执行放电
放电完成后,完成校准,并重新开始充电, 直接达到最大电量, 整个Learn Cycle才算完成 注意: 如果第二或第三阶段被中断,重新校准的任务会停止,而不会重新执行
IBM的服务器默认设置是30天执行一次Learn Cycle, 而DELL是90天。不推荐关闭Auto Learn模式,通过这个校准,能延长电池寿命,不作电池校准的Raid卡,电池寿命将从正常的2年降为8个月
查看当前的BBU Learn设置
root@hostname:~ # ./MegaCli -AdpBbuCmd -GetBbuProperties -aALLBBU Properties for Adapter: 0Auto Learn Period: 2592000 SecNext Learn time: 394618008 SecLearn Delay Interval:0 HoursAuto-Learn Mode: Enabled
Auto Learn Period: 自动校准间隔, 单位秒,IBM的服务器默认设置是30天执行一次Learn Cycle, 而DELL是90天。 该设置无法修改。
Next Learn time: 下一次自动校准的时间,从2000年1月1日算起的秒数,这个设置无法修改,根据上一次自动校准的完成时间加上自动校准间隔计算得来。该时间转化为实际时间时,需要加上RAID卡时间的误差,部分RAID卡时间转成GMT时间后,依然是错误的。
实际时间计算方法,伪代码如下
RealTime = Next Learn time + ( 系统时间的Unixtime - RAID卡时间的Unixtime )date -d 'UTC 2000-01-01 + $RealTime secs'
查看当前BBU的状态
root@hostname:~ # MegaCli -AdpBbuCmd -GetBbuStatus -aALLBBU status for Adapter: 0BatteryType: iBBUVoltage: 3837 mVCurrent: -152 mATemperature: 23 CBattery State : OperationalBBU Firmware Status:Charging Status : DischargingVoltage : OKTemperature : OKLearn Cycle Requested : YesLearn Cycle Active : YesLearn Cycle Status : OKLearn Cycle Timeout : NoI2c Errors Detected : NoBattery Pack Missing : NoBattery Replacement required : NoRemaining Capacity Low : NoPeriodic Learn Required : NoTransparent Learn : NoNo space to cache offload : NoPack is about to fail & should be replaced : NoCache Offload premium feature required : NoModule microcode update required : No...下略...
Charging Status: 当前电池处于什么状态,有Charging, Discharging, None等值,分别代表电池充电,放电,及没有充放电操作的状态
Learn Cycle Requested: Learn Cycle请求,当为Yes时,并且下面的Learn Cycle Active为No, 说明已经开始了Learn Cycle的第一阶段, 此时策略开始变为WriteThrough, 电池将经历一个放电后充电或者充电的过程
Learn Cycle Active: 是否处于Learn Cycle的校准阶段,如果为Yes, 则进入了Learn Cycle的第二阶段,控制器开始校准电池.
Battery Replacement required: 电池是否需要维修,如果为Yes, 请尽快更换电池5. Remaining Capacity Low: 剩余电容量低, 如果为Yes, 需要更换电池
如何强制启动Learn Cycle操作
强制执行自动校准的命令, 执行该命令后,会延迟几秒才会生效,策略会自动变为WriteThrough
root@hostname:~ # MegaCli -AdpBbuCmd -BbuLearn -aALL
通过该命令可以粗略的调整自动校准的下次执行时间,但无法100%准确:
如何查看当前的Cache策略是否发生变动
对比Default Cache Policy和Current Cache Policy是否不同,不同则是策略发生变动
root@hostname:~ # MegaCli -LDInfo -Lall -aALL
如何把Learn模式改为手动?
echo 'autoLearnMode=1' >/tmp/megaraid.confMegaCli -AdpBbuCmd -SetBbuProperties -f /tmp/megaraid.conf -aAll#1为Disable, 0为Enable, 从Disable切换到Enable时,Relearn操作会立刻执行#确认是否生效MegaCli -AdpBbuCmd -GetBbuProperties -aALL
建议
推荐的Cache策略: 使用No Write Cache if Bad BBU,在BBU出问题的情况下,牺牲性能来确保数据的安全性。 WriteBack, ReadAheadNone, Direct, No Write Cache if Bad BBU
以下有几种可选的方法
在非业务高峰对BBU强制启动Learn Cycle,但下次自动的Learn Cycle会向后延迟5-6小时(视整个Learn Cycle所需时间而定)。每一次Learn Cycle执行完,下次Learn Cycle的执行时间会发生向后偏移的情况,推移时间由上一次整个Learn Cycle的耗时决定,一般下一次执行时间都会向后推移大约5小时(一次Learn Cycle的时间)。建议可以根据实际推迟效果定期在非业务高峰做一次手动Learn Cycle(一般是02:00~05:00)
切换为手动模式,由crontab或者其他手动定期触发Learn Cycle,采用该方式需要根据不同硬件来决定Learn Cycle的间隔,采取错误的间隔将损耗电池的寿命。IBM的30天, DELL的机器为90天。
检测下次Learn Cycle的时间,在即将进入Learn Cycle前,设置为Write Cached OK if Bad BBU, 使得Write Cache策略在Learn Cycle期间不发生变动,Learn Cycle过后,切换会原配置,这种方式在Learn Cycle期间(大约5小时左右)数据将不保险,如果遇到断电的情况,将发生数据丢失。* 检测下次Learn Cycle的时间,提前1~2天,在非业务高峰期提前触发learn cycle. 这种方法效果最好,也最方便,需要专门的脚本进行下次Learn Cycle时间的计算
推荐做法: 在保留Auto Learn模式的同时,定期通过Crontab对Raid卡执行强制Relearn的操作,检测下次Learn Cycle的时间,提前1~2天,在非业务高峰期提前触发learn cycle(一般是02:00~05:00)。
参考资料
对RAID及BBU的自问自答
ServeRAID-M Series Battery Backup Unit (BBU) charge cycle behavior and cache modes - IBM System x
推荐本站淘宝优惠价购买喜欢的宝贝:
本文链接:https://www.hqyman.cn/post/8448.html 非本站原创文章欢迎转载,原创文章需保留本站地址!
打赏微信支付宝扫一扫,打赏作者吧~
休息一下~~