《VMware vSphere設計（原書第2版）》——2.2 ESXi設計

本節書摘來自華章出版社《vmware vsphere設計（原書第2版）》一 書中的第2章，第2.2節，作者：[美] 福布斯·格思裡（forbes guthrie）斯科特·羅威（scott lowe）肯德裡克·科爾曼（kendrick coleman），更多章節内容可以通路雲栖社群“華章計算機”公衆号檢視。

esxi hypervisor和傳統esx有很多共同元素，但是它與esx之間最大的差別就是移除了基于linux的service console。esxi保留了與esx類似的vmkernel和vmm元件，在vmkernel中增加了一些特性，增加了一個新的且比較小的管理控制台，以及一些使用者模式程序以取代老的service console 作業系統的功能。

esxi這樣重新設計是為了讓vmware使用者能夠像處理硬體裝置一樣，通過hypervisor實作橫向擴充。願景是實作一個基礎作業系統，讓它能夠自動配置，遠端接收配置資訊，從記憶體運作而不是從硬碟運作。但它仍然是一個足夠靈活的作業系統，支援不需要額外設施的小巧且随時可用的安裝：安裝到本地硬碟上，且保留本地儲存的狀态和使用者定義的設定。

當然，移除service console還是有一定負面影響的。很多以前安裝的服務和代理需要重新考慮如何處理。在esxi中，esx使用者熟悉的可以用于管理、排錯、配置的指令行工具已經被其他工具取代了。原來esx中用于備份、監控硬體的linux風格的第三方代理也需要用其他方式取代。

esxi作業系統建立在三個層次上，能夠實作和傳統esx一樣的虛拟機環境，但是在架構上與傳統esx有顯著差别：

vmkernel　vmkenel是esxi的基礎，且是為esxi專門設計的。它是64位的posix 作業系統的微核心。vmware設計并不是為了打造一個普通的作業系統（譯者注：即2型作業系統），而是一個能夠作為hypervisor的作業系統。vmkernel管理實體伺服器的硬體，協調所有cpu的資源排程和記憶體配置設定，控制磁盤和網絡的i/o stack，處理所有符合hcl（hardware compatibility list，硬體相容性清單）的裝置驅動。

vmkernel extensions　除了vmkernel外，還有很多kernel子產品和驅動。這些擴充使得作業系統能夠通過裝置驅動與硬體互動，支援不同的檔案系統，以及允許其他系統調用。

worlds　vmware把它的可排程使用者空間稱為worlds。這些worlds允許記憶體保護、與cpu排程共享，以及定義separation權限基礎。worlds有如下三種類型：

系統worlds　系統worlds是特殊的核心模式的worlds，能夠以系統權限運作程序。例如：idle和helper程序都是以系統worlds運作的。

vmm worlds　vmm worlds使用者空間的抽象，它讓每個guest作業系統都能夠看到自己的x86虛拟硬體。每個虛拟機都運作在由它自己排程的vmm world中。它将硬體（包括bios）呈現給每個虛拟機，配置設定必需的虛拟cpu、 記憶體、硬碟、虛拟網卡等。它還決定了每個虛拟機的監控模式，這取決于伺服器的實體cpu和guest作業系統的選擇。在完全虛拟化（二進制轉化）和硬體輔助虛拟化之間選擇（半虛拟化監控器，也叫vmi（virtual machine interface）在vsphere 5.0中已經不存在了）。

使用者worlds　使用者worlds指所有不需要以系統world賦予的權限來執行調用指令的程序。它們可以執行系統調用來與虛拟機或整個系統互動。

重要（且可以将esxi與其他普通作業系統差別開來）的一點就是系統引導的時候它是裝載到記憶體中的。使用者空間的worlds是永遠不會交換到硬碟中的。但是，可以通過資源池，像控制虛拟機一樣控制這些worlds。它們可以申請、共享或限制cpu和記憶體。這展現了esxi相對于傳統esx的優勢。在傳統esx中，service console是以一個world運作的，且一個service console代理會占用大量記憶體進而影響到其他程序。這就是為了阻止交換hostd程序，service console記憶體經常會增到最大值的原因。在esxi中程序得到了更好地保護，不會存在這個問題。

