cloud - 分配 openstack float IP，同时确保它不会从其他服务器中删除

Question

(我正在使用 openstack4j 通过 REST API 与 OpenStack 对话)

我想重用我的租户中分配的一些未分配的 float IP(分配给新配置的服务器)。然而，似乎addFloatingIp操作在分配未使用的 float IP 和在服务器之间重新分配它之间没有区别。

我想自动化该过程，但我担心以下竞争条件:一个客户端检查特定 IP 是否可用，并且在设法将其与服务器 A 关联之前，其他客户端将其与服务器 B 关联。从第二个客户端的角度来看，关联的 float IP 可以在成功关联后的任何时间点删除。

有没有更好的办法？

Answer 1

可能的解决方法是:

仅删除和创建 float IP。正如您所说，这是首选方式。小型虚拟机可以定期从内部清理不再使用的 float IP。但是应该首选 API 客户端从外部清理。因此，每个客户端都应该集成此功能，但是必须注意这是用户的意图，至少他们会丢失一些重要的东西。示例:用于删除 VM 的 Web UI 可能会询问是否还应删除关联的 float VM。 Openstack Heat(通过模板进行编排)会自动执行此操作。 CLI 客户端可以提供在删除 VM 后删除释放的资源。

使用支持同步的东西来协调。示例:etcd、具有事务支持的数据库(SQL 与否)、可以确保交付仅完成一次的队列(例如具有声明功能的 OpenStack Zaqar)。

利用时间的流逝进行同步:阅读、更改、等待特定时间，最后再次阅读以检查是否没有人覆盖更改。如果此更改时间过长，则在特定等待时间之前中止。如果更改被覆盖，请使用不同的 float ip 重试。这很难做到正确，因为有很多极端情况，尤其是在足够快地正确中止的情况下，可能会导致失败。例如，如果不是更改经过的每个地方都确保不会发生这种情况，那么高负载可能会使更改在中止后很长时间内成功。

其他 OpenStack API 也有同样的问题，例如 updating security groups .一般来说，这可以通过向 API 添加修订计数器来避免，例如 kubernetes (resourceVersion from ObjectMeta)和 etcd (modifiedIndex in v2 , v3 中的 mod_revision) 执行此操作。

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