保護虛擬環境的關鍵做法

我們將針對目前主要x86虛擬化平臺，整理出備份、備援與高可用性機制，分析不同的類型，找出現行對應的做法與解決方案。以下分為三大部分來討論。

Part1 虛擬環境更需要資料保護
虛擬化技術可讓資源集中，但風險也會隨之集中。「單點故障危害範圍大幅增加」與「共享資源，影響服務品質的維持」是可能造成的兩種風險。可以透過備份、備援解決虛擬化帶來的故障風險增加問題。

Part2 虛擬環境資料保護的作法

作法1 虛擬環境的備份
虛擬環境的備份可依工作執行層級與複本型態做不同區分，依工作執行層級可分成虛擬主機端、實體主機端與儲存端；從複本型態則有應用程式檔案或元件、磁碟映像（Image）與邏輯磁碟機等三個層級。

作法2 虛擬環境的備援
對某些執行關鍵任務、不允許服務中斷，或僅允許極短暫中斷的系統來說，由於從備份複本還原系統所需時間不等，因此僅有備份便不能滿足需要。這時候就必須讓可在極短時間內接續原系統服務的備援系統上場，構成具備自動失效轉移能力的高可用性系統。

作法3 協助維護升級：線上遷移

不中斷服務的線上遷移虛擬機器功能，是協助虛擬環境用戶執行實體主機維護與升級作業的一大利器。依廠商說法，這種線上遷移作業造成的系統中斷，可低到幾秒甚至幾毫秒，原先提供服務的虛擬機器，已經從一臺實體主機被搬移到另一臺實體主機上了。

作法4 保障存取資源：負載平衡

虛擬環境中一般會有分別負擔不同服務的多個虛擬機器，而這些服務通常會有優先順序的區別，也就是某個虛擬機器執行的服務比另一個虛擬機器的服務更重要，顯然的，更重要的服務就需要更優先資源分配。

VMware ESX與Virtual Iron的高可用性架構
目前唯一能提供高可用性機制的虛擬平臺，是VMware Virtual infrastructure 3的HA，以及Virtual Iron V4 XEE的LiveRecovery，兩者都架構十分類似，都是將數臺實體機器構成一個資源池，然後透過一個管理平臺為儲存池中的實體機器建立叢集關係。

Part3 保護虛擬環境的建置策略

依不同環境選擇合適的備份備援機制。我們可歸納出幾個基本原則：如「備份是不可或缺的基本措施」、「依任務關鍵性與預算選擇備援類型」、「視政策決定導入線上遷移與負載平衡與否」等。Part1 虛擬環境更需要資料保護

無論導入虛擬化與否，企業資料需要備份備援的保護已是基本共識，但比起傳統環境，虛擬環境的資料更需要保護。長期以來，「把雞蛋都放在同一個籃子裡」，是企業對導入伺服器虛擬化的一大疑慮。

透過運算資源的集中來提高硬體資源利用率，進而節省整體成本，固然是伺服器虛擬化的主要效益，然而世界上沒有十全十美之事，這種作法亦帶來相應的副作用。

藉由運算資源的切割與共享，虛擬化技術可讓少量高效能伺服器，替代大量舊的伺服器，從而有效降低硬體建置與維運成本。然而資源集中了、風險也隨之集中。

對企業用戶來說，虛擬化平臺要能發揮效用，就必須具備執行重要關鍵應用程式的能力，這要求虛擬平臺須能因應突如其來的服務中斷問題，故建立高可用性或失效轉移（Fail Over）機制是不可或缺的措施。

風險1 單點故障危害範圍大幅增加

導入虛擬化之前，任一伺服器故障通常只會影響到該伺服器負責的工作；導入虛擬化後，由於單一實體伺服器就承擔了過去多臺伺服器的工作，一旦故障，連帶也影響到多個服務的執行，風險比以前高出許多，因此備份或備援系統的必要性也大幅增加了。

除了故障會造成停機外，維護或升級也會造成停機。未導入虛擬化的環境，個別實體伺服器各自執行任務，因此當特定實體機器因定期維護、升級而停機時，僅會影響該實體機器上的服務；而在虛擬化環境，任一臺實體伺服器若因停機進行歲修或升級，影響的範圍就大的多了。

風險2 共享資源，影響服務品質的維持

用戶導入虛擬化的目的是節省成本，但不能以犧牲服務等級為代價。而虛擬化平臺雖能針對個別的虛擬機器分派硬體資源，如處理器、記憶體、網路頻寬與磁碟存取的優先順序，藉以確保不同服務的執行效率。然而資源總是有限的，不當的資源分派顯然會影響虛擬機器的效能。

