РЕЗЕРВНЫЙ УЗЕЛ МОЖЕТ СТАТЬ ИСТОЧНИКОМ НЕИСПРАВНОСТИ.
Одно предупреждение в документации provisioner для @Dusk заставило меня пересмотреть то, что для валидатора означает «резервирование».
Dusk прямо предупреждает операторов не использовать один и тот же ключ консенсуса на нескольких активных узлах.
Сначала это звучит странно.
Для обычной инфраструктуры наличие двух машин, готовых выполнять одну и ту же работу, — это как раз то, что помогает снизить простой.
Но ключ консенсуса — это другое.
Если два активных узла используют одну и ту же идентичность и в итоге подписывают конфликтующие предложения или голоса, само по себе резервирование может превратиться в эквивокацию.
И Dusk рассматривает это совершенно иначе, чем просто быть офлайн.
Так я получил чёткое различие, о котором раньше не думал:
резервирование инфраструктуры ≠ резервирование консенсуса.
Provisioner хочет, чтобы резервный узел был достаточно готов, чтобы быстро взять управление.
Но не настолько активным, чтобы обе машины могли одновременно выступать от имени одной и той же консенсус-идентичности.
Из-за этого проектирование аварийного переключения становится гораздо интереснее, чем просто «запустить ещё один сервер».
Есть узкая грань между:
узел выходит из строя → резервный узел вступает в работу
и
обе машины ненадолго считают себя активным подписантом.
Во втором случае система безопасности может стать тем самым фактором, который создаёт риск.
Документация Dusk классифицирует конфликтующее поведение консенсуса как тип неисправности, способный привести к жёсткому штрафу, включая сжигание части стейка.
Поэтому операционным показателем, о котором я бы заботился, является не просто доступность provisioner.
Мне нужно понимать, насколько надёжно оператор может выполнить аварийное переключение между машинами, не создавая при этом актив-актив ключ консенсуса.
Это совсем другое определение высокой доступности.
Самый безопасный резерв может быть тот, который полностью готов подписывать —
но который никогда не подписывает, пока первый узел не исчезнет окончательно.
#dusk $DUSK @Dusk
$BTW
$HEMI
Одно предупреждение в документации provisioner для @Dusk заставило меня пересмотреть то, что для валидатора означает «резервирование».
Dusk прямо предупреждает операторов не использовать один и тот же ключ консенсуса на нескольких активных узлах.
Сначала это звучит странно.
Для обычной инфраструктуры наличие двух машин, готовых выполнять одну и ту же работу, — это как раз то, что помогает снизить простой.
Но ключ консенсуса — это другое.
Если два активных узла используют одну и ту же идентичность и в итоге подписывают конфликтующие предложения или голоса, само по себе резервирование может превратиться в эквивокацию.
И Dusk рассматривает это совершенно иначе, чем просто быть офлайн.
Так я получил чёткое различие, о котором раньше не думал:
резервирование инфраструктуры ≠ резервирование консенсуса.
Provisioner хочет, чтобы резервный узел был достаточно готов, чтобы быстро взять управление.
Но не настолько активным, чтобы обе машины могли одновременно выступать от имени одной и той же консенсус-идентичности.
Из-за этого проектирование аварийного переключения становится гораздо интереснее, чем просто «запустить ещё один сервер».
Есть узкая грань между:
узел выходит из строя → резервный узел вступает в работу
и
обе машины ненадолго считают себя активным подписантом.
Во втором случае система безопасности может стать тем самым фактором, который создаёт риск.
Документация Dusk классифицирует конфликтующее поведение консенсуса как тип неисправности, способный привести к жёсткому штрафу, включая сжигание части стейка.
Поэтому операционным показателем, о котором я бы заботился, является не просто доступность provisioner.
Мне нужно понимать, насколько надёжно оператор может выполнить аварийное переключение между машинами, не создавая при этом актив-актив ключ консенсуса.
Это совсем другое определение высокой доступности.
Самый безопасный резерв может быть тот, который полностью готов подписывать —
но который никогда не подписывает, пока первый узел не исчезнет окончательно.
#dusk $DUSK @Dusk
$BTW
$HEMI