金融行業(yè)存儲設(shè)備升級擴容項目技術(shù)方案

金融行業(yè)存儲設(shè)備升級擴容項目技術(shù)方案

項目總體目標：

隨著信息系統(tǒng)的不斷發(fā)展，全面優(yōu)化整合現(xiàn)有存儲平臺，同時構(gòu)建一個靈活先進的高可用存

儲架構(gòu)，是保障各業(yè)務(wù)系統(tǒng)運行連續(xù)性的基礎(chǔ)。某行進行的存儲設(shè)備升級、整合、擴容項

目，將全面優(yōu)化整合現(xiàn)有存儲平臺，解決存儲單點故障，提升關(guān)鍵數(shù)據(jù)冗余保護，優(yōu)化存儲

系統(tǒng)性能，構(gòu)建靈活先進的高可用存儲架構(gòu)，保障各業(yè)務(wù)系統(tǒng)的運行連續(xù)性。

項目目標細則和策略：

1、消除開放平臺存儲單點的安全隱患，保障生產(chǎn)系統(tǒng)的連續(xù)性運行。

現(xiàn)狀與挑戰(zhàn)：

自2006年來，某行已先后購置了8臺存儲設(shè)備用于核心后臺、13個交易類和8個管理類

應(yīng)用系統(tǒng)開放平臺服務(wù)器使用，2臺存儲設(shè)備用于核心后臺交易，1臺存儲設(shè)備用于核心數(shù)

據(jù)備份，5臺存儲設(shè)備用于開放平臺應(yīng)用系統(tǒng)，中心機房所有存儲設(shè)備均為單點，眾多關(guān)鍵

系統(tǒng)數(shù)據(jù)只有T分，業(yè)務(wù)連續(xù)性和數(shù)據(jù)安全完全依賴單臺存儲的設(shè)備可靠性，根本不能避免

存儲單點故障。存儲設(shè)備一旦發(fā)生無法及時修復(fù)的故障或數(shù)據(jù)丟失，相關(guān)業(yè)務(wù)系統(tǒng)必然遭受

重大影響，RTO遠遠不能滿足監(jiān)管部門要求。

解決目標：

對開放平臺進行整合，通過新購存儲及現(xiàn)有存儲設(shè)備升級，利用軟件或者硬件的方式，將交

易類及管理類系統(tǒng)數(shù)據(jù)存放在2臺物理存儲設(shè)備內(nèi)并實現(xiàn)存儲設(shè)備間的實時數(shù)據(jù)保護，解

決存儲單點安全隱患，將RTO控制在監(jiān)管部門要求的范圍內(nèi)。

2、優(yōu)化整合開放系統(tǒng)存儲平臺，提升存儲性能和可靠性。

現(xiàn)狀與挑戰(zhàn)：

開放平臺現(xiàn)有存儲使用散亂、性能不一，由于業(yè)務(wù)系統(tǒng)上線時間及歷史殘留問題，交易類業(yè)

務(wù)系統(tǒng)所用存儲依舊為低端存儲,如DS6800.DS4700和DS3400等,而管理類業(yè)務(wù)系

統(tǒng)所用存儲卻為中端存儲，如DS8100和V7000,導致交易類系統(tǒng)存儲性能得不到滿足。

同時目前運行時間較長的DS6800/4700/等存儲的故障率呈先上升趨勢，一旦該類存儲故

障宕機，交易類系統(tǒng)則受重大災(zāi)難影響。

解決目標：

通過將開放平臺按照業(yè)務(wù)系統(tǒng)類型調(diào)整存儲分配，遷移交易類/管理類系統(tǒng)至新購或升級存

儲內(nèi)，充分發(fā)揮各存儲性能水平，提高業(yè)務(wù)系統(tǒng)效率；在現(xiàn)有的存儲架構(gòu)之上，搭建基于存

儲虛擬化的整體存儲架構(gòu)，便利未來數(shù)據(jù)遷移、調(diào)整等日常工作，優(yōu)化運維管理工作；充分

利舊現(xiàn)有設(shè)備，將運行時間較長且故障呈現(xiàn)上升趨勢的DS6800/4700等存儲將其轉(zhuǎn)作開發(fā)

測試用途，提升相關(guān)業(yè)務(wù)系統(tǒng)的穩(wěn)定及可靠性的同時并保障現(xiàn)有投資。

3、增強交易、管理類業(yè)務(wù)數(shù)據(jù)的安全保護，解決缺少數(shù)據(jù)存儲備份的問題。

現(xiàn)狀與挑戰(zhàn)：

目前交易類和管理類業(yè)務(wù)數(shù)據(jù)存儲只有一份數(shù)據(jù)，雖然存在集中備份平臺每日對主機系。

統(tǒng)進行在線備份，但備份的頻率仍然較長，且備份覆蓋面和覆蓋率也有很大限度，無法滿足

交易類系統(tǒng)對RPO的要求，一旦存儲故障宕機，有部分數(shù)據(jù)將徹底丟失，備份平臺的數(shù)據(jù)

恢復(fù)也很漫長，RPO較高。

解決目標：

利用存儲整合技術(shù)，實現(xiàn)業(yè)務(wù)數(shù)據(jù)在存儲層面的數(shù)據(jù)在線遷移，并構(gòu)建數(shù)據(jù)的存儲級別冗余

保護，保證交易及管理類系統(tǒng)的所有業(yè)務(wù)數(shù)據(jù)都在兩個不同的存儲設(shè)備存有拷貝，提升數(shù)據(jù)

的安全保護級別，避免單個存儲故障所可能造成的數(shù)據(jù)丟失風險，滿足RPO=0的硬性要

求。

4、項目實施過程盡可能保障業(yè)務(wù)的穩(wěn)定運行和數(shù)據(jù)安全。

現(xiàn)狀與挑戰(zhàn)：

因本次項目涉及到交易類和管理類存儲數(shù)據(jù)的整合，牽涉到存儲與存儲間的存儲復(fù)制或者同

步過程，甚至存在數(shù)據(jù)由存儲遷移至另一存儲的過程，因此，在數(shù)據(jù)遷移過程中，務(wù)必需要

