Update van je server is helemaal niet belangrijk. Update van je Applicatie is eigenlijk alleen maar van belang.

De update van een specifieke doos, is eigenlijk alleen maar, ik heb de grootste.

ongeveer 3 jaar. Dat was een Novell server. Wel 20 jaar geleden. Door de opmars van consumenten software in de enterprise (want dat hadden de beslissers thuis ook) is het wat dat betreft niet best gesteld. Toen had je 2 beheerders nodig en nu een heel leger om binnen het update timeslot te blijven.

Denk dat je de huidige tijden met 20 jaar geleden niet goed met elkaar kan vergelijken.
Techniek is zodanig complex geworden in 20 jaar tijd, dat een all-around systeembeheerder vaak lastig is, je hebt tegenwoordig beheerders op expertise gebied (of die een aantal expertises hebben...)
Bijvoorbeeld een verschil in Office 365 beheerder, VMware/Virtualisatie beheerder of een SQL beheerder, meestal heb je daar aparte beheerders voor.
(tuurlijk afhankelijk van de grootte van het bedrijf).

Software was 20 jaar geleden minder complex... Ook andere aandachtsgebieden, security was toen nog niet echt belangrijk, internet nog in opmars.
20 jaar geleden was elke server nog een fysieke doos, later werden ze gevirtualiseerd en draaien er nu een veelvoud in VM's in dezelfde omgevingen.

Novell was zeker een mooi product, ook aardig veel gezien, ook in combinatie met Zenworks van Novell op de werkplekken.

Is de uptime een doel op zich ? Indien een server down gaat door andere reden dan technische problemen, dan is daar toch niets mee mis ? I.e. een geplande reboot ? Zolang je server maar stabiel draait ;)

20 jaar geleden. Toen werd al meer dan 10 jaar lang het einde van de mainframes verkondigd.
Grote dozen met 30 jaar terug virtualisatie in VM's en net de centralisatie van security weg van applicaties via SAF afgerond.
Helaas vond men het te duur en te lastig, het werkt toch als je met eigen doosjes en een enterprise bus aan de slag gaat.
Beschikbaarheid van veel gebruikte systemen zeer hoog geplande migraties in geplande tijden.

Alleen apparatuur waarvan onbekend was hoe die te gebruiken en te beheren bleef lang aan.
Als je enkel naar up-time kijkt leverde dat grote problemen/verstoringen op.

Nee hoor. https://www.computerworld.com/article/2577518/ibm-to-host-linux--virtual-servers--on-its-mainframes.html
Dat was toen al 70% goedkioper dan windows staat er.

Volgens mij betekent "Promised savings: About 30% compared to Windows NT/2000 servers" dat IBM 30% goedkoper beloofde te zijn, niet 70%.

Maar inderdaad, dit klopt niet:
IBM introduceerde op mainframes al virtual machines in 1972, het concept is al veel ouder dan de schrijver van dit commentaar zich realiseert.

Zoals gewoonlijk pak je alleen voor jouw gunstige fragmenten eruit. Het artikel gaat over een plan en die goedkope prijs is een VM, geen Windows server!. Je vergeet dan even voor het gemak de prijs van de grote server, die al die VM's moet runnen. Die tellen ze niet mee.

Dat is de verkeerde vraag. Een hoge uptime is een mindset van de jaren 90 .
Vooral omdat het beheerteam dan steeds banger wordt om noodzakelijke dingen te doen - wat komt de server wel goed terug - mensen installeren dingen , patches, services worden handmatig gestart (of gestopt) of herstart - en hopelijk wordt alles in de startup goed gezet dat het ook bij een reboot werkt.

Hoe langer je op die manier draait , des te groter de kans dat er een keer _iets_ niet goed staat - en je daarop nat gaat als dan een keer de reboot - of power outage komt . (Ja, ook in high-end datacenters hebben ze wel eens een "oeps" . Meestal samengaand met onderhoud aan de UPS , of aan 'alleen' de A of 'alleen' de B feed. En dan "oeps" beide feeds )

Een _ongeplande_ downtime is slecht teken. Maar nu streef je naar een hoge _service_ beschikbaarheid - die los staat van de uptime van het één of andere device .

Die hele evolutie zie je in de stappen van bare metal -> virtual server -> container / micro service .
De verwachte 'service time' apparaat daalt met factoren van bare metal naar VM naar container naar micro service.
Upspinnen als nodig, en down als niet meer nodig.
Wat daar mee samen gaat is de noodzaak van een snellere startup tijd - als je vaker 'on demand' iets nodig hebt, is een lange startup niet meer acceptabel .
Eéns in de drie jaar een filesystem check van een half uur is te overzien. Dat is niet zo als dat op dag of weekbasis moet, en nog minder als je praat over minuten usage .

De voortgang op alle vlakken naar een snelle startup - van journaled filesystems naar parallele initialisaties is daardoor gedreven.
Met de stap naar virtualisatie volgt dat de "hardware" configuratie lang niet zo stabiel meer is als in de tijd van bare metal servers - allerlei voorheen statische devices zijn hot-pluggable geworden. disk-controllers, NICs, en zelfs CPUs .
In de tijd van bare metal kon een admin rustig statisch in de config van alles hard coden (eth1,eth3), want dat veranderde pas als iemand een server down bracht, uit het rack trok, de kaarten eruit schroefde en iets erbij zette). Een uitgebreid geplande maintance , vrij zeldzaam.
Met VMs - en mobiele devices - zijn veranderende 'hardware' configuraties zo normaal dat het handmatig tweaken of dependencies uitvogelen (eerst juiste netwerk, dan NFS/iSCSI e.d.) door het systeem gedaan moet worden.
Dat is waarom systemd zo snel en breed de startup wereld heeft overgenomen .

FWIW , ik heb ook servers met hoge uptime gerund voor grote (>100K) userbases, deels internet facing.
Overigens was noodzakelijkerwijs (SSL updates e.d.) de uptime van primaire processen al korter dan de server.
En ik heb me gerealiseerd dat het verkeerd is om _bang_ te zijn voor een reboot , en daarop zijn we structureel failovers gaan plannen - met reboots. En roulerend over het beheerteam.

Als je praat over uptimes van jaren , dan heb je mensen in je team die gewoon nog nooit een reboot/outage van die server hebben meegemaakt. Maar wel meelopen in een on-call rooster . Dat is geen gezonde situatie.

Wat gepionierd is door Google ooit - bouw je _dienst_ op de mogelijkheid dat hardware - servers, racks, datacenters - kan uitvallen - en zonder dat de _dienst_ daar fataal last van heeft. Dat was een enorme omzwaai van de mainframe (en high end server) mindset van extreem betrouwbare (en extreem dure) single points of failure zoals een centraal mainframe .

"Vroeger" was een uptime van enkele maanden/jaren stoerdoenerij in het ICT-wereldtje. Tegenwoordig moet je gewoon om de zoveel tijd herstarten zodat je weet dat je server dat ook aankan en niet omvalt vanwege 1 of andere patch/update. Je kan wel een uptime van een jaar hebben maar als deze plots herstart moet worden om wat voor reden dan ook en je ervaring zodanig is dat specifieke software daardoor ineens niet meer werkt of services niet meer goed opstarten wat heb je dan aan die ervaring? Precies niks. Dan maar liever elke week herstarten en weten dat keer-op-keer al je services goed "up" komen.

Het maakt nogal uit of je systeem dat testen faciliteert. Heb je een systeem waar je dingen met de hand kan doen én je stukken van de opstartroutine handmatig kan doorlopen, dan is het niet heel lastig om wijzigingen aan te brengen die met hoge zekerheid ook bij de volgende reboot correct zullen worden uitgevoerd. (*BSDs met hun rc.conf en bijbehorende shellscripts.)

Of je serverpark. Je wil je testen niet op productieservers doen, en een buildbox om zelf patches toe te passen of custom packages te klussen is ook erg handig.

