Есть ли способ ограничить выполнение задачи на определенных узлах, но не ограничивать ?
Я использую Docker Swarm, который охватывает несколько центров обработки данных. Swarm работает в «виртуальном частном облаке».
Один из центров обработки данных, участвующих в установке, имеет несколько более медленное соединение, чем другие. Я бы хотел, чтобы в этом центре обработки данных не планировалась услуга, особенно чувствительная к задержкам.
- Я могу использовать ограничения размещения, но это повлияет на доступность. Если "медленный" центр обработки данных по какой-либо причине будет единственным работающим, ограничения будут гарантировать, что ограниченная служба никогда не будет запланирована в этом центре обработки данных. Влияет на доступность.
- Я могу использовать настройки размещения, но это всего лишь предпочтения. Если я добавлю метку
lowlatencyко всем узлам, кроме узлов в «медленном» центре обработки данных, обслуживание все равно может быть запланировано там. В конце концов, это всего лишь предпочтение.
Есть ли способ каким-то образом ограничить службу определенными узлами, но разрешить Docker планировать службу на других узлах, если предпочтительные узлы недоступны?
Нет, это не встроенная функция Swarm Mode.
Единственная доступная в настоящее время настройка размещения – это распределение рабочей нагрузки между значениями ярлыка. Это используется, чтобы избежать планирования всех реплик в одной зоне доступности, например. все рабочие нагрузки в одной стойке, центре обработки данных и т. д. Нет предпочтения размещения, которое действовало бы как мягкое ограничение.
Другой доступный вариант планирования роя — это ограничение, и это жесткое ограничение.Рабочие нагрузки не будут планироваться на узлах, которые не соответствуют ограничению, даже если это означает, что они нигде не планируются, а служба остается недоступной.
Самое близкое, что вы можете сделать для достижения желаемой цели, — это запустить дополнительный процесс для обнаружения отключения всех других центров обработки данных и корректировки ограничения на вашу службу, однако я подозреваю, что это будет иметь две соответствующие проблемы. Во-первых, если другие центры обработки данных не работают, вы, вероятно, потеряли кворум с вашими менеджерами, никакие действия по планированию не будут выполняться, а команды для любого работающего менеджера не будут выполняться из-за потери лидера. И, во-вторых, если у вас есть кворум, узлы в оставшемся центре обработки данных, скорее всего, получат избыточное выделение из-за других перепланируемых рабочих нагрузок. Это известно как проблема громоподобного стада, которая требует установки требований к ЦП и памяти для ваших контейнеров. Эти требования будут блокировать планирование новых заданий на узле, чтобы избежать дальнейшего простоя и предотвратить обнаружение измененным сервисом узла с пропускной способностью.