Så er jeg her igen, og denne gang skal vi snakke bits og bytes, eller mere specifikt Mbits og TCP protokollen. Forhåbentlig noget som kan finde praktisk anvendelse hos jer.
Lad os starte med nogle kedelige definitioner,
TCP Transmission Control Protocol, en del af IP/TCP - eller TCP/IP som vi typisk kalder den vifte af protokoller som vi kalder IP, Internet Protocol suite.
Stevens, henviser til Richard W. Stevens forfatter og skribent om TCP/IP i detaljer
TCP bruges som transport protokol for mange af vores applikationsprotokoller, heriblandt
SMTP - email protokollen som tidligere var den protokol som sendte fleste bits
HTTP - hele web revolutionen og .com byggede på TCP forbindelser
DNS Domain Name System navneservice ville ikke virke uden TCP, idet de fleste slave servere i DNS får deres data fra master via en TCP forbindelse. Derudover er der mange DNS records og svar som gør at man idag skal tillade DNS over TCP, husk det lige!
TCP er således et af vores vigtigste værktøjer, og formentlig et af dem som I skænker færrest tanker i dagligdagen.
Hvis du arbejder med netværk til daglig og ikke kender Stevens så bør du straks tage et smut forbi
http://www.kohala.com/start/ som er hans hjemmeside - han er desværre død 1. september 1999. Jeg bruger jævnligt hans bøger når jeg har spørgsmål angående IP protokollerne, og ofte er svaret der.
Godt, TCP er beskrevet mange steder eksempelvis har Wikipedia ca. 19 sider om denne protokol hvis jeg trykker æble-p for at printe den:
http://en.wikipedia.org/wiki/Transmission_Control_Protocol og endnu en side omkring tuning af denne http://en.wikipedia.org/wiki/TCP_tuning (som igen har reference til en hel side om Bandwidth-delay product)
Netop tuning er årsagen til dette indlæg, og lad os for eksemplets skyld antage at vi har en gazillion bytes på noget super duper high performance disksystem i København. Disse mange bytes skal flyttes (af en eller anden årsag) ned til midt i Europa, lad os sige Luxembourg og det skal gå nogenlunde hurtigt - uden at det er specificeret hvor hurtigt.
Lyder det bekendt? Det er min dagligdag, lidt løse krav, bare det ikke går for langsomt!
Godt hvis vi så antager at vi har en server til rådighed i København og en server nede i Luxembourg. Begge disse servere har 1Gbit netværkskort og har adgang til disksystemerne i begge ender. Hvordan får vi overført data hurtigst muligt mellem dem?
Nogle vil måske bare starte en overførsel og se hvordan det går, det kan jeg fortælle at mine kunder også gør :-)
- det går ikke altid godt. Nogle gange bruges Microsoft windows med CIFS/SMB.
Godt, så er næste skridt at teste forbindelsen, det er altid netværkets skyld, eller firewallen - som også er netværkets - skyld.
Til test foretrækker jeg at starte med iperf, http://en.wikipedia.org/wiki/Iperf
Dette program er nemt at bruge, kendt af de fleste der arbejder med netværk og mere simpelt end diverse Bandwidth test som bygger på flash og giver billeder som output.
iperf on LAN links
Lad os prøve det på server patchman som er en CentOS release 5.7 og client solido01.ring.nlnog.net som er en Ubuntu 10.10
og fra clienten, som er en Ubuntu 10.10:
Det ser jo godt ud, solido01 som er en virtuel maskine på ESXi med 1Gbit ud får god hastighed 932 Mbits/sec.
Tip til iperf:
* kør altid mindst tre gange
* kør gerne iperf fra flere systemer, med forskellige operativsystemer
* kør mindst med 30-60 sekunder, -t 60 tilføjes til kommandolinien
og et lille check af latency
Alt er godt i vores tilfælde og vi kan konkludere at Linux systemerne fungerer efter hensigten.
Tester vi med en anden server får vi følgende resultat:
Note: her tester jeg over 30 sekunder, bedre fordi det giver TCP mulighed for at justere, læs: TCP slow start http://en.wikipedia.org/wiki/Slow-start
Jeg bruger også -i 5 som under testen giver lidt feedback. Se også at iperf straks angiver IP adresserne der sendes imellem - vital information for debugging.
Dejligt en FreeBSD performer også ret godt og vi får ens resultater - i iperf test i København, med lille latency. Denne freeperf er på samme virtuelle miljø som solido01.ring.nlnog.net serveren - samme netkort, næsten samme "hardware konfiguration".
CPH-LUX latency
Tester vi så mod en server lidt længere væk, får vi følgende resultater fra FreeBSD CPH - Linux Lux
Resultatet er voldsomt ringere end vores tidligere test fra samme maskine. Forskellen er at der er større afstand mellem enhederne, og dermed er latency væsentligt højere. Pudsigt nok giver mine Linux servere næsten samme hastighed på samme afstand (ikke gengivet her for at spare plads).
Dette resultat er forøvrigt ikke nyt, og skyldes blandt andet TCP window size, som er en funktion der tillader flere data at være undervejs, sendt men ikke modtaget acknowledgement. Denne funktion gør det specielt over større afstande muligt at sende en masse data og så når der modtages acknowledge flyttes vinduet henover data der skal sendes. Bemærk at der tales om både send window og receive window - som for optimal hastighed skal matche hinanden.
Hvad ER latency mellem CPH og LUX:
Der findes ligeledes også mange steder på internet hvor man kan indtaste data og få udregnet hvor meget data der burde kunne sendes over TCP. Disse kaldes generelt for "tcp bandwidth calculator" og dette giver mange søgeresultater.
Calculate Bandwidth-delay Product and TCP buffer size
BDP ( Bits of data in transit between hosts) = bottleneck link capacity (BW) * RTT
throughput <= TCP buffer size / RTT
TCP window size >= BW * RTT
Gengivet fra http://www.switch.ch/network/tools/tcp_throughput/index.html som efter min mening er en af de bedre
Et eksempel med 1000Mbit/sec - hastigheden vi ønsker, med latency på ca. 25ms som målt med ping, kan der udregnes med en standard TCP window 64 size:
Bandwidth-delay Product and buffer size
BDP (1000 Mbit/sec, 25.0 ms) = 3.12 MByte
required tcp buffer to reach 1000 Mbps with RTT of 25.0 ms >= 3200.0 KByte
maximum throughput with a TCP window of 64 KByte and RTT of 25.0 ms <= 20.00 Mbit/sec.
Hov, det er da ikke så godt. Vores window size er for lille og vores netværk udnyttes således ikke helt!
Tunet FreeBSD
Jeg vidste jo det med TCP window size og har da tidligere tunet diverse operativsystemer, blandt andet de Linux systemer som vi normalt bruger - som giver fuld båndbredde på 1Gbit mellem CPH og LUX.
Først uden tuning:
til at tune FreeBSD brugte jeg et lille hjælpescript, således at jeg kunne gentage test med kendte parametre:
Lad os prøve at tune lidt på memory til netværkslagene - angive flere Kb til sendspace på clienten (sendspace), som så igen kræver mere memory generelt til netværk (maxsockbuf) :
Meget bedre! Men er det nu KUN de parametre der gjorde så stor forskel? Det virker jo voldsomt at den pludselig fra den samme server kan få fuld throughput i test!
Verifikation af parametre ved at sætte dem tilbage til det oprindelige:
aha, en FreeBSD i København der sender til en Linux i Luxembourg skal altså tunes for at opnå gode resultater. Mit valg af parametre resulterede i større TCP window size - bemærk her at jeg IKKE angav TCP window size til iperf, som er en parameter -w. Det var således tuning som vil komme andre applikationer til glæde på samme server!
Den store forskel var TCP window size: 4.00 MByte som gav en voldsom forskel. Der var dog også nogle åbne spørgsmål:
Var det nok tuning - jeg prøvede med en Window size på 8.00 MByte og det gav sådan set ikke bedre resultat - surprise, testen viste 934Mbits/sec fra CPH-LUX :-)
Hvad er de optimale værdier - regneeksemplet sagde 3200.0 KByte for at nå 1000Mbps med en latency på 25ms, hvor stor margen giver det, hvis routingen ændrer sig til 30ms! TCP calculator ovenfor siger "required tcp buffer to reach 1000 Mbps with RTT of 30.0 ms >= 3840.0 KByte"
Hvilke andre tuningsparametre spiller ind, hvad er kernen bygget med, er FreeBSD bare dårlig fra starten, hvad med FreeBSD i begge ender?
Hvorfor kunne Linux med en TCP window size 285K nå fuld båndbredde, test ikke gengivet her - mens FreeBSD skulle tunes VOLDSOMT på disse parametre - hint: der findes mange måder at være mere aggressiv, men hvad der lige gav den store forskel var ikke tydeligt.
Der er altså nok at tage fat i og et helt andet problem med at overfør store datamængder er at starte og stoppe kopieringen, hvor programmer som rsync ofte kan være nødvendige - men kan bruge voldsomme mængder memory hvis der er mange små filer.
Mit afsluttende råd er således, check dine forbindelser og brug iperf. Prøv dig frem med tuning og find det som virker for dig i din brugssituation - og husk at generelt er vores operativsystemer ret konservative og allokerer alt for lidt memory til netværk, selvom vi har gigabytes af memory i vores servere (48Gb er ikke unormalt i vores servere!).
Start værdier for Linux tuning kan kopieres direkte til /etc/sysctl.conf (på en testserver):
Hvis de skrives ind i /etc/sysctl.conf sættes de ved boot, hvis man vil eksperimentere kan man bruge kommandoen sysctl -w direkte, som:
Start værdier for FreeBSD tuning:
Testet på FreeBSD 8.2 YMMV og du bør selv udføre test til dine applikationer.
Husk også at mange protokoller ovenpå TCP vil have indflydelse på overførselshastigheden, samt I/O på diske osv.
Tak til #bsd-dk på EFNet IRC netværket for input.
...men det er dyrt at lave god journalistik. Derfor beder vi dig overveje at tegne abonnement på Version2.
Digitaliseringen buldrer derudaf, og it-folkene tegner fremtidens Danmark. Derfor er det vigtigere end nogensinde med et kvalificeret bud på, hvordan it bedst kan være med til at udvikle det danske samfund og erhvervsliv.
Og der har aldrig været mere akut brug for en kritisk vagthund, der råber op, når der tages forkerte it-beslutninger.
Den rolle har Version2 indtaget siden 2006 - og det bliver vi ved med.
