Related Posts Plugin for WordPress, Blogger...

網管人雜誌

          本文刊載於 網管人雜誌第 73 期 - 2012 年 2 月 1 日出刊,NetAdmin 網管人雜誌 為一本介紹 Trend Learning 趨勢觀念、Solution Learning 解決方案、Technology Learning 技術應用的雜誌,下列筆記為本站投稿網管人雜誌獲得刊登的文章,網管人雜誌於每月份 1 日出刊您可於各大書店中看到它或透過下列圖示連結至博客來網路書店訂閱它。

文章目錄

Q1. vMotion / DRS 需要 vDS 交換器才可建置?
Q2. 虛擬主機能否套用 Microsoft Hyper-V 虛擬機授權?
Q3. vCenter 重新啟動後 vSphere Client 無法連上?
Q4. 啟用 VMware HA 功能後虛擬主機就不會有 Downtime?
Q5. vCenter Server 若故障則 HA 機制也無法運作?
Q6. 啟用 VMware FT 功能後虛擬主機就不會有 Downtime?
Q7. 如何達成零停機 (Zero Downtime) 的目標?

前言

          VMware公司長久以來專注在開發虛擬化技術,推出時日已久,所以擁護者非常多。在上集文章內已經討論過許多 VMware 實作時可能碰到的情況,而本文將接續探討更多用戶操作時可能碰到的狀況與解決辦法,例如 vMotion/DRS 是否需要vDS交換器才可建置、虛擬主機能否套用 Microsoft Hyper-V 虛擬機授權、啟用 VMware HA 功能後是否虛擬主機就不會有Downtime、vCenter 重新啟動後為何 vSphere Client 無法連上...等等。

          繼「VMware虛擬化技術實作問答(上)」之後,本文接著探討VMware實作時其他7個可能會碰到的實作問題,並進行疑難排解。這裡同樣以一問一答的方式進行講說。

Q1、vMotion / DRS 需要 vDS 交換器才可建置?

Q.聽說需要建立分佈式交換器 vDS (vNetwork Distributed Switch) 之後,才可以建置出 vMotion / DRS 遷移環境?

A. VMware 虛擬化平台架構中,具有二種虛擬交換器類型,分別是適用於中小型網路環境的標準型交換器 vSS (vNetwork Standard Switch),以及適用於大型集中控制網路環境的分佈式交換器 vDS (vNetwork Distributed Switch),簡單來說 vSS 交換器無法跨 Host 使用,而 vDS 不但可以跨 Host 使用,且當虛擬主機透過 vMotion 機制遷移到別台 Host 時,該虛擬主機在原先虛擬交換器中相關設定如 流入(Inbound) /流出 (Outbound) 頻寬限制、虛擬網路 VLANs 設定…等,都會自動套用到新的虛擬交換器上。

圖1、標準型交換器 vSS (vNetwork Standard Switch)

圖2、分佈式交換器 vDS (vNetwork Distributed Switch)

          虛擬交換器提供虛擬主機與實體網路交換資訊的能力,您可以把 ESX / ESXi Host 上的實體網路卡 (VMware 稱為 Uplink Port),指定給虛擬交換器以達到負載平衡 (Balances Traffic) 及容錯 (Failover) 也就是 NIC Teaming 功能,若虛擬交換器沒有指定實體網路卡則表示此虛擬交換器只能用於虛擬主機之間進行資料交換,而無法與實體網路環境溝通。

          但是否就表示一定要 vDS 才能建置進階功能 vMotion / DRS 遷移環境呢? 答案當然是否定的!! 就 vSphere ESXi 軟體授權來說,必須購買最高等級授權 Enterprise Plus 才具備分佈式交換器功能,那麼其它授權版本該如何建立支援 vMotion / DRS 遷移環境,答案是利用 vSS 虛擬交換器即可建置,不過前提為 ESXi Host 主機之間的 vSS 虛擬交換器必須「Port Group名稱相同」才可進行 vMotion / DRS 將虛擬主機遷移到另一台 Host 上相同的虛擬交換器上,但是相關設定並不會隨著遷移過去,所以遷移後必須檢查相關設定以避免遷移後虛擬主機網路不通的情況,當然還要符合其它運作條件如網路資源共通、儲存資源共享…等。

          以下表格為整理虛擬交換器 vSS 及 vDS 相關功能支援程度列表,以便讀者導入時可視需求及功能進行相關建置及設定:


Q2、虛擬主機能否套用 Microsoft Hyper-V 虛擬機授權?

Q.購買了 Microsoft Windows Server 2008 R2 Enterprise 在 Hyper-V 上可以運作四個 Windows 授權虛擬主機,在 VMware 虛擬化平台上是否也可以使用這樣的虛擬主機授權方式?