保證數(shù)據(jù)的完整性和數(shù)據(jù)一致性。

解決目標：

由于此次項目牽涉絕大部分某行生產(chǎn)交易類系統(tǒng)和重要管理類系統(tǒng)，所以在項目進行過程

中，需要提前進行各種測試，盡可能在正式上線前排除隱患和問題。對于可能會遇到的風險

點，需要項目實施方專家團隊盡可能多的提前進行提示，全力保障業(yè)務(wù)的穩(wěn)定運行和數(shù)據(jù)安

全。

5、項目盡可能減少業(yè)務(wù)系統(tǒng)的中斷時間。

現(xiàn)狀與挑戰(zhàn)：

本次項目涉及到某行較多的重要交易類系統(tǒng)，環(huán)境復(fù)雜，難度高，在項目實施過程中必然需

要中斷業(yè)務(wù)系統(tǒng)，需要一定的停機時間窗口，對于銀監(jiān)局和人行重點關(guān)注的業(yè)務(wù)系統(tǒng)，需提

前向本地銀監(jiān)局和人行中支進行申請停業(yè)報備，但單個業(yè)務(wù)系統(tǒng)整個停機時間窗口不得大于

4小時。

解決目標：

作為金融企業(yè)，需要嚴格滿足銀監(jiān)局關(guān)于金融企業(yè)業(yè)務(wù)連續(xù)性的要求。因此，為減少業(yè)務(wù)的

中斷時間，在項目實施過程中，需盡可能通過各種手段和方式來避免或減少軟硬件系統(tǒng)的停

頓。對于確實需要停頓系統(tǒng)的操作，需要提前進行合理安排，通過切換備機、一次進行多個

操作等手段來；降低業(yè)務(wù)的中斷時間。

項目所需的具體需求模型(負載模型)及取值說明

某行的開放平臺當前有若干個獨立的SAN網(wǎng)絡(luò),系統(tǒng)所有數(shù)據(jù)由DS3400,DS4700,

DS6800,DS8100與V7000共同進行承載。為解決以上問題，實現(xiàn)項目目標，擬通過

IBMSVC、EMCVPLEX.NETAPPMCC或飛康NSS等存儲虛擬化技術(shù)，對當前的SAN

網(wǎng)絡(luò)和存儲進行整合，利用存儲虛擬化網(wǎng)關(guān)將數(shù)據(jù)遷移到新的目標存儲上，并利用存儲虛擬

化的實時同步鏡像功能提高存儲的高用性。由于虛擬化網(wǎng)關(guān)是本次存儲升級、整合、擴容項

目的核心，因此虛擬化網(wǎng)關(guān)本身的冗余性至關(guān)重要，在項目實施前需要搭建一整套測試環(huán)

境，來模擬各種故障場景，以測試虛擬化技術(shù)的可行性及先進性。整個存儲架構(gòu)模型具體需

求參數(shù)如下：

需求目標一：

服務(wù)器訪問的任一存儲虛擬化網(wǎng)關(guān)的端口的光纖故障，不會導致整體業(yè)務(wù)系統(tǒng)中斷，

RTO-O,RPO=0o

(1)需求原因：用以測驗驗證存儲虛擬化網(wǎng)關(guān)節(jié)點的光纖線斷開對業(yè)務(wù)系統(tǒng)應(yīng)用的影響。

(2)模擬測試條件：存儲虛擬化網(wǎng)關(guān)設(shè)備配置完成、主機端多路徑軟件配置正確、SAN

Switch配置正確。

(3)模擬測試方法：

A、在測試服務(wù)器的測試磁盤上啟動10讀寫。

B、依次斷開/恢復(fù)存儲虛擬化網(wǎng)關(guān)節(jié)點的一根光纖線(一共有四根光纖線用于服務(wù)測試的服

務(wù)器)。

(4)需求結(jié)果：

A、存儲讀寫10短暫中斷。

B、主機端應(yīng)用不受影響。

C、主機端磁盤的某些路徑failed。

D、存儲虛擬化網(wǎng)關(guān)中出現(xiàn)相應(yīng)的event信息。

需求目標二：

任何一個存儲虛擬化網(wǎng)關(guān)節(jié)點發(fā)生故障，不會導致整體業(yè)務(wù)系統(tǒng)中斷，RTO?0,RPO=0o

(1)需求原因：用以測試驗證存儲虛擬化網(wǎng)關(guān)節(jié)點關(guān)機對業(yè)務(wù)系統(tǒng)應(yīng)用的影響。

(2)模擬測試條件：存儲虛擬化網(wǎng)關(guān)設(shè)備配置完成、主機端多路徑軟件配置正確、SAN

Switch配置正確。

(3)模擬測試方法：

A、在測試服務(wù)器的測試磁盤上啟動10讀寫。

B、直接關(guān)閉一個存儲虛擬化網(wǎng)關(guān)節(jié)點。

C、再次將存儲虛擬化網(wǎng)關(guān)節(jié)點開機。

D、直接關(guān)閉一個存儲虛擬化網(wǎng)關(guān)節(jié)點的UPS的電源，模擬外部供電故障。

E、恢復(fù)存儲虛擬化網(wǎng)關(guān)節(jié)點的UPS電源。

(4)需求結(jié)果：

A、存儲讀寫10短暫中斷。

B、主機端應(yīng)用不受影響。

C、主機端磁盤的某些路徑failed。

D、存儲虛擬化網(wǎng)關(guān)中出現(xiàn)相應(yīng)的event信息。

E、在存儲虛擬化網(wǎng)關(guān)的UPS電源關(guān)閉時，存儲虛擬化網(wǎng)關(guān)節(jié)點會迅速將緩存中的數(shù)據(jù)寫

入硬件，并將存儲虛擬化網(wǎng)關(guān)節(jié)點關(guān)機自我保護數(shù)據(jù)。

需求目標三：

存儲虛擬化網(wǎng)關(guān)底層任意一臺存儲發(fā)生故障，整體業(yè)務(wù)系統(tǒng)影響較小，RTO<1分鐘，

RPO=0o

