關於SAN 的設計-最佳的設計

   最近手頭項目接近尾聲，但願花些時間陸續把以往設計經驗分享出來，固然，這僅僅是來自我我的的經驗。

  我會盡可能捨棄些宏觀概念，包括項目潛在效益，成本保護等等，由於我以爲那隻不過是sales 該掌握的。

  SAN最佳的設計：

首先，咱們應該是知道SAN的工做原理，整個SAN架構中個角色的定義，及工做原理，這些是基礎的部分，但也是最關鍵的，若是缺乏對角色工做原理的理解，每每會延長故障的修復時間，設計的優化及性能的發揮。

   簡單來講，一個項目每每涉及到不少的集成商，哪怕承包給某一個集成商，也可能會存在不少不一樣的原廠設備，當一個問題出現時，咱們須要迅速排除，是SAN switch問題？存儲陣列的問題？仍是應用主機的問題？因此，哪怕僅僅是SAN系統中某個設備廠家，對周邊設備工做原理的瞭解，也是相當重要的。

   利用免費的互聯網資源，得到這些知識，是再好不過了。

保持最簡單：

在規劃的結構中，複雜的設計結構每每是智能的，但也會帶來更多的故障隱患，因此在每一個設計中，我一般會偏向，特地的打造一個孤島。

好比：在原有的系統中，每每會存在SAN switch，客戶也是但願設備通通接入switch進行統一管理，隨着角色愈來愈多的接入，switch 故障影響的範圍會逐漸擴大。固然我知道會有冗餘機制解決這個問題。

若是一個用於容錯的組件（不管主動仍是被動），已經發生問題，而咱們的Admin一般會在下次巡檢的過程當中發現此問題，而在巡檢還未開始另外一個組件也出現了問題，那麼咱們的麻煩就來了。一般處於技術限制，成本限制，咱們過多的高可用集中的單獨故障上。

所以，在以往的設計中，若是存儲陣列的端口夠用，我一般會直連在應用服務器上，跨過其它設備角色，固然備用端口也是須要的，用在從此的擴展，可接在SAN switch上面。若是是在一套高可用的構架中，保持最簡單的設計也是通用的。

隔離很重要：

SAN構架中，任何依賴於某個單點設備運行的角色，咱們都應該將它隔離出來，避免由於這個單點設備故障，帶來的全局影響。

SAN架構中，脫離公共網絡，避免非專業人員進行訪問，而後爲多個受權的Admin設置訪問策略。

若是系統部署在一個單獨數據中心（一個房間內），咱們儘量用機架隔離每一個設備。若是部署在樓層之間，咱們儘量用樓層來隔離每一個設備。果是位於兩個區域數據中心，那麼咱們就用區域隔離（在技術容許範圍內）。

配置UPS，避免相同設備接入同一個電路中。

監督與通知：

一般在高可用的架構中，故障會自動切換，可是爲了不跟多問題，咱們須要設置更多的策略，讓Admin及時獲得通知。

知識同步：

確保每一個Admin對系統瞭解的信息都是最新的，這些信息包括最新的升級，及最近一次的更改。

（關於此篇我已寫完，但不包括再次更新）