Intel werkt aan methode om serverbiosupdates te installeren zonder herstart

Intel werkt aan een 'Intel Seamless Update'-feature die UEFI- en biosupdates mogelijk maakt zonder dat de computer herstart hoeft te worden. De technologie is gericht op servers en Linux-systemen. Er is nog geen bewijs dat de functie ook naar Windows komt.

De feature werd ontdekt door techwebsite Phoronix in nieuwe Linux-kernelpatches en is te vinden in een whitepaper van Intel op de website van het UEFI-forum uit augustus. De feature is ontwikkeld om minder downtime te veroorzaken voor bepaalde computers door firmware-updates door te voeren zonder reboot.

Intel Seamless Update is primair gericht op Intel-klanten met een hoge service level agreement voor wie het herstarten van een systeem voor bijvoorbeeld een beveiligingsupdate impactvol kan zijn, zoals in een datacenter. Intel werkt momenteel aan Linux-kernelondersteuning voor Seamless Update, blijkt uit patchnotes voor Intels Platform Firmware Runtime Update and Telemetry drivers.

Phoronix verwacht dat de nieuwe feature geïntroduceerd gaat worden wanneer Intel zijn Xeon Scalable Sapphire Rapids-serverprocessors uitbrengt, ergens komend jaar. Er is nog geen indicatie dat de feature ook naar Windows-apparaten of consumenten-pc's komt. Het lijkt erop dat deze in eerste instantie alleen bedoeld is voor Linux-servers.

Wat vind je van dit artikel?

Geef je mening in het Geachte Redactie-forum.

Reacties (112)

Het artikel gaat om een speciale groep computers, namelijk Linux servers, en de meeste reacties gaat weer over pc georiënteerd geleuter. Leest en begrijpt eigenlijk iemand wel, waar een artikel over gaat?

Ik? Geen idee,, op zich ook jammer dat er niet veel dieper wordt ingegaan op dit onderwerp, ik bedoel, juist voor mij als pc leuteraar. Na dit artikel zit ik alleen maar met vragen eigenlijk, ik bedoel, het bios updaten live, dus je past de basic input en output aan terwijl het systeem draait, dat is toch miraculeus...

Hoezo? Zodra je OS geladen is doet het BIOS en UEFI niks meer. Dat is alleen van belang zodra je de machine opnieuw opstart voordat het OS geladen is van disk.

ja maar ik neem toch aan dat dat bios wordt ge upgedate omdat er wat mis was, een bug of een veiligheidslek. Ik begrijp ergens ook dat waar het bios is opgeslagen gewoon een verwisselbaar medium zou kunnen zijn denk ik... weet ik veel.

Ik dacht meer dat de wijzigingen ook in het OS werden doorgevoerd, en dat leek me miraculeus, of wonderlijk... dat dus... maar goed ik ben ook echt een (pc) leuteraar

edit
oh wacht, is het zo dat het bios niets meer doet als het os draait? Dat wist ik niet dus in principe kun je je bioschip na opstarten eruit wippen en dan, zolang je niet herstart is er geen vuiltje aan de lucht?

[Reactie gewijzigd door DeDooieVent op 15 september 2021 13:36]

Ik begrijp ergens ook dat waar het bios is opgeslagen gewoon een verwisselbaar medium zou kunnen zijn denk ik... weet ik veel.

Nee. Een UEFI (bios is sterk verouderd) word op read-only flash opgeslagen. Tuurlijk is dit te updaten, maar niet op een manier die het OS normaal ondersteund.

Ik dacht meer dat de wijzigingen ook in het OS werden doorgevoerd, en dat leek me miraculeus, of wonderlijk... dat dus... maar goed ik ben ook echt een (pc) leuteraar

Zoals in het artikel ook staat worden de wijzigingen doorgevoerd vanuit het OS. Normaal doe je een UEFI update vanuit de UEFI zelf, dus voordat je OS geladen is. Dat is met deze techniek dus niet meer nodig, wat opstarttijd bespaart aangezien je geen dubbele herstart hoeft te doen.

Deze flash chip is meestal gewoon vanuit het OS te updaten, zie flashrom.

Flashen is dan ook niet het probleem, het niet hoeven restarten na zo'n flash is (nu nog) het probleem.

Na dit artikel zit ik alleen maar met vragen eigenlijk, ik bedoel, het bios updaten live, dus je past de basic input en output aan terwijl het systeem draait, dat is toch miraculeus...

Erlang is miraculeus; daarbij kun je de software aanpassen terwijl die actief gebruikt wordt.

Ik bedoel maar, alleen al met dit zinnetje kost je mijn baas straks weer uren en uren leestijd

Je zit hier op Tweakers. No offense maar ik denk dat de meeste lezers niet eens een computer achtergrond hebben....

Wel jammer hè, dat dit tegenwoordig zo is op tweakers.

Jammer, maar begrijpelijk. Tweakers is overgenomen, koos ervoor zich te richten op de massa, kwam er achter dat dit niet echt de goede richting was en richt zich nu op de paywalls (net als de rest van de persgroep).

Ik zie het niet echt als jammer maar meer als een kans voor een ander op het gat te vullen. Al zal dat moeilijk zijn met de (engelstalige) concurrentie zoals reddit.

Ik ga eigenlijk bijna nooit op die Engelstalige concurrentie. We hebben echt weer een Nederlands alternatief nodig van liefhebbers voor nerds ipv winstmaximalisatie met de massa.

