作為業(yè)務(wù)系統(tǒng)的最后一道防線，IT數(shù)據(jù)災(zāi)備中心必須在極端狀況下確保重要業(yè)務(wù)系統(tǒng)穩(wěn)定運行。災(zāi)備方案的出現(xiàn)給業(yè)務(wù)系統(tǒng)提供了完備的數(shù)據(jù)級保護(hù)。然而，傳統(tǒng)的災(zāi)備方案中存在著資源利用率低、可用性差、出現(xiàn)故障時停機時間長、數(shù)據(jù)恢復(fù)慢、風(fēng)險高等問題。數(shù)據(jù)是否安全、業(yè)務(wù)是否連續(xù)運行無中斷成為用戶衡量災(zāi)備方案的關(guān)鍵。作為災(zāi)備方案中的高級別的雙活數(shù)據(jù)中心解決方案，成為應(yīng)對傳統(tǒng)災(zāi)備難題的一把利劍。
傳統(tǒng)的數(shù)據(jù)中心環(huán)境下，災(zāi)備生產(chǎn)中心長年處于休眠狀態(tài)，并不參與前端應(yīng)用的數(shù)據(jù)讀寫工作。如果數(shù)據(jù)中心環(huán)境良好，沒有突發(fā)性災(zāi)難的發(fā)生，災(zāi)備中心資源就一直處于閑置狀態(tài)，造成用戶投資浪費。而在雙活解決方案中，分布于不同數(shù)據(jù)中心的存儲系統(tǒng)均處于工作狀態(tài)。兩套存儲系統(tǒng)承載相同的前端業(yè)務(wù)，且互為熱備，同時承擔(dān)生產(chǎn)和災(zāi)備服務(wù)。這樣不僅解決了資源長期閑置浪費的大問題，還能使數(shù)據(jù)中心的服務(wù)能力得到雙倍提升。
在這樣的背景下，傳統(tǒng)的數(shù)據(jù)災(zāi)備中心越來越不能滿足客戶的要求，用戶希望在成本可控的同時，建立高可靠性、高可用性、高可切換性的雙活數(shù)據(jù)中心。
IBM SVC在雙活數(shù)據(jù)中心建設(shè)的虛擬化存儲解決方案中，有三種主流的雙活基礎(chǔ)架構(gòu)可以滿足我們搭建新形勢下高要求的雙活數(shù)據(jù)中心，值得我們深入探討，分別為：SVC Stretch Cluster、SVCHyperSwap和SVC Local VDM SVC PPRC。這三種架構(gòu)方案針對不同的企業(yè)需求均能發(fā)揮最大的效用，本期專題討論會就是要把這三種架構(gòu)方案聊透徹，講明白，讓企業(yè)在選擇時有所依據(jù)，有的放矢，并充分挖掘自身企業(yè)的思維方式，選擇最適合自身企業(yè)發(fā)展的雙數(shù)據(jù)中心虛擬化存儲解決方案。
在本期討論會上，大家針對“基于SVC的三種主流雙活數(shù)據(jù)中心架構(gòu)”的話題踴躍發(fā)言，提出了許多寶貴的觀點和意見，現(xiàn)在我將分享、各類議題觀點和各類問題及回答進(jìn)行梳理總結(jié)，如有疏漏，還請不吝賜教。
主要分為以下五個方面：
一、三種SVC雙活數(shù)據(jù)中心虛擬化存儲解決方案的架構(gòu)與特性方面
二、多種SVC雙活數(shù)據(jù)中心建設(shè)方案與非SVC方案的對比方面
三、雙活數(shù)據(jù)中心間鏈路與帶寬方面
四、虛擬化云時代，是采用分布式還是集中式管理方面
五、SVC同城容災(zāi)與異地容災(zāi)方面
六、私有云建設(shè)與雙活建設(shè)架構(gòu)、案例方面

總結(jié)格式為：
【方面】
【分享】
【議題】
【觀點】
【問題】
【疑問】
【問題解答】

一、三種SVC雙活數(shù)據(jù)中心虛擬化存儲解決方案的架構(gòu)與特性方面

【分享】SVC Stretch Cluster
SVC Stretch Cluster也就是SVC拉伸式集群架構(gòu)，就是把同一SVC集群中的SVC節(jié)點分散在不同的兩個數(shù)據(jù)中心，它們之間通過光纖鏈路連接，并且需要第三地的仲裁設(shè)備。為了幫助大家深入理解SVC Stretch Cluster，先來理解下SVC Local Cluster：
一套SVC集群最少包含2個節(jié)點，最大8個節(jié)點，兩兩節(jié)點組成一個I/O group，因此一套SVC集群最大可以包含4個I/O group，如下圖所示：

每一個存儲LUN都分配給一個I/O group，你也可以手動轉(zhuǎn)換存儲LUN的I/O group，比如說LUN1屬于I/O group0，當(dāng)I/O group完全不可用時，需要手動轉(zhuǎn)換至I/O group1，因為每一個I/O group均由兩個SVC節(jié)點組成，所以每個存儲LUN均分配給一個優(yōu)先的節(jié)點和一個非優(yōu)先節(jié)點，如下圖所示：

不同的存儲LUN的優(yōu)先節(jié)點可以不一樣，這是SVC集群系統(tǒng)自動負(fù)載和分配的，同一SVC I/O group節(jié)點均衡負(fù)載著存儲LUN，對于讀I/O請求來說，來自于優(yōu)先的SVC節(jié)點，而寫I/O請求在同一I/O group的兩個節(jié)點間同步，一次SVC I/O寫請求，分解為以下5個步驟：
1.主機發(fā)送寫I/O請求至SVC I/O group
2.優(yōu)先的SVC節(jié)點A寫入I/O至緩存，并發(fā)送I/O至同一I/O group的另一SVC節(jié)點B
3.節(jié)點B將寫入I/O至緩存后，并回響應(yīng)至節(jié)點A
4.節(jié)點A收到節(jié)點B的回響應(yīng)后，向主機回響應(yīng)
5.節(jié)點A將緩存寫I/O寫入LUN當(dāng)中
寫I/O流轉(zhuǎn)圖如圖所示：

有人會說了，第5步最后才將緩存數(shù)據(jù)寫入LUN當(dāng)中，那么當(dāng)還沒有寫LUN時，SVC節(jié)點突然斷電了怎么辦？這種情況SVC也是考慮了，每個SVC節(jié)點均配備了UPS電源，可以維持供電，可以保證緩存數(shù)據(jù)正常寫入LUN當(dāng)中。
基于以上這種機制，同一I/O group的兩個SVC節(jié)點是實時同步的，當(dāng)I/O group中的主節(jié)點故障時，另一SVC節(jié)點將接管，并進(jìn)入寫直通模式，并禁止寫緩存，也就是說只有1、5、4三個步驟。
以上是SVC的I/O group在一個數(shù)據(jù)中心的情況，而SVC Stretch Cluster則是將一套SVC集群下的同一I/O group的兩個節(jié)點拉開，分別放在兩個數(shù)據(jù)中心，之前連接SVC的一套存儲，拉開后各放置一套存儲，通過SVC做vdisk鏡像同步。說白了還是同一套SVC集群，同一個I/O group，SVC Local VDM(vdisk mirror)拉開成SVC Stretch VDM，映射給主機的volume還是同一個，這樣一來就不難理解了。SVC、存儲、主機及第三站點光纖連線下圖所示：

對于SVC Stretch Cluster來說，為了防范腦裂，仲裁站點是必需的。首先是configuration node，配置節(jié)點，是配置SVC集群后，系統(tǒng)自動產(chǎn)生的保存著所有系統(tǒng)配置行為的節(jié)點，不能人工更改配置節(jié)點，當(dāng)配置節(jié)點失效后，系統(tǒng)會自動選擇新的配置節(jié)點，配置節(jié)點十分重要，它對SVC節(jié)點仲裁勝利起著決定性作用，仲裁勝利的排序規(guī)則如下：
1.配置節(jié)點
2.距離仲裁站點近的節(jié)點
3.距離仲裁站點遠(yuǎn)的節(jié)點
下圖為SVC Stretch Cluster兩個站點的仲裁配置示意圖：

當(dāng)兩站點間光纖鏈路中斷，第三站點仲裁節(jié)點活動時，腦裂發(fā)生，將通過投票仲裁選舉獲勝的站點，按照上述的仲裁勝利規(guī)則，configuration node位于節(jié)點2，選舉站點2優(yōu)先贏得仲裁，通過站點2恢復(fù)業(yè)務(wù)的正常存儲訪問。

當(dāng)?shù)谌军c仲裁節(jié)點不活動時，不影響主機的正常存儲訪問，但是此時，兩站點間光纖鏈路也中斷了，發(fā)生腦裂，這時因為節(jié)點2為configuration node，它所擁有候選的Quorum將變?yōu)閍ctive Quorum，該Quorum選舉站點2為仲裁勝利站點，通過站點2恢復(fù)業(yè)務(wù)的正常存儲訪問。

另外，SVC版本到了7.2時，又出了一個新功能， 叫做Enhanced Stretched Cluster，這又是什么呢？增強版拉伸集群增強點在哪？之前的Stretched Cluster看似實現(xiàn)了雙活，實則只為數(shù)據(jù)級雙活(SVC VDM)，主機訪問SVC實則只訪問了一個I/O group優(yōu)先節(jié)點，另一非優(yōu)先節(jié)點則只是完成了寫緩存同步的任務(wù)而已，無論是local cluster還是Stretched cluster，實際的讀寫卷操作并未通過非優(yōu)先節(jié)點進(jìn)行，通俗的說就是主備模式（ACTIVE-PASSIVE），由于優(yōu)先節(jié)點是 SVC系統(tǒng)自動分配的，可能會出現(xiàn)一種情況是，主機在站點A，但是存儲卷的優(yōu)先節(jié)點卻在站點B，主拷貝的存儲卻在站點A，主機一直訪問了站點B的SVC節(jié)點，再訪問站點A的存儲，這樣的存儲路徑完全不是最優(yōu)的，對主機I/O性能造成影響，但是這些在Enhanced Stretched Cluster中均得到改善，實現(xiàn)了SVC雙節(jié)點雙站點讀寫雙活，在該版本，元素均賦予site屬性，如SVC節(jié)點、主機、存儲等，不同站點的主機對各自站點的SVC節(jié)點和存儲進(jìn)行讀寫操作，對同一volume來說，站點A的主機訪問站點A的SVC節(jié)點，站點A的存儲，站點B的主機訪問站點B的SVC節(jié)點，站點B的存儲，存儲訪問路徑最優(yōu)，兩個站點的SVC節(jié)點、主機、存儲都同時活動，實現(xiàn)應(yīng)用級雙活（ACTIVE-ACTIVE）,在site模式中，SVC優(yōu)先節(jié)點概念不起作用了，配置了site模式的主機，優(yōu)先訪問活動的同site的SVC節(jié)點和同site的存儲。如下圖所示為讀寫模式下的Enhanced Stretched Cluster 流轉(zhuǎn)圖：
綠色的箭頭為優(yōu)先的讀I/O流轉(zhuǎn)，紅色箭頭為站點2的存儲失效后的讀I/O流轉(zhuǎn)。

