Есть ли способ ограничить выполнение задачи на определенных узлах, но не ограничивать их?

Question

Я использую Docker Swarm, который охватывает несколько дата-центров. Swarm работает в «виртуальном частном облаке».

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

• Я могу использовать ограничения размещения, но это повлияет на доступность. Если по какой-то причине "медленный" центр обработки данных будет единственным работающим, ограничения гарантируют, что ограниченная услуга никогда не будет запланирована в этом центре обработки данных. Влияет на доступность.
• Я могу использовать предпочтения размещения, но это всего лишь предпочтение. Если я добавил метку lowlatencyко всем узлам, кроме тех, что находятся в «медленном» центре обработки данных, служба все равно может быть запланирована там. В конце концов, это всего лишь предпочтение.

Есть ли способ каким-то образом ограничить службу определенными узлами, но разрешить Docker планировать службу на других узлах, если предпочтительные узлы недоступны?

Answer 1

Нет, это не встроенная функция Swarm Mode.

Единственная доступная в настоящее время настройка размещения — это распределение нагрузки по значениям метки. Это используется для того, чтобы избежать планирования всех реплик в одной зоне доступности, например, все нагрузки в одной стойке, центре обработки данных и т. д. Нет настройки размещения, которая действовала бы как мягкое ограничение.

Другой доступный вариант в swarm-планировании — это ограничение, и это жесткое ограничение. Рабочие нагрузки не будут планироваться на узлах, которые не соответствуют ограничению, даже если это означает, что они не могут быть запланированы нигде, и служба остается недоступной.

Ближайшее, что вы можете сделать для достижения желаемой цели, — это запустить дополнительный процесс для обнаружения сбоя всех других центров обработки данных и скорректировать ограничение на ваш сервис, однако я подозреваю, что это будет иметь две соответствующие проблемы. Во-первых, с отключением других центров обработки данных вы, вероятно, потеряли кворум с вашими менеджерами, планирование не будет выполняться, и команды любому работающему менеджеру не будут выполнены из-за потери лидера. И, во-вторых, если у вас есть кворум, узлы в оставшемся центре обработки данных, вероятно, будут перегружены из-за других рабочих нагрузок, которые будут перепланированы. Это известно как проблема громового стада, которая требует установки требований к ЦП и памяти для ваших контейнеров. Эти требования заблокируют планирование новых заданий на узле, чтобы избежать дальнейшего сбоя и не дать вашему измененному сервису найти узел с емкостью.