Exadata 上關于SAS盤的小秘密

案例概述

一個X3-2 的Exadata臨時客戶，ORACLE原廠工程師在進行onecommand初始化的過程中，執行到第6步，calibrate檢測存儲節點磁盤性能時報錯，後續工作無法繼續。而由于一些商務上的原因，原廠的硬體工程師無法提供技術支援。

客戶最終找到了我們，希望我們能幫着一起分析分析，存儲節點磁盤的性能是否存在問題。在問題轉給我之前，客戶自己也做了大量的換盤和測試工作。目前存儲節點使用calibrate檢測的結果正常，但插槽0 或 插槽1 的MBPS偶爾比其它的磁盤低十幾MB左右，但還是在可以接受的範圍之内。

目前，客戶主要有兩個疑問，需要我進行解釋：

1、測試過程中以前一些表現比較差的磁盤，為什麼将這類磁盤更換到其它的存儲節點後再次測試，性能又能恢複正常？

2、現在的插槽 0 或 插槽 1 的磁盤MBPS偶爾比其它的磁盤低十幾MB左右，是否正常？

問題分析

在分析問題之前，我讓客戶提供了這段時間内的測試記錄，同時讓客戶收集了相應的一些資訊。

2016-11-10 13:57:48,276 [FINE] Calibrate output... 2016-11-10 13:57:48,276 [FINE] Output from cell01 . 2016-11-10 13:57:48,276 [FINE] Calibration will take a few minutes... 2016-11-10 13:57:48,276 [FINE] Error occurred during orion execution: 10219: Error completing IO 2016-11-10 13:57:48,276 [FINE] (storax_skgfr_aiowait) 2016-11-10 13:57:48,276 [FINE] ORA-27061: waiting for async I/Os failed 2016-11-10 13:57:48,276 [FINE] Linux-x86_64 Error: 5: Input/output error 2016-11-10 13:57:48,277 [FINE] Additional information: 4294967295 2016-11-10 13:57:48,277 [FINE] Additional information: 1048576 2016-11-10 13:57:48,277 [FINE] rand_ALL0_20161110_1345 2016-11-10 13:57:48,277 [FINE] Test aborted due to errors. 2016-11-10 13:57:48,277 [FINE] ORION: ORacle IO Numbers -- Version 12.1.0.2.0 2016-11-10 13:57:48,277 [FINE] Calibration will take approximately 1 minutes. 2016-11-10 13:57:48,277 [FINE] Using a large value for -cache_size may take longer. 2016-11-10 13:57:48,277 [FINE] CELL-01524: An error occurred while running CALIBRATE tests.

以上資訊是onecommand過程中報的錯誤，從錯誤日志可以看出，在調用CALIBRATE指令檢測所有存儲節點磁盤性能時，出現了錯誤。

Nov 10 13:46:13 cell01 kernel: sd 4:2:0:0: [sdq] Unhandled sense code Nov 10 13:46:13 cell01 kernel: sd 4:2:0:0: [sdq] Result: hostbyte=invalid driverbyte=DRIVER_SENSE Nov 10 13:46:13 cell01 kernel: sd 4:2:0:0: [sdq] Sense Key : Medium Error [current] Nov 10 13:46:13 cell01 kernel: sd 4:2:0:0: [sdq] Add. Sense: Unrecovered read error Nov 10 13:46:13 cell01 kernel: sd 4:2:0:0: [sdq] CDB: Read(10): 28 00 14 cd e8 00 00 08 00 00 Nov 10 13:46:13 cell01 kernel: end_request: critical target error, dev sdq, sector 349038592

以上資訊是sundiag收集的日志，可以看出，存儲節點cell01在通路/dev/sdq這塊盤的時候出現了Medium Error。