綠色的箭頭為優(yōu)先的寫I/O流轉(zhuǎn)，紅色箭頭為站點1/2的存儲失效后的寫I/O流轉(zhuǎn)。

需要注意是，在寫操作時，兩個站點的SVC節(jié)點的緩存是保持同步的，但是不同于SVC LOCAL CLUSTER，整個寫操作的過程中，SVC節(jié)點的寫操作響應(yīng)在寫入緩存后就發(fā)生了，而不需要等待另一SVC節(jié)點寫緩存完成并回復(fù)響應(yīng)，這樣一來，優(yōu)化了整個寫性能，具體過程如下：
1.主機向SVC寫I/O請求。
2.同站點的SVC節(jié)點將寫I/O寫入緩存，并向主機回復(fù)響應(yīng)，同時將寫I/O同步至另一站點的SVC節(jié)點。
3.另一站點的SVC節(jié)點將寫I/O寫入緩存，并回復(fù)響應(yīng)。
兩個站點的SVC節(jié)點陸續(xù)將緩存寫入各自站點的存儲當(dāng)中。

【分享】SVC HyperSwap
說到HyperSwap技術(shù)，在沒有SVC存儲虛擬化方案之前，HyperSwap技術(shù)主要用于IBM高端DS8000系列存儲當(dāng)中，達(dá)到應(yīng)用和存儲的高可用和雙活需求，但是當(dāng)時DS8000系列存儲成本高昂，適用于核心類或者關(guān)鍵類應(yīng)用的跨站點雙活需求，不利于整體性的雙活數(shù)據(jù)中心規(guī)劃和建設(shè)，更別談異構(gòu)存儲的跨中心雙活建設(shè)了。但到了SVC 7.5版本，SVC和V7000都可以支持HyperSwap技術(shù)了，中端存儲的地位瞬間提升了一個檔次，異構(gòu)的各類中端存儲，結(jié)合SVC HyperSwap，都可以實現(xiàn)跨中心的雙活高可用了，那么究竟SVC HyperSwap是什么技術(shù)？先來看看下面這張官方架構(gòu)圖：

從圖中可以看到的是，先從架構(gòu)上：
SVC HyperSwap采用了hyperswap的拓?fù)浼軜?gòu)，最少需要兩個I/O Group，同一I/O Group需要兩個節(jié)點，并在同一個站點，而且很驚喜的發(fā)現(xiàn)，每個站點均有VDISK，主機映射了四個SVC節(jié)點，存儲路徑更多了，冗余性更高了。
而SVC Stretched cluster采用的是stretched的拓?fù)浼軜?gòu)，一個站點一個SVC節(jié)點，最大可達(dá)4個I/O Group，但是同一I/O Group的兩個節(jié)點被分割到兩個站點。兩個站點的存儲通過SVC虛擬化后只有一個VDISK，主機還只是映射兩個SVC節(jié)點。
再從性能上：
SVC HyperSwap利用了更多的資源（包括SVC節(jié)點，線路和SAN交換機端口等），每個站點均含有完全獨立的SVC讀寫緩存，一個站點失效，另一站點也能提供完全的性能，因為讀寫緩存在一站點失效后，不會被DISABLE，兩個站點的讀寫緩存是獨立的兩套，這點特別重要。
而SVC Stretched cluster占用了相對較少資源，能提供更多的VDISK（同一SVC I/O Group VDISK劃分有上限），但是當(dāng)一站點SVC節(jié)點失效后，另一站點的讀寫緩存會被DISABLE，進(jìn)入寫直通模式，性能相對來說會下降，在某些情況下，比如后端存儲性能不夠強，緩存不夠大等。而且主機的存儲訪問路徑會減少一半。
另外一個主要不同點是，SVC HyperSwap有了Volume Groups這樣概念，它能夠?qū)⒍鄠€VDISK組合，共同保持高可用和數(shù)據(jù)的一致性，這對于需要映射多個VDISK的主機來說會有很大幫助，假設(shè)以下場景（主機映射多個VDISK）：
1.站點2失效。
2.應(yīng)用仍然從站點1進(jìn)行讀寫，只在站點1進(jìn)行數(shù)據(jù)更新。
3.站點2恢復(fù)。
4.站點1的VDISK開始同步至站點2的VDISK
5.站點1在VDISK同步時突然失效。
如果主機的多個VDISK沒有配置Volume Groups，主機將很大可能無法通過站點2的數(shù)據(jù)恢復(fù)業(yè)務(wù)，因為站點2的多個VDISK正在被同步，尚未同步完成，它們的數(shù)據(jù)并不在同一時間點，掛在起來無法使用，那么這樣的話只能寄希望于站點1。
但是如果主機的多個VDISK配置成Volume Groups，主機是能通過站點2的數(shù)據(jù)進(jìn)行恢復(fù)的，雖然數(shù)據(jù)尚未同步完成，但多個VDISK間的數(shù)據(jù)一致性是可以保證的，仍然屬于可用狀態(tài)，只不過數(shù)據(jù)不完全而已。
與SVC Stretched cluster類似的是，SVC HyperSwap中的主機、SVC節(jié)點和存儲均被賦予了站點屬性，同時也需要配備第三站點作為防范腦裂的仲裁站點。
接著看下面這張圖：

可以看見，一個hyperswap卷是由以下幾個部分組成：
1.4個VDISK（可以是THICK/THIN/COMPRESSED,也可以被加密）
2.1個ACTIVE-ACTIVE的REMOTE COPY RELATIONSHIP（系統(tǒng)自己控制）
3.4個FLASH COPY MAPS（FOR CHANGE VOLUMES）（系統(tǒng)自己控制）
4.額外的ACCESS IOGROUP（方便IO GROUP FAILOVER）
基于該hyperswap卷技術(shù)，實現(xiàn)了兩個站點VDISK的ACTIVE-ACTIVE。站點1的MASTER VDISK寫入變化時，被寫入站點1的Change Volume中（基于FLASH COPY，變化數(shù)據(jù)寫入快照目標(biāo)卷，原卷數(shù)據(jù)不變）,站點2的AUX DISK寫入變化時，同樣被寫入站點2的Change Volume中。一段時間后，系統(tǒng)自動停止VDISK與Change Volume間的快照關(guān)系，Change Volume將回寫變化數(shù)據(jù)至VDISK，VDISK將通過SVC PPRC（REMOTE COPY）同步變化數(shù)據(jù)至另一站點的VDISK中，之后，站點VDISK又將重新與Change Volume建立快照關(guān)系，與根據(jù)這一原理，不斷往返變化數(shù)據(jù)，保持四份COPY數(shù)據(jù)的同步的關(guān)系，當(dāng)然這些都是SVC hyperswap系統(tǒng)自動完成的，用戶無需干預(yù)。
另外，在hyperswap的卷復(fù)制ACTIVE-ACTIVE關(guān)系中，我們可以看到依然存在MASTER或者AUX的標(biāo)簽，對于主機來說，兩個站點的其中一個I/O Group的VDISK是作為PRIMARY，提供讀寫，所有讀寫請求必須經(jīng)過該I/O Group，然而hyperswap會自動決定是本站點的I/O Group的VDISK作為PRIMARY，還是主要承擔(dān)I/O流量的I/O Group的VDISK作為PRIMARY。在首次創(chuàng)建hyperswap卷和初始化后，被標(biāo)簽為MASTER的VDISK作為PRIMARY，但是如果連續(xù)10分鐘以上主要I/O流量是被AUX的VDISK承擔(dān)，那么系統(tǒng)將會轉(zhuǎn)換這種MASTER和AUX的關(guān)系，從這點上也可以看出與SVC Stretched cluster的不同，雖然SVC節(jié)點一樣被賦予站點屬性，但SVC hyperswap在另一站點仍然活動時，不局限于只從本地站點讀寫，它會考量最優(yōu)存儲訪問I/O流量，從而保持整個過程中主機存儲讀寫性能。另外需要注意的是主要的I/O流量是指扇區(qū)的數(shù)量而不是I/O數(shù)量，并且需要連續(xù)10分鐘75%以上，這樣可以避免頻繁的主從切換。
上面講了這么多，那么SVC hyperswap的讀寫I/O又是如何流轉(zhuǎn)的呢？
讀I/O見下圖：

可以看到，每個站點第一次HyperSwp初始化后，先各自從各自站點的SVC節(jié)點讀操作，綠色線為讀操作I/O流轉(zhuǎn)。
寫I/O見下圖：

可以看到，圖中顯示為站點1的主機一次寫I/O全過程：
1.主機向本站點1的其中一個SVC節(jié)點發(fā)送寫I/O請求。
2.該SVC節(jié)點2將寫I/O寫入緩存，并回復(fù)主機響應(yīng)。
3.該SVC節(jié)點2將寫I/O寫入節(jié)點1緩存，并同時發(fā)送寫I/O至站點2的節(jié)點3和節(jié)點4。
4.SVC節(jié)點1、3、4回復(fù)節(jié)點2的響應(yīng)。
5.兩個站點的SVC節(jié)點分別將緩存寫入各自站點的存儲當(dāng)中。

