數(shù)據(jù)中心雙活技術方案選型規(guī)劃

1、 數(shù)據(jù)中心雙活技術方案選型規(guī)劃 談到雙活就必須要從IT業(yè)務連續(xù)性管理這個話題談起。只有從根上我們知道這個需求以及技術方案是怎么生長出來的，我們才能夠徹底搞清楚，用戶在什么情況下適合什么樣的解決方案，以及未來技術解決方案的走向。為了保證IT系統(tǒng)對業(yè)務支撐的連續(xù)性，在HA高可靠方案的基礎上，生長出來了DR的概念。即如果由于某些不可抗力原因，如火災、地震、公共衛(wèi)生安全事件、或其他原因，導致單數(shù)據(jù)中心整個出現(xiàn)問題，如何能夠保證IT能夠繼續(xù)有效運行。在這個概念下提出了RTO以及RPO的概念。所謂的雙活方案就是在這樣的概念下生長出來的。即如果RTO和RPO都雙雙等于零，那就是所謂的雙活方案。針對應用服務器

2、場景，由于Load balance解決方案(這里又分為有狀態(tài)和無狀態(tài)兩種)已經(jīng)非常成熟了。因此一直以來應用服務的雙活方方面面的都問題不大（ 老舊應用改造除外 ）。核心需要解決的問題一直是數(shù)據(jù)庫層面上的雙活問題。目前針對數(shù)據(jù)庫雙活的解決方案有很多種?？偟膩碚f分為兩大類：原生數(shù)據(jù)庫雙活（多活）方案以及傳統(tǒng)數(shù)據(jù)庫的雙活方案。1.原生數(shù)據(jù)庫雙活（多活）方案目前新型的分布式NewSQL數(shù)據(jù)庫，在系統(tǒng)設計方面就充分考慮到了雙活/多活的需求。因此原生滿足。目前對于這類數(shù)據(jù)庫典型的實現(xiàn)方式有兩種：方法1：在數(shù)據(jù)庫底層建立統(tǒng)一的分布式存儲系統(tǒng)，數(shù)據(jù)庫實例寫下來的數(shù)據(jù)同時寫多副本。這些副本可以分布在多個數(shù)據(jù)中心上

3、。在數(shù)據(jù)庫實例端，可以做多個集群多實例方案，或者也可以做快速服務切換方案。因此任何一個數(shù)據(jù)中心出現(xiàn)問題，都不會影響。以下是一個例子：方法2：在數(shù)據(jù)庫底層建立統(tǒng)一的KV數(shù)據(jù)庫集群（目前用RockDB的居多）來解決數(shù)據(jù)文件跨節(jié)點，跨數(shù)據(jù)中心存儲的問題，并通過Raft機制來實現(xiàn)數(shù)據(jù)同步和跨數(shù)據(jù)中心切換。數(shù)據(jù)庫實例層的設計方式和方法1類似。這里典型方案如TiDB。綜上所述的兩種方法來看，其實原生的數(shù)據(jù)庫雙活解決方案也沒有太多神秘，基本的解題思路依然是在分布式存儲層來解決問題。只是實現(xiàn)的技術路徑不同而已。2. 傳統(tǒng)數(shù)據(jù)庫的雙活方案這里講的傳統(tǒng)數(shù)據(jù)庫如Oracle, DB2，Informix等。由于這些數(shù)

4、據(jù)庫本身并沒有在原生狀態(tài)下考慮雙活問題。因此雙活方案都是在原生體系外面通過附加解決方案來構建的。這類解決方案基本上也都是在解決一個問題：就是如何將多塊部署在不同數(shù)據(jù)中心上的數(shù)據(jù)盤（數(shù)據(jù)塊）邏輯上merge成一個。從接替思路上基本上有兩種：方法1：通過存儲設備層實現(xiàn)。如EMC的vplex解決方案，IBM的SVC解決方案，IBM的HyperSwap解決方案，浪潮存儲雙活方案等。都是通過存儲層來實現(xiàn)的。方法2：通過分布式文件系統(tǒng)實現(xiàn)。例如題主在問題里講到的GPFS解決方案，就是屬于這一類。通過GPFS分布式文件系統(tǒng)的Failure Group功能，將另一份雙活數(shù)據(jù)同步地寫到另一個數(shù)據(jù)中心去。以上是對

5、目前市面上的一些雙活方案的技術總結。雙活方案的優(yōu)缺點先來談談優(yōu)點：數(shù)據(jù)中心切換時間短：這個優(yōu)點是必然的，雖然在技術上無法實現(xiàn)完全的RTO=0，但是基本上可以控制在秒級。這已經(jīng)非常不錯了，無論是在銀行、證券。還是在社保、公安戶政、交警、這個級別的可靠性保證妥妥地沒問題。數(shù)據(jù)中心故障切換自動化：自動化切換是切換時間短的技術性保證。沒有自動化切換是不可能做到這么短的切換時間的。再來談談缺點：建設代價高：為了保證RTO和RPO同時為0，需要滿足的條件是非?？量痰?。1、是兩個數(shù)據(jù)中心的距離必須要短，最好在5公里以內。否則的話數(shù)據(jù)在兩個數(shù)據(jù)中心間的同步會拖慢整合業(yè)務系統(tǒng)。讓用戶感知下降，這個是我們最不希望看到的。2、網(wǎng)絡鏈路要求高：網(wǎng)絡鏈路延遲必須要低，并且不能有網(wǎng)絡抖動現(xiàn)象。最好是有單獨獨立的光纖。3、建設費用高：即使是只有上述兩點要求，這個建設的費用也是相當不低了。運維代價高：如果從應用系統(tǒng)級別就要實現(xiàn)雙活的話，那么就設計到應用服務器集群雙活、數(shù)據(jù)庫雙活、網(wǎng)絡雙活的多個方案集成。這個集成的復雜度，光想想看心里基本上就有點數(shù)了。因此對運維團隊的考驗是相當大的。最后的建議：雙活雖好，適不適合每個客戶的場景，這個問題