Присвоить OpenStack плавающий IP, а убедившись, что он не будет удален с другого сервера

Question

(я использую openstack4j поговорить с OpenStack через REST API)

Я хотел бы повторно использовать некоторые из присвоенных в плавающих IP-адресов, выделенных в моем арендатора (выделение для вновь созданных серверов). Однако, похоже, что действие addFloatingIp не имеет никакого отношения к назначению неиспользуемого плавающего IP-адреса и переназначению его с сервера на сервер.

Я хотел бы автоматизировать процесс, но я боюсь следующего состояния гонки: один клиент проверяет, какой IP-адрес является бесплатным, и до того, как ему удастся связать его с сервером A, другой клиент свяжет его с сервером B. С точки зрения второй клиент, связанный с ним плавающий IP-адрес может быть удален в любой последующий момент после успешного соединения.

Есть ли лучший способ?

Answer 1

Возможные обходные пути для этого:

• только удалять и создавать плавающие IP-адреса. Как вы говорите, это предпочтительный способ. Очистка плавающих IP-адресов, которые больше не используются, может происходить регулярно изнутри с помощью небольшой виртуальной машины. Но предпочтительнее очистка снаружи от клиента API. Таким образом, каждый клиент должен интегрировать эту функциональность, однако следует позаботиться о том, чтобы это было предназначено для пользователя, и в меньшей степени они теряют что-то важное. Примеры. Веб-интерфейс, который вы используете для удаления виртуальных машин, может спросить, следует ли также удалять связанную плавучую виртуальную машину. Openstack Heat (оркестровка через шаблоны) делает это автоматически. Клиент CLI мог бы предложить удалить освобожденные ресурсы после удаления виртуальной машины.
• Используйте что-то, что поддерживает синхронизацию для координации. Примеры: etcd, база данных (SQL или нет) с поддержкой транзакций, очереди, которые могут гарантировать, что доставка выполняется ровно один раз (например, OpenStack Zaqar с функцией заявки).
• Используйте проход времени для синхронизации: прочитайте, измените, ожидайте определенное количество времени и, наконец, прочитайте снова, чтобы проверить, что никто не переписывал изменение. Прерывание перед конкретным временем ожидания, если это изменение занимает слишком много времени. Повторите попытку с помощью другого плавающего ip, если изменение было перезаписано. Это трудно сделать правильно, так как есть много угловых случаев, особенно при правильном прерывании достаточно скоро, что может сделать это неудачным. Например, высокая загрузка может сделать изменение успешным после того, как оно было прервано, если не все места, через которые проходит изменение, гарантируют, что этого не произойдет.

Другие API OpenStack имеют одинаковую проблему, например. updating security groups. В общем, этого можно избежать, добавив счетчики ревизий к API, например kubernetes (resourceVersion from ObjectMeta) и etcd (modifiedIndex in v2, mod_revision в версии 3).

Даже для API, который реализует варианты изменений без гонок, большинство пользовательских интерфейсов для людей могут использовать это только для обнаружения гонки, но не для избежания, как для пользовательского интерфейса, который говорит им, что существует гонка, и то, что она перезаписано, предпочтительнее, чем для того, требует от них повторить свое действие каждый раз, когда происходит гонка.