异构实例类型

注意：此文档已被 ScheduleHeterogeneousInstances 取代

Launchpad 条目: NovaSpec:heterogeneous-instance-types
创建者: Brian Schott
当前维护者: Lorin Hochstein
贡献者: USC 信息科学研究所

总结

Nova 应该支持 CPU 架构、加速器架构和网络接口作为实例类型（或使用 RackSpace API 术语中的 flavor）的定义的一部分。目标发布版本是 Diablo，但是 USC-ISI 团队计划在 Cactus 版本发布时提供稳定的测试分支和部署。

USC-ISI 团队在此处提供了一个功能原型

https://code.launchpad.net/~usc-isi/nova/hpc-trunk（通常与 nova/trunk 同步）
https://code.launchpad.net/~usc-isi/nova/hpc-testing（稍旧，但更稳定）

架构感知调度器在此处蓝图化

HeterogeneousArchitectureScheduler

我们还在起草三种机器类型的蓝图

有一个 etherpad 用于讨论此蓝图，地址为 http://etherpad.openstack.org/heterogeneousinstancetypes

发布说明

Nova 已扩展，允许部署广告特定的处理器、加速器和网络接口选项，并允许用户使用 instance_types（或 flavors）请求这些选项。

nova-manage instance_types 命令支持额外的字段

cpu_arch - 处理器架构。例如：“x86_64”、“i386”、“P7”等（默认 x86_64）
cpu_info - JSON 格式的扩展处理器信息
xpu_arch - 加速器架构。例如：“fermi”（默认“”）
xpu_info - JSON 格式的扩展加速器信息
xpus - 加速器或加速器处理器的数量
net_arch - 主要网络接口。例如：“以太网”、“InfiniBand”、“Myrinet”
net_info - JSON 格式的扩展网络信息
net_mbps - 分配的网络带宽（兆比特每秒）

Amazon GPU 节点示例

22 GB 内存 33.5 EC2 计算单元（2 x Intel Xeon X5570，四核“Nehalem”架构）2 x NVIDIA Tesla “Fermi” M2050 GPU 1690 GB 实例存储 64 位平台 I/O 性能：非常高（10 千兆以太网）API 名称：cg1.4xlarge

cg1.4xlarge:
 * memory_mb= 22000
 * vcpus = 8
 * local_gb = 1690
 * cpu_arch = "x86_64"
 * cpu_info = '{"model":"Nehalem", "features":["tdtscp", "xtpr"]}' 
 * xpu_arch = "fermi"
 * xpus = 2
 * xpu_info ='{"model":"Tesla 2050", "gcores":"448"}'
 * net_arch = "ethernet"
 * net_info = '{"encap":"Ethernet", "MTU":"8000"}'
 * net_mbps = 10000

原理

目前 AWS 支持两种不同的 CPU 架构类型：“i386”和“x86_64”。此外，AWS 通过引用描述许多其他实例类型属性，例如：I/O 性能：（中等/高/非常高 10 千兆以太网）、扩展 CPU 信息（Intel Xeon X5570，四核“Nehalem”架构）以及现在 GPU 加速器（2 x NVIDIA Tesla “Fermi” M2050 GPU）。为了在 nova 中实现类似的功能，我们需要以一种可供高级调度器访问的方式来捕获这些信息。

有几个相关的蓝图

用户故事

Mary 管理着一个云数据中心。除了她的 x86 刀片服务器外，她还想向客户宣传她的 power7 高性能计算云，该云具有 40Gbit QDR Infiniband 支持。Mary 使用 nova-manage instance_types create 来定义“p7.sippycup”、“p7.tall”、“p7.grande”和“p7.venti”，cpu_arch="power7"，并增加默认内存、存储、核心和保留带宽的数量。Mary 还有少量 GPU 加速系统，因此她定义了“p7f.grande”和“p7f.venti”选项，xpu_arch="fermi"，xpus = 1 用于 grande，xpus = 2 用于 venti。

Fred 想运行一台 8 核机器，并配备 1 个基于 fermi 的 GPU 加速器。他查看了 Mary 的网站上的文本描述，然后想要 p7f.grande 虚拟机。他运行

euca-run-instances -t p7f.grande -k fred-keypair emi-12345678

前提条件

这假设有人已将 OpenStack 移植到不同的处理器架构系统，并且可以将 GPU 等加速器传递到虚拟实例。USC-ISI 团队正在致力于此。我们链接了相关的蓝图，但目标是这个顶层 CPU 架构感知能力能够独立存在。

设计

