记一次硬件问题导致IO较高分析
通常遇到此问题可能原因
第一、并发较大刷磁盘频繁
一般此问题不会造成io util 90%以上。如果事物较大或者并发较大，slow log会有记录，我们可以先看下当前线程连接情况，再结合slow log查看是哪些sql导致。
第二、Raid卡电池处于充放电阶段或者损坏
io util 90%以上，很大几率是硬件问题导致，我们可以通过如下命令检查，除HP服务器外其他采用MegaCli查看硬件信息，HP采用自带hpssacli命令查看，切记不要使用老命令hpacucli，此命令会导致部分HP型号服务器操作系统系统直接hang住。
MegaCli所兼容的服务器命令
查看缓存策略：
/opt/MegaRAID/MegaCli/MegaCli64 -cfgdsply -aALL |grep Policy
Default Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBUCurrent Cache Policy: WriteBack, ReadAhead, Direct, No Write Cache if Bad BBUAccess Policy : Read/WriteDisk Cache Policy : Disk's Default此种状态为BBU损坏时不写raid卡缓存 |
|---|
修改为BBU损坏时写raid卡缓存：
/opt/MegaRAID/MegaCli/MegaCli64 -LDSetProp CachedBadBBU -Lall -aALL
Default Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBUCurrent Cache Policy: WriteBack, ReadAhead, Direct, Write Cache OK if Bad BBUAccess Policy : Read/WriteDisk Cache Policy : Disk's Default |
|---|
生成自检及电池充放电日志：
/opt/MegaRAID/MegaCli/MegaCli64 -AdpEventLog -GetEvents -aALL -f 1.log
/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -aALL -f 2.log
打开物理磁盘缓存：
/opt/MegaRAID/MegaCli/MegaCli64 -LDGetProp -DskCache -LALL -aALL
Adapter 0-VD 0(target id: 0): Disk Write Cache : Enabled |
|---|
HP服务器hpssacli命令
HP查看缓存策略：
hpssacli ctrl all show detail|grep Cache
查看插槽号和逻辑磁盘号：
hpssacli ctrl all show config detail| egrep -i 'Logical Drive:|slot:'
打开物理磁盘缓存：
hpssacli ctrl slot=0 modify drivewritecache=enable
查看阵列号及SSDSmartPath：
hpssacli ctrl all show config detail| egrep -i 'Array:|HP SSD Smart Path'
SSD需要注意：(打开逻辑缓存需要先关闭SSD Smart Path功能)
hpssacli ctrl slot=0 array A modify ssdsmartpath=disable
打开逻辑磁盘缓存：
hpssacli ctrl slot=0 logicaldrive 1 modify caching=enable
在没有电池的情况下开启raid写缓存：
hpssacli ctrl slot=0 modify nobatterywritecache=enable
设置读写百分比：
hpssacli ctrl slot=0 modify cacheratio=10/90
了解以上命令后，分析三种情况
一、无Raid卡电池或电池损坏
查看raid卡电池状态：
/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuStatus -aALL
Adapter 0: Get BBU Status Failed.FW error description: The required hardware component is not present. |
|---|
这种情况，如果没有修改默认WriteCache OK if Bad BBU模式，在电池损坏时会转换成WT模式。从而导致IO非常高。
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBUCurrent Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU |
|---|
修改成WC模式后监控如下：可见io使用率从99.6%降到8%左右，效果显著。
但是这种情况下存在一个问题：因为没有raid卡电池保护，即突然断电或者主板故障时会造成数据丢失风险。数据库服务器一般采用双电模式，掉电风险较低，但是主板故障相对较高，所以BBU坏时是否要打开Write Cache，需要根据业务情况综合取舍。
二、Raid卡电池充放电
目前服务器除了HP服务器Raid卡采用电容外，大部分服务器Raid卡还都采用的是锂电池。
首先我们先了解BBU充放电原理：
BBU由锂离子电池和电子控制电路组成。锂离子电池的寿命取决于其老化程度，从出厂之后，无论它是否被充电及它的充放电次数多与少，锂离子电池的容量将慢慢的减少。这意味着一个老电池无法像新电池那么持久。也就决定了BBU的相对充电状态(Relative State of Charge)不会等于绝对充电状态(Absolute State of Charge)。为了记录电池的放电曲线，以便控制器了解电池的状态，例如最大和最小电压等，同时为了延长电池的寿命，默认会启用自动校准模式(AutoLearn Mode)。在learn cycle期间, raid卡控制器不会启用BBU直到它完成校准。整个过程大概1小时左右。这个过程中，会禁用WriteBack模式，以保证数据完整性，同时会造成性能的降低。 |
|---|
整个Learn Cycle分为三个步骤:
1. 控制器把BBU电池充满电(该步骤可能是放电后充电或直接充电，如果电池刚好满电，则直接进入第二阶段) 2. 开始校准, 对BBU电池执行放电 3. 放电完成后，完成校准，并重新开始充电，直接达到最大电量，整个Learn Cycle才算完成 注意: 如果第二或第三阶段被中断，重新校准的任务会停止，而不会重新执行。 |
|---|
不推荐关闭Auto Learn模式，通过这个校准，能延长电池寿命，不作电池校准的Raid卡，电池寿命将从正常的2年降为8个月。
再来说超级电容：
超级电容优于锂电池，采用电容+Flash子板的方式来将非正常掉电后的脏数据刷入Flash中永久保存。超级电容在50℃环境下可以使用5年，而且故障率低，不用例行充放电。目前大部分raid卡厂商也转向使用超级电容+Flash的备电方案。 |
|---|
采用MegaCli方式查看电池充放电周期：/opt/MegaRAID/MegaCli/MegaCli64 -AdpBbuCmd -GetBbuProperties -aALL BBU Properties for Adapter: 0 Auto Learn Period: 90 Days Next Learn time: Mar 4 2017 11:04:46 Learn Delay Interval:0 Hours Auto-Learn Mode: TransparentHP查看电容状态：hpssacli ctrl all show status Smart Array P440ar in Slot 0 (Embedded) Controller Status: OK Cache Status: OK Battery/Capacitor Status: OK |
|---|
各品牌服务器充放电周期：
产品类型 | 默认周期 |
|---|---|
DELL | 90天 |
ThinkServer | 28天 |
IBM | 30天 |
RH（华为） | 27天 |
HP | 电容不进行例行充放电 |
所以，Raid卡电池充放电阶段，会禁用WriteBack模式，以保证数据完整性，同时会造成性能的降低。
通过下面命令生成日志，可以查看充放电详细信息：
/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -aALL -f log.txt
三、硬件自检
首先看一个监控图，同一业务的8台服务器于11月12日凌晨3:00开始io开始升高，4:00左右达到最高峰io利用率达70%左右，之后开始下降直至平稳正常。此系统已经平稳运行了很长时间，并没有做什么上线操作。
因为是凌晨3:00出现，而且备份正好是凌晨3:00开始，首先想到可能是备份导致的io上升，但是登上服务器检查发现这几组机器并没有部署备份。
那么接下来可能会认为这段时间事物量较大，通过监控发现这个时间段并没有大量并发，而且此时间段为业务低峰期，相对访问操作较少。
开始着手分析硬件，通过命令生成硬件自检及raid卡电池充放电日志1.log和2.log，部分日志内容如下：
/opt/MegaRAID/MegaCli/MegaCli64 -AdpEventLog -GetEvents -aALL -f 1.log
Event Description: Patrol Read started Event Description: Consistency Check started on VD 00/0 Event Description: Patrol Read aborted on PD 1f(e0x00/s5) Event Description: Patrol Read aborted on PD 20(e0x00/s1) Event Description: Patrol Read aborted on PD 21(e0x00/s10) Event Description: Patrol Read aborted on PD 1e(e0x00/s3) Event Description: Patrol Read aborted on PD 25(e0x00/s0) Event Description: Patrol Read aborted on PD 22(e0x00/s2) Event Description: Patrol Read aborted on PD 23(e0x00/s8) Event Description: Patrol Read aborted on PD 26(e0x00/s6) Event Description: Patrol Read aborted on PD 27(e0x00/s7) Event Description: Patrol Read aborted on PD 24(e0x00/s4) Event Description: Patrol Read aborted on PD 29(e0x00/s11) Event Description: Patrol Read aborted on PD 28(e0x00/s9) Event Description: Consistency Check done on VD 00/0 |
|---|
/opt/MegaRAID/MegaCli/MegaCli64 -FwTermLog -Dsply -aALL -f 2.log
通过分析日志发现，系统会进行硬件自检，时间是每周六凌晨3:00开始。再查看更久的监控，发现每周六凌晨3:00 都会出现io较高现象。自检期间io消耗比较大，如果期间有事物处理，会出现慢sql、超时等现象，导致TP99报警。
如果调整的话需进入Bios修改，因为服务器产品不同，修改方法可能不一样。
以DELL、ThinkServer为例：
通过ILO F1进入BIOS，首先需要把BIOS的Legacy修改成UEFI模式： 1) 进入boot manage修改 boot mode为UEFI Only 2) 进入Miscellaneous Boot Settings 修改Storage OpROM Policy 为 UEFI Only 3) F10保存后重启再进入Boot manage 里面可以看到Adapters and UEFI Drivers 选项 4) 依次进入Controller Management—>Asvanced Controller Management—>Schedule Consistency Check即可看到检查频率： 5) 修改后，选择Apply Changes，务必选择应用生效 6) 把前面的UEFI修改回Legacy模式，否则无法进入操作系统，重启即可 7) 调整后，观察没有再出现凌晨3:00 io升高现象 |
|---|
总结
杜绝以上问题，需要从服务器初始化就做好：
- 调整硬件一致性自检策略，由每周调整为每月，并根据业务情况修改日期，针对电商来来说，618和双11是最大的两个大促，日期相对固定，但是赶到周几就不一定了，所以会尽量调到月末，相对影响更小、更安全。
- 修改Raid卡缓存策略 WriteBack,ReadAdaptive,Direct,Write Cache if Bad BBU模式： 此模式下存在在BBU有问题时(如电池失效)期间，突然断电或者主板故障都会导致数据丢失风险。 WriteBack,ReadAdaptive,Direct,No Write Cache if Bad BBU模式： 在BBU有问题时, 不使用Write Cache。但是可能发生Write Cache策略变更的情况(由WriteBack变成WriteThrough)，导致IO性能急剧下降。 所以，修改成哪种模式需要结合实际业务来定，建议无论是否有raid卡电池都改成WriteBack,ReadAdaptive,Direct,Write Cache if Bad BBU模式。
- 不建议关闭硬件自检，可以适当延长自检周期，通过自检可以及时发现硬件问题，监控更及时。
- 不建议关闭raid卡电池Auto Learn模式，通过这个校准，能延长电池寿命，不作电池校准的Raid卡，电池寿命将从正常的2年降为8个月。
- 另外mysql innodb_flush_method建议设成O_DIRECT模式：数据文件的写入操作是直接从mysql innodb buffer到磁盘（raid卡缓存）的，并不用通过操作系统的缓冲，而真正的完成也是在flush这步，日志还是要经过OS缓存。
HP官方工具集：
http://h20564.www2.hpe.com/hpsc/doc/public/display?docId=c03909334
http://h20564.www2.hpe.com/hpsc/swd/public/detail?sp4ts.oid=7252838&swItemId=MTX_38896e67ccde4fc8a752a3f0a6&swEnvOid=4124#tab3