(1)需求原因：用以測試驗證存儲虛擬化網(wǎng)關(guān)的后臺存儲發(fā)生故障時對業(yè)務(wù)系統(tǒng)應(yīng)用的影

響。

(2)模擬測試條件：存儲虛擬化網(wǎng)關(guān)設(shè)備配置完成、存儲虛擬化網(wǎng)關(guān)兩份同步鏡像已經(jīng)完

成，且數(shù)據(jù)完全同步、主機端多路徑軟件配置正確、SANSwitch配置正確。

(3)模擬測試方法：

A、在測試服務(wù)器的測試磁盤上啟動10讀寫。

B、直接關(guān)閉一臺備存儲。

C、將關(guān)閉的備存儲再次開機。

D、在SAN交換機上面將存儲虛擬化網(wǎng)關(guān)與主存儲的zone從配置里移除，模擬主存儲故

障。

E、將存儲虛擬化網(wǎng)關(guān)與主存儲的zone重新加入配置文件并激活。

(4)需求結(jié)果：

A、存儲讀寫10短暫中斷。

B、主機端應(yīng)用不受影響。

C、存儲虛擬化網(wǎng)關(guān)中出現(xiàn)相應(yīng)的event信息。

D、當備存儲恢復(fù)時，數(shù)據(jù)會自動地從主存儲同步到備存儲上；當主存儲恢復(fù)時，數(shù)據(jù)會

自動從備存儲同步到主存儲上。

需求目標四：

整套存儲虛擬化網(wǎng)關(guān)產(chǎn)生故障，整體業(yè)務(wù)系統(tǒng)雖受較大影響，但能快速進行恢復(fù)，RT0<2

小時，RPO=0o

(1)需求原因：用以測試驗證當存儲虛擬化網(wǎng)關(guān)嚴重故障無法使用時，生產(chǎn)系統(tǒng)是否可以

脫離存儲虛擬化網(wǎng)關(guān)直接使用后臺存儲的數(shù)據(jù)。

(2)模擬測試條件：存儲虛擬化網(wǎng)關(guān)設(shè)備配置完成、存儲虛擬化網(wǎng)關(guān)兩份同步鏡像已經(jīng)完

成，且數(shù)據(jù)完全同步、主機端多路徑軟件配置正確、SANSwitch配置正確。

(3)模擬測試方法：

A、將存儲虛擬化網(wǎng)關(guān)集群關(guān)機。

B、在測試服務(wù)器上面強行umount文件系統(tǒng)，varyoffvg。

C、在SAN交換機上面修改zone的配置，使測試服務(wù)器直接訪問備存儲。

D、在備存儲上面修改磁盤的映射關(guān)系，將測試服務(wù)器的磁盤直接映射給測試服務(wù)器。

E、在服務(wù)器上面運行cfgmgr并執(zhí)行varyonvg,mount文件系統(tǒng)。

(4)需求結(jié)果：測試服務(wù)器varyonvg成功，mount文件系統(tǒng)成功，數(shù)據(jù)無丟失。

需求目標五：

存儲虛擬化網(wǎng)關(guān)后臺存儲鏡像關(guān)系切換或拆除，不會導致整體業(yè)務(wù)系統(tǒng)中斷，RTO=0,

RPO=0o

(1)需求原因：用以測試驗證存儲虛擬化網(wǎng)關(guān)后臺存儲鏡像關(guān)系切換或拆除對生產(chǎn)業(yè)務(wù)系

統(tǒng)應(yīng)用的影響。

(2)模擬測試條件：存儲虛擬化網(wǎng)關(guān)設(shè)備配置完成、存儲虛擬化網(wǎng)關(guān)兩份同步鏡像已經(jīng)完

成，且數(shù)據(jù)完全同步、主機端多路徑軟件配置正確、SANSwitch配置正確。

(3)模擬測試方法：

A、在測試服務(wù)器的測試磁盤上啟動10讀寫。

B、切換主存儲和備存儲的主備關(guān)系。

C、拆除備存儲內(nèi)的LUNCOPY。

D、拆除主存儲內(nèi)的LUNCOPY。

(4)需求結(jié)果：

A、服務(wù)器數(shù)據(jù)無丟失。

B、存儲讀寫10訪問正常。

此外，考慮到存儲虛擬化在生產(chǎn)環(huán)境實施過程中，需要針對性的綜合考慮給各類業(yè)務(wù)系統(tǒng)帶

來的影響，避免過長的業(yè)務(wù)中斷時間，尤其是交易類、管理類系統(tǒng)的數(shù)據(jù)不能容忍丟失。根

據(jù)近期二周的調(diào)研，和銀監(jiān)局對商業(yè)銀行業(yè)務(wù)連續(xù)性的要求(RTO,RPO),列表如下：

當前業(yè)務(wù)環(huán)境（2012年）

存儲平臺應(yīng)用名稱數(shù)小單位：T]系統(tǒng)平臺蟀RTO要求RPO要求

DS3400客戶系統(tǒng)數(shù)據(jù)庫0.6AIX管理類1小時0硼

存儲客戶系統(tǒng)ETL0.7Win管理類6小時0硼

新POSP0.8Win交易類30分鐘09

DS4700兩銀數(shù)據(jù)庫服務(wù)器0.8AIX交易類30分鐘09

存儲卡系統(tǒng)2.01.6AIX交易類30分鐘0硼

批量業(yè)務(wù)系統(tǒng)1.6AIX交易類30分鐘0硼

資金營運1.6Win交易類30分鐘0陰

反洗錢2.2Linux1小時09

統(tǒng)一支付2AIX交易類30分鐘0硼

V7000短信平臺0.6AIX交易類30分鐘0金

存儲客戶管理、績效考核5Linux管理類1小時0惻

SAP測試3AIX測也6小時6小時

數(shù)據(jù)平臺測試3AIX測試類6小時6小時

門戶網(wǎng)站0.7Linux管理類30分鐘0捌

信貨省聯(lián)苣0.77AIX交易類30分鐘0硼

綜合前置0.6AIX交易類30分鐘0糊