【分享】SVC Local VDM SVC PPRC
上面通過大量篇幅介紹了SVC Stretched Cluster和SVC HyperSwap，這兩種存儲虛擬化雙活數(shù)據(jù)中心解決方案均為ACTIVE-ACTIVE模式SVC方案，那么SVC Local VDM SVC PPRC又是什么？SVC Local VDM即本地SVC VDISK MIRROR，跟Stretched Cluster方案采用了類似的存儲復(fù)制技術(shù)，只不過是本地非跨站點的VDM，又跟SVC HyperSwap方案采用了相同的SVC PPRC遠(yuǎn)程復(fù)制和Consistency一致性組技術(shù)，而且對SVC的版本沒有很高的要求，SVC 6.4版本就可以實現(xiàn)，可以說是另外兩種技術(shù)的爸爸，另外兩種技術(shù)均是由它演變升級而來，既然是較老的技術(shù)，為什么還要再這里談呢？還不是ACTIVE-ACTIVE，只是ACTIVE-STANDBY。
當(dāng)然有必要，有以下幾個必要點：
1.利用SVC Local VDM SVC PPRC可以實現(xiàn)本地雙同步數(shù)據(jù)保護(hù) 災(zāi)備同步數(shù)據(jù)保護(hù)，還很容易實現(xiàn)異地異步數(shù)據(jù)保護(hù)。充分保護(hù)本地級存儲數(shù)據(jù)，和本地可靠性。
2.結(jié)合PowerHA EXTEND DISTANCE(PowerHA XD)很容易實現(xiàn)本地雙主機 災(zāi)備主機熱備。本地主機故障，本地主機互相切換，本地雙主機故障，主機和存儲均切災(zāi)備主機和存儲，十分靈活，可將不同系統(tǒng)的主機分別布署在兩個數(shù)據(jù)中心。兩個數(shù)據(jù)中心均各自承擔(dān)些許業(yè)務(wù)。
3.無需第三站點仲裁，第三站點對于大部分企業(yè)來說，都基本相當(dāng)于虛設(shè)，怎么說呢，第三站點基本都放置于本地站點，本地站點故障時，第三方站點和本地站點相當(dāng)于全部故障，需要人為干預(yù)，才能在災(zāi)備站點恢復(fù)業(yè)務(wù)，復(fù)雜度高。如果真正建立第三站點，又需要增加大量成本。
4.無需擔(dān)心雙中心間光纖光衰、線路延時、抖動甚至中斷，充分保護(hù)本地站點系統(tǒng)的可靠性。發(fā)生腦裂時，基于HACMP XD，生產(chǎn)端的主機數(shù)多于災(zāi)備站點，發(fā)生腦裂仲裁時，生產(chǎn)站點總是會贏得仲裁勝利，將自動關(guān)閉災(zāi)備站點主機，生產(chǎn)站點不受任何影響。對于這種情況來說，如果是ACTIVE-ACTIVE方式的腦裂情況，特別是在將所有各類異構(gòu)存儲均接入SVC，通過兩站點間SVC復(fù)制，腦裂現(xiàn)象的影響面將擴(kuò)大至整個數(shù)據(jù)中心業(yè)務(wù)層面，而不是僅僅小部分業(yè)務(wù)造成中斷。
那么，有人會說，題目是雙活數(shù)據(jù)中心建設(shè)，SVC Local VDM SVC PPRC不應(yīng)該算是一種雙活建設(shè)方案，只是實現(xiàn)了數(shù)據(jù)級存儲雙活。其實不然，利用該架構(gòu)，實則實現(xiàn)了雙活中心的基礎(chǔ)架構(gòu)，應(yīng)用層雙活可以通過配合軟件架構(gòu)的方式來實現(xiàn)，具體內(nèi)容將在“雙活數(shù)據(jù)中心建設(shè)系列之---基于軟件架構(gòu)的雙活數(shù)據(jù)中心建設(shè)方案深入探討”主題中詳細(xì)探討。先來看下該SVC方案的架構(gòu)，如圖所示：

可以看到，該方案需要兩套SVC集群，最少需要2個I/O Group，4個節(jié)點，本地和災(zāi)備各一套SVC集群，一個I/O Group，兩個節(jié)點。該架構(gòu)與HyperSwap架構(gòu)有點類似，不同的是該架構(gòu)本地站點的存儲有兩個，災(zāi)備站點存儲為1個，本地站點兩個存儲通過SVC做VDM，本地站點和災(zāi)備站點存儲通過兩套SVC做SVC PPRC，實現(xiàn)了三份存儲數(shù)據(jù)實時同步。本地站點兩主機掛載本地站點的存儲，災(zāi)備站點主機掛載災(zāi)備站點的存儲，三臺主機通過HACMP XD（基于SVC PPRC）實現(xiàn)跨站點高可用，當(dāng)本地站點的主機故障時，自動切向本地備機，業(yè)務(wù)中斷時長5分鐘以內(nèi)，具體根據(jù)HACMP切換時長；當(dāng)本地站點主備機全部故障時，本地存儲和本地主機均自動切向災(zāi)備主機，業(yè)務(wù)中斷時長5分鐘內(nèi)，具體根據(jù)HACMP切換時長；本地一臺備存儲故障時，完全不受影響；本地一臺主存儲故障時，自動切往本地備存儲，業(yè)務(wù)I/O中斷1分鐘以內(nèi)。
另外，該架構(gòu)的數(shù)據(jù)讀寫流轉(zhuǎn)在上面的SVC LOCAL CLUSTER中已經(jīng)詳細(xì)介紹，只是多了在SVC I/O Group節(jié)點間寫同步后，再同步一份寫I/O至災(zāi)備I/O Group的兩節(jié)點，這里不再贅述。

【議題1】SVC HyperSwap和SVC Stretch Cluster做為A-A模式的SVC虛擬化存儲解決方案，有何缺陷或者風(fēng)險？
【觀點1】hyperswap不適合rac這種跨站點讀寫的雙活
【觀點2】據(jù)我了解到ESC模式下的iogroup并不是真正的冗余模式。比如我有兩個iogroup，所有的業(yè)務(wù)都在iogroup1上，當(dāng)?shù)谝粋€iogroup的兩個節(jié)點都宕機的話前端業(yè)務(wù)也就中斷了，業(yè)務(wù)并不會自動切換到iogroup2上。
【觀點3】對的，SVC ESC只有兩個節(jié)點，兩個節(jié)點同時故障時，需要手動干預(yù)才能恢復(fù)業(yè)務(wù)，所以為了更高、更苛刻的冗余時，出現(xiàn)了SVC HYPERSWAP，但是實際情況兩個SVC節(jié)點同時故障的情況還是非常少。
【觀點4】還是需要看業(yè)務(wù)類型，比如oracle rac，dg，vmware等，不一樣的業(yè)務(wù)要求不同。
【議題2】SVC Local VDM SVC PPRC作為A-S模式的SVC虛擬化存儲解決方案，有何缺陷或者風(fēng)險？
【觀點1】SVC Local VDM是作為本地高可用的解決方案，缺陷或者風(fēng)險來講如果同SVC PPRC只是作為本地數(shù)據(jù)高可用，無法做到容災(zāi)級別。
SVC PPRC是解決站點級別的災(zāi)備解決方案,所謂的缺陷是要跟誰去對比。比如作為存儲復(fù)制解決方案跟數(shù)據(jù)庫復(fù)制方案比，各有優(yōu)缺點。
【觀點2】SVC Local VDM SVC PPRC做為數(shù)據(jù)級本地保護(hù)和容災(zāi)，結(jié)合HACMP只是ACTIVE-STANDBY，像數(shù)據(jù)庫級別的復(fù)制，主要還是事物級別的TCPIP同步，性能和效率當(dāng)然沒有SVC VDM和PPRC高，但是一致性從事物層得到了保證，但是數(shù)據(jù)庫復(fù)制技術(shù)也是有限制的，它主要是通過事物日志復(fù)制和對端重寫來實現(xiàn)，但日志有時候也不能覆蓋全部數(shù)據(jù)庫操作，比如XML和LOB格式的字段，是沒法通過日志復(fù)制傳輸?shù)?，有些?yīng)用為了執(zhí)行效率高，對數(shù)據(jù)庫采取了不記日志操作。

