nginx Ubuntu Python Firefox Android java wordpress 程序员 编程 微软 apache 开源 php google 云计算 mysql shell Windows linux centos

《私有雲計算整合、虛擬化和面向服務的基礎設施》一2.3服務器虛擬化

2.3服務器虛擬化

雖然解決服務器散亂問題存在許多種方式,但是服務器虛擬化是當前既成事實的標準方法。借助虛擬化技術,一個物理服務器可以變身成很多個邏輯服務器,這也意味著DC內一大堆未充分利用的服務器可以被轉換成一個無縫的計算池,與此同時能夠將應用程序從它們的煙囪中拆離出來,因此也可以完全廢棄煙囪式存儲子系統。
服務器虛擬化後最直接的效果如圖2-4所示,通過服務器虛擬化可以完成DC物理服務器的整合,減少數據中心所需的物理服務器整體數量,由此而降低的成本讓人無法抗拒。而服務器虛擬化減少了物理服務器的數量,意味著更低的能源開銷,包括服務器以及冷卻系統的能源開銷,也因此降低了操作代價(Operation Expenditure,OPEX)和未來DC在硬件設備上或固定資產(Capital Expenditure,CAPEX)上的投入。服務器虛擬化也大大降低了對托管空間的需求,使得企業能夠以最小代價獲得發展空間。另外,從服務器整合和管理角度出發,服務器、存儲和網絡相互交織在一起而產生的復雜性也得到相應簡化。

screenshot

向雲計算遷移並不是一次性的徹底革新,它是一個向完全虛擬化DC漸進式的轉移和演變,而現在正是開始這一進程的最佳時機。

2.3.1虛擬機和監視器

服務器虛擬化采取的是“一對多”的模式,即一個單獨的物理服務器被劃分後,看起來就像多個相互獨立的邏輯服務器一樣。每個邏輯服務器分別對應著一個VM,提供一個完整的服務平臺,能夠支持一個完整操作系統所需的所有工作。一旦劃分好物理服務器,每一個邏輯服務器將自動運行相應的操作系統和應用。由於客戶端的操作系統不一定相同,因此在同一個物理服務器上以安全可控的模式同時運行幾個操作系統和應用程序是可行的。
為支持虛擬環境而研發的更強壯的x86平臺,包括了多核CPU、AMD虛擬化(AMD Virtualization,AMD-V)[1]應用和Intel公司虛擬化技術(Intel Virtualization Technology,Intel VT),讓服務器虛擬化更加可行。
市場上存在各種各樣的虛擬化軟件,其中最廣為人知的是VMware、XEN[2]和Hyper-V[3]。盡管它們的結構和特性都有所不同,但都是基於VM與VM相互共享硬件資源(CPU、內存、磁盤和單臺硬件服務器的I/O設備)這樣的概念。一般情況下,虛擬化軟件是通過直接在計算機硬件或者主機操作系統之上增加一個精簡軟件層而實現,這樣的軟件抽象層一般被稱為虛擬機管理程序或者是虛擬機監視器(Virtual Machine Monitor,VMM)。
虛擬機管理程序將基礎的物理硬件(如CPU、內存、磁盤和I/O系統)與OS剝離,把實際的物理服務器硬件資源隱藏在分布的VM之後,使得用戶感覺好像存在一個邏輯資源池,這些VM能夠共享池中資源。虛擬機管理程序的功能包括:
創建VM;
將物理服務器硬件資源的虛擬池中的“硬件資源”分配給VM;
監視VM的狀態;
負責將VM從一個系統遷移到另一系統中。
存在兩種類型的監視器:
I型(又稱本地、裸機)虛擬機管理程序:I型虛擬機管理程序直接運行在服務器硬件平臺之上,負責硬件控制及用戶OS監控,用戶OS運行在硬件之上的第2層。
II型(又稱宿主)虛擬機管理程序:II型虛擬機管理程序作為第2層軟件,在監控器層的常規OS環境中運行,而用戶OS運行在硬件之上的第3層。
本章服務器虛擬化部分將對兩種類型的虛擬機管理程序分別進行探討。

2.3.2VMware 網絡定時器

要了解服務器虛擬化,首先要懂得虛擬機管理程序的網絡基礎,它屬於圖2-2中所示的“互連端點A”部分。本章選擇VMware ESX服務器作為I型虛擬機管理程序平臺的代表,ESX服務器主機通過一個軟件虛擬交換機,連接到本地VM以及網絡(光纖模塊)中。
ESX服務器網絡組件
VMware 虛擬化環境中的網絡接口卡(Network Interface Card,NIC),是一個比物理硬件單元含義更廣的術語。確切地說,vmnic是指主機服務器硬件中的物理網絡適配器,而vNIC代表虛擬NIC,它是由VMware的硬件抽象層(Hardware Abstraction Layer,HAL)提供給VM的虛擬硬件設備。Vmnic用於通往物理DC 光纖模塊的上行鏈路中,在用戶OS看來,vNIC和物理NIC一樣。VMware能夠模仿幾種常見的NIC(vlance和Intel e1000),因而用戶OS可以對這些vNIC使用標準的設備驅動。圖2-5展示了ESX主機的各類接口,在物理主機(ESX服務器)上有4個vmnic以及4個VM,每個VM都單獨配置了一個vNIC,vmnic及vNIC均通過虛擬交換機進行連接。

