Offenbar kann sich eine einzige @Dusk -Maschine zwei Hüte aufsetzen… und ich dachte ehrlich gesagt zuerst, das klingt effizient 😭

Ich habe mir das Setup der archive-node angesehen und bin bei einer Sache hängen geblieben. Dusk empfiehlt, die Production-API-Infrastruktur getrennt von den Aufgaben des Provisioners zu halten, auch wenn dieselbe Node technisch beides machen kann.

Ich dachte die ganze Zeit: Warum? Wenn sie beide Jobs bewältigen kann, was ist das Problem?

Dann habe ich mir angesehen, was diese beiden Jobs tatsächlich brauchen.

Archive-Node: historische Indizes und API-Abfragen. Provisioner: synchron bleiben und am Konsens teilnehmen.

Okay. Bisher klingt es immer noch so, als müsste eine Maschine reichen.

Dann kam der nervige Teil.

Query-Last und Wartung können mit den Ressourcen konkurrieren, die der Provisioner für den Konsens braucht.

Also geht es nicht wirklich darum, „ob die Maschine beides laufen kann“.

Es ist eher so… was passiert, wenn eine Seite viel zu tun bekommt?

Und das hat meine Sicht ein bisschen verändert. Ich habe die Hardware gewissermaßen doppelt gezählt, weil sie technisch beide Jobs übernehmen könnte.

Aber die Ressourcen sind nicht unendlich, nur weil die Maschine zwei Rollen hat.

Vielleicht geht die Trennung also gar nicht so sehr darum, eine weitere Maschine zu brauchen.

Vielleicht geht es darum, nicht zuzulassen, dass API-Arbeit der Grund wird, warum der Provisioner ins Hintertreffen gerät.

@Dusk $DUSK #DUSK #dusk #dusk $PORTAL


Wenn eine Maschine beides übernehmen kann: Würdest du die Rollen dann trotzdem trennen?