以上圖檔是客戶在測試過程中的截圖，可以看出，MBPS為0，類似這種磁盤，需要直接更換掉。在問題轉到我們這裡之前，客戶也已經将這種磁盤全部更換掉。 注意：客戶更換的是SEAGATE ST360057SSUN600G 磁盤。而恰恰是這種磁盤，給後續的測試帶來了性能問題。也即客戶的問題1：為什麼測試過程中以前一些表現比較差的磁盤，為什麼将這類磁盤更換到其它的存儲節點後再次測試，性能又能恢複原樣？

客戶的測試過程

11月28日晚上20:25:30開始，客戶從作業系統層面直接調用CALIBRATE指令進行測試,循環執行55次。如下圖，是客戶截取的測試結果。

從上圖可以看出，有部分磁盤的性能還是比較差的。由于這個案例是事後分析，當時的一些日志資訊已經不完整，但還好CELL02節點的插槽5這塊盤的日志儲存完整，以下主要針對CELL02節點的插槽5這塊盤進行分析：

name: 20:5 deviceId: 25 deviceName: /dev/sdv diskType: HardDisk enclosureDeviceId: 20 errOtherCount: 0 luns: 0_5 makeModel: "SEAGATE ST360057SSUN600G" physicalFirmware: 0B25 physicalInsertTime: 2016-11-25T13:28:34+08:00 physicalInterface: sas physicalSerial: E06TT6 physicalSize: 558.9120712280273G slotNumber: 5 status: normal

以上資訊可以看出，插槽5這塊盤是2016-11-25 13:28:34剛剛更換後的SEAGATE的SAS硬碟。

Mon Nov 28 20:40:22 CST 2016 CELL02 ######### +++++++++++++++++++++++++++++++########### Calibration will take a few minutes... Aggregate random read throughput across all hard disk LUNs: 1774 MBPS Aggregate random read throughput across all flash disk LUNs: 8163 MBPS Aggregate random read IOs per second (IOPS) across all hard disk LUNs: 4765 Aggregate random read IOs per second (IOPS) across all flash disk LUNs: 122923 Calibrating hard disks (read only) ... LUN 0 on drive [20:0 ] random read throughput: 152.00 MBPS, and 402 IOPS LUN 1 on drive [20:1 ] random read throughput: 152.00 MBPS, and 405 IOPS LUN 10 on drive [20:10 ] random read throughput: 156.00 MBPS, and 406 IOPS LUN 11 on drive [20:11 ] random read throughput: 157.00 MBPS, and 396 IOPS LUN 0_2 on drive [20:2 ] random read throughput: 153.00 MBPS, and 400 IOPS LUN 0_3 on drive [20:3 ] random read throughput: 155.00 MBPS, and 396 IOPS LUN 0_4 on drive [20:4 ] random read throughput: 153.00 MBPS, and 401 IOPS LUN 0_5 on drive [20:5 ] random read throughput: 139.00 MBPS, and 416 IOPS LUN 0_6 on drive [20:6 ] random read throughput: 154.00 MBPS, and 395 IOPS LUN 0_7 on drive [20:7 ] random read throughput: 156.00 MBPS, and 400 IOPS LUN 0_8 on drive [20:8 ] random read throughput: 155.00 MBPS, and 407 IOPS LUN 0_9 on drive [20:9 ] random read throughput: 155.00 MBPS, and 398 IOPS Calibrating flash disks (read only, note that writes will be significantly slower) ... LUN 1_0 on drive [FLASH_1_0] random read throughput: 543.00 MBPS, and 33629 IOPS LUN 1_1 on drive [FLASH_1_1] random read throughput: 543.00 MBPS, and 34071 IOPS LUN 1_2 on drive [FLASH_1_2] random read throughput: 543.00 MBPS, and 33511 IOPS LUN 1_3 on drive [FLASH_1_3] random read throughput: 543.00 MBPS, and 33743 IOPS LUN 2_0 on drive [FLASH_2_0] random read throughput: 544.00 MBPS, and 43067 IOPS LUN 2_1 on drive [FLASH_2_1] random read throughput: 544.00 MBPS, and 43669 IOPS LUN 2_2 on drive [FLASH_2_2] random read throughput: 544.00 MBPS, and 44591 IOPS LUN 2_3 on drive [FLASH_2_3] random read throughput: 544.00 MBPS, and 43295 IOPS LUN 4_0 on drive [FLASH_4_0] random read throughput: 542.00 MBPS, and 39627 IOPS LUN 4_1 on drive [FLASH_4_1] random read throughput: 541.00 MBPS, and 40623 IOPS LUN 4_2 on drive [FLASH_4_2] random read throughput: 544.00 MBPS, and 40771 IOPS LUN 4_3 on drive [FLASH_4_3] random read throughput: 543.00 MBPS, and 40873 IOPS LUN 5_0 on drive [FLASH_5_0] random read throughput: 543.00 MBPS, and 37453 IOPS LUN 5_1 on drive [FLASH_5_1] random read throughput: 542.00 MBPS, and 36818 IOPS LUN 5_2 on drive [FLASH_5_2] random read throughput: 543.00 MBPS, and 35609 IOPS LUN 5_3 on drive [FLASH_5_3] random read throughput: 544.00 MBPS, and 33297 IOPS Found some bad LUNs, running tests sequentially to identify the bad LUNs... LUN 0_5 on drive [20:5 ] random read throughput: 167.00 MBPS, and 422 IOPS CALIBRATE results are within an acceptable range. Calibration has finished.

