Bepalen van optimale high-end en schaalbare webserver architectuur

Faculteit Ingenieurswetenschappen Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Bepalen van optimale high-end en schaalbare webserver architectuur door Steven VAN SCHOONACKER

Promotor:

Prof. Dr. Ir. P. DEMEESTER

Scriptiebegeleiders:

Dr. Ir. B. VERMEULEN, ING J. VAN AKEN

Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen

Academiejaar 2005–2006

Voorwoord Dankzij deze scriptie, is het mogelijk geweest om m’n theoretische kennis te toetsen aan de praktijk. De ervaring die hierbij opgedaan is, is een onmiskenbaar voordeel voor latere professionele uitdagingen.

Ik zou in de eerste plaats m’n promotor, Prof. Dr. ir. Piet Demeester, willen bedanken voor het bieden van de mogelijkheid om, met deze scriptie rond webserver achitectuur, ervaring op te doen in het testlab.

Een speciaal woord van dank gaat naar Brecht Vermeulen, die altijd klaar stond en de tijd nam om m’n vragen en problemen op te lossen. Verder wil ik zeker m’n andere scriptiebegeleider Jeroen Van Aken bedanken voor de tips en goeie raad.

Vervolgens wil ik ook m’n vrienden niet vergeten. Het Scouts Boekhoute webteam wil ik danken voor het ter beschikking stellen van de www.scoutsboekhoute.be website.

Een laatste woord van dank gaat naar m’n ouders, die me de mogelijkheid gegeven hebben na m’n studies industrieel ingenieur, verder te doen in de opleiding burgerlijk ingenieur in de computerwetenschappen.

Steven Van Schoonacker, mei 2006

Toelating tot bruikleen “De auteur geeft de toelating deze scriptie voor consultatie beschikbaar te stellen en delen van de scriptie te kopiëren voor persoonlijk gebruik. Elk ander gebruik valt onder de beperkingen van het auteursrecht, in het bijzonder met betrekking tot de verplichting de bron uitdrukkelijk te vermelden bij het aanhalen van resultaten uit deze scriptie.”

Steven Van Schoonacker, mei 2006

Bepalen van optimale high-end en schaalbare webserver architectuur door Steven VAN SCHOONACKER Scriptie ingediend tot het behalen van de academische graad van burgerlijk ingenieur in de computerwetenschappen Academiejaar 2005–2006 Promotor: Prof. Dr. Ir. P. DEMEESTER Scriptiebegeleiders: Dr. Ir. B. VERMEULEN, ING J. VAN AKEN Faculteit Toegepaste Wetenschappen Universiteit Gent Vakgroep Informatietechnologie Voorzitter: Prof. Dr. Ir. P. LAGASSE

Samenvatting Web surfers verwachten de dag van vandaag dat een webpagina snel binnenkomt. In sommige gevallen is dat geen sinecure. De combinatie van een zware dynamische webpagina met hoge bezoekersaantallen kunnen dodelijk zijn voor een webserver. In deze scriptie worden enkele high-end webserver architecturen voorgesteld. Er wordt geprobeerd om vast te stellen welke opstelling, in welke situatie, de beste keuze is. In een eerste deel wordt een algemene architectuur voorgesteld en enkele load balancing architecturen. Vervolgens worden alle componenten in detail besproken en gemeten. De bridged stateless firewall en NAT stateful firewall worden voorgesteld en gemeten met de smartbits en avalanche. In navolging van de thesis van Lien Deboosere worden nog enkele webservers getest op verschillende besturingssystemen en platformen. Ook het verschil in 32 en 64 bit wordt nagetrokken. Hieropvolgend worden enkele load balancers besproken en gemeten, zowel layer 4 als layer 7 load balancers. Hierbij maken we ook een vergelijking tussen een enkele webserver en een webcluster. Tenslotte worden er algemene besluiten getrokken, en worden voorstellen gedaan naar highend webclusters.

Trefwoorden load balancing, webserver, firewall, avalanche

Determining an optimal high-end and scalable webserver architecture Steven Van Schoonacker Supervisor(s): Piet Demeester, Brecht Vermeulen, Jeroen Van Aken Abstract— Web pages are a great part of the internet today. There are really some fancy sites out there. But what most creators forget, is that a webserver has its limits, especially when the load becomes high. Server side scripting, databases, etc can be really stressful for a webserver. In this paper I will compare and measure some architectures that pose a solution for this problem. Keywords—load balancing, webserver, firewall, avalanche

Pakketsize 1512 512 76

ackets/s 294332 357907 399182

Bandwidth 3.62 Gbps 1.52 Gbps 306 Mbps

TABLE I R ESULTS BRIDGED STATELESS FIREWALL

I. I NTRODUCTION

I

N the following chapters, I will start by explaining and comparing some load balancing architectures. Then these architectures will be split in components and each part will be measured. So we can easily determine bottlenecks in the system and propose solutions if necessary. II. A RCHITECTURE Firstly, a common architecture exists of a firewall, load balancer, one or more webserver and possibly a database server. We have to make a difference between layer 4 and layer 7 load balancing. In layer 7, connections with a webcluster are made with the load balancer, and packets are examined till the application layer (http). In layer 4, connections are made with one of the webservers and packets are forwarded to that server. I’ve tested 2 architectures, a NAT configuration and a direct routing configuration. The load balancer in a NAT configuration sees the round-trip traffic to the webservers. I’ve tested a layer 7, Zeus zxtm load balancer and a layer 4, Linux Virtual Server/NAT, load balancer. A direct routing load balancer sees only the traffic that goes to the webservers, not the return traffic. In this case I’ve measured the linux virtual server direct routing load balancer. III. F IREWALL I’ve taken the NAT stateful and bridging stateless firewalls as test cases. A stateful firewall keeps all the connection in a table and makes decisions based upon this table and the rules. A stateless firewall on the other hand is just a packet filter. It simply allows or denies packets based on simple rules. The bridged stateless firewall is tested with the spirent smartbits 6000. The rules were: iptables -P FORWARD DROP iptables -A FORWARD -j ACCEPT -s 10.0.0.1 --sport 80 iptables -A FORWARD -j ACCEPT -d 10.0.0.1 --dport 80 S. Van Schoonacker is with the Information Technology Department (INTEC), Ghent University (UGent), Gent, Belgium. E-mail: [email protected] .

iptables -A FORWARD -j ACCEPT -s 10.0.2.1 --sport 80 iptables -A FORWARD -j ACCEPT -d 10.0.2.1 --dport 80 The hardware consist of a Dual Opteron 280 (4 cores), 2 GB ram, quad intel pci-x nic. Results are in table I. With a packetsize of 1512 bytes, the quad nic or the test machine becomes saturated. That’s why there are less packets/s then with a packetsize of 512 and 72 bytes. We can see a bit less packets/s with greater packets, but if bandwidth is no issue, one can say it’s more or less the same. The stateful is tested at the same hardware with a small static “Hello World” page. This allows us to determine the maximum number of connections. The rules were: iptables -P FORWARD DROP iptables -A FORWARD -j DROP -p tcp ! --syn -m state --state new -d 10.0.0.1 --dport 80 iptables -A FORWARD -j ACCEPT -p tcp --dport 80 -m state --state new,established -d 10.0.0.1 iptables -A FORWARD -j ACCEPT -p tcp --sport 80 -m state --state established -s 10.0.0.1 The maximum number of connections could not be determined, because the 2 avalanches were the bottleneck at a connection rate of 55000 connections/s. If one scale linearly with the cpu load, one could obtain around 60000 connections/s. That’s around 376173 packet/s. If we compare that with the 72 bytes value (hello world connections consist of small packets), we can see that nat stateful is slower then bridged stateless as expected, but it doesn’t differ that much. IV. W EBSERVER There are 2 sites I’ve used, namely a static one, the CNN site and a heavy dynamical one, the scouts site. These 2 are good extremes, most sites will fall in between, concerning bandwidth and processing power.

Webserver Apache 2.0 Tux Zeus

Max successful users/s 161 322 320 TABLE II C OMPARISON CNN

Webserver Apache 2.0 Zeus

Bandwidth 360 Mbps 705 Mbps 691 Mbps

WEBSITE

Max successful/s 9 12

Bandwidth 15.95 Mbps 21.13 Mbps

TABLE III C OMPARISON SCOUTS WEBSITE

I’ve compared 3 webservers: Apache 2.0 worker mode, Tux and Zeus. The hardware consist of an Amd 2800+, Nforce 4, 512 MB Ram and a pci Intel pro 1000/MT network card. For the scouts site, the database was on an another server that was not the bottleneck during the test. The results are in table II and table III. One can see that Tux and Zeus are really fast in static pages. Tux is bottlenecked by the pci bus, so the difference between Tux and Zeus would be greater in a system with pci-x or pci express. Tux isn’t listed in the dynamic results because the php module is still in alpha phase. Zeus is faster in dynamic pages, but that’s mainly because the static content is served faster. They were both using php 4.4. V.

LOAD BALANCER

The load balancer is a machine with an amd 3500+, nforce 4, 2 GB RAM and a pci intel 1000/MT network card. The webservers are nearly the same as in the webserver chapter, only the motherboard has a via chipset. These motherboards have a slower pci link, with an maximum of 510 Mbps in stead of the 705 Mbps on the nforce 4 chipset with the CNN site and Tux webserver. One can see in table IV that LVS/DR is the best option for a static webpage. The scaling is almost 5 times the performance of a single webserver, so that’s nearly perfect. The webservers were the bottleneck, but the load balancer wasn’t far away from 100% cpu load. LVS/NAT had the problem of the pci bus (I couldn’t obtain pci express network cards) and the layer 7 load balancer, Zeus, was really cpu intensive. To compare the different alghorithms, I used 4 webservers with the scouts website, so the load balancer can’t be the bottleneck. If we take a look at figure 1, we see that round robin, least connections and random perform really well. That’s mainly because Webservers Apache(3x) Apache(3x) Tux (5x)

Load Balancer Zeus ZXTM LVS/NAT LVS/DR

Max users/s 126 167 1157

TABLE IV M AXIMUM CNN WEBSITE

Bandwidth 281Mbps 371Mbps 2531Mbps

Fig. 1. Comparison Zeus load balancing algorithms

the webservers are equal, if they aren’t equal then one should use weighted round robin or weighted least connections. That’s also the reason why random performs well. The useful LVS algorithms for the webcluster (round robin, least connections, source hashing and shortest expected delay) show more or less the same performance in the same test. VI. C ONCLUSIONS When high bandwidth is needed, LVS with direct routing is the way to go. It is better to use it with a stateful firewall, because the load balancer sees only half of a tcp connection, namely the packets the client sends, so it isn’t too difficult to mess things up. If one wants high bandwidth with a LVS/NAT load balancer, one has to use a pretty fast machine or DNS load balancing. The same holds true for the Zeus zxtm load balancer, but one can also cluster the front-end without dns load balancing. ACKNOWLEDGMENTS The author would like to acknowledge the suggestions of many people. R EFERENCES [1] Lien Deboosere, Experimentele karakterisatie van webservers, Information Technology Department (INTEC), Ghent University (UGent),2005. [2] D. Gaudet, ”Apache Performance Notes - Apache HTTP server”, http://httpd.apache.org/docs/misc/perf-tuning. html [3] Zeus load balancer and webserver, http://www.zeus.com [4] Apache webserver, http://www.apache.org [5] Linux Virtual Server, http://www.linuxvirtualserver.org [6] Redhat.com - Red Hat Content Accelerator (TUX) reference manuals, http://www.redhat.com/docs/manuals/tux/

