Узел всё-таки потерялся

Алексей, добрый день!
Только что получил сообщение о дисквалификации ноды на 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

на
saltlake.tardigrade.io:7777
asia-east-1.tardigrade.io:7777

Audit Score по 59.9% - т.е. всё?

На этих сателлитах, к сожалению, - да.

Где вы видите эту ошибку?
Когда запускаете 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 минут;
#через неделю получил сообщение о дисквалификации.

неподтвержденные мысли по теме:

  1. так как обе ноды используют один и тот же канал 100mbps с одинаковыми характеристиками (BANDWIDTH=“50TB”), есть предположение что происходит конкуренция, в которой одна подавляет другую, но на форуме читал что при multiple настройке и полном заполнении 1ой ноды канал делится пропорционально.
  2. 1я нода была ограничена на 10TB и полностью заполнена, при настройке через Docker увеличил количество места до 11,5ТБ, что могло создать конкуренцию за трафик и чего не наблюдалось за 1 год 3 мес с момента старта в single-режиме первой ноды;
  3. После получения дисквалификации, установил Docker версии 2.1.0.5, проблема с лагами node stats исчезла, но так же сократился и трафик у 1ой ноды в связи с дисквалификацией на 2 из 6 сателлитах;
  4. Возможна ли вероятность что отсутствующие/недоступные кусочки были “привязаны” к сателлиту 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

Это указано в документации по миграции:
https://documentation.storj.io/resources/faq/migrate-my-node/migrating-from-windows-gui-installation-to-a-docker-cli

Это проблема с Docker desktop. Решение, как обычно, в Windows - зайти и выйти :slight_smile:
В данном случае:

  1. Остановите и удалите контейнер storagenode
  2. Откройте настройки Shared Drives
  3. Снимите все галочки
  4. Нажмите Apply
  5. Проставьте галочки обратно
  6. Нажмите Apply
  7. Предоставьте логин и пароль от Windows. Если у вашего логина нет пароля - он необходим для этой функции, иначе диски монтироваться не будут. Docker desktop монтирует диски в контейнеры через сеть.
  8. Запустите контейнер и убедитесь, что диски смонтировались успешно.

Я бы рекомендовал перенести identity с системного диска на диск с данными - если диск сломается, то identity без данных будет всё равно бесполезна, а так узел не стартует, если диск не доступен. В данном случае offline лучше, чем дисквалификация.