Hardware.info is een betere site voor nederlands technieuws. Maar ook daar klagen gebruikers over het geposte nieuws (met verwijzingen naar de persgroep) al weet ik niet hoe correct dat is.

Maar het is inderdaad lastig om een goede Engelse site te vinden gezien ze vaker gespecialiseerd zijn.
Dat zie je ook terug in Nederland. iCulture is bijvoorbeeld een hele goede techsite maar enkel Apple nieuws.

Er is natuurlijk technisch gezien weinig dat de technologie beperkt tot servers. Een feature als deze zou ik persoonlijk flink verwelkomen op consumentenhardware, aangezien heel veel BIOS-updaters op consumentenapparatuur eruit zien alsof ze op DOS draaien of daadwerkelijk op (Free)DOS draaien. Bedrijven als Apple hebben hier al langer een oplossing voor die goed afgewerkt is en integreert met de rest van het systeem; zoiets binnen je OS, of het nou via Windows Update of fwupdate wordt gedaan, zou de gebruikerservaring van het proces in mijn ogen flink verbeteren.

Het is er wel, de surface laptops kregen hun firmware via windows update binnen en maken daar een laadbalkje van tijdens de reboot. Linux laat bij sommige merken en in sommige distributies dit toe via de reguliere update managers. Al weet ik niet hoe het update process daar te werk gaat.

Mijn dell laptop krijgt bios updates ook al jaren gewoon via een app van dell binnen en toont bij het booten netjes een laadbalkje.

Volgens mij wordt dit door de meeste grote fabrikanten wel netjes geregeld tegenwoordig.

Dit is niet een specialistisch forum, maar de nieuwspagina. Daar zitten dus veel geïnteresseerden, maar weinig experts.

Ik vraag me af of dit iets te maken heeft met het Linux Firmware Project.

Dat timmert al een tijd aan de weg om een universeel update mechanisme te maken voor firmware en alles wat daar op lijkt. De tijd dat je firmware installeerde door een DOS-bootdisk te maken en daarmee te booten is nu wel weer voorbij. De grote zakelijke leveranciers hebben dan wel weer oplossingen om firmware via het netwerk uit te rollen maar dat is al snel een fors project om op te zetten. Het is hoog tijd dat we het updaten van firmware vereenvoudigen en standariseren want het lijkt nog steeds de standaard te zijn om firware pas te updaten als er een probleem is.

Dan moet je wel betere updates hebben. Mijn retro PC uit 2004? Gaat soms niet aan bij nieuwere revisies door een foutieve usb spanning check. Gigabyte PC uit 2012? Kan permanent kapot gaan in hun UEFI implementatie gelukkig had die dual bios. Mijn huidige game game PC? Legacy emulation gaat kapot op de laatste versie waardoor je enkel nog met UEFI systemen kunt spelen. Enkel bij mijn lenovo laptop en HP 5710 heb ik nergens last van gehad maar zoals het bovenstaande beschrijft is het al jaren een risico dat nog steeds voort duurt.

Dus in alle gevallen heb ik downgrade tools beschikbaar en sla ik de goed werkende versies op. Dan kan ik altijd terug.

Dan moet je wel betere updates hebben.

Het is natuurlijk ook een beetje een kip-ei probleem. Als niemand updates installeert dan komen de problemen ook niet boven en vindt de leverancier het ook niet heel belangrijk om er veel moeite in te steken.

Dat iedere leverancier z'n eigen tools schrijft helpt natuurlijk ook niet.

En dit alles geldt natuurlijk dubbel voor downgrades, die zijn helemaal zeldzaam.

Een BIOS update installeren zonder herstart lijkt mij geen probleem. Een nieuwe versie van de BIOS actief maken zonder herstart, daar zit de truc in. Gecombineerd met Kernel Live Patching hoeft een officieel ondersteund systeem in diens levenscyclus nooit opnieuw gestart te worden, tenzij die crasht of bij een stroomuitval.

[Reactie gewijzigd door The Zep Man op 15 september 2021 11:48]

Uit nieuwsgierigheid. Wat gebeurd er met zo'n systeem wat nooit een reboot mag hebben. Als die, zoals jij beschrijft crasht of door stroomuitval. Uit gaat?

Ik bedoel, is het niet verstandiger om er voor te zorgen, dat je een systeem wel kan herstarten? Ik zelf, ben nog geen situatie tegen gekomen. Dat ik een server niet kon herstarten.

Meest voorkomende is webservers bij webhosting bedrijven. Je wilt geen downtime voor de klanten maar wel zo up to date mogelijk zijn.

eh, webservers werken toch samen in een farm, dat lijken me de meest makkelijke toestellen om te herstarten.

Heel vaak niet. Zulke mooie complexe situaties zie je bij echt grote websites en businesses.
Veel draaien nog gewoon op 1 server, elke reboot is dan downtime. Denk bijv. aan shared hosting, bij veel bedrijven is dat echt geen dubbel uitgevoerde farm met loadbalancers ed.

die moeten allang naar cloud gaan en niet meer door hobbien op duren eigen oplossingen,

Daarvoor is juist azure web services ed beschikbaar

Alsof "cloud" iets magisch is. Daar draaien de webservers vaak in een cluster (farm) achter loadbalancers. En daar betaal je dus voor. Een goedkoop hostingpakketje is goedkoop, omdat het op een enkele server draait. Daar doelt @rickdtop op.

je mist nu juist het punt,