【問題1】
【疑問一】SVC的ESC拉伸雙活模式Lun是否可以就近讀寫？hperswap模式是否可以就近讀寫？SVC的ESC拉伸雙活模式Lun是否可以就近讀寫？hperswap模式lun是否可以就近讀寫？還是只能讀對端lun？造成這個問題的原因是什么？
【問題解答一】SVC StretchCluster與SVC HyperSwap的最大特性就是SVC節(jié)點“站點化”，主機節(jié)點“站點化”，存儲節(jié)點“站點化”，所以這兩種模式都是同一站點的主機讀寫同一站點的SVC的節(jié)點，SVC節(jié)點讀寫同一站點的存儲節(jié)點。
所以這兩種ACTIVE-ACTIVE存儲雙活方案，是就近讀寫的，另外SVC HyperSwap不僅僅是就近讀寫，如果本地站點的IO流量連續(xù)10分鐘低于25%，而對端站點的IO流量連續(xù)10分鐘高于75%，那么SVC HyperSwap將反轉(zhuǎn)讀寫關(guān)系，優(yōu)先讀寫對端站點。
【疑問二】感謝解答，但我認(rèn)為hyperwap雙活模式下，不可以就近讀寫。兩個站點都要去找該lun的owner站點去寫，然后鏡像到另一端緩存。因SVC與vplex的全局一致緩存不同SVC的hperswap是兩套緩存表。正式因為這種情況，導(dǎo)致會有主機頻繁寫對端lun的情況出現(xiàn)，導(dǎo)致lun owner關(guān)系反轉(zhuǎn)。 不知道我的看法是否正確？謝謝
【問題解答二】不對，1.SVC hperswap雖然是兩套緩存表，但是緩存與緩存的同步是在SVC節(jié)點間進(jìn)行的，與主機無關(guān)，主機只是讀寫同站點的SVC節(jié)點和存儲，不會去讀寫另一站點的SVC節(jié)點，當(dāng)主機寫同站點的SVC節(jié)點后，SVC立即返回響應(yīng)，表明已經(jīng)完成寫操作，剩余的緩存同步和落盤的事情由SVC內(nèi)部完成。
2.SVC hperswap架構(gòu)，每個站點都有各自的MASTER和AUX VDISK，主機優(yōu)先讀寫MASTER VDISK，直到主機出現(xiàn)連續(xù)10分鐘75%以上的I/O讀寫在AUX VDISK上，AUX和MASTER的關(guān)系將反轉(zhuǎn)，基于這樣一種機制，MASTER和AUX的關(guān)系不會不停的反轉(zhuǎn)，而是既控制住了反轉(zhuǎn)頻率，又在MASTER VDISK站點出現(xiàn)性能問題時，能夠及時反轉(zhuǎn)關(guān)系，提升性能。
【問題2】
【疑問一】數(shù)據(jù)不完全，如何實現(xiàn)數(shù)據(jù)可用？
請問：'但是如果主機的多個VDISK配置成Volume Groups，主機是能通過站點2的數(shù)據(jù)進(jìn)行恢復(fù)的，雖然數(shù)據(jù)尚未同步完成，但多個VDISK間的數(shù)據(jù)一致性是可以保證的，仍然屬于可用狀態(tài)，只不過數(shù)據(jù)不完全而已。'既然數(shù)據(jù)不完全，然后和實現(xiàn)可用？
【問題解答】1.多個VDISK配置成了Volume Groups的形式，那么兩個站點的多個VDISK的一致性是同時的，也就是說站點1的多個VDISK同時寫，站點2相應(yīng)的多個VDISK寫也是同時寫的，這樣一來，每次站點2的多VDISK寫入后，從存儲視角來說，多VDISK是數(shù)據(jù)一致性的，站點2的主機是能利用這一致性的多個VDISK的，在允許數(shù)據(jù)一定丟失的情況下，即使同步?jīng)]有完成，還是可以利用的。而如果是主機擁有多個VDISK，但是這多個VDISK不配置成Volume Groups的話，兩個站點僅僅是單個VDISK是一致性的，站點2的多個VDISK的同步時間戳不一樣，不能保證多VDISK同時是一致性的，如果同步?jīng)]有完成，那么站點2可能無法利用這些VDISK。
2.存儲的一致性組是建立在存儲視角的，假如是數(shù)據(jù)庫的話，更好的辦法是從數(shù)據(jù)庫事物的層面保持一致性，但是當(dāng)今存儲沒有誰能做到這一點。
【疑問二】還是沒太明白，數(shù)據(jù)不完全跟數(shù)據(jù)可用如何理解？
【問題解答】主機對文件系統(tǒng)的一次寫是對多個PV分別寫，對吧？該站點的PV與站點2的PV同步時，如果沒有配置同步卷組是不是同步有先有后？有可能這個卷已經(jīng)同步了，那個卷還沒有同步，那這時，站點1故障了，站點2的這些存儲卷是不是得有邏輯錯誤了？是不是不可用了？那如果配置了同步卷組，站點2的的多個PV是一起同步的，本地站點的多個卷一次寫操作，站點2的多個卷也是一起寫的，是不是就是一致性卷組了？當(dāng)站點1故障了，即使站點2還沒有完全同步完，這些一致性卷組是不是沒有邏輯問題了？是不是可用的？
【問題3】
【疑問一】IBM svc ESC和 hyperswapcache工作模式和lun的讀寫訪問方式區(qū)別？EMC vplex的顯著區(qū)別是什么？IBM svc ESC和 hyperswapcache工作模式和lun的讀寫訪問方式區(qū)別？我們都知道EMC vplex metro是全局一致性緩存，緩存形式的不同，SVC和vplex在雙活特性上帶來了哪些不同？
【問題解答一】緩存形式的不同，VPLEX沒有寫緩存，這就意味著寫性能會有一定的影響
【問題解答二】1.IBM svc ESC是SVC LOCAL CLUSTER的跨站點拉伸版，主要是利用了VDM的技術(shù)和原理，而SVC hyperswap主要利用了FLASH COPY和SVC PPRC技術(shù)和原理；SVC ESC緩存同步是在同一I/O GROUP的兩個節(jié)點進(jìn)行，而SVC HYPERSWAP既有同一I/O GROUP又有不同I/O GROUP的兩個節(jié)點緩存同步
2.IBM svc ESC和SVC hyperswap讀寫方式均是就近原則，本站點讀寫本站點的SVC節(jié)點和存儲。但SVC hyperswap較高級的地方在于，它會判斷兩個站點的讀寫I/O流量，如果某個站點I/O流量連續(xù)10分鐘占比75%以上，那么它將反轉(zhuǎn)MASTER VDISK和AUX VDISK的角色。
3.EMC vplex metro是全局一致性緩存，但它沒有寫緩存，雖然都是各自站點就近讀寫，但是增加了后端存儲壓力，寫性能上可能會受影響。舉例來說，像SVC FLASH存儲，在關(guān)閉了SVC寫緩存的情況下，整個性能沒有打開SVC寫緩存高。
【疑問二】據(jù)我了解到ESC具有就近讀寫功能，HyperSwap沒有這個功能吧？
【問題解答】兩個都有就近讀寫功能，HYPERSWAP所需的SVC版本還比SVC ESC高，把SVC節(jié)點、存儲和主機都站點化了，有更多的節(jié)點冗余和更多的性能優(yōu)化。
【疑問三】PPRC是啥玩意？
【問題解答】point-to-point remote copy，也就是metro-mirror
【問題4】
【疑問一】SVC HyperSwap 和SVC Stretched Cluster適合哪些場景？
SVC HyperSwap 和SVC Stretched Cluster適合哪些場景？哪些場景選擇SVC HyperSwap 更有優(yōu)勢？二者的性價比如何？
【問題解答一】首先這兩者都是高可用解決方案中的兩個技術(shù)代表
SVC HyperSwap可以說是對 SVC esc 技術(shù)靈活性的補充或者說是增強
具體來說V7K V5K 是無法做到的ESC的，同樣IBM V9000也無法做到ESC.
而hyperswap技術(shù)對 V7K V5K V9000開啟了大門，使這些產(chǎn)品也有高可用的特性。
【問題解答二】樓上正解，如果是沒用SVC，僅僅用hyperswap技術(shù)，那么性價比肯定是V7K V5K V900之類的更高，只用存儲就實現(xiàn)了跨中心存儲雙活。
如果用了SVC，hyperswap用了4個以上的SVC節(jié)點，Stretched Cluster只用了兩個，但是hyperswap的性能和可靠性較Stretched Cluster有所增強，但Stretched Cluster又能擴(kuò)展到今后的異地災(zāi)備，如果簡單的以價格來區(qū)分兩者的化，那么首選Stretched Cluster，如果要綜合比較的話，兩者真的不相伯仲，要看你的需求。
如果你不關(guān)心價格，就是要最好的高可用，最好的性能優(yōu)化，對劃分的卷上限1024也可以接受的，不要求將來實現(xiàn)擴(kuò)展同城或者異地災(zāi)備的，運維技術(shù)也能保障，那就推薦hyperswap，如果你關(guān)心價格，對性能和高可用要求不那么苛刻，將來想實現(xiàn)異地或者同城災(zāi)備擴(kuò)展的，那么推薦Stretched Cluster，但是SVC hyperswap和SVC Stretched Cluster都要求有第三站點仲裁，而且對兩個站點間的鏈路的穩(wěn)定性、可靠性、性能要求很高。
【疑問二】你好，esc用兩個節(jié)點就夠了嗎，我看了一個文檔，esc也推薦最少4個節(jié)點，2個為1個iogroup。4個節(jié)點比兩個節(jié)點的優(yōu)勢有哪些呢？
【問題解答三】ESC最少兩個節(jié)點，在主機較多、SVC節(jié)點負(fù)載較大的情況下，推薦4節(jié)點，甚至6節(jié)點、8節(jié)點，將I/O讀寫分散于不同的I/O GROUP上，如果僅僅是1個I/O GROUP，那么所有主機均通過這個I/O GROUP讀寫存儲，是否負(fù)載能滿足，是需要考慮的。從冗余上來說，1個I/O GROUP和2個I/O GROUP都是一樣的。都是靠同一I/O GROUP的兩個SVC節(jié)點來冗余的。
【問題5】
【疑問】V7000 HYPERSWAP實施請教
HyperSwap中如何保證數(shù)據(jù)的一致性嗎？是如何配置的呢？
看到論壇里面說到SVC hyperswap通過VOLGRP數(shù)據(jù)的一致性，但是我在實施V7K （7.7.1.3）hyperswap時候，GUI中沒看到volume group。
【問題解答】建議從CLI中配置HYPERSWAP
1.創(chuàng)建一致性組
例如：mkrcconsistgrp –name hsConsGrp0
2.創(chuàng)建master vdisk
例如：mkvdisk –name hsVol0Mas –size 1 –unit gb –iogrp 0 –mdiskgrp siteA-ds8k -accessiogrp 0:1
3.創(chuàng)建AUX vdisk
例如：mkvdisk –name hsVol0Aux –size 1 –unit gb –iogrp 1 –mdiskgrp siteB-ds8k
4.創(chuàng)建Change vdisk
例如：mkvdisk –name hsVol0MasCV –size 1 –unit gb –iogrp 0 –mdiskgrp siteA-ds8k -rsize 0% -autoexpand
例如：mkvdisk –name hsVol0AuxCV –size 1 –unit gb –iogrp 1 –mdiskgrp siteB-ds8k -rsize 0% -autoexpand
5.創(chuàng)建relationship
例如mkrcrelationship –master hsVol0Mas –aux hsVol0Aux –cluster testCluster -activeactive –name hsVol0Rel
6.開始同步
例如：mkrcrelationship –master hsVol0Mas –aux hsVol0Aux –cluster testCluster -activeactive –name hsVol0Rel –sync
或者7.創(chuàng)建relationship并加入一致性組
例如：mkrcrelationship –master hsVol0Mas –aux hsVol0Aux –cluster testCluster -activeactive –name hsVol0Rel –consistgrp hsConsGrp0
或者8.創(chuàng)建relationship并加入一致性組同步
例如：mkrcrelationship –master hsVol0Mas –aux hsVol0Aux –cluster testCluster -activeactive –name hsVol0Rel –consistgrp hsConsGrp0 -sync
9.建立master和AUX的VDISK與對應(yīng)change vdisk的relationship
chrcrelationship –masterchange hsVol0MasCV hsVol0Rel
chrcrelationship –auxchange hsVol0AuxCV hsVol0Rel
完成
【問題6】
【疑問】SVC主流雙活方式之一Stretch Cluster的實現(xiàn)方式
Stretch Clustr，也叫拉伸式集群，在該模式下，本地的A，B站點是雙活的，遠(yuǎn)程C站點可以用Global Mirror實現(xiàn)兩地三中心，請專家通過實例講解這種雙活方式實現(xiàn)雙活的原理以及這種方式有沒有風(fēng)險？
【問題解答】1.實現(xiàn)雙活原理：
svc stretch cluster是SVC LOCAL CLUSTER的拉伸版，其實現(xiàn)原理和技術(shù)主要是SVC VDM，它需要最少一套I/O GROUP，兩個SVC節(jié)點作為需求，每個站點的主機均讀寫各自站點的SVC節(jié)點和存儲，對于寫操作來說，先寫某個SVC節(jié)點的緩存，再將該緩存同步至另一站點的SVC節(jié)點中，最后分別落盤，在另一站點的主機寫操作也是同樣，為了保證兩邊存儲寫數(shù)據(jù)的一致型，不導(dǎo)致臟讀，SVC用了鎖排斥技術(shù)。另外SVC利用在雙活的基礎(chǔ)上，利用Global Mirror技術(shù)可以將SVC的數(shù)據(jù)異步地同步至異地站點的V7000、SVC等中。
2.風(fēng)險
伴隨著雙活，風(fēng)險也是當(dāng)然的，沒有哪一種技術(shù)是十全十美的，按照企業(yè)的需求都有用武之地，SVC Stretch cluster的風(fēng)險在于同一I/O GROUP只有兩個SVC節(jié)點，本地一個，災(zāi)備一個。本地SVC節(jié)點故障，則切往了災(zāi)備SVC節(jié)點，冗余度來說，本地有點單點的感覺；另外SVC Stretch cluster對兩個站點間的鏈路要求很高，需要穩(wěn)定度高，時延和抖動盡量小，如果兩中心間鏈路中斷，那么兩個中心的SVC節(jié)點讀寫將HOLD住，直到第三站點仲裁選舉出勝利站點，如果所有業(yè)務(wù)主機均通過SVC節(jié)點訪問存儲，所有業(yè)務(wù)將有一段時間被中斷，中斷時間取決于兩個站點間距和仲裁時間。
【問題7】
【疑問】在一套SVC集群的，節(jié)點之間的緩存數(shù)據(jù)同步是通過什么途徑進(jìn)行的？是管理網(wǎng)絡(luò)？是san存儲？是fc鏈路？
【問題解答】通過fc鏈路。節(jié)點間通信走cluster zone內(nèi)的端口，或者通過cli限定只走某些端口。
【問題8】
【疑問】關(guān)于lun和raid group的問題
劃分lun時，一個lun可以來自不同的raid group嗎？
【問題解答】可以
1.如果劃LUN是通過普通存儲化，沒有經(jīng)過SVC，那么每個LUN和POOL是對應(yīng)的，POOL又跟RAID GOUP是對應(yīng)的，只有RAID GROUP的RAID形式是一致的才能放到同一個POOL中（一個RAID GROUP對應(yīng)一個MDISK），所以該LUN劃分出來后，該LUN是經(jīng)過了多個MDISK虛擬化之后的產(chǎn)物，BLOCK分布于多個MDISK上，所以可以來自多個相同RAID形式的RAID GROUP，但無法來自多個不同RAID形式的RAID GROUP
2.如果劃LUN是通過SVC劃出來的，但是底層存儲通過IMAGE模式透穿至SVC的，也就是說底層存儲LUN--->SVC LUN是一一對應(yīng)的，這時SVC上的LUN在底層存儲上的分布也是來源于相同RAID形式的RAID GROUP
3.如果劃LUN是通過SVC劃出來的，但是底層存儲通過MANAGE模式映射給SVC管理的，如底層存儲RAID 5組成如下一個邏輯關(guān)系：MDISK--->RAID 5 POOL--->存儲LUN1--->SVC MDISK1，底層存儲RAID 10組成如下一個邏輯關(guān)系：MDISK--->RAID 10 POOL--->存儲LUN2--->SVC MDISK2，再通過SVC MDISK1和SVC MDISK2劃出一個新的SVC VDISK，這時的SVC VDISK的BLOCK是分布于不同RAID形式的RAID GROUP的。
【問題9】
【疑問】SVC Local VDM和SVC PPRC數(shù)據(jù)同步的粒度是？是實時更新數(shù)據(jù)嗎？
【問題解答】都是實時同步的，因為每次的寫SVC節(jié)點的操作，都會要等待另一SVC節(jié)點的寫響應(yīng)，才會認(rèn)為是一次完整的寫操作周期。補充一點，同步的顆粒度是bitmap（位圖）
【問題10】
【疑問】SVC管理的存儲擴(kuò)容，SVC會不會出現(xiàn)瓶頸？
目前的環(huán)境下面一套svc有一個IO GROUP，下面掛載了不同的存儲，現(xiàn)在相對下面的掛載的存儲擴(kuò)容，擔(dān)心隨著后面存儲容量的擴(kuò)大，SVC會不會出現(xiàn)瓶頸？怎么判斷？
【問題解答】上面這個問題來說，如果僅僅從后端掛載的存儲容量擴(kuò)容，SVC是會不出現(xiàn)性能瓶頸的，SVC最大支持4096個VDISK，如果后端存儲擴(kuò)容，劃分出來的卷的數(shù)量也越來越多，甚至需要超過4096個VDISK，那么SVC僅僅是不再支持劃分而已，性能不會出現(xiàn)問題。如果從SVC映射的主機數(shù)量角度來說，如果SVC映射的主機數(shù)量越來越多，那么均分至每一個SVC I/O Group優(yōu)先節(jié)點的主機數(shù)量也越來越多，這時就需要考慮SVC節(jié)點的性能瓶頸，因為SVC節(jié)點的緩存容量有限，主機數(shù)量的增加意味著所有主機平均每次需要寫入的IO量增多，假如增大至單個SVC節(jié)點緩存不足夠容納時，這時就會開始出現(xiàn)性能瓶頸，就需要開始新增SVC I/O Group了。
其實SVC的性能很不錯，借用一下前人測試的結(jié)果：
“”單論SVC的節(jié)點性能，在前兩代的CF8節(jié)點上做過SPC-1測試，16個V7000在8個CF8節(jié)點管理下，SPC-1性能達(dá)到50多萬IOPS?，F(xiàn)在最新的DH8節(jié)點，性能是CF8的3-4倍，那么性能可達(dá)到150-200萬IOPS，每個I/O Group可達(dá)到50萬IOPS?！啊?br>我們可以利用監(jiān)控來判斷SVC節(jié)點是否已飽和，如TPC軟件，也可以用SVC自身WEB界面上的監(jiān)控來初步判斷。

