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.

[RJVG]

@CAPSLOCK2000 Heb jij dan als HA obsesser een docker swarm van 5 of meer nodes? En hoe heb jij dan je HA storage voor elkaar?

Ben momenteel zelf aan het oriënteren hoe ik mijn heavy over kill HPE DL380 eruit kan gooien en alle services in een docker swarm kan draaien, inclusief storage. Qua CPU capaciteit heb ik tegenwoordig nog maar weinig nodig en ik ben het ook zat dat bij het kleinste hardware probleem, alles plat ligt.

Ik denk zelf aan 5 mini-achtige PC's met SSD en een 14TB HDD voor massa opslag. Middels MinIO of Gluster worden dan 5 x 14TB een grote opslag met redundancy. Ben alleen sceptisch over de maximale data transfer rates over een 1GB verbinding. Een tweede network zal wel noodzakelijk zijn.

[CAPSLOCK2000]

Thuis heb ik momenteel 3 nodes voor docker en die gebruiken CEPH als storage backend.
Het cluster was ooit vijf maar ik heb een deel van de hardware weg moeten doen wegens te oud. Professioneel heb ik ook met grotere systemen gewerkt.

Het plan is eigenlijk om het hele cluster te vervangen, maar dat plan is al meer dan een jaar in onderzoek en ik weet eerlijk gezegd niet of het nog doorgaat of dat ik op de volgende generatie hardware moet wachten. Het plan is om naar minstens 5 nodes te gaan maar misschien wel 20. Dat is allemaal een tradeoff tussen prijs, stroomverbruik, compatibility en gemak. En availability natuurlijk

CEPH is super betrouwbaar maar niet heel snel. Voor mij is het dusver goed genoeg geweest maar heel veel shared storage heb ik niet nodig in mijn docker omgeving. Laat ik er even bij zeggen dan mij CEPH draait op afgedankte draaischijven van mijn NAS en die zijn niet bepaald snel. Verder heeft mijn cluster eigenlijk te weinig ram, geen ssd-cache disks voor CEPH en geen gescheiden storage netwerk. Dat zou ik allemaal wel willen maar dat is meer voor de leuk dan dat ik het thuis echt nodig heb.

Ik heb ook nog een NAS (een SPOF) waar de echte grote dingen op staan (media). Mijn CEPH-cluster is vooral storage voor Docker volumes en VMs. De container images staan overigens in de cache op lokale, die staan dus niet op CEPH. Heel wat containers hebben niet veel meer op CEPH staan dan hun configuratie en logfiles.

Ik draai ook VMs van diezelfde storage die wel volledig in CEPH staan en die zijn merkbaar langzaam. Mijn nieuwe cluster wil ik volledig van SSD draaien en ik verwacht dat CEPH daar ook enorm van profiteert.

[ Voor 95% gewijzigd door CAPSLOCK2000 op 19-07-2023 10:26 ]

[RJVG]

Goede tip CEPH. Ik zal me daar eens meer in verdiepen. Maar ik denk dat zelfs een apart 1G netwerk voor een dergelijke storage (media, backups etc) een flinke bottle neck zal opleveren. Opschalen met een extra 2.5G lijkt me bijna een must. Dat maakt het allemaal weer extra duur en complex.

Ik ben zelf ook al een jaar aan het afwegen. Misschien dan toch wel een zuinige SPOF NAS op basis van TrueNAS of UnRaid. Of idd de volgende generatie hardware afwachten. Massa SSD opslag begint al aardig betaalbaar te worden.