Смена IP адреса у ноды

Лайфхак, не лайфхак. В общем, вопрос. Предположим, у меня есть 3 разных ИП адреса. При этом они все находятся в разных /24 подсетях. Я запускаю 3 ноды, жду прохождения проверок и сливаю их в 1 адрес (основной). Далее использую 2 адреса для прохождения проверок, чтобы далее снова перенести на 1 адрес. С одной стороны понимаю, что в глубокой теории может сложиться так, что на эти 3 ноды попадут файлы, которые больше никуда не попадут и при выключении электричества файл может быть безвозвратно потерян.
С другой стороны - варианты ожидания верификации нод это жесть. Одна большая нода-вылетит что-то, и все. Все данные потеряны, беда. Много маленьких (предположим 1 нода на 2тб диск) - время ожидания верификации около года в текущих реалиях. За это время есть не нулевой шанс вылета одной ноды, что автоматически плюсует к времени ожидания 1 месяц и цикл замкнется.

Вопросы: можно ли пользоваться таким лайфхаком с мержем нод для “быстрой” верификации?

Po slovam @jtolio net ograni4enii skolki ip adresov u vas jest i kak imi polzovatsa. No dlja zdorovja sistemy zelatelno ne zloupotrebljat

Верификация ~ месяц, если это один узел в /24 подсети. Срок продлевается в зависимости от количества узлов. Сколько узлов - столько и месяцев в среднем.
Проверка предназначена для того, чтобы убедиться, что узел надёжен, прежде чем предоставить ему клиентские данные без ограничений.
То что вы описали - нарушение ToS и может быть использовано против вас.
Я не думаю, что кто-то будет специально это делать, но вы должны об этом знать.

@Alexey Mozhesh prokomentirovat eto togda?

Основная проблема не в том, сколько узлов за одним IP и тому подобное. А в том, что вы запускаете узлы для целей проверки на оборудовании и канале, которые потом не будут использоваться на том же канале и оборудовании. Это манипуляция результатами проверки, что является серьёзным нарушением ToS.
Я не говорю, что обязательно последуют штрафы или что-то подобное, но факт нарушения не будет считаться в вашу пользу, если вопрос возникнет.

Позвольте уточнить. Получается, если я запустил ноду в квартире 1, она прошла успешно аудиты, и начала работать как полноценная нода, проработала, предположим месяцев 5, и мне понадобилось переехать в квартиру 2, то получается, что я нарушаю ToS, т.к ip меняется и локация тоже. Далее, что если у меня динамический ip, прикрытый noip? Что значат скачки по ip адресам, возможно и по /24 подсетям для сети сторж?
И еще, правильно ли я понимаю, что исходя из рекомендаций, наилучшим вариантом для вас получается расположение нод в датацентрах с доступом к нескольким ip адресам с одной машины, или это тоже нарушение ToS? Если это не нарушение, можно ли использовать vpn для получения нескольких ip адресов на одной машине?

Могу порекомендовать не запускать все ноды одновременно. Я запускал по три штуки раз в три месяца, и пока следующие ноды проходили проверку, предыдущие уже работали в полную силу. Если есть 3 ip, то можно запускать по три ноды в месяц, и лучше равномерно распределить по всем трём ip, чтобы получить максимально возможный траффик

a vsjo ponjal, 4to noda dolzhna byt na tom zheleze i kanale na kotorom testirovalis, no 4elovek imell vidu vsego lish izmenenije vneshnego ip a ne kanala.

Я так понимаю, что если в /24 есть новые ноды, то старые могут работать в полную силу, только если уже заполнены. Что за месяц, с учетом минимального объема в 500гб, не реально.

Это другой крайний случай и он явно отличается от описанного в топике. Вы переезжаете и это нормально и никаких проблем не вызывает.
Но если вы, скажем, запустили 100 крошечных узлов, дождались их проверки и запустили их на полную сразу после прохождения проверки да ещё и на других IP, это, согласитесь, вызывает подозрения.

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

Пока вы не ставите производство проверенных узлов на поток и не продаёте их - вы будете в безопасности.

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

Узлы в одной подсети /24 делят только входящий трафик. Аудиты и исходящий трафик идут независимо.
Однако в сумме будет примерно тоже как один узел, конечно (просто потому что на узлы попадают только некоррелированные данные).
Зато несколько узлов в одной подсети позволяют распределить нагрузку (и риски) и не строить сложных конфигураций с RAID.

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

1 Like