A.沒問題!! 不管您使用的是哪一種虛擬化產品如 Microsoft Hyper-V、VMware vSphere ESX/ESXi、Citrix XenServer、RedHat KVM…等,您所購買的 Microsoft 軟體授權均適用,但是 Microsoft 對於運作在非 Microsoft 軟體虛擬化技術上的虛擬主機並沒有提供技術支援,所購買的軟體授權具有向下相容的降級權利特性來執行舊版的 Windows Server 作業系統,舉例來說您若購買 Windows Server 2008 R2 Enterprise 軟體授權,您可以在虛擬主機上運作 Windows NT Server 4.0、2000 Server、Server 2003、Server 2003 R2 舊版作業系統,及較低功能的 Server 2008 R2 Standard 版本。

          下列表格中整理了 Windows Server 2008 R2 各種版本的相關技術支援程度,以及在虛擬環境中常見功能,例如 虛擬機使用權利數量(Virtuall Image Use Rights)、叢集技術節點 (Failover Cluster Nodes)、記憶體容錯同步 (Fault Tolerant Memory Sync)、線上新增 CPU 及記憶體 (Hot Add Processors、Memory)…等功能。


          當採購一份 Windows Server 2008 R2 Enterprise 軟體授權之後,每一份軟體授權允許您在「一台實體伺服器」上運作 1實體 OSE (Operating System Environment)4虛擬 OSE,簡言之就是可以運作運作1台 Windows 作業系統在實體主機上,但是只能運來提供硬體虛擬化服務或虛擬化管理軟體之用,以及運作 4 台 Windows 作業系統於虛擬主機上。

          如圖 3 所示一台實體伺服器購買了,Windows Server 2008 R2 Enterprise 軟體授權,實體主機運作了 Hyper-V 以進行硬體虛擬化 (1 Physical OSE) ,並且在其上運作了一套 Windows Server 2003 R2、一套 Windows Server 2008 R2 Standard、二套 Windows Server 2008 R2 Enterprise (4 Virtual OSEs)。

          若是在有二台實體伺服器的情況下,能否將 4 台虛擬主機分散成在二台實體伺服器下運作呢? 答案是可以的,但必須符合下列二個前提條件才行:
  1. 另外一台實體伺服器也必須取得 Windows Server 2008 R2 Enterprise 或 DataCenter 版本軟體授權。
  2. 另外一台實體伺服器上運作的虛擬主機不可大於本來的授權數量 (Enterprise 為 4 台虛擬主機,DataCenter 則無限制)。

圖3、Windows Server 2008 R2 Enterprise 允許在實體伺服器上運作最多 5 台 OSE

Q3、vCenter 重新啟動後 vSphere Client 無法連上?

Q.vCenter 主機為 Windows 作業系統,進行安全性更新之後重新啟動,但重新啟動後 vSphere Client 無法連上 vCenter Server?

A. 通常會發生這種狀況,常常是 vCenter Database 與 vCenter Server 是安裝在同一台主機的情況,導至此狀況的主因是 vCenter 主機重新啟動時 vCenter Database 的服務 (例如 MSSQL 或 MSSQL Express) 尚在初始化期間,但是 vCenter Server 的服務 (VirtualCenter Management Webservice) 已經要啟動了,但是由於 vCenter Database 尚未初始化完成,導致vCenter Server 的服務啟動失敗,所以若您遠端桌面連線至 vCenter 主機查看服務清單時,您會發現 vCenter Server 的主要二個服務「VMware VirtualCenter Management Webservice 及 VMware VirtualCenter Server」會是未啟動的狀態。

          當然您可以每次重新啟動 vCenter Server 主機後,再遠端登入進去手動啟動這二個服務後 vSphere Client 就可順利登入 vCenter Server 了,但這樣總是有點麻煩,以下將說明解決此問題的根本辦法,也就是將 vCenter Database 服務與 vCenter Server 服務進行相依性設定,簡單說就是日後 vCenter Server 重新啟動時,會先等到 vCenter Database 服務啟動完成之後,才接著啟動 vCenter Server 服務。

          下列設定環境中 vCenter Server 為 Windows Server 2003 R2 而 vCenter Database 為 MSSQL Server 2005 Express:

1. 首先請先登入至 vCenter Server 中點選「開始」後點擊「執行」輸入「services.msc」開啟系統服務頁面。確定 vCenter Database 的完整服務名稱,例如此例中 MSSQL Server 2005 Express 其服務的顯示名稱為 SQL Server (SQLEXP_VIM),但完整服務名稱則為「MSSQL$SQLEXP_VIM」。

