在光纖通道結構上正確放置設備
我們正在為我們的光纖通道結構購買一對新的 8Gb 交換機。這是一件好事，因為我們的主數據中心的埠用完了，這將允許我們在兩個數據中心之間執行至少一個 8Gb ISL。
當光纖執行時，我們的兩個數據中心相距約 3.2 公里。幾年來，我們一直在獲得穩定的 4Gb 服務，我非常希望它也能維持 8Gb。
我目前正在研究如何重新配置我們的結構以接受這些新交換機。由於幾年前的成本決定，我們沒有執行完全獨立的雙迴路結構。完全冗餘的成本被認為比交換機故障的不太可能的停機時間更昂貴。這個決定是在我之前做出的，從那以後情況並沒有太大改善。
我想藉此機會讓我們的架構在面對交換機故障（或 FabricOS 升級）時更具彈性。
這是我正在考慮的佈局圖。藍色項目是新的，紅色項目是現有的連結，將被（重新）移動。
（來源：sysadmin1138.net）
紅色箭頭線是目前 ISL 交換機鏈路，兩個 ISL 都來自同一個交換機。EVA6100 目前連接到兩個具有 ISL 的 16/4 交換機。新開關將允許我們在遠端 DC 中有兩個開關，其中一些遠端 ISL 正在轉移到新開關。
這樣做的好處是，每台交換機與另一台交換機之間的距離不超過 2 跳，而將處於 EVA 複製關係中的兩台 EVA4400 之間的距離僅為 1 跳。圖表中的 EVA6100 是一款較舊的設備，最終將被替換，可能會被另一個 EVA4400 替換。
圖表的下半部分是我們大多數伺服器所在的位置，我對確切的位置有些擔心。裡面需要做什麼：
10 台 VMWare ESX4.1 主機
- 訪問 EVA6100 上的資源
一個故障轉移群集（文件伺服器群集）中的 4 台 Windows Server 2008 伺服器
- 訪問 EVA6100 和遠端 EVA4400 上的資源
第二個故障轉移群集中的 2 台 Windows Server 2008 伺服器（Blackboard 內容）
- 訪問 EVA6100 上的資源
2 個 MS-SQL 數據庫伺服器
- 訪問 EVA6100 上的資源，夜間數據庫導出到 EVA4400
1 個 LTO4 磁帶庫和 2 個 LTO4 磁帶驅動器。每個驅動器都有自己的光纖埠。
- 備份伺服器（不在此列表中）假離線到它們
目前，ESX 集群最多可以容忍 3 台（可能是 4 台）主機宕機，然後我們必須開始關閉虛擬機以獲取空間。令人高興的是，一切都打開了 MPIO。
目前的 4Gb ISL 連結還沒有接近我注意到的飽和度。這可能會隨著兩個 EVA4400 的複製而改變，但至少其中一個 ISL 將是 8Gb。看看我從 EVA4400-A 獲得的性能，我非常確定即使有複製流量，我們也很難跨越 4Gb 線路。
4 節點文件服務集群在 SAN1SW4 上可以有兩個節點，在 SAN1SW1 上可以有兩個節點，因為這將使兩個儲存陣列相距一跳。
10 個 ESX 節點讓我有些頭疼。三個在 SAN1SW4 上，三個在 SAN1SW2 上，四個在 SAN1SW1 上是一個選項，我很想听聽關於佈局的其他意見。其中大多數都有雙埠 FC 卡，因此我可以雙執行一些節點。不是全部，但足以讓單個開關失敗而不會殺死所有東西。
這兩個 MS-SQL 盒子需要在 SAN1SW3 和 SAN1SW2 上執行，因為它們需要靠近它們的主記憶體儲，並且 db-export 性能不太重要。
LTO4 驅動器目前在 SW2 上，距離它們的主流 2 跳，所以我已經知道它是如何工作的。這些可以保留在 SW2 和 SW3 上。
我不想讓圖表的下半部分成為全連接拓撲，因為這會將我們的可用埠數從 66 個減少到 62 個，而 SAN1SW1 將是 25% 的 ISL。但是，如果強烈建議這樣做，我可以走那條路。
更新：一些可能有用的性能數據。我有它們，我只是間隔它們對這類問題很有用。
上圖中的 EVA4400-A 執行以下操作：
工作日期間：
- 在文件伺服器集群 ShadowCopy 快照期間，I/O 操作平均低於 1000，峰值達到 4500（持續約 15-30 秒）。
- MB/s 通常保持在 10-30MB 範圍內，ShadowCopies 期間峰值高達 70MB 和 200MB。
在夜間（備份）是它真正快速踩踏的時候：
- I/O 操作平均約為 1500，在數據庫備份期間峰值高達 5500。
- MB/s 變化很大，但在幾個小時內執行大約 100MB，在 SQL 導出過程中大約 15 分鐘以驚人的 300MB/s 執行。
EVA6100 更加繁忙，因為它是 ESX 集群、MSSQL 和整個 Exchange 2007 環境的所在地。
- 白天 I/O 操作平均約 2000 次，頻繁峰值高達約 5000 次（更多數據庫程序），MB/s 平均在 20-50MB/s 之間。峰值 MB/s 發生在文件服務集群上的 ShadowCopy 快照期間 (~240MB/s)，持續時間不到一分鐘。
- 夜間，從凌晨 1 點到凌晨 5 點執行的 Exchange Online Defrag 以 7800（接近於使用此數量的主軸的隨機訪問的側面速度）和 70MB/s 的速度將 I/O Ops 泵入生產線。
如果您有任何建議，我將不勝感激。
抱歉耽擱了。
看看你所擁有的和你想要實現的，我有一些想法，這里首先是一張漂亮的照片……
- 剛才在站點之間使用 8Gbps 連結似乎沒有意義-原因是您受到遠端 4400 上的 4Gbps 埠的限制，您已經獲得了穩定的 4Gbps，而且可用頻寬遠高於實際使用要求- 今天，將其中一個 24x8 開關放在那裡似乎是一種浪費。我會在遠端站點使用兩個 16x4Gb 交換機。
- 我很想將新的 24x8 交換機用作您的主要“核心”交換機——您的大部分流量都是伺服器到 6100 的，新的機器會更快。通過這種方式，您應該會看到一些小的性能提升，因為新交換機具有更大的緩衝區和更低的延遲，而且您可以根據需要選擇將哪些伺服器遷移到 8Gb，換出 6100 時也是如此（ 4600 具有原生 8Gb 埠，但這還不是官方的 ;) )。
- 然後我們進入設計的一部分，我們有兩個選擇；保留或丟棄兩個 16x4Gb 的“中間交換機”——純粹基於埠數。基本上，如果您使用 24x8 交換機作為核心盒，那麼您只有 3 個備用埠（因為您將使用 18 個用於 18 個伺服器，加上 2 個到 6100 和一個 ISL 連結，相當於使用了 21 個）。你可以將本地 4400 連接到 24x8 交換機，為您的磁帶驅動器留出 1 個空閒埠，但剩下的空閒埠為零。我想做的是使用兩個 16x4Gb 的“中間交換機”作為輔助本地交換機來處理本地 4400 和磁帶驅動器，或者如果您願意，也可以處理站點間 ISL 連結 - 儘管您將擁有埠如果您願意，可以在 24x8Gb 交換機上免費從那裡直接執行此操作 - 我沒有展示兩者，因為它們非常相似。
所以這就是我的想法——到處都有調整，但我的總體想法是存在的——如果有任何澄清，請隨時與我聯繫。