二、三種SVC雙活數(shù)據(jù)中心建設(shè)方案與非SVC方案的對比方面。

【分享】三種SVC雙活架構(gòu)詳盡對比
在上面的章節(jié)中，我們已經(jīng)深入探討了基于SVC的三種主流雙活數(shù)據(jù)中心架構(gòu)，詳細(xì)的介紹了每種架構(gòu)的基本模式、特性、原理和I/O讀寫等方面內(nèi)容，為了更方便與直觀的展示三種架構(gòu)的區(qū)別和特性，列表如下：



上面的列表很直觀的展示了三種SVC架構(gòu)的區(qū)別和共同點，可以看到，三種架構(gòu)在不同的場景和不同的高可用要求下，均有用武之地。SVC Stretched Cluster和SVC HyperSWAP架構(gòu)實現(xiàn)了雙站點ACTIVE模式，但這兩種模式有兩個弊端，一是對數(shù)據(jù)庫雙活的實現(xiàn)，依舊需要配合數(shù)據(jù)庫軟件層的方案解決。二是對兩個站點間的線路要求非常高，一旦線路中斷（這種情況并非不可能，尤其在當(dāng)下各種修路、修地鐵，多家運營商的裸光纖都在同一弱電井，同時斷的可能性大增），將對兩個站點的所有主機均造成一段時間的影響，所有業(yè)務(wù)被中斷，影響時間取決于仲裁時間和兩站點間距離。而且還需要忍受站點間線路的時延和抖動的可能造成的影響，站點間距離越大，這種影響會被不斷放大，影響讀寫性能，甚至造成線路中斷。這種情況下反而不如用SVC Local VDM SVC PPRC架構(gòu)，從分保護(hù)了本地資源，排除了可能的不可抗拒的影響，而且如果采用了SVC Local VDM SVC PPRC架構(gòu)，雖然存儲架構(gòu)層作為ACTIVE-STANDBY方式，但仍舊可以配合軟件層實現(xiàn)雙活數(shù)據(jù)中心建設(shè)；另外SVC HyperSWAP架構(gòu)看似很高級，無論從雙站點的讀寫性能優(yōu)化、單一站點失效后的全面保護(hù)能力方面還是雙活架構(gòu)后的高可用方面均優(yōu)于Stretched Cluster，但卻無法繼續(xù)進(jìn)行兩地三中心擴(kuò)展，實施復(fù)雜性也更高，運維成本也提高，而且總的VDISK數(shù)量較少等等；SVC Local VDM SVC PPRC充分保護(hù)了本地，但是災(zāi)備的實施卻又局限于AIX系統(tǒng)下的HACMP，6.1之前的AIX版本和linux、windows系統(tǒng)均無法實現(xiàn)跨站點高可用，只能從數(shù)據(jù)層同步，并利用軟件層的方式實現(xiàn)高可用和雙活。而且SVC Local VDM SVC PPRC的一套SVC集群下的兩個IO Group間無法自動切換，這點SVC Stretched Cluster也是如此，也就是說如果SVC Stretched Cluster配置為2個I/O Group，I/O Group間是無法實現(xiàn)自動切換的，需要人為手動切換；SVC Stretched Cluster實現(xiàn)了ACTIVE-ACTIVE，又可以擴(kuò)展兩地三中心，但是讀寫性能優(yōu)化方面做得又不如SVC HyperSWAP，而且本地冗余度做得也不大好，本地一個SVC節(jié)點故障，本地就沒有冗余保護(hù)，只能利用災(zāi)備站點的SVC節(jié)點，這點在SVC Local VDM SVC PPRC和SVC HyperSWAP都得到了冗余度提升；另外還有一點共同點得我們關(guān)注，我們知道SVC Stretched Cluster、SVC Local VDM SVC PPRC和SVC HyperSWAP均使用了同步復(fù)制技術(shù)，但有沒有想過如果真的因為站點間距離長，時延比較大，導(dǎo)致兩個SVC節(jié)點同步緩慢，以致最后影響雙數(shù)據(jù)中心整個業(yè)務(wù)系統(tǒng)的寫I/O緩慢。SVC還考慮到了這一點的，在SVC節(jié)點同步的參數(shù)中有mirrowritepriority屬性，可以設(shè)置為latency，當(dāng)同步響應(yīng)時間大于5秒時，放棄同步，保證主站點/主存儲的寫I/O性能。基于此，三種方案針對不同的企業(yè)需求，不能說哪種方案通吃，也不能說哪種方案一定不行，都有使用優(yōu)勢和劣勢。

