Несколько ip адресов у ноды

Приветствую.

Есть два подключения к двум независимым провайдерам. У каждого подключения белый статический ip. Дефолтный маршрут всегда только через одного провайдера. Смена маршрута после падения одного из провайдеров происходит автоматически. Входящий трафик через каждого провайдера может достигнуть ноду через сеть любого оператора, если он не упал. Правильно ли я понимаю что при падении одного из операторов и последующей автоматической смены дефолтного маршрута в сети мне придется перезапустить контейнер ноды с указанием нового значения в переменной окружения ADDRESS? Можно ли обойтись без перезапуска контейнера, скажем, используя доменное имя в поле ADDRESS, которое всегда резолвится на оба ip адреса? Будут ли проблемы со статистикой при падении одного из операторов? Прошу прощения если вопрос задавался, но я не смог найти ничего похожего на форуме.

Спасибо.

kak 4asto padajet u vas internet, v vashem sluchae ja by zdelal 2 nody kazhduju na svojom IP.
padenije interneta na korotkii srok ne problema, esli mesjats rabotaet stabilno a potom den netu interneta tozhe vpolne mozhno perezhit.

Ну вот один линк лежит уже 12,5 часов. Это не первое падение. Собственно говоря тут вопрос не в том как часто падают и можно ли пережить не переключаясь. Ответ на этот вопрос я знаю. Можно. Вопрос как сделать так чтобы без лишних телодвижений нода не заметила отсутствия интернета. Правильно ли я понимаю вы предлагаете запускать две ноды с одним и тем же identity монтируя внутрь каждой ноды одни и те же файлы на диске? Полагаю в этом случае вторая нода вообще не запустится, т.к. не получит блокировки на файлы в которых хранится мета-информация. Но даже если и запустится вторая нода, что будет со статистикой если канал будет лежать, ну скажем неделю? Если дисквалифицируют одну ноду на упавшем канале, то дисквалифицируют и другую ноду на работающем канале. identity то у них один и тот же будет, как я понял.

net, ja predlozhil zapustit dve samostojatelnye nody, absoljutno nezavisimye, v itoge vy polu4ite vsjo v 2 raza bolshe.

У меня есть похожее соединение, и я некоторое время запускал несколько узлов без проблем. Но я использую оба шлюза. Итак, узел 1 использовал шлюз 1. Узел 2 использует шлюз 2. Это сработало для меня отлично. Преимущество для меня было в том, что я захватил двойной трафик с этой конфигурацией. Ваша проблема будет заключаться в том, что внешний IP-адрес вашей ссылки WAN изменится, когда одна ссылка выйдет из строя, и вам нужно иметь это обновление для получения трафика. Я распределяю свой риск, не заставляя все узлы использовать одну ссылку вместо этого.

Если у вас переключение происходит автоматически, и узел слушает все интерфейсы (порты в порт-маппинге указаны без IP), то и трафик будет получать тоже автоматически, и всё, что нужно, чтобы в ADDRESS был обновлённый внешний адрес.
Если не использовать DDNS или аналоги, то да - надо будет остановить и удалить контейнер, затем запустить его заново используя все ваши параметры, включая изменённый ADDRESS.
Если же вы будете использовать DDNS hostname вместо IP в ADDRESS, то пересоздавать контейнер не придётся, достаточно обновить этот DDNS hostname новым внешним адресом. Желательно, чтобы этот DDNS hostname имел как можно более короткий TTL на DNS, если вы будете использовать своё кастомное решение вместо публичных DDNS провайдеров, таких как no-ip или dyndns, …

Т.е. указание у доменного имени storj.example.com сразу двух ip адресов (один из которых может лечь) с последующем добавлением этого доменного имени в переменную ADDRESS, не прокатит. Нужно указывать один ip адрес у доменного имени и менять его например через API автоматически после смены маршрутов?

Такое будет работать, однако ресолвер будет возвращать адреса по round robin, а сателлит кэширует адрес. Вам может не повезти, когда ресолвер вернёт нерабочий и ваш узел вылетит из кэша и будет предлагаться клиентам реже, потому что он будет недоступен в 50% случаев. Online score тоже это покажет.

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