關於-最佳的業務連續性容災架構設計

       在容災的方案中，用戶每每會根據預算和業務不一樣的安全等級要求，制定不一樣級別的容災方式，更有一部分最終用戶，對安全及潛在的風險知之甚少，至少我遇到部分客戶是這樣的。

   一般我比較中意與金融行業的客戶討論方案，我想這一態度會有不少同行與我達成共識，最主要由於他們一般走在技術最前沿，更快的嘗試新技術(畢竟人家有錢嘛)，可以更好的找到方案的切入點，而且管理人員可以更專業的提出一些需求，一般這些需求他們已經認識到，在技術上已經能夠解決。

若是咱們不考慮客觀因素，如何提供一個高安全級別的方案給用戶 ？

  分享下以往的方案，以及我對容災安全方面的一些認識，在內容裏我刻意省去一些宏觀的理論，好比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........