您企業的業務通過異步備份便能夠獲得支持，抑或還是必須通過異地服務器的更新，才能夠始終保持業務的正常運行呢。

異步與同步;災難恢復與主動的架構(active architecture);主動與被動。客觀上而言，這幾者之間其實并沒有孰優孰劣之分。對您企業來說，最適合的一套方案的選擇將主要取決于您企業業務對于服務器發生停機中斷等事故的容忍程度。

[[213690]]

業界的安全專家指出，在預期可能發生停機中斷事故的情況下，個別公司所選擇的如何保存其數據的具體方式，將取決于他們的業務在停機中斷恢復之前所能夠保持繼續運行的時間有多久。您所在的公司需要怎樣的可用性呢?如果貴公司的主營業務是一個電子商務類的網站，那么，哪怕僅僅只是幾分鐘的停機離線中斷就能造成天文數字般的經濟損失?投資于積極主動的系統保障的成本開銷較之因停機中斷而造成的業務潛在損失之間孰輕孰重，您又會如何決擇呢?

“這并不是一個比另一個更有效率的比較。更為重要的是要正視您企業究竟想要解決什么方面的需求。例如，購買一輛法拉利固然能夠完成運輸食品雜貨的需求，但殺雞真的焉用牛刀?”Commvault公司解決方案營銷和技術聯盟高級總監Don Foster表示說。

在主動的體系架構中，通常是由一組非現場的服務器與現場服務器同步的。這樣，就可以確保在發生一臺服務器處于脫機狀態的災難事件時不會發生停機事故。其可以配置為故障的自動轉移。在此設置中，僅僅只需要較少的硬件，因為兩處站點上的所有系統都正在使用中，而在災難恢復的情況下，則只有一半的硬件被使用。如果您企業擁有48個內核的災難恢復，那么您總計將擁有96個內核，并且只能使用48個內核。在主動的模式下，您企業可以規模化縮小為32 x 2的64個內核，全部64個處于活躍狀態。

在災難恢復情況下，容量是一個完全冗余的系統——所有的硬件和軟件都已經準備就緒，但是完全閑置。在***處站點發生故障失敗之前，這一容量根本不會被使用，但是在某些特定時候會被復制。

Bluelock公司的高級云解決方案架構師Erin Swike解釋說：“主動的災難恢復是DR世界的獨角獸。這一理念是，如果您企業的生產站點發生故障，則您的災難恢復站點將自動開始向用戶提供應用程序，而絕不會造成那怕單個數據包的丟失，這絕對可以說是任何CIO或系統工程師們的必殺技。

“對于我們絕大多數人來說，這聽起來仍然像是童話般的東西。因此，請忘記接近數據中心處理站點和網絡延遲等明顯的要素吧;這其中所涉及到的一個最重要的因素是您的應用程序是否被編寫為能夠支持這種類型的場景情況。”她說，除非從一開始就秉承著這一理念進行應用程序的編寫，否則支持就不可能實現。

在主動模式下，軟件成本較高，因為在主動模式下運行的任何系統都必須具有軟件許可授權。當系統處于災難恢復模式時，第二個系統便不需要為數據庫內核的許可授權付費，例如，因為一次只有一款設備處于活動狀態。兩個系統保持同步的事實根本不會影響到成本。

在同步復制中，兩臺服務器之間需要有可靠的網絡連接。此外，還將需要安排額外的人手來不斷管理另一處的站點。

異步復制的消極面包括會在停機和服務器上一次更新之間丟失一些數據。但這也可以設置為故障的自動轉移。

Webscale Networks公司的產品副總裁Anand Hariharan表示，這基本上是服務器的熱備份、溫備份、冷備份(Hot/Warm/Cold Backup)的概念。其利弊可以從兩個方面進行分析，即：服務水平協議和成本。恢復點目標(RPO)和恢復時間目標(RTO)定義了供應商將提供的SLA，以便在發生停機時，通知用戶可接受的數據可能丟失的時間長度，以及服務恢復的速度。

“當然，通過熱備份或主動架構，停機時間為零，數據***復制，因此，從SLA的角度來看，這是一個非常有利的途徑，因為其確保了關鍵數據不會丟失，而且關鍵的應用程序也將繼續正常運行。”Hariharan表示說。“這方面所存在的缺點當然是成本。維護兩款始終運行的系統基本上會讓成本翻倍，無論這些成本是與在私有數據中心中運行的副本體系架構，支付托管托管服務提供商在非現場位置執行相同的任務相關，還是在云中運行雙倍實例的費用成本開銷相關。在其中一些情況下，根據部署規模的不同，可能還有人工成本方面的考慮，需要額外的技術人員來管理兩倍的系統也會導致成本急劇增加。”