【問題1】
**SVC存儲網(wǎng)關(guān)與友商類似產(chǎn)品的對比優(yōu)劣勢是什么？
**【問題解答】

【問題2】
針對有些廠商的存儲陣列自身帶有雙活 復(fù)制的功能，SVC的ESC的優(yōu)勢如何體現(xiàn)？現(xiàn)在有廠商存儲陣列自帶雙活 復(fù)制功能，例如：A中心和B中心之間雙活，B中心存儲和C中心存儲做復(fù)制，完全通過存儲陣列自身實現(xiàn)。目前，IBM DS8000和SVC ESC 復(fù)制能夠?qū)崿F(xiàn)。但是ESC的IO GROUP中單節(jié)點故障嚴(yán)重影響性能，如何應(yīng)對？
【問題解答】1.自帶雙活功能的存儲算是少數(shù)，如DS8000 HYPERSWAP，即使有，也需要LICENSE，有的MM也要LICENSE，GM也要LICENSE，中低端存儲就沒辦法了，像SVC這樣把高中低端存儲均融合后，用SVC ESC和SVC HYPERSWAP都實現(xiàn)了雙活或者雙活 異地。
2.SVC ESC的IO GROUP單節(jié)點故障，將引發(fā)節(jié)點切換，站點的主機將會訪問另一站點的SVC節(jié)點，只是造成了短暫時間的訪問中斷而已，另一站點SVC節(jié)點接管后，性能不會出現(xiàn)明顯的下降。這種方式并沒有不妥，只是本地站點只有1個SVC節(jié)點，冗余性來說，有點不夠。另外，SVC ESC的IO GROUP單節(jié)點故障后，由于一個IO GROUP是同一套緩存，會造成寫緩存DISABLE，這樣對于中低端存儲來說，可能會出現(xiàn)性能些許下降，但不明顯和致命。
3.對于SVC hyperswap的IO GROUP單節(jié)點故障，則好了許多，兩站點都有雙節(jié)點保護(hù)，站點與站點間的寫緩存均獨立，而且還有讀寫性能優(yōu)化方式，如連續(xù)10分鐘讀寫I/O占比75%以上則改變主從VDISK方式等。
【問題3】
SVC存儲網(wǎng)關(guān)雙活形式與控制器雙活（HDS\NETAPP\華為）間有何優(yōu)劣
【問題解答】單單從雙活形式來說，一個IO GROUP的兩個SVC節(jié)點的雙活和存儲控制器雙活實現(xiàn)原理都是類似的，都是兩個節(jié)點間的緩存同步和鎖排斥機制實現(xiàn)的，但是SVC先進(jìn)的地方是兩個節(jié)點可以拉伸至兩個站點，存儲控制器兩個節(jié)點是實現(xiàn)不了的。

三、雙活數(shù)據(jù)中心間鏈路與帶寬方面

【議題1】雙活數(shù)據(jù)中心建設(shè)過程中，最大的難點是雙中心間鏈路帶寬，時延和抖動，各位有什么深入的見解？如何更充分地考慮，需要注意的點有哪些？應(yīng)如何盡量避免該問題，高可用的鏈路該如何設(shè)計？各位專家對此有何深入見解？
【觀點一】鏈路帶寬，時延，抖動，這是由運營商線路質(zhì)量設(shè)備決定的，用戶對這塊只能加大監(jiān)控，束手無策，沒法改變
【觀點二】建議兩個數(shù)據(jù)中心距離不要超過100km，同時采用至少兩條以上的不同運營商線路
【觀點三】考慮到運營商的光纜質(zhì)量問題，使用雙運營商的鏈路，且距離不宜超過60KM
【觀點四】鏈路的抖動 我深有體會 ！
在一個客戶現(xiàn)場 ～兩個雙活數(shù)據(jù)中心～夸中心做的hacmp.～需要同時訪問兩個中心的存儲 ～中間運營商的鏈路有比較大的衰減 ——12到14吧 好像！這種衰減 都tcpip這種傳輸 沒有什么影響 但是對 光纖的傳輸就 影像大了～主機訪問存儲時好時壞！Vg被鎖 影像業(yè)務(wù)！
所以 我覺得在硬件層面做災(zāi)備雙活 不是很可靠 尤其是光纖的！
還是做數(shù)據(jù)庫那種dataguard好像更靠譜
【觀點五】dataguard據(jù)我所知是數(shù)據(jù)庫事物日志的復(fù)制技術(shù)，如果采用同步的方式，TCPIP效率較低，跨中心同步復(fù)制可能會影響性能，而且數(shù)據(jù)庫日志復(fù)制技術(shù)并不能覆蓋數(shù)據(jù)庫的全部操作，像XML和LOB格式的字段數(shù)據(jù)的增刪改操作，是不會記日志的，有些應(yīng)用為了效率的提升，采用了不記數(shù)據(jù)庫日志的方式。但是數(shù)據(jù)庫日志復(fù)制技術(shù)可以從事物層面保證數(shù)據(jù)庫一致性，而通過存儲鏈路作為數(shù)據(jù)傳輸通道的存儲復(fù)制技術(shù)是從存儲BLOCK層保證數(shù)據(jù)一致性的，差距可想而知。
【觀點六】1、取決于運營商，應(yīng)該選不同的兩家運營商。
2、距離不宜過遠(yuǎn)。（50km以內(nèi)比較好）
3、分業(yè)務(wù)，不是特別重要的 ，做主備即可，特別重要的可以考慮雙活。
【觀點七】從大家描述中，基本都是選擇了不同的兩家運營商，距離姑且不談，畢竟仁者見仁，智者見智，但是兩家運營商的裸光纖基本都在同一弱電井中，即使兩家都采用了各自裸光纖的冗余，但是當(dāng)前丟地鐵啊，修路啊，改造啊，建設(shè)啊非常常見，兩家運營商的裸光纖同時斷，或者幾條衰減很大，幾條又?jǐn)嗔说那闆r屢見不鮮，而在雙活建設(shè)當(dāng)中，中間鏈路是重中之重。
【觀點八】鏈路問題不可預(yù)估，也很難改善，做好監(jiān)控，想辦法降低RPO，這樣雙活才有意義
【議題2】如何實時監(jiān)控雙活數(shù)據(jù)中心鏈路狀況，避免因鏈路突發(fā)性故障或者性能衰減導(dǎo)致重大故障，如何應(yīng)急？
如果采用了雙活數(shù)據(jù)中心架構(gòu)，該采用哪種技術(shù)或者軟件監(jiān)控雙數(shù)據(jù)中心鏈路狀況？遇到突發(fā)狀況，該采取哪些措施應(yīng)急處置？
【觀點1】監(jiān)控鏈路本身還不如去監(jiān)控業(yè)務(wù)本身，比如交易響應(yīng)時間，峰值等，出現(xiàn)交易堵塞失敗，畢竟一切都是為了業(yè)務(wù)應(yīng)用服務(wù)的，必要的應(yīng)急預(yù)案應(yīng)該是在是建設(shè)雙活數(shù)據(jù)中心上線前，需要做的大量的場景測試，編寫應(yīng)急手冊。遇到類似的問題，根據(jù)業(yè)務(wù)和技術(shù)評估，采取如何的應(yīng)急方案.
【觀點2】鏈路監(jiān)控是必須的，但是鏈路監(jiān)控一般運營商決定的，我們在我們的出口上可以監(jiān)控到帶寬情況，這樣來推理，可以看出帶寬是否滿足需求，是否有抖動。
【觀點3】鏈路監(jiān)控一般是運營商去做的，客戶自己可能做不到，但客戶自己的應(yīng)用運行狀況，存儲運行狀況可以監(jiān)控到的