DS6800客戶系統(tǒng)數(shù)據(jù)庫2.1AIX管理類1小時0糊

存儲信貸SQLSRV0.77Win管理類1小時0硼

中間業(yè)務(wù)AFE0.3Linux交易類30分鐘0硼

核心測試2AS400測酸6小時6小時

財務(wù)系統(tǒng)數(shù)據(jù)平臺3AIX交易類30分鐘09

學管系統(tǒng)SAP1.8AIX交易類30分鐘0硼

DS8100異常信息監(jiān)控1.5AIX管理類1小時0硼

存儲核心業(yè)務(wù)測試7.5AS400測試類6小時3小時

人力資源系統(tǒng)2.2Linux交易類30分鐘0惻

數(shù)據(jù)平告擴容3AIX管理類6小時0硼

另外考慮到整個存儲優(yōu)化、整合、擴容項目的復(fù)雜性，業(yè)務(wù)系統(tǒng)停機中斷，進行存儲架構(gòu)改

造是必不可免的，所以因充分結(jié)合上述表格來合理安排時間，停機時間超過上述系統(tǒng)RTO

要求的，因提前申請，并向本地銀監(jiān)局和人民銀行做停業(yè)申請，申請應(yīng)提前15個工作日。

經(jīng)過調(diào)研，本行的停機時間可安排如下：

月員務(wù)器數(shù)據(jù)量存儲停機時間

財務(wù)系統(tǒng)財務(wù)系僦（據(jù)平臺6T

4,陽

數(shù)據(jù)平臺財務(wù)系統(tǒng)數(shù)據(jù)平臺2T

財管系統(tǒng)財管系統(tǒng)SAP4T

DS81004小時

SAP奧管系統(tǒng)SAP4T

異常信息

異常信息監(jiān)控1.5T2小時

雌

信貸省聯(lián)

信貸省聯(lián)社770G2小時

茸

信貸信貸SQLSRV206

0.22T3小時

SQLSRV信貸SQLSRV205

DS6800

綜合前置主

綜合前置600G3小時

綜合前置備

中間業(yè)務(wù)中間業(yè)務(wù)主

300G4小時

AFE中間業(yè)務(wù)備

兩銀兩銀數(shù)據(jù)庫

800G3小時

數(shù)據(jù)庫兩銀數(shù)據(jù)庫

新POSP主

新POSP800G2小時

新POSP備

卡系統(tǒng)卡系統(tǒng)2.0

1.6TDS47003小時

2.0卡系統(tǒng)2.0

批量代理應(yīng)用

批量業(yè)務(wù)

1.6T4小時

系統(tǒng)批量代理數(shù)據(jù)庫

批量代理數(shù)據(jù)庫

資金運營主

處及1.6T2小時

資金運營備

統(tǒng)一支付統(tǒng)一支付AFA0.7T

3小時

AFA統(tǒng)一支付AFA1T

統(tǒng)一支付統(tǒng)一支付AFE主

0.3T4加

AFE統(tǒng)一支付AFE備

短信平臺

短信平臺600G3小時

短信平臺V7000

反洗錢反洗錢2.2T2小時

客戶管理

客戶管理、儂考核5T2小時

績效考核

門戶網(wǎng)站（外網(wǎng)）portalhost500G

門戶網(wǎng)站4小時

門戶網(wǎng)站（外網(wǎng)）cmshost200G

信貸SQLSRV備崎

1T2小時

SQLSRV1SQLSRV主機新

客戶系統(tǒng)

客戶系統(tǒng)ETL1.3TDS34002小時

ETL

項目的整體架構(gòu)以及組成部分說明

為了達到整個項目的總體目標，其中最主要的部分，即利用存儲整合技術(shù)，來實現(xiàn)業(yè)務(wù)數(shù)據(jù)

在存儲層面的數(shù)據(jù)在線遷移，并構(gòu)建數(shù)據(jù)的存儲級別冗余保護，保證交易類/管理類系統(tǒng)的

所有業(yè)務(wù)數(shù)據(jù)都在兩個不同的存儲設(shè)備存有拷貝，提升數(shù)據(jù)的安全保護級別，避免單個存儲

故障所可能造成的數(shù)據(jù)丟失風險。

（1）當前開放平臺系統(tǒng)整體架構(gòu)圖如下：

DS3400DS4700V7000DS6800DS8100

(2)通過升級后開放平臺系統(tǒng)整體架構(gòu)圖如下:

8轉(zhuǎn)管時類系統(tǒng)AS400"f放平臺潰試13臺交易類系統(tǒng)

(3)整體架構(gòu)方案設(shè)計思路：

1、項目前期準備工作

為確保本次項目能夠有條不紊地進行，需要在項目實施之前，提前不少于兩個月對某行所有

相關(guān)設(shè)備、應(yīng)用、環(huán)境、技術(shù)條件等進行充分調(diào)研，主要內(nèi)容涉及以下7個方面：

(1)調(diào)研某行外圍系統(tǒng)的SAN網(wǎng)絡(luò)交換機配置使用情況。

(2)調(diào)研某行存儲空間的使用分配情況。

(3)調(diào)研某行存儲設(shè)備與各類存儲虛擬化網(wǎng)關(guān)兼容性情況。

(4)調(diào)研某行現(xiàn)有數(shù)據(jù)備份設(shè)施情況。

(5)調(diào)研某行應(yīng)用停機情況。

(6)某行新購設(shè)備的場地、承重、電源規(guī)劃等情況。

(7)某行新購設(shè)備的布線。

2、硬件安裝階段與原有存儲擴容、升級

本次項目存在大量新購設(shè)備，原有設(shè)備由于容量和微碼版本問題也需要進行擴容和升級工

作，主要包含以下5項工作：

(1)新購入的中、高端存儲的硬件設(shè)備上架、安裝與配置工作。

(2)新購入的SAN光纖交換機的硬件設(shè)備上架、安裝與配置工作。

(3)新購入的存儲虛擬化網(wǎng)關(guān)的硬件設(shè)備上架、安裝與配置工作。

(4)提前布置好所需的光纖網(wǎng)絡(luò)。