INHOUDSOPGAVE

i

Inhoudsopgave 1 Inleiding

1

1.1

Doelstellingen en methodologie . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

1.2

Inhoud . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

1

2 Architectuur 2.1

2.2

3

Layer 4 load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.1.1

NAT load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.1.2

Direct routing en tunneling load balancing . . . . . . . . . . . . . . . . . .

4


5

3 Firewall

7

3.1

Inleiding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.2

Stateless firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

7

3.3

Stateful firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

8

3.4

Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.4.1

Bridged firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

9

3.4.2

NAT firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

11

Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.5.1

bridged stateless firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.5.2

NAT stateful firewall . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.5

4 Webservers 4.1

18

Apache 2.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

4.1.1

Php 4.4.0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

19

4.2

Tux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

4.3

Zeus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

20

INHOUDSOPGAVE

4.4

4.5

ii

Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.4.1

Testsites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.4.2

Testmetrieken . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

Resultaten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.5.1

Vergelijking Apache 2.0, Tux en Zeus

. . . . . . . . . . . . . . . . . . . .

27

4.5.2

Vergelijking platformen . . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.5.3

Vergelijking besturingssystemen, 32 en 64 bit . . . . . . . . . . . . . . . .

31

4.5.4

Vergelijking kernels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

32

5 Load Balancer 5.1

5.2

5.3

39

Zeus ZXTM load balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

39

5.1.1

Ondersteunde load-balancing algoritmes . . . . . . . . . . . . . . . . . . .

39

5.1.2

Testopstelling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

40

5.1.3

Resultaten

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

42

Linux Virtual Server . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44

5.2.1

Ondersteunde load-balancing algoritmes . . . . . . . . . . . . . . . . . . .

44

5.2.2

NAT Load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

47

5.2.3

Direct Routing load balancing

. . . . . . . . . . . . . . . . . . . . . . . .

48

Verticaal versus horizontaal schalen . . . . . . . . . . . . . . . . . . . . . . . . . .

52

6 Conclusie

56

A Apache 2.0: httpd.conf

58

B Mysql: my.cnf

64

INLEIDING

1

Hoofdstuk 1

Inleiding 1.1

Doelstellingen en methodologie

Dat het webverkeer binnen het internet één van de belangrijkste schakels is, zal niemand ontkennen. Daarbij worden vaak mooie maar zware sites opgezet. Server side scripting, database, kunnen vaak zeer belastend zijn voor een webserver. Dat is iets dat vaak uit het oog verloren wordt. Hoeveel mensen zijn er niet die al de dupe geweest zijn dat men bij het bestellen van kaarten voor een populair concert, de bestelpagina’s niet bereikbaar zijn, en als ze dat wel zijn de kaarten al de deur uit zijn?

Om zulke zaken te vermijden zoeken we een schaalbaar high-end systeem dat bij hoge bezoekersaantallen aangepast kan worden om te voldoen aan de eisen. Hierbij ga ik eerst van een algemene architectuur uit en ga dan elke component onderzoeken. Elke component wordt uitgemeten om dan zo de bottleneck te determineren en eventuele oplossingen voor te stellen. Bij de metingen wordt gebruik gemaakt van de Spirent Avalanche en de Smartbits 6000.

1.2

Inhoud

Hoofdstuk 2 handelt over de algemene architectuur. Er wordt een beeld geschetst van hoe een schaalbare webserver architectuur er kan uit zien. De verschillende architecturen worden vergeleken. De Firewall komt in hoofdstuk 3 aan bod. Enkele firewalls worden naast elkaar gelegd, besproken en gemeten. Als aanvulling op een thesis van vorig jaar, ga ik nog enkele webservers bespreken en meten in hoofdstuk 4. Hierbij wordt ook naar het verschil gekeken op bepaalde platformen en besturingssystemen. Het volgend hoofdstuk behandelt de verschillende

1.2 Inhoud

2

load balancers. Uiteindelijk leg ik in het laatste hoofdstuk uit welke oplossing in welke situatie het best voor de dag komt.

ARCHITECTUUR

3

Hoofdstuk 2

Architectuur De algemene high-end webserver architectuur die ik in deze scriptie hanteer, is terug te vinden in figuur 2.1. De firewall inspecteert pakketten en laat enkel geldige door. De load balancer verdeelt de aanvragen naar de verschillende webservers. Deze kunnen dan eventueel een aanvraag doen naar een databaseserver, waarna de webserver het antwoord terugstuurt naar de client.

Figuur 2.1: Algemene architectuur

2.1

Layer 4 load balancing

Bij layer 4 load balancing, gaat men de pakketten wijzigen tot op layer 4. Dit wil zeggen dat men aanvragen op poort 80 gaat verdelen onder de verschillende servers die eventueel op een andere poort draaien. Men maakt een tcp connectie met een webserver, niet met de load balancer. De

2.1 Layer 4 load balancing

4

load balancer kan aanzien worden als een politieagent die het verkeer de juiste richting instuurt. Dit kan gebeuren door verschillende algoritmes, die verder in hoofdstuk 5 besproken worden.

2.1.1

NAT load balancing

Bij NAT load balancing wordt bij een aanvraag het bestemmingsadres gewijzigd naar één van de webservers. Wanneer het antwoord terug bij de load balancer komt, wordt het bronadres gewijzigd vooraleer het terug naar de client gaat.

Figuur 2.2: NAT load balancing

2.1.2

Direct routing en tunneling load balancing

Bij deze is de terugweg niet dezelfde als de weg van de aanvraag. Het antwoord van de webserver passeert niet meer voorbij de load balancer. Hier worden geen ip adressen gewijzigd. Bij direct routing wordt het mac adres gewijzigd, bij tunneling wordt het pakket geëncapsuleerd in een


5

nieuw pakket alvorens het naar de webservers gestuurd wordt.

Figuur 2.3: Direct Routing load balancing

2.2

Layer 7 load balancing

Als men een aanvraag doet op een layer 7 load balancer, dan maakt de client effectief een tcp connectie met de load balancer, die dan op zijn beurt een connectie maakt met de webserver. Het voordeel hiervan is, dat men kan analyseren tot op het http protocol. Zo kan men de hoofdpagina van een andere server halen dan de figuren, of de statische content door 1 server laten behandelen en de dynamische door meerdere servers. Het nadeel hiervan is dat de performantie een stuk lager is. In deze scriptie heb ik één layer 7 load balancer getest, namelijk de zeus zxtm load balancer. Dit is een commercieel product en wordt ondermeer gebruikt bij ebay, qualcomm en telefonica, om maar enkele bedrijven te noemen.


6

Figuur 2.4: Layer 7 load balancing

FIREWALL

7

Hoofdstuk 3

Firewall 3.1

Inleiding

Firewalls kunnen in twee grote groepen verdeeld worden, de proxy servers en de pakket filters. Het gebruik van proxy servers is in deze architectuur niet echt gebruikelijk, omdat een proxy server vooral het uitgaand verkeer van gebruikers binnen een lan controleert. Performantie degradeert ook als men de pakketten tot laag 7 in het OSI-model inspecteert. Pakket filtering is hier aangewezen. Deze gaat tot laag 4. We kunnen hierbij onderscheid maken tussen stateless en stateful firewalls. Stateless firewalls filteren pakketten zonder kennis van connecties, stateful firewalls houden in hun geheugen alle connecties bij.

3.2

Stateless firewall

Stateless firewalls zijn minder veilig doordat ze gewoon op pakketten filteren. Om een voorbeeld te geven, stel dat men een bedrijfsnetwerk wil beveiligen en alleen uitgaande connecties toelaten. De firewall herkent inkomende connecties door de SYN vlag en blokkeert deze. Netwerkscanners zoals nmap leiden de stateless firewall om de tuin, door bijvoorbeeld geen enkele vlag aan te zetten (null scan) of door een andere combinatie van de tcp vlaggen (URG, ACK, PSH, RST, SYN en FIN). Het eindstation reageert hierop door één of ander error bericht. Een groot voordeel is dat stateless firewalls sneller zijn en weinig geheugen vragen. Het heeft geen zin om deze in combinatie te zetten met NAT, want NAT bouwt dezelfde tabel met connecties op als de stateful firewall. Dan kan men ze zowel gebruiken voor stateful filtering. Bridging is hier aangewezen.

3.3 Stateful firewall

3.3

8

Stateful firewall

Stateful firewalls bieden betere beveiliging door in het geheugen verschillende attributen van alle connecties bij te houden. De tabel vinden we in linux terug in /proc/net/ip conntrack. Een voorbeeld van een rij staat hieronder:

tcp

6

431999

ESTABLISHED

src=192.168.1.31

dst=10.10.3.157

sport=2329

dport=22

packets=536

bytes=48015

src=10.10.3.157

dst=192.168.1.31

sport=22

dport=2329

packets=683

bytes=117610

[ASSURED]

mark=0

use=1 Eerst en vooral vinden we het protocol terug. Het protocolnummer is hier decimaal gespecifieerd. Daarna hebben we de timeout. Vervolgens hebben we de toestand. Er zijn meer toestanden in ip conntrack dan in iptables. Alle tcp toestanden in ip conntrack kunt u terugvinden in de kernel source, in de file ./include/linux/netfilter ipv4/ip conntrack tcp.h. [ASSURED] wil zeggen dat er verkeer teruggekeerd is, [UNREPLIED] is de andere mogelijkheid. [ASSURED] connecties worden niet gewist als de tabel vol zit. Hoeveel connecties er in de tabel kunnen hangt af van het geheugen en van de instellingen. De tabel is ge¨ımplementeerd met verschillende rijen die elk een gelinkte lijst bevatten. De lijsten worden opgezocht binnen een hash tabel. We kunnen met 2 parameters werken, namelijk de grootte van de hash tabel en het totaal aantal connecties. Het totale geheugengebruik kan in de volgende formule gegoten worden :

CONNTRACK MAX * sizeof(struct ip conntrack) + HASHSIZE * sizeof(struct list head)

waarbij CONNTRACK MAX het maximaal aantal connecties is, sizeof(struct ip conntrack) de grootte van zo een element in de lijst, HASHSIZE de grootte van de hash tabel en sizeof(struct list head) 2 maal de grootte van een pointer is. De grootte van een element is afhankelijk van de kernelversie en de gecompileerde opties. We kunnen deze terug vinden in de kernel log messages (bv dmesg). Deze bedraagt in mijn geval met de 2.6.16 kernel 312 bytes. De grootte van een pointer is op de x86 64 architectuur 8 bytes (4 bytes bij een i386 architectuur). Om nu maximale performantie te krijgen, willen we een grote hash tabel, bijvoorbeeld even groot als het aantal connecties. Als we nu bijvoorbeeld 1900 MB reserveren bij onze 2 GB machine voor die tabel, dan vinden we met bovenstaande formule iets meer dan 6 miljoen connecties. De grootte van de hash tabel moet een macht van 2 zijn en kan aangepast worden als parameter (bv

3.4 Testopstelling

9

ip conntrack.hashsize=4194304) wanneer de kernel of module geladen wordt. Het aantal connecties kan onmiddellijk aangepast worden in /proc/sys/net/ipv4/netfilter/ip conntrack max. Binnen iptables zijn 4 toestanden mogelijk, namelijk NEW, ESTABLISHED, RELATED en INVALID. De NEW toestand komt er wanneer een pakket passeert (hoeft daarom niet een SYN pakket te zijn!). Wanneer er een antwoord komt, dan gaat de toestand over naar ESTABLISHED. Iptables volgt dus niet het 3 wegs tcp handshakingprotocol. RELATED wil zeggen dat een connectie gerelateerd is aan een al bestaande connectie. Een voorbeeld hiervan is de ftp data poort (20) die gerelateerd is aan de controle poort (21). INVALID tenslotte is een pakket dat niet geldig is of niet aan een toestand kan toegeschreven worden.

