Docker Swarm: de sterkste machines, manager of worker?

[kmf]

Ik ben een docker swarm aan het inrichten en wacht op mijn nieuwe NUC om het project in productie te brengen. Op dit moment ben ik aan het oefenen met 5 VM's met debian bullseye en docker op elk van hun.

Ik vraag me echter af nu, moeten de sterkste machines workers worden of juist managers (en ook de zwaarste taken op zich nemen)?

Mijn swarm zal bestaan uit een VM op een nuc welke dan 16 GB Ram en 4 cpu met ssd opslag aan zich toegekend krijgt.
daarnaast zijn er 3 RPi 4's, waarbij 2 van 4GB, 1 van 8 GB en 1 van 2 GB.

data wordt geshared via een nfs4 nas.

bedoeling is dat de swarm iig mqtt, node red, npm en home assistant altijd beschikbaar stellen.
load balancing wordt gedaan met de ingebouwde swarm routing mesh, met NPM als entry.
De zwaarste machine zal (dmv labels) mysql, influxdb op zich nemen. (influxdb van mijn grootte kan niet eens op een 8GB pi gestart worden)
Omdat er dan mar 1 instantie is hoop ik dat er geen concurrency problemen komen.

De vraag is dus, wordt de zwaarste nou de manager en ook de entrypoint voor mijn 443-verkeer tbv NPM? of juist de zwakkere pi's?
Eerst was mijn plan om ze allemaal manager te maken en de zwaarste met labels het zwaardere werk laten uitvoeren, maar ik kan natuurlijk ook enkel de pi's manager maken (en dus 3 managers te hebben)

Mijn oude NUC waar ik nu op test wordt een testmachine en/of proxmox backup server.

In het echte leven doet een Manager ook niet het harde werk en moet ie maar bezig houden met managen.

[Voor 6% gewijzigd door kmf op 08-01-2023 01:53]

[CAPSLOCK2000]

Ik denk niet dat er echt één juist antwoord op deze vraag is en dat veel afhangt van je workload, je resources en je beperkingen.

Maar mijn gevoel zegt dat jij die managers op de grote nodes wil draaien.

Misschen is het handig om voor jezelf een overzicht te maken van hoe groot je containers zijn. Als veel containers bv meer dan 4GB ram nodig hebben dan gaat het sowieso niet lukken op een 2gb Pi en kun je die beter als manager inzetten. Als je veel grote containers hebt die niet op de kleine nodes kunnen draaien dan moet je proberen de grote nodes zoveel mogelijk te sparen. Dan zou ik de managers op de kleine nodes draaien. Als je vooral kleine containers hebt dan zou ik de managers op de grote nodes draaien. Hoe meer RAM hoe meer ruimte er is om dingen naast elkaar te doen en een beetje handig te schuiven met geheugen zonder dat het echt invloed heeft op je workload.

Volgens mij is de overhead van een docker swarm manager echter vrij klein. Ik zou alle nodes dus manager maken, maar ik ben dan ook een geobsedeerd met "High Availability". Mijn filosofie is dat je alles in (minstens) vijfvoud nodig hebt*, dus ik zou ze allemaal nodig hebben. Vijfvoudige redundantie zullen de meeste mensen overkill vinden en niet in verhouding met wat ze willen bereiken.

Nog iets om te overwegen. Stel je even voor dat we een cluster van 2 nodes hebben, 1 dedicated manager en 1 dedicated worker en voor het gedachte-experiment doen we niet aan quorum. Stel dat 1 van die twee nodes stuk gaat. Dan heb je toch niks over. Zonder manager kan die worker niet functioneren. En de manager kan wel zonder worker draaien maar je hebt er niks aan want het gaat je om de containers die op de worker draaien. Dan heb je dus echt helemaal niks aan je cluster van 2 nodes, sterker nog, je hebt de kans dat het systeem uitvalt verdubbelt.

Maar goed, misschien geef jij wel niks om high availability en gaat het je alleen om het combineren van resources en dan kun je dit hele verhaal vergeten. Dan zou ik de manager op de grootste node draaien.


* vijfvoudig zodat je tijdens het herstellen van een probleem nog eens een fout kan maken zonder dat alles stuk gaat. Het is me al te vaak gebeurt dat ik bij het zoeken naar een oplossing voor een probleem een ander fout veroorzaak. In een systeem met 3 nodes kun je geen 2 problemen opvangen want de laatste node stopt er voor de veiligheid ook mee als die geen andere nodes meer kan zien.