(5)原有的DS8100和V7000存儲的硬件升級工作，包括硬盤擴容，邏輯配置，和微碼

版本升級工作，以滿足存儲虛擬化網(wǎng)關(guān)的要求。

3、交易和管理類SAN網(wǎng)絡(luò)架構(gòu)優(yōu)化及整合

為確保本次存儲整合項目的順利實施，最為關(guān)鍵的一步即是：對現(xiàn)有SAN網(wǎng)絡(luò)進行整合配

置，接入新購光纖交換機，分別打通交易類和管理類SAN網(wǎng)絡(luò)，為后續(xù)存儲整合實施做好

基礎(chǔ)準備。最終實現(xiàn)核心生產(chǎn)、開放平臺交易、管理和開發(fā)測試四個獨立的SAN網(wǎng)絡(luò)，互

相隔離，便利管理維護。

當前某行一共有各種SAN交換機10臺，分為兩個SAN網(wǎng)絡(luò)，其中，第一個SAN網(wǎng)絡(luò)連

接有IBMDS8100,DS3400,V7000,DS6800及N6060等存儲，網(wǎng)絡(luò)拓撲結(jié)構(gòu)如下：

IBM_2005_B16_3(Prindple)

N6060□QB

XXXJOC^100855B

IBM_2498_B4Q'

IBM_2498_B40_5

107531D

10199LT

DS6800

xxxxx

1

IBM_2498_B4。IBM_2OO5_B16_2(Prinople)

107317R10199ME101087B

第二個SAN網(wǎng)絡(luò)僅連接有IBMDS4700,其網(wǎng)絡(luò)拓撲結(jié)構(gòu)如下：

DS4700

WXXSAXAX-

計劃通過本次SAN網(wǎng)絡(luò)整合實施，整個開放平臺最終SAN網(wǎng)絡(luò)的拓撲圖如下：

IBM_2005_B16_3（Prinapie：＞

1OO855B

IBM_2498_B40p

IBM_2498_B40_5

10753ID

10199U

IBM2005Bl

101828W

IBM_2498_B40IBM_2498_B40IBM_2OO5_B16_2（Principle）

107317R10199ME101087B

在后續(xù)的當存儲虛擬化整合完成后，可以將以前的舊SAN交換機從當前SAN架構(gòu)中移

除，但是保留交易類新購SAN光纖交換機到管理類新購SAN光纖交換機的連線（ISL）,其

拓撲圖如下：

（新購）

（新購）

B80JY_l

B80_GL_l

x2

4、交易和管理類業(yè)務(wù)系統(tǒng)存儲虛擬化整合

接著第二個關(guān)鍵步驟即是：對重要性等級高的13套交易類系統(tǒng)，原先所在的

DS6800/4700/3400/V7000存儲數(shù)據(jù)，將全部遷移整合至新購的兩臺存儲內(nèi)（V7000、

XIV、華為或者DS8800等兩套新購入的存儲），通過硬件或者軟件的方式，實現(xiàn)兩套存儲

間的實時數(shù)據(jù)鏡像；對管理類系統(tǒng)，原先所在的V7000和DS8100存儲數(shù)據(jù)，將全部遷移

整合至升級后的DS8100和V7000存儲（利舊）內(nèi)，通過硬件或者軟件的方式，實現(xiàn)存儲

間的實時數(shù)據(jù)鏡像，從而解決存儲單點故障隱患。優(yōu)化整合完成后，13套交易類系統(tǒng)完全

可以避免存儲的單點故障，而且，通過存儲虛擬化網(wǎng)關(guān)整合后，存儲管理簡單，數(shù)據(jù)遷移也

會非常容易，性能也會改善。需要強調(diào)的是，通過該方案進行優(yōu)化整合后，對目前13套交

易類系統(tǒng)的運行方式不會有任何影響,對操作系統(tǒng)或者應(yīng)用來說,看到的還是一份數(shù)據(jù)，數(shù)

據(jù)復(fù)制是在底層實現(xiàn)的。因此，當其中的一臺存儲發(fā)生故障的時候，切換是自動實時進行

的，用戶基本沒有任何感覺。存儲虛擬化網(wǎng)關(guān)基本工作原理如下圖所示：

StorageAStorageB

整合后的交易及管理類平臺數(shù)據(jù)環(huán)境如下，實現(xiàn)將交易及管理類系統(tǒng)數(shù)據(jù)均遷移至存儲虛擬

化網(wǎng)關(guān)整合管理下的高端存儲（新購）及中端存儲（新購）、V7000（利舊）、DS8100

（利舊）等存儲設(shè)備上，實現(xiàn)存儲間的數(shù)據(jù)冗余保護。

升級后的業(yè)務(wù)環(huán)境（2013年）

數(shù)據(jù)量[單

應(yīng)用名稱系統(tǒng)平臺數(shù)據(jù)類型理存儲平臺

位:T]

新POSP0.8WinDB2交易類

兩銀數(shù)據(jù)庫服務(wù)器0.8AIXOracleRAC交易類

卡系統(tǒng)2.01.6AIXDB2交易類

批量業(yè)務(wù)系統(tǒng)1.6AIXDB2交易類

資金營運1.6WinDB2交易類

統(tǒng)一支付數(shù)據(jù)庫1AIXDB2交易類存儲圜以化網(wǎng)關(guān)+

統(tǒng)一支付AFA0.7AIXFS交易類新購中端存儲+新

統(tǒng)一支付AFE0.3LinuxFS交易類購高端存儲

短信平臺0.6AIXDB2交易類

信貸省聯(lián)社0.77AIXDB2交易類

綜合前置0.6AIXDB2交易類

信貸SQLSRV0.77WinSQLSERVER交易類

中間業(yè)務(wù)AFE0.3LinuxFS交易類

客戶系統(tǒng)ETL13WinDB2管理類

反洗錢2.2LinuxOracle管理類

客戶管理、績效考核5AIXDB2管理類存儲圜以化網(wǎng)關(guān)+

門戶網(wǎng)站0.7LinuxFS管理類現(xiàn)有DS8100+現(xiàn)

財務(wù)系統(tǒng)數(shù)據(jù)平臺3AIXDB2管理類有V7000