我们建议将 cpu_arch、cpu_info、xpu_arch、xpu_info、xpus、net_arch、net_info 和 net_mbps 作为属性添加到 instance_types、instances 和 compute_nodes 表中。从概念上讲，这些信息与现有的 memory_mb、local_gb、vcpus 字段的处理方式相同。它们存在于“instance_types”中，并在创建实例时作为列复制到“instances”表中。

架构感知调度器将在选择目标 compute_nodes（nova-compute 服务）时比较这些附加字段。

cpu_arch、xpu_arch 和 net_arch 旨在作为快速行过滤的高级标签切换（例如“i386”或“fermi”或“infiniband”）。
xpus 和 net_mbps 被视为与调度器使用的 vcpus 相同的数量字段
cpu_info、xpu_info 和 net_info 遵循 instance-migration 分支示例，使用 JSON 格式的字符串来捕获任意配置。

这些新字段的上下文会根据它们所在的表而略有变化。

在 instance_types 表中，它们代表机器类型的广告功能，例如“此实例类型提供 100 兆带宽”或“此实例类型支持 Cortex-A9 处理器”。
在 instances 表中，它们代表请求的功能，例如“给我一个 xpu_arch=fermi 且 xpus=2 的实例”。
在 compute_nodes 表中，这些字段代表与 compute_nodes 关联的主机可用的资源。

处理器架构功能 cpu_arch 是理所当然的。许多部署今天就需要这个。添加 cpu_info 是为了多核处理器，例如我们项目中的 Tilera 系统。我们需要指定 instance_type.cpu_info("geometry":"4x4") 之类的内容，以便能够在 8x8 tilemp 处理器上空间地平铺多个虚拟机。在 instance 类型中定义“tile.small”、“tile.medium”和“tile.large”的含义是最简单的。

加速器也很重要，但与其拥有专门的 GPU 相关字段，不如尝试支持其他未来的加速器，如 FPGA、光处理器，任何可以传递到虚拟机的专用硬件资源。xpus 数量字段非常粗糙，不能轻松处理一个具有 2 种不同加速器的盒子，但以后可以将其分解为单独的一对多关系表。我们正在尽量减少 schema 变更。

网络字段试图将网络连接提升到与核心、内存和磁盘同等地位，以选择实例部署在哪个主机上。在 VM 上强制执行带宽会很好，但即使我们在调度器中使用“将网络带宽除以实例数”指标，也比没有好。此外，网络服务将增加另一层复杂性，但至少有了这个蓝图，网络服务将知道实例请求或已在主机上分配了多少带宽。

我们可能需要考虑这些表中额外的顶级列字段，以提高调度器性能，例如 cpu_model 和 xpu_model，但这些是增强功能。

支持多种加速器

提议的方法仅支持每台机器的一种类型的加速器。例如，您可以拥有机器中的 GPU 或 FPGA，但不能同时拥有两者。为了支持多种加速器，我们需要

一个单独的表，其中包含加速器信息
利用 extra-data 方法。

单独的表方法将使代码中的实现更简单。

信息流

nova 中的基本信息流如下

nova-compute 在主机上启动，并在 ComputeNode 表中注册架构、加速器和网络功能。此功能由 instance migration 蓝图提供，并且已经合并。我们需要添加新的字段并使用标志和/或提取的 /proc 信息在 compute_services 表中填充它们
nova-api 接收 run-instances 请求，实例类型字符串为“m1.small”或“p7g.grande”。这里没有变化。
nova-api 将 instance_type 传递给 compute/api.py create()，来自 api/ec2/cloud.py run_instances() 或 api/openstack/servers.py create()。这里没有变化。
nova-api compute/api.py create() 从 instance_types 表中读取，并将行添加到 instances 表中。我们需要将新的字段插入到传递给 instances.db.create() 的 base_options 参数中。这可能也是插入图像 cpu 架构支持 cpu_arch 的合理位置。
nova-api 执行 rpc.cast() 到调度器 num_instances 次，传递 instance_id。这里没有变化。
nova-scheduler 选择与实例表字段中指定的选项匹配的 compute_service 主机。简单的调度器将正常工作，并忽略同构部署中的这些字段。我们需要添加一个架构调度器，它根据 cpu_arch、cpu_info、xpu_arch、xpu_info、xpus、net_arch、net_info 和 net_mbps 过滤可用的 compute_nodes，并使用相同的字段。
nova-scheduler rpc.cast() 到每个选定的 compute 服务。这里没有变化。
nova-compute 接收 rpc.cast()，启动虚拟机等，实例对象中具有 cpu_arch、cpu_info、xpu_arch、xpu_info、xpus、net_arch、net_info 和 net_mbps 字段，并可以根据需要配置 libvirt。现有计算服务管理器不需要更改。USC-ISI 团队正在添加 GPU 和其他非 x86 架构支持（需要添加蓝图引用）。