screenshot

主機上運行的VMware ESX帶有一個虛擬管理端口vswif,也稱為服務控制接口,ESX服務器使用該接口與VMware vCenter服務器進行通信,管理與VMware vSphere客戶直接交互的主機,也可以使用安全外殼(Secure Shellssh)登錄到主機的命令行接口(command-Line Interface,CLI)。VMware ESXi主機因為沒有服務控制OS,所以不會使用vswif接口。
說明:服務控制OS是一個更新的Red Hat企業Linux OS版本,默認安裝並運行在每個ESX服務器上。
每個主機都擁有一個或多個虛擬端口,稱為虛擬機器核心NIC(Virtual Machine Kernel NIC,vmknic),VMware ESX分別使用這些端口為Internet SCSI(iSCSI)、網絡文件系統(network file system,NFS)訪問、VMware VMotion提供服務。Vmknics還可以用於VMware ESXi系統中,與VMware vCenter服務器進行通信。
說明:與傳統(完備)ESX相比,ESXi屬於“瘦”虛擬機管理程序,因為它沒有服務控制功能。由於ESXi相對輕便,安裝和啟動都比ESX要快得多,因此,可以將ESXi嵌入到物理服務器 的flash芯片,或者主板等中間。
VMware提供了兩種類型的軟件虛擬交換機:vNetwork標準交換機(vNetwork Standard Switch,vSS,也稱為vSwitch)以及VMware vNetwork分布式交換機(vNetwork Distributed Switch,vDS)。每個主機都會單獨配備一個vSS。另一方面,vDS在一組物理主機之間提供了一致的虛擬交換機,這將有助於減少網絡維護工作,同時借助網絡VMware VMotion就能夠實現VM在任意主機間的遷移,而不會對網絡協議帶來影響或對基本連通性產生破壞。
每一個vNIC都通過端口組連接到標準的vSS或者vDS,每個端口組都屬於某個特定的vSS或者vDS,系統也將定義一個VLAN或一組VLAN供vNIC使用。此外,端口組能夠指明其他網絡屬性,比如速率限制以及端口安全等。在隨後創建VM的階段中,編輯VM屬性時,可以將VM分配給端口組。
Cisco Nexus 1000也屬於vDS,本章將把它作為分布式虛擬交換機平臺的樣例,更多有關Nexus 1000的詳細內容,請參考2.3.3節的相關內容。
vNIC MAC地址及VM遷移
ESX3.x版本的VM能夠支持4個vNIC,ESX4.x版本的VM最多能夠支持10個nNIC。大多數情況下,vNIC介質訪問控制(Media Access Control,MAC)地址由ESX服務器自動生成,不過,管理員也可以靜態地定義MAC地址以方便基於DHCP的服務器尋址環境,與靜態指定的MAC地址關聯的固定ip地址通常都會分配給同一VM。
如果VM之間產生了MAC沖突,ESX服務器主機能夠檢測到沖突並解決沖突。00:50:56:00:00:00到00:50:56:3F:FF:FF的地址範圍是留給靜態分配的VM MAC地址,管理員為VM分配的靜態MAC地址不能超過該範圍。
每個VM都擁有一個帶有.vmx後綴的VM參數文件,包含了自動生成的MAC地址信息。文件中還包含了地址生成算法以及定位信息,所以如果移走該文件,VM的MAC地址也可能會發生變化。
使用Vmotion功能特性,ESX服務器可以在ESX服務器集群中將VM從一個物理的ESX服務器遷移到另一個服務器之上。VMotion遷移不會對MAC地址產生影響,如果一個VM使用VMotion從一個ESX服務器遷移到其他服務器上,該VM的MAC地址不會發生改變,因為VMware虛擬機器文件系統(Virtual Machine File System,VMFS)的卷位於SAN上,無論是源ESX主機還是目標ESX主機都能訪問到這一信息。
vNetwork標準交換機的局限
VMware將vSS視為虛擬機管理程序的一部分,ESX3.5(作為vSwitch)、ESX4.0以及vSphere 4(作為vSS)都支持該功能。VM通過vNIC連接到vSS,如果兩個VM分別帶有一個vNIC並連接到同一個vSS,相互之間希望通信,vSS將直接承擔起一個L2交換功能,不需要將網絡傳輸流轉發到物理或外部DC光纖模塊完成。因為嵌入式vSS的主要優勢就在於其簡單,所以每個虛擬機管理程序都帶有一個或更多的vSS的獨立實例。不過,vSS的局限性則超過了它的優勢:
配置缺乏可擴展性:因為每個嵌入式vSS都代表了配置(對每個ESX服務器都具備局部重要性)中一個獨立點,所以當在DC中需要部署多個ESX服務器時,將遇到配置可擴展問題。
貧乏的操作可控性:大多數情況下,網絡管理員訪問不到vSS,因此盡管vSS也是網絡的一部分,但並不如其他DC基礎設施一樣易於管理,因而在由vSS(也同樣被看成不受控的網絡設備)創建的非受控網絡上對VM進行維護和安全管理也逐漸成為服務器(或VM)管理員所面臨的挑戰,特別是當系統中VM數目不斷增加時更是如此。vSS會在DC基礎設施關鍵部位—服務器集群中引起嚴重的操作不一致性。
說明:當物理服務器散亂伴隨著VM產生時,同樣也會帶來另一種散亂—VM散亂。因此簡化VM配置的管理以及維護對服務器虛擬化非常重要。
分布式虛擬交換機
嵌入式vSS的局限性可采用分布式虛擬交換機(Distributed Virtual Switch,DVS)來克服,DVS能夠同時支持多達64個ESX主機交換,而不需要像vSS一樣對每個主機進行單獨配置。DVS從根本上將嵌入式虛擬交換機的控制及數據平面分離,它支持由集中管理系統(控制平面)對多個、相互獨立的vSS(數據平面)進行管理,有效地使服務器管理員從主機級別網絡配置中抽身而出,轉到ESX集群級別的網絡連通性管理上。
VMware上實現的DVS也稱為vNetwork分布式交換機(VNetwork Distributed Switch,vDS),可以通過VMware vCenter服務器完成vDS配置。Cisco使用Nexus 1000V系列交換機對DVS上的框架進行調整,ESX/i 4.0以及vSphere 4及以上版本均支持DVS。
總而言之,我們更推薦使用Nexus 1000V系列DVS,因為與vDS相比,前者功能更豐富,健壯性也更好。Nexus 1000V交換機是本章探討DVS平臺的樣例,更多有關Nexus 1000V系列交換機的詳細內容,請參考2.3.3節的相關內容。

