Onderwerp: kernelcare.com, wat vinden jullie hiervan? Is net released.

Oorspronkelijk geplaatst door Paulewk

Als je structureel 'slechte ervaringen hebt met reboots' zit je systeem niet goed in elkaar.

Ik ken systemen die wel degelijk goed in elkaar zitten, maar waar een update van raid driver of nic driver voor heel wat problemen kan zorgen. Zo heb ik al een paar keer meegemaakt dat de kernel na een update en reboot even zelf besliste om de eth0 om te zetten naar eth1 en de eth1 naar eth0 etc. Of dat na een reboot plots je raid controller driver niet meer werkt zoals het hoort.

En zoals @visser ook al aanhaalt ken ik bedrijven waar de server zelf wel binnen een minuut opgestart is, maar waar het opstarten van de services en de verwerking ervan 30 minuten in beslag neemt. En je kan alles wel zo redundant maken als mogelijk, maar in sommige situaties helpt dat niet.

Toch zie ik het niet zo'n vaart lopen. Alhoewel er genoeg redenen zijn waarom je niet midden op de dag als mensen aan het werk zijn, de server gaat rebooten, is dat ook geen moment om dingen zoals kernels te gaan upgraden.
Er komt tenslotte ook dat moment dat je eens van OS versie x naar OS versie Y zult moeten gaan omdat je zooi anders niet meer supported wordt.
Indien dit soort 'reboots' niet kunnen, dan zou ik toch kijken naar een andere stabielere oplossing dan realtime kernels laden.

Oorspronkelijk geplaatst door systemdeveloper

Toch zie ik het niet zo'n vaart lopen. Alhoewel er genoeg redenen zijn waarom je niet midden op de dag als mensen aan het werk zijn, de server gaat rebooten, is dat ook geen moment om dingen zoals kernels te gaan upgraden.
Er komt tenslotte ook dat moment dat je eens van OS versie x naar OS versie Y zult moeten gaan omdat je zooi anders niet meer supported wordt.
Indien dit soort 'reboots' niet kunnen, dan zou ik toch kijken naar een andere stabielere oplossing dan realtime kernels laden.

Er zijn natuurlijk wel echte 7x24 omgevingen, hetzij met autonome clients, of een dekking van veel tijdzones waar de nacht niet automatisch 'pijnloze downtime' betekent.

En als je hiermee zo'n pijnmoment van misschien maandelijks naar halfjaarlijks of jaarlijks of nog minder vaak kunt terugbrengen kan dat zeker de moeite waard zijn.

Het is de klassieke mainframe markt, extreem hoge availability (_cpu_ hotplug is daar uitgevonden).
En daaronder een deel 'dat hebben we er niet voor over/niet nodig, maar dicht in de buurt willen we wel' .

Laten de we hopen dat systemen die zich met een mainframe gaan vergelijken, toch wel reeds een oplossing hebben en dat dit abbootje van 3,95 per maand niet opeens de verlosser is, want er zijn 100 andere dingen die geupdate moeten worden en ook voor een service onderbreking kunnen zorgen (apache/mysql restart, bezopen ontwikkelaars, etc..).

Hoe je het ook bekijkt het kan nuttig zijn, ik geef even een klein voorbeeld:

Je doet wel aan reboot tijdens je maintenance windows (bvb 1 maal per week; maand; kwartaal; halfjaar; ...) maar je wilt niet dat belangrijke bugfixes/zero-days/patches achter lopen op de feiten. Dan kan dit een prima oplossing zijn om niet elke dag te moeten herstarten maar wel alle laatste cve kernel updates te kunnen patchen.

Volgens mij zullen ze na een live kernel update toch ook de init processen moeten aantrappen? In feite bespaar je dan alleen het verschil in tijd tussen de cold en hot reboot. Nu kan een cold reboot op een flinke server best een paar minuten duren natuurlijk, dus dan is het wel een uitkomst. Maar op een vps betwijfel ik het aangezien die helemaal niet die initialisatietijd hebben waarbij ze bijvoorbeeld 2 minuten op een check van de raidcontroller staan te wachten.

Oorspronkelijk geplaatst door systemdeveloper

Volgens mij zullen ze na een live kernel update toch ook de init processen moeten aantrappen? In feite bespaar je dan alleen het verschil in tijd tussen de cold en hot reboot. Nu kan een cold reboot op een flinke server best een paar minuten duren natuurlijk, dus dan is het wel een uitkomst. Maar op een vps betwijfel ik het aangezien die helemaal niet die initialisatietijd hebben waarbij ze bijvoorbeeld 2 minuten op een check van de raidcontroller staan te wachten.

