En av de minst uppmärksammade förändringarna i Windows Server 2008 (och förvisso även i Vista) är det nya protokollet för filservrar i Windowsnätverk kallat smb 2. Det är en vidareutveckling av det gamla och fortfarande dominerande smb. I stora drag är syftet med förändringarna att snabba upp prestanda jämfört med det gamla smb. Eftersom vi har sett undersökningar och tester som visar på fantastiska förbättringar i prestanda blev vi nyfikna. Vi bestämde oss för att testa om det stämde med verkligheten.

Smb och smb 2 är proprietära protokoll som ägs av Microsoft. Samba är öppen källkod och fungerar som en fri implementering av smb, byggd på kvalificerad analys av hur det stängda smb fungerar. Många hävdar att Samba är minst lika snabbt eller till och med snabbare än originalet. Av den anledningen valde vi att testa Samba utöver de två versionerna av smb. För jämförelsens skull har vi även utfört vissa tester med nfs (network file system). De testerna ska ses som referenstester och som en extra service till läsaren.

Windows Server 2003 använder det hittills vanligare smb. Windows Server 2008 använder smb 2 om det kommunicerar med en annan 2008-server eller med Vista. Annars faller det tillbaka på smb. I Linux används Samba tillsammans med Windowssystem och vanligtvis nfs mot andra Linux-/Unixsystem. I normalfallet är grundinställningen nfs 3 men genom inställningar i konfigurationsfilerna kan vi tvinga systemen att använda version 4. I vårt test har vi lämnat XP, Vista och andra klientsystem därhän.




När kommer servicepaketet?

Jag använder visserligen inte nätverksfilsystem vid långa avstånd, men kan tänka mig att många organisationer skulle välkomna ett servicepack som skulle öka produktiviteten. Kanske skulle det till och med spara in ett inköp av wafs-acceleratorer. Hör ni Microsoft, vi vill inte dras med gamla smb när det finns ett bättre och nyare alternativ. ”Ja, men uppgradera till 2008/Vista då” är det givna svaret. Men nej, jag vill ha kvar XP men kunna använda smb 2.

Lars Dobos, testredaktör
lars.dobos@techworld.se















Scenario
It-avdelningen behöver veta hur mycket mer effektivt personalen kan jobba mot organisationens filservrar. Vilket nätverkfilsystem ska användas? Om organisationen ska konsolidera filservrarna från lokalkontoren till en central punkt, skulle de då tjäna på att gå över till smb 2, eller kanske till och med Samba?



Så lade vi upp testet

För testet har vi använt fyra Sun Fire X4150-servrar från Sun Microsystems. Dessutom har vi samarbetat med Expand Networks som har hjälpt oss med en wan-simulator och bidragit med en benchmark-tillämpning från Cisco som simulerar arbete med Officedokument mot filservrar. Den använder Office och makron för att öppna, ändra, spara och stänga Word-, Excel- och Powerpointfiler av olika storlekar, från 50 kilobyte till två megabyte. För vårt test har vi begränsat oss till tre storlekar på filerna: 100 kilobyte, 500 kilobyte och två megabyte.

Vi satte upp servrarna med operativsystemen så att vi kunde utföra testerna med olika kombinationer av operativsystem och därtill hörande nätverksfilsystem. Med hjälp av wan-simulatorn har vi kunnat öka fördröjningen över nätverket från en millisekund (helt utan simulator) till tio millisekunder och 50 millisekunder. Det är fördröjning, inte bandbredd, som sätter nätverksfilsystemen på störst prov.

Förutom Ciscos benchmark har vi även kört ett antal filöverföringar, dels med en stor fil på drygt 329 megabyte, dels med ett katalogträd med 3 554 filer och 250 kataloger på sammanlagt drygt 802 megabyte. I de filöverföringstesterna har vi även kunnat använda nfs på Red Hat Enterprise Linux som referens och extra service till läsarna. Testerna med nfs har utförts både via gränssnittet (Gnome) och via terminalen. Eftersom testet gäller Windowsklienter mot Windowsservrar eller Windowsklienter mot en Sambaserver sker nfs-testerna utom tävlan.

Under filöverföringarna har vi klockat överföringen med tidtagarur när vi använt de grafiska användargränssnitten, men använt kommandot time när vi gjort detsamma i en terminal i Linux eller Solaris.


Öppna och spara program

Vi börjar med att köra över ett lokalt gigabitnätverk med bara en växel mellan klient och server, och bara en millisekunds fördröjning. Skillnaderna mellan såväl filsystem och filstorlekar är mycket små. Med en så liten fördröjning sätts begränsningarna primärt av nätverket och hårddiskarna (vi använde sas-diskar med 10 000 varv per minut och raid-0). Trots det finns skillnader. Server 2003 som klient är generellt snabbare än 2008, och smb 2 (2008–2008) tillhör snarare de långsammare kombinationerna.

Skruvar vi upp fördröjningen till tio millisekunder börjar det hända saker. Fortfarande går filöppnande och sparande ganska fort, på en handfull sekunder, men nu börjar det dyka upp skillnader mellan systemen.

Vid filöppnande är smb 2 snabbast, utom när den hanterar den stora Powerpoint­­filen. Smb 2 vinner i sju deltester av nio. Sambaservern på Red Hat är ofta bland de långsammare. Även vid sparande gör smb 2 bra ifrån sig, men här är resultaten mer blandade. I vissa fall är smb 2 sämre. En klar tendens är att med 2003 som klient går det ofta långsammare. Särskilt kombinationen 2003 och Samba går segt. 2008 och Samba går betydligt bättre; den kombinationen vinner i fem av nio fall. Smb 2 är snabbast i fyra fall.

Vid en fördröjning på 50 millisekunder är fördelarna för smb 2 ännu tydligare. I grenen filöppnande vinner smb 2 samtliga körningar, och vid sparande vinner smb 2 sex av nio körningar. De övriga tre deltesterna plockas hem av kombinationen 2008–Samba.

Sammanfattningsvis så här långt ser vi att skillnaderna över nätverk med låg fördröjning är försumbara. Det är först när vi simulerar längre avstånd som vi ser fördelar med smb 2. Då märker vi även att 2008 fungerar fint tillsammans med 2003 och Samba. Det är med 2003 som klient som vi ser de sämre resultaten, oavsett om servern heter 2003, 2008 eller Samba.

Windows Server 2003/SMB


WAFS Benchmark från Cisco spottar ur sig en csv-fil med resultat från samtliga körningar med olika storlekar. På grund av platsbrist har vi valt ut tre av filstorlekarna, inklusive den största på två megabyte.

Windows Server 2008/SMB 2


WAFS Benchmark från Cisco. Vi fick låna programmet från Expand Networks som själva använder det för att testa sina acceleratorer.
Här ser vi Ciscos WAFS Benchmark under en körning. Programmet öppnar, redigerar, sparar och stänger olika Officedokument. Vi har valt att inte ta med tiden för stängning då de är väldigt korta över hela linjen. Öppnande och sparande tar däremot tid, särskilt när vi skruvar upp fördröjningen över nätverket.

Red Hat Linux/Samba



En filkopiering i Red Hat Linux. På grund av fönsterhanteraren, i detta fall Gnome, tar filöverföringar längre tid i det grafiska gränssnittet (om vi bara drar och släpper) än om vi använder terminalen. Kanske något att tänka på när stora ­filer ska kopieras.



I konfigurationsfilen /etc/fstab skriver vi in de rader som gör att vi kan montera utdelade kataloger på andra system. Notera kolumnen med filsystemtypen. Det är det enda som behövs för att använda nfs 4 och det är klienten som styr detta.


Nfs bäst på filöverföringar

Vid filöverföringar med endast en milli­sekunds fördröjning och en stor fil är det kombinationen 2008 mot 2003 som fungerar bäst. Drygt tre sekunder är närmast så fort det kan gå. Vi kan också se att det är Red Hats Sambaklient mot både 2003 och 2008 som är klart sämst. Den snabbaste filöverföringen sker dock i referenstestet över nfs 3 mellan två Red Hat-maskiner med filkopiering i terminalen.



Om vi överför samma stora fil men ökar fördröjningen till tio millisekunder tar smb 2 över ledningen, medan Sambaservern sköter sig sämre. Vi kan också konstatera att Red Hats Sambaklient inte alls mår bra av att köras mot Windowsservrar. Återigen ser vi att referenstestet med nedladdningar över nfs 3 och nfs 4 under Red Hat går ännu lite snabbare än smb 2. Uppladdningarna är dock långsammare.

Katalogträd med många små filer ställer till det för nätverksfilsystemen. System som smb 2 som kan aggregera flera förfrågningar i ett borde ha fördelar här. Trots det handlar det vid endast en millisekunds fördröjning inte om några stora skillnader. Smb 2 tar hem det här deltestet med minsta marginal och i kampen om andraplatsen blir det dött lopp mellan 2008 mot Sambaservern respektive 2003-klienten mot 2008. Red Hats Sambaklient gillar fortfarande inte att köras mot Windowsservrar. Inget slår referenstestet med nfs som är helt överlägset.


”Överför man katalogträdet

mellan en Sambaklient och en

Windows­server kan man

nästan ta lunch.”



Smb 2 tjänar på att vi ökar fördröjningen till tio millisekunder. I det läget räknar vi försprånget till de andra i minuter. Överför man det här katalogträdet mellan en Sambaklient och en Windowsserver kan man nästan ta lunch medan överföringen pågår. För nfs i referenstestet blir skillnaderna nu lite större. Nedladdning i terminal vinner överlägset med halva tiden mot motsvarande operation med smb 2. De övriga överföringarna ligger dock i paritet med smb 2 eller däröver.

Testresultat för filöverföringar från Cisco WAFS Benchmark


Stor fil, liten fördröjning. Bäst går nfs på Red Hat, både grafiskt och via terminal. Smb 2 får se sig slaget även av smb eftersom kombinationen 2003–2008 går snabbare. Skillnaderna mellan nfs 3 och nfs 4 är mycket små.
Stor fil, stor fördröjning. Nedladdning över nfs 3 och nfs 4 mellan Red Hat-maskinerna går snabbast, men smb 2 ligger inte långt efter. Här är det dessutom om möjligt ännu tydligare vilka problem Red Hat har som Sambaklient.



Stort träd, liten fördröjning. Den här typen av överföring visar att nfs 3 och nfs 4 mellan två Red Hat-maskiner regerar. Smb 2 vinner visserligen över smb och Samba men det är med stort besvär.

Stort träd, stor fördröjning. Här spricker nfs segersvit en aning; det är uppladdningen i gränssnittsläget som inte riktigt hänger med. Annars är värdena för nedladdning mycket fina, särskilt i terminalläge. Smb 2 är också betydligt snabbare än smb och Samba. Faktum är att Red Hat är rent bedrövlig som Sambaklient.


* Testerna med nfs fungerar endast som referens.



Testresultat för kontorsprogram från Cisco WAFS Benchmark


Filöppnande över ett nätverk med bara en millisekunds fördröjning. Här är skillnaderna mycket små; de ligger inom ­tiondelar av en sekund. Vi kan i alla fall se att det går lite långsammare med Server 2008 på klientsidan.



Filsparande. Samma test som tidigare men nu gäller det sparande av filerna. Här är skillnaderna ännu mindre. Vi har valt att hålla skalan på diagrammet uppe för att det ska bli lättare att jämföra med övriga diagram.



Filöppnande med tio millisekunders fördröjning.  Här börjar skillnaderna att märkas. Förutom det sista testet, med stor Powerpointfil, vinner smb 2 alla delmoment. Det handlar dock fortfarande mest om tiondelar av en sekund.


Filsparande med tio millisekunders fördröjning. Här vinner Samba med fem delsegrar mot smb 2 som vinner fyra av delmomenten. Tendensen är annars tydlig att Server 2003 fungerar sämre som klient än 2008.



Filöppning med 50 millisekunders fördröjning. Det motsvarar ungefär fördröjningen mellan två svenska städer. Smb 2 vinner här alla delmoment och segermarginalen är ganska klar i samtliga fall.



Samma test som i diagrammet till vänster fast för filsparande. Smb 2 vinner sex av nio delmoment men 2008 mot sambaservern går också bra. Det är tydligt att 2003 inte hanterar en Sambaserver lika bra som 2008 gör.




Enkelt använda nätverksfilsystem

Vi kan konstatera att det går som smort att använda de testade nätverksfilsystemen i Windows, att dela ut kataloger och skapa nätverkskataloger. I Linux är det aningen svårare. Vissa system har grafiska användargränssnitt för Samba och i dem brukar konfigurationen inte vålla problem.

Med ett gränssnitt är det inte särskilt svårt att skapa en nätverkskatalog mot en Windowsserver heller, faktiskt är det snudd på enklare i Gnome än i Windows. Det gäller bara att vara observant på hur rättigheter och lösenord fungerar; det är där de flesta stöter på problem. Bara man vet vad man gör är det inte heller svårt att använda Samba, som server eller som klient, utan grafiskt användargränssnitt. Syntaxen i konfigurationsfilerna är relativt intuitiv och det finns mycket hjälp på nätet.

I fråga om plattformsstöd ser vi att nfs är det heterogenaste nätverksfilsystemet. Det fungerar inte bara på Unix och Linux, utan också med Mac OS X och faktiskt även med Windows 2003 och 2008. Vi vill dock höja ett varningens finger för att nfs 4 inte alltid är smidigt att få att fungera.

Samba är även det mycket plattformsoberoende och förekommer på så gott som alla Unix- och Linuxsystem. Naturligtvis fungerar det också via smb på Windows. Smb fungerar mellan alla Windowssystem och mellan Windowssystem och Linux/Unix, men naturligt nog inte mellan två Unix/Linuxenheter.

I fråga om interoperabilitet är smb 2 det sämsta nätverksfilsystemet. Det fungerar endast mellan kombinationer av Windows Server 2008 och Vista, punkt slut.

Avslutningsvis vill vi kommentera en egenhet i nfs som vi uppmärksammat. Det är stor skillnad på att dra och släppa filer i ett grafiskt användargränssnitt och på att köra kommandot cp på samma fil. Tidsåtgången blir upp till fördubblad.

Vår expert på Red Hat menar att det här beror på problem i fönsterhanteraren Gnome (vilket även bör gälla andra fönsterhanterare) som gör överföringen seg eftersom den måste illustreras grafiskt samtidigt som den sker ”under skalet”.



TechWorlds slutsats

Smb 2 är ett lyft för användare av nätverksfilsystem under Windows. Det nya filsystemet innebär åtminstone halverade vänte­tider i de flesta fall. Det är bara då nätverket är riktigt bra, det vill säga inom kontoret, som vi inte ser någon större skillnad. Så fort avstånden och därmed fördröjningen i kommunikationen ökar är smb 2 överlägset det äldre smb, men även snabbare än Samba.

I vissa fall hänger dock Samba med riktigt bra. Det är också tydligt att Server 2008 fungerar bättre tillsammans med andra operativsystem, såväl Linux som Server 2003. Det är slående att kombinationen 2008–2003 är bättre än 2003–2008 och 2003–2003.

Utom tävlan lurar nfs. Det är ett synnerligen bra nätverksfilsystem som dessutom är kompatibelt med alla operativsystem vi har med i testet. Det kan vi knappast säga om smb 2. Skillnaden mellan nfs 3 och nfs 4 är mikroskopiska. Testets snabbaste överföringar alla kategorier görs i terminalen mellan två Red Hat-servrar och nfs 3.




Foto: Andreas Eklund Grafik: Jonas Englund