Schema 变更

扩展了三个表

InstanceTypes

instance_types 现在存储在 nova trunk 中的自己的表中：ConfigureInstanceTypesDynamically

class InstanceTypes(BASE, NovaBase):
    """Represent possible instance_types or flavor of VM offered"""
    __tablename__ = "instance_types"
    id = Column(Integer, primary_key=True)
    name = Column(String(255), unique=True)
    memory_mb = Column(Integer)
    vcpus = Column(Integer)
    local_gb = Column(Integer)
    flavorid = Column(Integer, unique=True)
    swap = Column(Integer, nullable=False, default=0)
    rxtx_quota = Column(Integer, nullable=False, default=0)
    rxtx_cap = Column(Integer, nullable=False, default=0)
+    cpu_arch = Column(String(255), default='x86_64')
+    cpu_info = Column(String(255), default='')
+    xpu_arch = Column(String(255), default='')
+    xpu_info = Column(String(255), default='')
+    xpus = Column(Integer, nullable=false, default=0)
+    net_arch = Column(String(255), default='')
+    net_info = Column(String(255), default='')
+    net_mbps = Column(Integer, nullable=false, default=0)

计算节点

计算节点表由以下内容包含：https://code.launchpad.net/~nttdata/nova/live-migration

class ComputeNode(BASE, NovaBase):
    """Represents a running compute service on a host."""
...
    hypervisor_type = Column(Text, nullable=True)
    hypervisor_version = Column(Integer, nullable=True)
    cpu_info = Column(Text, nullable=True)
+    cpu_arch = Column(String(255), default='x86_64')
+    xpu_arch = Column(String(255), default='')
+    xpu_info = Column(String(255), default='')
+    xpus = Column(Integer, default=0)
+    net_arch = Column(String(255), default='')
+    net_info = Column(String(255), default='')
+     net_mbps = Column(Integer, default=0)

Instance

Instances 表只是携带额外的字段，以便 libvirt_conn 可以拾取它们。这也被调度器像 vcpus 一样使用。

 class Instance(BASE, NovaBase):
     """Represents a guest vm."""
.... 
     instance_type = Column(String(255))
+    cpu_arch = Column(String(255), default='x86_64')
+    cpu_info = Column(String(255), default='')
+    xpu_arch = Column(String(255), default='')
+    xpu_info = Column(String(255), default='')
+    xpus = Column(Integer, default=0)
+    net_arch = Column(String(255), default='')
+    net_info = Column(String(255), default='')
+    net_mbps = Column(Integer, default=0)

实现

USC-ISI 团队有一个功能原型：https://code.launchpad.net/~usc-isi/nova/hpc-trunk

UI 变更

没有向云用户公开的 UI 变更。他们通过 instance_types/flavors 访问该功能。

对于管理员，我们应该将这些字段添加到“nova-manage instance_types create/list”命令中。一个问题是如何处理用户输入的 json 文本字段，但纯文本也不是太糟糕。需要决定是否应该将所有这些内容显示给最终用户，或者将其隐藏为命令的高级/详细参数。

nova.conf 中还有额外的标志，用于在启动计算服务时指定 cpu_arch、xpu_arch、net_arch。

代码变更

变更摘要

nova/db/sqlalchemy/models.py

   - Schema changes for ComputeNode, Instance, and InstanceType

nova/db/sqlalchemy/migrate_repo/versions/013_add_architecture_to_instance_types.py

   - Migration code is such fun.

nova/db/sqlalchemy/migrate_repo/versions/014_add_architecture_to_instances.py

   - Migration code is such fun.

nova/db/sqlalchemy/migrate_repo/versions/015_add_architecture_to_compute_node.py

   - Migration code is such fun.

nova/compute/manager.py

   - Flags for default values inserted in ComputeNode
   - Periodic updates to ComputeNode

nova/compute/api.py

   - Added fields to base_options copied into Instances table

迁移

如果我们设置像今天一样合理的默认值，例如“x86_64”，那么部署使用此功能的方式几乎不需要更改。

测试/演示计划

这不必在规范接近 Beta 之前添加或完成。

未解决的问题

这应该突出显示需要在进一步的规范中解决的任何问题，而不是规范本身的问题；因为任何存在问题的规范都无法获得批准。

BoF 议程和讨论

使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。

异构实例类型

目录

异构实例类型

总结

发布说明

原理

用户故事

前提条件

设计

支持多种加速器

信息流

Schema 变更

InstanceTypes

计算节点

Instance

实现

UI 变更

代码变更

迁移

测试/演示计划

未解决的问题

BoF 议程和讨论