核心系統是企業最為重要的系統，尤其是金融行業，它是金融企業的生命線， 一旦信息科技風險越過了這條底線，企業的整個金融信息系統將全面癱瘓，后果不堪設想。所以為了牢牢守護住這條命脈，企業一直在不斷的尋求更好的技術和更優的解決方案，來對核心系統的優化之路進行探索，這其中之一便是核心系統存儲雙活優化。

傳統的核心系統存儲都是采用集中式存儲，通過搭建兩地三中心的存儲架構來防范核心系統數據的物理性錯誤，并通過數據備份來防范數據的邏輯錯誤。然而目前的兩地三中心存儲架構為主備架構，一來如果主存儲發生故障，必然需要進行存儲主備切換，由于核心系統數據量巨大，切換時間漫長，即使成 功切換之后 RPO=0，RTO 也不少于 10 分鐘;二來雖然備存儲實時存在一份和主存儲一樣的數據副本，但是這份副本長時間不對外提供讀寫服務，資源使用率低倒也無所謂，這份副本能否在切換之后正常使用，是需要打一個大大的問號。所以企業每年都會定期進行災難演練，也可能是出于對這份備副本的“不放心”。

[[210138]]

基于上述兩點，核心系統是有需要進行分布式雙活架構的轉型，來盡量降低故障帶來的影響，滿足 RPO=0，RTO小于 1 分鐘的要求，而轉型的最關鍵一步便是存儲雙活。

雖然存儲雙活技術方案層出不窮，幾乎所有主流的存儲廠商都有一套甚至多套存儲雙活技術解決方案，但基于核心系統的重要地位和獨特的特征，存儲雙活技術的真正落地實現還是存在著諸多難點，下面就是其中的三個核心難點。

1.首先最“突出”的難點就是性能影響問題。

傳統的集中式主備存儲架構，在主存儲寫入數據時，需要將數據同步一份至備存儲，完成后算是一次完整的寫周期;而雙活存儲架構則不一樣，兩個存儲雖然都同時受理寫請求，也會將寫入的數據同步一份至另一端，但關鍵點在于兩個存儲并不同時對同一個存儲塊寫操作，也就是說寫同一個數據塊時，搶占成功的存儲會對該存儲塊加一道“鎖”，防止被另一端寫，另一端想要讀該數據塊，也得乖乖等數據同步完成之后才能進行，所以這樣看來，雙活存儲雖然物理上實現了雙活讀寫，但實際的讀寫性能上，由于存在著大量的“等待鎖釋放”和“數據同步完成”兩個動作，造成了性能的影響。

這個影響面跟什么有關系呢?

***個動作取決于寫操作的頻繁度，也就是寫IOPS，寫 IOPS 越高，鎖競爭現象越嚴重;第二個動作取決于兩個存儲間的距離和存儲緩存的大小，距離越遠，寫同步往返延時越高，存儲緩存越小，寫緩存延遲現象的比例越高。

然而核心系統正是由于業務集中度和并發度高，對讀寫響應時間也特別嚴格，特別是對流水表的寫入操作，如果兩個存儲都同時承擔著高并發地對這些集中式的數據表讀寫的任務，那造成的鎖競爭現象將更加嚴重，再加上本身兩個存儲間距離原因導致的延時，性能影響將成倍放大，輕者業務處理緩慢，重則核心系統直接癱瘓，核心系統如果難以破解該難點，也將無法使用存儲雙活技術。

2.其次***“風險”的難點就是腦裂與鏈路隱患問題。

一方面，在傳統主備存儲架構中，由于兩個存儲間的關聯是松耦合的關系，存儲與存儲間心跳探測也只是為了保證數據同步，心跳鏈路中斷也只是數據復制中斷而已，并不會造成實質的存儲切換等動作，最多會因為中斷，造成主存儲的 IO 短暫HANG住，對業務也幾乎無感知。然而倘若升級為存儲雙活架構，由于整個架構呈現的是一種對稱式的架構，兩個存儲都是作為主存儲，必然需要一個第三方的仲裁設備，在存儲間鏈路中斷時，來投票選舉出存活的主存儲，不至于因兩個存儲互相爭搶主動權，而造成兩敗俱傷的慘烈局面。

然而問題就在于此，當發生腦裂現象時，仲裁之后存儲恢復時間需要多久?

這個時間取決于投票表決的時間和競選失敗的存儲前一刻的 IO 吞吐量，因為競選成功的存儲需要將這部分 IO 回退來保證業務數據的一致性，而核心系統存儲的 IO 吞吐量無疑是非常大的，尤其是在晚間批量時，這也將意味著當發生鏈路中斷，為了防范腦裂，需要將整個存儲 IO HANG 住，并且這個 HANG 住的時間也因為是核心系統變得更長。

而矛盾點卻在于，核心系統是最重要的系統，對業務連續性的要求比任何業務系統都要高上一大截，鏈路中斷造成的 RTO 太長將無法接受，更令人恐怖的是，如果此時正處晚間核心系統批量，那第二天白天還能否開業就真的是一個問號了，所以換句話說，建設核心系統存儲雙活需要保證高可靠的鏈路，無論這個鏈路是本地還是跨中心的，只有這個最重要的前提條件具備了，才能開始著手存儲雙活。

另一方面，如果雙活存儲間的鏈路是跨中心的，還需要考慮鏈路的穩定性問題。由于這個鏈路通常是租用運營商的裸光纖，光衰問題和抖動問題也是目前無法解決的難點，一旦發生于核心系統，性能受影響不說，如果因此觸發腦裂仲裁，造成 IO HANG 住，又是一場全局性的災難，所以核心系統上跨中心的存儲雙活更是難上加難。

3.******“考驗”的難點就是存儲架構轉型過程問題。

如果前面兩道鬼門關要么因自身企業核心系統 IO 壓力不大，業務連續性要求不高而“ 不太在乎”，可以靠著軟硬件技術而“化險為夷”，那在將傳統存儲高可用架構轉型為雙活存儲架構時，依舊存在些許技術難點的考驗。

表現為：在存儲雙活技術選型時，該技術是否為真正的存儲雙活?而不是備存儲將 IO 轉發至主存儲的模式，該技術的成熟度和穩定性如何?是否能夠保護原有存儲投資?能否支持兩地三中心擴展?等等;在存儲雙活實施過程中，巨量的核心系統數據如何快速同步到另一份存儲副本?完成同步之后的兩個存儲副本以怎樣的方式掛載給多臺核心系統主機?是兩個副本再虛擬成一個卷共享給主機還是分別掛給不同的主機?實施時，是否需要停止核心系統，停機窗口如何安排等等;在存儲雙活運維時，如何實時監控存儲雙活的性能狀況，遇到緊急存儲故障或者鏈路波動時，應急措施是怎樣的，是否需要人工干預，需要人工干預時，采取哪些應急解決辦法等等。

以上問題一個個接踵而至，都是在轉型存儲雙活架構時，需要事先進行周全縝密的考慮， 只有通過了這層“考驗”，方能大膽放心的著手核心系統存儲雙活優化。