Что внутри RackGrid, часть 5/7

Майнинг-ферма редко живёт в одной подсети. Площадки — это разные здания, разные провайдеры, разные города, и опрашивать сотни устройств через полстраны по одному TCP-соединению — плохая идея по всем статьям сразу. Отсюда режим лидер / агент. На удалённой площадке поднимается нода вообще без веб-интерфейса: она сама регистрируется у лидера по общему секрету, забирает задачи и опрашивает своё оборудование локально, по своей LAN. Наружу уходит только результат. Два решения, которыми я доволен: Дельта-снимки. Агент собирает текущее состояние своей иерархии, сравнивает с предыдущим и отправляет не состояние, а список операций: что создать, что обновить, что удалить — по контейнерам, стойкам и отдельным ASIC. Если за интервал ничего не изменилось — не отправляется ничего. Лидер получает не «вот вам мои 300 устройств, разбирайтесь», а «вот эти 4 изменились»: объём трафика определяется числом изменений, а не размером площадки. Атомарное применение задач. Задача от лидера может разворачиваться в цепочку: создать контейнер → создать в нём стойку → создать в ней устройство. Вся цепочка выполняется в одной транзакции. Либо появилось всё, либо ничего. Второе кажется занудством ровно до первого сбоя посередине операции. Полусозданная иерархия — контейнер и стойка есть, устройства нет — это то, что потом разгребается руками по базе, и хорошо ещё, если её кто-то заметит. Обрыв связи, кстати, по самой цепочке не бьёт: задача уже у агента и выполняется в его собственной базе, канал в этот момент не нужен. Бьёт он по отчёту о задаче — агент её применил, результат до лидера не доехал, и у лидера она осталась в статусе «выполняется». Данные при этом сходятся сами: созданное устройство приедет ближайшим дельта-снимком как обычный create. Расходится только запись о задаче — и это честный минус схемы, но он же показывает, на чём она держится: состояние сходится не потому, что канал надёжный, а потому что агент каждый раз пересчитывает разницу от того, что у него есть сейчас. И симметричное правило на стороне лидера, о котором я упоминал в третьей части: площадки, закреплённые за агентами, лидер не опрашивает сам. Иначе два источника пишут в одну запись наперегонки, и состояние устройства начинает мигать в зависимости от того, кто успел последним. Кто строил похожие схемы «центр + автономные агенты» — как решали расхождение состояний?

Что внутри RackGrid, часть 5/7 | Сетка — социальная сеть от hh.ru Что внутри RackGrid, часть 5/7 | Сетка — социальная сеть от hh.ru Что внутри RackGrid, часть 5/7 | Сетка — социальная сеть от hh.ru Что внутри RackGrid, часть 5/7 | Сетка — социальная сеть от hh.ru