Met als prijs een vrijwel complete onbeheersbaarheid door een zekere software-suite. (*kuch* poettering z'n rotzooi *kuch*)

Nu is dat wel te begrijpen, als er iets misgaat met de container schiet je 'm af en bouw je 'm opnieuw. Als dat nog te doen is. Er zijn ondertussen genoeg "full stack"/"devops"-knutselstukjes die in z'n geheel niet meer te beheren, te patchen, herconfigureren, of zelfs te reproduceren zijn. Dus om dat maar "voortgang op alle vlakken" te noemen... ach, de industrie beweegt zich in cirkeltjes, dat doen ze ook al een tijdje. Met iedere keer weer meer complexiteit, dat dan weer wel.

Overigens heb ik nog veel snellere startups gezien dan wat tegenwoordig voor "noodzakelijk" wordt gehouden, op veel minder snelle hardware. RISCOS direct uit ROM is daar een voorbeeld. Crasht weleens, maar herstart binnen een paar seconden, en dat op hardware waarbij de megahertzen nog in de lage tientallen lopen.

Dat is ook niet nieuw. Alleen heette hardware die dat soort fratsen had vroeger "mainframe". En had het beter voorelkaar dan "servers" die eigenlijk nog steeds aannemen dat er altijd iemand voor het apparaat zit om op een knopje "ja schiet nu op doe nu maar" te drukken of te klikken.

Daar zit vooral een groot stuk politieke druk achter, red hat vs. oracle die druk bezig is red hat hun lunch te jatten.

Dat is ook wel duidelijk als je tussen de regels doorleest: De executie van die code is werkelijk om te huilen. Dat kan zoveel beter. Sterker nog, er bestonden betere en robuustere alternatieven geschreven door mensen die wel "met de community" samenwerkten en zich niet gedroegen als arrogante huilebalken. Dus waarom deze prutsers hun code overal binnen wisten te wurmen? Politiek gekonkel. Binnen een wereldje van techneuten die helemaal geen zin hebben in politiek gekonkel en er dus ook helemaal niet op bedacht zijn als ze wel ineens aan alle kanten gemanipuleerd worden.

Verstandig, maar ik hoop dat het niet het enige is wat je gedaan hebt, want:

Alleen maar productie en geen speeltuin voor (aankomend) beheerders is ook niet goed.

Dat kon ook alleen maar gezien de structuur van zowel de dienst, zoekresultaten en als je hier geen antwoord krijgt vraag je het toch ergens anders, als de "connectionless"-heid (tcp niet, http wel) van webaanvragen. Maar dat gaat lang niet altijd op en je programmas zo bouwen dat de "state" automatisch wordt bijgehouden is niet eenvoudig. Tenzij je bouwt op iets dat dat wel biedt. AS/400 is hier een voorbeeld van.


Uptime was een beetje een fad, en een van de eerste keren dat ik daar wat perspectief op zag was toen iemand vloekend en tierend mijn reguliere irc-hangout binnenkwam. Stroom was uitgevallen, uptime van echt heel veel jaren (10+?) foetsie. Dat was een VAX, zo'n hele grote. Zelfs de beste Unix kon daar niet aan tippen. VMS met hun clustering had ook hele hoge uptimes. Dat maakt de Unix wereld, zeker de vrije Unix-achtigen, met hun streven naar zoveel mogelijk dagen uptime lief, maar toch een beetje amateuristisch.

Je kan het tegenwoordig nog steeds wel, inclusief updates. Er zijn live-patching truuks voor de linux kernel bijvoorbeeld. Maar eigenlijk is dat een beetje hopeloos. Het probleem zit hem erin dat eigenlijk alle enigszins gebruikelijke OSen nog steeds monolithisch zijn (inclusief macos, ja). Met een (echte) microkernel kun je bijna alles live updaten behalve de microkernel zelf en wellicht de driver van je rootdisk, en dat zonder allerlei extra code in je kernel om het mogelijk te maken. Heb je clustering en procesmigratie dan kun je zelfs de microkernel vervangen. Het probleem is alleen dat die techniek wel bekend is, maar overwegend niet in productie buiten een paar niche-toepassingen. Wat dat betreft is de state of the art nog steeds opgekalefaterde desktop uit de '90s.

Die tellen ze wel mee. Het gaat namelijk om een hosting service! Ik heb alleen verkeerd gelezen. Saving is 30% en geen 70 Wat wel aardig is dat dit er ook staat: The only problem, she noted, is that it's unclear how much interest there will be in the virtual server idea. "We don't really know what the demand is for that now," she said.
Klinkt een beetje als meneer Bell, toen hij zei dat er misschien nog een paar telefoons moesten komen.

Het bestaat nog steeds: https://www.ibm.com/it-infrastructure/z/zvm Let eens goed op dat RACF deel.
Stamt uit uit 1972 http://www.vm.ibm.com/vm40hist.pdf Een standaard aanpak regelmatig (2 wekelijks) booten van andere system disks zodat apars en alles getest in productie genomen konden worden.
Er werd toen nog over beheer nagedacht.

Ook wel logisch want rebooten duurde erg lang. Verder een indrukwekkend verhaal (toen al 1000 linux VM's op 1 hardware footprint!).

Onzin, Amdahl met UTS presteerde veel beter. 500 man op 1 hardware footprint geen enkel probleem. Desalniettemin was DIgital een mooi bedrijf. Zo veel mooie producten, maar het management lag meer te slapen.
DEC Alpha (toen al 64 bit) was echt uniek met Linux. Crashen deed het niet. Dat was meer een INtel ding. Die CPU's hobbelen wel door ook al gaat er van alles mis.

Uuuuhh. Er zit daar wel wat onzin in. Inderdaad was een DEC een mooi bedrijf - met een moeilijk probleem.
Hetzelfde moeilijke probleem dat gedeeld ging worden door alle propietary systeemvendors - wat voor reden hebben klanten nog om tig keer meer te betalen voor jou dan voor een 'commodity' systeem.

DECs cash-cow, de VAX lijn was doodlopend qua mogelijkheden om door te ontwikkelen in snelheid. DEC heeft toen de Alpha's ontwikkeld - bijzonder indrukwekkend en een tijd lang absolute performance kampioeen. Alleen de totaal niet compatibel met de VAX lijn , en de klanten zaten niet voldoende locked-in om "op DEC" te blijven. Als ze _toch_ een hele infra en software moesten migreren kon dat ook naar iets anders dan DEC-Alpha.
Je kunt je afvragen wat DEC management echt anders had kunnen doen en of DEC dan wel relevant gebleven was.
High-end CPUs (en systemen) ontwikkelen is extreem duur , en die kosten moet je terugverdienen op je verkochte producten.
Als dat relatief kleine aantallen zijn, moet je erg veel geld per systeem vragen - en moeten je klanten een reden hebben waarom ze dat willen (blijven) doen - Bij IBM is de reden dat die resterende klanten in software en bedrijfsproces helemaal locked-in zitten op een IBM mainframe.
De DEC klantenbase zat niet _zo_ vast . Noch de SGI klantenbase (ook daar kun je, deels terecht, boos zijn op het management) . En de klanten van Sun zagen ook steeds minder redenen om de servers bij Sun te kopen.
X86 CPUs verdienen de ontwikkelkosten terug over miljoenen CPUs.
(De Dec Microvax II verkocht tussen 1985 en 1987 65000 systemen. IBM PC en klonen verkochten 14.000.000 systemen .)

Het is pure onzin dat de Alpha _processor_ (vs de X86 _processor_ ) wat te maken heeft met systeem crashes.
Sterker - in de vroege jaren van Linux-Alpha was dat gewoon minder stabiel omdat er nog een hoop software niet zo 64-bit clean was. Linus is (later) de Alpha behoorlijk gaan haten vanwege het heel zwakke geheugen coherentie model .
Een een hypothetische wereld waarin Alpha gewonnen had zou dat nog heel veel pijn gedaan hebben in multi-core/multi-thread systemen.

Wat wel een feit was - een Alpha processor zat typisch in een 'enterprise server' - goede kwaliteit onderdelen, ECC , goede koeling e.d. Een x86 CPU kan in van alles zitten, waaronder een budget mobo met budget geheugen zonder ECC , een kleine koeler en een vage klonen nic . Dan zul je _om die reden_ meer x86 systeem crashes zien .
Maar het is gewoon lulkoek dat zo'n verschil ligt aan de geweldige CPU ligt dat 'die wel doorhobbelen' .

Dat zijn allemaal deeltesten - een gehele test kost je een reboot. Een deeltest geeft je (ook) ook een gedeeltelijke storing meestal (herstart van een service ) .
Daarnaast zijn er de afhankelijkheden die de rest van het server landschap heeft op de server die eventueel in storing gaat.
Ook daar kunnen dingen langzaam insluipen.


Ook bij de grotere namen waar ik gewerkt hebt was ontwikkel en test een 'representatief schaalmodel' van productie.
Er is dan _nooit_ sprake van een blinde rsync van test naar productie , maar wat 'kleine wijzigingen'. Andere NIC , ander subnet, host of domein (domain.prod, domain.test ). Minimaal, niet relevant voor een functionele test, maar het betekent dat je bij omzetten naar productie 'wat moet aanpassen'.

Of iets echt werkt - zeker redundantie en disaster recovery weet je uiteindelijk pas als je dat een keer test.

En als iemand praat over jaren uptimes - dan hoor ik dus 'jaren niet getest' . Of testen alleen maar in het testlab gedaan - heel goed, dat moet je eerst doen. Maar niet voldoende.


Tsja , in een IT carriere moet je eens in de zoveel jaar eens _echt_ iets nieuws gaan leren.
Fantastisch dat je van 1980 tot 2010 kon voortkabbelen met grosso modo hetzelfde, maar soms gaat de wereld even in een stroomversnelling.


[..]

Mijn C64 met 0.9 Mhz wint het daar nog van. sub-seconde boot. Ja en.
Ringkern geheugen was non-volatile . Nice.


Huh ? De reden dat 'hot-plug' zo normaal is, is dat je dat een VM management console doet - maar het guest OS moet omgaan met het feit dat z'n "platform" andere specs krijgt . Je hoeft echt niet voor een server te staan om een VM meer of minder resources te geven.


Dat is een heel rare theorie voor een bijna totale overstap die alle distro's van enige betekenis gedaan hebben
Het _landschap_ van grootschalig Unix beheer is veranderd, en iedere distro die daarin relevant wil blijven moet iets leveren waarin snelle boottijden en beter dependency beheer van services tijdens opstarten geregeld is.



Zo'n beetje alle klaagzangen die ik tegenkwam lazen als hobby admins en mensen die 'ambachtelijk' beheren op kleine schaal .

En van alle spelers die werkelijk Unix systemen op heel grote schaal gebruiken kwamen de klachten niet . Noch een alternatief systeem . Waar ze wel degelijk de developers hebben om waar nodig hun eigen wensen te laten implementeren.
Dan ben ik heel snel klaar met samenzweringenstheorieen en zielige techneuten die niet zouden kunnen manipuleren .
Alle distro's die in het segment van grootschalig en geautomatiseerd Linux gebruik spelen zaten met hetzelfde probleem - en kozen allemaal voor systemd . Dan is er toch echt iets wat de alternatieven _niet_ boden, en dat is een oplossing voor het probleem.


In het pierenbadje moet je leren, maar ooit moet je in het diepe.
Je bouwt je systemen zo goed mogelijk, je bouwt redundantie waar haalbaar/mogelijk/gewenst, en je doet maintenance en failover testen horen daarbij - ook op productie. Dat is uiteindelijk waar je dingen redundant voor hebt - omdat een component uit moet kunnen vallen.
Of, als de keus gemaakt dat ze niet redundant hoeven, waarom je soms een (geplande) outage moet accepteren vanwege maintenance.
Een deel van de 'redundantie' is vaardigheid en zelfvertrouwen bij alle personen die de lul kunnen zijn als het onverwacht nodig is.
En daarbij stap je dus af van de ultra-hoge uptimes op individuele systemen als doel en 'bragging rights' .


Dat is een beetje te simpel antwoord - onderliggend aan search is een waanzinnig grote database - die dus ook verspreid en ultra-high available is. Als _dienst_ . Niet als individuele server, rack of DC.
En op dat storage concept is 'gmail' gebouwd. Ook erg gedistribueerd.
Pre-google (en legacy) denkt men nog steeds in "database, redundante server, database replicatie naar tweede datacenter op enkele tientallen kilometers afstand ' e.d.
Als je zegt 'state' zeg je feitelijk meteen 'beperkt schaalbaar en moeilijk redundant te maken' . Dat is inderdaad precies waarom de klassieke oplossingen een schaalplafond hebben.
Het vergt inderdaad wel een andere manier van denken aan de programmeurskant - en dat is wat google destijds zo bijzonder maakte - vergeleken met ooit Alta Vista.


Je lijkt het concept nog niet te snappen - het gaat NIET (meer) om hoge uptimes of rete ingewikkelde software truken om een bepaald draaiend systeem eeuwig draaiend te houden.
Dat systeem draait met een _reden_ . Om DNS queries te beantwoorden. Of om via IMAPS mail aan te bieden. Of om betalingen mee te verrichten. Of om F1 races mee te streamen. *Dat* is wat door moet draaien - die DNS antwoorden, of de mogelijkheid om de mail te blijven ophalen, of de betalingen te doen,of die films te kijken.
De state of the art is niet om dat door de dezelfde bak ijzer in het hetzelfde rack in hetzelfde datacenter te laten doen, maar te zorgen _dat_ het 'altijd' _ergens_ gedaan wordt als erom gevraagd wordt. En dus de koppeling tussen de beschikbaarheid van de dienst aan de beschikbaarheid van een individuele server weg te halen.

Als je om de een of andere reden gebonden bent om dat met heroische inspanning door diezelfde bak te laten doen terwijl daar van alles live op gepatched moet kunnen worden - dat is steeds meer een (legacy) niche - misschien nog een vrij grote niche (ik geloof dat mn Oracle er veel op inzet) , maar m.i. conceptueel achterhaald.

Linux is van eind jaren 90 en dan nog in de kinderschoentjes als een aftreksel Unix. (licentiekosten AT&T)
We hebben het hier over jaren 60 70 begin jaren 80. Het was de tijd van E. Dijkstra.
Er was zeker een grote invloed vanuit wetenschap naar wat je nu gesloten systemen zou noemen. De software conferentie nato 1968 1969 is er een voorbeeld van.
Hoge hardware kosten en de grote impact was een garantie dat er goed nagedacht werd over gevolgen van acties. Zomaar wat doosjes neerzetten omdat ze weinig kosten is geen garantie voor kwaliteit.

Amdahl Fujitsu waren alternatieven in hardware delen voor IBM. Dat vond IBM niet leuk. Chips ic's bestonden nog niet, die kwamen eind jaren 70 pas door. Het was veel printplaat werk. De verwerkingssnelheid in een aanduiding als mips..

Die ontkoppeling van security in aparte delen met open interfaces is een wezenlijk. Alleen VMS had ook zoiets, dat is naar een ander OS doorgezet. In de huidige chaotische werkwijze dat beveiliging afgedaan wordt als iets wat in de applicatie wel achteraf gedaan kan worden, is niet best voor de stabiliteit. Je systeem mag up zijn, beschikbaarheid meet je als prestatie voor het doe, dat is: de verwerking voor de organisatie.

https://en.wikipedia.org/wiki/Availability is een van de letters van de CIA waarmee je aan een BIA probeert te voldoen.

"Linux is van eind jaren 90 en dan nog in de kinderschoentjes als een aftreksel Unix. (licentiekosten AT&T) "

1991 om precies te zijn: https://en.wikipedia.org/wiki/Linux

en het gebruik van het woord aftreksel is duidelijk een mening en geen objectieve constatering van jouw.

verdr is dat geratel van je over AT&T gerelateerd aan GNU en niet aan Linux (de kernel) zelf.

Maarja een karma die eens accuraat is in zijn uitlatingen, is ook pas mogelijk als de varkens kunnen vliegen. nietwaar?

"Als je om de een of andere reden gebonden bent om dat met heroische inspanning door diezelfde bak te laten doen terwijl daar van alles live op gepatched moet kunnen worden - dat is steeds meer een (legacy) niche - misschien nog een vrij grote niche (ik geloof dat mn Oracle er veel op inzet) , maar m.i. conceptueel achterhaald."


ik denk dat je hier even enkele dingen doorelkaar haalt;


je hebt gelijk voor gebruikers maat het niet uit of nu server 1 of server 2 hun requests afhandeld. voor beheer en de orgranisatie maakt het wel een beetje uit. er is een verschil tussen de situatie dat je te maken hebt met twee of met tientallen servers in een HA cluster [side track: vele HA clusters zijn dat maar ten delen, het kost allicht een paar microseconden te switchen en gaat alleen echt goed bij sessie-loze protocollen en vaak zie je dat ondanks allerlij voting mechanismen er ook HA implementaties in het veld bestaan die klassieke regel techniek fouten bevatten en dus in een ogedefineerde state terrecht komen bij een fail over met vaak het gevolg dat de 'down-time' van microseconden oid eerder seconden of minuten wordt en dat KAN een issue al zijn bij sommige tokos].

en ik denk dat je met een beperkte web-sitje-server only kijk de zaak belicht:

kortom, als je een situatie hebt waarin de server live gepatched kan worden en requests netjes afgehandled worden en nieuwe requests met de gepatchte software opgepakt worden, dan heeft dat invloed op je IT omgeving vwb size, complexiteit en beschikbaarheid. daar is een buisness-case voor te maken dan. dat live patchen (met bijv oracle, if you want) geeft je een extra beetje meer efficiency die misschien voor jouw wel belangrijk kan zijn en om serieuse centen kan gaan [denk aan wallstreet] en de je mogelijkheid geeft de patch/reboot window te mikken op een convenient time en toch steeds 100% security op orde hebben.

een andervoorbeeld is in de HPC wereld waarin lang durige simulaties met een dead line, die als die niet gehaald worden serieuze consequenties gaan hebben, onderbroken worden omdat er een update voorbij komt op de een of andere dinsdag en waarbij het dan gokken is of je daarna wel weer 'up' komt.

een OS/systeem dat live patched kan worden gaat automatisch hogere uptimes laten zien, is de praktijk.

bronnen:

https://www.pcworld.com/article/238068/how_linux_mastered_wall_street.html
https://www.infosecurity-magazine.com/blogs/linux-kernel-live-patching/
https://scholarworks.iu.edu/dspace/bitstream/handle/2022/21077/HPCSYSPROS16_Paper%201_Moye.pdf?sequence=3&isAllowed=y

hier wat statistieken:

https://uptime.netcraft.com/
https://www.monitis.com/blog/linux-versus-windows-os-impact-on-uptime-and-speed/

Een Linux 1.2 kernel met 3 jaar uptime toen uptime nog iets was om trots om te zijn. Er zat een deadlock in de kernel waardoor de load Artificiaal hoog was (load van 100 terwijl de belasting 0.1 was). Een tellertje binnen het VMM systeem niet goed ook maar hij pakte nog makkelijk een jaartje extra.

Toen kwamen die grote kernels (ik compileerde Linux kernels onder de 300kb met monolitisch alle modules erin) en toen begon Linux ook buggy te worden. Steeds weer zorgen dat je de laatste kernel had. Daarom ben ik in 2003 naar BSD geswitcht.

Tegenwoordig is uptime een teken dat je je systemen niet patched. Zeker als u Linux gebruikt. Het is eenmaal het populairste platform dat de meeste aanvallers trekt (na Windows)


groetjes, DNightshade

Niets is zo dodelijk as het tegenvoorbeeld: https://en.wikipedia.org/wiki/Knight_Capital_Group
Er zijn er veel meer. Als de kosten belangrijker zijn dan de kwaliteit dan moet je raar opkijken als je in de put verdrinkt.

Ik had een uptime van 60 dagen, daarna moest ik toch mijn kernel weer updaten.

Het blijft tenslotte Linux he.

ik zie daar voornamelijk een beheerder die een foutje heeft gemaakt.
Heeft niets met een OS, Uptime of HPC te maken....

Dat is niet het tegenvoorbeeld, zelfs niet eens een tegenvoorbeeld. Is je al vaker uitgelegd dus hou op met dezelfde onzin te verkondigen. Roep eens wat nieuwe onzin! Of liever geen onzin, maar laten we met kleine stapjes beginnen.

Kwaliteit kost ook wat. Maar is in het geval van wat je aanhaalt ook al niet echt een factor geweest.


Dat is toch al weer een paar dagen meer dan 49,7 dagen. Vooruitgang!

De uptimes hier zijn vooral gelimiteerd door externe factoren, zoals medehuurders die de aardlekschakerlaar eruit laten klappen.

joh het is geen ver pis wedstrijd.

verder snap ik je punt gewoonweg eigenlijk niet, de vraag ging om uptime en niet om fouten geintroduceerd door beheerders oid. live updaten en patchen kan nog steeds met beleid en vier ogen princiepe en volgens checklists met procedures.

Buiten alle (nuttige) discussie over het onderwerp uptime, mijn antwoord op de vraag van de OP:
- Desktop (linux) haalt meestal niet meer dan een paar uurtjes, dat komt voornamelijk omdat ik hem uitzet als ik hem niet gebruik :-)
- De rest (servers, router, etc., ook linux): Maximaal 90 dagen, daarna ga ik ze updaten

Mijn uptime record is 671 dagen op een raspberry pi 2b die ik als ntp server gebruik. Tegenwoordig gaat die ook mee in de 90-dagen cyclus. Kernel updates kreeg hij toen niet, alle overige updates kreeg hij wel mee.

Foei, dan heb je een keer niet gepatcht want er zijn minstens 2 kernel updates geweest in die tijd.
Daarnaast heeft het niks met Linux te maken. LInux is alleen een kernel en die kan live gepatcht worden indien vereist.

Uptime is niet van belang als integrity en confidentiality net zo belangrijk zijn naast availability.
Als je goed leest waar het mis ging was dit die balans zoek was.

Dit is terugkerende issue wat ik probeer aan te kaarten.
Problematisch omdat je dan tegen de muren van een "kijk mij eens belangrijk zijn" aan loopt. Uptime is zo'n kreng.

- je eerste zin is tegenstrijdig: iets is niet van belang als twee andere dingen net zo belangrijk zijn?
- je communiceerd onduidelijk met 'blurps' die niet te volgen zijn en bij doorvragen verandert het onderwerp.
- terug on topic en meteen maar een correctie weer:

availability is niet hetzelfde als uptime en stabiliteit / betrouwbaarheid van een systeem: https://en.wikipedia.org/wiki/Uptime. wel is meteen duidelijk, dat het concept availability geen waarde heeft als er niet eerst spraken is van enige stabiliteit of betrouwbaarheid.

Het terugkerende issue is je frustratie dat er wel ergens een OSS oplossing is die het beter doet dan jouw windows.
Lees je eigenlijk wel eens je eigen tekst door?
Hoe zo is Uptime niet van belang als integrity en confidentiality net zo belangrijk zijn? Hiermee haal je jezelf onderuit.
Je zegt dat uptime niet van belang is en vervolgens in een bijzin weer van wel (net zo belangrijk slaat namelijk op het onderwerp!)

NetBSD overduidelijk de winnaar!

NetBSD is ooit opgericht door o.a. Theo de Raadt. Hint: zoek uit wie deze persoon is, en dan heb je geen security problemen maar oplossingen.

Tijd om de updaten is wat uptime je vertelt. :)

