免费域名注册网站有哪些,房地产开发公司简介,新网站建设怎么样,亚马逊跨境电商个人开店要多少钱冲突与碰撞#xff1a;OpenStack中的虚拟机和裸机要虚拟化还是非虚拟化#xff1f;如果您追求性能#xff0c;那么就没有争议——裸机仍然胜过虚拟机#xff1b;特别是对于I/O密集型应用程序。但是#xff0c;除非您可以保证充分利用它#xff0c;否则是有代价的。在本文…冲突与碰撞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_GOLD1, resources:DISK_GB0, resources:MEMORY_MB0, resources:VCPU0}请注意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