固然IT管理人員理應能預估不同服務的硬體資源需求，但現實中總是會發生無法預期的狀況，若一開始的資源分派不適當，很可能會產生尖峰時段多個虛擬機器同時需要存取資源，以致承擔關鍵應用的虛擬機器資源不足，形成效能瓶頸的情況。因此動態的資源監控與調節，也是不可或缺的機制。

以下我們將分別介紹虛擬環境中的備份、備援與動態資源負載平衡的種種作法，以及不同類型解決方案的特性。作法1 虛擬環境的備份

備份是資料保護的最基本方式，導入虛擬化以後一樣需要做備份。備份的目的是得到一份複本，以待系統出狀況時仍能藉以回復系統資料。而就取得資料複本這個目的來說，有多種方法可供選擇，而不同方法取得的複本型態也有很大差異。

虛擬環境的備份可依工作執行層級與複本型態做不同區分，依工作執行層級可分成虛擬主機端、實體主機端與儲存端；從複本型態則有應用程式檔案或元件、磁碟映像（Image）與邏輯磁碟機等三個層級：

類型1 虛擬主機端備份
從虛擬主機端執行備份就是像傳統備份一般，將每一個虛擬機器當成實體主機一樣部署備份代理程式。這種方式的優點是完全無須更動原有的網路備份架構，而且任何既有備份軟體都能適用。但問題是用戶有多少虛擬機器，就得部署多少套代理程式，需要的軟體授權費用與未導入虛擬化之前完全相同。

從另一方面來看，企業通常是選擇下班離峰時間執行備份，導入虛擬化後也不例外。但若採用這種在虛擬主機上安裝代理程式執行備份的方式，很可能會造成一臺實體主機上的多個虛擬主機同時啟動備份作業的問題，以致給網路頻寬、磁碟I/O等主機硬體資源帶來極大的負荷，甚至會導致備份工作完全無法動作。

要避免這種問題，就只能限制實體主機上的虛擬機器數量，藉以減輕備份帶來的衝擊。但這又與虛擬化的主要目的背道而馳—無法在一臺實體主機上執行儘可能多的虛擬機器。

儘管這種方式有種種缺點，但由於傳統的備份軟體已發展多年，與特定應用程式間的配合也已相當成熟，如果用戶在虛擬機器上執行了資料庫、郵件伺服器等特定應用程式，則在虛擬機器上安裝傳統備份軟體的代理程式，仍是相對較為穩定可靠的備份方法。

另外若用戶對備份/還原精細度要求，是針對特定應用程式特定元件的層次（如Exchange的單一信箱或信件），或要執行檔案層級的增量或差異備份，那這種備份方式是唯一可行的方式。只有安裝在虛擬機器上針對特定應用程式的備份代理程式，才能辨識虛擬機器執行的應用程式特定元件，或是虛擬機器中各檔案的異動狀態，這是其他層級的備份無法做到的。

虛擬機器備份的3種層級

資料來源：iThome整理，2008年5月

類型2 實體主機端備份
即在執行虛擬化軟體的實體主機上執行備份，典型的方式有兩種，一為在實體主機上部署備份代理程式，二為利用虛擬平臺內建的快照（Snapshot）或複製（Clone）功能。

在實體主機上部署備份代理程式

直接在實體主機上安裝代理程式，所需軟體授權數量比前一種方式少的多，不管實體主機上執行了多少個虛擬機器，都只需在實體主機上安裝一份代理程式，可一次對全部或特定虛擬機器執行備份。

由於虛擬機器對應在實體主機上的本體是特定格式的檔案，如.VMDK或.VHD等，因此在實體主機上執行的備份也是屬於磁碟映像層級，只要備份軟體能辨識虛擬平臺的檔案系統格式，就能使用這種備份方式。

如Symantec NetBackup 6.5就將Client Agent部署到 VMware ESX的Service Console中，然後對ESX Server中對應不同虛擬機器的.VMDK進行備份，無論ESX Server上有幾個虛擬機器，都只需要1個NetBackup Client Agent。

這種備份方式雖能大幅節省代理程式的授權費用，但也存在幾個副作用：

● 在實體主機上執行備份將占用實體主機的硬體資源，嚴重影響虛擬機器的執行效能。

● 必須執行冷備份（Cold Backup），也就是先停止虛擬機器的運作再執行備份，才能確保備份複本的可用性，否則就得為應用程式撰寫Script，先將記憶體資料寫入磁碟、暫停應用程式對磁碟區的寫入，並將快照執行期間的資料寫入，導到另一暫存區，才能不中斷系統服務，同時保證複本的一致性與可用性。

