LE NOEUD DE SAUVEGARDE PEUT DEVENIR LA FAUTE.
Un avertissement dans la documentation du provisionneur de @Dusk m’a fait repenser ce que signifie « redondance » pour un valideur.
Dusk avertit explicitement les opérateurs de ne pas utiliser la même clé de consensus sur plusieurs nœuds actifs.
Au début, cela paraît étrange.
Pour une infrastructure normale, avoir deux machines prêtes à faire le même travail est exactement ce qui réduit les temps d’arrêt.
Mais une clé de consensus, c’est différent.
Si deux nœuds actifs utilisent la même identité et finissent par signer des propositions ou des votes contradictoires, la redondance elle-même peut devenir une equivocation.
Et Dusk traite cela très différemment du simple fait d’être hors ligne.
Cela m’a permis de faire une distinction que je n’avais pas clarifiée auparavant :
redondance d’infrastructure ≠ redondance de consensus.
Un provisionneur veut un nœud de secours suffisamment prêt pour prendre le relais rapidement.
Mais pas au point d’être si actif que les deux machines puissent parler en même temps pour la même identité de consensus.
Cela rend la conception du basculement bien plus intéressante que « lancez simplement un autre serveur ».
Il existe une ligne étroite entre :
un nœud tombe en panne → le nœud de sauvegarde prend le relais
et
deux nœuds pensent brièvement qu’ils sont le signataire actif.
Dans le second cas, le système de sécurité peut devenir la source du risque.
La documentation de Dusk classe les comportements contradictoires du consensus comme un type de faute pouvant mener à une pénalité sévère, y compris en brûlant une partie de la mise.
Ainsi, la métrique opérationnelle qui m’intéresserait n’est pas simplement la disponibilité du provisionneur.
Je voudrais savoir à quel point un opérateur peut basculer de machine en machine de manière fiable, sans jamais créer une clé de consensus active-active.
C’est une définition très différente de la haute disponibilité.
Le backup le plus sûr est peut-être celui qui est entièrement prêt à signer—
mais qui ne signe jamais tant que le premier nœud n’est pas définitivement hors service.
#dusk $DUSK @Dusk
$BTW
$HEMI
Un avertissement dans la documentation du provisionneur de @Dusk m’a fait repenser ce que signifie « redondance » pour un valideur.
Dusk avertit explicitement les opérateurs de ne pas utiliser la même clé de consensus sur plusieurs nœuds actifs.
Au début, cela paraît étrange.
Pour une infrastructure normale, avoir deux machines prêtes à faire le même travail est exactement ce qui réduit les temps d’arrêt.
Mais une clé de consensus, c’est différent.
Si deux nœuds actifs utilisent la même identité et finissent par signer des propositions ou des votes contradictoires, la redondance elle-même peut devenir une equivocation.
Et Dusk traite cela très différemment du simple fait d’être hors ligne.
Cela m’a permis de faire une distinction que je n’avais pas clarifiée auparavant :
redondance d’infrastructure ≠ redondance de consensus.
Un provisionneur veut un nœud de secours suffisamment prêt pour prendre le relais rapidement.
Mais pas au point d’être si actif que les deux machines puissent parler en même temps pour la même identité de consensus.
Cela rend la conception du basculement bien plus intéressante que « lancez simplement un autre serveur ».
Il existe une ligne étroite entre :
un nœud tombe en panne → le nœud de sauvegarde prend le relais
et
deux nœuds pensent brièvement qu’ils sont le signataire actif.
Dans le second cas, le système de sécurité peut devenir la source du risque.
La documentation de Dusk classe les comportements contradictoires du consensus comme un type de faute pouvant mener à une pénalité sévère, y compris en brûlant une partie de la mise.
Ainsi, la métrique opérationnelle qui m’intéresserait n’est pas simplement la disponibilité du provisionneur.
Je voudrais savoir à quel point un opérateur peut basculer de machine en machine de manière fiable, sans jamais créer une clé de consensus active-active.
C’est une définition très différente de la haute disponibilité.
Le backup le plus sûr est peut-être celui qui est entièrement prêt à signer—
mais qui ne signe jamais tant que le premier nœud n’est pas définitivement hors service.
#dusk $DUSK @Dusk
$BTW
$HEMI