Très bonne information
Publier
CR Insights
·
--
Apparemment, une machine @Dusk peut porter deux chapeaux… et honnêtement, je trouvais ça efficace au début 😭
Je regardais la configuration du nœud archive et je me suis bloqué sur un point. Dusk recommande de garder l’infrastructure d’API de production séparée des tâches du provisioner, même si le même nœud peut techniquement faire les deux.
Je n’ai cessé de me dire : pourquoi ? S’il peut gérer les deux, quel est le problème ?
Puis j’ai regardé ce dont ces deux tâches ont réellement besoin.
Nœud archive : index historiques et requêtes API. Provisioner : rester synchronisé et participer au consensus.
D’accord. Pour l’instant, ça ressemble quand même à une machine unique qui devrait suffire.
Et puis le détail agaçant est apparu.
La charge des requêtes et la maintenance peuvent entrer en compétition avec les ressources dont le provisioner a besoin pour le consensus.
Donc ce n’est pas vraiment “est-ce que la machine peut faire les deux ?”
C’est plutôt… que se passe-t-il quand un côté devient surchargé ?
Et ça a un peu changé ma façon de penser. Je comptais le matériel deux fois parce que, techniquement, il pouvait faire les deux tâches.
Mais les ressources ne sont pas infinies juste parce que la machine a deux rôles.
Peut-être que la séparation ne consiste pas vraiment à devoir avoir une autre machine.
Peut-être qu’il s’agit plutôt de ne pas laisser le travail des API devenir ce qui gêne le provisioner.
@Dusk $DUSK #DUSK #dusk #dusk $PORTAL
Si une seule machine peut faire les deux, est-ce que tu séparerais quand même les rôles ?
Je regardais la configuration du nœud archive et je me suis bloqué sur un point. Dusk recommande de garder l’infrastructure d’API de production séparée des tâches du provisioner, même si le même nœud peut techniquement faire les deux.
Je n’ai cessé de me dire : pourquoi ? S’il peut gérer les deux, quel est le problème ?
Puis j’ai regardé ce dont ces deux tâches ont réellement besoin.
Nœud archive : index historiques et requêtes API. Provisioner : rester synchronisé et participer au consensus.
D’accord. Pour l’instant, ça ressemble quand même à une machine unique qui devrait suffire.
Et puis le détail agaçant est apparu.
La charge des requêtes et la maintenance peuvent entrer en compétition avec les ressources dont le provisioner a besoin pour le consensus.
Donc ce n’est pas vraiment “est-ce que la machine peut faire les deux ?”
C’est plutôt… que se passe-t-il quand un côté devient surchargé ?
Et ça a un peu changé ma façon de penser. Je comptais le matériel deux fois parce que, techniquement, il pouvait faire les deux tâches.
Mais les ressources ne sont pas infinies juste parce que la machine a deux rôles.
Peut-être que la séparation ne consiste pas vraiment à devoir avoir une autre machine.
Peut-être qu’il s’agit plutôt de ne pas laisser le travail des API devenir ce qui gêne le provisioner.
@Dusk $DUSK #DUSK #dusk #dusk $PORTAL
Si une seule machine peut faire les deux, est-ce que tu séparerais quand même les rôles ?
Avertissement : ce contenu inclut des opinions de tiers. Il ne constitue pas un conseil. Binance Ai peut être utilisée, sans garantie de résultat. Consultez les CG.