juist omdat jij niks meer beheerd en alles Correct redundant is gemaakt en jij je daar niet zorgen over hoeft te maken is het uitermate goed cloud scenario.

de magie van cloud is dat ehet veel beter beheerd en gemonitord wordt dan dat jij dat onprem kan, en door de grote hoeveelheid automation is het ook goedkoper

ik doel ook niet op onprem, maar in datacenters, geen Azure of andere grote cloudproviders. Dit gaat hier over Linux op Intel servers, meestal is het windows binnen bedrijven. Linux is vooral erg veel gebruikt bij webhosting ed en die draaien in de cloud, wat in goedkope varianten op 1 server uitkomt en geen redundante situatie. Zelf servers draaien (in een DC uiteraard) is wat dan betreft echt stukken goedkoper als in een bijv. Azure oid.

Dat is inderdaad wat ik bedoel. Om de kosten te drukken bij bijv. shared hosting, wordt er zo goedkoop mogelijk gedaan. Dus een goedkoop dataverkeer/DC en niet redundant. Dan hou je alles echt zo goedkoop mogelijk.

Zoals @Firewrx ook aangeeft. Hangen webservers tegenwoordig achter een loadbalancer en daardoor te herstarten zonder enige downtime voor de dienst.

Heb je een andere voorbeeld, waarom een server niet herstart kan/mag worden?

Ja, dat schuift het gewoon een niveau omhoog, nu mag de loadbalancer niet uit. Gelukkig is het bij (web)hosting meer een kwestie dat een IP niet offline mag gaan, welke machine er uiteindelijk achter zit maakt weinig uit.

Ik kan mij andere toepassingen voorstellen waar het belangrijker is dat het aan blijft. Soms vind je die op plekken waar je het niet verwacht, zeg camera systeem van een gevangenis. Kan mij voorstellen dat een gevangenis wel 2 minuten zonder camera's kan, maar misschien vervalt dan opeens de verzekering, is is het niet toegestaan. Ik verzin maar wat, soms is de reden gek

loadbalancers draaien in active/passive of active/active teams,

ook die kunnen gewoon gerestart worden zonder impact.

je camera is je Single point of failure, daarna is het netwerk, switches en storage redudant en kunnen gewoon gerebootworden zonder impact.

in de nieuwe wereld waar je cloud native draait maakt het helemaal niet meer uit want hardware draait hypervisors dus virtual services kunnen gewoon actief gemaakt worden op andere servers als ze goed ontworpen zijn via micro services.

[Reactie gewijzigd door Scriptkid op 15 september 2021 18:47]

Mss is herstarten om eoa reden vervelend, als dit dat kan verminderen zonder verdere nadelen waarom niet. Dat hoeft niet meteen te betekenen dat herstarten onmogelijk/rampzalig is.

Aansturing van machines die 24/7 draaien. Elke minuut dat dat stilstaat kan flink, flink in de papieren lopen. Onderhoud e.d. moet echt ingepland worden.

Nooit is een groot woord maar servers bieden over het algemeen services aan een groep mensen en/of computers. Zet de server uit en je hebt meteen impact, hoe ver die impact gaat hangt ervan af.

's Nachts updaten kan ook maar heeft ook nadelen, systeembeheerders moeten dan in de nacht werken en als het systeem terug opgestart is waarbij applicatie X niet online komt, veel geluk met 's nachts support te krijgen.

Bijkomend probleem is dat die firmware updates niet meer enkel uitkomen om specifieke hardware issues op te lossen of nieuwe hardware te ondersteunen. In dat geval kon je ze immers negeren als het specifieke issue niet van toepassing was op jou server.

Tegenwoordig komen ze aan de lopende band uit met CVE security issue X dicht getimmerd waardoor je niet enkel verplicht bent ze uit te rollen, ze komen plots uit voor al je servers. Je moet dus niet 1 server even rebooten, je moet ze allemaal rebooten.

Daaraan gekoppeld kan een firmware update bij een server met gemak een uur duren want je krijgt niet enkel firmwares voor de Bios/Uefi maar ook voor je raid controller, netwerk controllers, backplane controllers, sas controllers, enterprise disks, IPMI modules en ga maar door.

Ook niet te vergeten dat servers niet quick booten zoals een consumenten pc, die hebben soms 5 minuten nodig omdat die bij iedere reboot alle hardware uitgebreid controleren.

het probleem is niet dat de service verbroken wordt
als je een goed ssysteem hebt staan dan is het minimaal dubbel uitgevoerd en een lopende sessie wordt afgehandeld op de andere server, hooguit een klein hikje wat je bijna niet merkt.

in uitzonderlijke gevallen, zoals financial systems kan dit een probleem zijn.

echter, 2 systemen in de lucht hebben emt verschillende drivers/firmware levert vaak meer problemen op dan het overschakelen van server a naar b.

zelfs met virtualisatie als de betreffende server van de ene naar de andere host over gaat zit er een heel klein hikje in.
onvermijdelijk.

verder levert een bios update vaak meer problemen op in het kader van niet ondersteunde hardware met hun versie van bios.
voor systeem bios X moet er iminimaal netwerk kaart bios versy x zijn en backplane versy Y enz enz.
bzelf ben ik veel bezig geweest met het op orde brengen van HP Synergy systemen.
ellende om alles op de juiste versie te krijgen voordat het weer allemaal werkt.
je gaat daar in 1 keer 48 server, 4 backplanes, converged netwerk infra stucture en alle rand zaken er om heen upgraden.
alles gaat wel 1 voor 1, maar er zijn minimale levels voorgesschreven voordat je de volgende stap kunt doen.