3.4

Testopstelling

Ik heb 2 mogelijke configuraties onderzocht, namelijk een bridged stateless firewall en een NAT stateful firewall. In het eerste geval wordt er met 1 segment gewerkt en wijzig je de ip-header niet, in het tweede geval wordt het bron of bestemmings ip-adres gewijzigd. Het voordeel is dat een bridged firewall enkel pakketten moet onderzoeken, een NAT firewall moet zo ook nog eens wijzigen en vereist dus meer processing capaciteiten. Ook kan een bridged firewall zonder ip-adres werken en is dus bijgevolg veiliger. De NAT firewall onder linux heeft als voordeel dat het met link aggegration (IEEE 802.3ad) overweg kan, daar waar de bridging en link aggregation in linux problemen gaven. Er ontstonden oneindige loops, waardoor de links op korte tijd uitgeschakeld werden. Een oplossing voor dit probleem is niet tussen een linux machine en switch link aggegration te gebruiken, maar tussen 2 switchen en per lijn aparte bridges gebruiken. Deze oplossing is voorgesteld in figuur 3.1. Met deze oplossing zou men ook load balancing tussen firewalls kunnen doen, maar dan is stateful niet mogelijk omdat pakketten behorende tot een tcp connectie langs dezelfde weg (en dus dezelfde firewall) terug moeten, iets wat bij layer 2 load balancing niet gegarandeerd is.

3.4.1

Bridged firewall

Een bridged firewall zet men in linux als volgt op: men bouwt een kernel met ondersteuning voor 802.1d Ethernet Bridging (in het menu networking options). Ook zet men de gepaste opties aan voor de firewall in het menu iptables. Vervolgens installeert men de pakketten bridge-utils en iptables. Met de volgende commando’s zet men de bridge op:

3.4 Testopstelling

10

Figuur 3.1: Oplossing aggregation en bridging firewall

brctl addbr br0 brctl addif br0 eth0(interface toevoegen aan de bridge) brctl addif br0 eth1 brctl addif br0 eth2 brctl addif br0 eth3 brctl stp br0 off (spanning tree protocol uitschakelen) ifconfig eth0 0.0.0.0 up ifconfig eth1 0.0.0.0 up ifconfig br0 0.0.0.0 up

Zoals je kan zien hoeft men geen ip-adres te geven aan de bridge, maar het kan wel.

Bridged stateless firewall Ik heb deze firewall met de Smartbits 6000 getest. Deze genereert pakketten zonder rekening te houden met connecties. Er werden 4 stromen ingesteld. Een overzicht van de stromen vindt u in figuur 3.2. Er is bovendien ook nog getest bij verschillende pakketgroottes. De regels in de firewall waren als volgt:

iptables -P FORWARD DROP

3.4 Testopstelling

11

iptables -A FORWARD -j ACCEPT -s 10.0.0.1 --sport 80 iptables -A FORWARD -j ACCEPT -d 10.0.0.1 --dport 80 iptables -A FORWARD -j ACCEPT -s 10.0.2.1 --sport 80 iptables -A FORWARD -j ACCEPT -d 10.0.2.1 --dport 80

Figuur 3.2: De smartbits en stromen binnen de firewall

3.4.2

NAT firewall

Ik heb vanuit elke avalanche 2 gigabit links naar de firewall gebruikt. Zo is bandbreedte nooit een probleem. Het bestemmingsadres moet bij aanvragen veranderd worden en dit kan met 1 regel gebeuren in de tabel nat van iptables : iptables -t nat -A PREROUTING -j DNAT --to-destination 10.0.0.1 -s 192.168.0.0/16 Belangrijk is ook om ip forwarding aan te zetten, en dit kan gebeuren door een 1 te zetten in /proc/sys/net/ipv4/ip forward. Waar we ook rekening dienen met te houden, is dat de interrupt aanvragen verdeeld worden over

3.4 Testopstelling

12

de verschillende processoren. In de 2.6 kernels wordt dit ondersteund, maar het kan ook in de gebruikersruimte gebeuren door het programma irqbalance. De ondervindingen bij m’n testmachine, die terug te vinden is in tabel 3.1 waren niet positief. Door statisch elke netwerkkaart aan een processor toe te wijzen, kan men de interruptaanvragen efficiënter behandelen. De interruptaanvragen vindt men terug in /proc/interrupts. In /proc/irq/215/smp affinity vindt men de processor terug, waarbij 215 hier de irq is. Het formaat binnen dit bestand is hexadecimaal. Enkel het laatste getal is in ons geval (4 processoren) belangrijk. Op bitniveau is 0001 processor 1, 0010 processor 2, 0100 processor 3, ... Combinaties kunnen hierbij gemaakt worden. Als we irq 215 behandeld willen behandeld zien worden door processor 1 en 4, dan moet de inhoud van /proc/irq/215/smp affinity 9 zijn. Ook combinaties werkten niet op dit systeem, dit doet m’n vermoeden rijzen dat er een bug zit in ofwel de kernel, ofwel het bios. Ook de hardware site anandtech kreeg beide cores met bios 1.20 niet aan de praat onder linux1 . Ik kreeg ze enkel werkende door statisch elke interrupt aan 1 processor toe te wijzen. Zo kan men als men met link aggregation, 2 links samenvoegd, de uitgaande load verdelen over 2 processoren (aan elke processor 1 netwerkkaart) en heeft men nog eens het voordeel van dubbele bandbreedte. Om link aggregation te gebruiken onder linux, compileren we de module voor de kernel, deze vinden we terug in device drivers -> network device support -> bonding driver support. Het gemakkelijkst is om ze als module te compileren, dan kan men heel gemakkelijk parameters meegeven. De miimon parameter is de monitortijd van de link in ms. De mode is hier 4, dit komt overeen met IEEE 802.3ad Dynamic link aggregation. Met het programma ifenslave kan men interfaces toevoegen of verwijderen

modprobe bonding miimon=100 mode=4 ifconfig bond0 10.0.0.3 ifenslave bond0 eth0 eth1

In de switch moet link aggregation ook ingesteld worden. De procedure hiertoe is uiteraard afhankelijk van switch tot switch.

3.5 Resultaten

13

Figuur 3.3: Testopstelling NAT stateful firewall

NAT stateful firewall We willen dat enkel connecties naar de server 10.0.0.1 op poort 80 toegelaten worden. Ook willen we dat het eerste pakket een SYN pakket is. Dit kunnen we door de volgende regels verkrijgen : iptables -P FORWARD DROP iptables -A FORWARD -j DROP -p tcp ! --syn -m state --state new -d 10.0.0.1 --dport 80 iptables -A FORWARD -j ACCEPT -p tcp --dport 80 -m state --state new,established -d 10.0.0.1 iptables -A FORWARD -j ACCEPT -p tcp --sport 80 -m state --state established -s 10.0.0.1

3.5 3.5.1

Resultaten bridged stateless firewall

De specificaties van de testmachine helios157 zijn terug te vinden in tabel 3.1. De resultaten zijn terug te vinden in tabel 3.2. De testen zijn uitgevoerd bij pakketgroottes van 1512, 512 en 76 bytes(ethernet frames pakketgrootte). We zien bij grotere pakketten dat het aantal per seconde iets minder is dan bij kleinere pakketten, maar dit scheelt niet zoveel (ongeveer 10% 1

http://www.anandtech.com/IT/showdoc.aspx?i=2447&p=3

3.5 Resultaten

14

Processor

2x AMD Opteron 280 (2.4 GHZ)

Socket

940

L1 Cache

2x 128 KB

L2 Cache

2x 1 MB

Moederbord

Iwill DK8ES

Geheugen

2 GB registered ECC DDR-RAM

Harde schijf

80 GB IDE Maxtor 6L080P0

Netwerkkaarten

Intel PRO/1000 MT Dual Port PCI-X Adapter met NAPI ingeschakeld Intel PRO/1000 MT Quad Port PCI-X Adapter met NAPI ingeschakeld

Besturingssysteem

Gentoo linux 64 bits

Kernel

2.6.15 gepatched met TUX Tabel 3.1: helios157 Pakketgrootte

Max aantal pakketten/s

Bandbreedte

1512

294332

3.62 Gbps

512

357907

1.52 Gbps

76

399182

306 Mbps

Tabel 3.2: Resultaten van de bridged stateless firewall verschil tussen 512 en 76 bytes). Enkel bij 1512 bytes is dit niet het geval, omdat de saturatie van de links begint mee te spelen (max 1 Gbps per link per richting).

3.5.2

NAT stateful firewall

Als testsite werd een hele kleine statische site genomen (“Hello world”), zodat we het maximum aantal connecties per seconde kunnen bepalen. In de praktijk zullen de processoren van de firewall meer interrupts per connectie krijgen omdat de bandbreedte hoger ligt. De belasting die aangelegd werd samen met het resultaat, vindt men terug in figuur 3.4. Men moet hierbij rekening houden dat het aantal connecties per seconde, het aantal connecties is dat hij effectief kan opzetten. Dat wil niet zeggen dat elke connectie een succesvolle transactie tot gevolg heeft. Daarvoor moet men kijken naar het aantal transacties/s. Zoals je kan zien, volgt de firewall mooi de avalanches, tot net voor het einde. Bij hogere belasting, blijft het resultaat rond de 50000 connecties/s. Bij nadere inspectie met het programma dstat, blijkt de firewall niet de bottleneck te zijn (ongeveer 80% cpu belasting), maar de avalanches. Het tabblad resource in

3.5 Resultaten

15

de avalanche software bevestigt dit ook, in de piek wordt er een queue opgebouwd omdat de avalanches deze niet in tijd kan verwerken. Als we het resultaat lineair schalen, dan zou het uiteindelijke resultaat rond de 60000 connecties/s moeten zijn. Aangezien er in het testlabo maar 2 avalanches zjin, heb ik dit niet verder kunnen onderzoeken.

Wat ook interessant is, hoe reageert de firewall op vele regels? Bij ons is dat beperkt tot 3 regels, maar we kunnen vermoeden, aangezien de tabel serieel doorlopen wordt, dat dit bij grote tabellen wel degelijk invloed zal hebben. Om dit te testen heb ik een klein scriptje geschreven dat een 4000 tal onbelangrijke regels invoert, en de laatste 3 regels zijn onze firewall regels. Zo moet de firewall elke keer de ganse tabel doorlopen en verwachten we een serieuze degradatie in performantie. De resultaten vinden we terug in figuur 3.5.

Figuur 3.4: Resultaten NAT stateful firewall

Wat onmiddellijk opvalt, is dat de performantie een stuk lager ligt. De belasting is hier zo gekozen, dat het een heel klein beetje boven de maximale performantie van de firewall ligt. Als

3.5 Resultaten

16

Figuur 3.5: Resultaten NAT stateful firewall met 4067 regels

we de belasting opdrijven, dan zien we in figuur 3.6 dat de firewall z’n maximum totaal niet meer haalt, en serieus degradeert in performantie. Het is dus belangrijk in een webserver architectuur, dat de firewall qua performantie een stuk boven de maximum te verwachten belasting ligt.