● 在實體機器上看到的是磁碟映像層級的資料，因此備份或還原都是針對整個系統，不能還原特定檔案。更麻煩的是，由於代理程式看到的是虛擬機器的實體磁碟檔案（.VMDK或.VHD），隨著虛擬機器的執行，對應的實體檔案也會有所異動，因此對備份代理程式來說，每次備份時所看到的.VMDK或.VHD都是異動過的，因此只能執行完全備份，相當占用磁碟空間與網路頻寬。

利用虛擬平臺內建的快照功能
較專業的虛擬平臺如VMware Workstation/Server/ESX與Virtual Iron等，都內建了快照或複製功能，用戶在操作虛擬機器時，可透過快照把當前虛擬機器的狀態儲存成複本，以供還原系統狀態或其他用途所需。

Clone是製作一個容量1：1的複本，較為耗時，而且Clone多少次就會占用多少倍的空間，空間消耗很大；而快照則可以不是1：1的，但必須參照索引並結合原始那一份磁碟資料，才能合成不同時間點的磁碟狀態。

這種方式優點是無需購買備份軟體，但問題也不少：
● 用戶必須分別為每一個虛擬機器執行快照，若用戶設置的虛擬機器很多，這將成為一個十分麻煩的工作。

● 這種快照所得的複本屬於映像層級，備份下來的是該系統的整個磁碟狀態，因此在還原時也只能還原整個系統狀態，不能還原特定元件或檔案。

● 除某些企業級虛擬平臺可提供能支援不中斷服務的熱備份（Hot Backup）工具外（如VMware ESX的vcbMounter與vcbSnapshot），多數虛擬平臺內建的快照多只能執行冷備份或暖備份（Warm Backup），也就是在關閉虛擬機器，或是使虛擬機器瞬間暫停再執行快照，才能保證複本的可用性，因此前端的服務將會中斷。

● 虛擬機器執行快照的動作，將會消耗實體主機的運算與磁碟I/O資源，影響整體效能。如果用戶要把複本移到其他媒體上保存，還會影響到前端的網路頻寬。

類型3 儲存端備份
許多企業級的中高階儲存設備都提供了快照或複製功能，因此也可利用儲存設備的快照功能執行備份工作。從儲存端備份的最大優點是不會占用前端主機硬體資源，屬於無主機（Serverless）型式的備份。但儲存端備份亦有幾個需要注意的問題：

● 磁碟陣列屬於底層的基礎設備，是以LUN或Volume向前端主機提供空間，本身並不去管前端主機在這些LUN中如何儲存資料，或是這些LUN中存放了什麼類型的資料。儲存端執行的快照或複製，只是一個區塊（Block）接著一個區塊的抄錄資料製成複本，因此這樣得到的複本，是整個LUN或Volume的複本，還原時也是以整個LUN或Volume為單位。必須將這些LUN或Volume掛載到虛擬平臺上指定的虛擬機器後，才能辨識並存取其中的特定檔案。

● 某些虛擬平臺可允許以NFS方式存取資料（如VMware ESX Server），這時候向主機提供Volume的後端儲存設備（即NAS），就能以檔案方式識別前端存放在Volume中的虛擬機器檔案（.VMDK），因此能執行映像層級的備份。

● 必須配合虛擬平臺本身的Script指令，才能執行熱備份，確保快照複本的可用性。

● 儲存端的備份雖然不會占用前端主機的硬體或網路資源，但會占用儲存設備自身的I/O資源，因此當儲存設備自身在執行快照或複製時，便會影響到提供給前端伺服器的I/O處理能力，從而降低虛擬機器的執行效能。

再考慮到不同儲存設備採用的快照技術差異，某些廠商是採用「一次讀取加兩次寫入」的方式，另一些廠商採用「一次寫入」的機制，不同快照方式對儲存系統造成的I/O負擔不同。

因此，某些廠商儲存設備起動快照時，I/O吞吐量會降低50～70％之譜，而另一些廠商的儲存設備則只有10～15％的降低，不同廠牌儲存設備間的差異非常大。

所以雖然許多儲存設備都能提供快照或複製功能，但並不是所有這些設備，都適合用來為虛擬機器進行儲存端備份，如果在那些快照會嚴重影響I/O效能的設備上，強行執行快照備份，則在快照執行期間，將會導致前端伺服器上的虛擬機器磁碟效能大幅下降，甚至陷入停擺的窘境。

所以若考慮使用儲存設備提供的快照功能進行備份，必須特別注意快照對儲存設備效能的影響。作法2 虛擬環境的備援