Nou nee - ik ben bekend met allerlei HA varianten. Noodzakelijkerwijs in een paar forumposts stap ik met wat zevenmijlslaarzen tussen varianten die nauw gekoppeld zijn (het extreme voorbeeld zijn lock-step systemen zoals bv Tandem ooit deed), naar heel veel losser gekoppelde varianten zoals een DNS record update als mechanisme.

Wat ik probeer duidelijk te maken - (en daarbij de typische enterprise mindset een beetje te challengen, en de old skool "wie heeft de langste ... uptime " prikkelen) is dat er een heel landschap van design keuzes is of en waar 'state' uit hangt. En waar en op welke OSI laag een eventuele failover keuze komt te loggen.
Dat 'state' niet per definitie iets is dat hoeft te leven in de vorm van datastructuren in de RAM van een Heel Belangrijke Server Die Nooit Down Mag.
Afhankelijk van eisen en gebruik kan het keuze zijn dat de clients voldoende state meegeven bij iedere transactie. Of dat je accepteert dat state reconstrueerbaar is bij een switchover ten koste van een stuk performance .

Eén absoluut gegeven is dat als alle 'state' op een centraal - eventueel redundant - device moet leven dat een schaalbaarheidsplafond legt op de service. En ook op de maximaal haalbare availability - je noemt terecht de beperking van de gebruikelijke HA cluster systemen, zoals de risico's van split-brain gedrag .
Wat je niet expliciet noemt , maar wel een feit is - al die klassiek strak gekoppelde HA systemen willen op heel low-latency van elkaar staan. Ik schreef niet voor niets eerder 'datacenters op enkele tientallen kilometers afstand' . Daarop bouw je geen globale service .