BIOS/UEFI leeft uiteindelijk in het RAM. De chip op het moederbord is vooral opslag en inladen. Je kan gewoon ervoor zorgen dat je dat overschrijft en dan live zet.

Je kan gewoon ervoor zorgen dat je dat overschrijft en dan live zet.

Je schrijft 'gewoon', maar zo vanzelfsprekend is dat niet. Zo moet de aansluiting van het OS met de ingeladen BIOS hier niet door beïnvloed worden zonder medeweten van het OS. Verder is een BIOS ingeladen in RAM een stuk complexer dan zoals die opgeslagen wordt in een chip.

[Reactie gewijzigd door The Zep Man op 15 september 2021 11:51]

Ja, het heeft inderdaad wel OS support nodig, maar er is geen inherente technische beperking.

[Reactie gewijzigd door ocf81 op 15 september 2021 11:51]

De technische beperking is dat het os nieuwe instructies moet krijgen van je bios.

Normaal gebeurd dat bij post, daarna wordt het os geladen.

Ook niet met een libc update? Sure er bestaan package manager plugins die automatisch running services kunnen restarten als out of date libs gebruikt worden. Maar als je in HA zit dan is het in zo'n geval toch beter om te rebooten en die node gewoon in maintenance te zetten.

Dit is dus precies het probleem. Live kernel patching klinkt heel leuk, maar toch wil je wel een reboot doen nadat je packages als libc een update hebt gegeven. Ik heb over de jaren rare dingen meegemaakt op servers die geen reboot kregen na b.v. een libc update. Het probleem is dan vaak ook dat het spul net niet "kapot genoeg" gaat voor je monitoring om het op te pikken, maar je productie wel in gevaar brengt.

ook dat kan tegenwoordig live gepatched worden: https://tuxcare.com/whitepaper-librarycare/

Yep en daar heb ik vrij wisselende ervaringen mee. We hebben het een tijd gebruikt in het bedrijf waar ik werk, maar hebben het uiteindelijk maar de deur uit gedaan omdat het alsnog voorkwam dat we servers zo nu en dan moesten rebooten om spul goed te laten draaien.

Heel herkenbaar. Nu is mijn ervaring wel van wat jaren geleden. Maak wel gebruik van kernelcare, dus de kernel actief patchen. Daarmee haal je wel wat reboots uit je cyclus.

Grotere uitdaging is microcode updates. Voorbeeldje daarvan is Intel TSX, dat sinds de introductie nooit fatsoenlijk gewerkt heeft en waarvan Intel bij steeds meer CPUs de instructies uitgezet heeft (inmiddels uitgeschakeld op alle CPUs). Dat is ook de reden waarom kernels tegenwoordig bij het booten direct microcode kunnen updaten nog voordat er andere code uitgevoerd kan worden.
Wat je krijgt is dat de threading library van glibc denkt TSX te kunnen gebruiken en op moment dat het wordt aangeroepen na een microcode update is de instructie niet meer beschikbaar en crasht je applicatie met SIGILL.

Even een stukje context: Je moet ook niet vergeten dat het herstarten van een server zo 10 minuten of meer kan duren.

In 2021? Nee, 10 minuten is zeldzaam. Alleen als je boot vanaf USB of wanneer je HDDs moet fsck'en omdat je dat al langer niet hebt gedaan. Wanneer je Kernel Live Patching gebruikt (zie The Zep Man in 'nieuws: Intel werkt aan methode om serverbiosupdates te insta... ) dan reboot je al niet. En bij een type 1 hypervisor blijft de onderliggende machine ook gewoon draaien.

Boottijd wordt vaak verlengd als er meer RAM in zit. Boottijd ligt dus niet altijd aan het OS.
Als ik mijn server thuis een herstart geef, is hij langer RAM aan het checken dan het OS aan het starten. En dat terwijl het OS op SSD staat (ESXi7 heeft voorkeur naar een bootSSD namelijk).

Dus ja, bij een server is een boottijd wel aanzienelijk langer. Als je meer dan 256GB RAM hebt, gaat dat alleen maar langer duren.

quick boot,

waarom wil je ram testen bij ECC

waarom wil je ram testen bij ECC

Omdat ECC ook gewoon defect kan zijn hé.. En sowieso, waarom zou je dat niet willen is meer de vraag. Kan nooit kwaad. Zovaak rebooten servers niet.

Omdat kapot ecc tijdens het schrijven de block al corrigeert, dus kapotte blokken worden niet gebruikt.

Ecc beschermt tegen één kapot bitje, of tegen sporadische bitflips.
Een kapot bitje is vaak het begin van een kapotte module.
Wanneer een module al wat verder stuk is, zijn er vaak meerdere bitjes stuk.
ecc kan niet beschermen tegen twee kapotte bitjes in een byte.

Een server boot max één keer per maand, Waarom niet dat kwartiertje wachten terwijl je boot?

Wanneer een klant niet die tijd wil wachten, kan hij OF in een HA oplossing gaan denken, of is hij zo stom dat hij het risico op een defect met veel downtijd voor lief neemt. En dan heeft de klant nog geluk. Wat als doordat je dat kwartierje niet wil wachten, er veel data corrupt raakt doordat twee bitjes naast elkaar stuk zijn?