備份只是最基本的資料保護手段，只是保留了「資料」的複本，但並沒有可讓這些資料馬上發揮作用的「系統」，用戶必須先找到合適的系統，再將備份複本還原到系統上，才能完整回復原來的系統服務。對某些執行關鍵任務、不允許服務中斷，或僅允許極短暫中斷的系統來說，由於從備份複本還原系統所需時間，從數小時到數分鐘不等，因此僅有備份便不能滿足需要。

這時候就必須讓可在極短時間內接續原系統服務的備援系統上場，構成具備自動失效轉移能力的高可用性（High Availability）系統。

與備份相同，虛擬環境中的備援亦能分為三個層級，分別為應用程式層、虛擬機器層與實體機器層：

第1級 實體機器層備援
即為執行虛擬軟體的實體機器建立備援，這是最基本也最重要的備援層級。一臺實體主機上通常會同時執行好幾臺虛擬機器，一旦實體主機故障或失效導致停機，則其執行的多個虛擬機器，以及這些虛擬機器所執行的服務通通都會中斷。要維持服務的持續，最基本的方法就是，另外找一臺主機與原有實體主機構成叢集（Cluster），以在實體主機故障時接替工作。

要為實體主機建立叢集有多種方法，可透過虛擬平臺自身提供的機制，也可透過第三方廠商提供的叢集軟體。前者如VMWare Infrastructure的High Availability、Virtual Iron的LiveRecovery等，這些功能可為多臺實體主機建立叢集備援關係，安裝在實體主機中的代理程式可透過心跳（Heartbeat）偵測檢視叢集中其他主機的狀況，若有任何主機未能回應心跳信號，就立即在事先指定的備援主機上啟動虛擬主機。

當然用戶也可以不使用虛擬平臺提供的備援機制，而採用Symantec的Veritas Cluster Server for VMware ESX這類可搭配特定虛擬平臺的叢集軟體，來為虛擬環境中的實體主機建立備援。

第2級 虛擬機器層備援
實體機器層的備援，可為整臺實體機器建立監控與將任務即時切換到正常主機上的機制，理論上只要保護了底層的實體主機，則其中運作的虛擬機器也獲得了保護。

但某些情況下出問題的只是某個虛擬主機，而不是整臺實體主機，這種情況下顯然不需要切換整臺實體主機，所以這時候需要的就不是整臺實體主機的備援，而是針對實體主機上的虛擬機器的備援。

要為實體機器上的特定虛擬主機建立叢集有幾種方法，最簡單的就是將虛擬主機當成實體主機一樣，在多臺虛擬主機上安裝Veritas Cluster Server（VCS）、Microsoft Cluster Server（MSCS）之類的高可用性（HA）叢集軟體，為指定的虛擬機器間建立叢集關係，以在叢集中任何虛擬主機失效時，自動將工作切換到另一個虛擬主機。

這種方式的缺點就是需要大量的軟體授權，必須為每一個欲加入叢集的虛擬主機購買叢集軟體授權，而且許多叢集軟體都是按照處理器或核心的數目計價，所以如果在虛擬機器中設定的處理器數目或核心越多，費用也隨之增加。

如果用戶在虛擬機器上執行的是Linux或Unix作業系統，則他們都提供了對應的高可用性叢集功能，如Sun的Solaris Cluster、RedHat Cluster Suite等，而且在這些平臺上都能找到開源式的解決方案，可替用戶省下不少授權費用。

某些專門針對虛擬環境的叢集軟體也值得一提，如Veritas Cluster Server for VMware ESX除了能執行實體機器層的失效轉移外，還能監控虛擬機器層的運作，在特定虛擬機器失效時自動切換到同一臺實體機器上的另一個虛擬機器，或是另一臺實體機器的虛擬機器。

第3級 應用程式層備援
虛擬機器層的備援機制只能對應虛擬機器的失效轉移，這個層級的失效偵測只針對虛擬機器，但有許多情況是虛擬機器上執行的應用程式失效了，但虛擬機器本身仍在執行。

而虛擬機器層的高可用性備援機制，一般只能監控虛擬機器本身是否仍在運行，而無法發現執行的應用程式或特定服務運作是否正常。因此僅依靠虛擬機器層的備援，仍無法完全確保系統服務的不間斷運作。

針對這類虛擬機器本身正常，但應用程式或服務可能失效的問題，需要的是可監控虛擬機器內執行的應用程式或服務的叢集軟體，以在某個虛擬機器內的應用程式或服務失效時，自動將服務切換到另一個虛擬機器上。