【問題1】
雙活數(shù)據(jù)中心建設(shè)過程中，雙中心間鏈路帶寬的選擇，鏈路采用的形式等方面，從用戶的角度那些更好一些？
比如采用那種方式，多少帶寬可以基本滿足雙活中心的要求？
鏈路采用的形式，是采用用戶全部租用運營商的鏈路 傳輸設(shè)備？還是只租用運營商的鏈路，而雙中心的傳輸設(shè)備按用戶要求來實現(xiàn)配置等？希望各位專家和同仁共同探討，給一些建議。
【問題解答一】個人意見
1.雙活數(shù)據(jù)中心”所需網(wǎng)絡(luò)的最低帶寬取決于兩個方面，一是存儲SAN網(wǎng)絡(luò)，二是IP網(wǎng)絡(luò)。SAN網(wǎng)絡(luò)帶寬取決于本地存儲 同城存儲寫入I/O吞吐量，這個吞吐量在建設(shè)雙活數(shù)據(jù)中心時，會同步寫至另一站點，這個可以在本地和同城進(jìn)行監(jiān)控和評估；IP網(wǎng)絡(luò)帶寬取決于你雙活的形式，如果是數(shù)據(jù)庫雙活，就需要評估和監(jiān)控跨站點兩個數(shù)據(jù)庫間數(shù)據(jù)傳輸?shù)木W(wǎng)絡(luò)吞吐，如果是應(yīng)用雙活，就需評估跨站點間兩個應(yīng)用間數(shù)據(jù)共享的網(wǎng)絡(luò)吞吐，還應(yīng)該考慮應(yīng)用是就近站點讀寫本地數(shù)據(jù)庫，還是跨站點讀寫，還有應(yīng)用間交互是就近站點讀寫，還是跨站點交互讀寫，根據(jù)雙活數(shù)據(jù)中心“雙活”的等級進(jìn)行提前規(guī)劃、監(jiān)控和整體評估，這是個浩大的工程。
2.鏈路采用的形式一般是只租用運營商的鏈路，雙中心的傳輸設(shè)備自己購買和配置，這樣更靈活又控制成本。
【問題解答二】這個問題我覺得還是主要看雙活中心存儲和應(yīng)用的需要了，存儲雙活，存儲之間同步鏈路需求最低帶寬多少，應(yīng)用如果是oracle rtt 時間是多少，而且中間鏈路延遲等等，得綜合考慮
【問題解答三】第一，雙活中心建立起來，基礎(chǔ)數(shù)據(jù)同步完成
第二、計算所有業(yè)務(wù)每天的數(shù)據(jù)量有多大。
第三、測試運營商帶寬速度和穩(wěn)定性
第四、計算比如千兆網(wǎng)絡(luò)把 ，一秒最多100m出頭，總數(shù)據(jù)量去除就得出你的帶寬，然后要考慮抖動，延遲，和高峰期，適量的加點富裕即可
保證以上4點，我認(rèn)為比較合理，不是拍腦袋上。
【問題2】
SVC雙活時FC交換機中間鏈路問題
有實施過程中關(guān)于生產(chǎn)中心與災(zāi)備中心間鏈路，是否有最佳實踐。
FC交換機間鏈路最多支持幾條？
自建光纜需注意哪些問題？
【問題解答】1.鏈路最佳實踐，目前沒有，我已列議題，希望各位專家提出自己的見解：雙活數(shù)據(jù)中心建設(shè)過程中，最大的難點是雙中心間鏈路帶寬，時延和抖動，各位有什么深入的見解？
2.FC交換機之間的級聯(lián)線建議是2條，做綁定，并且提升帶寬。
3.一般是租用用運營商的光纜，多家運營商互備，自建的也太有錢了吧。

四、虛擬化云時代，是采用分布式還是集中式管理方面

【議題1】虛擬化云時代，民主還是集權(quán)，如何在集權(quán)過程中，進(jìn)一步加強穩(wěn)定性和高可用？在虛擬化云時代，集中化、虛擬化、資源池和彈性動態(tài)伸縮等都成為其代名詞，但是我們感覺到業(yè)務(wù)系統(tǒng)越來越集中，使用的資源全部來自虛擬化過后的資源。如存儲通過SVC虛擬化，單臺物理機資源集中化，GPFS文件系統(tǒng)NSD格式化等等，越來越多的雞蛋都集中在一個籃子里了，各位專家對此有何看法和觀點，歡迎共同探討！
【觀點一】建議一般對資源池進(jìn)行集中管理比較穩(wěn)妥，業(yè)務(wù)系統(tǒng)需要直接申請資源就可以了，而且集中管理，，統(tǒng)一監(jiān)控，同時對設(shè)備的生命周期，運行狀況都能實時觀察到！
【觀點二】我覺得不能拍腦袋上，具體還得看業(yè)務(wù)類型，有得業(yè)務(wù)不適合集中，該分散就分散，不然中心壓力過大，但是總路線肯定是重視中心，弱化分支
【觀點三】集中便于管理，但帶來故障影響的風(fēng)險會增高，根據(jù)業(yè)務(wù)來找到平衡點，另外開始就需要考慮高可用的問題，否則后期會有巨大隱患
【觀點四】這里的集中或分散主要是從物理設(shè)備的使用角度來考慮的，集中會帶來管理方便和效率的提高，分散看起來分散了物理設(shè)備故障帶來的風(fēng)險。但我認(rèn)為并不盡然，我們的非功能性業(yè)務(wù)目標(biāo)一般有提高效率目標(biāo)和實現(xiàn)客戶需求的可用性目標(biāo)兩方面。集中虛擬化毋庸置疑能夠提高效率，而良好的可用性管理也可以實現(xiàn)在集中虛擬化環(huán)境下的業(yè)務(wù)可用性目標(biāo)，例如業(yè)務(wù)系統(tǒng)的可用性架構(gòu)、物理設(shè)備的配置使用策略、恢復(fù)管理等等都影響著是否能達(dá)到客戶需求目標(biāo)。同時，集中虛擬化后，我們可以用更經(jīng)濟(jì)更有效的手段來協(xié)助可用性管理。因此，我認(rèn)為我們需要從業(yè)務(wù)目標(biāo)出發(fā)，通過可用性管理來實現(xiàn)可用性目標(biāo)，物理設(shè)備集中化只是其中的一個因素，需要考慮但并非一個硬的限制。
【觀點五】民主還是集權(quán)，永恒的話題。雞蛋到底是放在一個籃子里？還是多放幾個籃子？真的很難選擇，但是在虛擬化云時代，集中化、虛擬化、資源池和彈性動態(tài)伸縮等都成為其代名詞。但是我們也有擔(dān)憂，也有憂慮，比如說SVC虛擬化，之前主機訪問各自存儲，分門別類，部分主機訪問高端存儲，部分主機訪問中端存儲，部分主機訪問低端存儲，SVC虛擬化上了之后，所有異構(gòu)、高中低端存儲均掛在至SVC，被SVC管理，再通過SVC虛擬化成VDISK，映射給所有主機使用，雞蛋基本全在一個籃子里了，SVC集權(quán)后，核心地位無可比擬。而且在私有云建設(shè)當(dāng)中，存儲掛載至SVC并不是通過IMAGE模式（透穿模式），而是manage模式，說白了這種模式下存儲全是SVC的LUN資源，SVC再在這些LUN資源上再虛擬化一層，再映射給主機使用，在這種模式下，主機只能識別SVC的vdisk,存儲的上的卷已經(jīng)完全無法單獨供主機使用，這也是一種集權(quán)，地位又提升一大截，風(fēng)險提升了。再比如說資源池，之前主機分散至不同的物理機中，為了動態(tài)彈性伸縮擴(kuò)展，為了快速部署，快速迭代等，一臺物理機資源容量越來越大，放置多個主機在一臺物理機中，主機不再擁有自己的I/O卡，主機不再擁有自己的硬盤，所有的網(wǎng)絡(luò)訪問和I/O訪問均需要通過虛擬I/O主機進(jìn)行，主機擁有的只不過是其他主機虛擬化之后的產(chǎn)物，這臺物理機也是一種集權(quán)，地位也提升了，風(fēng)險也提升了；再比如說GPFS共享文件系統(tǒng)，利用該軟件搭建應(yīng)用系統(tǒng)，可以在應(yīng)用端實現(xiàn)應(yīng)用讀寫雙活。但是GPFS軟件將主機識別的盤格式化了，成了GPFS本身擁有的NSD格式盤，不屬于該GPFS集群架構(gòu)的主機，是無法識別NSD格式盤的，該數(shù)據(jù)盤脫離GPFS軟件、脫離GPFS集群架構(gòu)的主機也無法單獨使用，這也是一種集權(quán)。
以上種種情況說明，我們的企業(yè)在構(gòu)建雙活數(shù)據(jù)中心、私有云平臺的過程中，是不斷集權(quán)過程，不斷提升了便利性、靈活性和高可用性同時，也提升了集權(quán)者的地位，加劇了風(fēng)險。為了防范風(fēng)險，SVC版本不斷更新，增加新的功能，新的理念，新的架構(gòu)，漸漸的有了SVC Local VDM來防范存儲單點風(fēng)險，有了SVC Stretched Cluster來防范站點風(fēng)險，有了SVC HyperSWAP來防范站點單SVC節(jié)點風(fēng)險，同時締造了基于存儲虛擬化方案的SVC雙活架構(gòu)方案；為了防范主機過于集中的風(fēng)險，我們不斷利用軟件層的雙活方案和可靠性方案，如WAS集群、TSA GPFS、HACMP、DB2 HADR TSA等等，主機端利用動態(tài)遷移、vmotion等技術(shù)共同來緩解主機的集中風(fēng)險壓力，并不斷提高資源池高可用，不斷提高資源池網(wǎng)絡(luò)及存儲I/O性能等；為了防范GPFS的風(fēng)險，我們將GPFS NSD數(shù)據(jù)盤通過SVC PPRC復(fù)制至災(zāi)備，并在災(zāi)備端新增了GPFS集群主機，加固該架構(gòu)的冗余性和可靠性，減輕了GPFS NSD格式化后的風(fēng)險壓力。
可以預(yù)見的是，隨著資源池不斷云化，主機不斷集中化，虛擬化技術(shù)不斷疊加，技術(shù)不斷更新，我們的高可用理念和雙活架構(gòu)不斷更新，集中還是民主這個話題會被漸漸遺忘，在集中化中民主，在民主化中集中。

五、SVC同城容災(zāi)與異地容災(zāi)方面

