Interview met kernel-guru van Windows Server 2003

Bij ZDNet is een interview verschenen met Rob Short, de persoon die bij Microsoft verantwoordelijk is voor kernelontwikkeling. In het gesprek wordt ingegaan op de verschillen tussen Windows XP en Windows Server 2003 op het gebied van beveiliging, IIS en bestandssystemen. Volgens Short zijn de wijzigingen die extra veiligheid mogelijk maken er de oorzaak van dat een groot aantal NT4-applicaties niet werkt op het nieuwe besturingssysteem.

Een nieuwe feature is een soort mini-IIS binnen de kernel die eenvoudige HTTP-requests kan afhandelen. Een soortgelijk project bestaat ook binnen Linux, maar daar bleek het uiteindelijk minder extra snelheid op te leveren in vergelijking met minimalistische userspace-implementaties dan in eerste instantie werd verwacht. Short spreekt voor Windows Server 2003 echter over een 'huge performance win'. Het is mogelijk dat er door de andere architectuur van de Windowskernel een grotere snelheidswinst wordt geboekt dan bij Linux het geval is. Een andere vooruitgang is te vinden in de verbeteringen aan het bestandssysteem:

What's happened to the file system?
There are two things. We spent a lot of time on performance. We created the SMB file server specs, and we didn't have the fastest one around, which was embarrassing. So we took our performance team and said "your mission is to make ours twice as fast as this other one on the market." We've actually done that. So there's a huge performance increase. Most of those are the type of changes in separating the different file streams from each other deeper down in the system so you get more parallelism it works better on a parallel system. We've drastically improved the performance on Checkdisk. The transaction file system lets you make a transaction across a collection of file changes. We've added shadowing, so you can take a snapshot of something at a point in time and make a backup on the fly. We've done things to the IO subsystem, with tighter integration between a RAID subsystem and caching.

Reacties (46)

[Anoniem: 70267]

Een soortgelijk project bestaat ook binnen Linux, maar daar bleek het uiteindelijk weinig extra snelheid op te leveren.

Sorry!? De kernel http server is geimplementeerd omdat Linux last had van wakeup storms (slapende processen die allemaal op dezelfde semafoor liggen te wachten en allemaal gewekt worden terwijl 1 proces voldoende is) het is was de snelste en meest schaalbare (aantal transacties/seconde schaalde lineair met het aantal processoren) webserver.

Check:
http://www.linuxjournal.com/article.php?sid=4132

...and tests with this setup have shown a dramatic increase in throughput compared to standard user space web servers.

Het is nu uit de kernel gehaald, omdat een http server eigenlijk niet in de kernel hoort en er features aan de kernel zijn toegevoegd die b.v. apache net zo schaalbaar maken.

[Anoniem: 6196]

de TUX patch die het mogelijkmaakt om HTTP in userspace te doen onder Linux brengt wel degelijk een snelheids winst ter weeg echter ALLEEN bij static pages dus met dynamische pagina's niet

Ik vind het laten lopen van http sub systeem in kernel niet zo heel erug verstandig, het lijkt mij dat waneer er iets met gaat met http dat je dan je hele doos neer krijgt. Mijn motto houdt je kernel zo klein mogelijk. valt er ook weining aan te verkloten

[odysseus]

Sorry!? De kernel http server is geimplementeerd omdat Linux last had van wakeup storms (slapende processen die allemaal op dezelfde semafoor liggen te wachten en allemaal gewekt worden terwijl 1 proces voldoende is) het is was de snelste en meest schaalbare (aantal transacties/seconde schaalde lineair met het aantal processoren) webserver.

