Есть два подключения к двум независимым провайдерам. У каждого подключения белый статический 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 то у них один и тот же будет, как я понял.
У меня есть похожее соединение, и я некоторое время запускал несколько узлов без проблем. Но я использую оба шлюза. Итак, узел 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 должен работать нормально, но лучше чтобы он был увязан с переключателем каналов.
Если вы используете статический IP в переменной окружения ADDRESS, то при смене провайдера (и, соответственно, IP-адреса) вам, вероятно, придется перезапустить контейнер с новым значением ADDRESS. Это зависит от специфики вашего приложения и как оно обрабатывает изменение IP-адреса. Использование доменного имени вместо конкретного IP-адреса может быть более гибким решением. Если доменное имя всегда разрешается в оба IP-адреса (независимо от того, какой провайдер активен), то вам не потребуется перезапускать контейнер при смене маршрута. Однако, опять же, это может зависеть от того, как ваше приложение обрабатывает изменения адреса.
Сеть обрабатывает смену адреса довольно просто: при следующем check-in ваш узел сообщит свой новый адрес и сателлит это закеширует на какое-то время, если сможет подключиться по нему.
Если вы будете использовать DDNS адрес и обновлять его тем IP, который сейчас доступен снаружи при переключении, то всё должно быть нормально. Однако если у вас произойдёт переключение до истечения TTL в вашем DDNS адресе, то есть вероятность что сателлит получит прежний IP вашего узла.
Если же вы зарегистрируете оба IP за вашим DNS адресом, то будет как описал ранее: ваш DNS адрес будет попеременно возвращать то рабочий, то не рабочий IP, online score будет падать и ваш узел будет реже выбираться для загрузок вплоть до полной их остановки (если online score упадёт ниже 60%).
Это не “у нас”, это вообще. У вас есть одно поле для адреса, и вам необходимо сообщать сателлитам корректный IP и порт, чтобы они могли его сообщать клиентам для передачи или скачивания данных, поэтому у вас три варианта для реализации использования двух IP от разных ISP для одного узла:
Во время переключения обновлять внешний IP узла и перезапускать сервис (пересоздавать контейнер).
Во время переключения обновлять DDNS hostname текущим публичным IP, узел перезапускать тогда не придётся, если в качестве внешнего адреса будет указан DDNS hostname с портом
Использовать DNS hostname и добавить в него оба IP.
Третий вариант приведёт к 50% доступности узла, падению online score и увеличению вероятности дисквалификации кроме того, что узел будет реже выдаваться клиентам.