Natuurlijk heb je als designer zelden of nooit een zodanig blanco sheet dat alle keuzes op alle niveaus open zijn.

Maar als je met oogkleppen kijkt dat "redundantie" altijd is "database op cluster" , of dat "HA" synoniem is voor "loadbalancer" dan wel "server met live-patchable kernel" dan mis je zo af en toe betere keuzes.
Je kan in een zodanige omgeving zitten dat een heel erg betrouwbare centrale server een lokaal optimum is - die niche is best groot . En wordt heel veel erg betroubware hardware verkocht daarvoor, met een software landschap zoals live patchable kernels.
Maar dat is niet de enige manier waarop diensten gebouwd kunnen worden , en sommigen die met een voldoende blanco sheet begonnen hebben services gebouwd die _niet_ afhankelijk zijn van een centrale server of een centraal nauw-gekoppeld cluster.

Je kunt een analogie zien met de state of art circuit-switched technologie - en wat een landschap aan alternatieven mogelijk werd op moment dat het concept "packet switching" als basis genomen wordt voor een netwerk.


Je lijkt te denken dat omdat het HTTP protocol stateless is, alle webservices stateless zijn. Dat is natuurlijk niet zo.
Ook webservices kunnen state bevatten, het zit alleen in de payload van HTTP (cookie), in de URL, of verder meer in de applicatie laag.
Google (en vergelijkbare hyperscalers) is een voorbeeld van wat je kunt bereiken - en moet doen - qua schaal en betrouwbaarheid - zonder een Heel Erg Redundante centrale server als primaire component te nemen.

Ja - *als* je ergens heel erg afhankelijk bent in je dienst van een Heel Belangrijke Centrale Server , *dan* is live patching (naast alle hardware redundantie) een heel goede techniek om te hebben.


Je _zou_ verwachten dat ook HPC het kunstje 'auto save' van desktop wereld inmiddels heeft overgenomen, en de hoeveel heid verloren werk te overzien is bij een onverwachte storing.
Ja - ik _heb_ stroomstoringen aan beide feeds 'die niet hadden mogen gebeuren' meegemaakt in high end DCs. Shit happens.

En je (ook ik) kan niet alles kiezen - er is een enorme stuk markt dat heel veel complexiteit in een (datacenter) netwerk bouwt om een VM met behoud van alle eigenschappen (ip/subnet/vlan/mac) door het datacenter te kunnen migreren. Puur omdat zoveel IT servers/OSen/applicaties gebouwd zijn op het idee dat hun vlan/ip/subnet heilig en onveranderlijk zijn.
Maar als je iets bouwt waarin dat niet het uitgangspunt is zijn heel veel van je schaalbaarheid en redundantie problematiek vanzelf opgelost.


Dat geloof ik vast - maar waar ik kan kiezen heb ik liever dat de uptime die er toe doet (die van de dienst) niet zo hard afhangt van de uptime van een enkele component .

Dit zei iemand er van: a bunch of masturbating monkeys, in that they make such a big deal about concentrating on security to the point where they pretty much admit that nothing else matters to them.

Kan het nou ook eens zonder direct te gaan haten op Windows? Het product werkt prima binnen ons bedrijf. Goed ingericht, altijd up-to-date en (even afkloppen) nog nooit een breach gehad. Hooguit het gebruikelijke "ik ben een gebruiker en ik klik op een link waarna ik mijn wachtwoord invul".

Dat Linux voor jou werkt wil niet zeggen dat het voor de rest van ons ook zo zal werken. Ik durf te wedden dat de mensen hier met niets anders dan Windows overweg kunnen, dus overschakelen zou niet eens gaan als we het al zouden willen.

Het gaat hier over uptime, dan loop je vanzelf tegen de maandelijkse windows reboot aan. Dus kwa uptime niet best gesteld. Heeft niks met haten te maken of dat je naar Linux zou moeten overstappen. Ik zou niet gaan wedden. Beetje een zinloze opmerking.

Inderdaad een beetje zinloos om als doosjes fanaat te kraaien over je uptime terwijl de organisatie in de kou staat.
Ooit werd gezegd: groot succes operatie geslaagd, helaas is de patiënt overleden.

Waarom misbruik jij mijn opmerking en is windows voor jou zo belangrijk? en mogen anderen geen voordeel halen uit meer uptime als dat een optie is?

Oké, on topic gaat het over uptime.

Ik werk voor een bedrijf met verschillende productielocaties verspreid over de wereld, daarmee verschillende tijdzones etc. Maar desondanks kunnen wij prima een onderhoudsuurtje inplannen voor de maandelijkse reboot voor veel servers. Wij hebben ons proces grotendeels geautomatiseerd en hebben er eerlijk gezegd niet veel werk aan. We vertrouwen op het testen + ons monitoring systeem om eventuele fouten snel eruit te halen.

Ons meest kritische servers hebben wel een hogere uptime omdat dit veeval Windows server core versies zijn. Daar zijn sowieso minder updates voor beschikbaar/noodzakelijk. Die willen best wel eens een uptime hebben van ~6 maanden. Moet daar wel bij zeggen dat deze zijn afgeschermd van de rest van het netwerk en alleen vanaf bepaalde control PC's te benaderen zijn. Daar durven we bepaalde updates ook uit te stellen tenzij een update echt kritisch blijkt.

Begrijp me verder niet verkeerd hoor. Ik heb niets tegen Linux, we draaien zelf een aantal Linux machines waarop o.a. onze monitoring software draait. Ik kan de basis zaken prima doen en het werkt voor mij ook prima. Maar Windows werkt bij ons ook gewoon goed, is goed ingericht, bijgehouden, gemonitord. Bij onze zusterbedrijven werken ze ook voor ruim 90% op Windows en we hebben gezamenlijk toch vele honderden servers.

Uptime van een doos is iets als, ik heb de grootste. Echt helemaal niet van belang.
Zoals de server up and running wanneer dit nodig is, kraait er echt helemaal niemand naar.

Dat zeggen alleen beheerders die met windows werken, want geen keuze. Daarom draaien de professionals zoals Amazon, Twitter, Facebook, Google, Wallstreet, London stockexchange etc geen Windows. Blijkbaar wel van belang. Niet alles is horizontaal schaalbaar.

Ach, een pool van servers is zo gemaakt. Altijd uptime.

Zal best, totdat walmare verschijnt want je slaat toch patches over voor je core servers. Segmentatie werkt alleen vertragend.

Zijn er in die twee jaar tijd essentiele updates/upgrades uitgekomen, waarbij een reboot noodzakelijk is, tijdens installatie (kernel upgrades, bijvoorbeeld) ? Zonder een reboot, blijf je op de verouderde kernel draaien ? Gaat het streven naar zo lang mogelijke uptime, ten koste van andere zaken ?

Een hypervisor rebooten is niet iets waar je maandelijks op zit te wachten. Dan moet je al je VM's eerst live migreren naar een andere VM. Dat gaat met Exchange stores niet altijd goed zag ik bij mijn buurman. Uiteindelijk gaat het om de applicatie, daarom is net genoeg OS belangrijk en zijjn containers populair.

Een hypervisor hoef je over het algemeen ook niet maandelijks te rebooten. En in het geval dat je dat wel wilt of moet om wat voor reden dan ook, dan moet het wel heel gek lopen wil jij problemen ervaren binnen een VM.

