EL NODO DE RESPALDO PUEDE CONVERTIRSE EN LA FALLA.
Una advertencia en la documentación del provisioner de @Dusk me hizo replantearme qué significa “redundancia” para un validador.
Dusk advierte explícitamente a los operadores que no ejecuten la misma clave de consenso en varios nodos activos.
Al principio eso suena extraño.
Para una infraestructura normal, tener dos máquinas listas para hacer el mismo trabajo es exactamente lo que reduce el tiempo de inactividad.
Pero una clave de consenso es diferente.
Si dos nodos activos usan la misma identidad y terminan firmando propuestas o votos contradictorios, la propia redundancia puede convertirse en equívoco.
Y Dusk lo trata de forma muy distinta a simplemente estar desconectado.
Esto me dio una distinción que no había pensado con claridad antes:
la redundancia de infraestructura ≠ redundancia de consenso.
Un provisioner quiere un nodo de respaldo lo bastante listo como para asumir el control rápidamente.
Pero no tan activo que ambas máquinas puedan hablar, al mismo tiempo, en nombre de la misma identidad de consenso.
Eso hace que el diseño de failover sea mucho más interesante que solo “ejecuta otro servidor”.
Hay una línea muy estrecha entre:
falla un nodo → el respaldo asume el control
y
ambos nodos creen brevemente que son el firmante activo.
En el segundo caso, el sistema de seguridad puede convertirse en aquello que crea el riesgo.
La documentación de Dusk clasifica el comportamiento contradictorio de consenso como el tipo de falla que puede llevar a una penalización fuerte, incluida la quema de una parte del stake.
Así que el indicador operativo que me importaría no es simplemente el uptime del provisioner.
Querría saber con qué fiabilidad un operador puede hacer failover entre máquinas sin crear nunca una clave de consenso activo-activo.
Esa es una definición de alta disponibilidad muy distinta.
El respaldo más seguro puede ser el que esté completamente listo para firmar—
pero que nunca firme hasta que el primer nodo esté definitivamente fuera.
#dusk $DUSK @Dusk
$BTW
$HEMI
Una advertencia en la documentación del provisioner de @Dusk me hizo replantearme qué significa “redundancia” para un validador.
Dusk advierte explícitamente a los operadores que no ejecuten la misma clave de consenso en varios nodos activos.
Al principio eso suena extraño.
Para una infraestructura normal, tener dos máquinas listas para hacer el mismo trabajo es exactamente lo que reduce el tiempo de inactividad.
Pero una clave de consenso es diferente.
Si dos nodos activos usan la misma identidad y terminan firmando propuestas o votos contradictorios, la propia redundancia puede convertirse en equívoco.
Y Dusk lo trata de forma muy distinta a simplemente estar desconectado.
Esto me dio una distinción que no había pensado con claridad antes:
la redundancia de infraestructura ≠ redundancia de consenso.
Un provisioner quiere un nodo de respaldo lo bastante listo como para asumir el control rápidamente.
Pero no tan activo que ambas máquinas puedan hablar, al mismo tiempo, en nombre de la misma identidad de consenso.
Eso hace que el diseño de failover sea mucho más interesante que solo “ejecuta otro servidor”.
Hay una línea muy estrecha entre:
falla un nodo → el respaldo asume el control
y
ambos nodos creen brevemente que son el firmante activo.
En el segundo caso, el sistema de seguridad puede convertirse en aquello que crea el riesgo.
La documentación de Dusk clasifica el comportamiento contradictorio de consenso como el tipo de falla que puede llevar a una penalización fuerte, incluida la quema de una parte del stake.
Así que el indicador operativo que me importaría no es simplemente el uptime del provisioner.
Querría saber con qué fiabilidad un operador puede hacer failover entre máquinas sin crear nunca una clave de consenso activo-activo.
Esa es una definición de alta disponibilidad muy distinta.
El respaldo más seguro puede ser el que esté completamente listo para firmar—
pero que nunca firme hasta que el primer nodo esté definitivamente fuera.
#dusk $DUSK @Dusk
$BTW
$HEMI