要建立應用程式層的備援可有幾種方式。一為採用可支援虛擬機器內服務監控的叢集軟體，如Symantec的VCS for VMware ESX就宣稱除了能監看VMware ESX的實體機器與虛擬機器外，還能透過RemoteGroup代理程式監看虛擬機器內的服務或應用程式，即使虛擬機器仍在運作，但只要系統發現其執行的應用程式不正常，就會自動執行切換動作。

當然這也要應用程式本身的配合，不是任何應用程式都能接受叢集軟體的監控與切換管理，以VCS for VMware ESX為例，能支援的應用程式為微軟IIS、SQL Server 2000/2005、Exchange 2003/2007、Apache、Oracle 10g、SAP（Linux）等。

另一種方式就是把虛擬機器當成實體機器，在多臺實體機器上安裝MSCS、VCS等叢集軟體，然後在這些虛擬機器上安裝Exchange 2003/2007、SQL Server、Oracle等支援叢集的應用程式，這樣也能建立起應用程式層的備援。

虛擬機器高可用性備援的3種層級

資料來源：iThome整理，2008年5月

作法3 協助維護升級：線上遷移

在實務中不是只有故障才會造成系統停機，在定期維護或升級時也會造成停機。而虛擬化環境中的一臺實體主機上，就集中了過去由多臺實體伺服器執行的服務，因此停機檢修造成的影響範圍也擴大許多。

主機端的線上遷移
要解決歲修停機造成的服務中斷問題，最簡單的方式就是啟用另一臺一模一樣的備用主機，在原系統主機停機時接替工作。然而除非原來的環境建有自動切換的高可用性叢集，否則要達成完全不停機的無縫轉換，仍有許多困難，或多或少仍需停機使服務中斷，才能確保接手的備用主機服務起始點，與原始主機的服務停止點能正常銜接。

為解決這個問題，現在許多虛擬平臺都能提供無需停機的線上遷移虛擬機器的功能，如VMware ESX的VMotion、Virtual Iron的LiveMigration、Xen Enterprise的XenMotion、Sun xVM Server的LiveMigration等。透過這類線上遷移功能，用戶可將環境中任一臺實體主機的任一個虛擬機器，轉移到另一臺實體主機上執行，而且在轉移過程中不用關閉虛擬機器，可將服務中斷時間降到最低。當然要確保虛擬機器的線上遷移能夠成功，必須讓兩臺實體主機的硬體配備與軟體設定儘可能一致。

儲存端的線上遷移
主機端的線上遷移只能解決主機停機問題，但在實務中，需要停機維護或升級的不止是主機，還有儲存設備。然而由於所有實體主機上所有虛擬機器的I/O資源，都是依靠底層的共享儲存設備提供，因此儲存設備停機帶來的影響將是全面性的，會造成整個虛擬環境的作業停止。因此虛擬環境中的儲存設備，是不能夠輕易停機的。

為解決這個問題，VMware提供了一個稱為Storage VMotion的工具，可將底層儲存設備中的虛擬機器檔案轉移到另一臺儲存設備上，甚至可達到完全不停機的資料遷移。透過這個功能，可在服務中斷儘可能低的情況下，進行儲存設備的移轉與更新。

除了Storage VMotion，用戶也可利用儲存設備端的儲存虛擬化產品，同樣也能達到在不同儲存設備間不停機的遷移資料。

作法4 保障存取資源：負載平衡

虛擬環境的應用，除了要考慮透過備援系統提高整個環境的穩定與高可用性外，還要考慮到前端服務品質的維持問題。如同我們在一開始提到的，用戶導入伺服器虛擬化的目的是降低成本，但並不希望前端原有的服務能力因虛擬化而有所降低。

維持服務品質的具體方式是透過硬體資源的調配，確保前端的服務不因離、尖峰時間或需求的變化而受到影響，在任何時刻都能獲得必要的硬體資源。

從另一方面來看，導入伺服器虛擬化的一大目的是在盡量拉高硬體資源（處理器、記憶體等）的利用率，避免系統資源閒置而造成浪費。但除了提高利用率外，更重要的是「利用的效率」，也就是要把系統資源分配到「對」的地方。否則即使將處理器利用率拉高到90％以上，但卻沒有妥善將運算能力分配到最需要的服務上，就會影響到關鍵服務的執行能力。

虛擬環境中一般會有分別負擔不同服務的多個虛擬機器，而這些服務通常會有優先順序的區別，也就是某個虛擬機器執行的服務比另一個虛擬機器的服務更重要，顯然的，更重要的服務就需要更優先資源分配。理論上，不同服務所需要的硬體資源是可以事先預測的，在導入虛擬化之前，管理人員就應該針對預訂執行的不同服務優先程度，替不同虛擬機器配置好需要的硬體資源。