Nee, zoals gewoonlijk heb je weer geen enkel idee wat een klant nodig heeft.

Ik heb nog nooit een klant gehad, die vroeg, wat is de uptime van mijn systeem geweest. Ze zijn alleen geïnteresseerd SLA van de dienst, of wel de beschikbaarheid.
Als ik mijn servers iedere dag moet rebooten, who cares. Zolang gebruikers er geen last van hebben.

Sterker nog… Veel diensten worden tegenwoordig bijgeschaafd afhankelijk van de load. In de nacht zetten we servers uit. In de ochtend zetten we ze weer aan. Scheelt behoorlijk in de kosten

Ik noem even iets als Azure, Office 365....

De meeste die je noemt zijn trouwens ook weer compleet verkeerd. Want... Bij de meeste bedrijven hebben ze echt helemaal niets met uptime. De omgeving is zo gemaakt, dat op basis van load er bijgeschaald wordt.
OS Patches worden vaak niet eens geinstalleerd. Gewoon nieuwe omgeving bouwen, load overzetten en oude herinstalleren en dan herhalen voor de volgende update cycle, of aan de huidige omgeving toevoegen.
Uptime... Daar lachten ze om. Zolang de dienst maar beschikbaar is.

En als je dit soort zware IT bedrijven met de normale bedrijven wilt vergelijken, dan laat je ook hier weer zien, dat je werkelijk geen idee hebt, hoe IT bij de meeste bedrijven gedaan wordt.


Als die buurman te veel naar jouw adviezen heef geluisterd wil ik best geloven dat het niet goed gaat.
We patchen hier zeer veel Hypervisors zonder enige problemen. Gaat volledig geautomatiseerd, zonder enige impact voor de VM's.

Live migreren van Exchange kan ook. Maar er zitten heel veel uitzonderingen op. Kans is aanwezig dat dit eerder verkeerd neer gezet is, dan dat dit echt aan Exchange heeft gelegen.
Daarnaast zijn er veel betere mogelijkheden om Exchange hoogbeschikbaar te maken. Het zit in de applicatie ingebakken en werkt gewoon heel goed.

Nou, _zo_ vanzelf gaat het ook weer niet altijd.
14 juni 09:20 in discussie met mij noemt terecht de uitdagingen bij HA en clustering.
(en ik ontken die niet).

Je wilt ernaar streven _dat_ je dienst op een pool van servers kan draaien waarvan ééntje probleemloos kan uitvallen. Of tenminste probleemloos uit service genomen kan worden.

En om het nog wat beter te doen wil je dat die pool verspreid over verschillende subnetten en verschillende DCs kan staan.
Hoe goed dat mogelijk is heeft (meestal) weinig meer te maken met het OS, maar alles met de applicatie/implementatie van de applicatie die de feitelijke dienst levert .

(Al is het wel zo dat voor enkele HA opties Linux zich van nature goed leent, en ik niet gehoord heb van vergelijkbare setups onder Windows )

Typische opmerkling van een windowsbeheerder die zogenaamd niets heeft met updates, want windows moet je toch elke maand rebooten (en vingers gekruist dat het weer opkomt).
Natuurlijk kijkt de klant naar beschikbaarheid van applicaties, een uitgestelde reboot en toch gepatcht is een strategisch voordeel tov het gebruik van een windows server die altijd moet worden gereboot. In jouw geval betaalt de klant toch wel voor de geplande downtime ook al is het een middelvinger naar de klant omdat deze tijd niet van de uptime afgaat (afgesproken in SLA). Typisch voor beheerders die zich ook nergens in willen verdiepen. Rebooten is de heilige graal en verbeteringen voorstellen is not done want Microsoft rules en als er iets mis gaat (wat we hier op security.nl elke week lezen) is het de schuld van de beheerders en noooit Microsoft. Blijkbaar is er ook iets mis met het MS certificeringstraject.

Ondertussen zie je dat windows in zo'n beetje elk gebied is uitgefaseerd behalve bij lichte kantoortoepassingen in het bedrijfsleven waar ze nog last hebben van een vendor lock en uiteindelijk een walmare lock.
Bij Google is men daarvan doordrongen en is de windows werkplek verboden na een malware incident in China.

Terug naar de reboots. Dit is de reden dat een van onze klanten bij Azure is weggegaan: reden unexpected reboots!
https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/understand-vm-reboot

Hoe je het ook wendt of keert. Als je de optie hebt om een reboot uit te stellen is het een strategisch voordeel en dat geldt ook voor Licenties, Disk RAM en CPU. Voor windows heb je altijd van alles meer nodig.

Je laat hier weer zien, dan je geen idee hebt hoe bedrijven IT gebruiken.

De keren wat we problemen hebben met Windows Patches kunnen we toch echt op 1 hand tellen. En dan hebben we de nodige servers en werkstations draaien, bij driver klanten.

Dit is bij geen van al mijn klanten ooit een issue geweest. Down tijd is gewoon een onderdeel van de change. Voor Windows Patches is dit al een jaar van te voren aangekondigd en loopt als een geoliede machine.

Goede beheerders hebben hier helemaal geen werk aan. Die hebben alles al geautomatiseerd en zich er dus allang indiept.

Volgens mij is er meer iets mis met de kennis waarmee jij werkt aan Microsoft producten.

"Je _zou_ verwachten dat ook HPC het kunstje 'auto save' van desktop wereld inmiddels heeft overgenomen, en de hoeveel heid verloren werk te overzien is bij een onverwachte storing."

tja waarom dus dan toch niet he? zouden al die mensen die HPC doen nou zo dom zijn? of zou er een diepere oorzaak zijn?

hier de clue. een HPC berekening spant vaak over meerdere servers waarbij speciaal opgezette links (infiniband bijv) tussen de servers opgezet worden en naar data opslag gaat en er is een interactie met een batch manager. ook werken ze niet met een paar megabytes oid, het gaat vaak om heel veel gigabytes tegen terabytes.

en nu denk jij dat het concept van een hibernate oid of een auto save die dan somseen uur de tijd kan kosten een optie is?

nein!

beetje off-topic,

maaeh

"Terug naar de reboots. Dit is de reden dat een van onze klanten bij Azure is weggegaan: reden unexpected reboots!
https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/understand-vm-reboot"

so hee, die cloud was toch altijd beter en stiebeler dan wat je zelf zou kunnen doen? waarom doen die niet zoiets als v-motion oid? je kunt toch niet zomaar de VMs van je klanten gaan herstarten zonder meldinge oid? wat een waanzin!

Windows patches een geoliede machine. Wat mij betreft nu al de quote van het jaar.

Om eerlijk te zijn - scientific coders en AIO's zijn goed in de rekenkernel, en niet altijd in het 'gebruikersvriendelijk' maken van de app.
Of desnoods powerusers-vriendelijk . kill -SIGUSR1 is ook een interface om app iets te laten doen, zoals een state dump.


Natuurlijk is dat een optie . Alleen niet elke tien minuten . Als je elke drie dagen een uur opoffert , heb je de garantie dat je bij een worst-case crash maximaal drie dagen werk kwijt bent . En niks kwijt bij een geplande downtime, want dan doe je de dump voordien.

Als de job 3 _maanden_ moet draaien , is dat een redelijke verzekeringspremie.
Elke drie dagen 1 uur 'niet-productief werk' => een job van 3 maanden duurt 10 uur langer .
Een crash zonder save kost je dan 'gemiddeld' 1.5 maand werk . Worst-case 2 maanden 30 dagen.
En met een save van een uur elke drie dagen kost een crash je gemiddeld 1.5 dag werk .

Je kiest een balans tussen de extra tijd die je besteed aan het maken van een tussentijdse snapshot van de toestand van de berekening, en het risico van verlies van veel meer tijd als de berekening tussentijds crasht .

Wij zijn HPC wij moeten in één keer doorgaan is onzin. (Wij zijn HPC de basis code is klaar en we hebben geen zin om een dump/restart erin te bouwen dus er mag gewoon niks misgaan - dat kan. Soms gaat dat gokje mis )

Je hebt wel gelijk als je roept dat je live binnenkomende data een het behandelen bent .
_dat_ moet wel doorgaan (iig collectie/preprocessing/opslag), want het experiment wacht niet. Ik denk dat er op dergelijke momenten gewoon een totale change freeze is.

Lees het verder door. Advies: Ik zou als klant snel een andere dienstverlener gaan zoeken.
Degene die niet weet wat HA is en waarom je dat met welke keuzes doet dient niet in de ICT werkzaam te zijn.

Die opties zitten er in, dat is correct. Over de kwaliteit van deze opties en storingsgevoeligheid ben ik toch echt wat minder tevreden. Maar goed Exchange is zolang ik het product al ken, bruikbaar met een scherp randje. Zeker icm de onderliggende databases. Inrichting is zeker belangrijk net als de patches en fixes (vergeet een hele goede backup niet).


Bij een nieuw product van MS wacht ik altijd tot de kinderziektes er uit zijn. Soms is dat binnen 2 jaar, soms wel 5 jaar. Ontwikkeling en bouwen kost nu eenmaal tijd, geld en veel moeite. Maar mijn ervaring met MS is (wil niet bashen) dat time-to-market altijd net even een paar maandjes te vroeg is. Of de optie net niet werkt zoals de "marketing slogan" pretendeerd.
Zoals de voorganger van MS wat nu Office365 heet, lag 2-3 dagen van de week eruit voor langere perioden. Echter nu is het een stabiele dienst/product.

Ik ken de achterliggende reden niet van deze klant, maar wellicht net iets te vroeg ingestapt? Verkeerde opzet?
Meestal is er wel een goed aanwijsbare reden.

Die tijd is gelukkig een beetje voorbij. Maar de kwaliteit van updates bij MS is altijd een golfbeweging. Er is een tijd geweest dat ik 1 jaar uit de IT ben gestapt omdat de updates zo dramatisch waren. Het was echt slecht. Maar niet met 1 product maar gewoon een hele serie producten. OS, SQL (mindere mate), Office en Exchange, werkelijk om te janken.

Nu vandaag de dag valt het weer mee, na wat vervelende maanden, alleen Office, Dotnet en oh ja ineens weer het printen. (KB4560960 en KB4557957)