2.3.3Cisco Nexus 1000V交換機

Nexus 1000V(NX1KV)屬於分布式軟件交換機,能夠跨越在運行VMware ESX/i 4.0的多個主機之間。它克服了vSS或vSwitch的缺點。NX1KV包括兩個主要部分:
虛擬監視器模塊(Virtual Supervisor Module,VSM): 此模塊組成了交換機的控制平面,是一個運行NX-OS[5]的VM。
虛擬以太網模塊(Virtual Ethernet Module,VEM):此模塊組成了交換機的數據平面,通常系統中會部署1個或多個VEM。VEM本質上是一個虛擬線卡,被嵌入到每個ESX/i 4.0主機中,由它實現L2轉發功能。每個ESX服務器主機只能安裝一個單獨的VEM。
這兩個模塊完成了對物理交換機的抽象:監視器模塊是VSM,而線卡是每個ESX/i 4.0主機中運行的VEM。所有的配置都在VSM上進行,並傳播給所有屬於同一個域(更多細節,請參考後面“域ID”小節相關內容)的VEM。圖2-6展示了NX1KV的組件。
在物理交換機中,監視器模塊及線卡共用一個內部交換光纖來進行通信,在NX1KV中的監視器模塊及線卡從物理上被分離開來,盡管它們在邏輯上看起來還像在同一個交換機中工作,但卻是使用外部光纖(外部DC網絡)而非內部光纖來完成彼此間通信。VEM上的物理NIC是通往外部光纖的上行鏈路,從VM vNIC到本地虛擬以太網端口間的數據傳輸由VEM負責轉發,但是VEM並不會直接將數據轉發給其他VEM。相反,源VEM將包發往上行鏈路,然後通過外部光纖將這些包轉發給目標VEM。VSM不在數據路徑中,並不參與實際的數據包轉發。
虛擬接入層是服務器虛擬化的前端,可以使用NX1KV來構建虛擬接入層。更多有關使用NX1KV進行虛擬接入層設計的案例,請參考9.1節的相關內容。

screenshot

