- 期待已久的vSphere 7.0終於在2020年3月中正式發佈了，從去年年底國外就已經開始有Beta的版本在進行測試了，等了快半年終於釋出正式的版本，那麼就讓我們來看看vSphere 7.0到底多了哪些新的功能及特點吧。
- 我們先來看新版本與舊版本之間的兼容性，若要升級vSphere 7以上的平台，ESXI及vCenter Server至少要6.5 U2以上的版本才可以，若是6.0 U3以下的版本就只能先升級至6.5或是6.7再接續Upgrade至7.0即可。但是我們來看第二張的貼圖，清單上是表示ESXI 6.5.0及6.5 U1竟然是不能直接升級至7.0，接著再看第三張圖，vCenter Server 6.5.0及6.5 U1是可直接升級至vCenter Server 7.0，所以假設我們現有的平台是vCenter Server 6.5 U1 + ESXI 6.5 U1的環境要升級7.0前，依照VMware升級Solution清單走的話，就必須先將vCenter先升級vCenter Server Appliance 7.0後，再將ESXI升級至6.5 U2以上的版本再接續升級至ESXI 7.0。
VMware升級路徑參考網址：
- 在VMTools的部分，只要是ESXI 6.0以上所安裝的VM Tools版本都可以直接Upgrade VMTools 11.0.5
- 在vSphere授權的部分也有做調整，原授權是採用CPU數量來定價的，但是現在是改成若單一CPU物理的核心數量超過32以上就必須再加一個CPU的License，我想這對大型企業來說多少一定會有所影響的。這時可能有人會想問若CPU因HT模擬續而超過32 Core是否也要加錢，因HT並不是物理核心所以是不用再加買一個CPU的授權。
vSphere 7.0授權參考資訊網址：
- vCenter Server General updates部分，vSphere 7與6.7相比，能使用更多的資源(ESXI、虛擬機器)，另外值得注意的是在vCenter Server linked Mode已經可以忍受Latency為150ms
更多功能比較參考網址：
- vSphere 7有新增針對部分CPU兼容性停止支援 (與vSphere 6.7相比)
※ 而VMware也有事先表示在vSphere 7.0未來之後的版本可
能也會針對以下CPU停止支援
※ EVC模式List參考網址 :
- vSphere 7.0已經不再支援舊版VMKernel所加載的驅動程式，這意味著部分網路卡或是其它HBA，若是採用VMKernel驅動程式所加載的裝置，當升級vSphere 7.0時，可能會遇到驅動程式的問題，而導致該裝置無法正常的運作，所以在升級vSphere 7.0版本之前必須特別留意目前的硬體(裝置)是否採用VMKernel所加載的驅動唷
※ 那麼我們要如何知道vSphere環境有哪些裝置是否使用
VMKernel所加載的驅動呢??
透過ssh連入ESXI主機並輸入esxcli system module list
| grep vmklinux
※ 當然也有其它高手有編寫腳本，可幫助我們協助辨識在
vCenter環境底下的Cluster內的ESXI主機有哪些硬體是
採用VMKernel所加載驅動的裝置
更多相關資訊網址可參考 :
(移除VMKernel加載的驅動)
(移除VMKernel加載的驅動)
- vSphere 7.0 vMotion的新功能
※ 在以往vSphere版本上vMotion是將虛擬機上所有的vCPU
來執行跟踪程序的作業(第一張圖)，而現在vSphere 7.0版
本vMotion已經可以採用虛擬機器上的僅一個vCPU來完
成所有的跟踪程序(第二張圖)，而其它vCPU依舊可以穩
定持續負載虛擬機器上的運作
※ 在Page Table Granularity的部分
從vSphere 7開始，虛擬機監視器進程將在1GB頁面上以
更大的粒度設置只讀標誌。如果發生頁面覆蓋，則將
1GB PTE分為2MB和4KB頁面。VMware工程師已經發
現，在vMotion流程中，VM通常不會佔用所有的內存。
vMotion期間的內存工作集大小通常僅為10％至30％。如
果在vMotion時間內使用了更多的內存，則成本效率將會
降低。
※ Switch-over Phase Enhancements部分
當然我們都一直希望vMotion準備就緒後，在源ESXI主機
上的VM切換至ESXI目標主機的過程中，切換的時間可
以更短，尤其是對大型的VM來說，會面臨很大的挑戰。
內存位圖用於跟踪VM的所有的內存。它知道哪些頁面將
被覆蓋，但仍需要傳輸到目標ESXi主機上。當vMotion傳
輸到最後的內存頁面時，目標主機上的VM將開始啟動。
但是它可能仍需要剩下最後幾頁進行傳輸。為了在目標
上標識這些頁面，我們使用從源傳輸來的位圖。如果客
戶過量使用內存，則在可選的交換位圖中將跟踪換出的
頁面。而在vSphere 7.0版本對於6TB以上內存的虛擬機
器，位圖已達192MB，所以我們希望可以花更短(快)的
時間來完成發送，vSphere 7.0可利用壓縮技術能夠在幾
毫秒內完成發送大型的位圖，藉此達到更高的效率。
想知道更多vSphere 7.0 vMotion資訊可以參考網址 :
- vSphere 7.0 DRS的新功能
※ 以往舊版DRS每5分鐘會運行一次，針對各台ESXI上的負
載使用率來直接達到最佳的平衡。而在vSphere 7.0版本
中，新版DRS則是每1分鐘運行一次，並計算每台ESXI內
VM的DRS分數，與舊版相比，不需再針對ESXI的使用
率來直接平衡負載，而是採用更精細的方式來計算工作
負載的放置及平衡，藉此提高工作負載的性能。
※ Assignable Hardware部分
vSphere 7版本支持具有新的Dynamic DirectPath I / O或
NVIDIA vGPU配置文件的PCIe設備並與vSphere HA、
DRS集成。因此可為直通設備啟用可分配硬件智能。
PCIe設備的硬件地址不再直接映射到虛擬機配置文件
(.vmx)文件，而是將屬性或功能公開給虛擬機上。
(注意 : VM相容性版本必須為17以上)
我個人認為這算是一項很棒的功能，對有VDI環境且有
大型繪圖運算的虛擬機器來說，可直通GPU至虛擬機器
(VDI)，藉此為使用者提供足夠的GPU效能外，且也能夠
有vSphere HA的保護，若ESXI主機發生故障，也可以透
過Dynamic DirectPath I / O功能來找尋其它ESXI上的相
對應符合可用的硬件來達到高可用性
想知道更多vSphere 7.0 DRS新功能可以參考以下網址 :
- 介紹了那麼多vSphere 7.0新功能後，我這邊就先來採用vSphere 6.5 U1的平台來至升級vSphere 7.0看看
1. 首先先將vCenter Server Appliance 6.5 U1升級vCenter Server Appliance 7.0 (在升級vCenter Server 7.0之前，若現有環境是採用External Platform Services Controller所部署的vCenter Server，升級vCenter Server7.0將會自動被轉為Embedded Platform Services Controller)
2. 輸入現有vCenter Server Appliance資訊
3. 這邊可以注意到vCenter Server 7.0版本在記憶體的要求比過往舊版多了2G
4. 開始部署
5. 接著進行第二階段 (這邊可以看到警示，可直接關閉即可)
6. 通常正式平台的話都是會連所有的Config、Log及資訊一同Migrate
7. 若確認已事先備份現有的vCenter Server，那麼就可以開始進行升級的作業
8. 過程中可以看到vSphere 7.0默認禁用TLS1.0及TLS1.1的訊息
9. Upgrade完成
10. 現在vCenter Server 7.0僅支援HTML5管理介面，並淘汰過往的Flash管理介面
11. 在vCenter Server 7.0版本可發現新型的Update套件，以前的版本vCenter Update Manager(VUM)已替換為Lifecycle Manager
關於Lifecycle Manager參考網址：
12. 我們到Lifecycle Manager設定頁面來匯入ESXI7.0 ISO檔，接著新增基準
13. 完成
14. 那麼我們來試一下在ESXI 6.5 U1是否可以透過Lifecycle Manager來Upgrade ESXI 7.0??
15. 連結基準
16. 選擇ESXI 7.0
17. 修復
18. 這邊可以看到竟然跳出錯誤訊息且無法完成升級
19. 先看一下VMware Solution有提到使用基準的升級方式下可用於在ESXI 6.5及ESXI 6.7的版本上，但是奇怪的事，我現在就是ESXI 6.5 U1了
20. 後來我再嘗試先Upgrade ESXI 6.5 U2的版本後再試試
21. ESXI 6.5 U2是可以透過Lifecycle Manager來完成升級ESXI 7.0的作業
22. 嘗試從ESXI 6.5 U1用Zip升級ESXI 7.0看看，升級過程跳出異常的訊息
23. 加入略過檢查的參數
24. 採用ZIP方式可正常完成升級
25. 我這邊還有再嘗試其它的升級方式(傳統全新安裝升級)
26. 等待升級中
27. 採用全新安裝升級方式也是可以順利升級的 (不過我個人還是比較建議按照VMware Solution所提供的最佳升級路徑來做會比較好，雖然以上兩個方法都可以順利升級ESXI 7.0，但是這樣不能確定後續是否會發生其它的異常狀況)
28. 那麼我們再回到Lifecycle Manager的部分，嘗試匯入ESXI 6.7 U1 ISO檔會跳出無法與Lifecycle Manager搭配使用的訊息，所以若要匯入ESXI ISO檔就必需是ESXI 7.0以上的ISO檔才可以唷
29. 這邊是映像管理的配置，此功能可以讓Cluster內所有主機能更便利的完成升級(更新)，且易集中管理
30. 接著Upgrade VMTools
31. 執行升級 (過程中虛擬機器會重開機)
32. 請耐心等待升級VMTools中
33. VMTools升級完成
34. 接著來升級虛擬機器相容性
35. 升級虛擬機器相容性 (升級前虛擬機器需為關機狀態)
36. 虛擬機器相容性升級完成
37. 我們來看ESXI 6.7 U3及ESXI 7.0在磁碟分割表的差異性，可以發現唯一不同的是在ESXI7.0上多了一個VMFSL的分割區
38. 根據網路上的VMFSL說明：VMFS-L是VSAN-1.0的基礎文件系統。葉級VSAN對象直接駐留在由服務器端直接連接存儲(DAS)組成的VMFS-L卷上。文件系統格式針對DAS進行了優化。優化包括針對DAS用例的主動緩存，剝離的鎖定管理器和更快的格式。
由於目前VMware並沒有特別針對vSphere 7.0上的VMFSL分割區上做太多詳細的說明，不過我個人是認為也許跟某些特定的服務有著密不可分的關係，我想後續應該會有人來針對vSphere 7.0的VMFS-L做更進一步的說明與研究
可參考更多VMFSL資料網址：
已有其它網友有針對ESXI 7本機安裝磁碟空間規劃說明
39. 另外這邊要特別說明一下，若是採用全新安裝ESXI 7.0的話，在安裝ESXI的磁區容量小於130G以下的話，是看不到DataStore的，且也無法建立DataStore唷
40. 建立DataStore時會發現並沒有可用的裝置 (不過很奇怪的是我用ESXI虛擬機器直接Upgrade上去的話就沒有這個問題，但是用ESXI實體機直接Upgrade也是一樣是沒有DataStore的)
41. 若安裝ESXI的磁區大於130G以上，可以發現光是VMFSL就佔掉了約120G的空間，剩餘的才能做為可用的空間
42. 雖然說ESXI若安裝在130G以下的磁區，是可以正常運作的，但是目前我個人還是認為並不能完全保證在任何的環境下(含vSAN)服務是否會有所影響，看看未來有沒有機會可以去聽VMware vSphere 7相關免費體驗的課程，這部分就可以詢問專業的人員看看囉
43. 來看ESXI時間的部分，ESXI 7.0多了PTP服務
44. ESXI 7.0在時間時區的部分預設依舊是+0000，並不是+8000 (跟以前的版本一樣需要透過其它方式來修改時區)
45. 在升級ESXI7過程中，我發現在Storage Adapter是抓不到QLE2400系列(4G) FC Card的(還沒升級前ESXI6.7是可以辨識到QLE2400的)，另外我有另外再嘗試採用全新安裝的ESXI7也是一樣無法辨識
46. 至VMware I/O Device相容性清單可以看到QLogic 2400系列僅支援到ESXI 6.7 U3版本
47. 我這邊剛好有一台是裝QLogic 2500系列(8G)的ESXI主機，測試升級至ESXI7是可以辨識到的
48. 我們可透過esxcli來查看目前ESXI7.0所自帶的驅動版本 (這也就代表QLE2400是無法在qlnativefc version 4.0.1.0-3vmw版本下運作的)
esxcli software vib list | grep "Device Name"
參考資訊網址：
49. 那麼若我希望可以在ESXI7.0辨識到QLE2400的話，就必須先移除較新版的Drivers，並下載及安裝較舊版的Drivers才可以唷
50. 進入維護模式後，輸入指令移除新版vib驅動
51. 上傳vib至DataStore並安裝驅動，輸入esxcli software vib install -v /vmfs/volumes/datastore/xxxx.vib --force
52. 重開機後，ESXI7已經可以成功辨識到QLE2400 (4G) FC Card
53. 接著我們來看vSphere 7.0 Dynamic DirectPath I / O功能，在前言介紹的DRS功能有提到Assignable Hardware的部分，其實在生產環境上要將PCI裝置Passthrough給虛擬機器的做法還蠻少見的，通常只有較特殊的場景下才會這樣做，例如是網路卡(SR-IOV)功能或是有VDI環境(GPU)..等，那麼這邊我就來實際測試一下吧，首先虛擬機器相容性必須為17版本
54. 我先測試一下若是用早期傳統的DirectPath I/O是否可以透過vSphere HA來保護該虛擬機器
55. 果然是容錯移轉失敗
56. ESXI都需要先對該裝置啟用Passthrough，並配置各台ESXI內的PCI Device硬體標籤 (這邊我是採用Fibre Channel Card)
57. 各台的ESXI上的標籤名稱需一致
58. 新增PCI裝置，並採用動態DirectPath I/O功能
59. 假設我們這台虛擬機器透過Fibre Channel來掛載DataStore
60. 該虛擬機器位於10.0.0.239，所以我們來把這台ESXI關機(模擬故障)
61. 可看到已透過vSphere HA成功移轉至10.0.0.240 (ESXI)主機上並持續運作
62. 而該虛擬機器掛載的DataStore依舊可正常存取 (而透過Passthrough裝置的虛擬機器依舊是不能在線vMotion、Snapshot、暫停..等功能唷)
63. 在vSphere 7.0版本中，Storage的部分也有很重大的進步唷，其實在早期的vSphere 6.5就有RDMA的功能，而現在vSphere 7.0已經可以透過RDMA來新增對NVMEoF的支持，此功能基於聚合以太網v2(RoCE v2)的RDMA，有助於在I/O效能上得到明顯的提升，由於我手邊沒有ConnectX的卡，所以這部分是沒有機會可以測試了
VMware Hardware I/O Device兼容性與驅動也要特別注意：
想多了解vSphere 7.0對NVMEoF的資訊可以參考網址：
(裡面有一些條件可能需要去注意)
(其它網站的測試)
64. 而在前面介紹vSphere 7.0在Storage的部分，還有一項很棒的突破，由於在以往vSphere環境下，若虛擬機器要採用(Windows Server Failover Cluster) WSFC功能就必須採用RDM(Physical)或是VVols(vSphere 6.7)才可以完成配置WSFC功能，而現在vSphere 7.0內的DataStore(VMFS 6)增加了對SCSI-3永久保留的支持，所以VMDK已經可以直接讓虛擬機器來掛載並完成配置WSFC功能，以利於達到高可用性，但是必需是透過Fibre Channel協定來掛載的DataStore才可以，且此功能還有一些限制的地方需要特別去注意唷
關於vSphere 7.0 Share VMDK資訊參考網址：
https://storagehub.vmware.com/t/vsphere-7-core-storage/shared-vmdk/ (VMware Solution)
65. 這邊我有大概選出比較需要特別注意的條件，在Solution有提到的是DataStore是無法擴大的，這也就是說若未來空間不足的時候，恐怕會面臨空間不足的問題，不過我在測試的時候是可以在線擴充的(後面會有測試結果)
66. 而在vSphere功能跟以往版本在建置WSFC時，一樣是不支援Storage vMotion、Clone及Snapshot..等其它功能，需特別留意的是無法對Share VMDK進行熱擴展的
67. 至DataStore設定啟用叢集化VMDK
68. 提示有說到要啟用叢集化VMDK時，DataStore內的所有虛擬機器都需為關機的狀態
69. 若是採用ISCSI所掛載的DataStore是不會看到已叢集化VMDK的功能
70. 至WSFC01虛擬機器新增SCSI Controller並將匯流排選擇為實體
71. 新增硬碟並選擇放置於FC_DataStore，而磁碟採用Eager Zeroed Thick，並指定新的SCSI Controller
72. 配置WSFC02虛擬機器，新增現有硬碟選擇剛剛建立於FC_DataStore的Share VMDK，且一樣是新增與指定新的SCSI Controller並配置匯流排為實體Mode
73. 這邊可以看到此VMDK已可指派給容錯移轉叢集來使用了
74. 各台虛擬機器新增容錯移轉角色服務
75. 選擇位於FC_DataStore上的VMDK
76. 容錯移轉角色服務建立OK
77. 測試將WSFC01主機關機
78. 這時可以看到檔案服務已移轉至WSFC02主機上
79. 接著我們來看在虛擬機器開機的情況下，試著將VMDK看看是否可以直接熱Expand
80. 跳出無法支援此操作的問題 (需將各台WSFC虛擬機器關機後才可以將Share VMDK進行Expand Space)
81. 擴展完成後，這時會發生虛擬機器無法開機的狀況
82. 查看磁碟類型竟然變成完整佈建消極式歸零
83. 利用Storage vMotion將此VMDK移至其它VMFS並轉成完整佈建積極式歸零
84. 接著再Storage vMotion回到原本的FC_DataStore即可 (當然若環境空間夠充足，可以Migrate到其它FC所掛載的DataStore，如此一來就不用再做一次vMotion回到原本的DataStore上)
85. 確認是否為完整佈建積極式歸零
86. 另外WSFC02虛擬機器需重新新增現有硬碟並選擇該VMDK
87. 如此一來WSFC01與WSFC02皆可正常開機
88. 至磁碟管理就可以看到已有多的空間可以擴大
89. 那麼我們再來測試FC_DataStore是否可以在線擴大 (目前空間為50G)
90. 在線擴大完成 (到這邊可能有人會想問說在VMware Solution針對Share VMDK裡面的其它注意事項有提到該DataStore無法擴展的問題，雖然說我只是在測試的階段下是可以在線擴充的，若有人想在正式平台導入的話建議先做POC模擬一下，畢竟每個人的環境可能都會因不同的配置與版本而結果也許會有所不同)
91. 接著來測試在線vMotion (從10.0.0.239上vMotion至10.0.0.240主機)
92. 在線vMotion成功
93. vSphere HA也沒有問題 (這邊需注意vSphere HA需配置規則將各台WSFC虛擬機器不要放置在同一台ESXI主機上，避免造成vSphere HA失敗)
94. 對VMware來說，這次的vSphere 7.0可以說是意義重大的一個新版本，與Kubernetes緊密結合成為全新的vSphere，由於我目前對K8s的功能還很陌生，所以我這邊就無法多做說明與測試，且環境還必需要先有NSX-T 3.0以上才可以部署
想了解更多關於vSphere 7.0與Kubernetes的資訊可參考網址：
(這篇對K8s的說明還蠻詳細的)
◎ 結論 : vSphere 7.0的體驗就到這邊囉，當然還有一些部分的新功能我是沒有特別提到，有興趣的人其實可以自行爬文，目前網路上針對vSphere 7.0的文獻已經有很多了。經過本篇這一連串的測試與體驗，而其中在DataStore Cluster VMDK (WSFC)功能的部分，主要是Share VMDK無法熱擴展，這對系統管理員來說會面臨被迫停機的考驗，我個人是認為若於WSFC環境下，還是建議採用Virtual Volumes (vSphere 6.7)的方式會比較妥當，當然我想未來vSphere 7.X版本可能可以改善這個問題(熱擴展)，就讓我們拭目以待囉。
沒有留言:
張貼留言