Nou denk je vast: dat gebeurt nooit, en ander bla bla.... nou, dan heb jij waarschijnlijk geen serieuze klanten, of over een paar jaar een claim van een klant aan je broek hangen.

[Reactie gewijzigd door Fiander op 15 september 2021 16:51]

Een server boot max één keer per maand,

Oh? Ik ken zat bedrijven die hun servers jaren achter elkaar aan laten staan en dat ze een uptime van 700+ dagen hebben .
Mij niet gezien, maar het komt helaas wel voor. Mijn server staat over het algemeen niet langer aan dan 2 maand, want dan is er wel weer ergens een update voor of dan wil ik hardware wijzigen. En als ik hardware wijzig, gooi ik vaak ook gewoon de updates erbij. Als hij toch al down is

Ik zeg toch ook max één keer per maand ( uitgaande van fysieke productie servers )
minder vaak booten komt inderdaad veel vaker voor. vaak worden P servers alleen geboot na een CVE melding ofzo.

Vaker booten vaak alleen bij OTA. ( Dat jij je hardware wil wijzigen zegt mij al : O of T )

juist als een hele module of stuk ram kapot is merk je dat al lang voordat je boot , en ECC kan de bit flip of enkele kapote bit gewoon detecteren,

als er echt zoveel stuk gaat dat je een ramtest nodig hebt moet je toch echt je hardware eens gaan vervangen, heb in 15 jaar tijd geen enkele module meer stuk zien gaan of een ramtest nodig zien hebben. Alleen bij particulieren game pcs die zwaar overclocked worden is dat nuttig

Ecc is geen oplossing voor kapot ram, het zorgt alleen dat je errors die normaliter voorkomen in normaal RAM niet zo snel krijgt, wat vooral bij applicaties waar het heel nauw kijkt handig is.

Je mag wel stoppen met dromen hoor, want zo werkt het niet in de praktijk. Dat zou betekenen dat je minder RAM zou hebben in een server, nadat je eerste block defect is. Dan ga je ineens van 256GB RAM, spontaan naar 250GB RAM bijvoorbeeld.

Hoe leuk denk je dat applicaties dat vinden als er ineens wat RAM weg is?

nee maar als jij een heel block kwijt raakt heb jij al lang een blue screen of een hele hoop errors voordat jij gaat reboten en dan heeft die bios ram test ook geen nut meer.

Dus ja, bij een server is een boottijd wel aanzienelijk langer. Als je meer dan 256GB RAM hebt, gaat dat alleen maar langer duren.

Dat ligt volledig aan je memory setup. Met huidige processoren is geheugen in een 128G/256G opstelling veel trager dan in een 192G/384G opstelling (6 memory channels per processor), dus (ik heb dit niet in de praktijk getest) zou het zomaar kunnen zijn dat een server met 384G even snel of zelfs sneller door zijn extended memory check is dan een server met 256G. Uiteraard is het document op de HPE website weer eens niet beschikbaar maar als je daar een bron van zoekt, dan google maar eens naar "Gen10 memory speed table".

Ah, hier een andere bron via Dell: https://downloads.dell.co...g_memory_xeon_2nd_gen.pdf

[Reactie gewijzigd door geeMc op 15 september 2021 15:48]

Het klopt wel hoe je RAM in een server prikt, met toegangstijden en ga zo maar door.
Maar je houd alleen rekening met RAM. Als er een RAID controller wordt gebruikt met disks en dergelijke, kan dit ook wel een paar seconden tot een minuut duren.

En als je al dat spul wat moet opstarten, bij elkaar optelt, zit je redelijk snel aan de 10 minuten.
Ja, RAM is de bulk van het opstarten, en hoe meer je hebt, hoe langer je moet wachten.

Maargoed, we begrijpen elkaar, dus laten we er vooral niet te lang over door druilen

Een bult geheugen en een aantal raidsets aan de server. Kost je zo een paar bakken koffie voordat het OS eindelijk geladen wordt. Vanaf dat moment gaat het snel.

10 minuten boottime is al jaren niet meer de standaard bij de meeste servers. Bijvoorbeeld een HP DL[3|5][6|8]0 Gen9,10,10+ boot doorgaans binnen 5 minuten.

Ik vind het maar een linke ontwikkeling om eerlijk te zijn. Een beetje architectuur staat downtime toe door middel van redundantie, dus zou het op wellicht wat edgecases na voor de meeste bedrijven helemaal niet interessant zijn. Dit soort dingen komen (op OS niveau, met b.v. live kernel patching) de stabiliteit van systemen doorgaans niet ten goede. Als dat op OS niveau al onstabiliteit met zich mee kan brengen, vind ik het voor een BIOS helemaal geen goed idee.

Ik ben het helemaal met je eens, dit is een onwenselijke ontwikkeling. Een onderdeel van een gecontroleerd patch proces is het testen na het patchen. En aangezien 1 van de meest belangrijke taken van de bios het boot proces is zal je een reboot moeten uitvoeren om zeker te weten dat de nieuwe bios in orde is. Anders loop je het risico dat je ergens in de toekomst bij een onvermijdelijke reboot er achter komt dat de nieuwe bios je storage niet goed detecteert of iets anders catastrofaals.

verschil tussen installeren en activeren.

je kunt gerust de install doen op 2vd 10 servers overdag en dan savonds restarten , als alles ok is up en running brengen en instaleren op de andere 8 maar er maar 2 per dag restarten