Als we de vergelijking willen maken tussen de bridged stateless en nat stateful firewall, dan moeten we kijken naar het aantal pakketten. Bij 49731 connecties/s bedraagt dit 311791 pakketten/s. Aangezien het hier een kleine site betreft, mogen we verlijken met de waarden bij 76 bytes. Als we lineair schalen naar onze verwachte 60000 connecties/s, dan zouden we ongeveer 376173 pakketten/s hebben. Als we dit getal nu vergelijken, dan is de nat stateful firewall ongeveer 6.1% trager dan de bridged stateless. In de praktijk zal dit wel iets hoger zijn, omdat connecties bij de avalanches onmiddellijk afgesloten worden, en dus de ip conntrack tabel klein blijft.

3.5 Resultaten

Figuur 3.6: Resultaten NAT stateful firewall met 4067 regels, hoge belasting

17

WEBSERVERS

18

Hoofdstuk 4

Webservers Dit hoofdstuk is een aanvulling op de thesis van ir. Lien Deboosere1 . Het was de bedoeling om nog enkele webservers op performantie te testen en te kijken naar platform specifieke verschillen.

4.1

Apache 2.0

Ik heb apache 2.0.54 in de threaded, worker mode getest. Dit op zowel 32 bit als 64 bit platformen en de debian en gentoo linux distributies. Er werd voor zowel de 32 bit als de 64 bit dezelfde kernel opties gebruikt en dezelfde kernel werd gebruikt voor zowel gentoo als debian. Apache 2.0 werd gecompileerd op het debian platform en die executable werd ook gebruikt op het gentoo platform. Bij de resultaten dient men rekening te houden dat gentoo gecompileerd met stabiele opties (CFLAGS=“-march=k8 -pipe -O2”), maar bij gebrek aan tijd is hier niet verder op ingegaan. Bij het gebruik van een dynamische php site werd de php module geladen, deze werd niet geladen bij het testen van een statische site. Dit maakt overigens een groot verschil, bij het testen van statische sites werd soms een performantievermindering van meer dan 10% waargenomen als de php module geladen was, en dat terwijl deze niet eens gebruikt werd. Bij het testen werd de log uitgeschakeld. De volgende compile opties werden gebruikt : ./configure --with-mpm=worker --enable-access=shared --enable-auth=shared --enable-include=shared --enable-log\_config=shared --enable-env=shared --enable-setenvif=shared --enable-mime=shared --enable-status=shared --enable-autoindex=shared --enable-asis=shared --enable-cgid=shared 1

L. Deboosere, Experimentele karakterisatie van webservers

4.1 Apache 2.0

19

--enable-negotiation=shared --enable-dir=shared --enable-imap=shared --enable-actions=shared --enable-userdir=shared --enable-alias=shared --enable-expires=shared --enable-headers=shared --enable-logio=shared --enable-ssl=shared De httpd.conf configuratiefile kunt u terugvinden in bijlage A.

4.1.1

Php 4.4.0

Php werd als volgt gecompileerd : ./configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --build=i686-pc-linux-gnu --enable-experimental-zts --with-apxs2=/usr/local/apache2/bin/apxs --disable-cli --without-pear --without-db3 --without-db4 --without-db2 --without-ndbm --with-mcrypt=/usr --with-mhash=/usr --without-ming --without-sybase --without-gdbm --without-java --without-mcal --without-unixODBC --without-pgsql --without-snmp --without-gmp --without-mssql --without-crack --without-pdflib --without-gd --without-png --without-jpeg --without-tiff --with-mysql=/usr --with-mysql-sock=/var/run/mysqld/mysqld.sock --without-ttf --without-t1lib --with-gettext --without-pspell --with-openssl=/usr --without-imap --without-ldap --without-dom --without-dom-xslt --without-dom-exslt --without-kerberos --with-pam --disable-memory-limit --enable-ipv6 --without-yaz --disable-debug --with-curlwrappers --with-curl=/usr --enable-dbx --with-zlib=/usr --with-zlib-dir=/usr --with-sablot=/usr --enable-xslt --with-xslt-sablot --with-xmlrpc --enable-wddx --with-xml --enable-mbstring=all --enable-mbregex --with-bz2=/usr --with-cdb --enable-pcntl --enable-bcmath --enable-calendar --enable-dbase --enable-filepro --enable-ftp --with-mime-magic=/usr/share/misc/file/magic.mime --enable-sockets --enable-sysvsem --enable-sysvshm --enable-sysvmsg --with-iconv --enable-shmop --enable-dio --enable-yp --without-ncurses --without-readline --enable-inline-optimization --enable-track-vars --enable-trans-sid --enable-versioning --with-config-file-path=/etc/php/apache2-php4 --libdir=/lib/php --without-pear

4.2 Tux

4.2

20

Tux

Tux is een threaded webserver die uitgegeven is door Red Hat, maar ook door middel van patches op andere distributies draait. Het grote verschil met apache is dat apache compleet in de gebruikersruimte draait, daar waar tux zich grotendeels in de kernelruimte bevindt. Daardoor is het mogelijk dat de netwerkkaart directe geheugentoegang heeft, in tegenstelling tot bijvoorbeeld apache die gebruik moet maken van een netwerkbuffer, waarin de gegevens uit het geheugen gekopieerd worden. Hierdoor haalt tux enorme snelheden. Tux biedt ook ondersteuning voor dynamische pagina’s door middel van modules, maar bijvoorbeeld de php module bevindt zich nog in alfa fase, waardoor tux eerder gebruikt wordt voor statische pagina’s. Men kan tux ook laten samenwerken met apache of andere webserver, door deze laatste op een andere poort(bv. 8080) te laten draaien. Hierdoor is het toch mogelijk om php pagina’s beschikbaar te stellen. Tux stuurt de php aanvragen door naar apache, die dan op zijn beurt de antwoorden terug stuurt naar tux.

De installatie van tux bestaat uit het patchen van de kernel source files2 , de kernel compileren, en uit het installeren van de gebruikersruimte programma’s. Het patchen gebeurt met hetvolgende commando :

patch -p0 < tux3-2.6.12-A3

Dit gebeurt in de directory boven de linux kernel source. Dit voorbeeld slaat op de 2.6.12 kernel. De instellingen kunnen gewijzigd worden zonder de webserver te herstarten, dit gebeurt door de waarden in de directory /proc/sys/net/tux/ te wijzigen.

4.3

Zeus

De Zeus webserver3 is een commercieel product en kost ongeveer 2600 dollar per licentie. Ik heb de proefversie uitgetest. Deze webserver is heel gemakkelijk te installeren en de instellingen kunnen gewijzigd worden via een webinterface. Deze webserver draait net als apache compleet in de gebruikersruimte. Bij het testen is ook hier het loggen uitgeschakeld alsook het verzamelen 2 3

http://people.redhat.com/ mingo/TUX-patches http://www.zeus.com

4.3 Zeus

21

van statistieken. De webinterface samen met de instellingen vindt u terug in figuur 4.1.

Figuur 4.1: De zeus webserver admin interface

4.4 Testopstelling

4.4

22

Testopstelling

De testopstelling voor de statische site is terug te vinden in figuur 4.2, voor de dynamische site in figuur4.3. Er werd gebruik gemaakt van een teruggeklokte helios155 met single channel ram om een faire vergelijking te maken met de helios150. Elke verbinding gebeurde met de Intel PRO/1000 PCI Adapter.

Figuur 4.2: Testopstelling statische site

Figuur 4.3: Testopstelling dynamische site

4.4 Testopstelling

4.4.1

23

Testsites

CNN website De CNN website is een grote statische site, die bestaat uit 75 objecten. De avalanche wordt zo ingesteld dat eerst de html file opgevraagd wordt, en na het antwoord van de webserver worden de 74 andere objecten (foto’s, javascript,...) tegelijk opgevraagd. De site zelf is 247 KB groot. Er wordt steeds gewerkt met http/1.1. De instellingen in de avalanche zijn zo dat er per gebruiker(SimUser) maximaal 2 open connecties zijn en maximum 50 objecten per connectie. Aangezien de site uit 75 objecten bestaat, volstaat dit met 2 connecties per gebruiker.

Figuur 4.4: De CNN website

4.4 Testopstelling

24

Processor

Amd Athlon64 2800+(1800Mhz)

Socket

754

L1 Cache

128 KB

L2 Cache

512 KB

Moederbord

Asus K8VSE Deluxe(Via K8T800 chipset)

Geheugen

512 MB 400 Mhz DDR-RAM

Harde schijf

80 GB IDE Maxtor 6Y080P0

Netwerkkaarten

2x Intel PRO/1000 PCI Adapter met NAPI disabled Onboard Marvell 88E8001 GbLAN

Besturingssystemen

Gentoo linux 32 bits Gentoo linux 64 bits Debian linux 32 bits Debian linux 64 bits

Kernel

2.6.12.6 gepatched met TUX Tabel 4.1: helios150 t.e.m. helios154

Scouts Boekhoute website De scouts Boekhoute website4 is een site waarbij alles behalve de statische content(figuren, javascript, css,...) uit een mysql databank gehaald wordt. De site is geschreven in php, en de talrijke dynamische scriptjes zorgen dat dit een zeer belastende website is. Als pagina werd de beginpagina genomen. Deze bestaat uit 45 objecten. De avalanche werd op dezelfde manier ingesteld als bij de CNN website. Hoewel per gebruiker 1 connectie volstaat, opent de avalanche er toch 2. Om ervoor te zorgen dat de mysql databank niet de bottleneck wordt, stellen we voldoende geheugen in voor de databank, zodat deze volledig in het geheugen kan geladen worden. De mysql instellingen vindt u terug in bijlage B. We houden tijdens de metingen met het programma dstat processor, geheugenverbruik en bandbreedte nauwlettend in de gaten, zodat we zeker zijn dat de databank niet de bottleneck is.

4

http://www.scoutsboekhoute.be

4.4 Testopstelling

25

Figuur 4.5: De scouts Boekhoute website

4.4.2

Testmetrieken

Om een webserver te testen, moeten we een aantal testen uitvoeren. Ik heb hiervoor een viertal testen geselecteerd: Maximum over 1 http/1.1 connectie Om de maximale bandbreedte te weten van de server, halen we een grote file (53 MB) een aantal keer na mekaar af over dezelfde connectie. Maximale piekbandbreedte bij overbelasting van een bepaalde site Hiervoor gebruiken we de CNN of scouts site. Er wordt een groot aantal gebruikers ingesteld, zodat heel even een piek waargenomen wordt, waarna de server in verval komt door het teveel aan aanvragen.

4.4 Testopstelling

26

Processor


Socket

939

L1 Cache

128 KB

L2 Cache

512 KB

Moederbord

A8N-SLI Deluxe (Nvidia Nforce4 chipset)

Geheugen

1GB 400 Mhz DDR-RAM (single channel)

Harde schijf

2x sata Maxtor 6B200M0

Netwerkkaarten

2x Intel PRO/1000 PCI Adapter met NAPI disabled Onboard nForce4 built-in Gbit MAC with external Marvell PHY Onboard MARVELL PCI Gbit LAN

Besturingssystemen


Kernel

2.6.12.6 gepatched met TUX

Tabel 4.2: helios155 die teruggeklokt is en single channel ram heeft De continue load bandbreedte bij maximale belasting van een bepaalde site Hiervoor gaan we op zoek naar het punt waarbij de server net niet overbelast wordt. We gebruiken daarbij het volgende criterium: de response tijd mag niet stijgen in z’n maximaal punt. Als een server overbelast wordt, dan komen de aanvragen in een rij, en wordt de response tijd steeds hoger. Na een tijdje resulteert dit in fouten, doordat er geen geheugen meer vrij is om aanvragen op te slaan. Reactie van de server op een burst Bij deze test, neemt men het maximaal aantal gebruikers uit het vorig punt, en gaat men 10% eronder. Gedurende 10s gaat men er 10% boven om dan terug 10% eronder te gaan. Een voorbeeld hiervan kan u terugvinden in figuur 4.6.

