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

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

方案 1：HP Campuscluster + RAC

方案 2：HP Metrocluster+CA

方案 3：Oracle data guard

方案 1

采用HP的Campuscluster來實現(xiàn)200mm和300mm兩套系統(tǒng)的自動切換，利用Mirrordisk實現(xiàn)兩個site的數(shù)據(jù)同步。該方案的系統(tǒng)架構(gòu)圖如下：

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

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

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

方案 2

采用HP的Metrocluster來實現(xiàn)200mm和300mm兩套系統(tǒng)的自動切換，利用CA實現(xiàn)兩個site的數(shù)據(jù)同步。該方案的系統(tǒng)架構(gòu)圖如下：

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

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

方案 3

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

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

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

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

方案 4

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

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

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

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

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

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

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

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

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

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

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

多易