Масштабирование GSA-фермы ломается не на инстансах, а на грязных списках и разъезде настроек

Масштабирование GSA-фермы ломается не на инстансах, а на грязных списках и разъезде настроек

Когда поднимаешь второй и третий движок, проблема не в железе. Проблема в том, что у каждого инстанса быстро появляются свои футпринты, свои дубли и свой мусорный пул. Если не выстроить синхронизацию, LPM падает, а расследование упирается в «почему этот лист уже не пробивается».

— Держи один master-пул: source list, verified, dead, tiered. Любой импорт идет только через него.
— Разноси списки по ролям: отдельные очереди под сабмит, парсинг, вериф, ресабмит.
— Не копируй руками между инстансами. Используй общий storage или жесткий экспорт по расписанию, иначе ловишь дубли и пересечения по footprint.
— Фиксируй одинаковые правила фильтрации: одна и та же логика для отсева, одинаковые маски, одинаковые лимиты на домены и платформы.

По инстансам схема простая: один менеджер очереди, несколько рабочих машин. Менеджер режет листы на пакеты, рабочие забирают только свой сегмент и отдают статус назад. Так ты видишь, где пробив просел, где капча душит поток, а где конкретный движок начал жрать ресурсы без отдачи. Срезаем косты на капчу через централизованный контроль, а не через хаос в настройках.

Финальная проверка одна: если любой инстанс можно выключить без потери структуры списков и очередей, ферма масштабируется. Если после остановки начинаются ручные правки, у тебя не ферма, а набор разрозненных окон.