考慮到平均每分鐘高達7,900美元(數據來源：Ponemon Institute)的停機時間成本，這無疑將對任何企業短期的業務利潤及長期的聲譽都會造成巨大的影響。

其他方面的成本還包括托管站點的服務器。這可以通過向眾多用戶分攤基礎架構成本來節省資金帶來巨大的吸引力，但是，根據ScaleArc白皮書的說法：仔細分析，就會發現這些成本節省根本沒能實現。托管服務供應商仍然會向企業客戶收取任何未使用的資源的費用，包括可能在未來某一天才被激活完全使用的資源。然而，企業不能減少專用于輔助站點的資源量，因為來自主服務器的所有信息都必須備份到輔助站點。

ScaleArc的報告還指出，就像托管服務一樣，公有云解決方案由于其規模經濟而顯得很有吸引力。然而，由于隱私方面的問題，擔心安全問題的企業組織(例如銀行和政府機構)仍然避開采用云計算。另外，云系統可能會有延遲，造成對于應用程序性能的影響超出可接受的水平。而且，云計算的經濟性并不總是其表面上所看起來那樣。在全面運營的情況下，云計算的支出通常比企業自有和運營自己的基礎設施時的開支要高。

ScaleArc認為，主動架構的維護成本較低，因為這些任務可以在工作時間內完成，而無需在半夜安排機組人員。其所需要的工作人員的數量更少，因為企業組織可以在維護期間保持應用程序的運行，所以不需要開發人員和其他應用程序專家的參與。

ScaleArc寫道：“成本僅增加20%，企業客戶將享有多出33%的系統容量，同時還能降低停機時間，降低運營成本，提高資產利用率，并可能帶來更高的總營收。”

企業客戶可能不了解計算體系架構，但他們確實希望他們的應用程序和數據始終保持可用。任何無法提供100%正常運行時間的供應商都有可能失去客戶和營收。

OneLogin公司的高級總監Al Sargent從財務角度分析說，***企業在IT預算上的花費會讓一般企業相形見絀。一項研究表明，企業在IT方面的開銷占到其營收的3%至7%。他表示：“轉向主動的架構可能會將IT預算增加一個百分點，但卻可以防止可能導致的高達百分之幾的營收下降的停機中斷。

一些基于云的SaaS解決方案降低了這些成本方面的問題，可以在兩個站點之間自動維護一個通用的管理環境。Hariharan說，云可以實現快速的橫向擴展，因此您企業可以部署一個縮小的(更小的占地面積)故障轉移基礎設施，在發生災難事件時幾乎可以立即恢復應用程序，從而實現更好的SLA。

Foster表示說，這兩種情況都適用于企業的災難恢復策略。許多應用程序甚至包括基礎設施(企業空間中的存儲陣列通過可跨數據中心的單個命名空間創建主動網格)已經開發了這種技術，以使企業客戶可以更容易的制定業務連續性計劃，并實現基礎設施的停機恢復。

“問題是維護和運行這些基礎設施的成本。如果一款應用程序或服務要求真正成為始終在線的系統，那么企業將花費所需的資金來確保五個九的可用性。”他說。

具有這方面需求的大多數關鍵應用程序都具有內置的故障轉移機制，以便在發生故障時二級或三級系統可以恢復。對于服務器來說，集群也已經存在了很長一段時間，而且隨著技術已經進入了基礎設施服務的范疇，可用性所提供的便利性也得到了極大的提高，只是需要付出成本代價。

他說，雖然成本并不是其唯一的缺點。“主動的恢復解決方案并不能解決用戶的人為錯誤。如果發生這種類型的停機中斷，則需要有一些跟蹤時間點來數據恢復的一致性。” Foster說。

市場調研機構451 Research的高級存儲分析師Steven Hill表示：“可能有許多關鍵任務應用程序值得采用主動冗余保護，訣竅在于確定那些應用程序是值得花費的。重要的是要記住，一套好災難恢復/業務連續性計劃要求對企業關鍵業務的優先事項進行廣泛的評估;支持這些因為所需的人員、數據和應用程序;以及替代它們的備選方案的成本，所有這些成本/效益分析權衡都是在發生損失風險和重大業務中斷可能性的情況下進行的。

災難恢復更具成本效益，其通常是數據中斷的重點，可以作為內置的主動恢復服務的補充，Foster指出。基礎架構可以通過實時和版本化的時間點參考來跟蹤數據副本變得高度可用，以解決可能出現的任何中斷問題。