4.5 Resultaten

27

Processor


Socket

939

L1 Cache

128 KB

L2 Cache

512 KB

Moederbord

A8N-SLI Deluxe (Nvidia Nforce4 chipset)

Geheugen

2GB 400 Mhz DDR-RAM (dual channel)

Harde schijf

2x sata Maxtor 6B200M0

Netwerkkaarten

2x Intel PRO/1000 PCI Adapter met NAPI disabled Onboard nForce4 built-in Gbit MAC with external Marvell PHY Onboard MARVELL PCI Gbit LAN

Besturingssystemen


Kernel

2.6.12.6 gepatched met TUX Tabel 4.3: helios155

4.5 4.5.1

Resultaten Vergelijking Apache 2.0, Tux en Zeus

In figuur 4.7 zien we dat Tux en Zeus heel wat sneller zijn dan Apache. Hierbij moet opgemerkt worden dat Tux en Zeus aan de limieten van de chipset oplopen, want hun processorbelasting is ongeveer 80% en 90% respectievelijk. Apache heeft een 100% processorbelasting. Tux is sneller omdat het in de kernel draait en dus dichter bij de hardware staat. Wat nog opvalt is dat de piekbelasting niet ver uit de buurt ligt van de maximale gemiddelde belasting en bij Zeus zelfs lager ligt. Dit is te verklaren door het feit dat Zeus gevoeliger reageert op overbelastingen (zie verder). Bij het transfereren van een grote file, is men op het helios155 platform beperkt door de pci bus. Als we de dynamische kant onder de loep nemen, dan zien we dat Zeus sneller is dan Apache, maar het verschil is niet zo groot als bij statische sites. Beiden maken gebruik van php 4.4 en het verschil is vooral te verklaren door het feit dat Zeus een pak sneller is in statische content, die ook nog aanwezig is in de scouts pagina. De processor is bij beiden de bottleneck.

4.5 Resultaten

28

Figuur 4.6: De burst meting

Webserver

Max aantal succesvolle gebruikers/s

Bandbreedte

Apache 2.0

161

360 Mbps

Tux

322

705 Mbps

Zeus

320

691 Mbps

Tabel 4.4: Vergelijking maximale continue load CNN website

Webserver


Bandbreedte

Apache 2.0

9

15.95 Mbps

Zeus

12

21.13 Mbps

Tabel 4.5: Vergelijking maximale continue load scouts website

4.5 Resultaten

29

Figuur 4.7: Resultaten Apache, Tux en Zeus

De burst metingen vinden we terug in figuur 4.9 tot en met figuur 4.13. We zien dat apache heel goed reageert op een burst, zowel bij de CNN site als bij de scouts site. Apache gaat sneller aanvragen laten vallen bij overbelasting, terwijl Zeus en Tux toch proberen om aanvragen op te slaan in het geheugen en deze dan later te beantwoorden. Maar de belasting blijft zo hoog (10% onder het maximum), dat dit opslaan zorgt ervoor deze belasting nooit meer gehaald wordt. Zeus reageert wel goed bij dynamische pagina’s. Dit komt omdat er slechts 1 gebruiker per seconde boven het maximum gegaan wordt(10%), en dit opslaan is niks in vergelijking met de aangelegde belasting.

4.5.2

Vergelijking platformen

Toen ik aan de metingen begon, kon ik niet verklaren waarom op het K8VSE moederbord, bij tux, de processorbelasting geen 100% was en toch de pci bus niet gesatureerd was. Na verder onderzoek heb ik besloten om de metingen te herdoen op een teruggeklokt nforce4 platform. Om vergelijkingen eerlijk te maken, heb ik de amd64 processor naar 1800 Mhz teruggebracht (Amd laat bij deze processor toe om de multiplier naar beneden in te stellen, maar niet naar

4.5 Resultaten

30

Figuur 4.8: Resultaten Apache en Zeus met de scouts site

boven). Het K8VSE platform biedt enkel ondersteuning aan single channel ram, dus ik heb een geheugenmodule uit het nforce4 platform genomen om zo single channel ram in te stellen. Het enige verschilpunt is nu dat in het nforce4 platform 1GB aan ram zit, en in de K8VSE 512 MB. Dit is geen probleem, zolang de geheugenhoeveelheid geen bottleneck is. Na controle met dstat blijkt dit inderdaad niet het geval te zijn. De geheugenhoeveelheid wordt een probleem wanneer er veel open connecties zijn. Bij Tux en 512 MB RAM zijn er dat ongeveer 80000. Maar aangezien de Avalanche direct de connecties afsluit hebben we niet veel gelijktijdige open connecties. Apache scoort zoals verwacht ongeveer gelijk, maar Tux laat merkwaardige resultaten zien. Het K8VSE platform moet hier duidelijk onderdoen. Hierbij is duidelijk dat de chipset een belangrijke rol speelt in het systeem. Ik had ook nog graag metingen gedaan met pci express netwerkkaarten, maar deze waren nog niet beschikbaar.

In het volgend hoofdstuk ga ik een vergelijking maken tussen verticaal en horizontaal schalen van systemen. Verticaal schalen betekent een of meerdere servers uitbreiden met meer geheugen, snellere processoren,... Horizontaal schalen betekent dat in een cluster een of meerdere servers

4.5 Resultaten

31

Figuur 4.9: Burst meting bij Apache met de CNN website op teruggeklokt helios155 platform

toegevoegd worden. Hierbij aansluitend vindt u in de figuren 4.15 en 4.16 zien we dat 2x opteron 280 (4 kernen aan 2.4 GHz) zoals verwacht een amd64 2800+ overklast. De specificaties voor de opteron vindt u terug in tabel 3.1. De opteron is ongeveer 3.6x sneller in de scouts site en ongeveer 3.1x sneller in de CNN site. De opteron werd bij de CNN website met 2 avalanches getest, omdat 1 avalanche een maximum heeft van ongeveer 1.3 Gbps bij de CNN site.

4.5.3

Vergelijking besturingssystemen, 32 en 64 bit

Als we gentoo en debian vergelijken, dan zien we dat gentoo iets sneller is in apache dan debian. De verschillen zijn niet groot, maar aangezien ik gentoo niet echt tot in de puntjes getweaked heb, zouden de verschillen in dat geval wel groter kunnen zijn. Tussen 32 en 64 bit is er wel een merkbaar verschil, althans in apache. In dat geval is de processor de bottleneck, bij tux is dat de chipset. Figuur 4.18 toont aan dat tux op het helios155 platform niet kan profiteren van 64 bit.

4.5 Resultaten

32

Figuur 4.10: Burst meting bij Tux met de CNN website op teruggeklokt helios155 platform

Webserver


Bandbreedte

Apache 2.0 kernel 2.6.12

160

357 Mbps

Apache 2.0 kernel 2.6.16

154

340 Mbps

Tux kernel 2.6.12

220

482 Mbps

Tux kernel 2.6.16

233

510 Mbps

Tabel 4.6: Vergelijking maximale continue load CNN website op 2 kernels op helios150

4.5.4

Vergelijking kernels

De testen tot nu toe zijn allemaal gebeurd met de 2.6.12 kernel. Ik heb op het K8VSE platform ook eens getest in gentoo64 met kernel 2.6.16. De vergelijkingen zijn terug te vinden in tabel 4.6. Wat opvalt is dat Tux sneller is en Apache trager. Maar als we kijken naar de response tijd van Apache, dan is die ongeveer 10x lager bij kernel 2.6.16 (40ms ipv 400ms) en staat daarmee op het niveau van Tux.

4.5 Resultaten

33

Figuur 4.11: Burst meting bij Zeus met de CNN website op teruggeklokt helios155 platform

4.5 Resultaten

34

Figuur 4.12: Burst meting bij Apache met de scouts website op teruggeklokt helios155 platform

4.5 Resultaten

35

Figuur 4.13: Burst meting bij Zeus met de scouts website op teruggeklokt helios155 platform

4.5 Resultaten

36

Figuur 4.14: Vergelijking tussen Via en Nforce chipset

Figuur 4.15: Vergelijking tussen Opteron 280 en Amd64 2800+ met CNN website

4.5 Resultaten

37

Figuur 4.16: Vergelijking tussen Opteron 280 en Amd64 2800+ met scouts website

Figuur 4.17: Vergelijking tussen gentoo en debian, 32 en 64 bit, in apache met CNN website

4.5 Resultaten

Figuur 4.18: Vergelijking tussen gentoo en debian, 32 en 64 bit, in tux met CNN website

38

LOAD BALANCER

39

Hoofdstuk 5

Load Balancer 5.1

Zeus ZXTM load balancer

De Zeus ZXTM load balancer is een layer 7 load balancer. De tcp connecties worden door de client opgezet met de load balancer. Dit is ge¨ıllustreerd in figuur 5.1. Deze draait net zoals de Zeus webserver in de gebruikersruimte. Ook kan men hier gebruik maken van een handige admin webinterface.

5.1.1

Ondersteunde load-balancing algoritmes

Round Robin Elke webserver wordt om beurt opgevraagd. Dit is een goed algoritme voor gelijke webservers. Voor 2 webserver A en B, wordt dit ABABABAB... Weighted Round Robin We kunnen aan elke webserver een gewicht toekennnen, zodat bijvoorbeeld een krachtigere webserver meer verzoeken krijgt. Nadeel hiervan is dat je een performantieschatting of meting moet doen. Als webserver A gewicht 2 krijgt, en webserver B gewicht 1, dan wordt het AABAABAABAAB... Perceptive Dit is een algoritme dat de belasting en antwoordtijden van de webservers onderzoekt en op basis hiervan de meest ideale webserver kiest. Zeus raadt dit algoritme aan bij hoge belastingen.

5.1 Zeus ZXTM load balancer

40

Figuur 5.1: TCP diagram bij layer 7 load balancing

Least connections De webserver met de minste connecties krijgt het volgende verzoek. Fastest response time Alle webserver worden gepinged, en op basis daarvan krijgt de webserver met de laagste delay het volgende verzoek. Random De webserver krijgen willekeurig verzoeken van de clients.

5.1.2

Testopstelling

De opstelling voor de Zeus load balancer en de Linux virtual server NAT kunt u terug vinden in de figuren 5.2 en 5.3. De eerste is voor de statische CNN site en de tweede voor de scouts


41

site. Bij de tweede werk ik met dezelfde switch voor de verbinding met de Mysql server. Er zijn 2 port based vlan’s. Eén om de webservers met de load balancer te verbinden en één om de webservers met de mysql server te verbinden. Elke verbinding in elke server gebeurt met een Intel PRO/1000 PCI Adapter. De webservers zijn Apache. Het gebruikte besturingssysteem op de webservers was gentoo64 met kernel 2.6.16, op de load balancer gentoo64 met kernel 2.6.12.

Figuur 5.2: Testopstelling Zeus en NAT load balancing met CNN site

De testinstellingen waren als volgt : • rules: inspectieregels (voor layer 7 onderzoek) werden uitgeschakeld om een zo goed mogelijke vergelijking te maken met een layer 4 load balancer. • logging: access logging werd uitgeschakeld • content caching: uitgeschakeld, zodat de verbinding met de webserver onderhouden wordt. • content compression: uitgeschakeld • load balancing: round robin, tenzij anders vermeld • session persistence: uitgeschakeld


