Алексей, добрый день!
Только что получил сообщение о дисквалификации ноды на saltlake и asia-east.
Понимаю что в обратную сторону это решение развернуть не удастся, хотелось бы понять где допустил ошибки. Нужна ваша консультация.
Здравствуйте!
Дисквалификация может быть за потерянные данные (или доступа к ним) или если узел не может предоставить запрошенный кусочек с четырёх попыток с таймаутом в 5 минут.
Вам нужно поискать в логах GET_AUDIT и failed в одной строке, можно использовать скрипты отсюда:
Если вы используете Windows и Docker, то необходимо откатить версию Docker desktop до 2.1.0.5:
откат происходит из самого Docker каким то образом или на сайте
stable version=2.1.0.5 version?
поискал на сайте, кроме stable и edge не нашел, на github только контейнеры
нода заблокирована необратимо и нужно начинать заново или есть возможность вернуться в строй?
если необратимо могу ли я сделать graceful exit?
Откат происходит как обычно - удаляете полностью, скачиваете 2.1.0.5 и устанавливаете.
Если audit score ниже 0.6 (ниже 60% на dashboard), то дисквалификация постоянная и необратимая.
только с не дисквалифицировавших сателлитов и если возраст узла не менее 6 месяцев на этом сателлите. Посмотреть возраст можно на dashboard в Payout information.
Если на одном ПК, то их необходимо сделать разными. Это порт для CLI dashboard.
Кстати, убедитесь, что эти узлы используют разные identity (должны быть разные пути) и разные диски для хранения данных.
Один из способов получить быструю дисквалификацию - клонировать identity вместо создания новой.
с этим проблем нет.
не совсем понял как, поменял в config.yaml - на +1 (7779) появилась ошибка
Error: rpccompat: dial tcp 127.0.0.1:7778: connect: connection refused
На этих сателлитах, к сожалению, - да.
Где вы видите эту ошибку?
Когда запускаете CLI dashboard для второго узла - необходимо указывать параметр --address 127.0.0.1:7779
ошибка появляется при запуске из командной строки команды:
docker exec -it storagenode /app/dashboard.sh
после внесения правки в config.yaml в параметре:
private address to listen on
server.private-address: “127.0.0.1:7778”
так?:
docker exec -it --address 127.0.0.1:7779 storagenode2 /app/dashboard.sh
но в этом случае получаю ошибку:
unknown flag: --address
так же, во избежание повторения моего негативного опыта другими пользователями, лучше внести правку ссылки в мануале по запуску по адресу:
https://documentation.storj.io/setup/cli/docker
со ссылкой на:
https://download.docker.com/win/stable/40693/Docker%20Desktop%20Installer.exe
или:
С указанием корректно работающей версии Docker. По тексту мануала ни слова, а на форуме это обсуждение пропустил, т.к. давно в настройке на Docker необходимость отпала - для работы single ноды более чем устраивал функционал из WIN GUI.
Потому что в мануале ссылка на последнюю версию, а это приводит к печальным последствиям - в моём случае к потере 15-месячной ноды.
Если вы используете docker версию без --network host, то контейнеры изолированы друг от друга, в этом случае ничего в конфиге менять не нужно. Верните, пожалуйста, как было.
Замена внутренних портов актуальна только для binary версий или если вы используете --network host.
Извиняюсь за путаницу, я почему-то подумал, что вы переключились на Windows GUI.
Я добавлю информацию по версии docker для Windows, спасибо за идею!
Без проблем, в данном случае сразу “в лоб” получил ошибку, всё вернул обратно.
Частично дисквалифицированную ноду продержу до конца сентября, потом сделаю выход и начну сначала. Так или иначе теперь есть понимание как масштабироваться дальше - и это важно.
В любом случае огромная благодарность за уделённое время и ответы на накопившиеся вопросы. Хорошего дня!
Пожалуйста!
Кстати, у нас нет статистики дисквалификации из-за docker desktop или offline (оно просто не включено).
Проверьте на всякий случай диски. Чаще всего дисквалификация наступает за потерянные или недоступные кусочки, а не медленную работу узла. Потому что чтобы провалить аудит кусочка, узел должен быть онлайн, ответить на запрос аудита но так и не предоставить нескольких килобайт кусочка за 5 минут, такой запрос повторяется ещё три раза в разное время.
Такое может быть, если узел не в состоянии прочитать кусочек с диска или какие-то серьёзные проблемы с сетью.
Чтобы audit score начал падать одного проваленного аудита недостаточно, а вот несколько подряд - вполне.
Были ошибки следующего вида:
contact:service ping satellite failed - предполагаю что эта свидетельствует о дисквалификации ноды на X сателлите;
ERROR “nodestats:cache Get held amount query failed”…“heldamount service error: unable to connect to the satellite 118UWpMCHzs6CvSgWd9BfFVjw5K9pZbJjkfZJexM
tSkmKxvvAW…” - так же по пониманию конструкции о дисквалификации.
ERROR piecestore upload failed
ERROR piecestore download failed
ERROR piecedeleter delete failed
Эти три очень похожи на потерянные/недоступные кусочки.
По лайнапу:
#была рабочая нода на 1 HDD;
#поставил +1 HDD под отдельную ноду;
#прописал через Storj Toolbox, видимо напортачил, обе ноды ушли offline;
#всё снёс, поставил Docker версии 2.3.0.5, использовал настройки:
docker run -d --restart unless-stopped -p 28967:28967 -p 127.0.0.1:14002:14002 -e WALLET=“wallet1” -e EMAIL=“email1” -e ADDRESS=“ip:28967” -e BANDWIDTH=“50TB” -e STORAGE=“11.5TB” --mount type=bind,source="c:\Storj\Identity\storagenode",destination=/app/identity --mount type=bind,source="G:\data",destination=/app/config --name storagenode storjlabs/storagenode:latest
docker run -d --restart unless-stopped -p 28968:28967 -p 127.0.0.1:14003:14002 -e WALLET=“wallet1” -e EMAIL=“email2” -e ADDRESS=“ip:28968” -e BANDWIDTH=“50TB” -e STORAGE=“11TB” --mount type=bind,source="C:\Storj\Identity\storagenode2",destination=/app/identity --mount type=bind,source="N:\data",destination=/app/config --name storagenode2 storjlabs/storagenode:latest
#обе ноды онлайн, всё прекрасно;
#через пару часов работы начал замечать что загрузка node stats (статы в браузере обновление страницы) занимает существенное время (около 2-5 минут), хотя отображаемые логи в Docker (в свежей версии есть dashboard в котором можно смотреть текущие операции) показывают что всё работает;
#попробовал перезагрузку, после перезагрузки - корректно, через пару часов опять лаги по 2-5 минут;
#через неделю получил сообщение о дисквалификации.
неподтвержденные мысли по теме:
- так как обе ноды используют один и тот же канал 100mbps с одинаковыми характеристиками (BANDWIDTH=“50TB”), есть предположение что происходит конкуренция, в которой одна подавляет другую, но на форуме читал что при multiple настройке и полном заполнении 1ой ноды канал делится пропорционально.
- 1я нода была ограничена на 10TB и полностью заполнена, при настройке через Docker увеличил количество места до 11,5ТБ, что могло создать конкуренцию за трафик и чего не наблюдалось за 1 год 3 мес с момента старта в single-режиме первой ноды;
- После получения дисквалификации, установил Docker версии 2.1.0.5, проблема с лагами node stats исчезла, но так же сократился и трафик у 1ой ноды в связи с дисквалификацией на 2 из 6 сателлитах;
- Возможна ли вероятность что отсутствующие/недоступные кусочки были “привязаны” к сателлиту satellite.stefan-benten.de, а требования приходили с saltlake.tardigrade.io и asia-east-1.tardigrade.io что привело к ошибкам выполнения запроса и в следствии дисквалификации?
в итоге - на данный момент обе ноды работают, дисквалифицированную собираюсь выводить через graceful exit по окончании месяца. сложносочиненные вопросы, связанные с эксплуатацией ноды написал абзацем выше.
Stefan satellite остановлен, возможно у него будет другое назначение в будущем.
может быть, особенно вместе с GET_AUDIT
Трафик делится пропорционально от каждого сателлита, поэтому и нагрузка пропорционально уменьшается, как и потребление ресурсов.
нет, а вот лаги - могли. Ещё, если место для данных было указано неверно. Docker версия создаёт папку storage в папке с данными, Windows GUI использует указанный путь. Если при переезде с Windows GUI на docker вы не перенесли данные в storage, то storagenode не найдёт данные и будет дисквалифицирована.
есть такое, структура файлов в storage и в корне папки совпадают.
было бы здорово так же добавить заметку об этом.
так же после перезагрузки машины слетает путь к identity:
Error response from daemon: invalid mount config for type “bind”: bind source path does not exist: /host_mnt/c/Users/x/AppData/Roaming/Storj/Identity/storagenode
Error response from daemon: invalid mount config for type “bind”: bind source path does not exist: /host_mnt/c/Users/x/AppData/Roaming/Storj/Identity/storagenode2
Error: failed to start containers: storagenode, storagenode2
Это указано в документации по миграции:
Это проблема с Docker desktop. Решение, как обычно, в Windows - зайти и выйти 
В данном случае:
- Остановите и удалите контейнер storagenode
- Откройте настройки Shared Drives
- Снимите все галочки
- Нажмите Apply
- Проставьте галочки обратно
- Нажмите Apply
- Предоставьте логин и пароль от Windows. Если у вашего логина нет пароля - он необходим для этой функции, иначе диски монтироваться не будут. Docker desktop монтирует диски в контейнеры через сеть.
- Запустите контейнер и убедитесь, что диски смонтировались успешно.
Я бы рекомендовал перенести identity с системного диска на диск с данными - если диск сломается, то identity без данных будет всё равно бесполезна, а так узел не стартует, если диск не доступен. В данном случае offline лучше, чем дисквалификация.