Целесообразность использования xmrig-proxy

Всем привет, собственно сабж. По всем характеристикам и плюшкам вроде куча плюсов, вопрос - есть ли смысл заморачиваться и использовать.

Я попробовал на стенде – работает, из плюсов:

· Все в локалке – контроль доступности внешнего пула только в одном месте

· Запуск на всех машинах однотипный, можно настроить удаленный запуск из одного источника в локалке, хоть политикой разливай.

· Настройки майнера однотипные на всех машинах все на автомате принимается с прокси

· Нет затрат машинных ресурсов на интерфейсную часть приложения, а это по наблюдениям 200-400 H/s на одну машину, не требуется множественная установка приложения.

· Выход на внешний пул под одним адресом – пулу легче (плюс детализация по машинам внутри прокси)

· При смене пула с одной монеты на другую не требуется перезапуск ни прокси, ни майнеров – при настройке автоматического выбора алгоритма все само работает.

· При гипотетическом парке от 20 единиц майнеров трудозатраты на поддержку и сопровождение снижаются перманентно.

Единственный минус – список указанных на прокси пулов работает в режиме приоретизированного бекапа по порядку указания, никакого анализа по уровню доходности естественно не предусмотрено.

Есть ли у кого-то опыт длительного использования xmrig-proxy и какие подводные камни могут всплыть?

В качестве бреда - если доработать приложение возможностью управлять конфигом прокси в плане адреса первого пула в config.json, то вырисовывается вариант:

Приложение установлено на одной машине в локалке для анализа доходности монет на текущий момент и через управление конфигом прокси управлять переключением на лету остальных ПК подключенных через прокси.

Если у вас парк > 10–20 CPU-майнеров → однозначно ДА.
Плюсы перекрывают все минусы.

Если < 10 машин → прокси даёт мало, почти не нужен.
Оправдывает себя только для полной унификации.

xmrig-proxy полезен, если ферма не “домашняя”, а производственная
✦ Даёт экономию времени, ресурсов, унификацию
✦ Основные риски: прокси = единая точка отказа, нет умного failover
✦ Необходим нормальный LAN и дублирование proxy, если парк крупный
✦ Твоя идея динамического управления – самая логичная «эволюция» прокси

Ну у меня сложилось такое же мнение… больше в сторону производственного варианта, хотя…

Домашние сети тоже разные - у меня дома так практически серверная в миниатюре с сегментированной LAN, доменом , виртуалками, полкой СХД и прочей административной требухой, проф.деформация :-)…

А как сети могут быть не нормальные? LAN либо есть и администрируется либо ее просто нет.

По единой точке отказа не согласен - технологически решается достаточно просто как внешний доступ в интернет к внешним пулам посредством load balance с 2 -3 провайдерами (мне дома хватает двух, последняя миля как правило одна на всех ) так и дубляж прокси в LAN посредством локального DNS failover , благо прокси очень не требовательный к ресурсам можно хоть 10 адресов поднять и резолвить на майнерах один локальный dns адрес.

Меня больше конечно привлекает унификация и снижение трудозатрат на сопровождение и обслуживание.

Добрый день,

вопрос такой : при работающем приложении возможно ли в параметрах командной строки xmrig указать внешний файл конфигурации --config=FILE для перенаправления трафика через свой прокси?

У меня не получилось - файл внешнего конфига просто игнорируется , что-то не так делаю или это целенаправленно сделано?

Специально сделано, чтобы нельзя было выполнить потенциально опасный код через приложение или майнеры.

Ок, принято, спасибо

Да, для прокси лучше сторонний майнер использовать, без приложения.
В будущем автосвич на стороне пула должен будет так же появится.