42

Figuur 5.3: Testopstelling Zeus en NAT load balancing met scouts site

• health monitoring: uitgeschakeld. Zeus ondersteunt enkele simpele health monitoring technieken zoals ping tot meer geavanceerdere zoals http inspectie.

5.1.3

Resultaten

Als we naar de round robin resultaten kijken in tabel 5.1, met de statische site CNN, dan vallen de resultaten tegen, de Zeus Load Balancer scoort slechter dan een enkele webserver. De verklaring is simpel, de load balancer heeft dubbel zoveel interrupts te verwerken als een webserver omdat het verkeer erdoor gaat in tegenstelling tot een webserver dat een eindpunt is. Ook het feit dat connecties getermineerd worden bij de load balancer en dan weer met de


43

Webservers


Bandbreedte

Apache 2.0

126

281 Mbps

Tabel 5.1: Maximale continue load CNN website bij Zeus load balancer webservers opgezet wordt is belastend. Een mogelijke oplossing zou het door zeus ondersteunde front-end clustering kunnen zijn. Hiermee wordt een cluster van load balancers gecreëerd die eventueel via dns load balancing kunnen aangesproken worden. Ofwel moet men een hele zware machine plaatsen. Om de verschillende algoritmes met elkaar te vergelijken, is het best dat de load balancer geen bottleneck is. Daarom m’n keuze voor de scouts site. De resultaten zijn terug te vinden in figuur 5.4. Round Robin, least connections en random doen het heel goed. Least connections en random schalen nagenoeg perfect ten opzichte van 1 webserver, maar dit heeft vooral te maken met het feit dat de webmachines gelijk zijn. Perceptive en fastest response time scoren slecht. Als we kijken naar de Mysql server, dan heeft deze een cpu belasting van ongeveer 80% bij de zwaarste belasting. In ons geval zou deze dus 5 webservers kunnen aansturen. Als de performantie daar te kort komt, kunnen we een mysql cluster aanleggen. Deze is echter niet getest.

Figuur 5.4: Vergelijking verschillende algoritmes met de scouts website bij Zeus load balancer

5.2 Linux Virtual Server

5.2

44

Linux Virtual Server

De linux virtual server is een layer 4 load balancer. De tcp connecties worden opgezet met de webservers. Een voorbeeld van een tcp diagram is terug te vinden in figuur 5.5. De linux virtual server ondersteunt NAT load balancing, direct routing en ip tunneling architecturen. De laatste is niet getest, omdat deze gelijkaardig is aan direct routing en iets minder performant is dan direct routing. De linux virtual server is een onderdeel van de linux kernel en kan men compileren door in het menu networking options IP virtual server(IPVS) support aan te zetten. IPVS heeft net zoals de conntrack tabel bij de firewall een eigen connectie tabel. De tabel is op dezelfde wijze opgebouwd als bij ip conntrack. De grootte van de hash tabel wordt in de kernel gecompileerd en moet een macht van 2 zijn. Elke hash is 2x de pointer size, dus in ons geval 16 bytes. De grootte van elke connectie hangt af van systeemarchitectuur en is hier (gentoo 64) 192 bytes. Als we kijken naar de helios155, en we reserveren 1900 MB geheugen voor onze connectietabel, en dan kunnen we ongeveer 10 miljoen gelijktijdige connecties in onze tabel krijgen. Als er geen stateful firewall aanwezig is op de load balancer, dan hoeven we de conntrack module niet te laden om zo geen dubbele tabel op het systeem te hebben. Enkel bij het gebruik van NAT load balancing moeten we een dubbele tabel gebruiken (zie verder) en zal dus het aantal gelijktijdige connecties minder dan de helft zijn. Met het programma ipvsadm kunnen we de load balancer instellen, realtime servers toevoegen en verwijderen, de connectie tabel bekijken,...

5.2.1

Ondersteunde load-balancing algoritmes

De linux virtual server ondersteunt alle algoritmes vermeld bij de zeus, behalve perceptive en random, en ondersteunt ook nog de volgende : Weighted least connections Het aantal connecties per webserver wordt gedeeld door het gewicht van die webserver, en deze met de laagste score krijgt het http verzoek. Destination hashing Dit algoritme wordt vooral gebruikt in cache systemen (zoals squid). Stel dat we de situatie hebben zoals in figuur 5.6. Wat we wensen is dat elk cache systeem een verschillende inhoud heeft. En als een client binnen een lan, een aanvraag doet aan de load balancer, dat hij voor een


45

Figuur 5.5: TCP diagram bij layer 4 load balancing

bepaalde site steeds op dezelfde cache server terecht komt. Via destination ip hashing, wordt elke aanvraag naar de goede cache server gestuurd. Voor onze webserver achitectuur is dit niet bruikbaar uiteraard, aangezien het bestemmingsadres bij ons alleen maar de webcluster is, en niet één of ander bestemmingsadres van een willekeurige site dat de client kiest. Locality-Based Least-Connection Een algoritme dat ook gebruikt wordt binnen cache structuren. Nu wordt er ook gebruik gemaakt van destination hashing, maar als de server overbelast of niet beschikbaar is, wordt de aanvraag naar een andere server overgeheveld en blijven volgende aanvragen voor deze server. Locality-Based Least-Connection with Replication Ongeveer zelfde systeem als het vorige, maar nu wordt met een server set per bestemming gewerkt. De server set is een deelverzameling van de cluster. Als alle server binnen de server set overbelast zijn, dan wordt een server uit de cluster met het minste jobs toegevoegd aan de


46

Figuur 5.6: Toepassing voor destination hashing en locality-based least connection (with replication)

server set voor deze bestemming. Als een server set niet wijzigt voor een bepaalde periode, dan wordt de meest beladen server uit deze server set verwijdert. Dit is om te vermijden dat iedere server set gewoon de ganse cluster wordt. Source hashing Dit algoritme hasht het source ip adres en bepaalt aan de hand van de hash naar welke server het gaat. Dit algoritme is in tegenstelling tot de vorige drie zeker bruikbaar binnen onze webserver architectuur.


47

Shortest Expected Delay Dit algoritme selecteert de server op basis van de volgende formule: (Ci + 1)/Ui, waarbij Ci het aantal jobs is op server i en Ui het gewicht van de server. De server i waarvoor deze formule het laagst is, krijgt de job.

5.2.2

NAT Load balancing

Bij NAT Load balancing passeert al het verkeer heen en terug door de load balancer. Dit maakt hem bij statische sites zeer snel tot bottleneck. Testopstelling De testopstelling is dezelfde als deze van de zeus load balancing en is terug te vinden in de figuren 5.2 en 5.3. We stellen de load balancer als volgt in : ipvsadm -A -t 10.0.0.1:80 -s rr ipvsadm -a -t 10.0.0.1:80 -r 192.168.5.2:80 -m ipvsadm -a -t 10.0.0.1:80 -r 192.168.5.3:80 -m ipvsadm -a -t 10.0.0.1:80 -r 192.168.5.4:80 -m iptables -t nat -A POSTROUTING -s 192.168.5.0/24 -j SNAT --to-source 10.0.0.1 echo 1 > /proc/sys/net/ipv4/ip_forward De eerste regel stelt de service en het algoritme in (round robin). Vervolgens voegen we de servers toe. De -m optie staat voor demasquerading. Uiteindelijk moeten we zelf op de terugweg een masquerade voorzien en we doen dit door SNAT (kan ook met -j MASQ). Hier zien we dat we ook de conntrack tabel nodig hebben. Dit is echter niet zo efficient omdat nu een dubbele tabel bijgehouden wordt. Resultaten In tabel 5.2 zien we dat de performantie van de load balancer ongeveer gelijk is aan een webserver met apache. De load balancer is genekt door de pci bus. Het verkeer dat binnenkomt moet ook nog naar buiten via een andere pci netwerkkaart, dus de pci bus wordt dubbel belast. Maar ook zonder deze bottleneck mogen we het een pak trager verwachten dan direct routing. Als we lineair schalen met de cpu belasting, dan verwacht ik ongeveer 500 Mbps in een systeem zonder netwerkbottleneck. Dns load balancing met verschillende load balancers of het gebruik


48

Webservers


Bandbreedte

Apache 2.0

167

371 Mbps

Tabel 5.2: Maximale continue load CNN website bij Linux Virtual Server NAT load balancer van een heel zwaar systeem zou de oplossing kunnen zijn. De vergelijking van de verschillende algoritmes kunt u in figuur 5.7. Alleen de geschikte algoritmes voor de webserverarchitectuur zijn weergegeven. Ze presteren min of meer gelijk, dit ligt aan het feit dat de webservermachines gelijk zijn.

Figuur 5.7: Vergelijking verschillende algoritmes met de scouts website bij Linux Virtual Sever load balancer

5.2.3

Direct Routing load balancing

Zoals we al in het hoofdstuk architectuur gezien hebben gaan de aanvragen door de load balancer, maar de antwoorden gaan rechtstreeks van de webserver naar de client. Dit stelt een aantal moeilijkheden, die algemeen omschreven worden als het “arp probleem”.


49

Het arp probleem Aangezien de client een antwoord terugkrijgt van de webserver, moet deze hetzelfde ip adres krijgen als de load balancer waar de vragen naartoe gestuurd worden. Anders kan men niet spreken van een geldige connectie. We stellen dit ip bij de webservers in als een virtueel ip adres van de local interface. De webservers mogen daarentegen niet reageren op arp aanvragen met dit ip adres. Ze moeten wel reageren op arp aanvragen van hun ’echt’ ip adres. Wat ook niet mag, is dat ze arp aanvragen uitsturen met het virtueel ip-adres. Want dan past de ontvanger van dit pakket z’n arp tabel aan. Bij sommige routers wordt een pakket met een mac adres dat niet overeenkomt met het ip adres in de arp tabel geweigerd. De oplossing hiervoor vindt u hieronder Testopstelling De volledige testopstelling vindt u terug in de figuren 5.8 en 5.9. Elke webserver (hier in ons voorbeeld 10.0.254.150) wordt als volgt ingesteld : ifconfig lo:0 10.0.0.1 netmask 255.255.255.255 broadcast 10.0.0.1 ifconfig eth0 10.0.254.150 netmask 255.255.0.0 broadcast 10.0.255.255 route add -host 10.0.0.1 dev lo:0 echo 1

>/proc/sys/net/ipv4/conf/eth0/arp_ignore

arptables -A OUTPUT -s 10.0.0.1 -j mangle

--mangle-ip-s 10.0.254.150

Arp ignore zorgt ervoor dat eth0 enkel reageert op arp aanvragen van de 10.0.254.150, niet van 10.0.0.1. Arptables is zoals iptables maar dan voor arp pakketten. Deze regel zorgt ervoor dat aanvragen zoals ”who has 10.0.3.16 tell 10.0.0.1” vertaald worden naar “who has 10.0.3.16 tell 10.0.254.150”. Hiervoor moet in de kernel de optie arp tables support met al z’n opties aanstaan (in networking options -> network packet filtering -> ip: netfilter configuration). Bij de avalanche was er geen probleem, maar wat moet er gebeuren als de router of firewall niet toelaat dat een antwoord op een aanvraag met bepaalde ip-mac combinatie, een andere ip-mac combinatie heeft? (wat bij direct routing wel het geval is). Een mogelijke oplossing is als volgt: ebtables -t nat -A POSTROUTING -j snat --to-source 00:0E:0C:6B:E1:0B --ip-source 10.0.0.1 -p 0x0800 Het bron mac adres wordt genat naar het mac adres van de load balancer. Ebtables kan in de kernel aangezet worden de optie 802.1d ethernet bridging in het menu networking options aan te


