由于是芯片企業(yè)，系統可靠性是第一位的，一旦停機損失慘重（每小時的損失高達100萬美金，主要是停產的產品銷售額和高昂機器設備的折舊），所以在IT系統上是非常舍得投入的。雖然采用了RAC，但負載全部集中在其中一臺機器上，采購兩臺一樣配置的機器加RAC就是為了在down機時，能零時間切換到另外一臺機器上。

從上圖可以看出，200mm和300mm的MES系統互相隔離，兩個SAN也沒有連接起來?？蛻舻膽貌块T認為，萬一300mm的存儲XP12000壞掉，雖然在200mm的XP12000系統上仍然有數據，但是應用并不能自動切換來訪問，所以提出了系統容災的項目。由于系統大部分是HP的，當然HP被邀請?zhí)峤唤鉀Q方案。另外客戶在其他的系統上還使用了EMC的Symmetrix，有競爭才能獲得更好的價格，同時EMC也對這樣一個大客戶虎視眈眈，所以EMC也參與了方案提交。最后總共提交了三個方案：

方案 1：HP Campuscluster + RAC

方案 2：HP Metrocluster+CA

方案 3：Oracle data guard

方案 1

采用HP的Campuscluster來實現200mm和300mm兩套系統的自動切換，利用Mirrordisk實現兩個site的數據同步。該方案的系統架構圖如下：

方案 1的優(yōu)點：支持Oracle RAC，可以實現在災難時，零時間切換到另外一個site。實施不需要停機。

方案 1的缺點：不支持CA，浪費現有投資；需要將兩個SAN連接起來，讓所有的Server可以訪問兩個存儲，主機利用Mirrordisk同時寫兩邊的存儲，對主機的性能有影響。

本來這是一個不錯的方案，但是由于XP在LUN上已經配置了條帶化Strip（不知道是誰出的主意），Mirrordisk不支持，需要去掉strip，重新劃卷，然后重新安裝Oracle，從磁帶備份恢復數據。這樣不但需要停機1天以上，而且風險極大（客戶的磁帶備份重來沒有做過恢復測試），萬一數據無法恢復將變成一個大事故。

方案 2

采用HP的Metrocluster來實現200mm和300mm兩套系統的自動切換，利用CA實現兩個site的數據同步。該方案的系統架構圖如下：

方案 2的優(yōu)點：對于現有的硬件環(huán)境不需要調整，利用存儲上的CA軟件來實現數據同步對于服務器負載無影響。

方案 2的缺點：由于Metrocluster不支持Oracle RAC，在兩個site間發(fā)生切換時，MESDB數據庫需要reboot。另外由于要去掉RAC，需要系統停機1~2小時。這兩點客戶都無法接受。

方案 3

是由EMC提出的方案。在一個HP的Installbase里要實現容災方案，EMC只能采用基于應用的辦法。具體辦法是增加一臺新的存儲（當然是EMC的啦），然后利用Oracle的Data Guard來同步數據。Data Guard對存儲沒有要求，對于服務器要求是相同的OS和相同的Oracle版本，所以服務器還必須是HP的（EMC也沒有服務器啦，當然不會眼紅）。

方案 3的優(yōu)點：對于存儲沒有要求，廠商無關。

方案 3的缺點：由于Data Guard的數據同步是基于Oracle的Redo Log或Arch Log，增加了主機的負載，而且要通過網絡來傳遞數據，消耗了帶寬；當災難發(fā)生時，所有客戶端必須重新連接備份站點的主機，會有中斷影響；Data Guard運作有兩種方式，同步或異步，同步模式對于主站點的性能影響大（主站點必須得到備份站點的肯定回復才能進行下一步操作），而異步模式可能在災難切換時丟數據；在最初始的數據同步階段，仍然需要系統停機，當兩邊數據一致之后備份站點才能基于日志進行更新。

