4

（我正在使用 openstack4j 通过 REST API 与 OpenStack 对话）

我想重用在我的租户中分配的一些未分配的浮动 IP（分配给新配置的服务器）。但是，分配未使用的浮动 IP 和将其从服务器重新分配到服务器之间似乎addFloatingIp没有区别。

我想自动化这个过程，但我害怕以下竞争条件：一个客户端检查特定 IP 是免费的，在它设法将它与服务器 A 关联之前，其他客户端将它与服务器 B 关联。从第二个客户端的角度来看，关联的浮动 IP 可以在关联成功后随时移除。

有没有更好的办法？

4

2 回答 2

1

可能的解决方法是：

  • 仅删除和创建浮动 IP。正如您所说，这是首选方式。小型 VM 可以定期从内部清理不再使用的浮动 IP。但是应该首选由 API 客户端从外部进行清理。因此，每个客户端都应该集成这个功能，但是必须注意这是用户的意图，至少他们会丢失一些重要的东西。示例：用于删除 VM 的 Web UI 可能会询问它是否也应删除关联的浮动 VM。Openstack Heat（通过模板进行编排）会自动执行此操作。CLI 客户端可以在删除 VM 后提供删除释放的资源。
  • 使用支持同步的东西来协调。示例：etcd、具有事务支持的数据库（SQL 与否）、可以确保交付只完成一次的队列（例如具有声明功能的 OpenStack Zaqar）。
  • 使用时间流逝进行同步：读取、更改、等待特定时间量，最后再次读取以检查没有人覆盖更改。如果此更改花费的时间过长，请在特定等待时间之前中止。如果更改被覆盖，请使用不同的浮动 ip 重试。这很难做到正确，因为有很多极端情况，尤其是在足够快地正确中止的情况下，可能会导致失败。例如，如果不是更改经过的每个地方都确保不会发生这种情况，那么高负载可能会在中止后很长时间内使更改成功。

其他 OpenStack API 也有同样的问题，例如更新安全组。一般来说，这可以通过向 API 添加修订计数器来避免，例如kubernetes（来自 ObjectMeta 的resourceVersion）和etcd（在 v2中的modifiedIndex，在 v3 中的 mod_revision）这样做。

即使对于实现无种族更改选项的 API，大多数人类 UI 也可能仅将其用于种族检测而不是避免，因为告诉他们存在种族并且它覆盖的内容优于要求他们重试的 UI每次比赛发生时他们的行动。

于 2017-09-01T14:34:33.253 回答
0

有问题的挑战涉及使用（现已弃用）计算服务的浮动 IP 扩展，该扩展将浮动 IP 分配分为两个步骤：分配（/os-floating-ips端点）和分配（addFloatingIp服务器操作）。

当前支持的方式是通过 Neutron 服务来操作浮动 IP，该服务允许在一个请求 ( POSTto /v2.0/floatingips) 中创建和关联浮动 IP。至少在理论上，这消除了希望重用浮动 IP 的客户端将一个与其他客户端同时关联的可能性。如果所有客户端都同意使用这种浮动 IP 分配模式，则未关联的浮动 IP 可以安全地作为悬空实体处置。

于 2018-10-15T10:10:12.567 回答