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。

機制流情圖：