但實務上要事先就擬好十全十美的資源分配，幾乎是不可能的事，不管事先的資源分配規畫多麼精確詳盡，一旦系統上線運行，總是會碰到各種未預料到的突發狀況，而使原先作好最佳化的資源分配變調。這時候就是自動負載平衡機制上場的時刻，與其透過人工監控不斷手動調整資源分配，不如讓自動化的負載平衡系統負責，讓這些系統持續監控系統資源利用狀況，並依預設政策動態調節資源分配，讓系統資源的調配能維持在最佳狀態。

目前一些較專業的虛擬平臺都提供了動態負載平衡的功能，如VMware ESX的Distributed Resource Service（DRS）、Virtual Iron的Live Capacity等。事實上，我們可以把這種虛擬機器的動態負載平衡看作是前面提到的線上遷移功能的延伸，系統先透過Virtual Center或Virtualization Manager之類的管理平臺，收集整個虛擬環境中的硬體資源訊息，並監控虛擬主機的工作負荷與實體主機資源使用狀況，然後依照事先定義的政策執行動態調整，使整個環境的硬體資源利用達到最佳化。

跨越實體虛擬的資源管理
對於同時執行數十個甚至上百個虛擬機器的環境，擁有一套能監控整個環境的運行與資源使用狀況的管理工具，的確是有效管理虛擬環境不可或缺的。

VMware與Virtual Iron都提供了Virtual Center或Virtualization Manager，這類平臺可監控與管理整個環境資源使用，但有一些限制：僅能用於支援自身的Hypervisor，而且Virtual Center還必須額外付費購買。

除了虛擬平臺廠商的管理平臺外，一些伺服器廠商也能提供類似的管理工具，如HP的VSE（Virtual Server Environment）就是，它是一套虛擬化管理工具，主要是搭配HP Integrity、ProLiant系列伺服器與BladeSystem c-Class刀鋒伺服器。VSE可同時分析實體及虛擬機器的資源利用狀況，必要時可以將系統負載，遷移到其他伺服器，以協助達成系統配置的最佳化，而且還能支援多家廠商的Hypervisor（VMware、Citrix和微軟等）。

另外Sun的xVM Ops Center、IBM的Virtualization Manager，以及Fujitsu的Systemwalker Resource Coordinator，也都是功能類似的管理平臺，不過由於這些工具的部份功能（如硬體健康狀態偵測、故障回報等），都必須搭配特定型號伺服器才能作用，因此限制便是只能搭配自家廠牌的伺服器使用。

儲存端的服務品質調節
前面提到的服務品質調節主要都集中在主機端，但我們從虛擬平臺的架構中可以看到，所有虛擬機器的I/O資源都是依靠底層的共享儲存設備提供，因此儲存設備是極關鍵的環節，它對效能及前端虛擬機器服務品質的影響非常大。

因為整個環境中所有實體主機，都是存取同一套儲存設備，僅僅在不同實體機器上遷移虛擬機器，並不能完全確保虛擬機器的服務品質，如果造成效能問題的主要原因是在I/O，那麼，在上層如何遷移虛擬機器都於事無補，無論怎麼遷移，I/O仍舊是同一個來源。

這麼一來，解決之道就是在儲存端也進行服務品質的調配，依前端對存取需求的優先性，分派不同的I/O資源，設法針對前端特定服務，去確保能取得足夠的效能，避免系統滿載時，衝擊到需要高存取效能的前端伺服器。

傳統上，儲存設備的調節效能作法，多半是切割快取記憶體給不同的磁碟區。但快取的大小，只是影響儲存裝置存取效能的因素之一，並不能充分達到調節效能需求的效果。

因此，目前許多廠商都在儲存設備中整合了更精細的資源調配功能。如NetApp的FlexShare，便能綜合考慮快取大小、存取的IOPS與頻寬上限等參數，以Volume為單位設定存取資源的優先程度，當系統滿載時，FlexShare可讓高優先等級的Volume維持在高效能狀態，其餘的Volume根據指定等級來提供服務。用戶還能設定更精細的存取政策，就像是在白天上班時間，優先把資源調度給資料庫應用的Volume；到了夜晚離峰時間，再把備份用的Volume轉到較高的優先順序。