Figuur 5.8: Testopstelling direct routing met CNN site

50


51

Figuur 5.9: Testopstelling direct routing met scouts site

vinken, en ook ebtables support met de gepast opties (in networking options -> network packet filtering -> bridge netfilter configuration). Dit is echter nog niet voldoende, ook de switch kan hierdoor in de knoop slaan. De mac tabel moet aangepast worden met een statische rij waarin de poort en het mac adres van de load balancer staan. Als de firewall of router een linux machine is, dan kan het bovenstaande ook opgelost worden door de reverse path filter uit te zetten (echo 0 > /proc/sys/net/ipv4/conf/default/rp filter).

De load balancer wordt als volgt ingesteld: ifconfig eth0 10.0.0.2 netmask 255.255.0.0 broadcast 10.0.255.255

5.3 Verticaal versus horizontaal schalen

52

ifconfig eth0:0 10.0.0.1 netmask 255.255.255.255 broadcast 10.0.0.1 echo 1 > /proc/sys/net/ipv4/ip_forward

ipvsadm -A -t 10.0.0.1:80 -s rr ipvsadm -a -t 10.0.0.1:80 -r 10.0.254.150 ipvsadm -a -t 10.0.0.1:80 -r 10.0.254.151 ipvsadm -a -t 10.0.0.1:80 -r 10.0.254.152 ipvsadm -a -t 10.0.0.1:80 -r 10.0.254.153 ipvsadm -a -t 10.0.0.1:80 -r 10.0.254.154 Ik heb deze site enkel met de statische site CNN en “Hello World” getest omdat de dynamische resultaten identiek zullen zijn als Linux Virtual Server NAT. Het gebruikte besturingssysteem op de webservers was gentoo64 met kernel 2.6.16, op de load balancer gentoo64 met kernel 2.6.12. Resultaten In tabel 5.3 kunt u de resultaten van apache en tux zien. Het gebruikte algoritme is round robin. De bottleneck ligt bij de webservers, hoewel de load balancer bijna aan z’n bottleneck zit (+/- 90% cpu belasting, bij 5 webservers) alsook de avalanches. Deze configuratie verdient de voorkeur voor statische sites, want het is verschrikkelijk snel. Als er grote files een aantal keer na elkaar afgehaald worden, dan geraken we tot 2.9 Gbps (met 1 Avalanche). De bottleneck is dan nog steeds de via chipset in de webservers. Om nu de load balancer toch eens te maximaliseren en te overbelasten, gebruik ik simpele website ”Hello World” die we eerder als eens gebruikt hebben voor de firewall. We zien in figuur 5.10 dat waar de firewall bij overbelasting serieus degradeert in performantie, deze hier zelfs nul wordt bij een geringe overbelasting. Het is dan ook belangrijk om het aantal SYN berichten/s te beperken. Dit kan gebeuren bij de firewall door bijvoorbeeld volgende regel (bvb: maximum 10 syn berichten per seconde): iptables -A FORWARD -p tcp --syn -m limit --limit 1/s --limit-burst 10 -j accept

5.3

Verticaal versus horizontaal schalen

Nu alle resultaten bekend zijn, kan men de vergelijking maken tussen 1 webserver en een webcluster. In het vorig hoofdstuk waren de resultaten voor de CNN site bij de opteron ongeveer 2.2 Gbps. Dit zou ongeveer gelijk zijn aan een webcluster met 4 à 5 pc’s met K8VSE (via chipset)


53

Webservers


Bandbreedte

Apache 2.0 (4x)

614

1346 Mbps

Tux (4x)

930

2038 Mbps

Tux (5x)

1157

2531 Mbps

Tabel 5.3: Maximale continue load CNN website bij Linux Virtual Server Direct Routing load balancer

Figuur 5.10: Linux Virtual Server Direct Routing met hello world site


54

Server

aanpassingen

kostprijs (e)

Helios157(1 grote webserver)

zonder dual intel kaart

3607

Helios155(load balancer)

1 netwerkkaart: intel pci express

718

Helios150 t.e.m

Amd64 3200+

517 (1 NIC)

Helios154(webservers)

Nvidia Nforce 4 moederbord

568 (2 NIC’s)

1 of 2 intel pci express netwerkkaarten 3com baseline 2808

157

8 poort unmanaged switch Webcluster CNN website:

3com ipv alcatel switch

2456

3com ipv alcatel switch

3364

3 Webservers met 1 netwerkkaart 1 Load Balancer 1 switch Webcluster scouts website: 4 Webserver met 2 netwerkkaarten 1 Load Balancer 2 switchen Tabel 5.4: Kostprijs verschillende systemen, prijzen komen van mpl.be en zijn inclusief BTW moederborden, of 3 pc’s met Nforce 4 chipset. Voor de scouts website hebben we 4 machines nodig. In tabel 5.4 kan men de kostprijs van de verschillende systemen terugvinden. De amd64 2800+ is niet meer verkrijgbaar, in plaats daarvan heb ik een gelijkaardig systeem genomen met een amd64 3200+, Nforce 4 moederbord en intel pci express netwerkkaart. Dit systeem zal zeker beter presteren dan de systemen waarmee ik getest heb. De alcatel 6800 omniswitch is een beetje overkill voor ons systeem, in plaats daarvan neem ik de 3com baseline 8 poort unmanaged switch. Tot slot is de mysql server niet in rekening gebracht omdat de extra prijs voor de webserver en de webcluster gelijk zijn. Als we de kostprijs vergelijken zien we dat in de 2 gevallen we goedkoper een webcluster kunnen bouwen dan een grote webserver. Andere voordelen : • schaalbaarheid: een webcluster is heel gemakkelijk schaalbaar door een of meerdere webservers bij te zetten (in ons voorbeeld hebben we bij de CNN site bij uitbreiden wel een zwaardere load balancer en grotere switch nodig, 1 loadbalancer geeft ons nog 7 poorten om te verdelen tussen uplink en webservers, wat niet voldoende is).


55

