存儲跨數據中心雙活的方案更是雙活數據中心架構方案中最重要且最艱難的一項，為了幫助企業IT架構師理清和解決存儲跨中心雙活方案架構的難點，twt社區特別組織線上交流，邀請專家逐一對難點進行解析和解答。

存儲跨中心雙活方案設計階段如何盡量降低對整體性能的影響?

性能影響問題：因為雙活系統在寫入數據時，會寫兩次數據，尤其是通過復制功能寫到遠端存儲的過程，傳輸鏈路的性能也會影響整體性能。在選型設計階段該如何解決該難點?盡量降低對整體性能的影響?

[[206858]]

解析和解答

鄧毓 某農信社資深骨干工程師

這個問題實際上存儲雙活不可避免要遇到的問題，相比單存儲直接提供讀寫來說，存儲雙活一定會增加讀寫響應時間，更別說存儲還是跨兩個不同數據中心的，隨著距離的增加，理論上每增加100KM，會增加1ms的RTT(往返延遲時間),通常單個IO總耗時在1-3ms左右，就會認為單個存儲I/O處理處于比較高性能的模式，如果加上其他因素，如“數據頭處理”和“并發”，1ms的“理論”延時增加的影響會成倍增加，將原本處于高性能模式的IO響應時間拉高，對應用或者數據庫來說，“變慢”了。所以存儲雙活的初衷是只是為了高可用性和提高總體并發、吞吐量，并不是為了降低讀寫響應時間。那么我們在設計、選型存儲雙活方案時，就需要考慮如何盡量降低雙活的存儲所帶來的性能降低影響。

我們先來看看一些存儲雙活方案的讀寫流程：

(1)IBM SVC Enhanced Stretch Cluster(ESC)和HDS GAD等

IBM SVC ESC和HDS GAD的讀寫方式都很類似，這里就放在一起來看。

SVC ESC：

HDS GAD：

讀：

ESC和GAD在兩個存儲拉開到兩個數據中心，形成AA模式的架構，對于讀來說，是兩個數據中心分別對各自中心的存儲本地讀，這樣讀來說不存在跨站點的RTT，讀性能跟單存儲是一樣的。

寫：

某數據中心的寫操作會先寫到本地控制節點緩存，然后再跨站點同步至另一控制節點緩存中，并原路返回，告訴主機寫操作完成，等到緩存達到一定的水位時，再刷入各自底層存儲當中，這時的寫操作存在1倍的跨站點RTT。當兩個數據中心都要對某一數據塊寫操作時，會先在緩存表對應的數據塊中加鎖，并同步鎖信息至對端緩存表，實現雙活存儲的寫并發。所以寫也是本地寫的方式，性能跟單存儲比是降低的。

(2)SVC HyperSwap

SVC HyperSwap的HyperSwap卷有master和aux之分，讀寫復雜度也高很多，master卷所在站點的主機讀寫是本地讀本地寫，而aux卷所在站點的主機讀寫方式是轉發模式。

假設初始化后，Site1的卷為Master卷，Site2的卷為Aux卷

讀：

Site1讀I/O

1.主機向SVC I/O Group1的任意一個節點發送讀請求

2.SVC I/O Group1將該請求傳至Storage Pool1

3.Storage Pool1響應請求，并將數據傳至SVC I/O Group1

4.SVC I/O Group1將數據結果傳至主機

Site2讀I/O

1.主機向SVC I/O Group2的任意一個節點發送讀請求

2.SVC I/O Group2將該請求轉發至SVC I/O Group1

3.SVC I/O Group1將請求傳至Storage Pool1

4.Storage Pool1響應請求，并將數據傳至SVC I/O Group1

5.SVC I/O Group1將數據回傳給SVC I/O Group2

6.SVC I/O Group2將數據結果傳至主機

所以可以看到AUX卷所在站點的主機需要跨站點讀對端存儲，存在1倍的RTT，而MASTER卷所在的主機讀IO和單存儲性能相差無幾。

寫：

Site1寫I/O

1.主機向Site1的其中一個SVC節點2發送寫I/O請求

2.該SVC節點2將寫I/O寫入緩存

