Имеется схема с сервером rsync, на нём соответственно лежат файлы. И множество клиентов - до 50к. Эти клиенты соответственно синхронизируются с сервером.
Что имеем по факту? systemctl из коробки даёт лимит 1024 max open files для сервиса, что даёт внутри rsync потолок около 500 клиентов. Увеличиваем лимит сервиса, ставим в настройках самого рсинка max connections=0 (безлим). В результате - клиенты коннектятся где-то до 5000+, затем начинаются дропы по TCP: "Connection reset by peer (104)" что вроде как говорит о TCP RST. Пока набирается пул коннектов, несколько устройств успевают обновиться, потом они толкутся переподключаются и не синхронизируются. Переваливаешь сервер - снова успевает несколько устройств синхронизироваться, пока не набивается количество коннектов. Памяти и ЦПУ достаточно.
То есть если устройства обновлять мелкими партиями - всё ок. Как только толпа - коллапс, и он сам не разгребается.
Итого вопрос - как обустроить это хозяйство?
Эти ддос-ящие 50к клиентов выглядят как неправильная архитектура.
У меня вопрос, не пробовал ли вместо rsync использовать rtorrent (или наверное лучше deluge или другой безголовый демон) со включенной опцией dht и поиском локальных пиров, если 50к клиентов в локальной сети? Если отключить в настройках пересканирование содержимого файлов при обновлении торент файла, должно быть очень эффективно и красиво работать.
С точки зрения нагрузки, она станет максимально эффективно распределенной по клиентам, а сервер максимум как трекер будет работать ну и работать как одним из гарантированных клиентов и стартом dht сети. Под вопросом работа при большом (десятки тысяч) количестве файлов, а вот по трафику это будет наилучший вариант.
Полностью поддержваю соменния насчет диска. При 5000 соединениях во первых канал будет поделен на 5 тыщ в пропорции. Если не поделен - то тогда зачем им вообще параллельно работать верно? Тоесть мы должны заложиться на какую-то сверх-быструю дисковую систему и такую-же быструю сеть.
Возможно-ли кластеризовать или партиционировать самих клиентов и их хранилища? Это был-бы инженерный вариант решения проблемы.
Кроме того они р-синкаются когда им вздумается. Следовательно сутошного баланса нету. В 19-00 - 20-00 в час наибольшей нагрузке все ломануться в одно время и будет затык. Возможно имеет смысл придумать расписание. Скедулер. И рекомендуемое время р-синка. Ну тоесть не запрещать а рекомендовать.
спробовать перейти от инструмента rsync к демону syncthing (или коммерческому resilio sync).
rsync разрабатывался как локальный инструмент подтвержденного копирования со всеми атрибутами из дирА в дирБ, 50 килоклиентов явно не его рабочая стезя.
а вот демон, в том числе разработанный с учетом опыта рсинка, должен осилить такую сеть.
битторент (исходник для ресилио и синхфинга) и большее число клиентов связывает без проблем. но у него раздачи в р/о, что гораздо проще.
минус в синхфинге - сложная система аутенфикации клиентов меж собой, 50 килов меж собой связывать придется "вручную" - гемор.
ресилио вообще не аутенфицирует клиентов. у кого есть ключ раздачи - тот и допущен к раздаче.
Dimonchik, норм. %тс% просто имеет практическую задачу и не програмист.
да и зачем писать свой колхоз, если кому-то задача подобная попадалась и вероятно както она уже решена.
А не думали что в диск может упирается?
По идее для такого кол клиентов уже надо что то адекватное разворачивать, вместо rsync...
Точнее адекватное на сервере, NFS там или webdav
Возможно вместо rsync сможет помочь rclone, по крайне мере у меня клиенты в вебдав с помощью rclone ходят, вроде всё ок.. порядка 1000шт, правда не всегда одновременно
Простой
Сложный