【問題1】
【疑問一】雙活數(shù)據(jù)中心 災(zāi)備模式的方案有哪些可以落地的？
假如客戶沒有異構(gòu)存儲需求的前提下，需要在同城建設(shè)基于存儲的雙活以及在異地還要做遠(yuǎn)程存儲復(fù)制，IBM 除了DS8000(成本較高）以外，還有可選方案嗎?
【問題解答一】如果沒有異構(gòu)存儲，可以通過存儲自身的鏡像軟件來實現(xiàn)，也可以通過系統(tǒng)的lvm方式來實現(xiàn)，或者如果客戶采用了gpfs那就更好了
【疑問二】相關(guān)廠商存儲本身就能實現(xiàn)，無需GPFS之類的；而且只是要求存儲實現(xiàn)，不要求通過數(shù)據(jù)庫實現(xiàn)，好像IBM的方案不多吧。沒有虛擬化的要求，為何提供SVC或VPLEX呀？
【問題解答二】高端存儲DS8000系列 hyperswap GM實現(xiàn)要求，排除DS800系列的話，可以結(jié)合存儲數(shù)據(jù)級容災(zāi)和軟件層應(yīng)用雙活來實現(xiàn)你的要求，如MM GM實現(xiàn)數(shù)據(jù)級同城容災(zāi)和異地災(zāi)備，應(yīng)用雙活可以用應(yīng)用負(fù)載 GPFS或者應(yīng)用負(fù)載 WAS集群等實現(xiàn)，數(shù)據(jù)庫雙活可以用GPFS ORACLE RAC或者DB2 PURESCALE GPFS等，數(shù)據(jù)庫異地可以用DB2 HADR或者ORACLE DG
【問題解答三】除去軟件層的解決方案、存儲虛擬化的解決方案，這種存儲的雙活 異地只能是高端存儲了，IBM不就是DS8000系列高端嗎，那么只能是通過DS8000 HYPERSWAP實現(xiàn)同城雙活，但是既然是用了HYPERSWAP，就無法用存儲實現(xiàn)容災(zāi)了，只能又配合軟件層的方案實現(xiàn)異地了。其他存儲廠商高端系列估計也有方案，接觸不多。
【問題2】
【疑問】災(zāi)備系統(tǒng)建設(shè)在滿足監(jiān)管要求的RTO、TPO外，有哪幾種建設(shè)方式的初期成本投入最少？
【問題解答】這個問題比較泛，要看你現(xiàn)有的架構(gòu)和設(shè)備情況，還要考慮你的可靠性、性能、擴(kuò)展等要求。
最小投入的話，那么只能實現(xiàn)數(shù)據(jù)級災(zāi)備。
1.用備份的方式可能會最少投入，如將生產(chǎn)數(shù)據(jù)庫、操作系統(tǒng)、文件通過備份至存儲中，然后用異步的方式傳輸至災(zāi)備中心，比如說NAS與NAS間IP異步傳輸?shù)姆绞?。這個可以是初步的方式。但是RPO和RTO可能是達(dá)不到要求的，因為要采用備份恢復(fù)的方式，數(shù)據(jù)必然存在丟失，恢復(fù)時間也有點長。
2.要么是用存儲的異步復(fù)制方式（需要看存儲型號，還有LICENSE等）
3.要么就上SVC，將本地的異構(gòu)存儲整合，再利用本地SVC與災(zāi)備的V5000/V7000/SVC采用異步復(fù)制的方式
4.上SVC與SVC間的PPRC實時同步方式，實現(xiàn)所有異構(gòu)存儲的數(shù)據(jù)級同步方式。
5.假定只實現(xiàn)數(shù)據(jù)庫級災(zāi)備，在災(zāi)備買個存儲和主機，如ORACLE可以用ORACLE DG，DB2可以用HADR等實現(xiàn)。
個人建議和想法，供參考。
【問題3】
【疑問】如何利用svc進(jìn)行異地容災(zāi)建設(shè)？
目前，數(shù)據(jù)中心內(nèi)包括EMC、DELL、IBM等廠家存儲，用于不同的生產(chǎn)系統(tǒng)，每套生產(chǎn)系統(tǒng)都是獨立的SAN架構(gòu)網(wǎng)絡(luò)。如果采用SVC進(jìn)行異地容災(zāi)建設(shè)，對于數(shù)據(jù)中心現(xiàn)有系統(tǒng)架構(gòu)豈不是改動很大，并且系統(tǒng)還需要停機時間對吧。對于這種情況，方案應(yīng)該怎樣設(shè)計才能使得數(shù)據(jù)中心內(nèi)現(xiàn)有架構(gòu)改動最小，除了利用svc還有其他解決辦法嗎？
【問題解答】1.用SVC等存儲虛擬化方案是改動最小的方案，用其他方案更復(fù)雜，要么用存儲的異地復(fù)制功能（可能還需要買專門的LICENSE），要么用CDP先進(jìn)行架構(gòu)改造，再用本地和異地兩套CDP的異地復(fù)制功能實現(xiàn)，有的存儲型號可能還不能都實現(xiàn)異地災(zāi)備。
2.用SVC等存儲虛擬化方案對以后架構(gòu)的提升最明顯的方案，對你企業(yè)架構(gòu)云化轉(zhuǎn)型最便捷的方案，新購兩臺SAN交換機，再利用SVC整合全部的異構(gòu)存儲，利用兩地的SVC與SVC進(jìn)行異步復(fù)制，或者用本地的SVC與異地的V7000等進(jìn)行異步復(fù)制，均能實現(xiàn)異地災(zāi)備。
3.無論你采用哪種方案，停機肯定是要的，用SVC改造的方式你可以理解為：
改造前為：各異構(gòu)存儲---->HOST
改造后為：各異構(gòu)存儲---->SVC---->HOST，中間只不過是加了一道SVC而已，改造后你之前所有的不同SAN網(wǎng)絡(luò)也進(jìn)行了統(tǒng)一整合，整個架構(gòu)清晰明了。
【問題4】
【疑問】云技術(shù)和云服務(wù)越來越普遍，災(zāi)備如何結(jié)合云及傳統(tǒng)的方式進(jìn)行實施，既保證安全便捷又節(jié)省初期費用投入？
【問題解答】云架構(gòu)下無非這么幾種：
云資源：
1.軟件定義網(wǎng)絡(luò)：目前來說，有點困難，難以落地，看今后技術(shù)進(jìn)步。
2.軟件定義計算節(jié)點：POWERVM，VMWARE，KVM。
3.軟件定義存儲：SVC和VPLEX為代表。
4.軟件定義存儲 計算節(jié)點：超融合架構(gòu)。
云管理：
POWERVC，ICM，ICO，VCENTER，統(tǒng)一監(jiān)控，統(tǒng)一備份，統(tǒng)一流管，自動化投產(chǎn)等
災(zāi)備要落地云，可參考上面的技術(shù)實施。

六、私有云建設(shè)與雙活建設(shè)架構(gòu)、案例方面

【議題1】雙活數(shù)據(jù)中心復(fù)雜性也大大提升，有無必要？難點在哪？復(fù)雜性在哪？適用哪些企業(yè)？
雙活數(shù)據(jù)中心進(jìn)一步提升了業(yè)務(wù)系統(tǒng)的RPO和RTO，提升了雙中心資源利用率，但相應(yīng)地系統(tǒng)復(fù)雜性也大大提升，有無必要？難點在哪？復(fù)雜性在哪？適用哪些企業(yè)？
【觀點1】雙活的難點 不是有一個廠商的技術(shù)產(chǎn)品就能完成的，往往需要太多技術(shù)的協(xié)同配合完成，這就會造成了技術(shù)兼容性成熟度的考驗。既然不是一個技術(shù)，那就會增加管理和運維的難度，對于一些IT技術(shù)力量的不足的企業(yè)，遇到問題，往往會很棘手，畢竟雙活的數(shù)據(jù)中心本身，需要業(yè)務(wù)，IT，多部門聯(lián)合才能更好地完成的,如何問題如何應(yīng)急，在完美的雙活都很難盡善盡美，最終還是要靠人去處理那些技術(shù)本身無法處理的問題。
【觀點2】數(shù)據(jù)大集成項目（包含物理鏈路，硬件，系統(tǒng)，存儲，甚至軟件），難度很高。
1、重點是網(wǎng)絡(luò)架構(gòu)設(shè)計，也是難點，因為網(wǎng)絡(luò)的架構(gòu)設(shè)計合理，可以減少延遲，抖動等。
2、很有必要
3、大企業(yè)都有這個需求吧，只是看投入大小，金融行業(yè)，國慶扛得住，民企就選擇性了，比如重要業(yè)務(wù)可以做，非重要業(yè)務(wù)備份即可。
現(xiàn)在還一個好處就是公有云可以減少一定的成本，形成雙中心或者多中心。
【議題2】雙活數(shù)據(jù)中心資源池中包括各類異構(gòu)的存儲、各類異構(gòu)的X86服務(wù)器，各類異構(gòu)的Power服務(wù)器，資源池，不同的虛擬化實現(xiàn)技術(shù)，那么如何分門別類統(tǒng)一進(jìn)行資源池管理，跨中心的資源池又該如何統(tǒng)一管理呢，希望各專家提出自己的獨特見解！
【觀點1】目前來說采用最多的還是虛擬化技術(shù)，存儲通過svc或者emc vplex實現(xiàn)，主機一般采用vmvare或者powervm來實現(xiàn)
【觀點2】vmware做類是項目比較多
近兩年流行的超融合技術(shù)也可以。

【問題1】
【疑問一】能給出幾個雙活數(shù)據(jù)中心 部署架構(gòu)圖嗎？
【問題解答】給幾個應(yīng)用雙活的吧
統(tǒng)一私有云平臺：

MQ災(zāi)備 JAVA應(yīng)用雙活：

JAVA應(yīng)用雙活：

WAS應(yīng)用雙活：

【疑問二】看得出來，都離不開負(fù)載均衡，這些負(fù)載均衡是按什么分類的呢？
【問題解答】對，應(yīng)用雙活，負(fù)載均衡少不了的，按網(wǎng)絡(luò)安全分區(qū)分類的
【問題2】
【疑問】
雙活可以有應(yīng)用級雙活和數(shù)據(jù)庫級雙活，目前有沒有數(shù)據(jù)庫級雙活的銀行應(yīng)用案例？對于兩地三中心的建設(shè)環(huán)境下，如何進(jìn)行雙活建設(shè)呢？
【問題解答】1.據(jù)我所知，數(shù)據(jù)庫雙活還是有案例的
如前幾年的山東移動的GPFS ORACLE RAC雙活
還有民生銀行和交行的DB2 PURESCALE GPFS雙活
2.如果是兩地三中心的話，基于SVC的的方案，HYPRE SWAP是不能用的，只能用SVC Stretch Cluster實現(xiàn)同城存儲層的雙活，再加SVC GM實現(xiàn)異地災(zāi)備，或者用SVC LOCAL VDM SVC PPRC SVC GM實現(xiàn)本地雙存儲高可用 同城災(zāi)備數(shù)據(jù)級災(zāi)備 異地災(zāi)備，同城應(yīng)用雙活只能用軟件層的雙活架構(gòu)，如應(yīng)用負(fù)載 GPFS跨中心雙活，應(yīng)用負(fù)載 跨中心WAS集群等等，數(shù)據(jù)庫的話DB2 PURESCALE很不錯。