Maar met 5m startup (en dan vergeten we nog even de tijd voor een correcte shutdown indien mogelijk) zit je nog maar net binnen 99.999%

Een uptime/availability van 99.999% is dan ook niet realistisch en ga je ook niet snel kunnen vinden. Wie bied zo een hoge uptime?

Een opstarttijd van 5 tot 10 minuten vind ik ook lang, maar zo gek is het niet. Een simpele 1U server zonder te veel hardware start snel op ja, maar op het moment dat je wat (exotische) hardware hebt duurt een reboot al veel langer.

OS is zo opgestart, maar voordat het zo ver is gaat er gewoon veel tijd verloren.

Wie geeft er nog een uptime garantie op een server i.p.v. een dienst?

En daarom is architectuur bij het deployen van een applicatie belangrijk. Er is vrijwel altijd wel een manier om iets HA neer te zetten. Shared IP's, shared storage, network raid1(drbd), custom (r)sync scripts, noem het maar op. Er zijn maar weinig cases waarbij je geen enkele mogelijkheid tot HA hebt, tenzij je het over legacy systemen hebt. Maar die laatste komen hiervoor waarschijnlijk uberhaupt niet in aanmerking. En als je geen mogelijkheid tot HA hebt, moet je misschien geen 99,99% uptime eisen stellen.

[Reactie gewijzigd door geeMc op 15 september 2021 12:20]

Het lijkt me dat als je op drie negens achter de komma in je contract hebt staan, je toch niet een enkele fysieke server hebt waar je afhankelijk van bent? Als uptime echt zo kritiek is, moet je ook kunnen dealen met stroomuitval of hardwarefouten en een betrouwbare failover hebben of de optie om live tussen machines te migreren.

ehh nee,

je applicatie hoeft niet down als een server reboot, de redundantie hoort in de app te zitten

Wat versta jij onder boottime? Ik zie dat als het laden/doorlopen van het bios/UEFI + laden van OS en alle services die op een machine draaien.

[Reactie gewijzigd door ocf81 op 15 september 2021 13:06]

Ik heb het over de hele boottime. Vooral bij Linux servers (waar dit artikel over gaat) is de boottime vrij klein. Het opstarten van een Linux server op gemiddelde enterprise hardware gebeurt echt binnen 5 minuten, inclusief het starten van services. Windows kan dan iets langer duren, maar ik heb al jaren geen Windows servers meer meegemaakt die er in totaal langer dan 5 minuten over doen (en ik heb een breed scala aan verschillende Windows servers beheerd, zowel fysiek als virtueel). Wellicht als je een server draait met een enkele Xeon Bronze processor en langzame storage dat het langer duurt, maar dat noem ik ook niet echt enterprise-grade .

Mijn NAS doet er 12 minuten over. (nog wel een Socket 2011-3 server)

Ah ja, dan heb je het inderdaad ook meer over (in HPE Proliant land) Gen8, die waren inderdaad een stuk trager met booten.

10 minuten boottime is al jaren niet meer de standaard bij de meeste servers. Bijvoorbeeld een HP DL[3|5][6|8]0 Gen9,10,10+ boot doorgaans binnen 5 minuten.

Ik heb niet al te lang geleden een DL380G10 toch anders ~15 minuten bezig gezien met een update. Ding had 768GB RAM, en voordat dát allemaal gecheckt is ben je even bezig. Het laden/starten van het OS duurde 45 seconden. De overige 13 en een beetje minuten was hardware check

Wellicht dat je wat extensieve checks doet tijdens het booten, is natuurlijk allemaal te tweaken in een server . Ik zie het nut van extensieve checks tijdens de boot niet als je een LOM (iLO in dit geval) hebt die dit ook prima tijdens runtime kan checken. Ik werk zelf ook met servers die helemaal volgeduwd zitten met zulke bakken aan geheugen, 4 processoren, RAID controllers, NVMe backplanes en noem maar op en geen enkele van die servers doet er zolang over om te booten.

Geen idee, standaard configuratie zoals aangeleverd vanuit HPE. ECC RAM wordt, zover ik weet, altijd gecheckt tijdens een boot, en dat duurt even.

De default in ProLiant BIOS inderdaad is om een extensive memory check te doen bij boot. Die zetten wij altijd uit. Zo zetten we wel meer uit, maar ik weet zo niet meer wat allemaal. Ooit een Ansible playbook voor BIOS settings gemaakt om zeker te zijn dat elke server (soort) dezelfde configuratie gebruikt.

Ik heb liever dat er een controle gedaan word tijdens het starten dan dat ik er een aantal weken later achter kom dat een deel van het cluster plat gaat door een dode/defecte RAM module bijvoorbeeld, maar ieder z'n ding.

Maar daar heb je nou juist ECC voor. Daarnaast kan je management module dit in realtime ook testen. Wellicht iets minder betrouwbaar, maar alsnog betrouwbaar genoeg. Maar inderdaad, ieder zo z'n afwegingen .

ECC slaat op de inhoud van het RAM als het in gebruik is zover ik weet. Een hardware defect gaat ECC ook niet oplossen..

Dat ligt aan het soort defect. ECC gaat inderdaad niet helpen tegen hardwaredefecten die de hele module als broken renderen, maar wel als een (beperkt) deel stuk gaat. Dat eerste zie je sowieso ook niet aankomen bij een on-boot memory check.

Nou, het wachten op die sea of sensors duurt me altijd veel te lang

Er zijn best servers die binnen 1-2 minuten up and running kunnen zijn.