De tekst van het artikel heb ik ondertussen wat verduidelijkt. In eerste instantie leek het er inderdaad op dat kHTTPd een heel grote snelheidswinst liet zien. Dit bleek echter niet alleen het gevolg te zijn van de aanwezigheid in kernelspace. kHTTPd was namelijk gewoon een extreem compacte webserver die alleen statische content kon serveren (wat vrij logisch is, maar dan dat wil je al helemaal niet in je kernel hebben) en daardoor erg efficiënt kon zijn. Toen kHTTPd eenmaal genoeg bejubeld was, kwamen er tests die lieten zien dat Boa (een userspace webserver) maar liefst drie of vier keer sneller was dan kHTTPd.

Later kwamen er tests met een verbeterde kHTTPd die die webserver weer voor Boa plaatsten, maar een verbeterde Boa ging daar op zijn beurt weer voorbij. Toen kwam Tux als webserver in de kernel en die ging weer harder dan zowel Boa als kHTTPd, maar vervolgens verschenen er weer tweaks voor Boa en ook Apache werd sneller. Uiteindelijk is een kernelspace implementatie wel wat sneller, maar het verschil is veel kleiner dan in eerste instantie geroepen werd .

Natuurlijk zou het zo kunnen zijn dat calls tussen userspace en kernelspace in de Windowskernel vrij lang duren - in dat geval is er met een webserver in kernelspace zeker voordeel te halen. De beveiligingsrisico's zijn alleen erg groot en eenvoudig updaten is ook minder makkelijk dan bij een op zichzelf staande webserver. De geïnterviewde medewerker legt er niet voor niets grote nadruk op dat er veel aandacht is besteed aan de beveiliging: alle requests die niet heel erg eenvoudig zijn worden door de kernel-webserver direct doorgeschoven naar userspace, waar een gewone webserver het mag uitzoeken. Op die manier moet worden voorkomen dat crackers straks via bugs toegang krijgen tot machines op kernelniveau.

Dit is tevens één van de redenen dat de nieuwe webserver alleen statische content serveert - daar zitten veel minder vaak beveiligingsproblemen aan dan aan dynamische pagina's. Een andere reden is dat bij het serveren van dynamische pagina's toch al minder in kernelspace werd gedaan en dat daar dus minder winst valt te behalen bij een overstap van een losstaande webserver naar een webserver die in de kernel zit .

Check:
http://www.linuxjournal.com/article.php?sid=4132

Dat artikel komt uit het jaar 2000, toen was kHTTPd net nieuw (en bestond Tux nog niet eens, volgens mij). De resultaten van Boa worden in dat artikel nog helemaal niet genoemd en vergelijken met een op dat moment gangbare Apache is niet echt bruikbaar, omdat die veel meer aankan dan alleen statische pagina's en alleen daarom al een overhead heeft.

[arnob]

Wat ik laatst op een MS dag had gehoord is dat het kernel component er alleen is om zonder winsock HTTP connecties af te handelen. Het kernel component heeft ook een cache voor statische pagina's maar het gaat om de listener

[Anoniem: 83858]

Ha Arno, je toch opgelet die dag!
Het werd ook een keer tijd dat winsock (of http listeners) naar kernel mode werden gebracht.

[Anoniem: 32075]

het betreft hier: TUX: Threaded linUX http layer

Nou.. Het is mischien uit de Linux Kernel gehaald maar maakt nog steeds deel uit, in sterk gewijzigde vorm, van de RedHat Advanced/ Enterprise Server als RedHat Content Accelerator:

http://www.in.redhat.com/products/ecommerce/about_sh3.pdf

http://www.redhat.com/docs/manuals/stronghold/Stronghold-4.0-Manual/SH 4_HTML/welcome.html


En is hiermee veiliger en sneller dan andere platforms:

Getuige http://www.redhat.com/about/presscenter/2003/press_coe.html


Dus... eer die kernelbakker van MS wat verkoopt, laat het effe door deskundigen checken...

[remier]

Nog een leuk stukje uit het ZDNet interview:

Why is there no command line only version?
We're looking longer term to see what can be done, looking at the layers and what's available at each layer and how do we make it much closer to the thing the Linux guys have -- having only the pieces you want running. That's something Linux has that's ahead of us, but we're looking at it. We will have a command line-only version, but whether it'll have all the features in is another matter. A lot of the tools depend on having the graphical interface. Printing, for example, requires all the graphics subsystems because we have the "what you see is what you get" model. You need to have the whole of the display stuff to render it. It's a very tangled subsystem.

[vso]

met andere woorden daar zijn veel fouten in te vinden omdat Win2k3 niet modulair is opgebouwd.
het zijn echt enorme lappen code IMHO. die code zo zo goor dat bugs niet makkelijk te ontwijken zijn.

modulair betekend dat je de code veel beter kan optimaliseren. omdat je dan op 1 "onderdeel" richt

Gepost door Koert van der Veer maandag 28 april 2003
Je kan veel zeggen, maar die man heeft zeker een gezonde portie zelfkritiek. Vooral dat stukje over de CLI, waar hij tussen de regels toegeeft dat windows fundamenteel ongeschikt is voor high-performance servertoepassingen, aangezien de GDI altijd geladen moet zijn...

dat zou best eens kunnen. toch is de highend server best te doen. oke tis niet het aller aller snelst, maar dat zegt niet dat de GUI super veel overhead heeft. misschien is het minder geworden ten opzichte van 2k of 9x ? maar goed .. das een gok.

ik vind het knap dat hij weet waar zijn fouten liggen alhoewel dat natuurlijk ook bekende feiten zijn. voor zowel *nix community als windows community.

laat dit wel een voorbeeld zijn door te leren van elkaar ipv oorlog te voeren

[mjtdevries]

Dat is natuurlijk een conclusie die je totaal niet kan trekken.

Win2003 kan best compleet modulair opgebouwd zijn, waarbij één van die modules "the display stuff" is.

Het is dan niet vreemd dat je voor wysiwyg dan die module nodig hebt, naast je "print" module.


Overigens snap ik ook die fixatie van linux mensen op die GUI niet. Als je 5 minuten met een windows systeem hebt gewerkt dan weet je dat de overhead van de GUI verwaarloosbaar klein is.

Dat Linx een sneller fileserver is komt niet door de GUI. (zoals ook al blijkt uit dat artikel)

Ik zie die man ook nergens tussen de regels door toegeven dat windows daarom niet geschikt is voor high-performance toepassingen.
(de vraag is dan ook sterk wat je een high-performance toepassing noemt)
Als je al wat tussen de regels door wilt lezen dan is het eerder dat het een probleem is voor embedded toepassingen.

[Anoniem: 53444]

welke Highend zou je bedoelen dan??

Windows draait enkel op lowend..

