《VMware vSphere設計（原書第2版）》——2.5 從ESX遷移到ESXi

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

将現有的vsphere環境從esx遷移到esxi依然是個很常見的項目。正常的約定毫無疑問是需要測試和計劃的，但重要的是vsphere host設計的基礎：保證主要目标能夠得到滿足，并确定是否需要其他改進措施。雖然esx和esxi之間的共同點多于不同點，但是了解如何從esx切換到esxi對你是很有益處的。

在将esx host重新部署成esxi前，需要測試目前部署并分析是否每個元素都是适用于esxi。顯然， 最好選擇一個試點測試現有配置的esxi的社交性。然而，在小試點上不可能測試到所有的場景，因為通常大型企業有很多不同類型的硬體、不同版本的硬體、連接配接不同的網絡和儲存設備、備份工具、監控工具等。

一個比較謹慎的做法就是制定預防性計劃以防esxi不能适應某些特殊情況。該計劃可以為更換裝置制定财務計劃，或者指定在某種情況下先保留esx，當裝置到位時再遷移到esxi。遷移過程中混合esx host和 esxi host是可行的（甚至在同一個叢集中）。如果考慮永久性地保留一些esx host，你還需要了解支援混合host的一些副作用，例如：維護兩個更新檔周期、排查兩個類型的host，以及用不同方式收集硬體監控資料。

仔細檢查伺服器的硬體以確定相容并全面支援esxi。可安裝esxi的hcl清單比經典esx大，但依然缺少一些老的伺服器。你得檢查并確定伺服器及其插件元件都在hcl清單中。

不管是什麼原因，如果無法将某些host遷移到esxi，請考慮盡量将它們看作esxi host來管理。大多數vmware和第三方工具都能連接配接到任一類型的host。你可以使用取代service console功能的那些工具，例如vma和powershell指令，去管理傳統esx host。這樣就可以使用esxi工具來管理混合環境，而不需要依賴于service console。

esx伺服器可以更新也可以重構。esx 4.x伺服器更新可以由互動式esxi、腳本安裝機制或vum來完成。如果esx 4.x 伺服器是從esx 3.x更新過來的，那麼從esx 3.x帶來的分區配置可能導緻無法更新到esxi。本地vmfs卷中至少要有50m的可用空間用于存儲上個版本的配置。如果用vum來更新，那麼/boot分區的可用空間要至少350m。如果沒有這麼多的可用空間，你還可以使用互動式更新，因為它不需要空間來存儲更新檔案。本地硬碟中任何需要保留的vmfs卷都必須在1gb存儲之後，否則更新時無法建立其必需的esxi分區。

如果有任何esx 3.x host，你得先把它更新到4.x，再更新到5.x。你肯定會問兩次更新會比一次全新安全更好嗎？而且esx 3.x host還要努力比對esxi 5的hcl。是以這種情況下要遷移到esx 5.x，還是全新安裝更适合些。

不重新建構esx伺服器，而是更新伺服器有很多不良影響，其中很多都與上一章節讨論的esxi 4.x更新的影響類似。總的來說，就是硬碟還會保持mbr模式，存儲不能超過2tb；沒有scratch分區，vmfs-3卷也會保留（雖然後續可以将其更新到vmfs-5，但還是一個“更新得到的”vmfs-5卷）。然而，與從esxi 4.x更新到esxi 5.x截然相反的是，從esx 4.x更新到 esxi在平台方面是個更大的跳躍，認為該過程不會順利是很合理的。

另外，重構政策實際上可能是更簡單的方法，而且會産生一個更一緻、更可靠的結果。重構過程中，所有的配置都會丢失，重新建構的伺服器也必須重新配置。有專門的伺服器管理者的大型公司可能非常熟悉重構作業系統而不熟悉更新。但是小公司可能聘請過咨詢師初步部署esx，但并沒有為在所有host中進行完整安裝做好準備。

