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

Question

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

我想重用在我的租户中分配的一些未分配的浮动IP(分配给新提供的服务器)。但是，似乎addFloatingIp操作在分配未使用的浮动IP和将其从服务器重新分配到服务器之间没有任何区别。

我想自动化这个过程，但我担心以下竞争条件:一个客户端检查特定IP是空闲的，在它设法将它与服务器A相关联之前，另一个客户端将它与服务器B相关联。从第二个客户端的角度来看，关联的浮动IP在成功关联后可以在以后的任何一点被删除。

还有更好的办法吗？

Answer 1

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

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

Answer 2

解决这一问题的可能办法是：

• 只删除和创建浮动IP。就像你说的，这是首选的方法。清理不再使用的浮动up，可以通过一个小型VM从内部定期进行。但是从外部清理API客户端应该是首选的。因此，每个客户端都应该集成这个功能，但是必须注意的是，这是用户想要的，至少他们失去了一些重要的东西。示例:用于删除VM的web UI可能会询问它是否也应该删除相关的浮动VM。Openstack (通过模板进行编排)自动完成此操作。CLI客户端可以在删除VM之后提供删除释放的资源。
• 使用支持同步的东西进行协调。例如: etcd、带有事务支持的数据库(SQL或非SQL)、能够确保传递准确一次的队列(例如，OpenStack Zaqar及其索赔功能)。
• 使用时间的段落进行同步:读取、更改、等待特定的时间，最后再读一次，以检查是否没有人重写更改。如果此更改花费太长时间，则在特定等待时间之前中止。如果更改被覆盖，则使用不同的浮动ip重试。这是很难得到正确的，因为有许多角落的情况，特别是正确中止足够快，这可能导致这一失败。例如，高负载可能会使更改在被中止很长时间后成功，如果不是每个更改经过的地方都会确保这种情况不会发生。

其他OpenStack API也有同样的问题，例如更新安全组。通常，可以通过向API添加修订计数器来避免这种情况，例如库伯奈特斯(resourceVersion，ObjectMeta)和modifiedIndex in v2，v3中的mod_revision )。

即使对于实现无种族更改选项的API，大多数用于人类的UI也可能只用于种族检测，而不用于回避，因为用户界面告诉他们存在种族，它覆盖的内容比要求他们每次发生种族时都要重试其操作的UI更可取。