沖突與碰撞：OpenStack中的虛擬機和裸機

要虛擬化還是非虛擬化？

如果您追求性能，那么就沒有爭議——裸機仍然勝過虛擬機；特別是對于I/O密集型應用程序。但是，除非您可以保證充分利用它，否則是有代價的。在本文中，我們描述了如何使用Nova來以統一的方式提供對虛擬機管理程序和裸機計算節點的訪問。

scheduling

當Nova首次引入通過Ironic支持裸機計算時，它不能輕松地與傳統的基于hypervisor的工作負載共存。當時的解決方法通常涉及使用宿主aggregates和flavor特性。

我們在定制的裸機博客文章中詳細介紹了 裸機調度(請參閱概述：Nova中的調度)。

自引入Placement服務以來，裸機的scheduling已發生了顯著變化。對于每個Ironic節點，將標準vCPU，內存和磁盤資源替換為自定義資源類的單個單元。這有兩個關鍵的副作用：

• 裸機節點已完全分配或根本未分配
• 虛擬機和裸機使用的資源類是不相交的，因此我們最終無法將VM Flavor調度到裸機節點

“tiny” VM的flavor可能如下所示：

openstack flavor show vm-tiny -f json -c name -c vcpus -c ram -c disk -c properties{ ?"name": "vm-tiny", ?"vcpus": 1, ?"ram": 1024, ?"disk": 1, ?"properties": ""}

“gold”節點的裸機flavor可能如下所示：

openstack flavor show bare-metal-gold -f json -c name -c vcpus -c ram -c disk -c properties{ ?"name": "bare-metal-gold", ?"vcpus": 64, ?"ram": 131072, ?"disk": 371, ?"properties": "resources:CUSTOM_GOLD='1', ? ? ? ? ? ? ? ? resources:DISK_GB='0', ? ? ? ? ? ? ? ? resources:MEMORY_MB='0', ? ? ? ? ? ? ? ? resources:VCPU='0'"}

請注意，vCPU/RAM/Disk資源僅供參考，并通過屬性歸零以進行調度。我們稍后將進一步討論這個問題。

那網絡呢？

在我們的混合環境中，我們可能希望vm和裸機實例能夠相互通信，或者希望它們彼此隔離。這兩種模型都是可能的，并且工作方式與典型的neutron網絡一樣——neutron網絡彼此隔離，直到通過neutron路由器連接。

裸機計算節點通常使用VLAN或扁平網絡。當然，通過網絡硬件和Neutron插件的正確組合，其他模型也是可以的。對于VLAN網絡，假設虛擬機管理程序與裸機計算節點連接到同一物理網絡，然后將VM與裸機計算實例連接到同一VLAN，這將在它們之間提供L2連接。或者，應該可以使用Neutron路由器將VLAN上的裸機實例與另一個網絡(例如VXLAN)上的VM相連，二這將在他們之間提供L3連接。

實際上這是什么樣的？我們需要同時支持VM和裸機網絡的Neutron plugins/drivers程序的組合。要將裸機服務器連接到租戶網絡，Neutron必須配置物理網絡設備。我們通常使用networking-generic-switch ML2機制驅動程序，盡管networking-ansible驅動程序正在成為一種供應商中立的替代方案。這些驅動程序支持裸機端口，即neutron端口與VNIC_TYPE的baremetal。特定于供應商的驅動程序也可用，并且可能同時支持VM和裸機。

有何問題？

更成熟的云可能遇到的一個問題是從基于標準資源類(vCPU、RAM、disk)的調度過渡到基于自定義資源類的調度。如果存在在Rocky發行版或更早版本中創建的舊裸機實例，則除了自定義資源類之外，它們在Placement中還可能具有標準資源類清單。例如，以下是報告給Placement的此類節點的清單：

