該問題的答案可以在宏觀層面上找到。你需有計劃應對可能影響區域服務的災難一一地震、限風，等等。因此你需要把服務布署在分開的地理區域中。至關重要的是:當下次大地震毀掉硅谷的數據中心時，必須有自動的方式將你的流量切換到東部海岸。一旦你解決了這個問題，所有的小事情都變得不重要了。如果一個數據中心的配電裝置、路由器或交換機失效，你的流量將自動地轉移到其他的大都市。很明顯，為了防止流量在不同的地方來回折騰，某種程度的本地冗余是需要的，但你不需要將之進行到收益減少或者負收益的程度。
與人們的普遍看法相反，數據中心的確會有故障，有時原因很古怪。有一天我在參加一個會議時，接到運維中心的電話，通知我說:一個主要的數據中心運行中斷。擔心在我們處理問題時，這個事事件會段掉我的會議，我立即打電話給我的同事了解影響的程度。使我放心的是:她告知，所有網站都已轉出那個地點，流量已轉移到另外的數據中心，她正期待著“烤松鼠”的晚餐，原因是一個壞蛋爬進了配電箱，咬穿了主要的配電電纜。松鼠沒能活過那天，不過我們安然無恙地度過了那一天。
正如前面提到的，BCP對于不同的人有許多不同的含義。讓我們看一下這些術語以及它們對你的站點而言意味著什么。開始時，我先去掉該術語的一大部分一一人員和地點。管理員工是一個完整BCP計劃的重要組成部分。如果你的辦公大樓燒毀了，所有的人到哪里工作?我是一個工程師，那不是我的領域，所以我將集中于BCP計劃的高可用性部分:保證站點正常工作。即使在高可用性領域，也有各種各樣的技術，從熱/熱(Hot/Hot)、熱暖(Hot/Warn)、熱冷(Hot/Cold)到災難恢復。
熱/熱(Hot/Hot)是高可用性的最高級別。用戶可以從任意的數據中心使用全部的應用程序。讀和寫可以發生在任何地方。這讓自動的故障轉移變得非常簡單，但它不是萬能的。
你必須認真思考如何處理數據一致性的問題。如果一個數據同時寫入兩個地點，在復制過程中將出現沖突。哪個寫入是正確的?互聯網是非常動態的媒介，在很多情況下這并不要緊，不過應確保你有所計劃。
熱/暖(Hot/Warm)是一種很好的方式，如果你不能容忍數據的不一致性的話。很多應用有大量的讀操作，僅偶爾(但很重要)寫一下。在這種情況下，區別處理這兩種操作是有意義的。讀操作使用熱熱的方式，可由任何數據中心提供，具有快速自動的故障轉移，這使大部分應用具有很高的可靠性。但一次只寫入一個數據中心，這保證了數據的一致性，代價是一小部分應用的故障轉移會慢一些。假設可以降低網站性能的話，就不用同步數據復制。在2寫操作發生時，盡最大努力將數據盡快傳到其他地點，但沒有擔保。復制延遲可能是幾秒、幾分鐘到幾小時不等。因此，當在一個地點進行寫操作而緊跟著在另一地點進行讀取時，會發生什么呢?更新可能還沒到達，你會得到過期的數據。我們稱之為臨界讀(critical reads)。你需要識別，以及通過錯誤處理或將讀操作引至源站點，來減少臨界讀。
熱/冷(1 Hot/Cold)讓我害怕。這種架構將讀寫流量送到單一地點，而讓另一個相同的部署在遙遠的地平線上閑置。它容易建立，但價值很低。當災難襲來時，你就會質疑計劃是否明智。它真的行得通嗎?軟件版本是最新的嗎?最后一次登錄到這個冷站點是什么時候?情況往往是，這個冷站點會被閑置不用一年或更長的時間。當你需要時，它可能已遺憾地過時了。擔心、不確定和懷疑都不可避免地會延長宕機時間。我見過無數次的事故，其冷情況下你不能使用冷站點，其意義何在?
站點是如此不可信，以至于我們寧愿有幾小時的宕機時間，也不用故障轉移。如果在緊急災難恢復是最差的技術，本質上是霧件(vaporware)。它的本意不是在平常的時候保護你，而是在大的災難發生時給你提供重建的選項。我們收購的一家公司有災難恢復計劃，它每月需要向第三方公司付“保險”費，該第三方公司維護了一個大型的數據中心，里面充滿了閑置的服務器和存儲設備。如果我們們的數據中心發生故障，我們可以用他們的。當然，如果有大的災難，我們就會和他們的其他所有客戶競爭資源。并沒有實際的計劃，也沒有做過任何測試。在開始探索實際的故障轉移會怎么樣的時候，我們發現了一些令人驚駭的問題。結果是服務器和存儲有各自不同部門，網站建設服務器群在一棟樓，而存儲在另一棟。兩棟樓之間有一根千兆以太線路連接，這明顯不能工作。在我們決定自己干時，他們允諾再建第二條千兆的以太線路。
本文地址：http://123beaconmarketing.com//article/3358.html
