容錯移轉技術的思考

容錯移轉技術在資料中心是很常見的，許多 大型企業都使用了容錯移轉技術處理伺服器故障，資料庫故障，甚至是整個資料中心故障。容錯移轉技術就是建立一個“熱網站”或“熱備用”同時運行與主站上相 同的系統和服務，理想情況下，當主服務、系統或網站失效時，終端使用者可以無縫地轉到備用網站，備用網站與主要站台是全部同步的，因此無需恢複操作，業務不會 因此中斷。
　　在正常情況下，這種架構不會有什麼問題，服務不會中 斷，資料不會丟失，在切換時，終端使用者最多能輕微感覺到一點延遲。進階容錯移轉技術已被證明可以很好地工作，但傳統的容錯移轉技術非常昂貴，採購、部署和 管理成本都非常高，對大多數企業而言，都承受不起。
　　
　　現代企業面臨的一個挑戰是，他們需要實施負擔得起的應用程式容錯移轉，僅保護 那些重要的應用程式，在某些情況下，他們唯一的辦法是重新設計應用程式以適應容錯移轉，但使用組織現有容錯移轉技術，可能無法實現重構，大多數情況下，打 包的應用程式需要廠商設計容錯移轉功能，很多組織需要考慮購買特殊的產品，以滿足他們的需要。但如果組織有自製打包應用程式，可能需要為應用程式容錯移轉 重寫代碼，允許開發人員直接將容錯移轉功能合并到應用程式中的技術已經出現。虛擬化為容錯移轉提供了新的解決方案，在某些情況下，可以減少重新設計應用程 序的需要。你選擇哪種技術完全取決於你的業務需求和應用程式開發能力。
　 　為容錯移轉自己動手編寫代碼
　 　要讓每個應用程式都具有彈性，沒有一個固定的單一解決方案，彈性和容錯移轉應從妥善保護獨立應用程式開始計劃，這聽起來象是一個不可能完成的任務，尤其 是應用程式已經在服務的情況下，但應用程式開發工具廠商為我們提供了一些選擇，不過大部分功能都是每個應用程式開發平台專屬的，這意味著應用程式開發人員 必須學習這些特定的開發生態系統，找到合適的工具實現容錯移轉功能。
　 　例如，通過Visual Studio可以開發出具有“故障識別”能力的應用程式，當然前提是要結合微軟的資料庫和伺服器運行。理想情況下，當使用者被重新導向到其它應用程式伺服器、 資料庫伺服器或檔案伺服器時，應用程式可以維護一個資料狀態和工作階段狀態。
　 　相同風格的彈性可以適用於那些運行在Oracle資料庫之上的應用程式，特別是那些用Java編寫或依賴於Ajax技術的應用程式。這裡，代碼將感知故 障的能力合并到Oracle資料庫伺服器上，在通知應用程式伺服器資料轉送目的地變化的同時，由Oracle伺服器處理故障事件。開發人員也可以使用面向 方面編程（Aspect-Orientated Programming，AOP），它是以重試和恢複過程為基礎的方法，有些人可能會認為AOP是一種強制容錯移轉的方法，但無論如何，它是一種可以減少 編碼量，並已經證明是可以工作得很好的方法。
　　對於那些使用客戶 端/伺服器模式本地執行的應用程式來說，要實現容錯移轉比較複雜，應用程式必須依賴於狀態輪詢或感知伺服器（資料庫或應用程式）狀態，然後重新路由請求到 正常運轉的系統，在後端需要更多的技術，如負載平衡和容錯移轉裝置。不過，根據應用程式的複雜性，將容錯移轉功能整合到現有應用程式花的時間可能很長，有 時還不如重頭開始開始寫代碼。同樣，還需要大量的測試確保應用程式在容錯移轉環境下可以正常運行，這將會延長開發週期。
　　在C+或其它編程套件下開發的應用程式通常使用混合的容錯移轉方法，應用程式只需要 知道請求和更新需要發送到哪裡，而由後台技術處理物理路由。例如，微軟提供了兩個API用於建立容錯移轉功能：容錯移轉叢集API（Failover Cluster API）和叢集Automation 伺服程式（Cluster Automation Server），容錯移轉叢集API是一套豐富的開發叢集感知應用程式的C/C++庫，而叢集Automation 伺服程式提供了一套指令碼對象，用於監控和管理容錯移轉集 群。Oracle開發人員可以使用Oracle調用介面（Oracle Call Interfaces，OCI），加入到使用者定義的回呼函數。
　　其它應用程式容錯移轉方法
　　深入瞭解程式碼程式庫後，你會發現其實靠應用程式本身實現容錯移轉不一定是最具成本效益 的方法，還有其它選擇，既滿足彈性需要，又無需重新編碼，在最好的情況下，這些替代方法不需要修改一行代碼，但需要研究應用程式是如何執行的，以及資料是 儲存在哪裡的。
　　第一個替代選擇是虛擬化，許多企業都在資料中心 使用了虛擬化技術，既節省了成本，又減少了資料中心空間佔用，最大化了裝置的投資回報。使用虛擬化的問題是它通常是一個可有可無的方法，對於虛擬化故障轉 移，應用程式伺服器必須虛擬化，應用程式本身也需要虛擬化，有些應用程式之間共用伺服器，這意味著虛擬化可能會使情況變得更加複雜，甚至比改造應用程式實 現容錯移轉功能還要複雜。然而，虛擬化可以簡化資料系統的彈性，支援關鍵應用程式容錯移轉。
　　許多第三方廠商提供了打包方案，結合了虛擬化和容錯移轉彈性的優勢，例 如，VMware提供了站台復原管理器（Site Recovery Manager），它是一個檢查故障和自動造就災難恢複環境的管理架構。另一個廠商是InMage系統公司，它提供了一個產品可以在虛擬桌面上捕捉I/O 和複製資料，可以快速恢複系統，甚至可以跨越廣域網路使用。另一種方法是使用冗餘虛擬機器，來自Marathon軟體公司的EverRun就是這樣的產品。
複 制技術結合了虛擬化和熱備用，看上去好像是企業中引入的最快速的容錯移轉方法，因為應用程式和資料都駐留在企業資料中心，用戶端只需要做少量工作就可以快 速建立一個容錯移轉環境。可以這麼說，對傳統應用程式而言，這是最快的容錯移轉方法，如果結合約步和虛擬化，還可以帶來另一個好處 – 應用程式負載平衡。
　　通過整合進負載平衡技術，應用程式容錯移轉 不僅可行，還可以建立更高的投資回報，而熱備用需要一直等待觸發容錯移轉事件，這些系統在高要求環境中可以用於共用負載，包括Barracuda網 絡，CoyotePoint系統，F5網路等公司在內，他們提供的負載平衡產品都整合了容錯移轉功能。
　　其它廠商的產品有可以建立統一的，虛擬化容錯移轉解決方案，如SteelEye的 LifeKeeper高可用叢集裝置，Racemi的Automation 伺服程式和災難恢複套件，Novell的Platespin Protect，IBM的System x刀片伺服器容錯移轉方案，以及VMware的高可應用服務，每個廠商提供的產品都具有不同水平的容錯移轉能力，在改寫代碼前，建議全盤考慮一下所有可能 的解決方案。
如果你是或曾經是一名伺服器管理員，則你總是會以某種方式遠端管理伺服器。隨著網路基礎設施逐漸延 伸到典型機房以外的地方，無論你是使用Citrix獨立計算體繫結構（Independent Computing Architecture，ICA）通道還是支援遠端桌面管理的VPN（虛擬私人網路）登入，遠程伺服器管理都不可否認地成為一項日常性工作。
　　而要進行遠程伺服器管理，就要用到遠端管理工具。現在，許多伺服器都配備了無人值 守管理（Lights-Out Management，LOM）工具，整合了完善的功能。通常情況下，一個伺服器系列的遠端管理工具有一個專有名稱。例如，戴爾PowerEdge伺服器 上的管理工具稱作OpenManage，而惠普ProLiant伺服器上的管理工具則稱作Integrated Lights Out（iLO）。儘管這些嵌入式軟體和硬體名稱各異，功能豐富，但是我們必須瞭解這些技術本身的缺陷，才能輕鬆駕馭這些遠端管理工具。
　　遠程伺服器管理失敗的原因
　　顯而易見的是，只有伺服器在接通電源的情況下，無人值守管理工具才能運行。當然， 你可能會為運行關鍵業務的伺服器提供後備電源。但是，如果這兩個電源都斷電了，那麼很不幸，你的伺服器仍然無法運行。此時，你應該調用現場的遠程伺服器管 理工具，以檢查問題所在。除此之外，無人值守管理工具也可以為你排憂解難。
　 　作為一名遠程伺服器管理員，你將為一些重要的非現場工作做些什麼準備？適當的災難恢複管理和規劃可以協助你應對和解決與遠程伺服器有關的簡單問題。除了 顯而易見的電源全部斷電的情況以外，遠程伺服器管理還需要考慮以下三個重要問題。
　 　首先，遠程伺服器管理依賴於Internet。如果Internet無法串連，遠端管理當然也就無從談起。在緊急情況下，有時管理員會使用撥號連線。但 是，如果你曾經利用撥號連線管理過伺服器，你就會知道，這可不是一件輕鬆的事。許多管理員必須遠程登入，而且離開Internet服務就無法管理伺服器。 此時，他們可以考慮使用冗餘路由。如果你選擇在伺服器陣列所建立第二條Internet線路，則一定要選擇使用不同線路的另一家網際網路服務提供者 （Internet Service Provider，ISP）。因為選擇兩家不同的ISP並不意味著他們使用的不是同一條線路，所以要驗證它們是不是由完全不同的電訊廠商提供的完全獨立的線 路。一種實現冗餘路由的方法是選擇兩家電訊廠商，其中一家提供T1/T3線路，另一家提供企業級電纜連線。更有甚者，一些強調正常已耗用時間的管理員還會建立 冗餘ISP基礎設施，其中可能包括移動解決方案、衛星鏈路以及作為最後一招的撥號連線。
　 　其次，管理員只能管理自己所能發現的問題。因此，選用的工具要能夠提供最符合自己需求的功能和介面。管理員通常可以選擇無人值守管理和IP-KVM（基 於IP的鍵盤、顯示器和滑鼠，有時也稱作iKVM）工具。無人值守管理整合了安裝有專用伺服器軟體的硬體晶片，這些軟體允許管理員管理伺服器。另一方面， 獨立的IP-KVM是在機架或伺服器環境中管理大量伺服器的輔助產品。無人值守管理和IP-KVM各有利弊，都可以遠端管理伺服器。例如，Avocent 公司生產的IP-KVM允許管理員在伺服器上插入鍵盤、顯示器、滑鼠甚至序列埠，對管理員大有裨益。利用Avocent IP-KVM，管理員可以解決思科防火牆、網路交換器以及其他沒有配置任何無人值守管理工具裝置的問題。管理員甚至還可以在IP-KVM裝置上通過串列連 接管理PBX（專用交換機）。
　　David Langlands是國際安全和IT諮詢公司Cyberklix的首席安全架構師，他需要管理和監視位於全球各地的眾多伺服器。他說，“當需要遠端管理服 務器時，IP-KVM就像人的結腸一樣，不是一種選擇，而是一種需要。”然而，單一的IP-KVM也會發生問題。正如Langlands指出的那樣，使用 輔助IP-KVM也有弊端。他說：“使用輔助IP-KVM的成本往往比較高昂，且對伺服器的物理組件幾乎沒有可見度。而令人遺憾的是，你還不能使用簡單的 IP-KVM實現電源迴圈。”
　　最後，在試圖全面診斷物理問題 時，無論使用獨立的IP-KVM還是無人值守管理，管理員都可能會遇到一些麻煩。對於遠端管理和快速修複，IP-KVM和無人值守管理都是重要的工具。但 如果是內部風扇或伺服器中的其他組件出現故障，遠端管理軟體不一定總是能夠顯示這些故障資訊。由於無人值守管理並不能解決所有問題，所以你必須準備第二套 解決方案，以排除嚴重的硬體故障。
　　因此，當發生遠端管理工具無 法識別或修複的問題時，現場管理員需要一雙慧眼，以準備解決這個問題。有些企業可能會在遠程位置派駐一名管理員，依靠遠程託管場所的IT人員或利用合約工 程師服務，獲得上門服務或按需服務。通常情況下，託管場所將會與企業簽訂一份服務等級協定，約定如果伺服器出現硬體故障，現場工作人員可以馬上更換出問題 的硬體。由於託管場所是全天候運行，因此不會出現伺服器等待修理的問題。託管服務的不利之處在於，託管合約和專業服務價格昂貴。因此，要盡量少用託管服 務。合約工程師服務的價格也便宜不了多少。例如，如果你在芝加哥，而遠程託管的伺服器在紐約，則你可以依靠外部網路工程師來協助解決問題。這些合約可以累 計，僱用一名工程師檢查伺服器的最低費用約為每小時150美元。
　 　遠端管理工具的局限
　　請記 住，遠端管理工具不能解決你所有的問題，因而不能保證你的伺服器不發生重大災難。如果說遠端管理工具有作用，它們也只是一些可以在緊急情況下使用的輔助工 具而已。沒有任何軟體或硬體是十全十美的。因此，在使用諸如無人值守管理硬體和軟體這樣的遠端管理工具時，請牢記以下事項：
    •    無人值守管理功能通常是通過嵌入在伺服器硬體晶片中的軟體實現的，因此你可能 會發現其GUI缺少某些功能。
    •    由於資源有限，這種板載軟體可能需要非常具體的Java/Active-X版本甚至特定的瀏覽器才能運 行。
    •    如果你的伺服器要求高解析度，則你在訪問伺服器時可能會遇到一些問題，因為有些遠端管理工具不完全支援高解析度訪問。
    •    慎 用鍵盤上的功能鍵組合（功能鍵+f2、功能鍵+ctrl+f12）。當使用無人值守管理工具時，由於軟體不能識別你試圖輸入的內容，你可能會遇到真正的風 險！
　　規劃和準備可以突破遠端管理的局限
　　那麼，什麼時候無人值守管理真的相當於現場操作呢？通常情況下，這取決於你的網路基 礎設施的規劃。作為一名IT管理員，一定要在遠程伺服器的無人值守管理和現場操作之間採取折中的辦法。當對公司進行災難分析時，一定要弄清業務關鍵型裝置 的重要程度究竟如何。問自己一個問題：“這台裝置有多重要？如果它宕機，我的業務還能運行多長時間？”在託管現場僱用經驗豐富的工程師準備修複伺服器是必 須的。IP-KVM或高端無人值守管理工具功能是有限的。在弄清什麼時候無人值守管理真的相當於現場操作時，商務持續性起著非常重要的作用。