$ openstack resource provider inventory list +---------------+-----------------+----------+----------+-----------+----------+--------+| resource_class | allocation_ratio | max_unit | reserved | step_size | min_unit | total |+---------------+-----------------+----------+----------+-----------+----------+--------+| VCPU ? ? ? ? | ? ? ? ? ? ? 1.0 | ? ? ? 64 | ? ? ? ?0 | ? ? ? ? 1 | ? ? ? ?1 | ? ? 64 || MEMORY_MB ? ? | ? ? ? ? ? ? 1.0 | ? 131072 | ? ? ? ?0 | ? ? ? ? 1 | ? ? ? ?1 | 131072 || DISK_GB ? ? ? | ? ? ? ? ? ? 1.0 | ? ? ?371 | ? ? ? ?0 | ? ? ? ? 1 | ? ? ? ?1 | ? ?371 || CUSTOM_GOLD ? | ? ? ? ? ? ? 1.0 | ? ? ? ?1 | ? ? ? ?0 | ? ? ? ? 1 | ? ? ? ?1 | ? ? ?1 |+---------------+-----------------+----------+----------+-----------+----------+--------+

如果將此節點分配給一個flavor請求(或未顯式清空)標準資源類的實例，我們將有如下用法：

$ openstack resource provider usage show +----------------+--------+| resource_class | usage |+----------------+--------+| VCPU ? ? ? ? ? | ? ? 64 || MEMORY_MB ? ? | 131072 || DISK_GB ? ? ? | ? ?371 || CUSTOM_GOLD ? | ? ? ?1 |+----------------+--------+

如果刪除此實例，則標準資源類清單將變為可用，并且可由VM的調度程序選擇。這不可能很好地結束。我們必須做的是確保不將這些資源報告給Placement。默認情況下，這是在Stein版本的Nova中完成的，并且可以通過在nova.conf中設置以下內容來配置Rocky以執行相同的操作：

[workarounds]report_ironic_standard_resource_class_inventory = False

但是，如果我們這樣做，Nova將嘗試從我們的實例已經消耗的Placement資源提供程序中移除庫存，并將收到一個HTTP 409沖突。這將很快使我們的日志充滿無用的告警。

Flavor遷移

值得慶幸的是，有一個解決方案。我們可以修改現有實例中的使用的flavor以刪除標準資源類清單，這將導致從Placement中刪除這些資源的分配。這將使Nova可以從資源提供者處刪除庫存。Matt Riedemann啟動了一個Nova Patch，它將刪除我們的標準資源類清單。該補丁需要推到生產線上，但效果很好，足以被 Rocky版本 生產使用。

遷移可以離線或在線完成。我們選擇離線進行此操作，以避免部署此修補程序。對于每個要遷移的節點：

nova-manage db ironic_flavor_migration --resource_class --host --node

或者，如果所有節點都具有相同的資源類：

nova-manage db ironic_flavor_migration --resource_class --all

您可以通過數據庫檢查實例包含的flavor是否已正確更新：

sql> use novasql> select flavor from instance_extra;

現在(僅適用于Rocky)，可以禁用標準資源類清單報告。在nova計算服務運行了一段時間之后，展示位置將被更新：

$ openstack resource provider inventory list +---------------+------------------+----------+----------+-----------+----------+-------+| resource_class| allocation_ratio | max_unit | reserved | step_size | min_unit | total |+---------------+------------------+----------+----------+-----------+----------+-------+| CUSTOM_GOLD | 1.0 | 1 | 0 | 1 | 1 | 1 |+---------------+------------------+----------+----------+-----------+----------+-------+$ openstack resource provider usage show +----------------+--------+| resource_class | usage |+----------------+--------+| CUSTOM_GOLD | 1 |+----------------+--------+

摘要

我們希望這表明OpenStack現在處于虛擬機和裸機可以和平共處狀態，即使對于那些討厭的場景。感謝Nova團隊努力使Ironic成為一流的項目。

原文： https://www.stackhpc.com/mixed-vm-bare-metal.html

總結

以上是生活随笔為你收集整理的中resource文件夹的作用_冲突与碰撞：OpenStack中的虚拟机和裸机的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。