Балансировка нагрузки хранилища артефактов Nexus

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

Тем не менее, я сделал это, поделившись файловой системой с GlusterFS для /storageи попытавшись включить липкость в конфигурации Apache Load Balancer и в конфигурации Nexus для пользовательского интерфейса.

С пользовательским интерфейсом у меня ничего не получается, так как кажется, что контейнер Nexus не поддерживает свойства для установки значения cookie; используя следующую конфигурацию на данный момент:

Для хранения, кажется, работает, ограничивая до GETи HEADзапросы только, по- прежнему должны попробовать отверстие в POSTс. Я также не был уверен в возможных побочных эффектах запланированных заданий, поэтому все они были отключены на «вторичном» узле.

Кто-нибудь достиг некоторого уровня надежной конфигурации для балансировки нагрузки Nexus? Пользовательский интерфейс на самом деле не важен, чтобы быть сбалансированным по нагрузке, я был бы достаточно счастлив с хранилищем.

Nexus 3 Pro от Sonatype поддерживает высокую доступность посредством нескольких механизмов, которые в совокупности известны как Component Fabric:

• Одноранговые менеджеры репозитория означают, что нет ни одного мастера, также известного как единая точка отказа. Пакеты реплицируются между узлами, чтобы обеспечить их согласованность.
• Хранение Backends означает, что вы можете использовать высокопрочное хранилище, такое как S3.
• Динамические узлы обеспечивают поддержку автоматического масштабирования для увеличения емкости при высоком спросе и уменьшения ее при низком уровне для снижения затрат.

На самом деле не в интересах Sonatype поддерживать HA для проекта сообщества, поскольку это может привести к гибели некоторых корпоративных клиентов от их платного продукта.