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

Я пытался перенести свою сеть Hyperledger Fabric (с запущенной службой заказов RAFT) с одного хоста на другой.

В этом процессе я следил за соблюдением связи TLS, а это означает, что я внес необходимые изменения в системный канал перед процессом миграции. Я использовал блок резервного копирования и создания (старой службы заказов) для восстановления сети на целевом хосте. Одна новая вещь, которую я обнаружил, заключалась в том, что когда узлы-заказчики запускались на новом хосте, им потребовалось 10 minutes, чтобы синхронизировать блоки и начать выборы RAFT.

Возникает вопрос: настроено ли это время по умолчанию в кодовой базе заказчика или это какая-то другая функция?

ПРИМЕЧАНИЕ. Я знаю, что добавление существующего узла заказчика в некоторый канал приложения по умолчанию занимает 5 минут, чтобы заказчик обнаружил изменение. Итак, вышеупомянутая ситуация чем-то похожа на эту или это другая возможность?

Полные журналы узла заказов (тот, который был запущен первым на новом хосте) можно найти здесь.


hyperledger-fabric raft
person Chintan Rajvir    schedule 05.05.2020    source источник
comment
вы можете прикрепить логи?   -  person yacovm    schedule 06.05.2020
comment
@yacovm Я добавил необходимые логи. Узел запускается в 14:25:44 (UTC), а репликация блока начинается после 14:35:44 (UTC). Разместите репликацию блока, в 14:36:09 (UTC) мы получим вывод для нашего лидера в системном канале. В 14:36:12 получаем лидера РАФ для нашего канала приложения. В течение первых 10 минут я не могу получить блоки каналов от имени заказчиков. Это вызовет SERVICE_UNAVAILABLE.   -  person Chintan Rajvir    schedule 07.05.2020

Ответы (1)


arrow_upward
1
arrow_downward

Подозрение о выселении - это механизм, который срабатывает после тайм-аут по умолчанию - 10 минут.

person yacovm    schedule 07.05.2020
comment
Прохладный! Понял. Но при миграции я переключаю сертификаты O3 TLS, затем сертификаты O2 в каналах источника. Затем я запускаю O2 и O3 на цели (новые хосты TLS). В идеале, поскольку O2 будет впереди в блоках и также будет иметь информацию о новой конечной точке O3, он должен иметь возможность общаться с O3 сразу. Подозрение на выселение может возникнуть, если ни один из двух заказчиков ничего не знает о другом. Пожалуйста, поправьте меня, если это неправильное понимание! - person Chintan Rajvir; 07.05.2020
comment
Узел подозревает, что его канал вытеснен, когда он не знает ни о каком избранном лидере и не может быть избран лидером на канале. В соответствии с этим, если мы посмотрим в глаза O3, он не знает новую конечную точку O2, но O2 будет знать новую конечную точку O3. Итак, при связи с O2, не будут ли блоки сразу же реплицированы? Если нет, то почему через 10 минут O3 начинает понимать, что может достичь новой конечной точки O2? - person Chintan Rajvir; 07.05.2020
comment
Поскольку он не зондирует сразу, он зондирует только через 10 мин. - person yacovm; 07.05.2020
comment
Я понимаю, что таким образом O2 пытается начать выборы, как только они начнутся (аналогично O3). Но O3 не знает о конечной точке O2 (при условии, что он попытается отправить сообщение голосования на конечную точку, как видно в канале И не напрямую в ответ на сообщение recvd от O2). Это приводит к подозрению на выселение через 10 мин. Почему через 10 минут O3 может связаться с новой конечной точкой O2 (хотя он не получил последний блок, имеющий эту новую конечную точку O2)? Теперь он пытается связаться с O2 по URI, с которого он уже получил сообщения о голосовании (вместо того, чтобы зацикливаться на канале)? - person Chintan Rajvir; 07.05.2020
comment
Я нашел причину этой проблемы. Подозрение на выселение возникает из-за того, что O1 был лидером в кластере RAFT на исходном хосте. Во время переключения на цель обновления конфигурации требовали запуска O2 и O3. Это привело к подозрению о выселении через 10 минут, что в дальнейшем побудило O2 и O3 общаться, в результате чего O2 выиграл выборы из-за более высокого срока. - person Chintan Rajvir; 08.05.2020