




版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領
文檔簡介
1、金融行業雙活數據中心架構設計最佳實踐一、 存儲雙活方面1、跨中心的雙活存儲數據一致性如何保障?一方面,當寫入數據時,在復制過程中,數據傳遞是在緩存中進行的,這樣做的好處是提升了性能,問題是當出現控制器節點異常宕機事件時,就會導致緩存內的數據不能寫入存儲中,從而造成數據的不一致,這時有沒有保障單個存儲數據一致性的措施?另外一方面, 兩個站點的存儲之間的數據一致性,從緩存層、底層數據層又是如何保障的?答:第一個問題:前端節點寫緩存與后端存儲間的數據一致性如何保障?存儲跨中心雙活中的單個存儲架構分為三種:1.物理存儲的內部雙控制器比如 V5000/V7000/V9000 HYPERSWAP,寫存儲的
2、操作也就是寫緩存的過程,寫了一個控制器,控制器也會將緩存數據同步至另一控制器的緩存,只有當真正同步完,這次的寫操作才算完成,當寫緩存達到水位線后,會將寫緩存刷入到磁盤組中,當一個控制器異常宕機時, IO HANG 住一小段時間,另一控制器將接管,緩存數據也不會因此丟失,一致性得到保障; 單控制器時,寫緩存被禁止,之前的緩存被刷入后端存儲,即使這時這個控制器也異常宕機, 后端磁盤的數據完整性和一致性也得到了保障;如果不幸兩個控制器的電源同時斷電了,這時寫緩存數據還未及時刷入磁盤組,不用怕,幾乎所有存儲都會考慮到這一點,都有專門的電池模塊維持供電幾分鐘,保證緩存數據能夠順利落到磁盤組當中。2.物理
3、存儲+存儲虛擬化網關(有寫緩存)比如 SVC ESC/HYPERSWAP,NETAPP MCC(叫寫日志),這種架構也就是相當于在物理存儲前端又加了一道控制器,也存在寫緩存,相當于擴大了后端物理存儲的緩存容量,寫操作 要先寫入 SVC 節點,再同步至另一 SVC 節點,只有完全同步成功,才算做是一個完整的寫周期,后面的操作也是等待寫緩存達到水位線刷后端存儲。佑了這種機制的保障,存儲虛擬化 網關的緩存與后端物理存儲的數據完整性和一致性得到保障,無論是單 SVC 節點故障,另一節點緩存數據冗余,寫緩存被禁止,所有緩存刷入后端存儲,還是 SVC 的電源斷電,SVC 有專門的 UPS 供電模塊保障寫緩
4、存及時刷入后端存儲,都能完整的保障數據的完整性和一致性。這里不再贅述。3.物理存儲+存儲虛擬化網關(無寫緩存)比如 EMC VPLEX METRO,它只有讀緩存,寫緩存還是由后端的物理存儲提供,所以該問題還是和前面說的類似的保障機制。第二個問題:兩個站點的雙活存儲間的數據一致性如何保障?這里分兩種方式來闡述這個問題:1.一種是兩個站點的主機識別的是相同的 VOLUME比如:SVC ESC、EMC VPLEX、HDS GAD 等,兩個站點的主機對這一個 VOLUME 寫操作時, 數據被刷入兩個鏡像的后端存儲,這有兩個存儲都寫完成返回,才算一個完整的緩存刷后端存儲的寫周期,這時兩個存儲從數據塊角度
5、來說,是一致的,一個站點或者存儲故障,另一個站點的存儲是可以接管,而不會造成數據丟失。2.另一種是兩個站點的主機識別的是不同的 VOLUME比如:SVC V7000/V5000 HYPERSWAP、NET APP MCC 等,由于兩個站點的主機識別的不是同一個 VOLUME,必然存在存儲或者存儲虛擬化網關的 VOLUME 與 VOLUME 的同步復制技術,HYPERSWAP 有 METRO MIRROR,MCC 有 Syncmirror,它們的技術共同點是復制技術的一致性校驗機制,更高級的有以多個卷為單位的卷組一致性校驗機制,來保障跨站點的兩個卷/卷組的一致性,在某站點所有控制器或者站點完全故
6、障時,另一站點有完整的、一致的存儲可以接管。2、存儲跨中心雙活是塊存儲的同步,無法避免邏輯錯誤被同步,出現該問題又該如何防范? 數據同步邏輯錯誤問題:存儲層面的復制技術基本以存儲塊為單位進行的數據復制,假設數據塊發生了邏輯錯誤,那么存儲是無法檢測到的,它會繼續將壞的數據塊兒同步到災備端,如果因此數據庫發生宕機,那么災備端的數據庫也同樣無法正常啟動。答:這是一個很典型的問題,塊存儲如何防范邏輯錯誤。做了存儲的跨中心的雙活或者做了存儲的鏡像,同步復制,很容易就會覺得數據有兩份甚至多份一致性的副本,就會覺得萬事大吉,甚至覺得不需要備份系統了。數據備份系統是企業數據安全的最后一道防線,無論做了什么同步
7、、異步、雙活還是連續性數據保護,數據備份系統都應該作為一個最穩固可靠的基礎的存在,地位無法替代。回到問題來,基于存儲的復制技術,無論復制方式是同步、異步、雙活還是連續性數據保護, 都是基于存儲數據塊級別的復制技術,復制源端在可讀時,會將塊中的數據原樣的拷貝一份至目標端,當源端數據出現誤刪、誤改、磁區退化數據異變、數據庫事物層邏輯錯誤等數據邏輯性錯誤時,復制目標端無法檢測到這些錯誤,依舊復制“錯誤”的數據,導致兩份副本都無法正常使用的災難。所以我們要有多層次的防范機制,來保障數據的可靠性和安全性,存儲雙活技術只是其中的一個層次,要輔以備份技術、數據庫復制技術,連續性數據保護,建立了完善的數據保障
8、體系。(1)備份系統按照一定的時間頻率對數據庫做全量和增量備份,在遇到數據邏輯錯誤時, 通過恢復將數據回退到最后一個備份版本。如 TSM、NBU、COMMVAULT。(2)數據庫復制技術有實時同步、準同步、異步等方式,保障主數據庫邏輯錯誤無法正常運行時,切至備數據庫,回退到備庫前一個日志 COMMIT 后的版本。如 DB2 HADR、ORACLE ADG、MYSQL 主從復制等。(3)連續性數據保護技術也是準/實時對存儲數據塊做快照,源端數據無法繼續使用時,通過快照回退至前一個數據可用版本。如 CDP。通常為了考慮不影響源端數據的訪問性能或者單個系統無法滿足需求時,可以考慮多種方式結合,比如備
9、份系統在備份超大數據庫時,沒有充足的帶寬或者備份時間窗口,可以用數據庫的異步復制方式來做為備份方式的補充;連續性數據保護技術需要通過 LVM 鏡像源端數據,增加了寫延遲,可以通過數據庫準實時同步或者異步的方式復制數據到備庫節點,備庫節點的后端存儲為連續性數據保護的存儲節點,如 DB2 HADR+CDP 的組合。所以總結來看,存儲跨中心雙活并不是萬能的,依舊需要傳統的數據保障技術輔助,建立常態高效的數據保障體系,才能應對萬難。3、兩個中心光纖距離 10KM,租用運營商的 DWDM,線路的穩定性依賴運營商?如何向運營商提出要求?答:鏈路冗余度方面:通常我們企業做雙活,都是自己購買波分設備,然后租用
10、運營商的裸光纖,作為通訊的鏈路。所以波分設備需要冗余,裸光纖也要冗余,波分設備好辦,購買即可。裸光纖通常租用兩家或兩家以上的運營商線路,比如電信和聯通,電信的裸光纖也需要冗余,聯通的裸光纖也需要冗余,防止單根裸光纖意外割斷或者損壞。然而單家運營商的裸纖都通常在一個弱點井中,一起意外割斷的事情常有,所以需要兩家運營商互相冗余。這兩家運營商裸纖的路線還不能一致,弱電井需要在不同的街道,并且分別走不同的路線到達目的地。所以可以看到,由于我們是租用,根本不可能要求運營商完全達到你的要求,最好的方式只能自建,成本太高,好像根本不現實。鏈路質量方面:鏈路質量包括光衰、抖動和帶寬等。一方面,光衰和抖動無法控
11、制,只能靠波分設備去探測,發現光衰和抖動,立即中斷該鏈路,切向備鏈路,這對后端的 SAN 網絡無感知,但對波分設備的要求很高,需要購買和建設時注意。至于帶寬,可以監測,達到帶寬預警閾值后,可向運營商申請提升帶寬。另一方面,對于鏈路質量的監測機制一定要在建設存儲雙活或者其他雙活之前建立,由于是運營商的鏈路,鏈路經過了多少中繼、多少設備我們是不得知的,我們只能在波分端建立有效的監測機制,有些波分設備也有專門的監控軟件支持。而且也要要求和運營商建立監測聯動機制,運營商監測到鏈路質量(是質量而不是中斷)有問題,也需要第一時間告知,做出合理的決策。4、想了解誰有 infiniband 下的存儲雙活的經驗
12、答:目前,支持 Infiniband 的存儲設備很少,支持雙活功能的就更少。Infiniband 用在 HPC 領域的并行數據訪問的環境中比較多,如在航空航天、石油勘探、汽車設計等,為了保證數據訪問的高性能和低時延,利用 IBM Spectrum Scale (GPFS)+ Infiniband 構建大型并行文件系統的案例很多。并且,IBM 的 Spectrum Scale 也支持基于 IP 網絡的跨數據中心的雙活功能,在銀行和電信運營商都有實際案例。5、 FC 模式下,時延太高,長距會有問題,對 oracle RAC 支持有問題答:在存儲雙活環境中,對兩個數據中心之間 SAN 網絡的時延要求
13、比較嚴格,所以,一般最佳實踐都建議兩個數據中心的距離不能太遠,盡管理論上和少數專有環境中(如 IBM 大型主機+IBM DS8000)可以支持高達 100-300KM 的距離,但一般建議不超過 3050 公里,并且是裸光纖或者 DWDM 環境。6、 小同城大異地模式,異地集群有什么好的思路不?文件共享如何實現,應用時候有必要著手從傳統 nas、gpfs 向對象存儲的改造答:跨中心的文件共享,除非是只基于 LAN 而非 WLAN,由于 NAS 對 WLAN 的支持不夠好和穩定,否則建議采用集群并行文件系統方式或者對象存儲方式來實現文件的共享。例如,IBM 的 Spectrum Scale(GPF
14、S)具有 AFM(活動文件管理,Active File Management) 功能,支持多中心的數據共享和文件訪問,并且支持 WLAN 的環境,還能夠實現多中心的數據災備和雙活。IBM 的對象存儲 COS(Cloud Object Storage)支持三中心部署模式,支持 WLAN 環境,只需要付出大約 60%的冗余度(即存儲 100TB 的數據,只需要大約 160TB 的物理容量),就可以實現防止站點級別的災難。二、 應用雙活方面1、單應用雙活本身不難,但難在如何解決應用間跨中心穿插交互的問題,如何解決該問題?答:關于這個問題,有以下四種應對策略來解決該問題:1、盡量減少跨中心應用間交互2
15、、兩個數據中心重要業務系統間盡量解耦合,各成體系,獨立運作3、允許必要的跨中心互聯,如非雙活數據庫、核心、只能主備模式的系統的訪問4、鏈路加強監控及鏈路波動/中斷后的應急機制2、如何實現雙中心之間的文件數據同步,包括聯機交易和批處理數據? 答:對于跨中心的文件數據共享,可按需求分類考慮:1、有數據共享需求,而且對 IO 性能要求較高的,只能用 SAN 存儲雙活方式2、對 IO 性能要求一般的,可以采用共享文件系統實現,如 GPFS SERVER+CLIENT,NFS Server+Client 或者雙活 NAS 等3、對 IO 性能要求較低的,屬于海量非結構化數據共享的,可以嘗試用跨中心的對象
16、存儲實現三、 數據庫雙活方面1、 雙活仲裁機制:存儲雙活與 DB 協同仲裁的機制與原理?答:假設定位到存儲雙活,那么是不是就割裂了數據庫層的仲裁問題。實際上存儲最終是為上層數據庫及應用服務,如果這個跨中心的架構涉及到數據庫、存儲兩層的組合,比如說存儲雙活之上是 oracle rac,那么就比較復雜了。首先對于存儲本身的仲裁,應該有自己的算法,例如:(1)仲裁站點,獲取了仲裁站點的投票的一方獲勝(2)最壞情況下,默認的算法(3)偏好仲裁模式,偏好設定仲裁獲勝的站點 對于跨中心的 rac 集群,同樣有自己的規則:(1)仲裁盤(2)通過網絡和磁盤心跳保證獲得票數最多的子集活著。(3)實例 ID 小的
17、節點存活。但是當存儲雙活和數據庫雙活二者結合的時候,就有更復雜的場景可能會出現,尤其是出現兩層架構仲裁的結果不一致。為了避免這個結果出現,那么我們需要攻克以下問題:如何保障仲裁觸發的時間序列一致。可以設定雙活存儲仲裁的超時時間小于數據庫仲裁的超時時間,來保證雙活數據庫的仲裁是在雙活存儲仲裁完成之后進行,這是目前通用的做法。極端情況下的仲裁算法一致性。可以設定偏好模式保證數據庫和存儲仲裁的結果是一致的,如將 ORACLE 實例 ID 小的放在偏好的站點 A,存儲雙活仲裁設為偏好模式,保證仲裁結果基本在站點 A。2、想咨詢一下 db2 數據庫更換存儲(只更換存儲)有什么好的方案及相關的操作步驟?答
18、:有對于數據庫更換底層存儲我們實踐過多次,通常按照以下四種標準做法去做,都基本沒什么問題:1、方案一:操作系統層數據鏡像技術,如 AIX LVM,步驟如下:(1)映射閃存陣列的 LUN 至 AIX OS,并加入 VG(2)將原傳統陣列 LUN 和閃存陣列 LUN 做 LVM(3)同步完成后,找停機窗口,從 VG 中拆除鏡像,剔除原傳統陣列 LUN(4)重新激活 VG,并掛載數據文件系統,驗證2、方案二:數據庫備份恢復和 OS 層面的克隆技術,如數據庫:DB2 BACKUP/RESTORE,ORACLERMAN,OS 克隆:AIX ALT_DISK_COPY,VM SNAPSHOT,VM P/V
19、 to V 等,步驟如下:(1)搭建新環境,該環境存儲采用閃存陣列(2)通過 OS 層面的克隆技術,將 OS 數據復制/遷移至新環境(3)通過數據庫層備份恢復,將數據庫數據恢復至新環境,并驗證3、方案三:存儲本身自帶的 LUN 鏡像技術,如 IBM V9000 等(1)找停機窗口,將原傳統陣列 LUN 映射至 V9000(2)在 V9000 中,將原傳統陣列 LUN 數據鏡像(VDM)至 V9000LUN(3)待鏡像同步完成后,將兩個 LUN 主備關系反轉,閃存作為主存儲,原傳統陣列 LUN 作為備存儲(4)將兩個 LUN 虛擬化后形成的 VDISK 映射至主機,驗證,此時主機存在 V9000
20、 和原傳統陣列兩份數據保護4、方案四:存儲虛擬化網關的 LUN 鏡像技術,如 IBM SVC、EMC VPLEX 等(1)找停機時間,取消原傳統陣列 LUN 至主機的映射,將該 LUN 映射至虛擬化網關進行管理(2)虛擬化網關將該 LUN(mdisk)虛擬化成虛擬 LUN(vdisk),并映射給主機(3)創建 vdisk 的閃存陣列 LUN 鏡像拷貝(4)待拷貝完成后,將閃存陣列 LUN 置為主拷貝,原傳統陣列 LUN 置為備拷貝(5)驗證答:1)在線更換存儲方法:首先將新的存儲設備接入現有的服務器,然后利用操作系統的裸設備的鏡像功能(如 AIX 操作系統的 LV Mirror 功能),在線將
21、 DB2 數據庫的所有裸設備和數據全部鏡像到新的存儲,當新舊存儲設備的數據全部鏡像完畢達到同步時,將舊存儲拆除, 完成存儲更換。這個方法的好處是可以完全在線操作,基本不影響生產;不利的地方是需要考慮同一臺服務器同時訪問新舊存儲的多路徑軟件的兼容性問題;還有就是一般情況下,大型數據庫的裸設備(LV)都比較多,不能有任何遺漏。2)準在線更換存儲方法:可以考慮使用存儲虛擬化設備,如 IBM 的 SVC,實現準在線的存儲更換方法。首先將存儲虛擬化設備 SVC 和新存儲接入現有 DB2 數據庫的 SAN 環境和服務器環境,并實現 SVC 對新存儲的管理;然后選擇恰當的時間,將 DB2 數據庫停下,實現 SVC 對舊存儲的管理,并通過 SVC 將舊存儲中的 LUN 以 Image Mode 的形式映射給現有服務器, 服務器可以讀寫原有的 DB2 數據后,馬上將 DB2 數據庫重啟,恢復業務。然后利用 SVC 的在線數據遷移功能(或者磁盤鏡像功能,如 VDM),將數據在線遷移到新
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
- 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
- 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 沙河紋眉活動策劃方案
- 概念活動策劃方案
- 武術公益課活動方案
- 母親節網上活動方案
- 檢察院包粽子活動方案
- 夢幻西游端午活動方案
- 樓盤合影活動策劃方案
- 水族館展覽活動方案
- 植物變色大賽活動方案
- 正宗草莓促銷活動方案
- 《 民航服務心理學》考試題及參考答案
- 公務員培訓包過班協議書范本
- 2021學堂在線網課《生活英語讀寫》課后作業單元考核答案
- 中國近現代史綱要超星爾雅答案貴州大學-
- 職業危害防護設施、器具檢查維護記錄
- 食品全過程防護工作手冊(食品防護計劃)
- Q∕GDW 12162-2021 隔離開關分合閘位置雙確認系統技術規范
- 燃氣入戶安檢培訓PPT.ppt
- 臨概題庫(南醫大)--內科部分
- 古代漢語授課教案(郭錫良版)教案分享
- 裝載機驅動橋培訓
評論
0/150
提交評論