財管系統(tǒng)SAP4AIXDB2管理類

異常信息監(jiān)控1.5AIXOracle管理類

SAP測試3AIXDB2測試類

數(shù)據(jù)平臺測試3AIXDB2測試類

DS6800/DS4700

^/臺測試2I5/OS測試類

/DS3400

核心業(yè)務(wù)測試7.5I5/OS測試類

5、剩余存儲全部轉(zhuǎn)入開發(fā)測試環(huán)境，保護原有投資。

最后，對于遷移后的DS6800/4700/3400存儲，本著充分整合、利舊現(xiàn)有存儲，構(gòu)建虛擬

化存儲池的原則，考慮到舊存儲運行年限較長、故障報錯較多、性能較差的情況，將開發(fā)測

試平臺相關(guān)系統(tǒng)數(shù)據(jù)遷移至DS6800/4700/3400等舊存儲內(nèi)，既提升了相關(guān)業(yè)務(wù)系統(tǒng)的可

靠性，又保護了原有投資。

關(guān)鍵技術(shù)難點

難點一：引入存儲虛擬化網(wǎng)關(guān)技術(shù)，如何解決存儲風險集中的問題？

難點分析：

本次項目前所未有的引入了存儲虛擬化網(wǎng)關(guān)技術(shù)，該技術(shù)需要接入在所有存儲前端，業(yè)務(wù)系

統(tǒng)的所有10讀寫流量均需先通過存儲虛擬化網(wǎng)關(guān)，再落入后端存儲陣列中，當網(wǎng)關(guān)可靠性

和穩(wěn)定性不高時，必然帶來風險集中的隱患，一旦網(wǎng)關(guān)故障，帶來的將是全局性災(zāi)難后果。

所以問題的根源是，存儲虛擬化技術(shù)是否足夠強悍，以高可靠的技術(shù)保證，來規(guī)避存儲網(wǎng)關(guān)

帶來的風險集中問題。一旦該體系架構(gòu)中的各個環(huán)節(jié)出現(xiàn)故障風險時，能立即在該體系內(nèi)完

成故障轉(zhuǎn)移，即使造成業(yè)務(wù)系統(tǒng)暫時中斷一段時間，但之后能迅速恢復(fù)，滿足某行對業(yè)務(wù)連

續(xù)性的要求。

解決方案建議：

通過多輪基于存儲虛擬化的存儲架構(gòu)高可用測試，來驗證該技術(shù)的可靠性和穩(wěn)定性。某行針

對IBMSVC虛擬化技術(shù)進行了多輪測試，來探究是否IBMSVC能夠滿足某行的要求。

高可用測試案例I、服務(wù)器訪問的任一SVC的端口的光纖故障

期待結(jié)果：主機端應(yīng)用不受影響，主機讀寫I。短暫中斷，主機端磁盤的某些路徑failed。

第一次測試結(jié)果：該SVC端口的其他冗余端口的光纖接管成功，接管時間約為50秒，該

結(jié)果不滿意。后仔細分析原因，發(fā)現(xiàn)主機端光纖適配器的FSCSI的參數(shù)fjerjrecov設(shè)置

為：為滿足中斷時，盡快切換的目標，將該參數(shù)設(shè)置為：

delayed_fail,10fast_failo

第二次測試結(jié)果：更改主機FCS參數(shù)后，該SVC端口的其他冗余端口的光纖接管成功，接

管時間縮短為20秒。

高可用測試案例2、SVC集群中的任何一介SVC節(jié)點發(fā)生故障

期待結(jié)果：主機端應(yīng)用不受影響，主機讀寫I。短暫中斷，主機端磁盤的某些路徑failed,

在SVC的UPS電源關(guān)閉時，SVC節(jié)點會迅速將緩存中的數(shù)據(jù)寫入硬件，并將SVC節(jié)點關(guān)

機自我保護數(shù)據(jù)。

第一次測試結(jié)果：關(guān)閉SVC的集群中的node3節(jié)點，同一IOGRP中的node4接管成

功，接管時間為65秒。可見接管時間依舊很長，不盡滿意，同樣也是需要修改主機端光纖

卡的FCS參數(shù)。

第二次測試結(jié)果：更改主機FCS參數(shù)后，重啟SVC的集群中的node3,同一IOGRP中的

node4接管成功，接管時間縮短至28秒。同時觀測到，在node3恢復(fù)時，讀寫速度略微

降低，但未造成I。中斷。

高可用測試案例3、SVC集群架構(gòu)體系下的任意一臺存儲發(fā)生故障

期待結(jié)果：主機端應(yīng)用不受影響，當備故障存儲恢復(fù)時，數(shù)據(jù)會自動地從主存儲同步到備存

儲上；當主存儲恢復(fù)時，數(shù)據(jù)會自動從備存儲同步到主存儲上。

第一次測試結(jié)果：

(1)備存儲關(guān)閉，數(shù)據(jù)讀取無影響，其中，恢復(fù)后vdiskmirror并未顯示同步至100%,

需要更改集群參數(shù)為

SVCmirrorwriterpriorityredunanacyo

(2)調(diào)整SANzone配置剔除SVC與主連接，測試寫操作，5分鐘后報錯退出，分析系

由仲裁盤全部在主存儲上丟失引起。

(3)加入備存儲仲裁盤后，調(diào)整SANzone配置剔除SVC與主存儲連接，測試寫操作，

第一次測試失敗，報錯退出；第二次測試，約5分鐘后恢復(fù)，滿足不了需求。

第二次測試結(jié)果：

更改SVC集群mirrorwritepriority參數(shù)為redunancy后：

(1)備存儲模擬故障，反復(fù)進行幾次讀寫測試。備存儲端口禁用后，約60秒鐘后，寫操

作暫停；寫操作暫停后1分鐘，手動運行detectmdisk約50秒至90秒后寫操作恢復(fù)，即

自寫操作暫停至恢復(fù)的時長約為120秒，讀操作僅在一次測試中出現(xiàn)了短暫中斷約40秒，

其他幾次測試中均未出現(xiàn)中斷。