Blijkbaar toch niet:Windows 10 users have been having a rough time for a long time. And now Microsoft has just shown why frustrated users should quit. - https://www.forbes.com/sites/gordonkelly/2020/06/14/microsoft-windows-10-problems-testing-windows-insiders-windows-10-updates/.

" Maar de kwaliteit van updates bij MS is altijd een golfbeweging. "


ha ha ha je hebt volkomen gelijk: de golf start zodra de eerste updates uitkomen en doven uit na een maandje ofzo.

Je bent blijkbaar niet in staat het onderscheid te maken tussen de boodschap (in dit geval van Forbes Magazine) en de boodschapper (ondergetekende; a.k.a. The FOSS). Indien je inhoudelijke problemen hebt met de boodschap dan zal je dit moeten opnemen met Forbes. Voor wat de rest van je commentaar betreft: ik weet niet waar je het over hebt. Maar dat zal je ongetwijfeld wel vaker horen.

Typisch journalisten stuk, sommige zaken extreem uitvergroot en deels over de 2004 update, die nog niet in de productie omgevingen wordt uitgerold. Echt een ja en nee verhaal.

Uptime was in een grijs verleden iets waar beheerders mee patsten, maar dat is allang niet meer van deze tijd. Servers zijn uitwisselbaar en irrelevant. Als het niet meer werkt deploy je gewoon een nieuwe. Als je standaarden hebt en de boel fatsoenlijk ingeregeld dan is dat zo gepiept.

Klopt Als zelfs Microsoft er niet mee zit om je VM zo maar te rebooten (en met een kernel panic achter te laten) houdt het op: https://docs.microsoft.com/en-us/azure/virtual-machines/troubleshooting/understand-vm-reboot

Heel veel is niet horizontaal schaalbaar. Daarnaast grote kans dat je weer met ellende terugkom want je hebt het probleem niet geanalyseerd. Typische windowsbeheerderaanpak. Nieuwe vorm van reboot. Servers zijn geen docker containers, waar dit inderdaad gebruikelijk is.

Uptime valt ook een beetje in dit rijtje omdat grote windows problemen uiteindelijk extern wordt opgelost:
Windows werd vroeger gehackt al tijdens het installatie proces, gelukkig kwam het ge-NAT achter een router dankzij ISP's.
Toen vereiste het te veel geheugen. Gelukkig werd RAM spotgoedkoop, toen was er te weinig CPU, gelukkig kwamen er cores. Toen was er een update probleem, gelukkig moet er elke maand verplicht ge-reboot worden. Toen was er een driver probleem, gelukkig is er virtualisatie uitgevonden en is het verschoven naar de hypervisor. Nu draait windows ook sneller gevirtualiseerd dan op bare metal en crasht het minder vaak dank zij de standaard aangeboden hypervisor resources. Toen waren er te weinig licenties maar gelukkig heeft de rijksoverheid al meer dan een miljard overgemaakt. Hoeveel precies weet men niet eens!. Toen waren er te veel malware infecties maar gelukkig ?

Waar staat dat ze "zo maar" gereboot worden?
Ik zie niet heel verschil tussen Azure en onze eigen datacenters of andere cloud providers.

Hangt natuurlijk van het probleem af. Sommige kan je sneller uitrollen dan troubleshooten. En als er een nieuwe server draait, kun je de oude troubleshooten.

Volgens mij laat je hier ook weer zien, hoe weinig je ervan begrijpt.

Waarom gelijk vol in de aanval met termen als 'windowsbeheerderaanpak'? Ik doe niet mee met die infantiele onzin en heb het ook niet over OS X of Y gehad. Adem in, adem uit. Laat de spanning van je afglijden.

Als je je omgeving goed beheert en in de smiezen hebt is nieuwe servers deployen een prima aanpak. Eindeloos priegelen aan een gare bak is zonde van de tijd. Dat een probleem terug zou komen betekent dat je niet goed getest hebt of je monitoring niet op orde is.

Artikel ook zelf gelezen? Want er vinden niet unexpected reboot zomaar plaat.

Er kan natuurlijk wel planned Maintenance plaatst vinden. Maar dit is net zoals bij iedere cloud provider. Je neemt een bepaalde dienst af, met bepaalde eigenschappen (bijvoorbeeld uptime). Is 1 machine niet voldoende, dan moet je hiervoor een oplossing bedenken in je applicatie. Net zoals in een on-premises oplossing, geen verschil hierin.
Je moet je omgeving hierop inrichten, die je dit niet, dan zit je op de blaren.

We hebben hier ook een hele grote omgeving, maar er vinden soms echt disruptive changes plaats. Gelukkig uitzonderingen, maar ze kunnen plaats vinden. Zoals ook onze SLA met het storage team, esx of networking. Bijna alles is hoog beschikbaar en gebeurt zonder downtime. Maar zo nu en dan vinden er toch incidenten plaats of moet er onderhoud plaatsvinden met impact. Dit wordt gewoon netjes gecommuniceerd van te voren. En de meeste onderhouds windows zijn al bekend. Dan dit vinden in ieder kwartaal plaats.

Maar het is niet zo, dat MS zomaar even op ieder moment je servers gaat rebooten.

Dat doen ze dus wel als er een issue is (geen communicatie met de hypervisor bv) . Mijn VM's worden in de cloud eerst live gemigreerd en al helemaal niet gepauzeerd voor een Memory-preserving Microsoft update.

Ze zullen het nu vast wel beter doen maar de downtime was vorig jaar schrikbarend hoog:

Als ik hoor een uptime voor 2 jaar dan gaan mijn haren recht op staan.
Hoeveel securtity patches heb je gemist, of is het machine niet verbonden aan een netwerk ?

Hoe staat dat in verhouding tot het totale aantal uren? Hoeveel impact op hoeveel klanten? In de VS vallen ook meer slachtoffers op de weg, maar pas als je dat gaat verhouden tot het aantal kilometers of het aantal inwoners weet je dat dat ook relatief veel slachtoffers zijn. Zonder context zeggen dat soort cijfers niet zoveel. Daarmee zeg ik ook expliciet niet dat het wel meevalt, maar wel dat er meer informatie nodig is.

Met een uptime van twee jaar moet het bijna wel een principekwestie voor de beheerder zijn en dan kan het weer bijna niet anders dan dat er ten bate van uptime keuzes worden gemaakt die ten koste gaan van andere zaken.

81 dagen van de 365 downtime is nogal wat. Dat is bijna 6 keer zo veel als Amazon (15 dagen) of Google! Voorlopig doe ik het on premise een stuk beter.

No way dat welke klant dan ook 81 dagen downtime heeft ervaren, wat het eerdere punt ook illustreert. Het is niet duidelijk hoe de cijfers geïnterpreteerd moeten worden.

Er zijn ook nu nog steeds zeer sterke argumenten voor zelf servers on-premise draaien, maar dan helpt het om die discussie op basis van objectieve gegevens te voeren. Van het eindeloze gereutel van fanboy X versus fanboy Y worden we alleen maar doodmoe.

Je negeert de vraag. Hoe moeten die gegevens opgevat worden?

Cool... JIj kan dus zo maar 8 VM's met 128Gb geheugen opstarten, verdeelt over meerdere datacenters met ieder 8TB aan storage? Nice....

Dit soort machines moet ik toch echt allemaal bestellen, wat al snel een paar maanden kost. Nog afgezien we maar 2 datacenters hebben, en ik storage ongeveer 6 maanden van te voren moet forecasten....

Maar zoals vaak. Zonder exacte informatie, zeggen cijfertjes niet zoveel. Eigenlijk exact hetzelfde als de uptime van een server.

16 GB geheugen is echt niet zo bijzonder. Hoewel snel op- en afschalen een pré is, zijn veel van dat soort verhalen toch ook vooral een indicatie van een slechte planning. Het soort VM's dat je noemt worden overigens doorgaans ook niet zomaar op stel en sprong ingeklikt.

ja gelezen:

"Azure virtual machines (VMs) might sometimes reboot for no apparent reason, without evidence of your having initiated the reboot operation. This article lists the actions and events that can cause VMs to reboot and provides insight into how to avoid unexpected reboot issues or reduce the impact of such issues."

zal het even voor je bold maken.

a.u.b.

Ik heb ook even een heel belangrijk puntje even in bold gemaakt voor je.
Ik weet niet of je de rest van het artikel ook gelezen hebt? Selectief quoten is natuurlijk erg gemakkelijk.


Planned maintenance
Microsoft Azure periodically performs updates across the globe to improve the reliability, performance, and security of the host infrastructure that underlies VMs. Many of these updates, including memory-preserving updates, are performed without any impact on your VMs or cloud services.

However, some updates do require a reboot. In such cases, the VMs are shut down while we patch the infrastructure, and then the VMs are restarted.

To understand what Azure planned maintenance is and how it can affect the availability of your Linux VMs, see the articles listed here. The articles provide background about the Azure planned maintenance process and how to schedule planned maintenance to further reduce the impact.
https://docs.microsoft.com/en-us/azure/virtual-machines/maintenance-and-updates?toc=/azure/virtual-machines/windows/toc.json&bc=/azure/virtual-machines/windows/breadcrumb/toc.json

Staat nog veel nuttige informatie in.

Kan het dus gebeuren, ja. Gebeurt het vaak. Geen idee. Ik heb in onze omgevingen er nog nooit last van gehad. En we hebben toch echt duizenden machines draaien. Van kleine gewone IAAS servers tot data lakes of SAP omgevingen.

Reken maar dat het voorkomt als Microsoft het zegt. Individuele gevallen cijfertjes zeggen niks. Voor mij ook een zeer kerkenbaar windows ding: for no apparent reason

joh, het boeit me niet WAAROM, het is gewoon de constatering DAT dit gebeurt zonder dat je daar controle over hebt of meldingen van te voren van krijgt. hoe weet jij nu zeker dat een of andere MS cowboy al dan niet per ongeluk niet die VMs tegelijk een reboot kick geven waarop JIJ je HA fail over applicatie zou hard hebt proberen op te zetten?

