SAN I/O error（2）

正如上回所述，SAN問題所引起的影響隨時超過5分鐘，在秒秒鐘幾廿萬上落的金融世界當然不可以接受。有見及此，在SLES11 SP3 / RHEL6.5+及kernel 2.6.32-431或之後增加左SCSI timeout parameters tuning feature，可以在/etc/udev/rules.d檔案下增加下列rules：

timeout －更改進入recovery mode的timeout value。default是60，可以改成30

SUBSYSTEM=="scsi" , ATTR{type}=="0|7|14", ATTR{timeout}="30"

eh_timeout - 更改unresponsive device的timeout value。default是10，可以改成5

SUBSYSTEM=="scsi" , ATTR{type}=="0|7|14", ATTR{timeout}="5"

eh_deadline - 更改整個error recovery process timeout value。default是0，建議改成90

SUBSYSTEM=="scsi_host" , ATTR{modelname}=="42C2069", ATTR{eh_deadline}="90"

Finetuning 完畢後recovery flow如下：

優化後最大的recovery time是120s，比之前的500s縮短了很多！就算在最壞情況，因為每個device的timeout value是5s，假如系統有10 LUN device，也只是120 ＋ 5*10 ＝ 220s，完全符合Oracle RAC eviction的300s限制！

SAN I/O error（1）

SAN 既問題係筆者遇過最麻煩的問題之一。當SAN fabric有事的時候可以隨時影響數十或上百台server。

SAN error handling機制：
－假設@time＝0， SAN path出現問題
－當SCSI request 30秒內沒有回應，就會進入recovery mode
－首先會abort I/O，再send TUR checker檢查path是否正常
－這裡要注意的是每一個LUN device都會發出TUR checker，所以TUR checker都timeout才會進入下一階段
－如果TUR checker沒有回應，就進入下一步device reset，之後再發出TUR checker檢查path
－接著會reset target／bus／host，中間每次都有TUR checker檢查reset後的情況
－reset完host之後系統會重新搜尋remote port, 如果有事的path還是unavailable, 系統會直接把它block了，所以traffic轉移到其他available的path。
－最壞情況是remote port該死未死，還可以login。最後系統還會發出一次TUR checker，timeout之後就逐一把LUN device mark failed。
－我們來計一計數，TUR checker的timeout value是10秒。
    假設一台server有10 LUN device，所需時間就是100秒。
                                     （reset時間不算在內） 30s ＋ 4＊10＊10s ＝430s
     正常情況下系統需要430秒把traffic轉移到正常path
     最壞情況需要  430s ＋  10*10s （最後一次TUR checker）＝ 530s 才能把有事的path isolate。
－所以SAN問題可大可小，在筆者的公司，超過5分鐘的outage足以引發financial impact。累公司輸錢！
－Oracle有自我保護機制，過了200s timeout自動reboot出事系統，是比較醒的software。

機制流情圖：