EMC的服務品質管理器（Quality of Serive Manager，QoS）也能提供類似的功能。QoS可以監控系統的存取狀態，依據回應時間、頻寬與吞吐量來調節效能，在這種方式中，同樣也能制定出細緻的存取政策。至於HDS的QoS工具Hitachi Virtual Partitioning Manager與Server Priority Manager，則具備從傳輸埠、快取記憶體到磁碟的三層式資源調配架構，能搭配虛擬平臺的動態負載平衡（如VMware的DRS）確保關鍵應用所需的資源。VMware ESX與Virtual Iron的高可用性架構

目前唯一能提供高可用性機制的虛擬平臺，是VMware Virtual infrastructure 3的HA，以及Virtual Iron V4 XEE的LiveRecovery，兩者都架構十分類似，都是將數臺實體機器構成一個資源池，然後透過一個管理平臺（VMware的Virtual Center或Virtual Iron的Virtualization Manager）為儲存池中的實體機器建立叢集關係。

接下來每臺實體主機之間都會定期執行心跳檢測，如果任一主機未能在時限內回應心跳檢測，其他主機就會判定該主機已經失效，將會自動啟動與該主機有關的虛擬機器。限制是資源池剩餘的硬體資源必須大於或等於失效的那臺實體主機，這樣才能確保重啟成功。
如果與DRS或LiveCapacity等自動負載平衡功能搭配，則系統還能在任一實體主機故障時，自動安排在最佳位置重啟虛擬機器。

兩種高可用性機制的關鍵都在於底層必須依靠一套共享儲存設備，虛擬機器的資料是存放在後端儲存設備，而不在前端實體主機，因此實體主機失效不會影響到資料，只要把資料轉給另一臺實體主機上新啟動的虛擬機器使用即可。

兩者較大的差別是當Virtual Iron的Virtualization Manager失效時，將無法啟動LiveCapacity，必須復原Manager Server才能恢復高可用性機制。另外在記憶體的設定方面。VMware允許以硬碟Swap方式模擬記憶體，即使實體主機的實體記憶體較為不足，仍能重啟故障主機上的虛擬機器。而Virtual Iron就會限制一定要實體記憶體。

兩種方式互有利弊，VMware具有較大的彈性，但風險是若採用硬碟Swap將會大幅拖累虛擬機器的效能，雖然虛擬機器上的Guest OS仍可執行，但過慢的效能很可能會造成應用程式回應過慢，以致服務終止。而Virtual Iron的機制對記憶體的限制較嚴格，但較能保障服務的持續。

儘管這些高可用性架構都會持續監控整個叢集的資援使用率，確保叢集預留有足夠的備用資源。但普樺科技的產品顧問李舒玄表示，最保險的作法還是在叢集（或資源池）中保留一臺沒有執行虛擬機器的「空」實體主機，這樣才能確保失效切換的成功。

Part3 保護虛擬環境的建置策略

現實中不存在十全十美的IT解決方案，只有較適合或較不適合某類環境的區別。從我們前面談到的種種虛擬環境備份、備援與負載平衡手段就可看出，要達到相同目的，不會只有一種辦法。但不同方式所需付出的代價，以及達到的效果都各有不同，以備援來說，越高層級的保護，效果雖然越好，但相對的付出的投資也越高，不見得適合所有用戶。

不過從前面的討論，我們仍可歸納出幾個基本原則：

原則1 備份是不可或缺的基本措施
無論是否建有高可用性備援架構，都仍然需要備份。考慮到高可用性架構屬於一種同步複製的機制，也就是說主系統的錯誤也會被同步到備援系統上，要解決這個問題，還是得利用備份取得不同時間點的複本。另外為因應法規要求的長期保存需求，同樣也必須依靠備份來滿足。

至於要採取哪一種備份手段，則須依具體情況而定：

● 在虛擬機器上安裝代理程式：導入虛擬化之前，如果已為每一臺伺服器都購買了備份代理程式授權，則可把這些授權移到虛擬機器上使用，如此即可無需更動原有備份架構與政策。但前提是執行虛擬軟體的實體主機不能背負太多的虛擬機器，以免備份帶來的負荷影響到系統效能。如果要在實體主機上執行超過10個以上的虛擬機器，這種方式便不適用。

● 實體主機端備份：如果只有執行冷備份的需求，又能容許備份期間的效能降低，可以考慮實體主機端的備份，否則就得透過撰寫Script來確保熱備份的一致性。

● 儲存端備份：如果用戶的儲存設備能提供快照功能，那在備份時可優先考慮選擇儲存端備份，以將備份負擔從前端主機卸下。不過還要注意到需透過Script保持複本一致性，以及儲存設備效能問題。