Hence het woordje doorgaans.

Even een stukje context: Je moet ook niet vergeten dat het herstarten van een server zo 10 minuten of meer kan duren.

Aanvulling: Je zit inderdaad met (bijvoorbeeld HP servers) kalibratie van hardware dat elke reboot uitgevoerd wordt. Dat duurt enkele minuten. Vervolgens alle checks aan alle componenten, elke NIC, je Raid controller etc.

Dan ben je echt wel blij als BIOS updates zonder reboot hoeven te gebeuren, net als het linux systeem dat doet.

Leuk, maar ik kom weinig servers tegen die bare metal zijn geïnstalleerd. Zou mooi zijn als dit voor hypervisors beschikbaar komt.

Ik begrijp er het nut niet van, maar misschien kan iemand mij dat uitleggen.

Als een server een bios upgrade nodig heeft, dan is dat neem ik aan omdat er een ernstig probleem is. Niet een nieuwe feature ofzo.

Een server met een ernstig probleem komt bij mij niet in productie. En als het ontstaat of ontdekt wordt tijdens de periode dat die in gebruik is dan moet het wel echt ernstig zijn wil ik die server een bios upgrade geven.

Die enorm kleine kans, vermenigvuldigd met de enorm kleine kans dat ik niet ergens een plekje in een service window kan vinden om die update uit te voeren...

En dan nog: stel dat er iets mis gaat tijdens de upgrade? Dit ga je toch nooit doen buiten een service window?

Ik moet daarbij zeggen dat ik live kernel updates ook niet doe. Ik heb veel servers, en geen enkel SPOF. De meeste systemen in mijn beheer zijn redundant by design, enkele anderen hebben fail-over mechanismen die ik regelmatig gebruik voor onderhoud.

Een bios update kan zowel nieuwe features als bugfixes bevatten. Kleine bugfixes voor bugs die uiteindelijk toch wel irritant zijn, zoals een kvm die geen muis pointer heeft wil je toch wel? Verder zou het prima werken dus is het geen catastrofaal probleem, maar handig is het dan niet.

Verder kan ook de bios bij- of afdragen aan de stabiliteit van een systeem, als een update dit verbetert dan wil je deze toch sowieso hebben?

Stel je wil een bepaalde setting aanpassen (bijvoorbeeld turbo boost die minder hoog boost maar wel 100% uptime kan hebben) maar je huidige bios heeft dat niet en een update voegt dit toe (alleen turbo aan en uit bijv. Waardoor die alleen af en toe boost ), ook dan wil je die update hebben.

Er worden steeds meer functies ge- offload naar hardware en OS control tegenwoordig.

Zo'n groot probleem zal het niet zijn.

In bios applicaties zijn er volgens mij altijd dingen die tot nu toe hoe dan ook een restart nodig hebben, dus ik ben benieuwd hoe ze dat op gaan lossen.

Een bios doet wel in principe het initialiseren van hardware (cpu, ram, pcie, etc), een environment creëren waar een OS kan booten en verder zijn mond houden, maar het opnieuw schrijven en inlezen van smbios tabellen, acpi tabellen onder andere lijkt me toch iets wat er dan door Linux overgenomen moet worden. En stel je voegt nieuwe devices toe die in het sysfs terecht moeten komen zal ook Linux daar iets mee moeten gaan doen, je draait de bios immers toch niet opnieuw?

Ben benieuwd.

Ideaal voor malware-schrijvers bedenk ik zonet.

Er is nog geen bewijs dat de functie ook naar Windows komt

Duh, windows kan, na ruim 25 jaar, nog niet eens een software update installaren zonder 2 herstarts

Wat Windows eigenlijk nog het meeste mist is een 'doe alles om alle beschikbare updates te installeren automatisch, zonder gebruikersinteractie' functie. Het komt vaak genoeg voor dat na een herstart en opnieuw inloggen, dat er alsnog weer updates klaar staan en er weer een nieuwe herstart nodig is.

Dat Windows meerdere keren moet herstarten is niet erg, zolang dat maar automatisch gebeurt. Voor servers is het natuurlijk wat anders (maximale uptime, en zo), maar daar heb je weer redundantie voor.

[Reactie gewijzigd door The Zep Man op 15 september 2021 11:46]

Sommige Linux distributie s hebben dat ook wel eens na een kernel update. En voor de meeste mensen is dat prima. Pc's starten tegenwoordig zo snel op .. op mijn werk heb ik er. Desk pro met een Pentium gold uit de 6de generatie en nog een harde schijf ik kan letterlijke 2 bakken koffie doen. De nieuwe pc's die hebben ssds en een i5 me 6 cores 15 seconden opgestart nog 15 seconden na de log in en je bent klaar..

Sommige Linux distributie s hebben dat ook wel eens na een kernel update.

Ik heb nog nooit twee herstarts moeten doen na een kernel update. Met de meeste Linux distributies is het installeren van updates ook transparanter en efficiënter dan in Windows. Alles kan geïnstalleerd worden zonder te herstarten (waarbij tijdens het installatieproces precies duidelijk is wat naar wat geactualiseerd wordt), en na een enkele herstart is alles geactualiseerd.

En voor de meeste mensen is dat prima. Pc's starten tegenwoordig zo snel op .. op mijn werk heb ik er. Desk pro met een Pentium gold uit de 6de generatie en nog een harde schijf ik kan letterlijke 2 bakken koffie doen. De nieuwe pc's die hebben ssds en een i5 me 6 cores 15 seconden opgestart nog 15 seconden na de log in en je bent klaar..