以上資訊可以看出，在2016-11-28 20:40:22時，對CEll02存儲節點的磁盤做性能測試時，發現插槽5上的磁盤性能比較低。

11月29日,客戶根據28日的檢測結果，對一些性能偏低的硬碟進行更換，例如：将Cell07存儲節點上插槽7（沒有測出性能問題日立原盤）的磁盤 與Cell02存儲節點上插槽5(出現性能問題的希捷硬碟)的磁盤進行互換。

更換後測試結果如下圖：

我們仍然關注Cell02的 插槽5(希捷硬碟)，發現它換到Cell07的插槽7後，Cell07沒有出現性能問題了。同理，Cell07的 插槽7（日立硬碟）更換到Cell02的 插槽5後，Cell02也沒有出現性能問題。

問題1的原因

通過客戶的以上測試過程來分析，我們基本可以得出結論，針對Cell02的插槽5的這塊希捷硬碟，這塊硬碟本身是沒有問題的，但在某種情況下，會引發性能問題。但是什麼的條件會引發硬碟的性能低下呢？同樣，滿足什麼樣的條件，進入性能低下的硬碟又能恢複原有的性能呢？

[[email protected] ~]# cellcli -e list metrichistory where name like CL_TEMP > Cell02_TEMP.txt [[email protected] ~]# more Cell02_TEMP.txt CL_TEMP cell02 22.0 C 2016-11-28T19:00:44+08:00 CL_TEMP cell02 22.0 C 2016-11-28T19:01:44+08:00 .......(略) CL_TEMP cell02 22.0 C 2016-12-05T19:49:03+08:00 CL_TEMP cell02 23.0 C 2016-12-05T19:50:03+08:00 [[email protected] ~]# [[email protected] ~]# cat Cell02_TEMP.txt |awk '{if ($3<20.0) print $2 "||" $3 "||" $5}' cell02||19.0||2016-11-28T20:12:44+08:00 cell02||19.0||2016-11-28T20:17:44+08:00 [[email protected] ~]# [[email protected] ~]# cat Cell02_TEMP.txt |awk '{if ($3>23.0) print $2 "||" $3 "||" $5}' |more cell02||24.0||2016-12-02T17:53:49+08:00 cell02||24.0||2016-12-02T18:24:49+08:00 cell02||24.0||2016-12-02T18:33:09+08:00 [[email protected] ~]#