圖4、查看 vCenter Database 的完整服務名稱

2. 接著修改機碼內容 (Registry),點選「開始」後點擊「執行」輸入「regedit」,切換路徑至「HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vpxd」,點選機碼名稱「DependOnService」後按下滑鼠右鍵修改機碼內容,在結尾加上 vCenter Database 的完整服務名稱「MSSQL$SQLEXP_VIM」後按下「確定」,關閉登錄編輯程式。

圖5、修改 vpxd\DependOnService 機碼內容加上vCenter Database 完整服務名稱

3. 再次開啟系統服務頁面,點擊 vCenter Database 服務名稱「SQL Server (SQLEXP_VIM)」後,按下滑鼠右鍵查看內容並切換到「依存性」頁籤,確認 vCenter Server 服務在依存清單內即完成服務相依性設定。

圖6、vCenter Database 服務相依性設定完成

Q4、啟用 VMware HA 功能後虛擬主機就不會有 Downtime?

Q.聽說啟用了 VMware HA 功能之後,運作於其上的虛擬主機就不會因為實體主機損壞而產生停機 (Downtime) 的問題?

A.VMware HA(High Availability) 其主要功能用為,當實體伺服器發生不可預期錯誤而導致停機 (也就是「非計畫性」的停機) 時,本來運作在此台 ESX/ESXi Host 虛擬化平台上的虛擬主機 (VM),會因為實體伺服器損壞而釋放對該虛擬主機及檔案 (.vmdk) 的鎖定機制 (Locking),因此別台健康的 ESX/ESXi Host 便可以接手相關的虛擬主機及檔案,接手成功之後便會將該虛擬主機「重新開機 (Power On)」。

          因此我們可以了解 VMware HA 機制啟用後當災難發生時虛擬主機的停機時間 (Downtime)為:
  1. 實體伺服器損壞時其上的虛擬主機等於不正常關機 (斷電)。
  2. 該台損壞的 ESX/ESXi Host 釋放虛擬主機檔案鎖定機制。
  3. 虛擬主機在別台健康 ESX/ESXi Host 上開機。


圖7、實體伺服器故障時虛擬主機遷移至其它台 ESX/ESXi Host 上開機

Q5、vCenter Server 若故障則 HA 機制也無法運作?

Q.因為建立 VMware HA 機制需要 vCenter Server 才能建立,所以當 vCenter Server 故障的話則 VMware HA 也無法運作?

A.在 VMware vSphere 4.x 其 HA 機制為 EMC 公司收購 Legato 公司後,將其公司的 Automated Availability Manager 技術加以改進後改名為 EMC Autostart,其運作原理是加入 HA Cluster 中的前 5 台 ESX/ESXi Host 為成為 Primary Host,而之後加入的 Host 則為 Secondary Host,並且 5 台 Primary Host 會自動推舉一台成為 Active Paimary Host。

          Active Paimary Host 功能為當 ESX/ESXi Host 發生故障損壞時,將會決定虛擬主機要在哪些健康的 ESX/ESXi Host 上進行啟動 (若您沒有另外指定啟動的 Host 時!!),而 Primary Host 主要功能則為同步整個 HA Cluster 之間所有 Host 的運作資訊,若故障損壞的 ESX/ESXi Host 是 Primary Host 時,則會有其中一台 Secondary Host 遞補上來成為 Primary Host。

          VMware HA 機制在建立時確實需要由 vCenter Server 來進行安裝 Agent 的動作,當 ESX/ESXi Host 加入至 HA Cluster 時,vCenter Server 會在該 ESX/ESXi Host 上安裝「VMware HA Agent」,此 HA Agent 為 ESX/ESXi Host 之間用來偵測彼此心跳 (Heartbeat) 以確認在同一個 HA Cluster 中的 ESX/ESXi Host 是否運作正常,因此當 ESX/ESXi Host 安裝好 HA Agent 之後,即使 vCenter Server 故障而 ESX/ESXi Host之間的 HA Agent 也能繼續偵測彼此心跳 (Heartbeat),所以不會影響到 VMware HA 機制的運作。

圖片來源: VMware 官方文件 – High Availability and Data Protection
圖8、VMware HA Cluster 運作流程圖

          至於最新版本 VMware vSphere 5.0 其 HA 機制,則已經不採用先前舊版的 Primary / Secondary Roles,而改為採用 Master / Slave Roles 的運作概念,也就是所有加入 HA Cluster 中的 ESX/ESXi Host 只有 1 台會成為 Master Host,而其它主機則成為 Slave Host,並且由 Master Host 來負責整個 HA Cluster 同步資訊,及決定當有 Host 故障損壞時虛擬主機啟動於哪一台 Host 上,至於成為 Master Host 的條件則依照 HA Cluster 中所有的 ESX/ESXi Host 中,哪一台 Host 能連接存取到的「儲存資源 Datastore」數量最多而成為 Master Host,若大家能存取的數量都一樣時則依 MOID (Managed Object ID) 數值進行比較,誰的 MOID 數值較大便成為 Master Host。

