MoveIpAllocation
|
旧设计页面
此页面曾用于帮助设计 OpenStack 早期版本的一个特性。该特性可能已经或尚未实现。因此，此页面可能不会更新，并且可能包含过时的信息。上次更新时间为 2013-12-19 |
- Launchpad 条目: NovaSpec:move-ip-allocation
- 创建: 10/31/10
- 贡献者: Vish Ishaya
总结
IP 分配目前发生在 API 层。这并不是 IP 分配的最佳位置，因为它迫使 API 了解网络拓扑的太多信息。这个规范很可能为 虚拟网络 铺平道路。
发布说明
IP 分配被移到了堆栈的更底层。这意味着向 API 发起启动实例的请求不再返回实例的 IP。一旦实例被分配了 IP，该 IP 将在任何获取实例数据的 API 调用中返回。
原理
Nova 支持各种网络拓扑。在大型部署中，IP 地址可能特定于运行实例的主机机器，或者主机机器所属的集群。API 没有这些信息，也不应该需要这些信息。此外，API 命令在运行实例时无需阻塞等待 IP 地址分配完成。
用户故事
这更像是一个提供商功能，而不是用户功能。它允许提供商在设计其基础设施的网络时拥有更大的灵活性。
前提条件
设计
当前实现
目前，有三种网络策略，由不同的管理器实现：FlatManager -- IP 地址从网络中获取，并在启动时注入到镜像中。所有实例都连接到相同的手动配置桥接。FlatDHCPManager -- IP 地址从网络中获取，并为所有实例创建一个桥接。启动一个 DHCP 服务器来分配地址。VlanManager -- 每个项目获得自己的 VLAN、桥接和网络。为每个 VLAN 启动一个 DHCP 服务器，所有实例都桥接到该 VLAN。
创建桥接、VLAN、DHCP 服务器和防火墙规则的实现由驱动程序 linux_net 完成。这种抽象化是为了让我们能够在某个时候使用相同的管理器支持配置硬件交换机等。
我重构 Manager 的目标是将与每个组件相关的所有代码移动到 Manager 类中。例如，与网络/IP 相关的所有代码都将由 NetworkManager 完成。也就是说，与业务对象相关的代码需要由三个单独的工作者运行，并且并非所有代码都封装在管理器中。例如，实例/卷的记录的初始创建是由 nova-api 通过直接访问数据库完成的，而不是使用管理器上的方法。
以下是每个组件在运行实例期间所做事情的糟糕 ASCII 艺术图。管理器的方法直接用于本地设置，并通过 RPC 调用到 nova-network，nova-network 运行一个包装了管理器并通过公开方法暴露给 RPC 的服务。*d 项目不特别与网络相关，但有助于说明事情发生的时间
+----------------+ +----------------+ +----------------+
| nova-api | | nova-network | | nova-compute |
-----------------+ +----------------+ +----------------+
(direct manager) (service) (direct manager)
*create instance in db
find correct network host
(get_network)
call (if no host) -----> sets up network
(set_network_host)
<----------------------- returns host
allocates fixed ip
(allocate_fixed_ip)
cast-------------------> sets up fixed ip
V (setup_fixed_ip)
cast-----------(goes through scheduler)---------> (ComputeManager.run_instance)
| sets up compute network
| (setup_compute_network)
| * launches instance
| sets up security groups
V (done by compute driver)
*return instance data
所有这些都有效，并允许我们从 API 调用中非常快速地返回 IP，但它确实存在一些问题。最重要的是，在某些网络模型中，API 服务器可能没有足够的信息来知道如何分配 IP。例如，在 flat 模式下，我们可能希望将一个与特定网络主机关联的计算节点集群，并且 get_network 返回基于计算主机而不是项目（如我们在 VLAN 模式中所做）的网络。
新实现
IP 的分配应该进一步下移到堆栈中，如下所示
+----------------+ +----------------+ +----------------+ | nova-api | | nova-network | | nova-compute | -----------------+ +----------------+ +----------------+ (direct manager) (service) (direct manager) *create instance in db check for available network resources (check_free_ips?) cast-----------(goes through scheduler)---------> (ComputeManager.run_instance) | find correct network host | (get_network) | sets up network <------- call (if no host) | (set_network_host) | -----------------------> returns host | sets up compute network | (setup_compute_network) | allocates fixed ip <---- call (because we're not in a rush) | (allocate_fixed_ip) | (setup_fixed_ip) | -----------------------> returns fixed_ip | * launches instance | sets up security groups V (done by compute driver) *return instance data (with no ip address)
实现
实现本身应该相当简单。这意味着将网络调用移动到计算管理器。
概念验证
应该尝试至少一种使用不同网络模型的实现。可以修改 FlatNetwork 以从与主机关联的网络而不是项目分配 IP，或者可以创建一个新的网络模型来支持集群和每个集群一个网络。
迁移
这不需要数据迁移，但需要向用户明确说明，他们的 IP 地址不会在从 API 调用返回时立即可用。他们需要轮询 API 以查找 IP 地址。
未解决的问题
在某个时候，拥有某种 webhook 会很有用，可以指定 webhook，以便最终用户可以替代不断轮询 API 系统。Webhook 在 IP 分配之外还有用，因此应该在单独的蓝图（blueprint）中解决。
BoF 议程和讨论
使用本节记录 BoF 期间的笔记；如果将其保留在批准的规范中，请用于总结讨论内容并记录任何被拒绝的选项。