Nu hebben wij het ook over servers, waarbij hertstarttijd iets belangrijker is.

[Reactie gewijzigd door The Zep Man op 15 september 2021 11:54]

Nu hebben wij het ook over servers, waarbij hertstarttijd iets belangrijker is.

Beetje OT, maar mijn mening is dat je servers/applicaties die zo belangrijk zijn dat je ze niet een paar dagen(!) kan missen dubbel uitgevoerd moeten worden. Een paar minuten opstarttijd zou er nooit toe moeten doen. Als je bij ieder onderhoudsmoment tijdsdruk hebt gaat het vroeg of laat fout.

Beetje OT, maar mijn mening is dat je servers/applicaties die zo belangrijk zijn dat je ze niet een paar dagen(!) kan missen dubbel uitgevoerd moeten worden.

Dat is helemaal niet off-topic. Nog steeds wil je de opstarttijd minimaliseren omdat je niet te lang op minus één been wil lopen voor je kritieke applicatie(s).

Wij hebben in ons DC allemaal HP Proliant servers hangen (meeste G9/G10) en daar duurt het opstarten rond de 10 minuten. Zodra je door de bios heen bent is het seconden werk, maar de bios van de HP servers voert zoveel checks uit dat hij er echt lang over doet.

Nu is dat eigenlijk nog steeds niet echt een probleem als je de architectuur goed in elkaar zet, maar het kan problematisch zijn voor sommige servers.

Ja, servers zijn niet geoptimaliseerd voor boot-snelheid. Ik heb zelf geen ervaring met HP machines, maar je kunt vast wel een en ander uitzetten of optimaliseren.

PXE boot, extensive memory checking dat soort dingen zet ik altijd uit als ik het niet nodig heb.

Waarom zou je ook? als ik mijn blades update maak ik een blade vrij van VM's en maakt het me niet uit hoe lang de opstart duurt want er is geen downtime voor virtual machines..

Omdat een dll die is geladen niet op disk kan worden gewijzigd. En dat is als je een Unix gewend bent heel vreemd.

Ik krijg op Debian/Mint regelmatig de melding dat ik moet herstarten na een (kernel) update dus heel veel verschil is er niet in de praktijk.

Je hoeft niet perse te herstarten in deze gevallen, alleen als je ook echt die nieuwe kernel actief wil maken. Volgens mij staat dat ook in de melding iets van "you have to restart IF you want to activate the kernel changes"
Alle andere geupdate software packages kunnen doorgaans gewoon direct gebruikt worden is mijn ervaring.

Maar op zich is het raar toch, die melding? Je hoeft de kernel-update ook niet te installeren als je het niet gaat gebruiken. Maar als je de update installeert, moet je herstarten vooraleer je het kan gebruiken. Ik kan die 2 dingen dan toch niet los van elkaar zien.

De meeste windows software (die ik gebruik) vereist ook al lang geen herstart meer om te kunnen gebruiken. Het kan aan mij liggen, maar ik zie niet zo’n groot verschil.

- Er zijn bij de meeste linux distributies manieren om te voorkomen dat je überhaupt kernel updates meekrijgt. Systeem- en andere software updates zullen dan doorgaans helemaal niet meer om een reboot vragen.
- Mijn ervaring met windows updates is dat je vrijwel altijd je computer moet rebooten en dat hij daarna pas de laatste 30% afmaakt van de update.
- losse software updaten op windows heeft meestal geen reboot nodig, maar je moet nog wel altijd het programma zelf helemaal afsluiten anders blijven de bestanden gelockt.

Voor een desktop computer valt dit allemaal wel mee natuurlijk! Maar op een server is het soms een ander verhaal.

Mja, maar die Linux kernel updates zijn er niet alleen voor de lol, maar verhelpen ook kwetsbaarheden. Dus die wil je dan ook wel gebruiken.
Je kan idd nog wel kijken welke kernel updates wat dat betreft onnodig zijn. Ik "moet" elke maand ofzo rebooten ivm kernel security bugs, al zou dat nog minder kunnen omdat sommige van die bugs mij niet treffen.
Maar gewoon rebooten is voor mij makkelijker dan dat eerst helemaal te gaan lopen uitzoeken.
Als je meer geeft om uptime dan security wordt het natuurlijk een ander verhaal, maar wat je dan het beste kan doen is nogal subjectief.

Eens!

Een Linux systeem hoeft eigenlijk alleen maar opnieuw te worden gestart na een update van de kernel of de gedeelde standaard C library (libc6). Op een desktop/workstation is het wel aan te raden ook te herstarten na een update van de grafische drivers, zeker de proprietary driver van NVidia die gebruik maakt van DKMS waardoor er een nieuwe module in de kernel geladen moet worden. Na overige updates hoeft in principe alleen de software of service in kwestie opnieuw te worden gestart. Op Linux zou je dus regelmatig updates moeten krijgen die je kan installeren zonder opnieuw op te starten, wat op Windows echt een zeldzaamheid is.

Dat gezegd hebbende, het kan zijn dat op desktop gerichte distributies zoals Mint het zekere voor het onzekere nemen en je iets vaker laten herstarten dan strikt noodzakelijk is. Ook is het zo dat desktop georiënteerde distributies vaker kernel updates doorvoeren dan server georiënteerde distributies zoals RHEL of SLES.