(2)主存儲模擬故障，反復(fù)進行幾次讀寫測試，主存儲zone配置移除后，讀操作立刻暫

停，寫操作約30秒后暫停，1分鐘后手動運行detectmdisk,約80秒后，讀寫操作恢

復(fù)，即自主存儲DS8100調(diào)整引起讀寫暫停后，約2分45秒左右恢復(fù)正常。

第三次測試結(jié)果：

更改SVC集群mirrorwritepriority參數(shù)為latency后：

(1)備存儲模擬故障

多次測試，在備存儲相關(guān)交換機端口禁用后，約半分鐘后，主機端讀或?qū)懖僮鲿霈F(xiàn)短暫中

斷，或速率下降現(xiàn)象，統(tǒng)計結(jié)果，讀寫操作從中斷至恢復(fù)時間間隔為32秒至43秒，滿足

要求。

(2)主存儲模擬故障

主存儲zone配置移除后，讀操作立刻暫停，數(shù)秒后自動恢復(fù)，寫操作未受影響統(tǒng)計結(jié)果，

讀寫操作從中斷至恢復(fù)時間間隔為13秒至35秒，滿足要求。

高可用測試案例4、整套SVC產(chǎn)生故障

期待結(jié)果：當整套SVC嚴重故障無法使用時，生產(chǎn)系統(tǒng)可以脫離SVC直接使用后臺存儲的

數(shù)據(jù)測試服務(wù)器varyonvg成功，mount文件系統(tǒng)成功，數(shù)據(jù)無丟失。

第一次測試結(jié)果：通過SVC后端存儲直接掛載給測試服務(wù)器后，恢復(fù)接管成功，但測試服

務(wù)器在mount文件系統(tǒng)時報錯dirty,后通過fsck修復(fù)成功。

第二次測試結(jié)果：

通過SVC后端存儲直接掛載給測試服務(wù)器后，恢復(fù)接管成功，啟動VG/文件系統(tǒng)均無異

常。

高可用測試案例5、SVC后臺存儲鏡像關(guān)系切換或拆除

期待結(jié)果：服務(wù)器數(shù)據(jù)無丟失，1。訪問正常。

第一次測試結(jié)果：

更改mirrorwritepriority參數(shù)設(shè)置為redunancyo

(1)切換主備存儲角色，包括主存儲切換為備存儲及回切為主存儲整個過程，1。讀寫均無

影響。

(2)拆除備存儲的LUNCOPY,讀操作無影響，寫操作無中斷，但速率下降到5M儂［正

常時約為170M/秒］，約80秒后恢復(fù)。

第二次測試結(jié)果：

更改mirrorwritepriority參數(shù)為latency0

(1)切換主備存儲角色，包括主存儲切換為備存儲及回切為主存儲整個過程，I。讀寫均無

影響。

(2)拆除備存儲的LUNCOPY,10讀寫均無影響。

本項目最終解決方案參考：

以上經(jīng)多場景的反復(fù)測試，可以得出結(jié)論，經(jīng)過各類相關(guān)參數(shù)調(diào)整之后，SVC存儲虛擬化

方案可以較好滿足某行的規(guī)劃需求，即構(gòu)建基于SVC層面的存儲級別鏡像，實現(xiàn)數(shù)據(jù)在線

遷移復(fù)制。基于本次測試結(jié)果，解決該難點的有關(guān)SVC存儲虛擬化配置的具體建議如下：

1、主機相關(guān)光纖卡參數(shù)的修改建議

建議修改主機內(nèi)FSCSI設(shè)備屬性，包括dyntrk和fc_err_recov,默認參數(shù)配置情況下，模

擬SVC端口或節(jié)點故障，主機10暫停時間約為1分鐘左右；修改參數(shù)配置后，模擬SVC

端口或節(jié)點故障，主機10暫停時間縮短至20至30秒，可顯著降低對主機10讀寫的影響

fcerrrecov參數(shù)對10的影響

2、有關(guān)SVC內(nèi)LUNmirrorwriterpriority參數(shù)值的設(shè)定建議

Mirrorwritepriority該參數(shù)用于定義SVC內(nèi)如何配置mirrorwrite算法的優(yōu)先級別，共有

兩個選項值：latency和redundancy,,

latency模式開啟fastfailover功能，SVC會將10請求同時發(fā)送到兩份數(shù)據(jù)拷貝（在我們的

測試場景里，一份數(shù)據(jù)位于DS8100,另外一份位于V7000上），如果數(shù)據(jù)的某份copy寫

延遲了5秒鐘以上，SVC則允許暫時放棄對此份較慢寫入的copy,只要寫入另T分copy

數(shù)據(jù)正常完成，則通知主機端10寫入已經(jīng)完成，并在SVC內(nèi)存維護的數(shù)據(jù)同步位圖中標

識該份數(shù)據(jù)未同步，系統(tǒng)等待約5分鐘后再嘗試對較慢寫入的copy重新同步。如果在

SVC數(shù)據(jù)未同步時，擁有最新數(shù)據(jù)拷貝的存儲出現(xiàn)故障，且所有數(shù)據(jù)無法恢復(fù)，則可能會

出現(xiàn)數(shù)據(jù)丟失的情況。

redundancy模式始終保證兩份copy的數(shù)據(jù)完全一致性，即必須將10同時成功寫入后臺

兩臺存儲，才會通知主機端寫10已經(jīng)完成（在寫入過程中，如果確認某一份數(shù)據(jù)所在的磁盤

已經(jīng)。ffline,則取消對該份數(shù)據(jù)copy的寫入）。如果后臺兩臺存儲性能差異較大時則可能

對應(yīng)用讀寫造成影響，拖慢寫入效率。但是在redundancy模式下，任一時刻，任一存儲

發(fā)生故障，都不會發(fā)生數(shù)據(jù)丟失的情況。如下為在兩種參數(shù)設(shè)置模式下，相關(guān)場景測試的對

比情況

場景Latencyredundancy

時備詢出現(xiàn)故障10暫停時間為32至43秒IO暫停時間為約為2分鐘