op highend (sun fire's , S/390's) en midrange (compaq alpha's) ben ik ze nog niet tegen gekomen.

[DaRealRenzel]

Lekker fantastisch dus.. Om een stream PostScript of PCL ASCII Data naar een parallelle poort te sturen heb je echt geen Grafische renderer nodig.... Beetje knullig dus nog steeds...

[mjtdevries]

Je hebt bij postscript geen grafische renderen nodig in je OS omdat die renderen in je printer zit ja.

Als een printer de windows renderer ingebouwd zou hebben, dan hadden ze in het OS ook geen grafische renderer nodig gehad.

Klinkt me nogal logisch en weinig schokkend in de oren.

[Anoniem: 5082]

Hey das de eerste keer dat ik ze hoor toegeven dat andere SMB implementaties sneller zijn.

Ik ben benieuwd of ze genoeg incompatibiliteiten ingebrouwd hebben om deze postie lang vast te houden.

Mits het natuurlijk waar is dat het echt 2X zo snel is.

Het nieuwe smb protocol zal wel flink kluifje worden voor de samba bakkers

Toch ben ik bang dat SMB er alleen maar brakker op is geworden. Immers er is WEER een laag toegevoegd.

En dus hebben we inmiddels 3.11, 95 2000 en 2003 style sharings.

Extra code, extra fouten extra brak.

Het samba team zelf vind het geen goed protocol trouwens.

[egeltje]

Ik ben benieuwd of ze genoeg incompatibiliteiten ingebrouwd hebben om deze postie lang vast te houden.

Het is voor MS onmogelijk om incompatibiliteit in te bakken. Zij hebben zelf namelijk dit protocol bedacht en er bestaan geen officiele specs.
De enige test om te kijken of je SMB implementatie goed werkt is over het netwerk praten tegen een windows machine. Krijg je contact en kun je files sturen/halen, dan is je implementatie goed. SMB zit overigens vol met legacy problemen...
Met CIFS hebben ze geprobeerd het wat strakker op de rails te zetten.

[iceblink]

Als het echt 2x zo snel is, zou het betekenen dat het simpeler in elkaar zit. Dat zou dan weer betekenen dat het makkelijker uit te pluizen is door het Samba team et al.

[Beaves]

Was het maar zo simpel, MS kan ook complexe oplossingen bedacht hebben, zoals ook al in het bericht staat: Most of those are the type of changes in separating the different file streams from each other deeper down in the system so you get more parallelism

Zo kan het bijvoorbeeld zijn dat het systeem bij schrijf/lees opdrachten opdrachten sorteert op positie op de HDD voordat ze uitgevoerd worden. Als er genoeg opdrachten binnen de gestelde tijd zijn verzameld die dicht bij elkaar zitten wordt alles in een keer gedaan en op die manier kan er snelheid worden gewonnen.

Zo zijn er wel meer oplossingen te verzinnen die behoorlijk complex in elkaar zitten.

Maar volgens mij hoeft het team van Samba niet overnieuw te beginnen, zolang NT4 nog met Windows 2003 servers kan communiceren kan Samba dat ook.

[Anoniem: 65804]

Uhm... zoiets bestaat al.

Dat heet 'command reordering' en is standaard bij iedere willekeurige SCSI-controller. Heeft je filesystem verder niets mee te maken, meer je controller-driver.

[mjtdevries]

Maar je filesystem kan dat waarschijnlijk een stuk efficienter doen, omdat het afgestemd kan worden op je configuratie.

[Anoniem: 77853]

Het nieuwe smb protocol zal wel flink kluifje worden voor de samba bakkers

Volgens mij hebben ze het niet over een nieuw SMB protocol hoor. Ze zeggen alleen dat 'de concurrent' (samba dus) sneller was.

Conclusie die microsoft uit dit verhaal kan trekken: markwerking en concurrentie is goed om je eigen produkt te verbeteren.

In de auto industrie weten ze dit allang.

[RIP-airco]

We created the SMB file server specs, and we didn't have the fastest one around, which was embarrassing. So we took our performance team and said "your mission is to make ours twice as fast as this other one on the market." We've actually done that

Hey das de eerste keer dat ik ze hoor toegeven dat andere SMB implementaties sneller zijn.

sneller waren .....

[Anoniem: 4632]

Laten we de benchmarks maar even afwachten shall we ?

[mxcreep]

Ervan uitgaande dat ze samba bedoelen als andere SMB client/server...denk dat 2 keer zo snel als samba wel erg sterk overdreven is, samba performde altijd al ontzettend goed, 2 keer zo snel als de huidige samba is volgens mij bullshit...

Dit is weer typisch zo'n microsoft vent die alleen maar marketing onzin uitkraamt...ik heb op zich niets tegen microsoft produkten, maar ik heb er onder andere ook een aantal trainingen gevolgd (mcad) en die gasten doen niks anders als promotiepraat blaten...

We zien de benches wel tegemoet van onafhankelijke testers en daarna zien we de security bulletins over eventuele security issues ook wel langswaaien...een jaar verder zonder problemen en dan is het vroeg genoeg om te bevestigen dat het nu eens wel goed voor elkaar is....

[mjtdevries]

Dit is weer typisch zo'n anti-Microsoft linux figuur die alleen maar anti-Microsoft en pro-linux onzin uitkraamt. Ik heb op zich niets tegen linux producten, maar die linux gebruikers doen niks anders dan promotiepraat blaten...


Kijk eens naar de balk in je eigen oog zou ik zeggen...

[Maurits van Baerle]

The transaction file system lets you make a transaction across a collection of file changes. We've added shadowing, so you can take a snapshot of something at a point in time and make a backup on the fly

Betekent dit dat er een nieuwe NTFS-revisie (NTFS 5.2) in zit?
Is dat compatible met 5.1 (XP) en 5.0 (2K)?

[Trax_Digitizer]

waarschijnlijk niet... ik denk dat dat hetzelfde werkt als bij een SAN systeem. Je slaat de pointers naar de datablocks op en dan heb je bijv 8 backups in 1 minuut. Alle wijzigingen die tussentijds op het filesysteem plaatsvinden worden op een 'appart' stuk opgeslagen. Ondertussen wijzen die pointers van die backups nog steeds naar die originele data van moment van backup..... ze noemen dit ook wel 'copy-on-first-write'.

[Anoniem: 5082]

Moet ik me daar iets bij voorstellen zoals JFS ? of reiserfs onder linux ?

[Trax_Digitizer]

Ik denk dat ze qua filesysteem niet veel hebben aangepast. Deze uitspraak is echter niet gebaseerd op harde feiten....het is slechts wat ik denk.
Maar dat 'copy-on-first-write' staat enigszins los van het filesysteem. Je zou het theoretisch ook kunnen implementeren voor JFS, onlineJFS, ReiserFS, EXT3 etc etc.

[kvdveer]

Je kan veel zeggen, maar die man heeft zeker een gezonde portie zelfkritiek. Vooral dat stukje over de CLI, waar hij tussen de regels toegeeft dat windows fundamenteel ongeschikt is voor high-performance servertoepassingen, aangezien de GDI altijd geladen moet zijn...

[_JGC_]

Ongeschikt is het niet, maar het kan altijd beter.
Zolang er produkten zijn die goed met MS software kunnen concurreren, gaat de kwaliteit van MS software wel vooruit qua serverOS.

[Anoniem: 42823]

In een article op http://e-serv.ebizq.net/wbs/lee_1.html over de waarde webservices werd gesproken over de kernel of horizontal services . en hoe je een systeem beter kan bouwen en goedkoper kan verbeteren door verschillende onderdelen los te trekken. Vooral het stuk over consolidation spreekty me erg aan.

Ondanks dat het hier over webservices gaat vraag ik me af of iets dergelijks ook mogelijk is bij de kernel van een OS ?

Het doorbakken op fouten uit eerdere versies van een OS kan zo voorkomen worden.....?

[Anoniem: 53444]

Ik blijf van mening dat je webservice ge-relateerde zaken nooit in een kernel moet gaan dumpen..het is al een keer eerder gezegt hier.. in theory is het met een paar requests mogelijk een hele server compleet plat te leggen..
controles vastleggen in de kernel om dit soort geintjes tegen te gaan maakt de kernel alleen maar complexer waarbij de kans op fouten drastisch toeneemt. Dit gaat dus ten koste van stabiliteit.

Ik vindt dat die kernel guru op een aantal punten gelijk heeft...het is iemand met een gezond verstand.. kom je niet vaak tegen bij dat bedrijf..heb ik wel respect voor..maar als kernel guru zou je ook moeten weten dat je OS valt of staat met de kernel.
hou je deze zo compact mogelijk is de kans op fouten kleiner en zal deze stabieler zijn... helemaal als deze in staat is op een fatsoenlijke wijze "userland" te sturen en indien nodig een PID te killen of niks meer toe te wijzen indien iets loopt te bokken..
Userland is het grootste foutenblok bij OS's .... stop dit niet in een kernel.

[Anoniem: 51287]

dat een groot aantal NT4-applicaties niet werkt op het nieuwe besturingssysteem

Ik mag hopen dat dit meevalt,
lijkt me voor veel bedrijven wel iets om je te weerhouden van een nieuwe windows server.

Zullen de meeste bedrijven trouwens blij mee zijn, met weer een nieuwere versie.
De meeste zitten net halverwege de migratie naar 2000.

[TheGhost]

Bedrijven hoeven niet over te stappen hoor !!

als een bedrijf nu net op w2k draait gaan ze dat echt ook echt niet doen...

[ArnoudJ]

Wat is het alternatief dan als NT4 straks niet meer ondersteund wordt? Hackers vriendelijk verzoeken dat systeem met rust te laten omdat MS geen patches meer maakt?

[Creesch]

w2k word nog steeds ondersteunt en dat blijft voorlopig zo lowrider had het ook niet over nt4

[Anoniem: 11125]

Dat lowrider het er niet over had betekent niet dat het geen probleem is. MS heeft niet voor niets de levensduur van hun OS'en (=support) verlengd.

[Anoniem: 1788]

Volgens Short zijn de wijzigingen die extra veiligheid mogelijk maken er de oorzaak van dat een groot aantal NT4-applicaties niet werkt op het nieuwe besturingssysteem.

Iets anders zal hij ook niet mogen zeggen van het management van MS. Dus de geloofwaardigheid is minimaal van deze man.

Omdat het WINE project aardig wat vorderingen maakt komt het Microsoft ook wel verdacht goed uit dat programma's een update krijgen en het OS minder compatible is.

Backwards compatibiliteit is altijd heilig geweest bij MS, maar zodra het in hun voordeel is - als concurrentie compatible wordt - is het ineens niet meer heilig. Dat komt ook overeen met de incompatibiliteits strategie met gesloten standaarden.

Short spreekt voor Windows Server 2003 echter over een 'huge performance win'.

Uiteraard spreekt hij vol lof over de performance.

Eigenlijk een nutteloos interview omdat hij met geen mogelijheid onafhankelijk is en z'n baan ervan afhankelijk kan zijn. Hij zal uiteraard wel de opdracht gekregen hebben onafhankelijk over te komen, en daarom dus ook zeker enige zelfkritiek uiten.

Edit:
0--overbodig
Nevermind. Men is hier wel heel erg goedgelovig als de bron microsoft is. En nog wel over het topic compatibiliteit! Als er een onderwerp over is waar het management van microsoft leugens over naar buiten brengt is het dat wel. Daar is het bedrijf zelfs voor veroordeeld een tijdje geleden. Zo bont heeft MS het reeds gemaakt, en nog steeds worden gegevens van het bedrijf hier als zoete koek geslikt. Ongelovelijk.

* 786562 Flipz

[Anoniem: 24471]

ach hij zegt wel dat zijn kernel 2x zo snel is
door de enorme snelheids winst
ik geloof em best
maar dan dat vergelijken met linux??
tja vindt je het vreemd dat linux niet zo warm loopt door dit techniek

en lompe trage OS is makkelijk sneller te maken (windows)
maar als je OS al bijna maximaal presteert(linux) dan wordt het zeer moeilijk er nog wat uit te persen

hij zeg ook niet dat het sneller loopt dan linux
hij zegt alleen dat de snelheids winst t.o.v eigen OS groter is dan de linux snelheids winst

hij heeft het slim aangepakt in zijn interview er zijn ook zeker heel veel mensen die uit dit opmaken dat windows sneller is dan linux

en dan de grap is als mensen erop terug komen van het is niet zo zegt hij simple weg heb ik niet gezegt want inderdaad hij zegt het niet

marketing truckjes kunnen soms zo misleidend zijn dat je er niet goed van wordt

[Anoniem: 15923]

grote woorden, nu nog zien of het ook daden levert.
tis iig duidelijk dat ze de concurrentie met linux nog steeds keihard aan blijven gaan (en het dus als een grote tegenspeler ziet)