以上的日志是事後進行分析時，讓客戶抓取的資訊，讓客戶抓取Cell02存儲節點的溫度曆史資訊。可以看到，由于是事後分析，隻能看到2016-11-28 至2016-12-05 這部分的資料，對溫度曆史資訊進行過濾，我們可以看到，Cell02存儲節點在2016-11-28 20點12分 和 20點17分 這兩個時間點的溫度隻有19度， 而客戶進行性能測試的時間點為20:25:30開始。

Nov 22 20:25:26 cell02 ntpd[10952]: 0.0.0.0 c016 06 restart Nov 23 17:53:45 cell02 ntpd[13021]: 0.0.0.0 c016 06 restart Dec 2 20:30:36 cell02 ntpd[12990]: 0.0.0.0 c016 06 restart

以上是Cell02存儲節點的作業系統重新開機資訊，可以看出，11-23 至 12-2 之間，作業系統是未重新開機過的。

同樣，讓客戶抓取Cell07存儲節點的溫度曆史資訊進行分析：

[[email protected]~]# cellcli -e list metrichistory where name like CL_TEMP > Cell07_TEMP.txt [[email protected]~]# more Cell07_TEMP.txt CL_TEMP cell07 24.0 C 2016-11-28T19:00:16+08:00 CL_TEMP cell07 24.0 C 2016-11-28T19:01:16+08:00 ......(略) CL_TEMP cell07 23.0 C 2016-12-05T19:53:48+08:00 CL_TEMP cell07 23.0 C 2016-12-05T19:54:48+08:00 CL_TEMP cell07 23.0 C 2016-12-05T19:55:54+08:00 [[email protected]~]# [[email protected]~]# cat Cell07_TEMP.txt |awk '{if ($3<20.0) print $2 "||" $3 "||" $5}' [[email protected]~]#

以上的日志是Cell07存儲節點的溫度曆史資訊。可以看到2016-11-28 至2016-12-05 這部分的資料，對溫度曆史資訊進行過濾，我們可以看到，Cell07未出現過溫度低于20度的情況。

Nov 22 13:57:20 cell07ntpd[13001]: 0.0.0.0 c016 06 restart     Nov 23 17:54:02 cell07ntpd[13045]: 0.0.0.0 c016 06 restart     Nov 28 18:17:47 cell07ntpd[13029]: 0.0.0.0 c016 06 restart     Dec 2 20:35:56 cell07ntpd[12981]: 0.0.0.0 c016 06 restart

以上是Cell07存儲節點的作業系統重新開機資訊，可以看出，11-23 至 12-2 之間，作業系統是重新開機過多次的。

下面，我來歸納下客戶所做的性能測試：

Cell02存儲節點在2016-11-28 20點17分時，溫度低下20攝氏度，并且作業系統未重新開機過，同時未出現連續30分鐘以上的24度高溫，客戶在20點25分，開始做性能測試，此時的希捷SAS盤性能表現比較差；接着，在11-29日，這塊希捷SAS磁盤換到了Cell07，由于Cell07從未出現過低于20攝氏度的情況，并且作業系統于11-28 18:17重新開機過，是以這塊希捷SAS在CELL07上又表現良好。

結合Cell02與Cell07的曆史溫度資訊和作業系統重新開機情況，正好驗證了Exadata上SAS盤的一個小秘密：

Exadata上的希捷SAS硬碟，當溫度低于20攝氏度時，性能會出現下降，并且這種性能下降的現象一直存在。有兩種情況才能讓這種希捷SAS硬碟恢複原有的性能：(1).希捷SAS的溫度必須連續30分鐘以上保持在24攝氏度。 (2).希捷SAS的溫度在20攝氏度以上，并重新開機作業系統。

問題2的原因

對于問題1，前面已經進行了完整的闡述，下面來看看問題2：現在的插槽 0 或 插槽 1 的MBPS偶爾比其它的磁盤低十幾MB左右，是否正常？

1、批量運作CALIBRATE指令對所有存儲節點硬碟整體測試

測試結果如下圖：

