冲突与碰撞:OpenStack中的虚拟机和裸机

云计算 虚拟化 OpenStack
如果您追求性能,那么就没有争议——裸机仍然胜过虚拟机;特别是对于I/O密集型应用程序。但是,除非您可以保证充分利用它,否则是有代价的。

[[319074]]

 

要虚拟化还是非虚拟化?

如果您追求性能,那么就没有争议——裸机仍然胜过虚拟机;特别是对于I/O密集型应用程序。但是,除非您可以保证充分利用它,否则是有代价的。在本文中,我们描述了如何使用Nova来以统一的方式提供对虚拟机管理程序和裸机计算节点的访问。

scheduling

当Nova首次引入通过Ironic支持裸机计算时,它不能轻松地与传统的基于hypervisor的工作负载共存。当时的解决方法通常涉及使用宿主aggregates和flavor特性。

我们在定制的裸机博客文章中详细介绍了 裸机调度(请参阅概述:Nova中的调度)。

自引入Placement服务以来,裸机的scheduling已发生了显着变化。对于每个Ironic节点,将标准vCPU,内存和磁盘资源替换为自定义资源类的单个单元。这有两个关键的副作用:

  • 裸机节点已完全分配或根本未分配
  • 虚拟机和裸机使用的资源类是不相交的,因此我们最终无法将VM Flavor调度到裸机节点

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

  1. openstack flavor show vm-tiny -f json -c name -c vcpus -c ram -c disk -c properties 
  2.  "name""vm-tiny"
  3.  "vcpus": 1, 
  4.  "ram": 1024, 
  5.  "disk": 1, 
  6.  "properties""" 

“gold”节点的裸机flavor可能如下所示:

  1. openstack flavor show bare-metal-gold -f json -c name -c vcpus -c ram -c disk -c properties 
  2.  "name""bare-metal-gold"
  3.  "vcpus": 64, 
  4.  "ram": 131072, 
  5.  "disk": 371, 
  6.  "properties": "resources:CUSTOM_GOLD='1'
  7.                 resources:DISK_GB='0'
  8.                 resources:MEMORY_MB='0'
  9.                 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的此类节点的清单:

  1. $ openstack resource provider inventory list <node UUID> 
  2. +---------------+-----------------+----------+----------+-----------+----------+--------+ 
  3. | resource_class | allocation_ratio | max_unit | reserved | step_size | min_unit | total | 
  4. +---------------+-----------------+----------+----------+-----------+----------+--------+ 
  5. | VCPU         |             1.0 |       64 |        0 |         1 |        1 |     64 | 
  6. | MEMORY_MB     |             1.0 |   131072 |        0 |         1 |        1 | 131072 | 
  7. | DISK_GB       |             1.0 |      371 |        0 |         1 |        1 |    371 | 
  8. | CUSTOM_GOLD   |             1.0 |        1 |        0 |         1 |        1 |      1 | 
  9. +---------------+-----------------+----------+----------+-----------+----------+--------+ 

如果将此节点分配给一个flavor请求(或未显式清空)标准资源类的实例,我们将有如下用法:

  1. $ openstack resource provider usage show <node UUID> 
  2. +----------------+--------+ 
  3. | resource_class | usage | 
  4. +----------------+--------+ 
  5. | VCPU           |     64 | 
  6. | MEMORY_MB     | 131072 | 
  7. | DISK_GB       |    371 | 
  8. | CUSTOM_GOLD   |      1 | 
  9. +----------------+--------+ 

如果删除此实例,则标准资源类清单将变为可用,并且可由VM的调度程序选择。这不可能很好地结束。我们必须做的是确保不将这些资源报告给Placement。默认情况下,这是在Stein版本的Nova中完成的,并且可以通过在nova.conf中设置以下内容来配置Rocky以执行相同的操作:

  1. [workarounds] 
  2. report_ironic_standard_resource_class_inventory = False 

但是,如果我们这样做,Nova将尝试从我们的实例已经消耗的Placement资源提供程序中移除库存,并将收到一个HTTP 409冲突。这将很快使我们的日志充满无用的告警。

Flavor迁移

值得庆幸的是,有一个解决方案。我们可以修改现有实例中的使用的flavor以删除标准资源类清单,这将导致从Placement中删除这些资源的分配。这将使Nova可以从资源提供者处删除库存。Matt Riedemann启动了一个Nova Patch,它将删除我们的标准资源类清单。该补丁需要推到生产线上,但效果很好,足以被 Rocky版本 生产使用。

迁移可以离线或在线完成。我们选择离线进行此操作,以避免部署此修补程序。对于每个要迁移的节点:

  1. nova-manage db ironic_flavor_migration --resource_class <node resource class> --host <host> --node <node UUID> 

或者,如果所有节点都具有相同的资源类:

  1. nova-manage db ironic_flavor_migration --resource_class <node resource class> --all 

您可以通过数据库检查实例包含的flavor是否已正确更新:

  1. sql> use nova 
  2. sql> select flavor from instance_extra; 

现在(仅适用于Rocky),可以禁用标准资源类清单报告。在nova计算服务运行了一段时间之后,展示位置将被更新:

  1. $ openstack resource provider inventory list <node UUID> 
  2. +---------------+------------------+----------+----------+-----------+----------+-------+ 
  3. | resource_class| allocation_ratio | max_unit | reserved | step_size | min_unit | total | 
  4. +---------------+------------------+----------+----------+-----------+----------+-------+ 
  5. | CUSTOM_GOLD   |              1.0 |        1 |        0 |         1 |        1 |     1 | 
  6. +---------------+------------------+----------+----------+-----------+----------+-------+ 
  7.  
  8. $ openstack resource provider usage show <node UUID> 
  9. +----------------+--------+ 
  10. | resource_class | usage | 
  11. +----------------+--------+ 
  12. | CUSTOM_GOLD   |      1 | 
  13. +----------------+--------+ 

我们希望这表明OpenStack现在处于虚拟机和裸机可以和平共处状态,即使对于那些讨厌的场景。感谢Nova团队努力使Ironic成为一流的项目。

 

责任编辑:武晓燕 来源: 新钛云服
相关推荐

2011-12-12 09:08:48

OpenStack虚拟机监控

2010-05-14 11:38:24

虚拟机备份

2015-07-08 14:33:23

虚拟机OpenStack

2023-11-27 00:46:39

裸机虚拟机

2018-07-10 15:10:50

OpenStack虚拟机metadata

2012-05-18 10:22:23

2018-08-17 07:49:01

2015-04-28 13:35:22

SDNOpenFlowOpenStack

2013-07-17 09:32:58

2010-07-26 09:02:38

2014-02-19 09:25:21

网络冲突改虚拟机MAC

2016-09-01 12:37:13

OpenStack虚拟机Metadata

2017-09-14 10:11:24

OpenStack虚拟机过程分析

2023-04-26 07:51:36

虚拟机操作系统进程

2010-09-25 15:13:40

JVMJava虚拟机

2010-05-20 11:17:41

虚拟机备份恢复

2010-09-30 09:32:01

虚拟机

2015-05-15 10:36:13

2010-03-15 14:24:59

StackHeapJVM

2009-10-13 15:00:36

物理机虚拟机网络安全
点赞
收藏

51CTO技术栈公众号