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