Houd toch eens op met dat onzinnige geschreeuw en zoeken naar problemen omdat het 'jouw' platform of merk niet is. In het artikel staat luid en duidelijk:


Als dat je zomaar overkomt ligt het echt aan jou en moet je een vak kiezen waarbij een agenda kunnen gebruiken geen vereiste is.

Typisch Souplost, halve vragen beantwoorden en zaken ontwijken. Net als karma en FOSS. Die 3 samen zijn echt de grootste flamers en fanboys op security.nl

Dat staat er ook ja, ze doen ook nog aan een netjes gemelde maintenance windows en aan maintenance waarbij ze je VM even pauzeren!, maar ook aan een niet netjes gemelde en dat wil jij niet lezen, daarom laat ik het hierbij.

Oei! Iemand anders zou weleens gelijk kunnen hebben. Gauw weglopen, dan is het net alsof niemand het zag.

"Oei! Iemand anders zou weleens gelijk kunnen hebben. Gauw weglopen, dan is het net alsof niemand het zag."

ja ja je gaat maar lekker hard blijven spinnen wat je wilt, maar het is duidelijk wat er staat:

"sometimes reboot for no apparent reason" en "how to avoid unexpected reboot issues" en er staat nergens het woord 'apear to' oid.

wacht, haal het even door google translate voor je:

"Virtuele machines (VM's) van Azure kunnen soms zonder duidelijke reden opnieuw worden opgestart, zonder bewijs dat u de herstartbewerking hebt gestart. Dit artikel bevat de acties en gebeurtenissen die ervoor kunnen zorgen dat VM's opnieuw worden opgestart en geeft inzicht in hoe u onverwachte herstartproblemen kunt voorkomen of de impact van dergelijke problemen kunt verminderen."

als je melding krijgt, dan is het natuurlijk niet meer "onverwacht" dus het stukje impliceert duidelijk dat er ook herstarts zijn znder meldingen oid. onverwachts dus.

Dat het MOGELIJK is. Niet dat het (vaak) gebeurt.
Bij AWS is dit trouwens exact hetzelfde https://aws.amazon.com/maintenance-help/

1: Dan heb jij de omgeving verkeerd neergezet. Daarvoor gebruikt je available zones / sets. Die zijn gescheiden.
2: Volgens mij zijn er vrij weinig van dit soort cowboys actief bij Microsoft, of bij andere grote cloud leveranciers. Of jij moet ander bewijs hebben? Heb je trouwens enige idee om dit soort omgevingen gemaakt zijn/worden?
3: Ditzelfde kan je in je eigen omgeving hebben. Die kans is zelfs groter, dan in een Cloud oplossing. Omdat bij de meeste inhouse de omgevingen niet zo geautomatiseerd zijn.
4: Wat is hierin het verschil tussen MS of een andere leverancier Cowboy? Bij Cloud neem je een dienst af met bepaalde eigenschappen. Voldoet dit niet, dan moet je het zelf bouwen/onderhouden.

Zoals het hoort.

Het is mogelijk, dat wil niet zeggen dat het (vaak) gebeurt. Maar hetzelfde kan gebeuren in je eigen omgeving.

Laat het daar maar bij inderdaad, verstandig.

Eerst is er altijd de bekende MS ontkenning. Als het dan onderkent wordt, betekent dit dat het vaak gebeurd.
Daarnaast grijpen ze ook in op je VM. Pauzeren, niet iedere windows VM kan daar tegen (timeskew). Ze melden zelfs in het stuk dat een LInux VM een kernel panic kan krijgen na een windows hypervisor update. Dat is helemaal van de zotte.
https://support.microsoft.com/en-us/help/3212236/an-azure-linux-vm-on-a-3-10-based-kernel-panics-after-a-host-node-upgr Daarnaast zien er veel features (fatsoenlijke templates en hot standby wat vmware al jaren biedt) voor een Linux VM niet beschikbaar. Of te wel blijf er zo ver mogelijk vandaan als je iets anders hebt dan windows. Zelfs de api's zijn k.m.p

Je weet hoe vreemd je nu zelf eigenlijk klinkt?

Dit is inderdaad een mogelijkheid. En is zeker niet ideaal. Maar dat doen de meeste cloud providers volgens mij.