Ik heb wat verder zitten lezen, en het is een stuk meer 'on the fly' dan dat.
Alle programma's blijven draaien met behoud van al hun state, en lopende sessies e.d. moeten ook blijven staan.

Ik ga er maar even van uit dat de ksplice methode min of meer standaard is voor deze stijl van live kernel updates.
(waarom ksplice - daar vond ik een uitgebreide beschrijving van )
Hoewel kernelcare zegt een andere manier van patches genereren te gebruiken dan Oracle (ksplice) denk ik dat de techniek grofweg op hetzelfde neerkomt.


Kort gezegd wordt het volgende gedaan :

Van de functie(s) die gepatched worden bij de update wordt een vervangende versie gecompileerd.
Dan wordt uitgebreid gekeken in de object code of er niet naar midden in de te vervangen functie gesprongen wordt, of die functie niet ge-inlined is e.d.
Met een 'stop_machine' call worden alle CPUs behalve één stil gezet.
Er wordt nu gezocht of er geen programma's zijn die net nu in de functie die vervangen moet worden zitten.
Zo niet, dan wordt de vervangende functie in het geheugen gezet, en wordt een jump daarnaar toe geschreven in het begin van de oude functie.
(en zo ja , dan wordt het een aantal keren opnieuw geprobeerd . Het stilzetten en patchen gaat < 1 msec).

Je zou kunnen zeggen dat er een bypass gemaakt wordt naar een nieuwe functie. Het resultaat is dus geen volledig andere kernel, maar een vervangen functie .

Niet alle functies zijn in alle omstandigheden te vervangen maar het ksplice paper heeft gekeken naar alle security updates en getest dat dat ksplice-bare updates waren.

details : http://www.ksplice.com/doc/ksplice.pdf
high-level : http://en.wikipedia.org/wiki/Ksplice

Ik heb wel het gevoel dat je wel _heel veel_ last moet hebben van reboots om dit als geschikte mitigation te zien.

Ksplice is volgens mij een paar jaar geleden door oracle overgenomen, dus daar heb ik niet meer echt naar gekeken. De kexec-tools heb ik wel eens gebruikt voor een bak aangezien die met zijn raidzooi gewoon een paar minuten weg is en dan alle connecties dood gaan, terwijl dit goed opgepakt wordt als je maar een paar seconden geen verbinding hebt. Die trapte overigens wel de init opnieuw aan.
Dus het zeker interessant spul. Overig merkte ik toen met kexec (vanwege de init) wel dat ik vergeten was een varnish met chkconfig aan te zetten, wat dus tot resultaat had dat de server in feite useless was.
Als ik puur vertrouwde op een init-loze vervanging van een kernel, dan had ik dat waarschijnlijk pas geweten als ie echt eens goed op zijn bek ging.

Maar alle procs stopzetten, de jumpertabel wijzigen en zorgen dat je patches niets essentieels in ram overschrijven is wel de manier om het te doen, denk ik. Nou ja, totdat de eerste de beste hacker/virus/trojan je een custom kernel de strot afduwt en je niks merkt.

Ksplice gebruik ik al een aantal jaren tevreden. Voorkomt inderdaad dat je snel een server moet opstarten (dit duurt toch al snel weer een paar minuten) als er een kritiek veiligheidslek is ontdekt. Ondanks dat Ksplice helaas door Oracle is overgenomen ondersteunen ze voor bestaande klanten nog steeds diverse RHEL gerelateerde besturingssystemen waaronder CentOS en CloudLinux.

Heeft iemand KernelCare al getest?
Het is me niet helemaal duidelijk of ze het nu gratis aan Cloudlinux toevoegen. Zoiets lijkt me toch een extra verkoopargument.

Oorspronkelijk geplaatst door The-BosS

Ik ken systemen die wel degelijk goed in elkaar zitten, maar waar een update van raid driver of nic driver voor heel wat problemen kan zorgen. Zo heb ik al een paar keer meegemaakt dat de kernel na een update en reboot even zelf besliste om de eth0 om te zetten naar eth1 en de eth1 naar eth0 etc. Of dat na een reboot plots je raid controller driver niet meer werkt zoals het hoort.

Juist dit is de reden dat je regelmatig moet rebooten. Als je dit hebt na bijv. een powerfaillure ben je mooi zuur en niet zo lekker ontspannen als wanneer je regulier onderhoud pleegt Dit soort dingen maken wij ook regelmatig mee (grappig die omwisselende netwerk devices of niet ;-)

Dit is ook de reden dat wij eigenlijk alleen maar high available geclusterde omgevingen maken. Kan je lekker overdag updates draaien en elk component en elke server kan in een rack uitvallen, maakt niet veel uit. Kost wat extra maar dan heb je ook wat.