節點名	問題類型	硬碟	性能下降次數	總次數
cell01	性能問題	插槽 0	無	50
性能問題	插槽 1	1
cell02	性能問題	插槽 1	1	50
cell03	性能問題	插槽 0	1	50
性能問題	插槽 1	3
cell04	性能問題	插槽 0	2	50
性能問題	插槽 1	1
cell05	性能問題	插槽 1	4	50
性能問題	插槽 0	無
cell06	性能問題	插槽 0	無	50
cell07	性能問題	插槽 0	2	50

從以上測試結果可以看出：插槽0和插槽1的磁盤性能下降問題是偶爾出現，同時也隻是提示資訊，且CALIBRATE測試結果在ORACLE的接受範圍之内， 并不像以前直接報ERROR錯誤。

2、批量運作CALIBRATE指令單獨對插槽0和插槽1硬碟進行性能測試

測試結果如下圖：

節點名	問題類型	硬碟	性能下降次數	總次數
cell01	性能問題	插槽0	無	50
性能問題	插槽1	無
cell02	性能問題	插槽0	無	50
性能問題	插槽1	無
cell03	性能問題	插槽0	無	50
性能問題	插槽1	無
cell04	性能問題	插槽0	無	50
性能問題	插槽1	無
cell05	性能問題	插槽1	無	50
性能問題	插槽0	無
cell06	性能問題	插槽1	無	50
性能問題	插槽0	無
cell07	性能問題	插槽0	無	50
性能問題	插槽1	無

從以上測試結果可以看出：單獨對所有存儲節點的插槽0和插槽1硬碟進行性能測試，沒有發現性能降低情況，說明硬碟沒有問題。

3、通過hdparm工具對插槽0和插槽1硬碟以及其他硬碟進行性能測試

其實，在診斷Exadata上的磁盤是否出現性能問題時，可以使用hdparm工具來進行分析，其中對每個盤單獨測試5次，對Timing buffered disk reads取其平均值後，進行比對。

以下，還是拿cell02來進行測試。

存儲節點二插槽0 盤測試結果:

平均值為：(177.06+178.58+175.69+178.64+177.31)/5=177.456 MB/sec

存儲節點二插槽1 盤測試結果:

平均值為：(189.09+176.97+174.36+173.54+176.77)/5=178.146 MB/sec

存儲節點二其他盤測試結果

平均值為：(189.25+189.66+189.72+189.80+189.53)/5=189.592 MB/sec

以上測試可以看出，插槽 0 和 插槽1 上的磁盤性能與其它盤基本一緻，無太大差别，但比其它盤還是要低一些。這是由于Exadata上的插槽0和 插槽1上安裝了作業系統，必然會消耗部分性能。

後續思考

至此，客戶提出的兩個問題，基本上已經進行了解答。

在處理這個案例的過程中，客戶也透露了一個資訊，在3年前，他們剛買這台X3-2時，ORACLE原廠曾經一次性将7台存儲節點的84塊硬碟全部換過，理由是這批硬碟有性能問題，更換前是什麼硬碟我不得而知，但更換後的是日立的硬碟。我猜測更換前，應該是希捷硬碟，因為Exadata以前的版本一直用希捷硬碟，後來發現了溫度引發硬碟性能低下這個問題後，基本上就放棄了希捷硬碟，而改用日立硬碟，而日立硬碟是不是就不存在這種溫度影響性能的問題呢，其實也是存在的，隻不過觸發的條件更加極限，隻有當溫度低于15攝氏度時,才會引發性能問題。

那以後，Exadata會不會永遠放棄希捷硬碟呢，這個也不好說，低于20攝氏度觸發性能低下，這個特性是希捷特意設計的，不能簡單稱之為BUG，ORACLE硬體部門目前與希捷也在共同合作，希望在以後的firmware中進行修正這個問題。

轉載于:https://www.cnblogs.com/missyou-shiyh/p/6181905.html