最近手頭項目接近尾聲，希望花些時間陸續把以往設計經驗分享出來，當然，這僅僅是來自我個人的經驗。
我會盡量捨棄些宏觀概念，包括項目潛在效益，成本保護等等，因爲我覺得那只不過是sales 該掌握的。
SAN最佳的設計：
首先，我們應該是知道SAN的工作原理，整個SAN架構中個角色的定義，及工作原理，這些是基礎的部分，但也是最關鍵的，如果缺少對角色工作原理的理解，往往會延長故障的修復時間，設計的優化及性能的發揮。
簡單來說，一個項目往往涉及到很多的集成商，哪怕承包給某一個集成商，也可能會存在很多不同的原廠設備，當一個問題出現時，我們需要迅速排除，是SAN switch問題？存儲陣列的問題？還是應用主機的問題？所以，哪怕僅僅是SAN系統中某個設備廠家，對周邊設備工作原理的瞭解，也是至關重要的。
利用免費的互聯網資源，獲得這些知識，是再好不過了。
保持最簡單：
在規劃的結構中，複雜的設計結構往往是智能的，但也會帶來更多的故障隱患，所以在每個設計中，我通常會偏向，特意的打造一個孤島。
比如：在原有的系統中，往往會存在SAN switch，客戶也是希望設備統統接入switch進行統一管理，隨着角色越來越多的接入，switch 故障影響的範圍會逐漸擴大。當然我知道會有冗餘機制解決這個問題。
如果一個用於容錯的組件（無論主動還是被動），已經發生問題，而我們的Admin通常會在下次巡檢的過程中發現此問題，而在巡檢還未開始另一個組件也出現了問題，那麼我們的麻煩就來了。通常處於技術限制，成本限制，我們過多的高可用集中的單獨故障上。
因此，在以往的設計中，如果存儲陣列的端口夠用，我通常會直連在應用服務器上，跨過其它設備角色，當然備用端口也是需要的，用在今後的擴展，可接在SAN switch上面。如果是在一套高可用的構架中，保持最簡單的設計也是通用的。
隔離很重要：
SAN構架中，任何依賴於某個單點設備運行的角色，我們都應該將它隔離出來，避免因爲這個單點設備故障，帶來的全局影響。
SAN架構中，脫離公共網絡，避免非專業人員進行訪問，然後爲多個授權的Admin設置訪問策略。
如果系統部署在一個單獨數據中心（一個房間內），我們儘可能用機架隔離每個設備。如果部署在樓層之間，我們儘可能用樓層來隔離每個設備。果是位於兩個區域數據中心，那麼我們就用區域隔離（在技術允許範圍內）。
配置UPS，避免相同設備接入同一個電路中。
監督與通知：
通常在高可用的架構中，故障會自動切換，但是爲了避免跟多問題，我們需要設置更多的策略，讓Admin及時得到通知。
知識同步：
確保每個Admin對系統瞭解的信息都是最新的，這些信息包括最新的升級，及最近一次的更改。
（關於此篇我已寫完，但不包括再次更新）