綜合分析上述三種方案，對于客戶來說，停機都不可避免，不能滿足客戶不停機的硬指標。而且客戶都需要不小的投資，獲得的回報從上面的分析來看，都有很大不如意的地方，ROI不值。所以我們最后建議客戶的方案是方案 4。

方案 4

主要是連通兩個SAN，讓主機都可以訪問兩個存儲，然后在主機上寫一個shell文件，在災難發(fā)生時，系統管理員只需要one click執(zhí)行該Shell文件就可以完成切換。該方案的架構圖如下：

方案 4的優(yōu)點：不需要停機；投資最小。

方案 4的缺點：仍然需要人工參與，不能做到100%自動化。

通過前面的具體分析，我們可以看到，一個DR方案設計需要全面細致的考慮，絕對不是靠廠商的售前技術力量用PPT就做出的方案，否則真到實施環(huán)節(jié)，就悔之晚矣（目標達不到，或投資打水漂）。

當然為什么在這個案例中，我們會碰到各種技術限制將我們陷入兩難境地，最根本是客戶的初始系統設計有很多不夠完美的地方，不夠靈活，投入運行后再要調整就有很多限制。主要的不完美地方如下，希望其他的客戶在系統設計初期找對全系統真正專業(yè)的顧問一起參與：

1. Oracle的RAC一個非常好的feature就是在提供高可靠性的同時，將負荷分擔在cluster內的多臺機器上，提高系統利用率，節(jié)省投資。該案例中客戶在正常狀態(tài)下，只使用了一臺服務器的處理能力，實在浪費。后來由于rp7640的處理能力不夠升級到兩臺同配置的rp8640，浪費更大。采用分擔負載的方案憑空增加一倍的處理能力也許就不需要升級主機了。當然作為芯片行業(yè)，可能會擔心采用分擔負載的方式，一旦故障發(fā)生，負載全部切換到一臺機器時，處理能力不足造成連鎖down機（據說某電力客戶就發(fā)生過該情況，不過是否是RAC的缺陷不確定），不過完全可以將200mm和300mm兩套系統組成一個大的RAC，正常情況下，每個應用的負載各自運行在一臺主機上，這樣三臺主機構成的RAC就可以實現同樣的高可靠性，相比生產環(huán)境，節(jié)省了一臺主機。

2. 生產環(huán)境兩個SAN互相隔離，冠冕堂皇的理由是系統安全，可是造成的存儲孤島限制了系統架構的靈活性。在同一個機房中還用昂貴的CA來同步數據，實在是不經濟的做法。同一個機房也完全不能達到容災的要求（真有火災等天災還不是一毀全毀）。

3. XP12000已經是企業(yè)級的高端存儲，所有的部件都是雙份的，不存在單點故障，無需采用兩套XP，而且采用CA來同步數據，對于每一個XP來說，只有一半的磁盤容量是服務于業(yè)務系統的，數據冗余太大。

4. MES也是一個典型的OLTP應用，每次寫入的數據并不會太多。而XP存儲作為企業(yè)級的高端存儲，完全用VG就可以將數據分散到多個控制器下的多個盤中，實現I/O的并發(fā)，再橫向加上Strip條帶化完全沒有必要（主要原因是一開始設計系統時，對于某些應用的負載估計不足，XP上分配的主機端口不足造成性能不好，沒有找到根本原因之前，想用Strip的方式提高并發(fā)，結果瓶頸不在于此，最后還是增加主機端口解決，但Strip加上后要撤銷可不容易）

5. 整個系統設計中有很多點似乎被廠商忽悠而增大投資的嫌疑：4臺主機兩兩RAC；用昂貴的CA在一個50米不到的距離內來實現數據同步，而且冗余一半的XP磁盤等。

本文是DoSTOR存儲技術論壇精華帖摘錄，更多關注或參與討論請看： http://bbs.doit.com.cn/viewthread.php?tid=51987&extra=page%3D1%26amp%3Bfilter%3Ddigest

多易