Эксперимент с backup-нодой


Появилась идея сделать backup-ноду, чтоб в случае падения основной ноды, на лету переключать генерацию блоков на резервный сервер.

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

Алгоритм действий

Что я сделал?

Имея активную ноду (я в данный момент активный делегат) я запустил еще одну ноду на отдельном сервере, в cli_wallet сделал import_key от своего аккаунта xtar, сгенерировал с помощью команды suggest_brain_key новый набор ключей и прописал private brain key в config.ini.

После запуска golosd начал периодически выдавать резонное сообщение

Not producing block for xtar because I don't have the private key for GLS6rfMKdTTd...

Сделал update_witness с новым ключом (brain public key резервного сервера). Словил 1 missed блок, после чего резервный сервер успешно начал генерировать блоки.

Сделал update_witness с ключем от основного сервера, missed не словил и генерация успешно переключилась на основную ноду.

Итоги и вопрос

У меня получилось на лету переключать активного витнесса с ноды на ноду.

Вопрос. В вики указано:
Вы не должны заводить ноду свидетеля с той же учетной записью, your-account-name, на более чем одну систему steemd. Если это произойдет, то обе системы steemd произведут блок одновременно. Другие узлы сети увидят это двойное подписание и представят доказательство в сеть, что позволит им претендовать на остаток средств на вашей учетной записи.

Хотел уточнить. Мне крупно повезло или речь идет о двух нодах с идентичным набором brain-ключей?

Можно ли действовать по данному алгоритму? Или это чревато последствиями?


Comments 10


Единственный нюанс, насколько я понимаю, шаг с import_key был совершенно не нужен. suggest_brain_key просто создает набор ключей от балды никак не связаных с имеющимися или импортироваными ключами. В остальном все ок, правда не понятно почему потерялся блок - но возможно просто реально нужно сразу после генерации блока делать, что-бы успело принять блок с изменением ид ибо видимо если прям перед созданием блока переключиться происходит его потеря.

24.10.2016 10:43
0

шаг с import_key был совершенно не нужен

Почему это не нужен? Иначе он не смог бы в cli_wallet вводить команды своего аккаунта xtar.
Т.е. если надо будет переключиться, он не сможет сделать update_witness

24.10.2016 10:52
0

В этом плане да, но кстати интересно где правильнее посылать команду на смену ключа - не резервном сервере или на текущем? По логике быстрее должно сработать на резервном.

24.10.2016 15:16
0

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

24.10.2016 23:28
0

Или на любом другом если их еще больше - может отдельный сервер заниматься мониторингом всех остальных - там можно сделать более надежно.

25.10.2016 09:19
0

Блок потерялся в момент между тем, когда я отправил update_witness и ожиданием ответа от сервера.

24.10.2016 11:20
0

Я правильно понимаю, что при этом посылал команду на смену ключа ты на резервном сервере?

24.10.2016 15:17
0

Да, на резервном.

24.10.2016 16:26
0

Я так понимаю, что речь идет о двух нодах с одинаковыми ключами, т.е. если ты использовал два разных ключа, то просто выключил одну ноду и включил другую.

24.10.2016 10:48
0

Тогда в Вики надо так и написать. Сейчас там только про your-account-name.

24.10.2016 11:16
0

Но получается, что если основной сервер падает, то надо делать update_witness для переключения на резервный. Можно ли как-то автоматизировать переключение?

24.10.2016 15:23
0

Да, возможно сделать скрипт.

24.10.2016 16:26
0

В принципе уже есть готовые скрипты от @jesta - но не очень легко настраиваемые:
https://github.com/aaroncox/witness-failover

25.10.2016 09:21
0