vmkernel有幾個值得關注的代理或程序：

hostd　hostd（由mgmt-vmware服務管理）是主要的管理程序。它負責與vmkernel互動，是直接vsphere用戶端和遠端api調用之間的聯系點。hostd還包括預設的snmp代理（預設是禁用的）。

vpxa　vpxa使得vcenter執行個體可以連接配接到vmkernel。當首次将host esxi伺服器連接配接到vcenter時，它會啟動vpxa程序，作為vpxuser賬号下vmkernel功能之間的媒介。

syslog　syslog程序可以将日志轉發到遠端syslog伺服器上。

ntpd　ntpd程序提供時間服務以保持host和時間伺服器的時間是同步的。保持時間同步很重要，這是因為伺服器之間的幾個服務，比如高可用性（ha）和基于目錄的校驗服務都是依賴于準确的時間同步的。你也可以設定虛拟機使guest作業系統的時間與本地host同步。

dcui　dcui是bios分割的黃色界面，顯示在伺服器控制台視窗。通過它你可以進行基本的配置、設定通路權限、重新開機服務代理等。

sfcbd　sfcbd程序是cim（common information model）代理，它通過一個可以外部通路的api以無代理的方式通路硬體監控。這樣就降低了對第三方硬體代理和snmp的依賴。

esxshell　esxi shell（technical support model，tsm）以esxshell程序的形式運作，提供一個簡單的指令行工具、一個本地控制台可以使用esxcli工具包（esxcli）、其他cli工具（如vmkfstools）、 esxcfg-* 指令（esxcli的替代），以及實時程序監控工具esctop。

後續會詳細介紹最後三個程序，以展示這三個程序在host管理方面中所發揮的作用。

在介紹esxi設計的安裝和部署選項前，有必要先了解esxi鏡像的結構。系統鏡像（system image）是個可引導的鏡像，它被加載到記憶體中然後以hypervisor的形式運作。esxi安裝程式使用這個系統鏡像将檔案拷貝到可引導裝置中（/bootbank分區）。首次引導後，鏡像會自動發現硬體并根據所選的安裝類型執行自動配置。系統鏡像可以通過cd、pxe、本地硬碟、usb儲存設備（u盤或sd卡）、fc、fcoe和iscsi san 等多種管道引導。

除了一些用來引導esxi的檔案外，esxi系統鏡像主要包括以下兩類檔案：

vmkernel可執行檔案　這些可執行檔案都是壓縮檔案，它們一起構成了vmkernel。你可以根據.gz擴充名來組織它們。加載esxi後，這些檔案不會在檔案系統中顯示。

歸檔檔案　歸檔檔案構成了可見的檔案系統。它們是由很多擴充名為.bgz、.v0n或者.tgz的 vib（vmware installation bundle）檔案。

解壓縮每個vib後，都會被覆寫添加到檔案系統中。連續解壓縮所有歸檔檔案後，隻有最新的變更是可見的。如果删除了一個歸檔檔案，那麼在檔案系統中就會顯示它的上一個歸檔檔案。

最後一個被解壓縮的歸檔檔案叫作狀态歸檔（state archive）state.tgz。這個歸檔中包含所有配置資訊，例如/etc檔案。在iso鏡像檔案裡是找不到這個狀态歸檔的，因為那時候（引導前）是沒有非預設配置的，配置都是在初始化的時候建立的。為了避免對引導磁盤的過度磨損（可能是基于flash的），配置變更發生時，這些更新會直接更新到硬碟中。這個更新動作每10分鐘發生一次，每小時不會超過6次。這就意味着host崩潰後有些變更可能無法恢複（雖然重新開機前會有硬碟更新的過程）。這個歸檔檔案tardisk是日常備份與恢複的基礎。

由于鏡像是被裝載到記憶體中的，是以運作時并不依賴于引導裝置。這表明引導裝置故障或者斷開連接配接時，作業系統都會正常運作。針對檔案系統但不會修改系統鏡像的變更在重新開機後會丢失。是以所有添加元件和配置的變更必須更新到鏡像中，以確定其永久性且能夠被重新裝載。