ScaleArc的***執行官Justin Barney認為，對主動架構成本的評估必須考慮到潛在的停機損失。“主動操作確實會花費一定的費用 ——約20%的硬件和軟件成本。但是這些額外的成本不包括對于造成損失的來源的抵消，例如由于避免了停機而避免的營收損失。總的來說，主動操作只適用于無法承受停機時間的企業。

Barney表示，隨著持續可用性的需求開始逐漸主導幾乎每個行業，主動的操作運營顯然提供了***的組合優勢。

據Barney稱，有新的數據顯示，備份系統和企業流程最依賴的確保業務的連續性/災難恢復實際上可能不利于防止重大的停機中斷。 “這在現在很重要，因為這些災難恢復系統已經不能滿足必須實現企業組織持續可用的需求了。”

他說：“今天的企業負擔不起停機失敗的損失，故而在脫機時從故障失敗中恢復過來并不是一種選擇。”

Foster不同意這種說法。“如果您企業仍然像十多年前那樣運行備份和恢復以及災難恢復，那么，這樣的說法可能是正確的，但現實情況是，隨著基礎架構和體系架構的成熟和變化，企業客戶正在對他們如何執行災難恢復和備份進行現代化改造。當他們不這樣做時，由于沒有整合的方式來進行保護和災難恢復決策，停機中斷可能會發生。”

另外，主服務器的正常工作流程必須重定向到輔助服務器，至少暫時成為新的主服務器。這種重定向可能需要大量的人工手動配置，需要兩個IT團隊(每處站點位置一個團隊)加班工作，以啟用和排除交換機故障。類似的重新配置適用于DNS、網絡、復制拓撲和其他基礎設施元素。測試需求是巨大的，必須安排額外的IT人員在輔助設施中就位管理，而原始的IT團隊仍然將會被迫停止嘗試將主要設施恢復到在線狀態。

“當然，隨著我們看到‘軟件正在主導整個世界’和‘每家公司都在成為軟件公司’的大趨勢，只會有越來越少的企業可以接受停機中斷。災難恢復通常意味著至少幾分鐘的停機時間，當然，因為您企業突然間將一款閑置的系統聯機，可能無法順利啟動。而主動架構最適合那些不能容忍停機中斷的企業組織。”Barney說。

Sungard AS的產品管理副總裁Joseph George表示，他不會僅僅從效率角度來看待這兩種架構之間的爭論，因為決定企業彈性層級選擇的***決定因素是基于企業是否能夠負擔得起的。“顯然，如果成本不是唯一一個因素，每家企業都會有高可用性的系統。但他們通常只能為大多數關鍵任務的系統和應用程序提供(并且需要)這一級別的可用性。他說。

企業將他們的應用程序進行分層，以幫助管理風險與投資之間的經濟平衡，對于減輕風險來說是至關重要的。應用程序分層以及映射它們之間的相互依賴關系，可以實現***的恢復順序排序，并允許基于應用程序停機中斷和數據丟失業務所造成的影響水平，來確定***成本效益的可用性程序，他補充說。

Swike說，大多數企業并不需要特別實施主動的災難恢復。溫災難恢復就能夠滿足他們的需求。利用站點之間的適當帶寬，就可以實現幾秒鐘的RPO和幾分到幾小時的RTO技術。“技術只是這其中的一部分，災難的過程必須有嚴格的規定和時間。服務器的復制是一個很好的步驟，但是如果您企業不經常進行測試的話，您怎么知道其到底是否奏效呢?

她說，對于很多企業來說，災難恢復在他們企業排名前10位的優先級事項中僅排名第11位。“這絕不意味著他們不關心災難恢復。只是日常問題和生產項目往往是排在最前面的。”

Coalfire實驗室的副總裁Mike Weber說，從根本上說，堅實的備份戰略的關鍵取決于企業的業務需求和關鍵任務的系統。有許多分層模型會需要與關鍵數據通信，在幾分鐘內需要RTO測量，需要流式備份或復制到冗余(但不是高可用性)系統，通過非關鍵數據可以在幾天內消化恢復的影響。

“這兩者之間以及各個層面都需要不同的策略來實現業務連續性和災難恢復目標。有幾十種方法可以實現這些目標。” Weber說。

他曾多次表示，Coalfire實驗室發現備份或災難恢復站點并沒有與生產站點相同的安全保護和控制。滲透測試發現，當系統使用各種備份或冗余容量時，預算限制通常會導致缺乏相同的網絡安全控制措施來保護生產環境。