說明:為了遵守NX1KV VSM/VEM的慣例及術語,“包”與“幀”兩個術語在本節及它的子章節中可以互換使用。
虛擬監視器模塊
VSM建立了NX1KV的控制(管理)層,它為網絡管理員提供了跨越多個VEM的單點配置管理。與傳統交換機將控制平面集成到硬件中不同,VSM被部署成一個運行NX-OS的VM,也就是一個OS。即可以使用IOS文件[6]也可以使用公開虛擬化格式模板(Open Virtualization Format,OVF)[7]來安裝VSM。
說明:作為在VM上運行VSM的替代,VSM也有一個物理設備實體—NX1010,用戶能夠使用Nexus 1010同時運行最多4個NX1KV VSM。
安裝了VSM/NX-OS的VM與其他OS擁有相似的基本系統需求。VSM要求有一個單獨的虛擬CPU,2GB的指定RAM,以及3個vNIC,這3個vNIC需具備以下功能:
控制接口:控制接口屬於L2接口,VSM使用該接口與VEM進行通信。該接口負責處理低級別控制包,包括心跳以及任何需要在VSM及VEM之間進行交換的配置數據。控制接口通常是VEM的第一個接口,在VM網絡屬性中以“網絡適配器1”身份進行註冊。
管理接口:在常見的Cisco交換機中,管理接口通常為mgmt0端口。為了便於管理,會為mgmt0分配一個IP地址。該接口負責建立並維護VSM與VMware vCenter服務器之間的連接。管理接口一般都是VSM上的第2個接口,在VM網絡屬性中以“網絡適配器2”身份進行註冊。
包接口:包接口也是一個L2接口,只負責兩種類型的控制流傳輸:Cisco發現協議(Cisco Discovery Protocol,CDP)[8]及Internet組管理協議(Internet Group Management Protocol,IGMP)[9]。當VEM接收到一個CDP包,VEM會將該包重新轉發給VSM,VSM對包進行分析後,會將包轉送到CDP入口。包接口同時還負責協調多個VEM間的IGMP。例如,當一個VEM接收到一個IGMP請求時,該請求將被發送給VSM,由VSM負責協調交換機上所有VEM之間的請求。包接口通常為VSM上的第三接口,在VM網絡屬性中以“網絡適配器3”的身份進行註冊。
說明:VSM VM的vNIC要求Intel e1000網絡驅動,e1000網絡驅動並不是建立VM時的默認驅動,因而有可能當定義VM時,OS並不一定能夠支持它。不過,用戶可以手動改變VM參數文件中的驅動器。使用“Other Linux 64-bit”作為OS,就可以激活e1000驅動器,並且將其設置成默認驅動。
NX1KV使用了虛擬機箱的概念來模仿一個66槽模塊化以太網交換機,該交換機具有一些冗余功能:
槽1是為活動VSM保留的。
槽2是為雙工監視器系統的從VSM保留的。
當主機都接入到NX1KV交換機時,槽3~66以順序方式分別分配給相應的VEM。換句話,一個VSM最多可以管理64個VEM。
說明:用戶可以通過改變“host vmware id”配置順序來更改VEM–到–槽–序號的映射關系,更多有關該命令的詳細內容,請參考2.3.3節的內容。
高可獲得性及VEM
一個VSM可以扮演如下角色:
active:active角色負責系統控制,在mgmt0接口上進行配置。
standby:standby角色監控active VSM的狀態,如果發生交換機切換,則取而代之。
standalone:standalone角色是沒有其他active-standy配置時,VSM端默認配置模式。
說明:調用“system redundancy role{standalone/primary/secondary}”命令可以控制VSM角色類型,調用“show system redundancy status”命令可以驗證VSM的系統冗余狀態。要記得執行“copy running-config startup-config”命令來保存配置信息,維持系統重啟後的一致性。更多有關這些命令的細節信息,請參考2.3.3節的相關內容。
NX1KV交換機的高可獲得性(High Availability,HA)部署更像是在物理機箱中配置雙工監視器。在虛擬機箱中,兩個VSM以active-standby方式配置,槽1留給active VSM,而槽2留給standby VSM。第一個VSM將承擔active VSM角色,而其他VSM將默認為standby VSM。在固定間隔內,將對兩個VSM的狀態及配置信息進行同步,來保證在active VSM發生故障時,能夠進行透明和穩定的交換機切換(Stateful Switchover,SSO)[10],將工作移交給standby VSM。
VMware vCenter及Nexus 1000V
NX1KV交換機的實例在VMware vCenter服務器中被表示成vDS。借助vDS,一個虛擬交換機能跨越多個ESX主機的虛擬交換機。在建立VSM與vCenter服務器之間的鏈路時,可以使用VMware虛擬基礎架構方法體系(Virtual Infrastructure Methodology,VIM)[11]應用程序接口(Application Programming Interface,API)在vCenter服務器上構建NX1KV交換機。
說明:VMware的管理體系被分隔成兩個主要模塊:DC和集群。DC包括了所有VMware部署組件,如主機、VM以及網絡交換機,像NX1KV。在VMware DC內,一組主機與VM所組成的CPU及內存資源池構成了一個集群,用戶可以創建一個或多個集群,然後在集群內創建VM或在屬於該集群的主機間任意遷移VM。主機和VM不一定必須是集群的一部分,它們也可以駐留在DC上。
Nexus 1000V vCenter服務器擴展
vCenter服務器支持第三方管理插件對vCenter服務器功能及它的圖形化用戶界面(Graphical User Interface,GUI即vSphere客戶端進行擴展。NX1KV交換機使用vCenter服務器擴展來展示NX1KV及其在vSphere客戶端的主要組件。NX1KV擴展是一個小的XML[12]文件(cisco_nexus_1000v_extension.xml),可以使用Web瀏覽器從VSM的管理IP地址上下載,插件必須在VSM之前安裝,才能建立一個到vCenter服務器的鏈路。
Opaque數據
Opaque數據包含了一組NX1KV配置參數信息,由VSM進行維護,當VSM與vCenter服務器之間的鏈路成功建立後,將傳播給vCenter服務器。Opaque數據還包含了每個VEM所需的配置信息,當安裝VEM時,VEM可以利用這些配置信息建立與VSM間的連接。這些信息包括:
交換機域ID
交換機名稱
控制及包VLAN ID
系統端口屬性文件
當一個新的VEM加入後,無論是初始化安裝後還是當ESX主機重啟後,VEM均類似於一個未編程線卡。vCenter服務器將自動向VEM發送opaque數據,隨後VEM將利用這些信息與VSM建立連接,然後下載正確的配置數據。
VSM到vCenter的通信
VSM與vCenter之間的鏈路負責保持vCenter服務器內的NX1KV交換機定義,同時負責傳播端口參數文件(參見後面的“端口參數文件”的內容)。當NX1KV vCenter服務器插件安裝完畢,鏈路也隨之定義成功。連接包括了以下參數:
vCenter服務器IP地址
通信協議—HTTP之上的VMware VIM
ESX主機駐留的VMware DC名稱
當連接建成後,除了鏈路外,還在vCenter服務器內創建了一個NX1KV交換機。每個VSM都通過一個唯一的擴展鍵連接到vCenter服務器。在創建交換機實例的過程中,VSM將把之前定義好的所有端口參數文件及opaque數據傳播給vCenter服務器,opaque數據向VEM提供了規定好的配置信息,使得VEM安裝後就能與VSM通信。
如果VSM和vCenter服務器之間的連接發生故障,一旦連接恢復,VSM將必須確保故障期間所有配置更改信息都必須及時告知vCenter服務器,VSM與vCenter服務器之間的鏈路也將負責在連接建成後,傳播新的端口參數文件以及任何對現有系統的更改信息。
虛擬以太網模塊
VEM的作用類似模塊化交換平臺中的線卡,從轉發的角度來看,每一個VEM都是一臺獨立的交換機。不同於VSM,VEM將作為核心組件,按照在每一個ESX主機而非VM上。VEM的存儲空間是固定的(大約需要6.4MB的磁盤空間),而它的RAM使用是可變的。
常規配置方案中,每一個VEM需要10~50MB的RAM,而如果要求能夠充分發揮VEM的擴展性,則最多需要150MB空間。每一個NX1KV實例交換機包括66個槽—2個留給VSM,剩下的64個留給VEM。最低配置是一個VSM(無法實現VSM高可獲得性)加一個VEM,而最高配置是2個VSM(一個為active,一個為standby)加64個VEM。
VEM交換機端口分類
VEM能夠支持如下類型的交換機端口:
虛擬以太網(Virtual Ethernet,vEth):該端口負責連接到VM的vNIC上,或者是某個指定類型接口,諸如vswif或vmknic接口。vEth接口屬於沒有關聯物理組件的虛擬端口,vEth接口可以表示成vEth Y,這裏的Y代表具體的端口序號。借助VMotion,標註對VM是透明的,即不論相關聯的VM的具體位置,接口名稱都是一樣的。當創建好一個新的VM後,與該VM所關聯的vNIC的vEth接口也相應被創建。vEth接口與VM擁有同樣的生命周期,如果某個VM被臨時性關閉(用戶OS關閉了),vEth接口將仍然保持活動狀態,並且映射到原來的VM上,如果刪除該VM,系統將釋放與之連接的vEth接口資源,以便它能夠為新加入的VM提供服務。
以太網(Ethernet,Eth):接口代表了某個VMNIC(物理NIC),可以表示成EthX/Y,其中X代表模塊序號,而Y代表模塊上的端口序號。這些Eth接口分別對應著特定的模塊。
端口通道(PortChannel,Po):端口通道是同一VEM的多個Eth接口匯聚之處,它不能由系統默認生成,必須顯式說明。
端口參數文件
NX1KV提供了一個名為端口參數文件的功能特性,這是一些網絡協議,VMware使用它來簡化網絡服務。端口參數文件是一組接口級配置命令,被加工整理成一個完整的網絡協議。VSM負責制定端口參數文件,並通過VMware-VIM API將它傳播(輸出)到vCenter服務器,在NX1KV上配置好的端口參數文件看起來就像分布在vSphere客戶端的一個VMware分布式虛擬端口組,類似一個標準的vDS。一個新加入或現有的VM能夠擁有獨立的vNIC,並分配到正確的虛擬端口組,這些端口組繼承了端口參數文件的設置。
當認可一個新加入的VM後,系統將選擇合適的端口參數文件,NX1KV會基於該端口參數文件定義的協議創建一個新的交換機端口,可以通過重用端口參數文件來降低類似VM服務的工作量。當新開通的VM啟動後,NX1KV交換機將為VM帶有的每個vNIC都創建一個vEth接口,這些vEth繼承了之前所選定的端口參數文件的定義。代碼清單2.1給出了一個vNIC端端口參數文件配置模板的樣例。
screenshot

端口參數文件屬於動態協議,當網絡需求發生改變時可以對其進行修改,對主端口參數文件的更新將被應用到使用該參數文件的每個交換機端口上。端口參數文件同樣也負責管理ESX主機上的物理NIC(physical NIC,VMNIC),這些參數文件也稱為上行鏈路端口參數文件,將分配給物理NIC,這一信息也包含在ESX主機安裝VEM的工作中。當添加某個ESX主機到交換機中後,上行鏈路參數文件會同樣分配給新加入VEM的物理NIC。代碼清單2.2展示了一個VMNIC末端的端口參數文件配置模板樣例。
screenshot

說明:如果配置某個參數文件為上行鏈路(調用可選“capability uplink”命令),就只能把它分配給物理端口(physical port,Eth),而不能再用它來配置虛擬端口(virtual prot,vEth)。
VM的整個生命周期中,都將通過端口參數文件來強化網絡協議,而不論該VM是否會從一個服務器遷移到另一個服務器上,或者是掛起、休眠還是重啟。在VM遷移中,諸如端口計數器以及流統計信息,所有VM所參與的網絡傳輸檢測活動,包括NetFlow、封裝遠程交換端口分析器(Encapsulated Remote Switched Port Analyzer,ERSPAN)[13],在有了VMotion後都能不受幹擾地執行。而這一點正是雲IaaS操作所需要的關鍵可管理性。
該誰了:服務器還是網絡管理員
在典型的DC操作環境中,服務器管理員通常負責管理OS以及應用,而網絡管理員則控制交換機以及相關協議。NX1KV交換機保留了網絡管理員與服務器管理員不同的功能角色,同時還創建了一個新的角色,該角色綜合了網絡及服務器管理員的功能,這一點也是通過端口參數文件完成的(更多細節請參見本章的“端口參數文件”的相關內容)。
網絡管理員負責定義端口參數文件,並將它們輸出給vCenter服務器,端口參數文件在vCenter服務器中類似普通的VMware端口組。當系統為新加入的VM提供服務時,服務器管理員將挑選合適的端口參數文件,NX1KV將基於該參數文件創建新的交換機端口,服務器管理員也可以通過重用該參數文件來簡化對其他類似VM的服務。
VEM到VSM的通信
類似VSM,每一個VEM都擁有一個控制和包接口。這些接口是不可控的,終端用戶不能直接配置接口。VEM借助vCenter提供的opaque數據在合適的VLAN上完成對這些控制及包接口的配置工作,並將這些正確的上行鏈路參數文件應用到控制及包接口,以便和VSM之間建立連接。當VSM識別出VEM後,一個新模塊將被虛擬地插入到NX1KV交換機的虛擬機箱中,VEM隨後將被分配得到一個3~66中最小可得的模塊序號,VEM首次啟動時,VSM將會分配該模塊序號給VEM,並在ESX服務器上使用全局唯一ID(Universally Unique ID,UUID)[14]對該VEM進行追蹤。UUID能夠確保即使發生連接超時或電力故障使得ESX主機掉線,在故障解除後,VEM也能夠保留它的模塊序號。
VSM負責維持與它相關的VEM之間的心跳信號,信號每次傳輸間隔為2秒,如果VSM在8秒內沒有接收到應答消息,VSM將認為該VEM已經被移除到虛擬機箱之外。如果VEM是因為連接問題而無法進行應答,VEM將在它最後的正常狀態時間段中堅持轉發包,當運行中的VEM與VSM之間的連接恢復後,VEM就不需要再次被重新編程。
系統VLAN
系統VLAN是端口參數文件中的可選部分,如果采用系統VLAN,該參數將把端口參數文件變成特定系統端口參數文件,然後包含在opaque數據中。使用系統端口參數文件的接口都是系統VLAN的成員,即使是ESX重啟後VEM與VSM間還未建立起連接,接口也將被自動激活。這樣一來,在ESX主機重啟後還未與VSM建立連接也能保證關鍵VMNIC的可用性。可以手動地將控制及包VLAN也定義成系統VLAN,用在vswif以及vmknic的VLAN也可以看成系統VLAN。不過,傳遞普通VM數據的VLAN不能被當做系統VLAN處理。代碼清單2.3給出了一個關鍵端口的端口參數配置模板。
screenshot

域ID
由於多個VSM及VEM之間可以共享相同的控制及包VLAN,因此系統必須要能夠確定此VSM應與哪個VEM連接,使用域ID則可以將VSM綁定到VEM中。NX1KV交換機使用域ID參數用來確定VSM及其相關聯的VEM,當系統首次安裝VSM後,將創建一個域ID,並作為opaque數據的一部分傳送給vCenter服務器,VSM向其關聯的VEM所發出的每一條命令都帶有域ID標識。
當VSM和VEM共享同一個域ID時,VEM將接受並響應該VSM的命令。VEM會自動忽略那些未包含正確域ID標識的命令或配置請求。如圖2-7所示,域ID18“連接”了兩個屬於同一VSM的VEM,它們均屬於同一個vDS,域28也屬於相同情況。
交換轉發
與帶有集中轉發引擎的物理交換機不同,每一個VEM都維護著一張單獨的轉發表,不同VEM之間的轉發表不需要同步。此外,也不存在從一個VEM的端口轉發到另一個VEM的端口這樣的概念,轉發給非本地VEM的設備的包將首先被轉發至外部網絡交換機,然後再被轉發給不同的VEM。

screenshot

MAC地址學習
無論是靜態方式還是動態方式,在一個NX1KV交換機中MAC地址都可能被多次學習。當VM運行在VEM上時,系統將自動生成靜態入口,這些入口不會隨時間失效。對於那些沒有運行在VEM上的設備,VEM能夠通過ESX主機上的物理NIC動態學習到MAC地址。換句話,與本地附加的VM有關的入口可以靜態習得,而與上行鏈路有關的MAC入口地址可以動態習得。來自其他ESX主機的VEM都維護了一個單獨的MAC地址表,因此,同一NX1KV交換機可能多次學習到同一給定MAC地址—每VEM一次。例如,某個VEM是直接連接到VM,VEM將靜態得到該VM的MAC地址,而另外一個VEM,也屬於同一NX1KV交換機,可能就是通過動態學習得到VM的MAC地址。
回路預防
NX1KV交換機不支持生成樹協議(Spanning tree Protocol,STP),也無法響應及生成橋接協議數據單元(Bridge Protocol Data Unit,BPDU)[15],NX1KV交換機會丟棄所接收到的BPDU包。
NX1KV交換機使用一種簡單的不需要STP的方法來預防回路產生。在以太網(Ethernet,Eth)接口所接收到的每個匯入包都需要檢查其目的地址,以確保所有包的目標MAC地址都是指向VEM內部,如果目標MAC地址屬於VEM外部範圍,NX1KV交換機將丟棄這樣的包,以防止指向物理網絡的回路產生。
NX1KV交換機無須使用STP就能夠防止VEM及第一跳接入層交換機之間的回路,不過,接入層交換機仍然需要激活STP,以防止物理拓撲上其他地方產生回路。

2.3.4ESX服務器存儲網絡概略

如果讀者能堅持讀到此處,在繼續之前應該給自己一些鼓勵,現在你已經完成ESX服務器網絡化的第一步,接下來該著手解決ESX服務器存儲網絡化的基礎問題了。這部分內容對應圖2-2中的“互聯點B和C”部分,也就是連接服務器模塊與存儲模塊(直接連接或通過光纖連接)的部分。
說明:互聯點C通常不會采用光纖通道,服務器模塊通過互聯點A連接完成NAS和FCoE接入才會使用的技術。
ESX服務器存儲組件
ESX服務器存儲操作主要由以下5個存儲組件完成:
虛擬機器監視器(Virtual Machine Monitor,VMM):VMM(或虛擬機監視程序)包含的層,能夠在VM內模仿小型計算機系統接口(Small Computer System Interface,SCSI)設備。VMM提供了一個抽象層,能夠隱藏並管理物理存儲子系統之間差異。對每個VM內的應用及用戶OS而言,存儲就是一個SCSI磁盤,只不過該磁盤是連接到虛擬BusLogic或者是LSILogic SCSI主機總線適配器(Host Bus Adapter,HBA)上。
說明:VM使用BusLogic或LSILogic SCSI驅動,BusLogic意味著系統采用的是Mylex BusLogic BT-958,BT-958屬於SCSI-3協議,支持Ultra SCSI(Fast-40)傳輸速率為每秒40MB。驅動模擬支持“SCSI自動配置”功能,例如,SCAM允許使用ID序號自動配置SCSI設備,因而不需要人工分配ID。
虛擬SCSI層:虛擬SCSI層的首要任務是管理SCSI命令並負責VMM與虛擬存儲系統之間的連接,這些虛擬存儲系統既可以是虛擬機器文件系統(Virtual Machine File System,VMFS),也可能是網絡文件系統(Network File System,NFS)。所有來自VM的SCSI命令必須經過虛擬SCSI層,這一層還負責管理I/O放棄和重置操作。在這一層,通過VMFS、NFS或原始設備映射(Raw Device Mapping,RDM),虛擬SCSI層將來自VM的I/O或SCSI命令傳送到更低層。RDM支持兩種模式:pass-through和nonpass-through。在pass-thruogh模式下,所有SCSI命令都能通過虛擬SCSI層,而不會受到阻攔。有關RDM的詳細內容請參考本章後面的“裸設備映射”的相關內容。
虛擬機器文件系統(Virtual Machine File System,VMFS):VMFS屬於集群文件系統,能夠協調共享存儲支持多個ESX主機同時讀寫同一存儲。VMFS支持磁盤分布式鎖機制,能夠確保同一個VM在同一時刻不會被多個服務器啟動。在簡單配置方案中,VM的磁盤將被看成VMFS中的文件。更多VMFS的內容請參考本章後面的“虛擬機器文件系統”的相關內容。
SCSI中層:SCSI中層的主要作用是管理ESX服務器主機上的物理HBA,維護請求隊列以及處理SCSI錯誤。此外,該層還包括自動重復掃描登錄,可以發現邏輯單元號(Logical Unit Number,LUN)到ESX服務器主機間的映射變更。它同時還負責處理路徑管理,包括自動路徑選擇、路徑重疊、故障切換以及恢復到某個指定卷。
虛擬SCSI HBA:在ESX服務器環境中,每個VM最多能夠使用4個SCSI HBA,而虛擬SCSI HBA能夠支持VM對邏輯SCSI設備的訪問,對VM而言,虛擬SCSI HBA等同於一個物理HBA。
虛擬數據存儲的概念
VM內的虛擬SCSI磁盤均由虛擬數據存儲提供,這些虛擬數據存儲源自物理存儲系統。一個虛擬數據存儲類似一個虛擬存儲池,能夠為VM內的虛擬磁盤提供存儲空間,也能存儲相應的VM定義。
虛擬磁盤(vmdk)是一個駐留在虛擬數據存儲中由ESX管理的文件,虛擬數據存儲屬於VMFS卷,是實現基於塊的存儲(類似光纖通道SAN以及iSCSI)的基礎,也是NAS存儲(基於NFS的卷)的掛載點。VMFS卷通常由單個LUN組成,不過它也能跨越多個LUN。虛擬數據存儲可以是如下任意一種文件格式:
虛擬機器文件系統(Virtual Machine File System,VMFS):ESX服務器會在本地SCSI磁盤(DAS)、iSCSI卷或光纖通道卷上部署該類型的文件系統,為每個VM創建一個目錄,在大多數虛擬數據存儲中,都推薦使用VMFS。
裸設備映射(Raw Device Mapping,RDM):RDM支持VM把RDM當做代理來直接訪問裸設備。一個RDM可以被理解成是一條VMFS卷到RDM卷的象征鏈路。
網絡文件系統(Network File System,NFS):ESX服務器能夠使用NFS服務器(NAS設備)上一個指定的NFS卷,ESX服務器將掛載該NFS卷,並為每個VM創建一個目錄。
總的來說,虛擬數據存儲僅僅是一個VMFS卷或者一個NFS掛載目錄。一個VMFS卷能夠跨越多個物理存儲子系統以便實現擴展。虛擬數據存儲提供了一個簡單的模型,無須將VM暴露在各式各樣復雜的物理存儲技術中,就能為每個VM分配存儲空間。這些技術包括:
fc SAN:由於FC SAN能夠支持VMFS、RDM以及HA集群,因此是一種應用最廣泛的部署選擇。FC SAN還支持VMotion及ESX引導。
iSCSI SAN:基於硬件的iSCSI SAN支持的功能類似FC SAN,如果使用了基於軟件的iSCSI,則不能夠支持從iSCSI SAN進行引導。
NAS:這一種部署將使用NFS協議,基於NFS的存儲不支持RDM、HA集群以及VMFS。按理說,通過NFS,比借助基於塊的存儲,更容易進行瘦管理、存儲動態擴展/收縮,以及克隆,不過兩者差別不大。
說明:DAS是一種合法部署,但由於它不提供共享,因此很少使用。
圖2-8展示了一個ESX服務器存儲體系結構,該結構中使用了VMFS卷和掛載NFS卷。每一個VM都被以一組文件形式存放在它自己的虛擬數據存儲目錄中。一個單獨的VMFS卷能夠包含一個或多個更小的卷,這些卷來自FC SAN磁盤或iSCSI SAN磁盤集群。新產生的卷可以被加在任意一個物理存儲、子系統或隨著存儲子系統一起被擴展的ESX服務器能獲悉的LUN中,並且將因為vCenter服務器向ESX服務器發送重新掃描的請求而被發現。

screenshot

說明:在某種程度上,ESX服務器實現了基於主機(或服務器)的存儲虛擬化,因為VMFS卷能夠支持FC和iSCSI SAN的塊級別虛擬化。
虛擬機器文件系統
VMFS存儲了VM文件,包括磁盤映像、快照等,它屬於聚簇文件系統,通過存儲共享以支持多個物理服務器同時讀寫同一存儲空間,同時對單獨的VM上鎖以預防發生沖突。VMFS提供了到磁盤的分布式鎖機制以保證同一VM不會在同一時間被多個服務器占用。如果某個物理服務器發生故障,該服務器對VM加上的磁盤鎖將被釋放,以便其他物理服務器能夠重新啟動該VM。
通過將多個VMFS卷綁在一起,能夠對VMFS卷進行邏輯擴展(例如,無損規模增長)。ESX服務器3.x以及vSphere 4.x支持VMFS版本3(VMFS3),它能夠在文件系統中引入一種目錄結構,更早一些的ESX服務器版本不支持對VMFS3卷的讀寫操作。自ESX 3以及VMFS3版本起,VM配置文件默認存放在VMFS分區中。一個VMFS卷能夠擴展到32個物理存儲擴展(每個VMFS卷可擁有32個擴展卷),包括SAN卷及本地存儲,這一功能特性能夠滿足VM對創建存儲資源卷的靈活性及資源池的需求。
對VMFS進行優化是為了實現存儲和訪問大容量文件,由於使用了大尺寸塊,VM磁盤性能與本地SCSI磁盤相差無幾。VMFS磁盤越大,元數據存儲所需的空間比例就越低,VMFS磁盤還能利用自有邏輯自動檢測到LUN的變化。VMFS還能夠支持諸如分布式日誌、沖突一致性VM I/O路徑以及機器狀態快照等功能,從而能夠實現對VM、物理服務器以及存儲子系統的快速根本原因分析及恢復。
裸設備映射
VM使用裸設備時可以采用兩種映射模式:
虛擬模式:該模式下系統隱藏了被映射磁盤的實際物理特征,因此用戶OS感覺被映射的磁盤像一個邏輯卷,或者虛擬文件系統。文件上鎖可以對並發更新時數據進行隔離從而能夠保護數據,寫操作復制可以啟動快照,由於虛擬模式支持虛擬磁盤文件的一致性行為,因而具備了存儲硬件之間的可移動性。
物理模式:該模式類似傳遞模式(pass-through),VMM繞過I/O虛擬化層(虛擬SCSI層),將所有I/O命令直接送給存儲設備。所有底層存儲設備的物理特性都將暴露給用戶OS。該模式適用於用戶在VM中使用了SAN感知設備的情況。不過,付出的代價就是VM以及物理節點RDM不能被復制,或者生成某個模板,也不能在有磁盤復制操作時進行遷移。該模式下系統不會提供鎖機制來實現數據保護。
RDM為VM直接訪問物理存儲子系統(采用FC或iSCSI)上的卷提供了一定的靈活性,它在VMFS卷與裸卷之間提供了一個象征性的連接,VM配置中引用了RDM文件(非裸卷),包括了管理和重定向物理存儲設備訪問的元數據信息。
如圖2-9所示,當一個卷對外開放後,VMFS完成了RDM文件到正確的物理存儲設備的映射,以及卷訪問之前必要的訪問檢查以及鎖控制,因此,接下來無須通過RDM文件就可以對裸卷直接進行讀寫操作。

screenshot

RDM支持對物理存儲設備的直接訪問,同時又保留了VMFS中虛擬磁盤的優勢,RDM一般適合於用戶OS上的HA集群或基於SAN的備份這類應用。

延伸阅读

评论