Node is Disqualified after migrate on docker

Здравствуйте. Ситуация такая. Нода 1hc2BBabDQtNM4zri4P6ZC3f5yGbn9PV6U59U4M5S8YS2wUbcP работала около полугода. Набрала около 100 долларов в удержании. У сервера сломался процессор. Не было возможности заменить сразу, поэтому несколько дней она простояла в офлайне. Дальше выявились проблемы и с материнской платой, потому я решил перенести данные временно на другую машина. Первая машина работала через GUI на виндоус, на вторую был поставлен docker, и когда я указал путь до данных, я полагал, что нужно указать такой же как в GUI, и получил дисквалификацию… Тут на форуме я нашёл в чем причина. Указал правильную папку. Но я теперь в бане. Что мне теперь делать? Весь отработанный результат просто получился впустую?

Я привёл ноду к состоянию, когда она видит старые данные, но по некоторым спутникам (не по всем) я получил бан. Есть возможность его снять?

Дисквалификация является постоянной и не может быть отменена. Вам придется начинать с нуля, поскольку вы дисквалифицированы с 4 из 6 спутников. Вы не можете изящно выйти из 2 спутников, потому что ваш узел будет слишком молод (менее 6 месяцев) на этих спутниках.

Ну нет) Для чего начинать заново, если в случае чрезвычайного происшествия (а на длительной отрезке времени это неизбежно) все снова обнулится без должного взаимодействия со стороны администрации. Тем не менее спасибо за быстрый ответ.

К сожалению я могу только подтвердить слова @nerdatwork, дисквалификация постоянная и сбросу не подлежит.
У вас два варианта: держать эту ноду онлайн для спутников, где она ещё не дисквалифицирована или начать с новой identity и чистым storage.
Graceful Exit возможен только после 15 месяцев в сети (временно снижен до 6 месяцев), так что с остальных двух можно будет выйти только на ту дату, которую покажет storagenode, когда вы попытаетесь выйти: Graceful Exit Guide

Если решите оставить эту ноду - вы можете удалить папки из blobs для дисквалифицировавших сателлитов:

Спасибо за информацию и оказанное внимание. Ситуация ясна, но факт того, что при абсолютном намерении держать ноду в долгосрок и при поломке оборудования или человеческой ошибке (в моем случае комбинация факторов, но разное вложение по папкам крайне не ожидаемый момент), система лишает меня большей части наработанного прогресса за полгода ($93 of $100) без возможности регуляции административным путем огорчает.

ps: И за ссылки спасибо.

Я прекрасно вас понимаю, я сам SNO.
Сателлит не имеет никакой практической возможности убедиться, что все данные на месте. Проверить все данные займёт очень много времени. Для сети дешевле восстановить все данные целиком, чем проводить дорогостоящий (как по деньгам, так и по времени) аудит всех данных.
Можете прочитать обсуждение здесь:

Можно было бы пойти от противного. Ваш софт умеет определять отсутствия данных. Если человек подаёт ручным способом запрос, что данные восстановлены, допустить, что это так, убрать из бан листа. И если по факту это нет так, cистема снова его дисквалифицирует. Бесконечно такие запросы человеку нет смысла отправлять (можно например сделать ограничение по количеству), а в единичных случаях это может помочь.

Если вопрос встанет в несправедливой оплате, можно сделать испытательный срок проверки восстановленных данных (или не срок, а количество раз успешных ответов ноды), если за этот срок систему устраивала доступность данных по хранилищу, значит оно признаётся адекватным. У человека остаётся стимул следить за нодой, чтобы не попасть в такой режим.

В любом случае полное безоговорочное исключение из системы, когда по факту у тебя на руках остались данные, крайне демотивирует (особенно когда прогресс скапливался не один месяц, и в моем случае данные лежали просто не в той папке и я не понял этого сразу). Но вот если ты потерял целостность данных, дисквалификация хоть и печалит, но справедлива. Адекватной схемой проверки было бы до 3 раз дисквалификации подряд за короткой срок. Один раз может быть случайность, два - совпадение, три закономерность.

Мое дело просто выказать мысли, решать Вам.

1 Like

Система его дисквалифицирует если обнаружит подряд проваленные аудиты. Так как сателлит использует вероятностную модель при проверке данных, то таким методом нельзя быть уверенным на 100% после дисквалификации, что данные не повреждены. Разумеется, это выяснится, когда клиент захочет загрузить свои данные обратно, но может быть слишком поздно - если количество кусочков снизится до минимального уровня 29 и ваш узел будет содержать как раз последний, 29 кусочек - клиент не сможет больше загрузить файл.
Сателлит никогда не пойдёт на риск потери клиентских данных.