模擬主存儲出現(xiàn)故障I0暫停時間為13至35秒IO暫停時間為2分鐘45秒左右

臺詢主切換I0讀寫均無影響I。讀寫均無影響

模擬后臺拆除備存儲LUN讀操作無影響，寫操作無中斷，IO讀寫均無影響

COPY但速率出現(xiàn)短暫時間的下降［由

170M儂降至5M物

結(jié)合參數(shù)說明和測試結(jié)果，選擇latency模式下僅在極特殊情況下（某份COPY寫入的延

遲超過5秒鐘)才會出現(xiàn)短暫的LUNCopy數(shù)據(jù)不同步,正常環(huán)境下VdiskMirror持續(xù)保

持同步狀態(tài)，同時可實現(xiàn)fastfailover,存儲故障情況下主機端I。影響時間為秒級別；而

選擇redundancy模式，因需持續(xù)保持LUNCopy的同步一致,存儲發(fā)生故障后10影響

時間較長(2到3分鐘).

考慮到某行的生產(chǎn)環(huán)境中，DS8100和V7000,以及即將購買的中高端存儲的性能都非常

優(yōu)秀，不會出現(xiàn)寫入延遲達5秒以后的情況，綜合數(shù)據(jù)一致性和故障容錯性的要求，建議

將SVCvdisk的mirrorwriterpriority參數(shù)值設(shè)定為latency。

難點二：引入存儲虛擬化網(wǎng)關(guān)技術(shù)，如何應(yīng)急防范存儲虛擬化網(wǎng)關(guān)整體故障帶來長時間的

RT0?

難點分析：

由于主楣口存儲之間多了一道存儲虛擬化網(wǎng)關(guān)，增加了一道風險關(guān)卡，倘若這道關(guān)卡發(fā)生致

命故障或者軟件層面的BUG,導致整個存儲虛擬化網(wǎng)關(guān)集群宕機，主機再也無法識別存

儲，全行所有外圍交易類系統(tǒng)都將癱瘓，如果此時繼續(xù)等待該網(wǎng)關(guān)能夠修復(fù)，所耗費時間也

是無法估量，帶來的風險后果無法掂量，所以務(wù)必需要一種可靠的應(yīng)急辦法，能夠在存儲虛

擬化網(wǎng)關(guān)癱瘓時，迅速恢復(fù)業(yè)務(wù)系統(tǒng)對存儲的訪問。

本項目最終解決方案參考：

倘若某行選擇了SVC作為存儲虛擬化網(wǎng)關(guān)的選擇，那么在某行外圍交易類和管理類SVC系

統(tǒng)的可靠性設(shè)計中，當SVC本身發(fā)生整體故障時，可以通過修改SAN交換機上的zone配

置，使主機直接訪問交易類新購的中端存儲和管理類V7000,達到快速恢復(fù)的目的。所以

應(yīng)提前在SAN交換槌口V7000.中端存儲上面增加相應(yīng)的配置，以便SVC故障發(fā)生且無

法在短時間內(nèi)修復(fù)時，實現(xiàn)快速響應(yīng)，大幅度縮短RTO時間。包括以下兩個步驟：

(1)在SAN交換機中增加應(yīng)急恢復(fù)的zone配置以及cfg文件，但是不激活；

(2)在交易類中端存儲和管理類V7000中增加相應(yīng)主機的定義及映射關(guān)系；

方案說明：本方案主要是將在交易類中端存儲和管理類V7000上創(chuàng)建主機，并將兩套存儲

上相應(yīng)的vdisk直接映射給主機，由于SAN交換機上主機與兩套存儲的zone并未激活，

主機并不能真正訪問到存儲上的LUN;當SVC出現(xiàn)致命故障/BUG時，可直接將SAN交

換機上主機與兩套存儲的zone快速激活,主機可立即識別到存儲上的LUN,以達到迅速

恢復(fù)業(yè)務(wù)系統(tǒng)的目的。

難點三：存儲虛擬化網(wǎng)關(guān)后端主存儲的選擇問題

難點分析：

某行的外圍系統(tǒng)的管理類應(yīng)用倘若采用SVC存儲虛擬化網(wǎng)關(guān)，建設(shè)完成后數(shù)據(jù)存儲將分布

在一臺DS8100和一臺V7000,根據(jù)原規(guī)劃，我們原先認為DS8100的配置和性能比

V7000更好,推薦將虛擬卷的PrimaryCopy設(shè)置到DS8100上。但是在數(shù)據(jù)同步測試過

程中，我們發(fā)現(xiàn)DS8100的性能沒有達到預(yù)期值，在經(jīng)過研究后，發(fā)現(xiàn)當前DS8100已經(jīng)

發(fā)揮了最大性能，但是與V7000相比，是否有性能差距？該如何進行驗證和測試？所以究

竟如何選擇SVC那套后端存儲做為主存儲是一個難以抉擇的問題。

解決方案建議：

為了解決該難點，某行采用了IBMDiskMagic工具對當前的DS8100和v7000進行了詳

細的評估。

(1)DS8100的性能

打開IBMDiskMagic,General頁面中，選擇IBMDS8100Turbo型號，內(nèi)存設(shè)置為

128G:

在Interfaces中,添加8個4Gb的存儲端口:

漢

圃Modell-DS8100

GeneralInterfaces|OpenDisk|OpenWorkload]

DSSsideServersideCountUtiltoSwitch[%)

Fibre4GbFibre4Gb4N/A

ForaP

arenot

)istance

rXRC

FPRCNotused0N/A

rPPRC|XD/A$ync)Notused0N/A

ThisDSSisnotaRemoteCopyPrimary

Edit

再添加8個8GB的主機端口：

■Modell-DS8100

GeneralInterfaces|OpenDisk|OpenWotkloadj

SewerServerside|DSS$ideCountDistance

OperdFibre4GbFibre4Gb8

Remote

Distance

rXRC

rW/A

rPPRC|XD/A$ync)Notused0N/A

ThisDSSisnotaRemoteCopyPrimaty

Edit

在OpenDisk中，添加一個10個rank的RAID10類型的extentpool:

圃Modell-DS8100

General