• beschikbaarheid: Bij de Zeus load balancer zitten de tools ingebouwd, bij Linux virtual server doet men beroep op andere tools, maar elke webserver die uitvalt, kan onmiddellijk uit de cluster gezet worden zonder dat de site uitvalt. Als een zware enkele webserver uitvalt, ligt de site plat. Er kunnen ook meerdere load balancers zijn, die met heartbeat elkaars toestand volgen. • verticaal uitbreiden: De cluster kan ook verticaal uitgebreid worden zonder dat de site daarom van het net moet gehaald worden. Men voert op een rustig moment de upgrades machine per machine uit. Er zijn ook enkele nadelen: • stroomverbruik: Het Thermal Design Profile(TDP) van amd64 ligt op 89W en van de opteron op 95W (voor 1 processor). Dit is uiteraard niet het reële verbruik, maar de 4 ` a 5 machines zullen toch meer stroom verbruiken dan de dual opteron. • plaats: een webcluster neemt met al z’n machines een pak meer plaats in dan de enkele webserver.

CONCLUSIE

56

Hoofdstuk 6

Conclusie De bottleneck binnen een webcluster is afhankelijk van een aantal factoren.

Ten eerste is het type site heel belangrijk. Bij dynamische sites zal men vooral naar de webservers en eventueel database server(s) moeten kijken. Daar moet men vele zware machines voorzien afhankelijk van het aantal verwachte bezoekers.

Bij statische sites daarentegen, volstaan enkele machines. NAT load balancing en Layer 7 zijn minder geschikt omdat ze geen hoge doorvoer hebben. Direct Routing load balancing is hier aangewezen. Maar het probleem komt dan bij de firewall te liggen. Link aggregation met verschillende bridge stateless firewalls of DNS load balancing met NAT stateful firewalls kunnen de oplossing bieden. De eerste oplossing heeft als nadeel dat stateful firewall niet mogelijk is, de tweede dat verschillende internet ip adressen moeten gebruikt worden.

Een andere factor is het surfgedrag, men kan sites hebben waar veel geklikt moet worden en deze veroorzaken veel pakketten per seconde. Dan kan de bottleneck zowel in de front-end als in de back-end liggen, afhankelijk van de site. Ook zijn er sites met korte bezoeken en veel bezoekers, andere lange bezoeken en minder bezoekers. De eerste veroorzaakt veel connecties per seconde en de laatste veel open connecties. Bij veel open connecties is meestal de geheugenhoeveelheid in de webservers de bottleneck. 1 webserver met 512 MB ram kan 80000 open connecties aan, de stateful firewall kan er 6 miljoen aan met 2 GB. De direct routing load balancer kan er 10 miljoen aan met 2 GB ram.

CONCLUSIE

57

Als we kijken naar de webserver die in deze thesis aan bod gekomen zijn, dan is Tux heel geschikt voor statische sites. Zeus is ook een hele snelle en kan ook dynamische pagina’s aan, maar is wel een commercieel product. Als men niet in de geldbuidel wil tasten, dan is een combinatie van Tux en Apache onder linux ideaal.

Onder de load balancer is de direct routing load balancer heel snel, zelfs op een beperkt systeem. Het nadeel is dat hij gemakkelijk om de tuin te leiden is aangezien hij maar de helft van elke tcp connectie ziet. Hij ziet dus de reactie van de webserver niet. Een stateful firewall is dan zeker op z’n plaats! De NAT load balancer heeft dit niet, maar is door z’n beperkte doorvoer alleen te gebruiken bij dynamische sites waar de verwachte bandbreedte niet te groot is. De Zeus zxtm heeft een nog beperktere doorvoer, maar kan een cluster in front-end opzetten zonder dns balancing en is een layer 7 load balancer.

De vergelijking tussen een enkele webserver en een cluster leverde ons volgend beeld op: als de plaats en het verbruikte vermogen geen rol spelen, dan is er geen reden om te twijfelen aan een webcluster.

APACHE 2.0: HTTPD.CONF

58

Bijlage A

Apache 2.0: httpd.conf ServerRoot ”/usr/local/apache2”

PidFile ”/var/run/apache2.pid” Timeout 200 KeepAlive On MaxKeepAliveRequests 100 ServerLimit

128

StartServers

15

MaxClients

8192

MinSpareThreads

25

MaxSpareThreads

200

ThreadsPerChild

64

MaxRequestsPerChild

0

Listen 0.0.0.0:80 #LoadModule php4 module modules/libphp4.so LoadModule access module modules/mod access.so LoadModule auth module modules/mod auth.so LoadModule env module modules/mod env.so LoadModule expires module modules/mod expires.so LoadModule headers module modules/mod headers.so LoadModule mime module modules/mod mime.so


LoadModule negotiation module modules/mod negotiation.so LoadModule setenvif module modules/mod setenvif.so LoadModule log config module modules/mod log config.so LoadModule logio module modules/mod logio.so LoadModule autoindex module modules/mod autoindex.so LoadModule dir module modules/mod dir.so User apache Group apache ServerAdmin root@localhost UseCanonicalName Off DirectoryIndex index.html index.htm index.php DefaultType text/plain HostnameLookups Off ErrorLog logs/error log #CustomLog logs/access log common ServerTokens Prod ServerSignature On IndexOptions FancyIndexing VersionSort AddIconByEncoding (CMP,/icons/compressed.gif) x-compress x-gzip AddIconByType (TXT,/icons/text.gif) text/* AddIconByType (IMG,/icons/image2.gif) image/* AddIconByType (SND,/icons/sound2.gif) audio/* AddIconByType (VID,/icons/movie.gif) video/* AddIcon /icons/binary.gif .bin .exe AddIcon /icons/binhex.gif .hqx AddIcon /icons/tar.gif .tar AddIcon /icons/world2.gif .wrl .wrl.gz .vrml .vrm .iv AddIcon /icons/compressed.gif .Z .z .tgz .gz .zip AddIcon /icons/a.gif .ps .ai .eps AddIcon /icons/layout.gif .html .shtml .htm .pdf AddIcon /icons/text.gif .txt

59


AddIcon /icons/c.gif .c AddIcon /icons/p.gif .pl .py AddIcon /icons/f.gif .for AddIcon /icons/dvi.gif .dvi AddIcon /icons/uuencoded.gif .uu AddIcon /icons/script.gif .conf .sh .shar .csh .ksh .tcl AddIcon /icons/tex.gif .tex AddIcon /icons/bomb.gif core AddIcon /icons/back.gif .. AddIcon /icons/hand.right.gif README AddIcon /icons/folder.gif ˆˆDIRECTORYˆˆ AddIcon /icons/blank.gif ˆˆBLANKICONˆˆ DefaultIcon /icons/unknown.gif ReadmeName README.html HeaderName HEADER.html IndexIgnore .??* *˜ *# HEADER* README* RCS CVS *,v *,t .svn AddLanguage ca .ca AddLanguage cs .cz .cs AddLanguage da .dk AddLanguage de .de AddLanguage el .el AddLanguage en .en AddLanguage eo .eo AddLanguage es .es AddLanguage et .et AddLanguage fr .fr AddLanguage he .he AddLanguage hr .hr AddLanguage it .it AddLanguage ja .ja AddLanguage ko .ko

60


AddLanguage ltz .ltz AddLanguage nl .nl AddLanguage nn .nn AddLanguage no .no AddLanguage pl .po AddLanguage pt .pt AddLanguage pt-BR .pt-br AddLanguage ru .ru AddLanguage sv .sv AddLanguage zh-CN .zh-cn AddLanguage zh-TW .zh-tw LanguagePriority en ca cs da de el eo es et fr he hr it ja ko ltz nl nn no pl pt pt-BR ru sv zh-CN zh-TW ForceLanguagePriority Prefer Fallback AddDefaultCharset ISO-8859-1 AddCharset ISO-8859-1 .iso8859-1 .latin1 AddCharset ISO-8859-2 .iso8859-2 .latin2 .cen AddCharset ISO-8859-3 .iso8859-3 .latin3 AddCharset ISO-8859-4 .iso8859-4 .latin4 AddCharset ISO-8859-5 .iso8859-5 .latin5 .cyr .iso-ru AddCharset ISO-8859-6 .iso8859-6 .latin6 .arb AddCharset ISO-8859-7 .iso8859-7 .latin7 .grk AddCharset ISO-8859-8 .iso8859-8 .latin8 .heb AddCharset ISO-8859-9 .iso8859-9 .latin9 .trk AddCharset ISO-2022-JP .iso2022-jp .jis AddCharset ISO-2022-KR .iso2022-kr .kis AddCharset ISO-2022-CN .iso2022-cn .cis AddCharset Big5 .Big5 .big5v AddCharset WINDOWS-1251 .cp-1251 .win-1251 AddCharset CP866 .cp866 AddCharset KOI8-r .koi8-r .koi8-ru AddCharset KOI8-ru .koi8-uk .ua

61


62

AddCharset ISO-10646-UCS-2 .ucs2 AddCharset ISO-10646-UCS-4 .ucs4 AddCharset UTF-8 .utf8 AddCharset GB2312 .gb2312 .gb AddCharset utf-7 .utf7 AddCharset utf-8 .utf8 AddCharset big5 .big5 .b5 AddCharset EUC-TW .euc-tw AddCharset EUC-JP .euc-jp AddCharset EUC-KR .euc-kr AddCharset shift jis .sjis AddType application/x-compress .Z AddType application/x-gzip .gz .tgz AddHandler type-map var BrowserMatch ”Mozilla/2” nokeepalive BrowserMatch ”MSIE 4{}.0b2;” nokeepalive downgrade-1.0 force-response-1.0 BrowserMatch ”RealPlayer 4{}.0” force-response-1.0 BrowserMatch ”Java/1{}.0” force-response-1.0 BrowserMatch ”JDK/1{}.0” force-response-1.0 BrowserMatch ”Microsoft Data Access Internet Publishing Provider” redirect-carefully BrowserMatch ”ˆWebDrive” redirect-carefully BrowserMatch ”ˆWebDAVFS/1.[012]” redirect-carefully BrowserMatch ”ˆgnome-vfs” redirect-carefully NameVirtualHost *:80 DocumentRoot ”/var/www/” Options Indexes FollowSymLinks AllowOverride None Order allow,deny Allow from all


63

MYSQL: MY.CNF

Bijlage B

Mysql: my.cnf port = 3306 socket = /var/run/mysqld/mysqld.sock

[safe mysqld] err-log = /var/log/mysql/mysql.err

[mysqld] skip-innodb skip-locking port = 3306 socket = /var/run/mysqld/mysqld.sock pid-file = /var/run/mysqld/mysqld.pid log-error = /var/log/mysql/mysqld.err basedir = /usr datadir = /var/lib/mysql tmpdir = /tmp language = /usr/share/mysql/english key buffer = 96M max allowed packet = 1M max join size = 4294967295 myisam max sort file size = 4294967295 table cache = 7000 open-files-limit = 16000 sort buffer size = 8M read buffer size = 2M

64

MYSQL: MY.CNF

tmp table size = 64MB myisam sort buffer size = 16M thread cache = 8 query cache type = 1 query cache size = 96M thread concurrency = 4 max connections = 350 wait timeout = 300

[mysqldump] quick max allowed packet = 16M

[isamchk] key buffer = 96M sort buffer size = 128M read buffer = 2M write buffer = 2M

[myisamchk] key buffer = 96M sort buffer size = 128M read buffer = 2M write buffer = 2M

[mysqlhotcopy] interactive-timeout

65

BIBLIOGRAFIE

66

Bibliografie [1] Lien Deboosere, Experimentele karakterisatie van webservers, Information Technology Department (INTEC), Ghent University (UGent),2005. [2] D.

Gaudet,

”Apache

Performance

Notes

-

Apache

HTTP

server”,

http://httpd.apache.org/docs/misc/perf-tuning. html [3] Zeus load balancer and webserver, http://www.zeus.com [4] Apache webserver, http://www.apache.org [5] Linux Virtual Server, http://www.linuxvirtualserver.org [6] Redhat.com

-

Red

Hat

Content

Accelerator

(TUX)

reference

manuals,

http://www.redhat.com/docs/manuals/tux/ [7] Conntrack performance tuning, http://www.wallfire.org/misc/netfilter conntrack perf.txt [8] Netfilter/iptables project homepage, http://www.netfilter.org

LIJST VAN FIGUREN

67

Lijst van figuren 2.1

Algemene architectuur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3

2.2

NAT load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

4

2.3

Direct Routing load balancing . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5

2.4


6

3.1

Oplossing aggregation en bridging firewall . . . . . . . . . . . . . . . . . . . . . .

10

3.2

De smartbits en stromen binnen de firewall . . . . . . . . . . . . . . . . . . . . .

11

3.3

Testopstelling NAT stateful firewall . . . . . . . . . . . . . . . . . . . . . . . . . .

13

3.4

Resultaten NAT stateful firewall . . . . . . . . . . . . . . . . . . . . . . . . . . .

15

3.5

Resultaten NAT stateful firewall met 4067 regels . . . . . . . . . . . . . . . . . .

16

3.6

Resultaten NAT stateful firewall met 4067 regels, hoge belasting . . . . . . . . .

17

4.1

De zeus webserver admin interface . . . . . . . . . . . . . . . . . . . . . . . . . .

21

4.2

Testopstelling statische site . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.3

Testopstelling dynamische site . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

22

4.4

De CNN website . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

23

4.5

De scouts Boekhoute website . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

25

4.6

De burst meting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

28

4.7

Resultaten Apache, Tux en Zeus . . . . . . . . . . . . . . . . . . . . . . . . . . .

29

4.8

Resultaten Apache en Zeus met de scouts site . . . . . . . . . . . . . . . . . . . .

30

4.9

Burst meting bij Apache met de CNN website op teruggeklokt helios155 platform

31

4.10 Burst meting bij Tux met de CNN website op teruggeklokt helios155 platform . .

32

4.11 Burst meting bij Zeus met de CNN website op teruggeklokt helios155 platform .

33

4.12 Burst meting bij Apache met de scouts website op teruggeklokt helios155 platform 34 4.13 Burst meting bij Zeus met de scouts website op teruggeklokt helios155 platform .

35

LIJST VAN FIGUREN

68

4.14 Vergelijking tussen Via en Nforce chipset . . . . . . . . . . . . . . . . . . . . . . .

36

4.15 Vergelijking tussen Opteron 280 en Amd64 2800+ met CNN website . . . . . . .

36

4.16 Vergelijking tussen Opteron 280 en Amd64 2800+ met scouts website . . . . . .

37

4.17 Vergelijking tussen gentoo en debian, 32 en 64 bit, in apache met CNN website .

37

4.18 Vergelijking tussen gentoo en debian, 32 en 64 bit, in tux met CNN website . . .

38

5.1

TCP diagram bij layer 7 load balancing . . . . . . . . . . . . . . . . . . . . . . .

40

5.2

Testopstelling Zeus en NAT load balancing met CNN site . . . . . . . . . . . . .

41

5.3

Testopstelling Zeus en NAT load balancing met scouts site . . . . . . . . . . . . .

42

5.4

Vergelijking verschillende algoritmes met de scouts website bij Zeus load balancer

43

5.5

TCP diagram bij layer 4 load balancing . . . . . . . . . . . . . . . . . . . . . . .

45

5.6

Toepassing voor destination hashing en locality-based least connection (with replication) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.7

46

Vergelijking verschillende algoritmes met de scouts website bij Linux Virtual Sever load balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

48

5.8

Testopstelling direct routing met CNN site

. . . . . . . . . . . . . . . . . . . . .

50

5.9

Testopstelling direct routing met scouts site . . . . . . . . . . . . . . . . . . . . .

51

5.10 Linux Virtual Server Direct Routing met hello world site . . . . . . . . . . . . . .

53

LIJST VAN TABELLEN

69

Lijst van tabellen 3.1

helios157 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

14

3.2

Resultaten van de bridged stateless firewall . . . . . . . . . . . . . . . . . . . . .

14

4.1

helios150 t.e.m. helios154 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

24

4.2

helios155 die teruggeklokt is en single channel ram heeft . . . . . . . . . . . . . .

26

4.3

helios155 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

27

4.4

Vergelijking maximale continue load CNN website . . . . . . . . . . . . . . . . .

28

4.5

Vergelijking maximale continue load scouts website . . . . . . . . . . . . . . . . .

28

4.6

Vergelijking maximale continue load CNN website op 2 kernels op helios150 . . .

32

5.1

Maximale continue load CNN website bij Zeus load balancer . . . . . . . . . . . .

43

5.2

Maximale continue load CNN website bij Linux Virtual Server NAT load balancer 48

5.3

Maximale continue load CNN website bij Linux Virtual Server Direct Routing load balancer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5.4

53

Kostprijs verschillende systemen, prijzen komen van mpl.be en zijn inclusief BTW 54

Bepalen van optimale high-end en schaalbare webserver architectuur

Recommend Documents