esxi僅認可授權的代碼，而且這些子產品必須有vmware 的數字簽名。這個關于vmkernel擴充的限制保證了環境的安全性、保全了系統資源和確定了代碼庫的嚴格性。

供應商鏡像

主要的伺服器供應商會定制自己的系統鏡像。這些iso鏡像都是正常vmware系統鏡像的增強版（包含硬體方面的擴充）。其中會包含新的或改進的硬體驅動，以及可以提供更好的硬體監控和支援資訊的cim插件。

你也可以定制自己的esxi鏡像。這個是很有幫助的，因為vmware提供的正常系統鏡像可能會過期。雖然vmware會釋出更新檔，但隻有在更新較少的情況下才會釋出新的鏡像。通過定制自己的鏡像，可以将鏡像流分成多個更新檔。此外，标準的系統鏡像并不會包含所有的驅動或硬體cim提供程式（provider），或者即使包含了也是過期的，需要更新。對于剛釋出的新硬體，用标準的鏡像可能無法安裝，這是因為其中沒有相應的驅動。還有一些插件，比如ha代理，通常它們都是通過vcenter推送安裝的，以及一些第三方解決方案，都可以通過自定義的方式添加到鏡像中。

為了滿足自定義esxi鏡像的需求，vmware在vsphere 5中釋出了一個新的工具image builder。image builder是一套powercli小指令，它将安裝包一起打包到自定義的iso鏡像中，并填充到一個專門的鏡像釋出容器（軟體倉庫）中。image builder使用三個不同的元件來建立自定義esxi鏡像：

vib　vib是esxi元件的安裝包，它的檔案擴充名是.vib。vib是個壓縮檔案，類似于tarball，其中包括載荷（例如，軟體、插件或者驅動）、一個描述檔案和一個簽名檔案。描述檔案中包含很多重要資訊：此vib依賴的vib（這些vib必須先于此vib安裝）、與其他vib間的沖突、此vib是否會取代以前的vib、是否需要重新開機host或者進入維護模式，以及它的驗收等級（acceptance level）。簽名檔案是用于驗證驗收等級的數字證書。

image builder工具有四個驗收等級：vmwarecertified、vmwareaccepted、partnersupported和communitysupported。每個vib都屬于某個等級，當image builder建立自定義鏡像的時候，這個鏡像不會接受任何高于最低vib級别的驗收等級。這保證了一個鏡像的驗收等級以最低驗收等級的元件為準。

vib author

vmware提供一個叫vib author的工具，使用這個工具可以很容易地建立community supported級别的vib。

image profile　image profile定義了由image builder建立的esxi鏡像中所包含的包。建好鏡像後，就可以建立image profile、添加vib了。更直接的方法就是克隆已有的image profile，然後根據要添加或删除的vib進行調整。你可以為不同的硬體或不同的配置建立和維護多個image profile。例如，不同的伺服器模型/生産商，是否帶有vmware工具、第三方插件、ha代理等。從vsphere 5.1開始，鏡像中已包含fdm（fault domain manager）代理。

除了每個vib的驗證等級外，image profile也有驗證登記。所有vib的驗證登記必須等于或高于image profile的驗證登記，否則就無法添加vib。當将vib添加到image profile中時，它的依賴和沖突也要遵從這個原則。

software depot　除了自定義鏡像前可以建立并添加vib外，伺服器供應商和oem硬體廠商也可以提供vib檔案以表示對其硬體的特殊支援，其中包括驅動和cim插件。

vib本身是可以被分發的，但是前提是必須先通過指令行工具或圖形界面的vum安裝。供應商則通常會選擇通過software depot來分發它們的産品。software depot将vib組成一個軟體包，這個包可以被image builder直接使用。software depot就是一個vib或者一個vib集合，再加上一些額外的包含在zip檔案中的中繼資料。這是一個很好的分發軟體包方式，因為它提供了多樣化的安裝選項。software depot包含vib而不是基本的esxi vib，它有時候會被叫作software bundles以避免誤認為隻是對核心鏡像的簡單增加。

