在容災的方案中，用戶往往會根據預算和業務不同的安全等級要求，制定不同級別的容災方式，更有一部分最終用戶，對安全及潛在的風險知之甚少，至少我遇到部分客戶是這樣的。
通常我比較中意與金融行業的客戶討論方案，我想這一態度會有很多同行與我達成共識，最主要因爲他們通常走在技術最前沿，更快的嘗試新技術(畢竟人家有錢嘛)，能夠更好的找到方案的切入點，並且管理人員能夠更專業的提出一些需求，通常這些需求他們已經認識到，在技術上已經可以解決。
如果我們不考慮客觀因素，如何提供一個高安全級別的方案給用戶 ？
分享下以往的方案，以及我對容災安全方面的一些認識，在內容裏我刻意省去一些宏觀的理論，比如RPO，RTO，或投資回報率之類的，原因在於，我想更貼切的表達我想要表達的內容，而那些通常我只是在方案裏面湊字數。
High Availability+Remote Replication +CDP
-至少我認爲這是目前最佳的業務連續性方案
--------------------------------------
（一）High Availability__高可用
對於高可用性的理解，集成商經常會通過不同的方式展現給用戶，而無論如何展現，都是在盡最大力度包裝其方案，使其更完美。導致一些潛在問題無法被客戶重視，在今後的運行中，必須花更多時間修復這些“方案Bug”。SNIA權威的定義了高可用性的概念，而目前技術則能夠做的更出色，我們升級這個概念爲：
當主機意外停機時，業務能夠無縫轉爲連續性，並且能夠自動的同步增量數據，無需人工干預。
應用主機：
可以使用應用業務本身的集羣功能，如MS Failover Cluster，AIX HACMP，Oracle RAC,VMware vSphere等等，這樣能夠保障應用主機方面的高可用性。採用第三方集羣軟件可能要考慮到兼容性和監聽參數，並且市場絕大部分的集羣軟件並不支持-負載均衡機制，僅僅做到應用主機之間的Failover,而這一點Oracle RAC和vSphere絕對會更有優勢。
存儲層：
在高可用性的方案中，對存儲設備提出了更高，更苛刻的要求，而不僅僅基於RAID磁盤的保護。我們希望應用主機集羣之間的共享卷時刻響應服務。如果不能夠做到這一點，主機已經部署的集羣系統將會蕩然無存，因此，存儲層的高可用更爲重要。
關於存儲層的高可用性方案，我們有很多選擇的餘地，但是哪些是我們想要的？
以下有三種方案可選：
1）基於CDP高可用性方案，目前仍然有廣泛的市場，這些產品通常會在應用主機安裝代理軟件，分拆IO至CDP的設備，待主存儲故障，由CDP設備進行指定時間點的回退。由此我們需要至少考慮4個問題：需要手動掛在備援卷時間通常是多久？對主機原有性能的影響，甚至說最初設計主機硬件平臺時，我們需要把CDP所損耗的性能計算進去？與操作系統的兼容性？支持多少個主機集羣？按照自身的經驗來說，我認爲這對主機性能是個不小的損耗，並且產生惡性的放大效應，尤其是CPU。當主機業務繁忙時，必定會產生更多的IO，此時主機需要更多的性能處理業務，而就在此時，CDP的代理軟件同樣提出了更高性能需求，因爲有更多的IO要處理，看來EMC當初把分拆IO的工作交給SAN Switch確有優勢。另外，分拆IO到CDP的設備是實時寫入的嗎？這一點很重要。如果是實時的，意味着CDP存儲設備寫入的性能至少要高於主存儲，否則會降低原有的IOPS。如果不是實時寫入的，意味著在應用主機會有Buffer，當主機意外停機後，會導致數據丟失，而丟失的程度卻居於Buffer到底有多少東西。
通過以上來看，依靠CDP高可用架構設計，考慮的因素確實很多，有更簡單的嗎？往下看：
2）通過應用主機來完成高可用，IBM在一些方案希望那些小型環境用戶通過AIX邏輯卷管理工具(LVM)完成存儲與存儲之間的Mirrored，由於兩套存儲之間是Mirror，當一臺存儲設備故障，而第二臺則可以接管。
VERITAS則是在應用主機徹底安裝一個文件系統，允許添加更多的存儲設備進行Mirror，或者包含了更多的功能。這兩方面來看，應用主機在承載業務同時還充當一個軟RAID的，這對主機性能影響會比CDP來的更沉重。
無論是CDP或者基於應用主機卷鏡像，能夠帶來很多的思考，如果我們的容災節點建立的兩個數據中心，比如100km,業務是否會因此而造成隱患，尤其是面對巨大，且無法估算的延遲。其二，爲什麼不能把這些工作單純的交給存儲層來做，而應用主機主機專心的提供生產服務。
3）基於存儲層的高可用性方案，目前一線存儲廠商均能夠提供此方案，依靠中，高端的存儲產品。使用兩臺或多個存儲節點集羣，存儲陣列所提供給應用主機的每一個共享卷會Mirroring到另外一套存儲設備，應用主機不會感知鏡像卷的不同，照常進行讀寫操作，很多時候依靠應用主機的MultiPath Software對鏡像捲進行聚合與Failover工作，只是當一臺存儲節點故障，MultiPath Software會及時切換至另一健康路徑，而這條路路徑有可能指向另一臺存儲節點。存儲節點之間可以部署在同一個機房，或者有限距離內的同城之間。一些高端的容災存儲已經擴展到了遠程複製功能，允許再次把鏡像卷複製到另一個地區來減小災難影響。這類廠商和技術類似：IBM PPRC,HDS TrueCopy,EMC SRDF......。總之，整個數據同步週期完全脫離應用主機，完全由存儲之間，及存儲之間的高效鏈路來完成。
用於高可用的存儲節點之間，如果支持負載均衡，那就再好不過。我們都知道，這與存儲陣列的雙控之間雙活完全不是一個概念。在位於兩個站點之間的獨立的存儲設備，在任意時間，完全允許應用程序寫入數據，而不是一臺Active，另一臺等待Failover，這是實際意義上的雙活，當與那些具備負載均衡高級集羣程序配合，可發揮更大效益，如Oracle RAC，VMware vSphere等等。
基於存儲層的高可用無疑是一個不錯的選擇，是否還有其它注意的？
首先，通常來說，客戶必須購買兩個或多個同廠商，同型號的設備，這是被綁定的，其次需要一筆昂貴的預算，因爲這類方案的設備通常是中，高端的。再有就是目前已有的存儲設備，無法再利舊，或與其相容性的工作等等；（這些問題也能夠規避，我寫在另一篇博文）詳見存儲虛擬化。
若干個容災存儲設備之間，爲了保障及時Failover響應，節點之間數據任何時刻都會是一致的。OK，這也延伸出來第二個問題，如果位於主存儲上面一個卷，遭受到網絡***，病毒蠕蟲，或者誤操作呢？毋庸置疑，備援存儲節點也會更改這些數據同步主存儲上面的更改，這個問題必須引起關注。
因此，我們仍然需要藉助快照進行輔助，當類似問題發生時，讓我們的數據能夠回退到上一個時間點。對於一些關鍵的業務及要求性比較高的IT組織，CDP技術將是一個不二的選擇，在於其提供更密集的時間點，稍後聊CDP。
----------------------------------------------------------------------------
（二）Asynchronous Remote Replication_異步遠程複製
之前討論的高可用方案，很大程度的使我們業務連續性的需求得到滿足，但是一些細節也很重要。比如採用實時鏡像的2套設備，通常規定了一個有限的距離。這是因爲2套實時鏡像的設備之間的線路不僅僅是傳統的心跳線，而是Mirroring Link's。線路里面往往跑的是信息數據，更遠的距離意味着更大的延遲，所以我看到的廠商往往把距離限制在有限距離之內，例如200km。這也是爲什麼我們看到很多用戶的同城容災中心之間，沒有太多超過100km的主要原因。
當一個地區，或城市發生災難，意味着我們將失去所有的數據，哪怕是高可用方案也是蕩然無存，所以客戶希望能夠再次創建副本，放置在一個更遠的地區：另一個省市或國家。
此時我們需要使用Remote Replication方案來實現，通常使用Asynchronous Replication（異步複製）技術：較之前者，不會對數據採取迴環的驗證，對線路的要求當然就沒有這麼苛刻，並且能夠把數據備份到一個理想的場所,關鍵在於主中心與災備中心一般使用IP 網絡進行數據的，所以消除的距離限制。
另外：之前有供應商提到，遠程備份是爲了提供災難後數據能夠最快的掛載。我自己不認可這種觀點，並且對最終用戶我也不會承諾。
1.如果真的瞭解Asynchronous這種技術，您就會明白，"不會對數據採取迴環的驗證"是它最大的硬傷，這也是我們爲什麼不直接使用遠程複製，而刻意在本地使用高可用的主要原因。簡單來說，很多情況下，遠端的備份數據與本地的主/副本數據有可能是不一致的。在這種情況下，即使掛起遠端的數據，也未必會有我們預想的結果。這種情況的產生可能是故障時，數據停留在緩衝區沒有傳過去，或者在IP網絡裏。
2.還有更現實的一點，不要更多的追求智能，掛在遠程數據中心的備援卷給Standby應用主機。道理很簡單，當需要啓動遠程災備中心時，通常是本地數據不可用的狀態，比如洪災，火災，地震。而此時遠程數據則是唯一剩下的副本數據，由於上述介紹了遠程複製的傳輸機制，災難有可能會帶來與源數據不一致，如果未作任何計劃掛載遠端的數據副本很有可能會造成寫入錯誤，破壞僅剩的數據，最好藉助快照或CDP更爲安全。
-----------------------------------
（三）CDP_持續數據保護技術
快照功能是一個很古老的技術，但是並沒有因爲歲月流逝被運維人員捨棄，至少我個人還是比較青睞的。它能夠在故障發生時，回滾到上一個時間點，減少了誤刪除，病毒，文件。但隨之業務關鍵性，時間窗口成爲無法忍受之痛。邏輯性損壞帶來的損失。
在容災上，無論是基於哪種技術的複製，或是基於Block的更新都不會進行數據可靠性的驗證。
這裏的可靠性我指的是，如果我們在一個源數據上誤刪除一個文件，那麼同步的副本數據也會執行刪除動作。所以我們需要一個用於回滾的機制，在因爲數據邏輯錯誤而無法掛載時，返回上一個時間點。快照雖然可以提供上一個時間點的回滾，但是對於客戶更高級別的要求，早某些情況可能會力不從心，比如快照無法提供一個密集的恢復時間，對一個大容量的卷。假如：做一個快照窗口需要1分鐘，那麼後面59秒的數據意味着丟失，對於大型數據庫系統會有更大的損失。
CDP技術徹底的改變了傳統數據回滾的方式，使用時間軸進行恢復，用戶可以回撥到需要的一個時間點，不再有時間的備份窗口。弊端往往是損耗一部分空間進行I/O的log記錄。如果把快照比作照相機，那麼真正的CDP技術則無疑是持續錄像機，我們可以更加密集回放和提取每一個幀的鏡頭。
在這個議題上至少有兩點需要先聲明：
1）較之前提到CDP，這個議題僅僅是用於對存儲之間高可用的一個補充，而不是完全用於容災。下圖能夠看出，數據實時同步和高可用部分，依靠的仍然是存儲之間。也因此，在衆多的CDP產品方案中，可以選擇那些依靠存儲層，完全脫離應用層的產品，也就說CDP執行週期對應用主機完全透明，更是無需在應用層安裝代理軟件，使用主機性能分拆IO等等。記住，完全獨立。
2）CDP產品目前很多，但是這裏討論的是SNIA True CDP技術，而不是某些依賴於連續快照的準CDP。
在下圖能夠看到，防止存儲系統意外宕機的——高可用部分仍然是依靠獨立的，具備實時複製的節點進行作業（這些節點或許是某些同型號的高端存儲，或許是位於存儲前端的引擎，又或是內置存儲虛擬化技術的網關）。而CDP僅僅是高可用部分的一個附加技術，只是當面臨應用主機遇到如：軟件升級過程bug(如，數據庫)，病毒蠕蟲，網絡***，人爲邏輯錯誤等等，之後纔會進行數據狀態時間點的回退。但凡發生存儲意外停機，或者同城的某個site癱瘓CDP技術將不參與恢復作業，而是依靠高可用的核心部分實時複製，最終，這是一個完善而又無需爭議的聰明做法。
------------------------
High Availability+Remote Replication +CDP
注：上述引用的“實時複製”技術SNIA標註是synchronous replication。大意是數據副本被實時的更新在額外節點。
-------------------------------------------------------The end........