Diskless image bijwerken

[Keeper of the Keys]

Is weer een tijd geleden dat ik hier ben geweest.
Op het moment ben ik aan het kijken of ik bij ons de diskless oplossing kan verbeteren en ik hoop dat er misschien iemand hier al zoiets heeft gedaan...

Het probleem dat ik op het moment graag zou willen oplossen is dat we geen goede methode hebben om onze distributie bij te werken zonder dat het mogelijk leidt tot crashes (van individuele programma's of het hele systeem) van onze Linux distributie.

Dit komt voor zover ik begrijp omdat na het bewerken van een bestand in de distro, het "niet meer bestaat" op de clients omdat hun NFS filehandle niet meer naar een bestaand object wijst.

Ik vroeg me af of iemand anders hier misschien ook zoiets heeft gedaan en dit probleem heeft opgelost....

Bij voorbaat dank.

Technisch
- PXE boot
- NFSv3 read-only root
- /etc /var met unionfs met een lokaal bestandsysteem
- /tmp, swap lokaal

[Hero of Time]

We kunnen hier nogal weinig mee. Welke distro wordt er gebruikt? Wat zit er in de PXE boot? Welke config wordt er gebruikt? Waar loop je nou precies tegenaan, wat wil je nou update? Waarom zou wat jij wilt niet werken en zijn de clients het bestand kwijt, die herstart je toch hiervoor?

Zoals je ziet, zoveel vragen, zo weinig info. Wees duidelijk en volledig, we kunnen niet in je omgeving kijken.

[Keeper of the Keys]

Sorry daarvoor.
Dit komt deels omdat dit tot nu toe vooral door een van mijn collegas werd gedaan.

Hier is wat ik kan beantwoorden:
Distro: Debian (meeste 64bit, maar we hebben geloof ik ook nog hier en daar 32bit, we hebben nieuwe en oude "distros")
PXE boot laadt geloof ik syslinux (via tftp), die mount op zijn beurt de relevante NFS boom.
Welke config van wat?

Alle clients mounten hun root image read-only, het root-image kan alleen worden bijgewerkt vanaf een specifiek station.

Het probleem voor zover ik het heb begrepen is dat als een programma wordt bijgewerkt en het draait op een client het zal crashen, voor individuele programma's is dat vervelend maar verder geen ramp.
Maar als we het gaan hebben over dingen als libc wordt het plotseling heel vervelend en kan het betekenen dat we langs elk station moeten gaan om ze te power-cyclen omdat halt/reboot/etc niet meer werken...

/Edit:
De reden dat ik er nu een beetje naar aan het kijken ben is dat problemen met UEFI en PXE misschien een andere boot-strategie vereisen en ik daarom dacht laten we meteen maar eens kijken of we dan wat oude problemen uit de wereld kunnen helpen.

NFS servers draaien freebsd maar dat is denk ik minder relevant.

[ Voor 21% gewijzigd door Keeper of the Keys op 28-07-2014 21:06 ]

[Hero of Time]

Als het enige probleem een power cycle is van de clients, zie ik geen enkele reden om geen update toe te passen. Hiervoor heb je een maintenance window, een tijd waarin je onderhoud aan je servers e.d. kan plegen. Als je clients nog een beetje modern zijn, kan je ze van afstand beheren met reboot en scheduled shutdown/power on. WoL is ook een leuke techniek hiervoor.

Ik zie dit eerder in een uitermate geschikt moment om de oplossing die je hier hebt draaien eens goed onder handen te nemen zodat beheer er ook daadwerkelijk mogelijk mee is. Nu is het blijkbaar slecht geregeld of slecht gedocumenteerd dat je hier moet vragen voor een oplossing.

Trouwens, waar is de verantwoordelijke collega nu dan? Zaterdag met 't vliegtuig naar Verweggistan voor 3 weken en je moet 't voor 't eind van deze week hebben uitgevoerd?

[Rainmaker]

Hmm, zo op het 1e gezicht grappig opgezet.

Wat mogelijk helpt is om voor de update een shutdown -r -t+10 uit te voeren op de werkstations.

Als de binary eenmaal in geheugen geladen is, zou er geen call meer naar het FS moeten gaan, dus heb je ook geen stale filehandles.
Voor het uitvoeren daarvan iets als dsh gebruiken.

[Keeper of the Keys]

Wij zijn een universiteit en de werkstations van de studenten/onderzoekers moeten het liefst zo min mogelijk downtime hebben, waardoor onze maintainence window bijna niet bestaat.

Mijn collega is gelukkig nog niet aan het plannen om weg te gaan maar een van de redenen dat onze distro slechts 1 keer per jaar wordt bijgewerkt (en daarna is Debian[/testing/sid/experimental mix] bevroren op het dat punt in tijd) is dit, daarnaast willen we onze gebruikers niet te vaak dwingen hun programma's tegen nieuwe libs te compileren, maar ik zou heel graag toch in elk geval de beveiligings updates wat regelmatiger door te voeren evt. door naar een distro te switchen die een (half-)jaarlijkse freeze doet en daar wel beveiligings updates voor blijft voorzien.

Daarom wilde ik even pollen of er nog andere mensen waren die ook dit soort oplossingen gebruiken en of zijn hier wel omheen kwamen.

[CAPSLOCK2000]

Zolang je 1 NFS-export voor alles hebt zie ik geen mogelijkheid om het goed te doen. Ik zou het systeem aanpassen zodat je clients niet '/export' mounten maar '/export/debian-stable-20140729/' . Die namen zijn uiteraard maar een voorbeeld.

Vervolgens zorg maak je een nieuw mountpoint aan waar de bijgewerkte versie van je OS staat. Als je fileysteem snapshots ondersteunt kan dat makkelijk en snel. De werkwijze wordt dan.
1. update je systeem
2. maak een nieuwe export-directory (bv met een snapshot)
3. test de nieuwe versie
4. pas het image aan dat je clients gebruiken zodat het nieuwe mountpoint wordt gebruikt

Draaiende clients blijven dan de oude export gebruiken en bij de volgende boot krijgen ze automatisch het nieuwe systeem. Rebooten zal echter nodig blijven.

Software updaten zonder dat draaiende software in de problemen komt lukt niet. Meestal gaat het goed, vooral als je alle software die je wil gebruiken al geladen hebt waardoor je op je eigen desktop er makkelijk mee wegkomt. Maar vroeg of laat gaat het fout en als je het over veel systemen hebt wordt die kans steeds groter.

Ok, in theorie kun je alles statisch linken maar daar wordt je ook niet vrolijk van.

[Keeper of the Keys]

Op zich hebben we wel ongeveer dat, maar dan op een (half-)jaarlijkse basis.

Ik zat zelf nog te denken dat als het FS een copy-on-write (ZFS/btrfs) systeem is waarbij de netwerk-mount op de een of andere manier zou kunnen specificeren welke tijd ze mounten deze hele operatie misschien ook bergen makkelijker zou worden, de lab stations doen eens per week een reboot via hun OS (dus als het crasht zitten ze nog wel vast), en dan zouden ze dus in een keer door zijn naar het volgende checkpoint....

[_JGC_]

Persoonlijk zou ik geen root on NFS draaien, maar met Network Block Device. Dan serveer je gewoon een ext4 filesystem of desnoods btrfs met compressie via TCP, wat een flink stuk sneller werkt dan NFS. Op de NBD-server gebruik je vervolgens copy-on-write zodat je clients gewoon R/W kunnen doen.

Updaten wordt alleen lastiger, je zult op een of andere manier de oude image moeten laten staan, nieuwe image ernaast en vervolgens de clients rebooten. Als alle clients een reboot gehad hebben kan je de oude image weggooien.

[Hero of Time]

Updaten is helemaal niet zo lastig. Je hebt tenslotte een PXE boot en je hoeft alleen maar de config van de PXE server iets aan te passen om naar de nieuwe image te verwijzen. Clients die al draaien hebben er geen last van, maar zodra ze rebooten krijgen ze gelijk de nieuwe config en booten van het nieuwe image. Je maakt dan 2 configs aan, een voor de werkende omgeving en een voor de nieuwe release, Die wisselt dan telkens als je een nieuwe release gaat doen (of eigenlijk schuift 't telkens op, of wat je ook maar implementeert).

[Keeper of the Keys]

Het dupliceren van een image is behoorlijk tijd rovend en wordt niet gezien als relevant voor wekelijkse updates, maar misschien heb je gelijk en is het een kwestie van een andere benadering van de boot images.

[CAPSLOCK2000]

Waar gaat die tijd in zitten? Als je het goed opzet zou het nauwelijks tijd moeten kosten.

[Keeper of the Keys]

Toen ik voor test doeleinden de hele image kopieerde duurde dat uren, uiteraard hoef ik daar niet de hele tijd bij te zitten, maar het blijft extra load op de filer etc.

Uit discussies hier blijkt een van de grotere factoren te zijn dat we dezelfde image op desktops en op servers gebruiken, en daarnaast dat slechts een deel van onze desktops een wekelijkse reboot doet (de "open space" computers, persoonlijke stations doen dit niet), uiteraard is regelmatig rebooten voor servers überhaupt problematisch.

Ik blijf nadenken over een oplossing en als we ooit tot iets goeds komen zal ik het zeker ook hier proberen te delen, we gebruiken hier ook lustre voor onze reken-clusters en misschien zou dat een oplossing kunnen vormen voor onze linux distros (maar niet freebsd/os x), ik moet gaan testen wat er gebeurt op lustre als een library die in gebruik is door programma X op node 1 wordt gewisseld door node 2...

Hoe dan ook iedereen bedankt voor het meedenken!

[CAPSLOCK2000]

Je wil eigenlijk een systeem hebben waarbij kopieren goedkoop is. ZFS en BTRFS kunnen op filesysteem-niveau snapshots maken die heel snel en licht zijn. LVM kan het op blockdevice niveau doen. De betere filers hebben hier ook een oplossing voor.

Enne, ik wil niet de betweter uithangen, maar als het rebooten van servers een probleem is dan is dat een indicatie dat er iets niet goed geregeld is. Als het zo belangrijk is dat je niet zonder kan dan zou je er twee moeten hebben. Anders kom je nog eens zwaar in de problemen als er een storing is.

[Keeper of the Keys]

Voor de meeste servers is het inderdaad geen ramp als ze worden gereboot als het gaat over services etc. het probleem zit hem in het feit dat veel 'servers' gebruikt worden als wat vroeger een time-sharing machine was, dus mensen hebben er soms allerlei langlopende taken op draaien, intensieve berekeningen (op de clusters) of gewoon simpelweg een openstaande emacs/vi/nano/whatever sessie, dus voor gebruikers die op de machines zitten zou het heel vervelend zijn als we de frequentie van reboots verhogen.

Uiteraard kun je het aankondigen etc. maar het blijft een flink ongemak.

[Hero of Time]

Bij m'n vorige werkgever hebben ze een terminal server en hier deed ik elke maand op de vrijdag na Patch Tuesday updates installeren en de server rebooten. Er was goed doorgegeven dat iedereen op vrijdag (elke vrijdag!) moest afmelden. Eventuele documenten of andere zaken die ze open lieten staan en de volgende maandag kwijt waren, was hun eigen schuld.

Sowieso moet je je gebruikers goed duidelijk maken om documenten e.d. tijdig op te slaan en geen sessies (of zo min mogelijk) open laten want hoewel je een UPS kan hebben, is er geen garantie wat er gebeurt als de stroom uitvalt of iets anders gebeurt met de machine en 't ding spontaan reboot of uitvalt. Nu zijn ze gewend dat 't 24x7 beschikbaar is en dat is geen goede mentaliteit. Zodra er dan wat is, gaan de gebruikers massaal klagen, terwijl als je 't duidelijk aan hebt gegeven, ze niets kunnen beginnen. Ze zullen alsnog gaan klagen, maar doen dat dan maar tegen een dichte deur, niet een die je op een kier hebt laten staan zoals nu.