電子發燒友App
災備技術涉及的領域很多，有很多廠商提供了多種技術解決方案，當前比較常見的數據復制技術有幾大類，例如基于傳統存儲的復制技術，技術數據庫的復制技術，基于存儲虛擬化網關的復制技術，基于主機卷管理的復制技術，基于備份的復制技術等等。
關于傳統存儲復制的痛點，大家主要關心如下幾個方面：
1. 生產中心與同城災備中心采用同步復制遇見的痛點
2. 存儲復制中的復制鏈路上的痛點
3. 存儲和主機密切相關的多路徑軟件的痛點
4. 基于存儲復制技術的兩地三中心解決方案的痛點
5. 雙活數據中心中仲裁技術的痛點
6. 數據復制所帶來的數據完整性，一致性的痛點
7. 數據復制的安全性的痛點
8. 災難恢復演練中關心的問題
下面逐一加以分析和總結
[*本文主要觀點來自多位社區專家及會員分享，由社區專家張鵬匯總、梳理]
一、生產中心與同城災備中心采用同步復制遇見的痛點
[典型問題]
同步復制技術讓生產和災備中心的聯系過于緊密，這樣的技術風險點我們該如何規避?
[問題描述]
存儲同步復制技術通常應用于生產和同城災備中，同步技術將生產中心和同城中心的聯系過于緊密，生產中心的數據變化會及時同步到同城中心.
就像2015年銀監會發布的162號文件中提到的，某銀行生產中心數據庫文件的損壞導致生產中心的數據庫故障，中斷業務，由于該行同城災備中心采用了存儲級同步復制技術，數據庫損壞文件被復制到災備中心，導致災備中心也無法恢復業務。
這種問題是不是技術上的必然風險點?廠商應該如何以此為鑒改進產品?用戶應該采取何種措施規避這種風險?
[問題描述]
還有朋友提出這樣的問題：
“能否這樣理解：傳統存儲復制技術的致命弱點就是應用如何隨生產變更而變更?”
[觀點總結]
?觀點一：
關于這個問題，可以談談可追溯功能的災備解決方案。不管存儲復制采用同步還是異步復制技術，都只能體現當前或者某一個時間點的狀態，不具備追溯功能的災備解決方案，在應對邏輯錯誤或者上訴文件損壞的時候就顯得力不從心。快照技術是一種解決方案。并且很多第三代存儲都實現了不限數量，或不限頻率的快照解決方案。我們迫切希望傳統存儲廠商在更多的高端存儲解決方案中進行改進。
?觀點二：
可用多個存儲復制版本解決 (消耗大量存儲空間)，保存一天前或一個星期前的 版本，再次保存一個同步版本。
?觀點三：
存儲級同步復制在生產端數據由于外部因素被損壞的時候，可能災備端也難以幸免，因此可考慮進行應用級別的同步，同時增大備份頻率，將數據丟失降至最小。
觀點綜述：
同步復制的技術原理決定了生產中心和采用同步復制的同城災備中心的數據改變是一致的，在存儲底層復制單元以上的錯誤，例如邏輯上的錯誤，同步復制會將錯誤一并復制到災備中心，為此出現此類錯誤，是同步復制為之所痛的地方，如何防范呢，我們希望廠商能夠采用多副本的機制例如頻繁的快照技術提供可追溯的災備解決方案，盡量減少發生此類故障時的損失。
二、存儲復制中的復制鏈路上的痛點
[典型問題]
存儲同步復制技術中，遠距離光纖傳輸的延時、抖動等線路問題風險如何避免?
[問題描述]
存儲同步復制技術通常應用于生產和同城災備中，生產存儲和同城災備存儲通常采用光纖通道SAN網絡連接，其光纖線路距離通常為幾十公里，長距離傳輸線路的不穩定因素，例如延時，抖動，都會給存儲復制帶來影響，有時甚至是災難性的影響。
今天就來分析一下，存儲同步復制由于光纖網絡線路的問題出現的風險。
同步復制出現鏈路抖動，會影響到生產運行，那么異步復制出現鏈路抖動會不會影響生產運行呢?
同城災備或異地災備建設中，鏈路距離和網絡延遲對于應用場景的考量如何?
在鏈路距離和延遲方面對于不同的場景要求也是不一樣的，是否有具體案例可以針對性的數量一下這方面的問題，遇到問題時對應的解決方案又有那些?
網絡抖動對于同城間基于存儲的數據同步復制的影響有多大?如何減少網絡抖動的概率?
同城間基于存儲的數據同步復制方案受網絡抖動尤其是頻繁發生抖動的對源端主業務的影響程度有多大?要減少網絡抖動發生的概率，在網絡設計及規劃時有什么需要注意的?
[觀點總結]
?觀點一：
線路鏈路實施監控跟蹤和運維服務商鏈路穩定性質量有關，相關線路鏈路應急預案和恢復手冊，希望對你有幫助，謝謝!
?觀點二：
關于延時，一般沒有辦法，只能找運營商;
抖動問題給你兩個建議：
1、實時監控SAN交換機級聯鏈路端口(porterrshow)，一旦發現大量報錯，立刻disable這個端口;保證生產端可用。
2、采用iprouter鏈路(博科交換機的7800),將不同廠商的鏈路進行綁定(目前在同步環境下的案例，但是異步情況下案例很多，按照原理應該可以解決抖動，而且目前IP的延時也很短了)
?觀點三：
同城或異地災備或者雙活鏈路抖動是不可避免的，主要考慮的是應用能夠接受的程度。目前來說超過50KM距離的場景，應該不會有廠家拍著胸脯打包票的。
?觀點四：
主要還是看系統的RPO和RTO的要求，有些災備數據是異步復制的，有些實時同步的，對不一樣的系統采取的手段不一樣，有些就是實時的傳輸，異地Standby，還有一些是拷貝一些備份數據到異地之后進行數據恢復，金融行業對于實時性要求較高。
?觀點五：
例如網絡延遲較大時對證券行業有很大的影響，因為證券行業的特殊性要求數據傳輸實時性高
?觀點六：
實施前是要對運營商線路進行檢測評估的。
?觀點七：
同城間距離及交易情況和RPO要求來評估鏈路類型和帶寬。前期需進行光強度衰減和時延測試。
觀點綜述：
大家對復制技術中的鏈路環節還是尤為關注的，通過大家提出的問題，我們不難發現遠距離傳輸的延時和抖動問題，一直是復制技術中的痛點。那么如何解決呢，看來大家更多寄希望于運營商是否能夠提供高質量的線路。同時在運維過程中加強監控和應急防范。
三、存儲和主機密切相關的多路徑軟件的痛點
[典型問題]
多個廠商的多路徑軟件裝載在一臺主機上的風險，以及多路徑軟件在存儲雙活架構中的風險怎么辦?
[問題描述]
主機連接存儲多路徑的問題，這個問題很早開始就一直存在，主要是主機連接多個存儲時，每個存儲廠商有獨立的多路徑軟件，主機上是否安裝多個廠商的多路徑軟件，一直是用戶困惑的;隨著雙活數據中心解決方案中存儲雙活的架構出現，主機多路徑在災備技術中也占據著重要地位。
今天主要來分析一下兩個問題：
老問題：多個多路徑軟件裝載在一臺主機上帶來的風險?
新問題：多路徑軟件在存儲雙活中的風險?
[觀點總結]
?觀點一：
先談談老問題：多個多路徑軟件裝載在一臺主機上帶來的風險?
我想在這個問題上好多實施人員都會遇見，多數的解決辦法是為了避免相互扯皮，在一臺主機上只裝一種多路徑軟件。實際應用中，多個多路徑軟件在一臺機器上運行，也是存在的。為了避免實施人員和客戶的困惑，我們更多的是要呼吁，存儲廠商盡量兼容操作系統廠商發布的原生多路徑軟件。主機的問題讓主機去解決，存儲的問題讓存儲去解決。
?觀點二：
再談談新問題：多路徑軟件在存儲雙活中的風險?
現階段存儲雙活架構中多路徑軟件扮演了重要的角色，多路徑軟件是否可靠，設置是否正確，是架構穩定性的關鍵。考驗廠商和實施團隊的時候到了，請大家關注長距離傳輸路徑和本地路徑是有區別的，多路徑中路徑的選擇是要充分考慮這個問題，避免不必要的風險發生。
?觀點三：
有關一臺主機上安裝多種多路徑軟件的場景應當盡力避免，在源頭就減少這種情況的發生。舉個例子：使用powerpath的多路徑軟件，可以驅動sdd，sddpcm的產品的盤符變化，導致管理和使用上的一系列問題。
參考解決方案：
1. 可以考慮使用存儲虛擬網關
2. 同一種應用盡量使用同品牌的存儲，使用一種多路徑軟件進行管理。
?觀點四：
生產環境中 應避免 一個lpar使用多種存儲 安裝多個多路徑軟件問題
?觀點五：
多個多路徑軟件裝載在一臺主機上帶來的風險?可能造成兼容性問題
?觀點六：
多路徑軟件在存儲雙活中的風險?只使用存儲雙活設備指定的多路徑軟件即可。
?觀點七：
先談談老問題：每一個廠商針對針對自家存儲設備的多路級管理軟件都會開發一些高級功能、監控功能和優化手段;比如說：路徑不穩定時候，多路徑管理軟件就會監控一些參數指標，當某些指標達到一定數值，多路徑軟件就自動執行一些操作保證生產和性能;不同廠商的操作可能不同，因此可能產生一些故障;而且不好去解決。
?觀點八：
雙活環境下多路徑軟件，對路徑組合的監控以及監控參數更加多了;判斷項也更多了，我也感覺到參數設置對架構穩定性至關重要。
觀點綜述：
主機端多路徑兼容的問題一直是大家關注的問題，值得一提的是，更多的廠商已經通過支持操作系統原生的多路徑軟件而解決兼容性的問題了，雖然原生多路徑和廠商特有的多路徑軟件有一些功能上的差異和缺失，但是隨著技術的革新，未來應該會有好的改變。存儲雙活解決方案中多路徑軟件起著重要的作用，希望大家在使用過程中得以重視，合理配置，強加監控，防范風險。
四、基于存儲復制技術的兩地三中心解決方案的痛點
[典型問題]
兩地三中心的存儲復制技術中，三角形復制架構，生產到異地的復制鏈路真的有用嗎?
[觀點總結]
?觀點一：
經常看到和聽到的架構是這樣的。理論上生產數據復制到異地的備份也會對數據有保障，但是架構越復雜，維護，操作起來也越復雜，往往這樣的架構最后出問題的并不是數據復制鏈路本身。而是在生產系統故障的時候業務割接時候的其他問題。
舉個簡單的例子，剛剛做雙機結構的時候。是微軟win2000+sql2000的架構，做的過程是裝好兩臺系統，配置雙機結構，然后在主機上安裝SQL,這樣備機也同時安裝上了sql2000，當主機掛掉，備機會自動接替主機工作，到這里位置一切都很理想，但是很快我們就放棄了這種結構，因為1，當主機故障，備機切換了以后。我無法在線把主機在添加到這個雙機結構中，只能把整套雙機環境全全部推了重來，2，兩臺機器不能同時啟動，否則會因為爭搶資源而導致雙機結構崩潰。
現在的技術發展的自然比起零幾年的時候要先進了許多，但同樣會因為某些條件至于而導致這種理想的架構真的在出現故障的時候能理想的實現智能接管。所以雙活也好。兩地三中心也好。有成熟的容災方案，做定期的容災演練是保證系統架構運行的根本。，如同拿著倚天劍的人一定要是個武林高手。否則可能傷到的會是自己。
?觀點二：
這個問題很奇特，當然是由用的，沒有建它做什么，關鍵看你為什么要建，目的是什么，建災備的需求，響應級別。
如果說你是認為，本地雙活完全能滿足生產環境的高可用需求，那就要看是否能滿足用戶的業務和管理需求，有不少企業做災備不是為了別的就是為了審計或等保的需要。
你有沒有聽說過某個IDC機房因失火，造成對外業務全部中斷的情況，雖然可能，但基本沒有發生過。那做了數據同步建了災備機房是否就安全了，如果恰巧2個機房相聚數十公里卻在同一個地震帶上時會發生什么...............
這也就是開始說的，為啥要建災備，目的、需求、預算要先搞清楚，才能設計建設有效的災備環境。
?觀點三：
在災備系統上見過這樣的系統，但是業務生產上沒有見過有客戶這么花氣力。
災備系統是A--B---C，但C不復制到A，是一個不閉合的三角模型。即使是一個災備三中心，也是相當花錢的。備份存儲都是EMC DataDomain的高端產品，都是窄帶復制傳輸，運行也沒有問題。恢復驗證也測試過，安全性確實有提高，但是三中心數據一致的滯后性還是很明顯，基本都在3H左右，數據量大的時候滯后更多。可想而知，如果是業務上三中心互備，算上SAN網絡、設備、存儲，估計不是特大公司都不會采用了吧。
?觀點四：
還是有用的，當同城災備中心的異地中心鏈路有問題的時候，異步數據將自動的通過生產中心到異地災備中心鏈路進行數據傳輸
觀點綜述：
大家談到了兩地三中心災備架構的重要性，其實這點我們都是認可的。大家可能沒有理解這個問題的真正含義，這里主要想描述的是很多廠商和客戶想要達到的三角形閉合的兩地三中心架構，主要糾結在A和C 是否有必要連接。
在真實的災難場景中，生產中心發生災難，肯定是優先選擇同城災備中心的，因為同城災備中心的綜合配置多數都優于異地災備中心。只有生產和同城都發生災難，這種區域性災難的發生才考慮異地災備中心接管。所以我個人認為過多關注與A-C的閉環架構沒有太多必要。
五、雙活數據中心中仲裁技術的痛點
[典型問題]
Quorum/Tie-Breaker對于避免腦裂和場地分割有效嗎?仲裁技術是否會給生產數據中心帶來風險?
仲裁機制會不會同樣帶來對生產數據中心的風險?多數用戶真的做到第三數據中心仲裁了嗎?
[觀點總結]
?觀點一：
仲裁機制還是有必要的。如果兩個數據中心斷開，至少仲裁服務器能在其中一邊把應用拉起，避免腦裂。如果能有第三數據中心仲裁的話，那樣最好。
?觀點二：
跨數據中心的存儲集群技術，必須要有仲裁機制作為保障，希望廠商在這方面加強技術改進，不要讓原本作為防范機制成為風險的隱患。
觀點綜述：
關于防范腦裂的仲裁問題不僅僅是在存儲雙活解決方案，虛擬化存儲雙活解決方案中用到，在主機HA的方案中更為廣泛的應用。腦裂一直是集群技術中的痛點，為了避免腦裂的發生，廠商想出了多種辦法，其中包括仲裁機制。在這里引出這個痛點主要是想提醒更多的用戶慎重看待每一個風險點，仲裁也許是解決腦裂的一個好辦法，但是它也許也隱藏著其他隱患。如何防范，需要加強運維和應急處置。
六、數據復制所帶來的數據完整性，一致性的痛點
[典型問題]
通過存儲復制技術，在手工暫停存儲復制后，災備端數據庫仍然有一定幾率拉不起來。存儲復制的目標端如何保證數據庫能夠拉起來?
同步復制和異步復制是否成功，如何驗證?有哪些方法?
[觀點總結]
?觀點一：
一般情況下，只要你能保證所有卷組的設置了一致性情況是能保證的。如果還是不行，你可以寫一個腳本，先將oracle處于backup狀態，立刻停止復制(只對同步有用);再將oracle數據庫處于正常狀態。
?觀點二：
只遇到過同步復制,2邊數據不一致的問題
?觀點三：
復制是否成功，主要看存儲管理界面顯示的狀態，是否有復制中斷，但是不能確保數據完整和一致性。
觀點綜述：
歸結起來還是災備數據和源數據一致性完整性的問題，看來大家在實際環境中確實遇見過災備數據不可用的情況，這的確是數據復制中最大的痛。雖然存儲層面可以通過設備狀態，日志等方式監控復制的完成情況，但是無法從業務數據層面來做數據的檢查。需要通過工具或管理方法定期從業務數據層面來做檢查。來驗證災備數據一定與生產數據一致性，防范真正災難發生了，災備數據不可用的風險。
七、數據復制的安全性的痛點
[典型問題]
如何保證存儲復制技術中，數據傳輸的安全性和可靠性?存儲加密技術給數據傳輸帶來的影響有多大?
[問題描述]
數據傳輸的安全一直是監管機構的關注點，存儲復制就涉及到數據傳輸，那么如何保證安全不被篡改和非法獲取呢?是加密技術嗎?
那么問題來了：目前廠商的產品中是否都具備加密技術?這些加密真的可靠嗎?加密給效率帶來的影響是否很大?有用戶真正在使用嗎?
關于加密，這里想談一個問題，數據傳輸時是否需要增加加密功能，開啟加密功能對復制的影響有多大?
[觀點總結]
?觀點一：
存儲級別的復制都會自帶校驗和加密，校驗能保證收發數據一致，加密能保證數據安全。存儲上的數據本來也不是明文而是數據塊，因此再加密后，數據一般很難破解。倒是存儲換下來的壞盤，如果重要，建議購買留盤服務。現在采用存儲級別的復制的客戶也很多了，實施順利的，現在也少有聽到故障重重的案例。
?觀點二：
加密解密這種對數據的附加操作，是否會對數據完整性有影響。其實這個問題和數據傳輸是否壓縮，是否去重類似。加解密，壓縮，去重，這些對數據的操作，正常情況下是對數據完整性無影響的，當然也存在異常的因素。數據遠距離傳輸不管是否經過加密，壓縮，去重等加工操作，數據的完整性都存在異常的可能。那么我們所關注是否有一種機制，可以定期去檢查復制兩端的數據一致性。
?觀點三：
網絡層面考慮使用安全性較高的專線線路，可保證傳輸安全。
觀點綜述：
首先安全是任何時候都必須關注的。安全分為數據完整性，數據可靠性，數據防篡改性等等。災備是為了防范數據丟失的安全風險，同時也要綜合考慮數據的安全性。所采用的安全手段應該是對數據安全有利的，而不會反而成為風險隱患或性能隱患。
八、災難恢復演練中關心的問題
[典型問題]
上了災備后，怎么進行演練?
多長時間進行一次災備演練?
切換后對數據是否異常有什么好的方法進行驗證碼?
演練中你曾經跳進過哪些坑?
[觀點總結]
?觀點一：
主要是手工切換，一年一次或者兩次。
?觀點二：
演練是必須的過程，一年一次是必要的。每次演練都可能能發現之前的手冊的不完善，并加以補充完善。還有演練需要有實績業務支持才能驗證其有效性。災難時的應急預案要實現準備好，應急流出要梳理清楚。系統相關業務、技術人員的應急手順書都要有，并且經過培訓和模擬測試。災備系統演練時需要退避生產系統，網絡、存儲、主機從災備端開啟后，模擬生產環境進行測試，網絡外部接口全部封閉，避免不正常的業務數據通過接口流出，造成其他在線系統的異常。演練過后能鏟掉災備環境的數據，恢復生產環境的網絡存儲主機。
?觀點三：
模擬演練，一般一年要做一次，可以安排在業務非高峰時段，證券行業比較特殊，一般每年會有那么兩次演練。
?觀點四：
災備演練每年至少演練一次，演練類型可以是模擬演練、實戰演練、部分演練和全面演練。大多企業采用模擬演練。
?觀點五：
廠家提供的災備方案通常只能提供底層的存儲接管和應用的啟停。真正實施的時候一定要熟練掌握本地應用系統的技術人員協同實施。我碰到過廠家實施災備系統后(WAS+DB2)操作系統切換，WAS應用確實在備機上自動啟動起來了，但是因為實施時應用程序包沒有放到共享存儲中，兩臺機器本地存儲各放了一份。導致新的WAS運行的程序包是最老的版本，導致切換失敗。
?觀點六：
版本不一致這個也是一個問題
?觀點七：
做好數據同步，確保容災端的數據和應用都是最新的，配置文件也不能錯
?觀點八：
切換后注意對關聯系統的影響，注意IP地址，確認業務運行在哪一端了。(網絡策略很重要)演練盡可能減少對生產的影響。
工商網監
評論