software depot有兩種使用方式：離線和線上。離線 software depot隻是一個zip壓縮檔案，很像是一個包含esxi鏡像的software bundle。用image builder時需要使用software depot，此時選一個本地的zip檔案就可以很快開始了。也可以使用線上的software depot，它和基于檔案的離線版本中包含的内容相同，不過是安裝在一個web伺服器上的。大多數主流供應商會搭建他們自己的線上software depot，這樣就可以通過internet通路了。使用線上depot還有一個優勢，就是無論什麼時候想建立一個新的鏡像，都可以直接從供應商的工具上自動擷取最新的版本。但是這樣你就會受制于供應商來掌握其他元件的最新動态。你可以使用vum中的線上depot，注冊到供應商的網站，然後允許vum發現新的軟體版本時給你發送通知。

vmware還提供它自己的sofware depot，包括離線的zip檔案和基于web的軟體庫。如果沒有要建立的鏡像中伺服器硬體所需的定制depot，那麼你可以使用vmware的基礎鏡像。vmware提供了兩類鏡像：标準鏡像（完整版）和去掉vmware工具的鏡像（簡化版）。标準鏡像的大小幾乎是後者的兩倍。知道要如何使用鏡像就知道要選擇哪個了。可以看出，完整版适合iso方式的安裝，簡化版适合自動部署。如果你選用簡化版，則還需要為vmware tools搭建一個可以全局共享的服務，并且将所有host都指向這個服務。

software depot一直是用image builder建立鏡像時所需的必要輸入。image builder建立的鏡像可以用于正常安裝或更新的iso檔案，也可以轉換成可供vum、cli安裝或自動部署伺服器使用的軟體格式。

image builder 使用流程

image builder是一個powershell指令集合，需要在powercli中執行指令來建立自定義鏡像。這些指令會用到vib、image profile和software depot。生成的esxi鏡像可以是用于互動式腳本安裝的iso檔案，也可以是自動部署準備包。

用image builder建立自定義鏡像的基本流程如下（其中使用的指令為主要指令，真正執行時還需要增加相應的開關和參數）：

将software depots導入/連接配接到image builder（add-esxsoftwaredepot）。

建立image profile，制定所需的基礎vib。或者克隆現有的profile（new-esximage-profile）。

根據需要添加/删除vib（add-esxsoftwarepackage或remove-esxsoftwarepackage）。

将image profile導出到打包的iso鏡像或depot檔案鏡像中（new-esximageprofile）。

建立自定義鏡像的備選方案

如果不是真正需要，那麼建立自定義鏡像是不值得的。如果大型企業有很多伺服器或者需要頻繁地重構伺服器，那麼就會從自定義鏡像中受益。但是對于大多數公司來說，标準的vmware iso鏡像和供應商定制iso鏡像就已經足夠了。

esxi引導後會被加載到記憶體中，并在記憶體中運作。在記憶體中，它會使用tardisk（靜态檔案的歸檔檔案）和ramdisk（記憶體虛拟硬碟檔案，在使用過程中會不斷增長或減少）。除了tardisk和ramdisk外，在記憶體中還會找到一些硬碟分區。esxi的部署方式和部署後硬體的發現方式決定了會有哪些額外的分區以及這些分區的存儲位置。如果存在額外的分區，那麼它們會被挂載到檔案系統中。安裝時無法手動設定分區。但是，如果存在分區的話，那麼記憶體中的備份檔案會比較多。本章後續内容會有關于esxi部署選項的詳細介紹。在此，我們主要介紹最流行的類型可安裝esxi鏡像是如何被拷貝到本地硬碟的，因為這個類型涉及所有可能的分區。典型的分區布局如圖2-1所示。

新的esxi 5 build版本使用一個gpt（guid partition table）分區表，而上一版本使用的是老的mbr（master boot record）分區方式。要檢視分區清單，請執行paredutil指令，而不是之前的fdisk。

system　磁盤開始部分是一個隻有4mb的引導分區，這個系統盤負責引導兩個bootbank中的一個。