原則2 依任務關鍵性與預算選擇備援類型
不是所有虛擬環境用戶都需要建立可自動執行失效切換的高可用性備援系統，需視用戶對虛擬機器失效後能容忍的回復時間長短而定，如果虛擬機器中執行的是極為關鍵的服務，只能容許幾十秒或更短的服務中斷，才需要導入高可用性架構，否則一般的備份就能滿足要求。

而虛擬環境的高可用性架構，由低到高又可分為幾個等級：

基本的實體主機備援
也就是在多臺實體主機上建立高可用性叢集，但底層的儲存設備、網路與外部的虛擬化管理平臺仍為單點。

實體主機＋儲存設備的高可用性
目前企業級虛擬平臺的架構中，資料都是存放一個共享儲存設備中，而虛擬平臺提供的高可用性功能，也都必須依賴這個共享儲存設備才能實現，因此共享儲存設備也就成為一個單點故障來源。一旦儲存設備損毀，則一切資料都會遺失，更談不上高可用性。因此對較講求可用性的用戶，為儲存設備建立高可用性架構，也是不可或缺的措施。

目前許多企業級儲存設備都能提供A-A或A-S的高可用性架構，當然用戶也可不利用儲存設備本身的高可用性機制，而透過儲存虛擬化產品如IBM SVM、DataCore的SANsymphony、SANmelody，以及Falconstor的IPStore等提供的多路徑動態傳輸功能，來達到儲存設備高可用性的目的。

實體主機＋儲存設備+傳輸通道的高可用性
當前端實體主機與後端儲存設備都建立高可用性後，還要考慮到連接實體主機與實體主機的區域網路，以及實體主機連接儲存設備或儲存設備彼此互連的區域網路或儲存區域網路（SAN），也都可能是導致系統失效的因素。

雖然網路設備出問題的機率比實體主機或儲存設備要低，但若要確保實體主機或儲存設備高可用性機制的傳輸路徑動態切換能夠成功，也需連帶建立起高可用性的傳輸通道，包括前端伺服器的區域網路，或後端儲存設備的儲存區域網路（SAN）也都必須冗餘設置，也就是兩套傳輸線路與兩套交換機。

全冗餘化（Full-Redundance）架構
許多虛擬平臺的監控管理，以及線上遷移、自動負載平衡等功能都需依賴Virtual Center或Virtualization Manager之類的管理平臺才能實現，雖然這些管理平臺的失效，不會直接影響到虛擬機器的運作，也不會影響高可用性功能，但用戶仍將因此失去許多管理功能（如線上遷移、自動負載平衡等）。一般的備份固然能滿足保護這些管理平臺的需求，但最理想的作法便是為這些管理平臺建立叢集，使整個虛擬環境的每一個環節都有冗餘系統備援，達到全冗餘化。

全冗餘化+異地端備援
全冗餘化的虛擬環境雖能達到極高的可靠性，但問題是所有備援系統都是位於同一地點（頂多是不同樓層），並無法因應天災、大規模停電等意外的衝擊。要解決這個問題，就必須建立異地端的備援。

異地備援建置有多種方式，可採取主機端、網路端或儲存端，不過考慮到虛擬環境中實體主機與網路的負擔通常相當高，並不太適合採用會增加主機與網路負荷的主機端或網路端異地備援方案，因此儲存端是較理想的方式。

目前許多較高階的儲存設備都能提供遠端複製機制，如EMC的SRDF（Symmetrix Remote Data Facility）、NetApp的SnapMirror、HDS的TureCopy等，均可不經過前端主機，而直接把資料複製到遠端另一臺儲存設備上。

當然也可利用DataCore SANsymphony與Falconstor IPStor等儲存虛擬化產品來達到遠端複製的目的，這類儲存虛擬化平臺也內建有遠端複製功能，可將其界接的儲存設備資料，從本地端複製到遠端，同樣不會佔用前端主機的運算資源，而且不像儲存設備內建的遠端複製會限制異地端設備的廠牌型號，可在不同廠牌、類型的儲存設備間進行鏡像複製，系統建置彈性更大。



原則3 視政策決定導入線上遷移與負載平衡與否
無需停機的線上虛擬機器遷移，或是自動負載平衡通常只有較少數用戶需要。多數企業都訂有停機歲修時間，也能容許主機在升級時短暫停機，除非是執行的業務極為關鍵，連一點點服務中斷都不允許，才用得上不停機的線上遷移功能。

而自動負載平衡的情況也類似，即使用戶發現原先為虛擬機器調配的硬體資源並不適當，而需重新調整，多數用戶也能接受以手動方式遷移虛擬機器，將虛擬機器從負擔較重的實體主機轉移到負擔較輕的主機上，只有大量執行關鍵應用的虛擬化用戶，才需要全自動的負載平衡機制。