Как я уже говорил, для сети дешевле пометить все ваши данные как потерянные после дисквалификации и восстановить их, когда понадобится (когда количество неповреждённых кусочков снизится до 35). Сателлит должен скачать 35 кусочков, реконструировать 45 кусочков и распределить их по сети. Скачивание этих 35 кусочков должно быть оплачено операторам. Где деньги взять? Из held amount вашего узла (и других узлов, кто тоже потерял кусочки)

Даже если теоретически убрать статус дисквалификации с вашего узла, это означает:

  • репутация должна быть обнулена. Ваш узел должен начать с проверки снова (5% потенциального трафика, пока не пройдёт 100 аудитов ~ месяц)
  • held amount истрачено на восстановление, то есть = 0 и начинать опять собирать held amount, значит начинать с 75% удержаний;
  • так как сеть считает кусочки на вашем узле потерянными, за них сателлит не будет платить, Garbage Collector удалит их с вашего узла, но медленно - недели. Всё это время вы не будете получать выплату за занятое место, так как на сателлите информации о нём больше нет.

Это ровно то же самое, как начать с нового узла, но с медленной очисткой места.

Сейчас разработан новый режим suspension, в него узел помещается, когда отвечает неожиданной ошибкой на запрос аудита. В этом режиме узел перестаёт получать данные и имеющиеся данные помечаются как возможно недоступные, то есть он не выбирается и для скачиваний тоже. Тут почти та же самая вероятность срабатывания триггера восстановления, и практически те же самые последствия для узла - падение репутации, удаление данных, а через неделю (пока столько по дизайну) - дисквалификация.

Однако если узел ответил на аудит известной ошибкой (нет данных, повреждённый кусочек) - аудит считается проваленным сразу же. Если несколько подряд - очень быстро снижается Audit score, и когда падает ниже 0.6 - узел дисквалифицируется.

К сожалению, пустая папка для хранения означает как раз последний случай - данных нет. У узла нет никакой возможности выяснить - были ли у него данные раньше, так как вся информация в базах данных, а они тоже должны быть в папке с данными, которая оказалась пустой. Сателлит тоже не может использовать память что раньше узел был надёжным, потому что теперь - перестал.

Помещать все проваливающие аудиты узлы в suspension - очень рискованно для клиентских данных и дорого для восстановления - потому что если сработает триггер, деньги будут использоваться из held amount только дисквалифицированных узлов, остальное придётся платить оператору сателлита из своего кармана.

Хотя можете проголосовать тут:

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

Спасибо за развёрнутый ответ. А что происходит, когда много нод по конкретным данным уходят в suspension? Начинается дублирования из имеющихся? Если так, кто это оплачивает? И что будет, если suspended ноды возвращаются? Получается данные имеют количество копий больше нормы.

Триггер на восстановление данных работает независимо от сервиса аудита. Если количество “здоровых” кусочков упадёт до 35, он сработает автоматически и создаст job для восстановления.
Процедуру восстановления я описал раньше. Можно прочитать детальнее в блоге

Сателлит оплачивает услуги Операторов узлов по восстановлению данных. Так как в suspension не предусмотрено уменьшение held amount узла в suspension, то это происходит за счёт оператора сателлита. Когда узел станет доступен, он потеряет те данные, что были восстановлены другими узлами. Чем дольше узел в suspension - тем больше данных и репутации он потеряет.
Если suspended узел успешно проходит аудиты - он переводится в нормальный режим, его данные больше не помечены как временно недоступные, за исключением тех, что уже восстановлены. О неоплачиваемых данных позаботится Garbage Collector.

Желательно, чтобы оператор узла починил свой узел как можно быстрее, на это сателлитами Tardigrade ему даётся неделя, а затем наступает дисквалификация.
Это сокращает вероятность того, что наступит момент когда сработает триггер, а узел ещё не в строю, и оператору сателлита придётся платить из своего кармана.
Как понятно из описания, оператору сателлита это не выгодно. Так что grace период зависит полностью от оператора сателлита. Сателлиты Tardigrade предоставляют в настоящий момент неделю. Другие сателлиты могут предоставлять свои варианты.

1 Like