3.該SVC節點2將寫I/O同步至節點1緩存，并同時通過MM發送寫I/O至站點2的節點3和節點4

4.SVC節點1、3、4陸續回復節點2的寫響應

5.SVC節點2回復主機寫響應

6.兩個站點的SVC節點分別將緩存寫入各自站點的存儲當中

Site2寫I/O

1.主機向Site2的其中一個SVC節點3發送寫I/O請求

2.該SVC節點3將寫I/O轉發至Site1的任意SVC節點2

3.SVC節點2將寫I/O寫入緩存

4.該SVC節點2將寫I/O同步至節點1緩存，并同時通過MM發送寫I/O至站點2的節點3和節點4

5.SVC節點1、3、4陸續回復節點2的寫響應

6.SVC節點2回復SVC節點3的轉發響應

7.SVC節點3回復主機的寫響應

8.兩個站點的SVC節點分別將緩存寫入各自站點的存儲當中

同理，AUX卷所在站點的主機需要跨站點寫對端存儲，并且回寫AUX卷底層存儲，總共存在2倍的RTT，而MASTER卷所在的主機寫IO和單存儲性能相差無幾。

所以很明顯，SVC HYPERSWAP的SVC節點是跨站點雙活，而存儲則為ACTIVE-STANDBY。

(3)NetApp MCC

MCC的雙活方式實際上是兩個數據中心的存儲互為鏡像，各自提供不同的存儲服務。

對于AGGX來說，為站點A的主機提供本地讀和本地寫，并通過集群節點的NVRAM寫日志同步至站點B，維持數據一致性，也是等到日志達到水位線，刷入底層存儲當中。

對于AGGY來說，也是類似，為站點B的主機提供本地讀和本地寫，并同步NVRAM的寫日志至站點A。MCC通過這種方式實現兩個站點存儲的雙活，MCC集群節點也是雙活，但對于某一應用主機來說，實則只在一個站點活動。

性能方面，MCC的讀性能和單存儲類似，寫性能存在1倍的RTT。

(4)SVC Vplex Metro

Vplex Metro和其他三種方式都不一樣，是一種分布式的存儲雙活/多活架構。Vplex沒有寫緩存，有了分布式緩存，標榜為access anywhere

[[206859]]

沒有寫緩存就意味了，主機對VPLEX的寫是透寫模式，主機的寫IO只是經過VPLEX的虛擬化直接落入到底層存儲，并在分布式緩存目錄表中記錄這個寫IO是通過哪個VPLEX引擎寫入的。當需要對該數據塊進行讀操作時，先是在分布式緩存目錄中查找數據塊是通過哪個VPLEX引擎寫入的，然后再通過本地的VPLEX引擎轉發該讀請求至上一次寫入該數據塊的VPLEX引擎，通過它來讀取它后端的存儲，最終原路返回。另外，對于寫入的IO，透穿過VPLEX寫底層存儲時，還將同步一份IO副本至另一VPLEX引擎的底層存儲。

所以可以看到，對于某數據中心VPLEX的讀操作來說，如果剛好上次該數據塊的寫操作時也是發在該VPLEX中，那么讀是本地讀，親和性好。如果剛好上次該數據塊的的寫操作不是在該VPLEX，那么就需要跨站點進行讀操作，親和性弱，存在1倍的跨站點RTT;對于寫，都是本地寫，只不過需要將該寫IO同步至另一站點的底層存儲，也存在1倍的跨站點RTT。

好了，寫了這么多，將幾種主流的存儲雙活架構的讀寫操作流程寫清楚了。簡單對比如下：

歸根到底，我們最想要的存儲跨中心雙活，就是為了讓兩個數據中心的主機對存儲的讀寫，盡量本地讀和本地寫，或者本地讀，減少跨中心寫。這是“盡量降低對整體性能的影響”的最直接的方法!

首先是讀寫比例問題，不能將讀寫比例過小的應用放到雙活存儲系統中。

再是距離對讀寫RTT的放大問題，讀寫響應時間越敏感，距離越不能過遠。

***是想盡辦法，減少跨中心寫，這里有很多辦法，比如通過數據庫的分庫分表，將應用分割至兩個站點，熱點數據分離;增大緩沖池，盡量減少直接的寫存儲操作等。