bootbank　bootbank分區是主要的系統鏡像。這個分區挂載在檔案系統的/bootbank目錄下。這個分區中的鏡像，特别是s.v00檔案，在引導時被解壓到記憶體中，稱為檔案系統的根目錄。

alt bootbankalt　bootbank分區是為備份鏡像預留的分區。更新時如果發生故障就可以使用這個備用的bootbank。其中存儲了“最後一次正确配置”來作為故障保險。引導時，按shift+r可以回到這個選項。這個分區被挂載在檔案系統的/altbootbank目錄下。

vmkdiagnostic　當host因紫屏（purple screen of death，dsod）故障崩潰時，核心記憶體轉儲資訊就存儲在這個分區中。排查故障時，可以檢索和分析這些資訊。一般情況下，這個分區是空的，也不會被挂載到檔案系統中。

store　store分區儲存了vmware工具的iso檔案和要挂載到虛拟機上的驅動軟碟鏡像。它還用于存儲所有輔助檔案。store分區被挂載在/store目錄下。./locker通過符号連結連接配接到這個目錄。

scratch　scratch分區是一個4gb的vfat（virtual file-allocation table）分區，如果首次引導時本地磁盤大于5.2g，那麼正常安裝時預設會建立這個分區。scratch分區保留狀态歸檔并捕捉運作時狀态檔案，如日志和診斷包（vm-support，排查故障時可以建立）。userworld的交換也在這裡進行。如果沒有scratch分區，也沒有可替代的本地分區，那麼scratch目錄就會被重新定向到ramdisk的/temp/scratch目錄。這意味着scratch分區的内容重新開機後就消失了，而且最多有4gb的記憶體可以用來存儲這些檔案。

如果本地引導硬碟或另一個本地硬碟上還有剩餘空間，esxi就會建立scratch分區。如果沒有剩餘空間，esxi會嘗試在本地vmfs（virtual machine file system）資料存儲（如果有的話）中建立一個目錄。如果失敗的話，就使用ramdisk。如果安裝程式無法建立scratch分區，那麼你可以将它重新定向到永久的vmfs或nfs卷中（雖然vmware并不推薦使用nfs卷）。即使有剩餘空間，esxi也不會将scratch分區建立在遠端硬碟（即“boot from san”邏輯單元數和被标記為遠端的sas硬碟），也不會建立在usb存儲器或sd卡上，這是因為來自userword交換的大量i/o會損壞這些裝置。

vmfs資料存儲　如果首次引導時有足夠的空間，esxi就會建立vmfs-5 資料存儲。這個資料存儲大小就是引導磁盤的剩餘空間。

esxi使用tardisk和ramdisk來建立檔案系統。系統一啟動，tardiak就會以目錄的形式挂載在基礎vmkernel的tardisk（被解壓縮到記憶體中）上。不同于正常的檔案系統，esxi不會解壓tardisk然後使用解壓後的檔案副本，而是保持tardisk的原貌，就像硬碟一樣挂載它們。上節介紹的實體分區也會被挂載到檔案系統中。執行ls –lah指令就可以看到每個目錄的符号連結，這些目錄都會被重新定向到指定的分區（這是一個檢查本地分區、vmfs或ramdisk中是否有/scratch目錄的簡單方法）。系統引導時tardisk會被依次放到檔案系統中，一旦這個過程結束，檔案系統就安裝好了（可以通過esxi shell檢視或操作這個檔案系統）。tardisk是隻讀的，無法修改。鏡像中的tardisk可以覆寫但不能修改正在運作的檔案系統中的tardisk。

ramdisk存儲esxi運作時建立和修改的檔案。例如，需要維護的配置和日志檔案。如果需要修改tardisk中的某個檔案，esxi就會用分支技術在ramdisk上建立一個它的副本。這個技術廣泛應用于/etc 檔案夾。用檔案粘滞位來指定這個檔案可以通過分支技術來建立分支。但是這些修改是無法寫回到tardiak檔案中的，因為tardiak檔案是隻讀的。是以為了保留這些資訊，它們會被寫到狀态檔案state.tgz檔案中（實際上大多數檔案會存儲在state.tgz裡面的local.gz中）。