Вы можете скопировать бинарники из контейнера. Другой вариант - собирать их исходников.
Обычно это делается указанием хоста в порт маппинге -p hostip:28967:28967
Так как вы хотите запустить в режиме --network host, то нужно указать явно адрес для биндинга в параметре server.address: вместе с портом в config.yaml
Это очень интересная статистика, спасибо!
На моём Windows “сервере” с этой опцией не работает (что не удивительно, там Linux VM, которая может быть доступна только через бридж).
RPI3 без --network host:
========== AUDIT =============
Successful: 6107
Recoverable failed: 0
Unrecoverable failed: 0
Success Rate Min: 100.000%
Success Rate Max: 100.000%
========== DOWNLOAD ==========
Successful: 63887
Failed: 1423
Success Rate: 97.821%
========== UPLOAD ============
Successful: 9877
Rejected: 0
Failed: 137337
Acceptance Rate: 100.000%
Success Rate: 6.709%
========== REPAIR DOWNLOAD ===
Successful: 16571
Failed: 1
Success Rate: 99.994%
========== REPAIR UPLOAD =====
Successful: 414
Failed: 5572
Success Rate: 6.916%
С опцией --network host спустя почти сутки:
========== AUDIT =============
Successful: 323
Recoverable failed: 0
Unrecoverable failed: 0
Success Rate Min: 100.000%
Success Rate Max: 100.000%
========== DOWNLOAD ==========
Successful: 3133
Failed: 47
Success Rate: 98.522%
========== UPLOAD ============
Successful: 2173
Rejected: 0
Failed: 14645
Acceptance Rate: 100.000%
Success Rate: 12.921%
========== REPAIR DOWNLOAD ===
Successful: 848
Failed: 0
Success Rate: 100.000%
========== REPAIR UPLOAD =====
Successful: 34
Failed: 250
Success Rate: 11.972%
Могу подтвердить, что для rpi3 разница заметна. К сожалению, у меня нет других чистых Linux нод, чтобы проверить на них тоже.
Эту опцию могу добавить в руководство по Raspberry Pi3.
К сожалению не могу порекомендовать её для общего руководства - на Docker Desktop for Windows и Docker Desktop for MacOS работать не будет.
Для нормального подтверждения эффективности этого параметра нужно сэмулировать это с помощью storj-sim и подключенных docker storagenode к нему.
Потому что результаты могут варьироваться от дня ко дню даже без добавления каких-либо параметров.
Предлагаю заинтересованным это сделать. Я постараюсь это воспроизвести и предоставить результаты для разработчиков.
sucсessrate не обеспечивает надёжного подтверждения. Вернул -p 28967:28967 и убрал --network host
========== AUDIT ============= |
Successful: 46 |
Recoverable failed: 0
Unrecoverable failed: 0
Success Rate Min: 100.000%
Success Rate Max: 100.000%
========== DOWNLOAD ==========
Successful: 563
Failed: 25
Success Rate: 95.748%
========== UPLOAD ============
Successful: 705
Rejected: 0
Failed: 3892
Acceptance Rate: 100.000%
Success Rate: 15.336%
========== REPAIR DOWNLOAD ===
Successful: 88
Failed: 0
Success Rate: 100.000%
========== REPAIR UPLOAD =====
Successful: 14
Failed: 57
Success Rate: 19.718%
1 Like
Мой пример с чистым дебианом 10
было 72-76
стало 96-100
Пока наши результаты не могут быть расценены как воспроизводимые.
1 Like
А эти проценты вообще хоть на что-то влияют?
4 ноды запущены почти одновременно, процент успеха при аплоаде от 22 до 71, количество данных на диске, сетевая активность, выплаты - всё абсолютно одинаковое.
Я тему начал через эти циферки, а циферки начала смотреть потому как у коллеги за январь на аналогичных нодах было В ЧЕТЫРЕ РАЗА больше исходящих
Убрал iSCSI
Сейчас экспериментирую с LXC и хостом, с EXT4 и ZFS… мониторю по двухсуточной стате РЕАЛЬНОЙ…
ИМХО, данный скрипт показывает погоду на марсе ибо реально втянуто данных почти одинаково, при отличии статы В 3 РАЗА
Не особенно. Это больше для интереса.
Медленные системы будут проигрывать в передаче мелких кусочков из-за latency, но обычно неплохо справляются с большими.
Скрипт анализирует имеющиеся логи. При установке по умолчанию все логи удаляются вместе с контейнером, поэтому реальной статистики таким способом не получить. Но за интервал времени с последнего создания контейнера годятся для примерного анализа.
Рекомендую использовать встроенный мониторинг:
curl localhost:7777/mon/funcs
надо только включить этот порт Guide to debug my storage node, uplink, s3 gateway, satellite
Кстати насчёт точности метода successrate. Вернул -p 28967:28967 и убрал --network host с моего raspberry Pi3.
========== AUDIT ============= |
Successful: 46 |
Recoverable failed: 0
Unrecoverable failed: 0
Success Rate Min: 100.000%
Success Rate Max: 100.000%
========== DOWNLOAD ==========
Successful: 563
Failed: 25
Success Rate: 95.748%
========== UPLOAD ============
Successful: 705
Rejected: 0
Failed: 3892
Acceptance Rate: 100.000%
Success Rate: 15.336%
========== REPAIR DOWNLOAD ===
Successful: 88
Failed: 0
Success Rate: 100.000%
========== REPAIR UPLOAD =====
Successful: 14
Failed: 57
Success Rate: 19.718%
Продолжаю эксперименты
Линух, сделал 3 IP в одной подсети на интерфейс
правлю config.yaml
Стартую ноду
docker run -d --restart unless-stopped --network host …
А ему плевать, оно вешает консоль на 14002 на ВСЕ ИНТЕРФЕЙСЫ
Что я делаю не так?
Почему игнорируется config.yaml?
Единственое, что не игнорируется порт - server.address: 10.1.1.33:28969
Как запусть две ноды на одном линухе?
server.private-addess dolzhen byt port unikalen tozhe
допустим и исправлю это
Но пока я стартую только одну ноду - почему оно на 14002 вешается? Разработчики игнорят эту опцию?
u node dolzna byt i imja svojo tozhe unikalnoe
называю нода 2 и нода 3
mozhno initsializirujushuju comandu? polnostju
нода 3
docker run -d --restart unless-stopped --network host
-e WALLET=“0x302ba66689ab1ba2b1769b2eb8481bbde6632d51”
-e EMAIL=“igмммм@eммм.ua”
-e ADDRESS=“storj3.zhyr.cloud:28969”
-e BANDWIDTH=“30TB”
-e STORAGE=“1000GB”
–mount type=bind,source="/mnt/pve/storjext4/storj3/identity/storagenode",destination=/app/identity
–mount type=bind,source="/mnt/pve/storjext4/storj3/",destination=/app/config
–name storagenode3 storjlabs/storagenode:beta
Ниже убрал ибо в режиме хоста оно игнорится (с ним тоже самое… ноде плевать, она 14002)
-p 28969:28967 \
-p 10.1.1.33:14004:14004 \
it may be there is no way to run multiple docker under host, when you make run command, it usehis standard values, and rewrite conf.yaml you can then stop it, change config and start again but not with run command. docker start storagenode3 or what name it has
[quote=“Vadim, post:75, topic:4279”]
docker start storagenode3[/quote]
Остановил
Сделал docker start storagenode3 - все тоже самое
vozmoshno nikto ne delal mnogo node s host vareantom.
-p 28969:28967
-p 10.1.1.33:14004:14002 \
takim vareantom, togda v dockere nat i on sam posebe.
Вероятнее всего вы правы и это банально нода игнорит конфиги ЧАСТИЧНО
Но с НАТ запускать не хочу - они лишний…
Есть еще кто практикует мультинодовость?
АУ
Я тут один?
Как-то еще можно ваше детище перевесить с 14002 на кастомный порт?
Или мы так боремся за скорость, что без обгортки НАТ докера оно не гибко?
u menja vsjo na GUI rabotajut po 4-5 shtuk, s dockerom vozitsa ne ho4u, da i proizvoditelnost u GUI bolshe.