Je hebt ook gezien dat dit artikel is uit 2016, met een kernal die redelijk antiek is? Maar bugs bestaan nu eenmaal, in software. IK heb ze overal al gezien, eigenlijk op alle hypervisors.
[urlhttps://kb.vmware.com/s/article/51958[/url]. Best een leuke... Linux crash op ESX ivm hun eigen vmxnet3 driver.

Heeft niet zoveel met uptime te maken. Maar we rollen hier volledig automatisch gewoon Windows en Linux machines uit.

Dus ik weet niet wat je exact mist? Maar veel is ook op te lossen icm een puppet of chef oplossing. Dat zijn producten die daarvoor gemaakt zijn. Voordeel is daarbij ook nog eens, dat die cloud onafhankelijk zijn.

Nu weet ik niet exact wat jij onder hot standby verstaat? Ik heb wat google gedaan, maar krijg nu niet echt een duidelijk beeld van wat je nu hiermee bedoelt.hot standby is een redelijk generic iets.

Je moet wel snappen (en willen begrijpen) dat een eigen vmware oplossing die je zelf in elkaar zet, iets anders in elkaar zit dan een Azure Cloud (of AWS, Google of Oracle). En dat is een Cloud niet alles mogelijk is wat in je eigen omgeving wel mogelijk is, ook wat in je eigen oplossing niet mogelijk is, kan soms wel in de Cloud.

Ik heb eerder een vermoeden dat jij nog niet echt begrijpt wat Cloud is, en hoe je daarmee moet omgaan.
Het klinkt eigenlijk eerder als je eigen onkunde en gewoon met je gedachte "Het is van Microsoft, dus k*t", dan dat een echt Azure probleem is.
Met cloud moet je anders gaan denken en implementeren, dat ziet alleen niet iedereen. Er zitten vele voordelen aan, maar ook diverse nadelen en die eigenschappen kunnen ook nog eens verschillen per Cloud provider.

Je neemt een dienst af en daarbij kun en mag je niet alles zelf bepalen. De dienst bepaald de eigenschappen waaruit je kunt kiezen. Bevallen je die niet, dat moet je of verder kijken bij een andere cloud leverancier, zelf gaan hosten, of aanpassen.

@Anoniem
Het is duidelijk voor uptime moet je niet bij Azure zijn. Had ik ook niet verwacht met al die windows hypervisors. Azure biedt je niet de stabiliteit maar garandeert wel de unexpected reboots, waardoor je allerlei high availability clusters mag gaan verzinnen. Een simpele fail over d.m.v. een hot standy VM (kan ook in een ander DC staan) kennen ze niet.
Het is mij een raadsel waarom er meer Linux dan Windows draait in Azure (wat is er mis met windows?) . Deze ondernemingen vergeten dat Azure geen OpenStack is en dat ze dus weer vast zitten aan een nieuwe vendor lock.

Je zou niet meer reageren? Dat was namelijk wel het beste, want je laat nog steeds zien, dat je gewoon Cloud niet begrijpen en een afschuw hebt tegen Microsoft. Iets met BIAS.

Uptime kan gewoon in Azure Cloud. Je moet alleen je omgeving inrichten zoals de Cloud cloud leverancier adviseert. Doe je dit niet, dan creëer je inderdaad je eigen probleem. In AWS heb je ook exact de zelfde eigenschappen die Azure voor onderhoud heeft. Niets meer of minder.
En als je iets tegen unexpected reboots wilt beschermen, moet je ook in je eigen omgeving iets van een hoogbeschikbare oplossing bedenken.

Misschien omdat in Cloud niet alle mogelijke netwerk eigenschappen beschikbaar zijn? Iets simpel kan complexer zijn, dan iemand even denkt. Wat jij als simpel ziet, dan complexer zijn, dan iemand soms bedenkt (ARP/GARP).
Kan dit trouwens wel in andere Enterprise cloud leveranciers? Als bijvoorbeeld AWS of Oracle?
Maar misschien is het wel mogelijk op basis van https://azure.microsoft.com/en-us/services/azure-vmware/?

Misschien omdat het gewoon goed werkt in Azure?
Microsoft een Enterprise partner is en weet wat klanten willen en nodig hebben?
De systemstack goed integreerd bij wat bedrijven willen en nodig hebben?
Ze eigenlijk alles kunnen aanbieden, wat een bedrijf nodig heeft? IAAS, SAAS, PAAS.
Volgens Garner ze het heel goed doen? (en andere marktonderzoeken).

En wat is er mis met Linux draaien in Azure? Het werkt dus gewoon heel goed volgens heel veel bedrijven. Behalve bij souplost natuurlijk. Maar zou dat misschien aan de visie van souplost kunnen liggen? Aangezien er zoveel (Linux) VM's draaien in Azure?
Blijkbaar denken heel veel bedrijven hier heel anders over dan sommige posters hier. Complete bedrijven moven of zitten al in Azure zonder enige problemen.

Veel leveranciers gebruiken multicloud, maar in Azure heb je 1 vendor waarmee je praat, wat een groot voordeel is. Heb je ook een paar leveranciers die op basis van OpenStack de schaalbaarheid en mogelijkheden kunnen bieden zoals Azure (of AWS / Google) kunnen aanbieden? Integratie,schaalbaarheid/ sizing, configuratie, certificeringen en wereldwijde presents?
Ik kon ze niet echt vinden.

Sommige bedrijven of personen vinden een vendor lock lastig, maar voor veel bedrijven zijn juist veel vendors een lastige en dure kost post, wat alles complexer maakt. Maar je kunt Azure ook gewoon aan andere clouds koppelen / integreren.

En bij deze vendor (Microsoft) kan je gewoon eigenlijk je complete IT landschap hosten en beheren.

Mensen zijn zo verstrikt geraakt in hun OS-geneuzel dat een fatsoenlijke discussie niet meer mogelijk is. Het hebben over de voors- en tegens van diverse platforms is voor professionals nog best interessant, maar zoals het hier gaat is het duidelijk dat de stellige en ongefundeerde posities geen enkele inhoudelijke waarde hebben, om het over een professionele discussie maar niet te hebben. Enige nuance is allang vervlogen, wat betekent dat er een klein clubje overblijft dat elkaar steeds meer versterkt in steeds extremer wordende denkbeelden.

Ondertussen is er nog steeds geen antwoord op de vraag hoe die cijfers nu precies opgevat moeten worden.

Als ik er de cijfers bij zoek gaat het om 99,9987 procent uptime bij Amazon, 99,9982 procent bij Google en 99,9792 procent bij Azure. Is dat genoeg om te zeggen dat je voor uptime niet bij Azure moet zijn? Dat is waarschijnlijk aan de lezer om te bepalen, dat hangt nogal van je specifieke eisen af. Wel is duidelijk dat de SLA's ruimschoots gehaald worden, wat betekent dat er geen sprake van verrassingen is - als je je huiswerk hebt gedaan.

Waar staat exact "garandeert" in de documentatie?

Wat is hierin het verschil met een On-premises omgeving? Als je wilt dat je omgeving niet afhankelijk is van 1 machine, dan moet je iets van redudantie inbouwen. Of je dan in Azure of in je eigen meerdere datacenters iets neerzet, staat er helemaal los van. Hoe je dit dan exact oplost, hangt van je requirements af.


Je wilt dus nu een OpenStack (IAAS) vergelijken met Azure (IAA,PAAS,SAAS) mogelijkheden?
Gelukkig snappen deze ondernemingen wel wat cloud precies is en hoe je dit moet gebruiken.

Dit heeft niets met wel of geen Microsoft te maken. Mensen raken zo verstrikt in hun infantiele OS-gesteggel dat ze de realiteit uit het oog verliezen. Een discussie over de voors en tegens van diverse platforms kan voor professionals best interessant zijn, maar op deze manier is er geen sprake van enige inhoud of waarde. Mensen horen zichzelf slechts graag praten.

De diverse mensen die hier rondlopen met de nodige ervaring met Azure melden dat ze hier geen problemen mee ondervinden. Dan kunnen we er op papier allerlei zaken van vinden, maar maakt het in de praktijk dus geen zier uit. Maak daar ontkenning van, of een professionele houding. Vasthouden aan iets dat je kent doet iedereen, maar als mijn mensen zo krampachtig met OS'en of platforms zouden omgaan liggen ze er bij de eerste gelegenheid uit.

Hoeveel ervaring heb je eigenlijk zelf precies met Azure?

Dit heeft heel veel met Microsoft te maken. Uptime is een van de windowsbeperkingen door verplichte reboots t.g.v. verouderd ontwerp. Azure schijnt gebouwd te zijn op basis van windows 2008. Er zijn altijd belanghebbenden die een handicap als een voordeel proberen uit te leggen. Azure is vooral het land van de unexpected reboots. Wij zijn over op iets anders.

Hoeveel ervaring tot wanneer heb je met Azure? Het beeld van "het land van de unexpected reboots" komt desgevraagd niet naar boven bij mensen die verantwoordelijk zijn voor vele honderden Azure-servers verdeeld over een aantal klanten. Dat zijn overigens mensen die verre van met Azure getrouwd zijn.

Daar komt de aap uit de mouw. Met een enorme omweg moest er aangestuurd worden om het uitgekauwde "jamaar Windows heeft reboots nodig" en dan zijn we weer terug bij het begin, waarbij we al vastgesteld hebben dat trots zijn op uptime echt niet meer van deze tijd is. In een goed ingerichte omgeving is uptime geen kwaliteit en in sommige gevallen een behoorlijk risico. Wellicht past een printje van je uptime mooi naast je ITIL V1-certificering, maar daar houdt het ook op.

Het windows oligopolie moet je met een korreltje zout nemen want die verdienen er flink aan. Ik geloof eerder Microsoft zelf:
"Azure virtual machines (VMs) might sometimes reboot for no apparent reason, without evidence of your having initiated the reboot operation. This article lists the actions and events that can cause VMs to reboot and provides insight into how to avoid unexpected reboot issues or reduce the impact of such issues."
Dan moet je bedenken da MS dit schoorvoetend meldt als er geen ontkomen meer aan is want transparantie is niet het sterkste punt.
Daarnaast heeft Azure zomer 2018/2019 een outage gehad van 81 dagen! tegen Amazone 15 dagen . Dan tellen die reboots niet eens mee.

Je hebt nog steeds niet verhelderd wat die cijfers nu precies inhouden, waarmee ze dus weinig toevoegen. Hoe weet je dat reboots niet meetellen, even los van dat mensen die wel met Azure werken opmerken dat ze praktisch gezien geen rol spelen? De discussie heeft baat bij minder fundamentalistisch geblaat en meer feitelijke omstandigheden.

Cijfers zeggen niets . Dat zeggen ze ook van de licentiekosten. https://www.geekwire.com/2019/microsoft-may-cloud-computing-azure-reliability-lagging-competition/ We zullen zien wat het dit jaar gaat worden.

Mijn SQL cluster draait al 21 jaar zonder downtime.
Onzinnige discussie dit.

Jullie vervallen in herhaling. Reboots worden netjes aangekondigd, maar mensen die daadwerkelijk met Azure werken geven aan dat dat in de praktijk geen probleem vormt. Documentatie over hoe Microsoft zaken aanpakt bij onwillige en onkundige beheerders gelijktrekken met "schoorvoetend" melden is natuurlijk van de zotte. Dan ben je erg veel moeite aan het doen om het in een nogal gekleurd wereldbeeld te zien. Als je iets niet meldt is het niet goed en als je iets wel meldt dan is dat zogenaamd een indicatie van een groot probleem. Volgens die nogal kromme logica kan Microsoft het dus nooit goed doen. Er valt heus wel het nodige aan te merken op Microsoft, maar documenteren doen ze nou net best wel aardig.

Cijfers waarbij niet helders wat ze aangeven zeggen niets, inderdaad. Wat die mysterieuze 81 dagen nou moeten inhouden weet niemand, want geen klant heeft 81 dagen downtime gehad, of zelfs maar een korte downtime op 81 losse dagen. Wat wel blijft onbeantwoord.

In het artikel staan wat beter te plaatsen cijfers, die in dit draadje ook al eerder genoemd zijn: 99,9987 procent uptime bij Amazon, 99,9982 procent bij Google en 99,9792 procent bij Azure. Dat is, zoals ook al eerder vastgesteld, binnen de SLA. Als de SLA niet goed genoeg blijkt, had je vooraf je huiswerk beter moeten doen. Goed om op te merken is dat geen van deze partijen 100% uptime biedt en je daar dus hoe dan ook rekening mee moet houden.

Daar lijken al deze argumenten toch steeds weer op terug te komen: zolang je je huiswerk doet, en je gedraagt als een professional die afspraken kan nakomen en een agenda kan gebruiken, werkt alles naar behoren. Als je niet goed leest, inschaalt en plant dan kom je inderdaad mogelijk voor zure verrassingen te staan, maar dan heb je ook niets te zoeken in de dienstverlenende sector.

Hoe veel of beter hoeweinig ervaring heb jij eigenlijk met Azure? Je weet ook dat Hyper-V een enterprise hypervisor is, waarbij je gewoon zonder impacts je VM's kunt verplaatsten naar een andere Hyper-V server?

Gezien de ervaringen hier, en de vele bedrijven die in Azure hun landschap hosten, met zoweinig echte voorbeeldbeelden of klachten hierover, kan ik alleen maar constateren, dat het eigenlijk niet voor komt. Dat het voor KAN komen, is heel iets anders.

BIAS issue, heeft niets met de werkelijkheid te maken. Oogkleppen kijken.

Even WEER een belangrijk puntje voor je aangestipt. Aangezien je wat met oogkleppen leest (whats new). Het is inderdaad mogelijk.
Trouwens https://aws.amazon.com/maintenance-help/
The recent release of our scheduled events functionality provides greater visibility into the timing of these reboots. In addition to added visibility, in most cases you can use the scheduled events to manage reboots on your own schedule if you want to reboot before the scheduled update window. You can easily view any upcoming scheduled events for your instances in the AWS Management Console or using the API tools or command line. Reboots such as these should be infrequent, but may be necessary from time to time to apply upgrades that strengthen our security, reliability and operational performance.

There are two kinds of reboots that can be required as part of Amazon EC2 scheduled maintenance – instance reboots and system reboots. Instance reboots are reboots of your virtual instance, and are equivalent to an operating system reboot. System reboots require reboots of the underlying physical server hosting an instance. If you do not take any action, the impact on your instance is the same in both cases – during your scheduled maintenance window your instance will experience a reboot that in most cases takes a few minutes.
Ofwel bij AWS zal in de meeste omstandigheden de VM alleen rebooten tijdens een maintenance, maar "most cases" vs "might", iets anders beschreven, maar het komt op hetzelde neer.

Planned onderhoud valt nergens in downtime.
Maar cijfertjes zijn leuk, maar wat betekend deze downtime werkelijk voor de klanten? Ze hadden in 2018 wat cooling problemen in een Datacenter. Niet direct een Windows probleem, maar een datacenter infrastructuur probleem. Heeft natuurlijk wel direct impact op de gehoste omgevingen. Oorzaak bliksem inslag.
https://www.geekwire.com/2018/microsoft-azures-southern-u-s-data-center-goes-hours-impacting-office365-active-directory-customers/
Ik zou wel eens bedrijven of Nederlandse Datacenters willen zien, hoegoed ze daar werkelijk tegen bestand zijn.
En azure is niet compleet 81 dagen down geweest.

Leuke post, past ook precies op je downtime dagen in Azure.

Dat klopt ook. Licentie kosten zijn maar een klein gedeelte van de werkelijke kosten. Blijft alleen zo lastig voor sommige om dat te begrijpen.

En wat werkelijk de impact gaat zijn/worden.
Gezien de Corona crises, hebben dankzij Azure heel snel onze infrastructuur kunnen opschalen voor onze infrastructuur. eigenlijk hebben we ook nauwelijks impact gehad dit jaar in Azure, eigenlijk nauwelijks de afgelopen jaren. En execpted reboot komen eigenlijk vaker in ons datacenter voor, dan wat we in Azure hebben draaien.