Toon posts:

Docker Swarm: de sterkste machines, manager of worker?

Pagina: 1
Acties:

Vraag


  • kmf
  • Registratie: November 2000
  • Niet online
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. 8)

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

One thing's certain: the iPad seriously increases toilet time.

Alle reacties


  • CAPSLOCK2000
  • Registratie: Februari 2003
  • Laatst online: 22:22

CAPSLOCK2000

zie teletekst pagina 888

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.

This post is warranted for the full amount you paid me for it.



Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee