Jämförelse av nätverksfilsystemsprotokoll i Windowsmiljö

Jämförelse av

nätverksfilsystemsprotokoll i

Windowsmiljö

Jonas Ramsin Barlas

Stefan Skedebäck

Mikael Hagberg

Handledare: Jacob Lindehoff, Högskolan i Kalmar, IKD Institutionen för Kommunikation och Design

Abstrakt

Detta arbete handlar om nätverksfilsystemsprotokollen SMB/CIFS, SMB2 och NFSv3. Arbetet baseras på artikeln ”A New Network File System is Born: Comparison of SMB2, CIFS, and NFS” som skrivits av Steven M. French på IBM, Samba Team. I den artikeln saknas det prestandatester och därför känns det relevant att göra prestandatester för att få fram vilket protokoll som har högst hastighet med olika filstorlekar i

Windowsmiljö. Dessa tester utfördes mellan två Dell PowerEdge 2900 servar där den första agerade som klient och den andra som filserver. Testerna utfördes en gång utan nätverksfördröjningar (även kallat latens/latency) och en gång med. Detta resulterade i att vi fick stora skillnader i hur snabba protokollen är med och utan

nätverksfördröjningar.

Nyckelord: Network File System, SMB / CIFS, SMB2, SAMBA, NFS, Protokoll

Abstract

This essay is about the networkfilesystem protocols SMB/CIFS, SMB2 and NFSv3. The work is based on the article ”A New Network File System is Born: Comparison of SMB2, CIFS, and NFS” which is written by Steven M. French at IBM, Samba Team. In the article there are no performance tests, we found it relevant to do performance tests to see which networkfilesystem protocol was the fastest with different filesizes in a Windows client environment. These tests were performed between two Dell PowerEdge 2900 servers where one of them was acting client and the other one fileserver. The tests were done once without network latency and once with. This resulted in that we got differences in how fast the protocols were with and without network latency. Keywords: Network File System, SMB / CIFS, SMB2, SAMBA, NFS, Protokoll

Förord

Vi har valt nätverksfilsystemsprotokoll som ämne i vår C-uppsats då vi vill se vilket som har högst nätversöverföringshastighet i en Windowsklientmiljö. Vi vill tacka vår mentor Jacob Lindehoff då han har hjälpt oss med uppsatsskrivandet och kommit med tips och tankar på vägen. Vi vill även tacka Stefan Pettersson och Marcus Wilhelmsson då de har ordnat så att vi fick låna hårdvaran som krävdes för att utföra testerna.

Innehållsförteckning

1.1 Syfte och frågeställningar ... 1

1.2 Avgränsningar ... 2

2. Teoretisk bakgrund ... 3

2.1 Internet Protocol version 4 & 6 (IPv4/IPv6) ... 3

2.2 Transmission Control Protocol (TCP) ... 4

2.3 User Datagram Protocol (UDP) ... 4

2.4 Nätverksfilsystemsprotokoll ... 5

2.5 Network File System (NFS)... 5

2.6 Server Message Block (SMB) & Common Internet File System (CIFS) ... 6

2.7 Server Message Block 2.0 (SMB2) ... 7

2.8 Samba ... 7

2.9 Red Hat Enterprise Linux 5 Server ... 7

3. Metod ... 9 3.1 Labborationsmiljö ... 9 3.2 Labborationsverktyg ... 10 3.3 Metoddiskussion ... 11 4. Genomförande ... 12 4.1 Genomförandediskussion ... 14

5. Resultat & analys ... 16

5.1 Filöverförningstester ... 16 5.2 Simulering av användaraktivitet ... 20 6. Diskussion ... 25 6.1 Slutsats ... 26 6.2 Fortsatt forskning ... 27 7. Källförteckning ... 28

1. Introduktion

Centraliserad fillagring är idag standard på företag. Det finns väldigt få företag som fortfarande använder sig av decentraliserad lagring dvs. att varje användare har sina filer på sin lokala hårddisk. Det som används i dagsläget är centraliserade

lagringsplatser såsom filservrar där man lagrar sina dokument (Anidi & Nujeerallee, 2002). Nätverkslagring är ett sätt att få en centraliserad lagringslösning. Det innebär att till exempel dokument inte sparas på den lokala hårddisken utan på en gemensam server, vilket leder till att man som användare kan komma åt sina dokument oberoende på vilken dator man sitter vid så länge den datorn är inkopplad till nätverket (Anidi & Nujeerallee, 2002). För att detta ska fungera så kan man använda ett nätverksfilsystemsprotokoll såsom SMB/CIFS, SMB2 eller NFS. Det intressanta med dessa protokoll är att alla går att använda sig av om man vill ansluta med en klient som kör ett Windows operativsystem. Detta är något alla som arbetar med fildelning i Windowsklientmiljöer skulle kunna dra nytta av.

Detta arbete utgår från undersökningen ”A New Network File System is Born: Comparision of SMB2, CIFS, and NFS” som skrivits av Steven M. Frenchs på IBM Samba Team. Steven M. Frenchs undersökning är en djupgående beskrivning om protokollen och hur de skiljer sig från varandra rent teoretiskt. Vi har valt att fortsätta vår forskning från detta arbete då det saknades detaljerade prestandatester vilket vi anser är mycket relevant och intressant (French, IBM, & Team, 2007).

I den här rapporten testas dessa protokoll mot varandra genom att kopiera och öppna filer och dokument med olika prestandaverktyg som räknar ut hastighet och tid för att på så sätt komma fram till vilket som är snabbast under olika omständigheter.

1.1 Syfte och frågeställningar

Syftet med detta arbete är att få svar på vilket protokoll som har snabbast överförningshastighet, hur protokollen skiljer sig mellan olika operativsystem i hastighet och hur hastigheten påverkas när det är fördröjningar i nätverket. Vilket protokoll bör man välja i en Windowsklientmiljö och hur stor är prestandaskillnaden beroende på om man har fördöljningar i nätverket?

1.2 Avgränsningar

Avgränsningar har gjorts till att endast testa överföringshastigheter mot Windows klienter. Detta då arbetet skulle bli för stort för att framställa en komplett utredning om vilket protokoll som är snabbast på klienter som kör andra operativsystem än Windows.

Det finns en version 4 av NFS men denna kommer inte att testas då Windows Server 2008 inte har något stöd för det än.

IPV6 gjorde så att våra klienter gick runt WAN emulatorn, därför kommer endast IPV4 att användas.

2. Teoretisk bakgrund

I detta kapitel beskrivs bland annat grundstenarna till all nätverkskommunikation såsom IPv4, IPv6, TCP och UDP, men även vad ett nätverksfilsystemsprotokoll är.

2.1 Internet Protocol version 4 & 6 (IPv4/IPv6)

Internet Protocol (IP) är den grund Internet vilar på. Alla Internetansluta datorer använder sig av IP-adresser. En sådan adress krävs för att två datorer ska kunna kommunicera med varandra över ett TCP/IP nätverk. Det finns två versioner av protokollet som används i dagsläget. Dessa är Internet Protocol version 4 (IPv4) och Internet Protocol version 6 (IPv6). IPv4 är den version som används i störst

utsträckning i dagsläget. Det finns i dagsläget endast en miljon användare av IPv6 (Gunderson, 2008), detta beror till mestadels av höga licenskostnader för protokollet samt inkompatibilitet med många av dagens program (Colitti, 2008). En av de stora anledningarna till att man vill övergå till IPv6 är att IP-adresserna helt enkelt är på väg att ta slut. IPv4 använder sig av 32-bitars adressrymd vilket innebär att det totalt finns 4 294 967 296 publika IP-adresser som kan användas. IPv6 däremot använder sig av 128-bitars adressrymd vilket innebär att det finns totalt

340 282 366 920 938 463 463 374 607 431 768 211 456 publika IP-adresser (Hogg, 2007). Olikheten på utformningen av IP-adresserna är väldigt stor, ett exempel på en IPv4 adress är 192.168.2.1/24 medans ett exempel på en Ipv6 är

2.2 Transmission Control Protocol (TCP)

TCP står för Transmission Control Protocol och är en av grundstommarna till arkitekturen av datakommunikation över nätverk. TCP utvecklades av Institute of Electrical and Electronic Engineers (IEEE) och började användas på ARPANET (föregångaren till Internet) redan 1983 (Leiner, o.a., 2000).

Tabell 3.1 TCP huvud under IPv4

Bitar 0 - 3 4 – 7 8 - 15 16 - 31 0 Avsändaradress 32 Mottagaradress 64 Nollor Protokoll TCP längd 96 Avsändarport Mottagarport 128 Sekvensnummer 160 Kvittonummer

192 Huvud Oanvänd Flagga Fönsterstorlek

224 Checksumma Prioritet

256 Inställningar

256/288+ Data

TCP protokollet är ett så kallat statefull protokoll och upprättar därför en session mellan parterna vid överförning. Som vi ser i tabell 3.1 så har TCP protokollet ett sekvens- och kvittonummer vilket gör TCP mindre känsligt för paketförlust och nätverksfördröjningar (Information Sciences Institute, 1981).

2.3 User Datagram Protocol (UDP)

Tabell 3.2 UDP huvud under IPv4

Bitar 0 – 7 8 – 15 16 – 23 24 – 31

0 Avsändaradress

32 Mottagaradress

64 Nollor Protokoll UDP längd

96 Avsändarport Mottagarport

128 Längd Checksumma

160 Data

UDP står för User Datagram Protocol och är helt stateless till skillnad från TCP statefull, med detta menas att ingen session upprättas mellan de kommunicerande parterna. Detta betyder att sändarsidan aldrig får något meddelande om paketet kom

fram eller inte. UDP är lämpligast på nätverk med låg nätverksfördröjning och där paket inte försvinner eller kommer i olika ordning då det saknas sekvens- och prioritetsnummer som visas i tabell 3.2 (Postel, 1980).

2.4 Nätverksfilsystemsprotokoll

Samlingsordet nätverksfilsystemsprotokoll är en fri översättning av ”Network File Systems Protocol” som protokollen kallas för. Syftet med dessa protokoll är att ge åtkomst till externt lagrad data (French, IBM, & Team, 2007).

2.5 Network File System (NFS)

NFS som står för ”Network File System” utvecklades av Sun Microsystems och används för att få transparent fjärraccess till sina delade filer över ett nätverk . NFS version 1 användes endast i testsyfte men efter att Sun Microsystems hade gjort stora förändringar i protokollet beslutade de sig för att släppa NFS till allmänheten och använde då namnet NFS version 2 (Sun Microsystems, Inc, 1989). Den officiella RFC för NFSv3 kom ut 1995. Version 3 har bland annat stöd för filer som är större än 4 Gigabyte, asynkron skrivning till servern, extra fil attribut och officiellt stöd för TCP som transportprotokoll (Callaghan, Pawlowsi, Staubach, & Sun Microsystems, 1995). NFS är designat för att fungera oberoende på operativsystem, nätverksarkitektur och överförningsprotokoll. Detta uppnås genom att NFS använder ”Remote Procedure Call” (RPC) och byggt på ”External Data Representation” (XDR) (Sun Microsystems, Inc, 1989). NFS har även släppts i version 4 och är byggt för att klara av

nätverksfördröjningar bättre än tidigare versioner. Detta har man lagt mycket fokus på för att protokollet skall fungera över Internet (Shepler, o.a., 2003).

Montering av en NFS utdelning fungerar på så vis att servern först startar med att lyssna på UDP och TCP port 111 efter förfrågningar från NFS klienter. När en klient monterar en NFS utdelning skickas en RPC get_port request på port 111 till servern. Servern skickar en RPC get_port reply i svar och klienten skickar tillbaka en RPC MOUNT request. Servern autentiserar klienten med hjälp av IP-adressen. Servern gör sedan en lokal montering för att sedan skicka tillbaka resultatet till klienten med en RPC MOUNT reply. Slutligen monterar klienten utdelningen med hjälp av svaret från servern och skickar en SUCCESS till NFS servern (EventHelix, Inc, 2007).

2.6 Server Message Block (SMB) & Common Internet

File System (CIFS)

SMB utvecklades till en början av Barry Feigenbaum på IBM redan 1985. Microsoft släppte sedan 1990 ut sin version i samarbete med 3Com. Efter detta tog Microsoft helt över vidareutvecklingen av protokollet (Shearer, 1996). SMB är gjort för att på enkelt vis dela filer och skrivare mellan Windowsdatorer (Microsoft Corporation, 2009).

År 1996 gav Microsoft ut en större uppdatering av SMB och passade samtidigt på att byta namn på protokollet till Common Internet File System (CIFS). Den nya

uppdateringen innebar bland annat stöd för större filer och möjligheten att fungera utan NetBIOS (Storage Networking Industry Association, 2002).

Figur 3.1 SMB, öppning av session.

Klienten använder CIFS protokollet för att begära fil och skrivar-utdelningar från servern och SMB utökar CIFS protokollets säkerhet, fil och disk-hanteringen. Klienten skapar en session med servern för att utföra de olika förfrågningarna. För att en session skall upprätthållas skickar klienten olika SMB_COM förfrågningar till servern som ger svar enligt figur 3.1. Dessa kommandon måste utföras medans en

SMB_COM_SESSION_SETUP_ANDx Request kan skickas flera gånger och får då löpnummer 1,2,3 osv. Likadant med svaret från servern används motsvarande löpnummer för Response (Microsoft Corporation, 2009).

Klient

Server

SMB_COM_NEGOTIATE Request SMB_COM_NEGOTIATE Response

SMB_COM_SESSION_SETUP_ANDx Request 1 SMB_COM_SESSION_SETUP_ANDx Response 1

2.7 Server Message Block 2.0 (SMB2)

SMB2 är en vidareutveckling av SMB/CIFS och implementerades i Windows Vista som släpptes för allmänheten 2007 (Microsoft Corporation, 2007). Protokollet är sedan dess standard i Microsofts nya operativsystem såsom Windows Server 2008 och Windows 7. SMB2 är bakåtkompatibilitet med SMB/CIFS.

2.8 Samba

Samba är en implementation för att kunna använda sig av SMB/CIFS protokollet på Unix-system. Den första versionen av Samba skrevs 1992 av Andrew Tridgell på Australian National University. (Shearer, 1996) På den tiden var SMB/CIFS ett Microsoftproprietärt protokoll. Samba utvecklades därför med hjälp av sniffprogram som avlyssnar nätverkstrafik för att undersöka hur SMB/CIFS fungerade. Från början hette Samba smbserver men fick på grund av licenstvister byta namn. Namnet Samba uppkom genom att följande kommando användes:

"grep -i '^s.*m.*b' /usr/share/dict/words". Kommandot tar fram ord som innehåller s, m och b från en ordlista som medföljer många Linuxdistributioner (Tridgell & Team, 1997).

Samba utvecklas idag av ca 30 personer som kallar sig "The Samba Team" och protokollet utvecklas ständigt. Samba släpps under "GNU General Public Licence" vilket bland annat innebär att källkoden är helt öppen (Samba). I nuläget stöds inte SMB2 men Samba teamet håller på att utveckla stöd för detta (Tridgell & Team, Exploring the SMB2 protocol, 2009).

Samba har stöd för fil och skrivartjänster, autentisering, namnuppslag och bläddring av filer över nätverket. Det finns två tjänster som Samba behöver för att fungera, dessa är smbd för att få det grundläggande SMB/CIFS tjänsterna och nmbd för att få

NETBIOS stöd (Hertel, Team, & Team, 2001).

2.9 Red Hat Enterprise Linux 5 Server

Red Hat Server är ett serveroperativsystem som finns i två olika versioner. En standard version, ”Red Hat Enterprise Linux Server” som riktar sig mot företag med mindre nätverkstjänster och ”Red Hat Enterprise Linux Advanced Platform” som främst är framtaget för deras genomsnittliga kunder. Båda versionerna är baserade på

”core”-teknologi, har stöd för serverapplikationer med öppen källkod samt

virtualiseringsstöd. Vanligtvis används operativsystemet som filserver, skrivarserver, webbserver, applikationsserver, databasserver eller nätverksinfrastrukturserver. Red Hat är baserat på Linuxkärnan 2.6.18 och har stöd för Intel x86/64/Itanium2, AMD x86/64 och IBM POWER/System z/S 390 arkitekturer. Operativsystemet har även inbyggt stöd för NFS version 4 och Samba (Red Hat, Inc, 2009).

3. Metod

Till denna undersökning ska en experimentell metod användas då nätverksmiljön kommer att manipuleras för att kunna undersöka skillnader med och utan

nätverksfördröjningar. Den experimentella metoden kommer fungera bäst för oss då vi testar oss fram till resultaten (Trochim, 2006). Testerna kommer att genomföras med olika testprogramvaror som presenterar resultaten i siffror. För att ta reda på vilka program och protokoll som ska behandlas görs en litteratursökning via internet. När programmen och protokollen är fastställda kommer olika tester att utföras. En klient, en filserver och en WAN emulator kommer att installeras och konfigureras. Därefter kommer samtliga tester utföras från klienten. Filserverns operativsystem kommer att bytas ut efter att samtliga tester är utförda för att sedan utföras mot det nya

operativsystemet. Resultaten från testerna kommer att sammanställas i ett Exceldokument och presenteras med diagram för att få en överskådlig bild.

3.1 Labborationsmiljö

Figur 4.1 Labborationsmiljö.

I testmiljön kommer två stycken Dell Poweredge 2900 datorer att användas. Den första som klient med Windows Server 2008 och den andra som filserver. Dessa två maskiner är utrustade med varsitt RAID-kort för att få maximal skriv och läshastighet på hårddiskarna. Filservern kommer alltid att konfigureras med IP-adressen

Först kommer nätverket och datorerna kopplas samman i en gigabit switch enligt figur 4.1. Därefter installeras och konfigureras klient- och serversystemet varpå testerna utförs både med och utan nätverksfördröjningar. Sedan byts operativsystemet på filservern och testerna utförs igen. Filserverdatorn kommer att först installeras med Windows Server 2003 sedan Windows Server 2008 och slutligen Red Hat Server. Operativsystemen kommer att installeras på separata hårddiskar för att enkelt kunna återgå till en tidigare installation vid behov.

För att testa hur nätverksfilsystemsprotokollen fungerar med fördröjning i nätverket används applikationen WANem. WANem kan emulera bland annat fördröjning i nätverket och installeras på en tredje dator i nätverket. För att WANem skall kunna påverka testmiljön behöver filservern och klienten konfigureras så att all data skall skickas till WAN emulatorn innan trafiken sedan skickas vidare till rätt dator. WANem kommer att konfigureras med IP-adressen 192.168.1.10/24.

3.2 Labborationsverktyg

WANem

Programvara för att emulera en WANkoppling (Internet). I programvaran kan bland annat bandbredd, fördröjning, paketförluster och paketkorruption ändras genom ett webbgränssnitt. Programmet är gratis med öppen källkod och startas med en enkel live CD som innebär att operativsystemet med programmet färdiginstallerat startas från en cd-skiva (Nambiar, 2007).

IOzone

IOzone är en programvara för att testa skriv och läshastigheter på olika filsystem. Programmet genererar en fil i bestämd storlek och använder en valfri destination för att skriva och läsa filen. Programmet startas genom en kommandotolk där det krävs att ett flertal variabler sätts.

Ett exempel kan vara variablerna: -n 32M, -i 0, -i 1, -g 5G, -q 64k, -y 64k och -f x:\001.tmp. Denna sträng gör att programmet skapar en 32 megabyte stor fil på x:\ med namnet 001.tmp som den sedan skriver och läser till. Detta upprepas sedan fast med en fil som är dubbelt så stor. Testet avbryts när filen har kommit upp i ca 4 Gigabyte. I detta fall kommer filstorlekarna 32MB, 64MB, 128MB, 256MB, 512MB, 1024MB, 2048MB och 4096MB användas (Norcott & Capps, 2009).

Teracopy

Teracopy är en programvara för att kopiera och flytta filer. Det går att ställa in så att den används istället för Windows egna inbyggda filkopieringsprogram. Teracopy har bra övervakningsfunktioner av kopiering som kan visa hastighet, återstående tid och hur lång tid det tog att kopiera en fil (Code Sector, Inc, 2009).

Cisco WAFS benchmark

WAFS benchmark eller ”Wide Area File Services Software Benchmark Tool for Microsoft Office Applications” som det egentligen heter är en programvara för att testa tiden det tar att öppna, redigera, spara och stänga olika PowerPoint, Word och Excel dokument i storlekarna 50kb, 100kb, 200kb, 500kb, 1mb och 2mb. Programmet kräver en installation av Microsoft Office paket och kan användas mot den lokala hårddisken men också en nätverksutdelning (Cisco Systems, Inc, 2004).

3.3 Metoddiskussion

Den experimentella metod som använts visar en lättöverskådlig bild av resultaten. Alla de tester som utfördes under genomförandet gjordes tre gånger. Därefter räknades medelvärdet fram vilket är det som presenteras i arbetet. Detta gjordes för att minimera felaktiga resultat som kan bero på hårddiskar, övrig nätverkstrafik och operativsystemet. Fördelen med en experimentell miljö jämfört med en verklig miljö är att vi har möjlighet att ändra de olika variablerna i nätverket som exempelvis

nätverksfördröjningar samt utesluta andra felkällor. En nackdel skulle kunna vara att företag använder olika program och andra nätverkstjänster som påverkar protokollens prestanda och på så vis kan ge andra resultat. Vi vill jämföra enbart protokollens prestanda och inte hur protokollen fungerar i olika företagsmiljöer, därför anser vi inte att detta skulle vara ett problem. De verktyg vi använder för att testa protokollen ger oss resultat som avspeglar verkligheten till stor grad då de utför operationer på ett snarlikt sätt som om protokollen skulle används ute på ett företag. Dock kan vi aldrig härma ett företags vardagliga beteende med dessa verktyg vilket kan vara en nackdel. Testmiljön och verktygen är densamma för alla olika protokoll vilket ger oss rättvisa, korrekta och trovärdiga tester.

4. Genomförande

Dell PowerEdge servrarna och WANem maskinen kopplades samman i en gigabit switch enligt figur 4.1. Sedan konfigurerades RAID-Kortet på Dell PowerEdge servrarna med följande inställningar:

Volym 1 (Operativsystem): Antal diskar 1

Typ Raid0

Skrivblocks storlek 256kb

Läspolicy Adaptive readahead Skrivpolicy Writeback Volym 2 (Testhårddisk):

Antal diskar 3

Typ Raid0

Skrivblocks storlek 256kb

Läspolicy Adaptive readahead Skrivpolicy Writeback

WAN emulatorn startades upp med Live CD. Scenario 1

Första testscenariot är mellan en Windows Server 2003 som filserver och en Windows Server 2008 som klient. Operativsystemen installerades och uppdaterades. På klienten installerades Microsoft Office 2007, IOzone, WAFS Benchmark och Teracopy. För att få trafiken att gå genom WAN emulatorn kördes följande kommandon:

C:\> route add 192.168.1.1 MASK 255.255.255.255 192.168.1.10 //på klienten. C:\> route add 192.168.1.2 MASK 255.255.255.255 192.168.1.10 //på filservern.

För att kontrollera att de verkligen går igenom WAN emulatorn kördes följande kommando på klienten:

C:\> tracert 192.168.1.1

Tjänsten ”Services for Network File Systems” installerades på både klienten och filservern och säkerhetspolicyn ”Network access: Let Everyone permissions apply to anonymous users” startades på filservern. Katalogerna e:\smbshare delades ut med SMB/CIFS och e:\nfsshare med NFSv3. Till båda katalogerna gavs fulla rättigheter och på e:\nfsshare byttes ägaren till användaren Alla. På klienten valdes NFS-TCP och de utdelade katalogerna anslöts enligt följande:

C:\> Mount –o anon \\192.168.1.1\nfsshare x: C:\> Net use \\192.168.1.1\smbshare z:

Tester utfördes med IOzone, WAFS Benchmark och Teracopy mot x: och z:. På WAN emulatorn ställdes 10ms fördröjning in vilket resulterade i 25ms

nätverksfördröjning och testerna utfördes åter igen med samma programvaror. Sedan ändrades inställningarna till NFS-UDP och alla tester utfördes mot x: igen med och utan nätverksfördröjning.

Scenario 2

Det andra testscenariot är mellan två Windows Server 2008 där det ena agerar filserver och det andra klient. I filservern byttes hårddisken som Windows Server 2003 var installerad på ut mot en ny där Windows Server 2008 installerades och uppdaterades. För att nätverkstrafiken ska gå igenom WAN emulatorn kördes följande kommando i kommandotolken på filservern:

C:\> route add 192.168.1.2 MASK 255.255.255.255 192.168.1.10

Rolltjänsten ”Services for Network File Systems” installerades och säkerhetspolicyn ”Network access: Let Everyone permissions apply to anonymous users” startades. Katalogerna e:\smbshare delades ut med SMB2 och e:\nfsshare med delades ut med NFSv3. Katalog rättigheterna ändrades till fulla rättigheter och för e:\nfsshare byttes ägaren till användaren Alla. På klientdatorn valdes NFS-TCP och de utdelade katalogerna anslöts enligt följande:

C:\> Mount –o anon \\192.168.1.1\nfsshare x: C:\> Net use \\192.168.1.1\smbshare z:

Tester utfördes med IOzone, WAFS Benchmark och Teracopy mot x: och z:. På WAN emulatorn ställdes 10ms fördröjning in vilket resulterade i 25ms

nätverksfördröjning och testerna kördes igen. Sedan ändrades TCP till NFS-UDP och därefter utfördes alla testerna mot x: igen med och utan nätverksfördröjning. Scenario 3

Tredje och det sista testscenariot utfördes mellan en Red Hat Server som filserver och en Windows 2008 som klient. I filservern byttes hårddisken som Windows Server 2008 var installerat på ut mot en ny där Red Hat Server installerades. Operativsystemet uppdaterades fullt ut och tjänsten Samba installerades. På filservern kördes följande kommando för att trafiken ska gå igenom WAN emulatorn:

Den stora raid volymen monterades på /share och där i skapades två mappar, nfsshare och smbshare. För att dela ut /share/nfsshare editerade vi /etc/export med följande:

/share/nfsshare *(rw,sync,insecure_locks,anonuid=500,anongid=500)

För att dela ut /share/smbshare editerades /etc/samba/smb.conf enligt följande:

[global]

workgroup = WORKGROUP server string = samba netbios name = LINUX security=user

passdb backend = smbpasswd [smbshare]

comment = Samba

path = /share/smbshare public=yes

writable=yes

Därefter startades tjänsterna om för NFS och Samba om med följande kommandon:

Linux# services nfs restart Linux# services smb restart

På klientdatorn valdes NFS-TCP och de utdelade katalogerna anslöts enligt följande:

C:\> mount –o anon \\192.168.1.1\share\nfsshare x: C:\> net use \\192.168.1.1\smbshare z:

Testerna utfördes med IOzone, WAFS Benchmark och Teracopy mot x: och z:. I WAN emulatorn ställdes 10ms fördröjning in vilket resulterade i 25ms

nätverksfördröjning. Därefter utfördes testerna med WAFS Benchmark och Teracopy igen. Sedan ställdes NFS-TCP in till NFS-UDP och testerna utfördes igen mot x: med och utan nätverksfördröjning.

4.1 Genomförandediskussion

Vi använder oss Windows Server 2008 som klient då de datorerna vi har fått låna är gjorda för serveroperativsystem vilket gjorde att det fattades drivrutiner för att använda Windows Vista på dessa.Windows server 2008 har IPv6 aktiverat som standard. Detta påverkade de första testerna mellan Windows server 2008 som klient och filserver. Trafiken gick inte genom WAN emulatorn då endast IPv4 trafiken skickades vidare till denna dator och operativsystemet tog den kortaste vägen till

filservern som var genom IPv6. Detta löstes enkelt genom att stänga av IPv6 stödet och utföra testerna igen.

Att testerna görs mot en Windows Server 2008 som klient kan ge en missvisande bild då exempelvis NFS är något som vanligtvis används på Linux och Unix system. Därför är det viktigt att vi påpekar att testerna utförs mot en Windows Server 2008 som klient och är medvetna om att NFS kan vara snabbare mellan exempelvis två Linux maskiner.

Prestandan kan ha blivit begränsad på grund av hårdvaran som använts. För att minska denna begränsning används ett ”Intel® PRO/1000 PT Dual Port Server Adapter” nätverkskort och en RAID 0 med tre hårddiskar på filservern och klienten. Hårdvaran är samma för alla tester.

Operativsystemen kan behandla förfrågningar olika och det är viktigt att man inte jämför protokollen mellan operativsystemen utan att man är medveten om vilket operativsystem och protokoll som användes för det aktuella testet.

WAN emulatorn kan påverka prestandan även utan att fördröjning är påslaget då all trafik går genom denna dator. Dock påverkar detta inte skillnader mellan protokollen i och med att trafiken alltid går genom WAN emulatorn.

Sammanfattningsvis anser vi att metoden är pålitlig då testerna är utförda med flera olika verktyg och skillnaderna bör stämma överrens med verkligheten. Dock är det inte säkert att överförningskapaciteten är maximerad men det är inte heller intressant i denna undersökning utan det är skillnaderna som är det intressanta.

5. Resultat & analys

Nedan följer resultaten av de tester som utfördes. För att minska felmarginalen utfördes varje enskilt test tre gånger. De resultat som presenteras i figurerna är genomsnittet av dessa tre tester.

5.1 Filöverförningstester

De första resultaten är med testprogramvaran IOzone. Det första testet som utfördes var med Windows Server 2008 på klientdatorn och Windows Server 2003 på

filservern. Dessa tester utfördes utan fördröjning i nätverket.

Figur 6.1 Avläsning med IOzone mot Windows Server 2003.

Figur 6.1 visar att SMB ligger i snitt 59,49 megabyte per sekund och snittet på NFS-TCP är 37,57 megabyte per sekund. Detta är en skillnad på 32 megabyte per sekund vilket är en enorm skillnad. SMB är nästan dubbelt så snabbt som NFS-TCP.

Intressant att tillägga var att NFS-UDP testet inte har något resultat då det inte gick att köra testet beroende på rättighetsproblem på nätverksdisken.

32MB 64MB 128MB 256MB 512MB 1024MB 2048MB 4096MB SMB/CIFS 59MB/s 58MB/s 59MB/s 59MB/s 59MB/s 62MB/s 60MB/s 60MB/s NFS-TCP 38MB/s 38MB/s 38MB/s 37MB/s 37MB/s 37MB/s 37MB/s 38MB/s 0MB/s 10MB/s 20MB/s 30MB/s 40MB/s 50MB/s 60MB/s 70MB/s 80MB/s 90MB/s 100MB/s

Figur 6.2 Avläsning med IOzone mot Windows Server 2008.

Det andra testet gjordes likadant som det föregående däremot kördes Windows Server 2008 på filservern. Detta gjorde att SMB kördes i version 2. Enligt testersultaten i figur 6.2 så har SMB2 ett snitt på 80,22 MB/sek, NFS-TCP 36,08 MB/sek och NFS-UDP 26,03 MB/sek. Skillnaderna är ännu större i detta test då SMB2 är över dubbel så snabbt som NFS-TCP och tredubbelt så snabbt som NFS-UDP.

Figur 6.3 Avläsning med IOzone mot Red Hat Server.

Det sista testet med IOzone gjordes när filservern körde Red Hat Server. Enligt figur 6.3 så kan vi se att SMB har ett snitt på 59,35 MB/sek, NFS-TCP 37,36 MB/sek och NFS-UDP 28,52 MB/sek. Det vi kan konstatera direkt är att SMB inte är lika snabbt som det var när man delade ut det genom Windows server. SMB är 37 procent snabbare än NFS-TCP och 52 procent snabbare än NFS-UDP.

32MB 64MB 128MB 256MB 512MB 1024MB 2048MB 4096MB SMB2 80MB/s 81MB/s 81MB/s 80MB/s 82MB/s 79MB/s 80MB/s 79MB/s NFS-TCP 36MB/s 36MB/s 37MB/s 36MB/s 35MB/s 36MB/s 36MB/s 37MB/s NFS-UDP 26MB/s 26MB/s 26MB/s 25MB/s 26MB/s 26MB/s 26MB/s 27MB/s 0MB/s 10MB/s 20MB/s 30MB/s 40MB/s 50MB/s 60MB/s 70MB/s 80MB/s 90MB/s 100MB/s

Avläsning med IOzone mot Windows Server 2008 Enterprise

32MB 64MB 128MB 256MB 512MB 1024MB 2048MB 4096MB Samba - SMB/CIFS 58MB/s 57MB/s 55MB/s 62MB/s 61MB/s 60MB/s 62MB/s 58MB/s NFS-TCP 38MB/s 38MB/s 38MB/s 37MB/s 37MB/s 37MB/s 37MB/s 37MB/s NFS-UDP 29MB/s 28MB/s 29MB/s 29MB/s 29MB/s 29MB/s 28MB/s 28MB/s 0MB/s 10MB/s 20MB/s 30MB/s 40MB/s 50MB/s 60MB/s 70MB/s 80MB/s 90MB/s 100MB/s

Figur 6.4 Sammanställd avläsning med IOzone.

Enligt figur 6.4 så är SMB2 överlägset i IOzone testerna. Efter SMB2 kommer SMB/CIFS därefter NFS-TCP och i botten NFS-UDP. I detta test konstateras att SMB2 är det man ska använda sig av om man sitter i en miljö med Windows klienter och vill få högst överföringshastighet.

32MB 64MB 128MB 256MB 512MB 1024MB 2048MB 4096MB Win2008 - SMB2 80MB/s 81MB/s 81MB/s 80MB/s 82MB/s 79MB/s 80MB/s 79MB/s Win2003 - SMB/CIFS 59MB/s 58MB/s 59MB/s 59MB/s 59MB/s 62MB/s 60MB/s 60MB/s RedHat - Samba 58MB/s 57MB/s 55MB/s 62MB/s 61MB/s 60MB/s 62MB/s 58MB/s Win2003 - NFS-TCP 38MB/s 38MB/s 38MB/s 37MB/s 37MB/s 37MB/s 37MB/s 38MB/s RedHat - NFS-TCP 38MB/s 38MB/s 38MB/s 37MB/s 37MB/s 37MB/s 37MB/s 37MB/s Win2008 - NFS-TCP 36MB/s 36MB/s 37MB/s 36MB/s 35MB/s 36MB/s 36MB/s 37MB/s RedHat - NFS-UDP 29MB/s 28MB/s 29MB/s 29MB/s 29MB/s 29MB/s 28MB/s 28MB/s Win2008 - NFS-UDP 26MB/s 26MB/s 26MB/s 25MB/s 26MB/s 26MB/s 26MB/s 27MB/s Win2003 - NFS-UDP 0MB/s 0MB/s 0MB/s 0MB/s 0MB/s 0MB/s 0MB/s 0MB/s 0MB/s 5MB/s 10MB/s 15MB/s 20MB/s 25MB/s 30MB/s 35MB/s 40MB/s 45MB/s 50MB/s 55MB/s 60MB/s 65MB/s 70MB/s 75MB/s 80MB/s 85MB/s 90MB/s 95MB/s 100MB/s M e gaB yt e i Se kunde n

Nästa test som utfördes var filöverföring av en förbestämd fil på 3,7gb. Testet gjordes först utan och sedan med nätverksfördröjning på 25ms.

Figur 6.5 Filöverförning.

De vänstra staplarna i figur 6.5 representerar testet utan nätverksfördröjning och SMB2 har en snitthastighet på 102,67MB/s vilket är väldigt snabbt då nätverkets teoretiska maxhastighet är 128 MB/s. SMB2 följs av SMB/CIFS med en snitthastighet på 98MB/s och Red Hat Samba på 97,46 MB/s. Därefter följer NFS-TCP med snitthastighet på 36,18 MB/s och i botten NFS-UDP med en snitthastighet på 27,4MB/s.

Testerna som gjordes med nätverksfördröjning gav väldigt intressanta resultat. För SMB2 så halveras hastigheten till 41,80MB/s detta kan ses som en drastisk förlust i hastighet. Detta är inte speciellt stor förlust om vi tittar på skillnaderna i SMB protokollet. Där har hastigheten gått ner från 97,46 MB/s till endast 4,76 MB/s. Trenden på enorma skillnader fortsätter där NFS-TCP går ner från 36,18 MB/s till endast 1,2 MB/s och NFS-UDP går ner från 27,4 MB/s till 1,16 MB/s i snitt. NFS hastigheterna påverkas väldigt mycket av nätverksfördröjningen och detta skulle innebära att vissa applikationer som behöver stora mängder data skulle sluta fungera.

0ms Nätverksördröjning 25ms Nätverksfördröjning Win2008 SMB2 103MB/s 42MB/s Win2003 SMB/CIFS 98MB/s 5MB/s RedHat Samba 97MB/s 5MB/s Win2008 NFS-TCP 38MB/s 1MB/s Win2003 NFS-TCP 36MB/s 1MB/s RedHat NFS-TCP 35MB/s 1MB/s Win2003 NFS-UDP 28MB/s 1MB/s RedHat NFS-UDP 27MB/s 1MB/s Win2008 NFS-UDP 27MB/s 1MB/s 0MB/s 10MB/s 20MB/s 30MB/s 40MB/s 50MB/s 60MB/s 70MB/s 80MB/s 90MB/s 100MB/s 110MB/s

5.2 Simulering av användaraktivitet

De sista testerna som gjordes var med testprogramvaran Cisco WAFS benchmark. Detta test mäter hur lång tid det tar att öppna och spara Microsoft Word dokument i .doc format på den valda nätverksdisken. Programmet skapar sex olika dokument i storlekarna 50, 100, 200, 500, 1024 och 2048 kilobyte. Testerna för att öppna och spara dokument utfördes en gång utan och en gång med nätverksfördröjning på 25ms.

Figur 6.6 WAFS Benchmark – Tid för att öppna filer.

50K 100K 200K 500K 1024K 2048K NFS-TCP Win2003 1,08s 8,83s 1,37s 1,22s 2,23s 1,67s NFS-TCP Win2008 39,34s 22,93s 29,98s 26,64s 15,16s 15,65s NFS-TCP RedHat 0,94s 1,01s 1,28s 1,09s 1,37s 1,45s NFS-UDP Win2003 NFS-UDP Win2008 26,44s 34,34s 26,71s 20,53s 20,95s 38,16s NFS-UDP RedHat 0,91s 1,00s 1,56s 1,25s 1,36s 1,67s SMB/CIFS Win2003 1,12s 1,29s 1,40s 1,37s 1,92s 1,90s SMB2 Win2008 1,04s 1,06s 1,40s 1,17s 1,42s 1,42s Samba RedHat 1,00s 1,04s 1,51s 1,23s 1,33s 1,70s 0,00s 2,00s 4,00s 6,00s 8,00s 10,00s 12,00s 14,00s 16,00s 18,00s 20,00s 22,00s 24,00s 26,00s 28,00s 30,00s 32,00s 34,00s 36,00s 38,00s 40,00s Ti d i s e kunde r

Figur 6.6 visar hur lång tid det tog att öppna dokumenten i sekunder. Överlag ligger SMB, SMB2, NFS TCP och NFS UDP väldigt nära varandra förutom när filservern kör Windows Server 2008. Detta test visar att det inte är några större skillnader mellan SMB, SMB2 och NFS utan det skiljer endast millisekunder. Däremot när Server 2008 används med NFS tar det i snitt 24,95 sekunder att öppna dokumentet, detta är väldigt lång tid och skulle inte accepteras i en arbetsmiljö.

Figur 6.7 WAFS Benchmark – Tid för att spara filer.

50K 100K 200K 500K 1024K 2048K NFS-TCP Win2003 0,17s 1,81s 0,69s 0,33s 1,11s 0,89s NFS-TCP Win2008 36,38s 19,31s 25,66s 14,23s 26,26s 25,86s NFS-TCP RedHat 0,16s 0,16s 0,28s 0,33s 1,08s 0,81s NFS-UDP Win2003 NFS-UDP Win2008 22,17s 25,76s 22,29s 14,35s 14,96s 35,40s NFS-UDP RedHat 0,20s 0,27s 0,39s 0,34s 1,09s 0,92s SMB/CIFS Win2003 0,20s 0,39s 0,33s 0,42s 1,16s 0,81s SMB2 Win2008 0,17s 0,17s 0,28s 0,34s 1,11s 0,80s Samba RedHat 0,19s 0,30s 0,34s 0,37s 1,09s 0,91s 0,00s 2,00s 4,00s 6,00s 8,00s 10,00s 12,00s 14,00s 16,00s 18,00s 20,00s 22,00s 24,00s 26,00s 28,00s 30,00s 32,00s 34,00s 36,00s 38,00s Ti d i s e kunde r

Figur 6.7 visar hur lång tid det tog att spara dokumenten på nätverksdisken. Här visas även att desto större filerna blir desto längre tid tar det att spara filerna. Testet visar även här väldigt stora skillnader när NFS utdelningen ligger på Server 2008. Det tar i snitt 24,95 sekunder att skriva ett dokument i NFS-TCP vilket är väldigt högt om man tittar på snittet för NFS-TCP i Server 2003 som ligger på 2,73 sekunder. Testet ger oss liknade resultat som testet för att läsa filer så även här är det inga större skillnader på SMB, SMB2 och NFS.

Figur 6.8 WAFS Benchmark – Tid för att öppna filer med fördröjning.

Nästa test är det första som utfördes med 25ms nätverksfördröjning mellan filserver och klient. I testet för öppning av dokument är det en klar skillnad mellan NFS och SMB respektive SMB2. Enligt figur 6.8 är snittet för att öppna dokumenten i NFS-TCP 2,17 sekunder, NFS-UDP 3,41 sekunder, SMB 4,58 sekunder och till sist SMB2 med ett snitt på 2,92 sekunder. Detta visar att NFS-TCP är snabbast, därefter kommer SMB2 följt av NFS-UDP och sist SMB.

50K 100K 200K 500K 1024K 2048K NFS-TCP Win2003 1,48s 1,42s 1,90s 1,95s 2,51s 3,37s NFS-TCP Win2008 29,83s 22,98s 35,19s 35,37s 21,31s 24,96s NFS-TCP RedHat 1,47s 1,56s 2,05s 2,11s 2,62s 3,50s NFS-UDP Win2003 NFS-UDP Win2008 20,26s 34,90s 24,37s 23,51s 27,10s 25,05s NFS-UDP RedHat 2,73s 2,75s 3,17s 3,31s 3,79s 4,74s SMB/CIFS Win2003 3,70s 4,21s 4,23s 4,04s 4,96s 5,69s SMB2 Win2008 2,62s 2,67s 3,07s 2,90s 3,06s 3,20s Samba RedHat 3,95s 4,15s 4,59s 4,74s 5,04s 5,65s 0,00s 2,00s 4,00s 6,00s 8,00s 10,00s 12,00s 14,00s 16,00s 18,00s 20,00s 22,00s 24,00s 26,00s 28,00s 30,00s 32,00s 34,00s 36,00s Ti d i s e kunde r

Figur 6.9 WAFS Benchmark – Tid för att spara filer med fördröjning.

I det fjärde och sista testet uppmättes hur lång tid det tog att spara dokumenten med en nätverksfördröjning av 25MS. Enligt figur 6.9 får NFS-TCP och NFS-UDP väldigt dåliga resultat när de delas ut från en Windows Server 2008. Det är en hel del

intressanta skillnader mellan SMB, SMB2 och NFS. Utan NFS från Server 2008 har NFS-TCP ett snitt på 1,6 sekunder och NFS-UDP 3,1 sekunder. NFS-TCP resultatet är väldigt bra då SMB har ett snitt på 3,75 sekunder och SMB2 2,89 sekunder. NFS-TCP vinner detta test då det är 1,29 sekunder snabbare än SMB2 att spara filer.

50K 100K 200K 500K 1024K 2048K NFS-TCP Win2003 0,87s 0,89s 1,08s 1,33s 2,29s 2,85s NFS-TCP Win2008 22,95s 30,23s 23,82s 23,42s 27,14s 25,74s NFS-TCP RedHat 0,95s 1,00s 1,19s 1,44s 2,34s 2,93s NFS-UDP Win2003 NFS-UDP Win2008 38,59s 34,43s 34,76s 26,18s 35,99s 31,90s NFS-UDP RedHat 2,42s 2,47s 2,64s 2,87s 3,81s 4,40s SMB/CIFS Win2003 3,37s 3,45s 3,67s 3,74s 4,60s 4,69s SMB2 Win2008 2,50s 2,50s 2,64s 2,81s 3,59s 3,31s Samba RedHat 3,25s 3,23s 3,40s 3,45s 4,18s 3,99s 0,00s 2,00s 4,00s 6,00s 8,00s 10,00s 12,00s 14,00s 16,00s 18,00s 20,00s 22,00s 24,00s 26,00s 28,00s 30,00s 32,00s 34,00s 36,00s 38,00s 40,00s Ti d i s e kunde r

6. Diskussion

I detta kapitel kommer vi göra en reflektion över hur de olika

nätverksfilsystemsprotokollen presterade i hastighet och tid för att öppna och spara filer.

SMB/CIFS

En SMB utdelning från en Windows Server 2003 är något snabbare än en Samba utdelning från Red Hat Linux även fast de använder samma protokoll. Detta tror vi beror på att Samba är framställt utan källkoden till SMB vilket kan leda till att Samba inte är lika optimerat som SMB/CIFS. I filöverföringstestet enligt figur 6.5 visar att protokollet fungerar bra så länge det inte finns någon större nätverksfördröjning. Det klarar nästan av att maximera nätverkets kapacitet. När vi däremot lägger på

nätverksfördröjning så tappar vi en stor del av hastigheten som vi kan se på figur 6.5. Detta beror på att SMB/CIFS är känsligt för nätverksfördröjningar. Om vi tittar på figurerna 6.6 och 6,7 så ser vi att Linux Samba utdelningen är snabbare än SMB utdelningen från Windows Server 2003 när det gäller att öppna och spara dokument. Enligt figurerna 6.8 och 6.9 så ser vi även där att de har väldigt lika tider. En av anledningarna till de små tidskillnaderna kan bero på klienten då den ska öppna dokumentet i Word göra en ändring och sedan spara det.

SMB2

I figur 6.4 så ser vi att SMB2 är överlägset de andra protokollen. Detta beror troligtvis på att SMB2 är en uppdaterad version som även har ett effektivare protokollhuvud. Detta gör att mer data kan skickas inom samma bandbredd. I filöverföringstestet enligt figur 6.5 kan vi se att SMB2 är snabbast utan nätverksfördröjning men även med. Detta tror vi beror på att protokollet har utökat stöd för nätverksfördröjningar som resulterar i att protokollet fungerar över Internet och överbelastande nät. I WAFS Benchmark testerna enligt figurerna 6.6, 6.7, 6.8 och 6.9 så ser vi att SMB2 har liknande resultat som SMB/CIFS både med och utan nätverksfördröjningar men att SMB2 är något snabbare. Detta tror vi även vid detta tillfälle beror på uppdateringar i protokollet.

NFS

Det första vi ser i figur 6.4 är att NFS med både TCP och UDP är klart långsammare än SMB/CIFS och SMB2. Detta beror troligtvis på att Microsoft inte har optimerat stödet för NFS samt att NFS kräver en tilläggstjänst i Windows för att fungera. Vi kan

även se att NFS överförningar med TCP protokollet är något snabbare än med UDP protokollet. Detta tror vi beror på att NFS är optimerat för att använda TCP som transportprotokoll. Anledningen till att IOzone och WAFS Benchmark testerna med NFS-UDP inte fungerade i Windows Server 2003 tror vi beror på rättighetsproblem då testprogrammen skapar filer automatiskt med fel rättigheter. I filöverförningstestet enligt figur 6.5 visar att NFS-TCP är något snabbare igen än NFS-UDP och att båda hanterar nätverksfördröjningar dåligt. Anledningen till detta tror vi beror på att vi använder NFSv3 som inte är anpassat för nätverksfördröjningar eller att vi använder en Windows Server 2008 som klient. Figur 6.6, 6.7, 6.8 och 6.9 visar att NFS med TCP har en kortare åtkomsttid. Samt att NFS fungerar bättre nät utdelningen ligger på en Red Hat Server. Windows Server 2008 hanterar NFS dåligt då det tar mellan 20-30 sekunder innan filen kan öppnas eller sparas. Detta tror vi beror på att Red Hat Server hanterar en NFS utdelning mycket bättre än Windows Server 2008. Windows Server 2003 hanterar däremot NFS-TCP nästan lika bra som Red Hat Server. Varför Windows Server 2003 hanterar NFS-TCP bättre än Windows Server 2008 har vi inte hittat någon anledning till.

6.1 Slutsats

Då vi nu har testat filöverföring med de tre olika nätverksfilsystemsprotokollen har vi kommit fram till att NFSv4 inte är implementerat i Windows Server 2008 vilket har lett till att vi har testat NFSv3. Enligt våra tester fungerar NFSv3 i Windows Server 2008 men ger inte samma hastighet som SMB/CIFS och SMB2. Detta är förståligt då vi endast har testat till Windowsklienter. Vi måste ändå påpeka att NFS inte är något dåligt nätverksfilsystemsprotokoll det är bara inte implementerat från börjar i Windows kärnan, det är en tilläggstjänst. Detta resulterar att det blir problem med rättigheter men även hastigheter. Vi har även konstaterat att SMB/CIFS och NFS ger låga överföringshastigheter när det finns fördröjningar på nätverket, detta till skillnad mot SMB2 som klarar dessa fördröjningar betydligt bättre. I våra tester var NFS väldigt snabbt när det kom till att öppna och spara filer vilket är ett stort plus. Vi har även kunnat se att om NFS skall användas i Windowsklientmiljö bör NFS-TCP användas, detta då NFS-UDP i Windows Server 2003 inte fungerade alls.

Om vi skulle göra en rekommendation till val av ett nätverksfilsystemsprotokoll för användning i Windowsklientmiljö skulle vi i dagsläget välja SMB2 då det har högst överföringshastighet och hanterar nätverksfördröjningar väldigt bra.

6.2 Fortsatt forskning

Vi tror att NFS version 4 kan vara något att göra fortsatta studier på när stöd för detta släpps för Windows. En annan intressant framtida studie skulle vara att undersöka hur Samba hanterar SMB2 när stöd för detta kommer. Det skulle även kunna göras en liknande undersökning fast med olika klient operativsystem så som Windows 7, Vista eller någon Linux distribution.

7. Källförteckning

Anidi, D. V., & Nujeerallee, S. (October 2002). Storage area networking - an introduction

and future development trends. Hämtat från SpringerLink:

http://www.springerlink.com/content/mrj502632v274735/fulltext.pdf den 12 Maj 2009

Callaghan, B., Pawlowsi, B., Staubach, P., & Sun Microsystems, I. (Juni 1995). NFS

Version 3 Protocol Specification. Hämtat från The Internet Engineering Task Force:

http://www.ietf.org/rfc/rfc1813.txt den 5 April 2009

Cisco Systems, Inc. (2004). Cisco WAFS Benchmark Tool for Microsoft Office Applications

Installation and Configuration Note. Hämtat från Cisco:

http://www.cisco.com/en/US/docs/app_ntwk_services/waas/wafs/v30/benchmark /benchmrk.pdf den 19 April 2009

Code Sector, Inc. (2009). Teracopy. Hämtat från Code Sector: http://www.codesector.com/teracopy.php den 10 April 2009

Colitti, L. (2008). A strategy for IPv6 adoption. Hämtat från RIPE Network Coordination Centre:

http://www.ripe.net/ripe/meetings/ripe-57/presentations/Colitti-A_strategy_for_IPv6_adoption.Z8ri.pdf den 11 Maj 2009

Deering, S., Cisco, Hinden, R., & Nokia. (December 1998). Internet Protocol, Version 6

(IPv6) Specification. Hämtat från The Internet Engineering Task Force:

http://www.ietf.org/rfc/rfc2460.txt den 11 Maj 2009

EventHelix, Inc. (den 11 Augusti 2007). Network File System Protocol (NFS Protocol

Sequence Diagram). Hämtat från EventHelix:

http://www.eventhelix.com/RealtimeMantra/Networking/NFS_Protocol_Sequence_ Diagram.pdf den 7 Maj 2009

French, M. S., IBM, & Team, S. (2007). A New Network File System is Born: Comparison of

SMB2, CIFS and NFS. Hämtat från Samba:

ftp://219.106.227.18/pub/samba/cifs-cvs/ols2007-paper-smb2-french.pdf den 11 Maj 2009

Gunderson, S. H. (2008). Global IPv6 statistics. Hämtat från The Internet Engineering Task Force: http://www.ietf.org/proceedings/08nov/slides/v6ops-4.pdf den 11 Maj 2009

Hertel, C., Team, S., & Team, j. (den 27 11 2001). Samba: An Introduction. Hämtat från Samba: http://us3.samba.org/samba/docs/SambaIntro.html den 5 Maj 2009 Hogg, S. (2007). Internet Protocol version 6. Hämtat från Global Technology Recources, Inc:

http://www.gtri.com/docs/IPv6%20-%20The%20Next%20Generation%20Protocol%20v1-1.pdf den 5 Maj 2009

Information Sciences Institute. (1981). Hämtat från The Internet Engineering Task Force:

http://www.ietf.org/rfc/rfc0793.txt den 5 Maj 2009

Leiner, B. M., Cerf, V. G., Clark, D. D., Kahn, R. E., Leonard, K., Lynch, D. C., o.a. (den 4 Augusti 2000). A Brief History of the Internet. Hämtat från Institute for

Information Systems and Computer Media:

http://www.iicm.tugraz.at/thesis/cguetl_diss/literatur/Kapitel02/References/Leiner _et_al._2000/brief.html den 5 Maj 2009

Microsoft Corporation. (den 11 April 2009). [MS-SMB]: Server Message Block (SMB)

Protocol Specification. Hämtat från Microsoft:

http://download.microsoft.com/download/a/e/6/ae6e4142-aa58-45c6-8dcf-a657e5900cd3/%5BMS-SMB%5D.pdf den 6 Maj 2009

Microsoft Corporation. (2009). [MS-SMB]: Server Message Block (SMB) Protocol

Specification, Sequence Diagram. Hämtat från Microsoft Developer Network:

http://msdn.microsoft.com/en-us/library/cc246380(PROT.13).aspx den 7 Maj 2009 Microsoft Corporation. (2007). Press Release: Microsoft Launches Windows Vista and the

2007 Office System to Consumers. Hämtat från Microsoft:

http://www.microsoft.com/nz/presscentre/articles/2007/jan07_windowsvistalaunch .mspx den 6 Maj 2009

Nambiar, M. K. (den 27 April 2007). WANem 1.1 Wide Area Network Emulator User

Guide. Hämtat från WANem The Wide Area Network emulator:

http://switch.dl.sourceforge.net/sourceforge/wanem/WANemv11-User-Guide.pdf den 15 April 2009

Norcott, W. D., & Capps, D. (2009). Iozone Filesystem Benchmark. Hämtat från Iozone: http://www.iozone.org/docs/IOzone_msword_98.pdf den 20 April 2009

Postel, J. (den 28 Augusti 1980). User Datagram Protocol. Hämtat från The Internet Engineering Task Force: http://www.ietf.org/rfc/rfc0768.txt den 5 Maj 2009

Red Hat, Inc. (2009). Red Hat Enterprise Linux 5 server. Hämtat från Red Hat: http://www.redhat.com/rhel/server/ den 6 Maj 2009

Samba. (u.d.). Samba Team. Hämtat från Samba: http://us3.samba.org/samba/team/ den 5 Maj 2009

Shearer, D. (den 16 November 1996). History of SMB Project. Hämtat från Samba: http://www.samba.org/cifs/docs/smb-history.html den 5 Maj 2009

Shepler, S., Callaghan, B., Robinson, D., Thurlow, R., Inc, S. M., Beame, C., o.a. (April 2003). Network File System (NFS) version 4 Protocol. Hämtat från The Internet

Engineering Task Force: http://www.ietf.org/rfc/rfc3530.txt den 9 Juni 2009 Storage Networking Industry Association. (den 3 Januari 2002). Common Internet File

System (CIFS) Technical Reference Rev:1.0. Hämtat från SNIA:

http://www.snia.org/tech_activities/CIFS/CIFS-TR-1p00_FINAL.pdf den 6 Maj 2009

Sun Microsystems, Inc. (Mars 1989). NFS: Network File System Protocol Specification. Hämtat från The Internet Engineering Task Force:

http://www.ietf.org/rfc/rfc1094.txt den 15 April 2009

Tridgell, A., & Team, S. (den 27 Juni 1997). A bit of history and a bit of fun. Hämtat från RXN Communications: http://www.rxn.com/services/faq/smb/samba.history.txt den 6 Maj 2009

Tridgell, A., & Team, S. (2009). Exploring the SMB2 protocol. Hämtat från Samba: http://www.samba.org/~tridge/smb2.pdf den 10 05 2009

Trochim, W. M. (den 20 10 2006). Web Center For Social Resarch Methods. Hämtat från Experimental Design: http://www.socialresearchmethods.net/kb/desexper.htm den 16 06 2009