如果想徹底重構host，那麼則需要将本地vmfs卷中的所有資料都清除掉，包括虛拟機、模闆、iso檔案等。保留這些資料也可以将esxi全新安裝到剩餘的空間中，但是在出錯的時候會有安裝失敗的風險，這樣也就達不到重新建構的目的了（實作完美的安裝）。 檢查檔案系統檢視/home、/tmp以及任何本地使用者可能存放檔案的目錄。最後還要備份檔案，特别是/etc目錄下的配置檔案，以及/opt目錄下第三方安裝的代理軟體。

vmware fling軟體esx system analyzer是一個可以掃描加入到vcenter的所有esx host，并生成遷移前報告的工具。報告中包含實體伺服器的hcl相容性詳情、本地存儲中注冊的虛拟伺服器、service console變更，以及資料存儲和虛拟機的版本資訊。這些報告對制定遷移計劃是很重要的，該工具使原本繁雜的工作變得輕松了許多。

想要避免虛拟機故障停機，必須有共享存儲，或者至少在每個叢集中最強大的伺服器中有與之相當的存儲空間。這樣，就可以在從叢集中删除一個時圍繞主機遷移虛拟機，以便重建它。

幸運的是，在傳統esx host上用過的很多部署方法在esxi中也同樣适用。esxi可以使用已經建好的pxe伺服器：隻需要把新的鏡像拷貝到伺服器上即可。你還需要為esxi修改esx的kickstart腳本，但是配置的文法是一樣的，而且通常隻需要删除不需要的配置，很少增加新的内容。

盡早使用新的跨host管理工具可以讓從esx到esxi的轉換過程更順利。大多數傳統esx host的工具都适用于esxi host。vsphere用戶端、vcenter伺服器、vcenter web用戶端、vsphere指令行界面，以及powercli都是診斷host用的，可以減少轉換的破壞性。我們沒有任何理由不從最開始就使用這些工具。即使不打算在那個階段遷移，但最好還是在esxi host開始在環境中出現時就做好準備。

替換esx在管理方面最大的損失就是失去了service console。如果你經常使用它，就必須改用與之相當的工具。有兩個工具可供選擇：vcli和esxi shell。vcli提供了和service console相同linux風格的指令。最簡單的方法就是下載下傳vsphere management assistant（vma）虛拟裝置。其中包含一個linux shell和所有你想要的相關的環境工具。通常，在service console中能做的事情，在vma中也可以做。可以輕松地将大多數腳本轉換為vma文法的指令。

第二個選擇是esxi shell。雖然它是一個非常精簡的環境，但仍然可以提供大多數可以在service console中找到的vsphere指令。某些基于linux的指令可能無法使用，但是它提供了比vma更讓人熟悉的風格，因為它是host相關的，是以文法更接近于service console。

除了重寫腳本外，你還需要替換esx在service console中包含的其他服務。由于esxi host沒有scratch 分區的永久存儲，是以将日志重新定向到遠端資料存儲或将host指向到遠端syslog 伺服器是很重要的。esxi host沒有像esx host那樣有自己的web直接通路特性。這個特性使用頻率不高，但是如果某些環境依賴于這個特性的話，你還得習慣通過windows用戶端來連接配接host。最後，如果通過snmp或伺服器供應商的硬體代理用service console來監控host，那麼esxi針對hcl中的硬體也有内置的cim代理，而且很多供應商都會供應它們各自特殊硬體的增強子產品。有了cim子產品，就可以在vcenter中建立警告資訊了，而且一些第三方的硬體監控軟體還可以使用這些警告資訊。esxi也支援snmp，你可以用來替換service console代理中的缺失的功能。

如果host有enterprise plus授權，host profile就可以為從esx到esxi的遷移提供更友善的方法。你可以将叢集中的某個現有的esx host作為參考host，将一個伺服器重構為esxi，然後使用它的profile得到一個通用的配置集。應用了叢集profile的新esxihost就可以作為新的profile的基礎，你可以将這個profile應用到其他host。如果要遷移的伺服器不需要改變設計，那麼host profile就能節省很多時間。

當然還需要替換所有使用service console的第三方應用。大部分擴充都有esxi版本，是以還可以繼續使用，雖然需要将它們更新到最新版本。大多數工具使用相同的api集合。與供應商确認這些工具是否與esxi host相容；如果不相容，請考慮用其他供應商的工具（與esxi host相容的）替換。