Q6、啟用 VMware FT 功能後虛擬主機就不會有 Downtime?

Q.若希望虛擬主機不要有任何停機時間,則 VMware FT 機制是否能達成這個要求?

A.VMware FT (Fault Tolerance) 主要功用為,若您的企業無法接受 VMware HA 機制啟動時虛擬主機有短暫的停機時間,那麼 VMware FT 可能是一個解決的方案。

          但是啟用 VMware FT 有許多先決條件要達成,例如 該虛擬主機不能進行快照 (Snapshot)、無法使用 Stoarge vMotion 功能、該虛擬主機只能使用一個 vCPU…等條件限制,VMware FT 機制會於二台不同的 Host 上分別建立 Primary 及 Secondary 虛擬主機,並且採用 vLockstep 技術以 ESX/ESXi Host 上的 VMkernel Port 來傳送 Primary 虛擬主機的資料至 Secondary 虛擬主機上 (但 Secondary 不會有實際 I/O 的寫入行為),當 Primary虛擬主機所處的 ESX/ESXi Host 故障損壞時,那麼 Secondary 虛擬主機會馬上接手相關作業並且成為 Primary虛擬主機,此時會在另一台 ESX/ESXi Host 再度建立一台新的 Secondary 虛擬主機來與 Primary虛擬主機同步資料。

圖片來源: VMware 官方文件 – High Availability and Data Protection
圖9、VMware Fault Tolerance 運作流程圖

Q7、如何達成零停機 (Zero Downtime) 的目標?

Q.所以若想以虛擬化平台來打造企業零停機 (Zero Downtime) 的環境應該如何達成?

A.經過上面相關的說明後,可以整理規納如下:
  • vMotion / DRS: 此機制為適合用於「計畫性」停機,例如 ESX/ESXi Host 實體伺服器發生記憶體、硬碟故障或者需要停機進行 Firmware 更新及歲修時,這種排定好計畫性的工作時可以使用此技術將運作於虛擬化平台上的虛擬主機遷移到其它台 ESX/ESXi Host 上,使得企業服務不中斷的情況下維修實體主機。
  • HA / FT:此機制為適合用於「非計畫性」停機,例如 ESX/ESXi Host 實體伺服器電力系統出問題不當斷電,或者實體主機的主機板損壞導致實體主機故障,這種非人為因素損壞的非計畫性故障狀況發生時,透過此機制可以使虛擬主機自動遷移到其它台 ESX/ESXi Host 上繼續開機運作。

          但是很重要的一點是,這些機制都僅僅是以保護 ESX/ESXi Host Level 層級而以,而並非虛擬主機的作業系統層級 (OS Level),以及作業系統上的應用程式層級 (Application Level),例如先前所提到的 VMware HA 機制當 ESX/ESXi Host 故障損壞時等於運作於其上的虛擬主機也是被不當關機,雖然虛擬主機可以在其它台 Host 上再度開機,但很有可能剛才虛擬主機的作業系統已經因為不當關機造成作業系統損壞,因此即使已經遷移到別台 Host 上也無法順利開機成功,因此作業系統的備份作業也是有其必要性。

          而 VMware FT 機制是讓二台虛擬主機資料一模一樣進行運作,因此若是 Primary虛擬主機發生當機的狀況時,例如 Windows 作業系統發生藍色當機畫面 BSOD (Blue Screen Of Death),則此時將會因為 vLockstep 同步機制所以 Secondary 虛擬主機也會發生系統當機的狀況。

          至於應用程式層級的保護機制,目前也有許多廠商研發相關機制如 Symantec 以 Veritas Cluster 技術開發的 Application HA 便是可以保護虛擬主機上運作的應用程式,如 MSSQL、Exchange、Oracle、SAP…等。

          所以綜合上述後我們可以了解到,想要達成企業服務零停機的目標其實要努力的方向很多,從實體伺服器擺放機房的冷氣空調、電力迴路、網路設備至保護實體伺服器 ESX/ESXi Host 及運作其上的作業系統 (OS) 及應用程式 (Application),都有許許多多不同的各種解決方案,當然每種解決方案都有其優缺點存在,端看企業所能忍受的停機時間及預算來預先做最好的打算。
文章標籤: ,