Loadbalancing bij Tweakers.net

Loadbalancing in het algemeen

Wat houdt loadbalancing in? Loadbalancing betekent heel letterlijk het verdelen van werk over meerdere uitvoerenden. In praktijk houdt dat voor Tweakers.net in dat wij de binnenkomende requests (opdrachten van bezoekers om pagina's te genereren) voor de verschillende websites verdelen over het serverpark. Dat dit een groot aantal voordelen heeft hoeven wij je waarschijnlijk niet te vertellen, maar toch noemen wij een aantal redenen die voor ons van belang waren:

• Als er een server uitvalt wordt dat opgevangen door de andere servers uit de groep servers (de serverpool). Hetzelfde geldt uiteraard voor servers die vanwege onderhoudsredenen worden platgelegd.


• Indien een bepaalde website ineens heel zwaar belast wordt staan de andere servers klaar om die verzwaring samen op te vangen. Zonder loadbalancing zou één server op eigen houtje alle extra aandacht moeten verwerken, iets wat meestal resulteert in een niet bereikbare site.

Loadbalancing wordt dus meestal om twee redenen toegepast; het verdelen van de werklast en het verlagen van het aantal 'Single Point of Failures'.

Hoe doet Tweakers.net dat op dit moment?

Momenteel proberen we de websites zo goed mogelijk te verdelen over de servers, rekening houdend met de zwaarte van de verschillende onderdelen. De frontpage wordt door middel van een zogenaamde 'round robin DNS' verdeeld over verschillende webservers. Dit betekent dat er meerdere servers zijn die reageren op de naam www.tweakers.net, omdat de DNS-server instructies heeft om het IP-adres van een willekeurige server uit de groep terug te geven wanneer iemand om de naam www.tweakers.net vraagt. Het nadeel van deze methode is vrij makkelijk te zien; als er een server uitvalt zal een deel van de requests niet afgehandeld worden omdat de DNS-server niet controleert of een bepaalde server wel online is. Stel dus dat één van de drie servers uitvalt, dan komt een derde van de bezoekers bij een dode server uit. Ook een nadeel is dat de DNS server niet kan zien hoeveel werk de servers hebben, hierdoor kan het nog steeds voorkomen dat een server, die te veel werk heeft, aangesproken wordt.

Enkele andere manieren van loadbalancing

Naast de vrij primitieve 'round robin'-methode is het ook mogelijk om een speciale server in te zetten als 'front-end'. Deze vangt dan alle connecties op en stuurt deze door naar één van de servers uit de serverpool. De zogenaamde 'virtual server' software voor Linux is een voorbeeld van een pakket dat dit kan regelen. Net toen we bezig waren om een dergelijke constructie te implementeren werden we benaderd door BrainForce, met de vraag of we niet toevallig interesse hadden om de nieuwe One4Net B-100 opstelling uit te proberen.

Uiteraard zijn er nog vele andere manieren van loadbalancing, zo zijn er een aantal softwarematige methoden. Een ervan is het inzetten van een reverse-proxy met bijvoorbeeld Squid. Deze methode kan weliswaar een verdeling maken van de load, maar heeft geen mogelijkheden voor failover als de load balancer of één van de webservers uitvallen. Verder zijn er modules voor Apache zoals mod_backhand, maar hoewel dit best aardig werkt hou je natuurlijk een 'Single Point of Failure'.

Er zijn natuurlijk ook vele hardwarematige oplossingen. De zelfbouw Linux Virtual Server systemen, die we al eerder hebben genoemd, beschikken wel over failover en high availability features voor zowel de loadbalancers als de webservers. De hardwarematige oplossingen van bedrijven als Cisco, BigIP en Foundry Networks hebben als voordeel dat zij snel geïmplementeerd kunnen worden, veel mogelijkheden hebben en gebruiksvriendelijk zijn. Helaas zijn deze loadbalancers erg duur. Denk hierbij aan bedragen van 10.000 tot soms wel 25.000 dollar.

Tweakers.net en BrainForce

Waarom de keus voor BrainForce

De One4Net B-100 van BrianForce is een machine die in principe precies kan doen wat we zelf wilden maken, maar dan als kant-en-klare oplossing. Het product bestaat uit een speciaal getweakte Linux-kernel en met zorg geselecteerde hardware; een erg interessante optie voor een site als deze die zo'n 1,2 miljoen views per dag moet afhandelen. Voor een snelle verwerking van de requests staat een 800MHz Pentium III met 256MB RAM garant. Tweakers.net heeft daarom nu beschikking over twee van deze loadbalancers in speciale HA uitvoering. Hierbij staat HA voor High Availability, een logische keuze vanwege de vele tweakotine-junks, en twee stuks om te voorkomen dat een probleem met een loadbalancer meteen de hele site onbereikbaar maakt. Omdat BrainForce een relatief kleine speler in deze markt is kunnen ze goedkope producten aanbieden. Bovendien luisteren ze goed naar onze ideeën en denken ze mee in het geval van problemen. Zo heeft een medewerker uit Duitsland in de eerste week uitleg gegeven over 'Zhe Guichi' , en is Kees daarna nog diverse malen naar TrueServer geweest om samen met BrainForce een goed begrip te krijgen van de werking van het systeem.

Samenwerking met BrainForce

De One4Net loadbalancers die we ontvingen hadden pas het laatste stadium van de bèta-periode bereikt, en waren nog niet helemaal klaar voor productie. Toch besloten we ze al in te gaan zetten, om alvast ervaring op te kunnen doen en waar mogelijk feedback te geven om het product verder te verbeteren. Een deel van de door ons aangedragen suggesties zijn inmiddels ook daadwerkelijk in de software doorgevoerd. De belangrijkste verbeteringen zijn de volgende:

• De GUICC (Graphical User Interface Control Centre) beheerssoftware is grotendeels in Java geschreven en zou in theorie dus op ieder besturingssysteem moeten draaien. Toch bleek het nog niet helemaal lekker te lopen buiten het ontwikkelplatform (SuSe). Na enkele aanwijzingen wisten de mensen van BrainForce deze problemen op te lossen, waardoor de software nu op veel meer - zoniet alle - Linux versies werkt.


• De GUICC interface kon geen contact leggen met de B-100 als software en loadbalancer niet in hetzelfde subnet zaten. Ook dit euvel is nu opgelost, waardoor de loadbalancers nu ook van buitenaf beheerd kunnen worden.


• Volledige ondersteuning voor NAT is ook naar aanleiding van problemen die we ontdekten geïmplementeerd. Toen de loadbalancers pas in gebruik waren genomen kwamen we tot de conclusie dat dit nog niet helemaal werkte, waardoor bijvoorbeeld de passmailer de buitenwereld niet kon bereiken.

Wij zijn echter niet de eersten die met deze loadbalancers werken. Een goed voorbeeld van een site die al sinds november met de B-100 werkt is Foto Keller in Duitsland. De loadbalancer daar is nog niet down geweest.

De One4Net B-100 in detail

De bedieningsinterface

Voor het beheer van de loadbalancers is er de GUICC (Graphical User Interface Control Center), waarmee de loadbalancers remote bediend kunnen worden. Om te bekijken hoe stabiel het netwerk draait kunnen er via de GUICC ook allerlei statistieken opgevraagd worden over zaken als uptimes en serverbelasting. Deze gaan we proberen te integreren in de statistieken-pagina van Tweakers.net.

De interface bij binnenkomst

Allerlei interessant uitziende grafiekjes met statistieken

Globale instellingen voor loadbalancing

Aanmaken nieuwe virtual-service

Overzicht van de hosts

Wat kunnen de One4Net loadbalancers allemaal?

Ondanks de beta-versie van de software zijn we van mening dat we de loadbalancers erg goed kunnen gebruiken. Niet alleen zijn ze makkelijk in gebruik, maar ook nog eens speciaal geoptimaliseerd voor het werk dat ze moeten doen. De B-100 kent vijf verschillende manieren om de aanvragen over verschillende servers te verdelen:

• Round Robin: simpelweg 'één voor één' de verschillende servers een verbinding doorgeven.


• Weighted Round Robin: ongeveer hetzelfde als de normale Round Robin, maar de servers met een hogere 'weight' krijgen meer verbindingen te verwerken. Zo kun je bijvoorbeeld aangeven dat een dual bak twee keer zoveel werk krijgt als een andere server met één processor.


• Least Connection: als er grote verschillen zijn in de tijdsduur van het verwerken van een request kan het zijn dat 'Round Robin' niet goed meer werkt. Least Connection geeft de server die het minste verbindingen open heeft staan het meeste werk.


• Weighted Least Connection: zie Least Connection, maar dan weer met de mogelijkheid om aan te geven dat een bepaalde server zwaarder belast kan worden dan een andere.


• Adaptive weighted method: de servers bepalen zelf hoe zwaar ze belast kunnen worden. Dit kan afhankelijk zijn van verschillende factoren zoals hoeveelheid vrije schijfruimte, aantal openstaande verbindingen, beschikbare bandbreedte, hoeveelheid vrij geheugen en gebruik van de CPU.

De beveiliging tegen uitval en downtime.

De loadbalancer merkt zelf op dat er een server uitvalt en schrapt deze dan uit het lijstje van beschikbare servers. Mocht het nodig blijken, dan kunnen alle verbindingen doorgesluisd worden naar een enkele server. Ondanks het feit dat de One4Net B-100 gebruik maakt van CompactFlash in plaats van een harde schijf en volledig gebaseerd is op robuuste IBM hardware en Linux software kan het voorkomen dat een loadbalancer uitvalt. Ook hier is bij de B-100 rekening mee gehouden. De twee loadbalancers hebben dezelfde configuratie-files aan boord en houden deze synchroon middels een null-modem kabel. Zodra één van de twee merkt dat de ander niet meer reageert worden direct alle taken naar de overgebleven balancer geschoven.

Er kan echter een vertraging van (nu nog) 30 seconden optreden als de reserve-balancer standby was op het moment dat de primaire uitviel. Dit komt omdat interne en externe IP-adressen moeten worden overgenomen, en deze door de werking van de ethernet-standaard niet van het ene op het andere moment kunnen overspringen. Zodra de uitgevallen loadbalancer weer online komt zal deze in standby modus gaan en netjes zijn broertje beginnen te monitoren, waarna het bovenstaande proces zich eventueel weer kan herhalen. Gelukkig is dit 'probleem' grotendeels opgelost in de nieuwe software; de 30 seconden is een standaard instelling die getuned kan worden, en in de nieuwe software is deze instelling standaard op 4,5 seconde gezet.

Laatste woord

Nu denk je misschien: "wat een raar einde voor dit verhaal". Dat klopt, omdat we nog bezig zijn met nieuwe software en het configureren van de apparaten is het op dit moment lastig om een echte conclusie te trekken, maar Tweakers als we zijn willen we jullie graag op de hoogte houden . Als we de One4Net B-100 apparaten in gebruik hebben genomen zal er een tweede artikel verschijnen.

Reacties (66)

[RvdH]

Gaaf apparaat, maar hoe zit het met de beveiliging?
Het lijkt mij immers niet wenselijk dat iemand controle krijgt over deze balancers en de hele site onderuithaalt/doorwijst naar microsoft.com ofzo.
Zijn de verbindingen via SSL? Authenticatie met crypto-keys?

En draait de site er nu al op? Maakt fokzine doordat ze op jullie servers draaien ook gebruik van deze technieken?

Wat als er een database server down gaat, lost die loadbalancer dat op, of zit het in de php scripts? Of is er geen backup-db server?

Zit er firewall software op, of moet dat alsnog op de individuele servers gebeuren?

Zitten de servers nu ook echt afgeschermd van het net en zijn de balancers ook gateways, of zijn ze nog direct bereikbaar via inet? In het laatste geval, is het niet veel veiliger en mooier om alle verkeer via de balancers te laten lopen?

Zijn de loadbalancers zelf ook onder elkaar gebalanced?

[ACM]

Ze zijn in principe bedoelt om vanaf een lokaal netwerk bedient te worden.

Dus niet echt een issue om dat allemaal te encrypten, wat voor protocol de client-software met de server-software speekt weet ik niet, dat zou heel goed encrypted kunnen zijn.

Authenticatie is verder (voornamelijk) ip-based, wat je dus ook in moet stellen op de lokale prompt.

Fokzine moet er in principe ook mee kunnen draaien, maar geen van de sites draaien er nog op.

Databases zijn niet zo eenvoudig te loadbalancen als een webservice, zeker niet door simpelweg de connecties te roundrobinnen.

De huidige versie van de software op die LB's ondersteund geen gateway-werking, dat is de voornaamste reden dat we ze nog niet gebruiken.
Het laatste geval willen we dus mede afvangen dmv (een) firewall(s).

Replication is met mysql niks geworden, doordat topix queries weet uit te voeren die de replicatie onderuit hielpen.

En inderdaad ze loadbalancen onderling niet... Dat zou de boel wel heel erg complex/foutgevoelig maken, vooral omdat er ergens bekend moet zijn bij de client met welk ip ze moeten verbinden... En dat dat ip niet zomaar mag wijzigen.

[RvdH]

Databases zijn niet zo eenvoudig te loadbalancen als een webservice, zeker niet door simpelweg de connecties te roundrobinnen.

Inderdaad, daarom was ik er benieuwd naar. Hier op mijn werk hebben we gelukkig de mogelijkheid om mysql hotcopy's te doen om de databases te synchroniseren, want updates komen alleen voor als wij die beginnen (en dat doen we dus net voor een sync), waardoor we de load kunnen verdelen over 2 mysql databases.

De huidige versie van de software op die LB's ondersteund geen gateway-werking, dat is de voornaamste reden dat we ze nog niet gebruiken.
Het laatste geval willen we dus mede afvangen dmv (een) firewall(s).

Hoe gaat dat samenwerken met de loadbalancers? Een firewall voor de balancers, of erachter? Hmm *denkt na* er voor denk ik. Gaat die firewall dan alles wat mag doorsturen naar de loadbalancers? Weten die dan nog waar het packet vandaan kwam? Lijkt me een ingewikkelde operatie... zou ik graag een stukje over zien verschijnen als het eenmaal zo ver is

En inderdaad ze loadbalancen onderling niet... Dat zou de boel wel heel erg complex/foutgevoelig maken, vooral omdat er ergens bekend moet zijn bij de client met welk ip ze moeten verbinden... En dat dat ip niet zomaar mag wijzigen.

Dat gebeurt ook niet, elke client zou gewoon z'n verbinding houden. Maar goed, de load op die balancers zal ook wel meevallen, dus zo'n issue is het niet.

Hoe werkt die adaptive weighted method?
Hoe weten de balancers wat de hoeveelheid hd space, memory, verbindingen e.d zijn per server? Gaat dat via snmp ofzo, of moet je een soort client installeren die die info naar de balancers stuurt?

[ACM]

De (set) firewall(s) zal inderdaad voor de loadbalancers komen.

Met het dataverkeer zal het prima gaan hoor
De firewall is niet perse een NAT-gateway natuurlijk, als deze gewoon een normale gateway werking heeft met packet-filtering/throtteling/etc zal het allemaal prima lopen.

Ik denk dat het vele malen ingewikkelder is om een (niet te) sluitende firewall config te maken dan het daadwerkelijk implementeren van die firewall

En inderdaad de loadbalancers zullen niet vreselijk zwaar belast worden, de loadbalancers zijn (bij ons) voorzien van 800Mhz pentium 3's en zelfs met geavanceerde scheduling algortime's zal dat nog soepel lopen op 100Mbit.

De adaptive methode werkt niet met smtp, maar 'via http' je laat (een script) een getal tussen de 0 en 100 genereren (dus je doet dat per server waarbij je zelf kan bepalen wat voor die service van belang is) en dat getal wordt elke (halve?) minuut opgehaald door de loadbalancer.

Als dit getal 0 is, is de server onbelast, als het 100 is zal de server niet gebruikt worden

[Floor-is]

1. Beveiliging weet ik zelf weinig van, dus geef ik maar geen antwoord

2. Nee de site draait er nog niet op, dat komt nog, daar gaat het 2e artikel dan ook over.

3. De DataBeestjes worden niet geloadbalanced, dus dat zou nog een probleem zijn, maar hier zijn wel andere (nog niet werkende) oplossingen voor.

4. FireWallsoftware zit er niet op, we zijn nog aan het onderzoeken of we 2 firewalls in gaan zetten of dat we dat op een andere manier oplossen.

5. De LB's werken met een soort aangepast NAT-protocol. Al het verkeer loopt derhalve via deze apparaten.

6. Ja en nee, dat staat in het artikel, ze draaien onder een HA opstelling. Dat wil zeggen dat er eentje het werk doet en dat als deze uitvalt, de tweede het opzal vangen.

[RvdH]

3. Replication toch niks geworden?
4. Ik geef geen reply vanwege je antwoord op punt 1
6. Das dus geen loadbalancing

[Sir_Killalot]

Rick, je baalt gewoon dat jij geen beheerder meer bent van al dit moois

[Postman]

3. Replication staat uit (volgens mij... ooit eens van Femme gehoord op GoT)

[ZeRoC00L]

Had Rick niet zelf besloten ermee te kappen ?
(tijdgebrek ?????)

[ACM]

Jongens, wat heeft het hoe en wat omtrent Rick te maken met de loadbalancers?

Rick is ondertussen alweer ruim een jaar niet meer voor Tweakers.net in dienst.

[Verwijderd]

1. De B-100 draait op een 'hardened' -gemodificeerde- Linux variant, wat o.a. betekent dat er geen overbodige services draaien en alleen de noodzakelijke poorten openstaan.
De verbinding tussen de userinterface en de B-100 is beide kanten op met Blowfish encrypted en zoals ACM al terecht opmerkt in een volgend bericht is de authenticatie voornamelijk IP-based.

[Femme]

Replication heeft vorig jaar na de zomer een tijdje goed gedraaid. De redenen waarom het nu niet gebruikt wordt:

- Sinds de upgrade naar dual Athlon MP 1600+ en wat tweaks in de scripts is de load op Artemis zo laag dat load balancing dmv replication niet noodzakelijk is.

- Als replication slave werd Apollo gebruikt, waar ook GoT op draait. Het is echter niet ideaal om als replication server een server te gebruiken die zelf al een redelijk zware load heeft. Het liefst gebruik je voor replication een server die verder niets anders dan replication doet, zodat andere databases (die op de slave draaien) geen invloed kunnen hebben op de master->slave replication.

- Sinds we InnoDB gebruiken is het lastiger geworden om een snapshot te maken van de database. De beste manier op een snapshot te maken is om de complete data directory van MySQL op de master naar de slave te kopieren. Omdat MyISAM de data per database in een aparte directory zet, is het eenvoudig om alleen die databases te kopieren waarvan replication wordt gedaan op de slave. InnoDB stopt z'n data in een of meerdere datafiles. Dit geeft twee problemen: als niet alle databases 'gereplicate' moeten worden zit je met het probleem dat je niet de specifieke data kunt kopieren aangezien dat allemaal bij elkaar staat in de datafiles en 2) als de slave ook andere InnoDB databases draait heb je ook op de slave datafiles die je niet zomaar kunt overschrijven. Als de slave een dedicated replication slave zou zijn die een 1:1 kopie van de master draait zou dat allemaal geen probleem zijn, maar we hebben op dit moment niet de hardware voor een dedicated replication slave.

Uiteraard kun je ook gewoon mysqldump gebruiken om de gewenste data te kopieren, maar dat kost meer downtime op de master en de slave. Een snapshot van de datadir geeft altijd de zekerheid dat het snapshot op de slave gelijk zal zijn aan de master (dit is essentieel de database op de slave synchroon met de master te houden nadat repliation is gestart).

- MySQL draait sinds 3.23.49 dermate stabiel (uptime van +50 dagen en 1,1 miljard queries voor stroomuitval in de colo) dat er geen noodzaak is om vanuit het oogpunt van high availability replication te draaien. Zoals eerder gezegd was er ook geen noodzaak om vanwege loadbalancing replication te draaien.

- Failover vanuit de PHP scripts blijkt lastig te realiseren omdat de PHP mysql_connect functie geen timeout geeft als een server onbereikbaar is (??). Als de master onbereikbaar is, blijft het connect scriptje doodleuk hangen op de connect in plaats van een timeout te geven zodat geprobeerd kan worden om een (read-only) verbinding te maken met de slave (er is wel iemand geweest die een patch voor PHP heeft gemaakt).

[oh,when?]

- Failover vanuit de PHP scripts blijkt lastig te realiseren omdat de PHP mysql_connect functie geen timeout geeft als een server onbereikbaar is (??). Als de master onbereikbaar is, blijft het connect scriptje doodleuk hangen op de connect in plaats van een timeout te geven zodat geprobeerd kan worden om een (read-only) verbinding te maken met de slave (er is wel iemand geweest die een patch voor PHP heeft gemaakt).

Dat probleem had ik een tijdje geleden ook. Ik heb het gewoon opgelost door eerst een fsockopen te doen naar mijn master database en als deze een time-out geeft naar de slave te connecten. Is dat misschien een idee?

[Verwijderd]

Die 4.5 seconden dat de andere lb het over moet pakken is wel _ERG_ lang...heb betere tijden gezien met een Linux oplossingen waarbij zeker geen PIII's in zaten, maar die 1 ping reply 10ms aangaf, er raakte dus onderweg geeneens data kwijt 4.5 seconden...kan VEEEL beter...

Dit komt omdat interne en externe IP-adressen moeten worden overgenomen, en deze door de werking van de ethernet-standaard niet van het ene op het andere moment kunnen overspringen.

Ik neem aan dat je hier het principe van de ARP cache bedoelt? waarom niet gewoon de MAC adressen overnemen?

Adaptive weighted method: de servers bepalen zelf hoe zwaar ze belast kunnen worden. Dit kan afhankelijk zijn van verschillende factoren zoals hoeveelheid vrije schijfruimte, aantal openstaande verbindingen, beschikbare bandbreedte, hoeveelheid vrij geheugen en gebruik van de CPU.

Kees: staat het scriptje wat je hiervoor gebruikt op de machines ergens online? ben namelijk erg benieuwd wat je eindresultaat geworden is (nav die draad op GoT)

[Kees]

Kees: staat het scriptje wat je hiervoor gebruikt op de machines ergens online? ben namelijk erg benieuwd wat je eindresultaat geworden is (nav die draad op GoT)

Nog niet, ik ga er binnenkort weer mee bezig. Heeft even stilgelegen omdat de loadbalancers nog niet in productie waren. Maar ik ga hem zeker OS maken als je dat leuk vind

Voorlopig zit ik te denken aan een paar variablen die van invloed zijn op de load, en een (groter) aantal "stop" variablen, dus zodra die een bepaalde hoogte bereiken wordt de server niet meer aangesproken.

[Verwijderd]

[quote]De GUICC interface kon geen contact leggen met de B-100 als software en loadbalancer niet in hetzelfde subnet zaten. Ook dit euvel is nu opgelost, waardoor de loadbalancers nu ook van buitenaf beheerd kunnen worden. [quote]

Hmm, is dat niet een beetje link, want wat van buitenaf bestuurd kan worden kan ook van buitenaf gehacked worden!!

[Kees]

daarom accepteerd de loadbalancer alleen connecties van 1 ip dat je op de console moet opgeven. Errug vervelend kan ik je wel vertellen aangezien dat een probleem kan opleveren als je ip veranderd (apart naar a'dam fietsen enzo )

De nieuwe versie, die overigens woensdagocvhtend erop komt zal hier een oplossing voor bieden, hoe, dat moet ik nog zien

[TD-er]

Ik zou jullie aanraden van de gebruikte compact-flash kaartjes een backup te maken in de vorm van een extra kaartje, die dan ter plekke in de machine gestoken kan worden.
Ik weet niet hoe vaak je die dingen kunt lezen, maar het aantal schrijf operaties is zeker eindig (500 - 1000 x)
Ik ben nu zelf ook bezig om een soort van embedded toepassing te maken en overweeg nog steeds om compact-flash te gebruiken ipv. een hdd. Alleen als het echt een kortere levensduur heeft, ga ik toch over op een etherboot-oplossing.

't is maar een suggestie.

[ACM]

Dat is opzich wel een aardige tip, maar als het goed is wordt er zelden of nooit wat naar de CF geschreven

Alleen bij een configuratiewijziging, als het goed is is het wel mogelijk om (via de GUICC, maar of dat nu al kan of bij de volgende versie) een backup van de configuratie te maken.

Ik weet verder niet hoe fijn One4Net het vindt als wij die kaartjes gaan kopieren

[Verwijderd]

Backupje voor eigen gebruik is toch altijd goed?
(en legaal, toch???) Ik heb in ieder geval wel een firmware backup van de meeste apparatuur die hier staat.
In hoeverre is de software in die doos GPL?

[Hielko]

500 - 1000 x is inderdaad een veel te laag getal. Als ik bijv. een datasheet opzoek van een willekeurig flashgeheugen van AMD zie ik staan: "Minimum 100.000 erase cycle quarantee per sector". Dus dat geheugen is echt niet zomaar kapot (data blijft trouwens ook minimaal 20 jaar aanwezig bij een temperatuur van 125 C).

[PanMan]

Dat lijkt me vrij weinig, dan zouden digicams ook een vrij eindig aantal foto's kunnen maken,,,,
Ik geloof je verhaal dus niet helemaal. (wat niet wegneemt dat backups nooit kwaad kunnen! )

[Verwijderd]

Ik zou graag willen weten wat de reden is waarom in de topologie ervoor is gekozen om gebruik te maken van 2 switches. (ik heb het hier niet over de LB's).
namelijk eentje inet<--->www's en www's<--->mysql's.
het is toch veel efficienter als je alles op een grotere snelle switch zet? nu moeten alle data query's over dat ene lijntje van en naar de 2 switches gaan. een bottleneck...

[Femme]

Alle servers hebben twee netwerkkaarten waarvan de eerste aangesloten op switch 1 en de tweede op switch 2. De HTTP requests komen via de eerste switch/netwerkkaart de webservers binnen en gaan ook weer via die switch/netwerkkaart naar buiten. De SQL queries gaan over de tweede switch/netwerkkaart naar de database servers. Als alle servers met 1 netwerkkaart aan 1 switch zouden hangen, zou alle verkeer over 1 switch gaan wat alleen maar trager is. Bovendien heb je dan een enorm groot single point of failure. Als er nu iets fout gaat met een netwerkkaart kunnen we de SQL queries of het HTTP verkeer vrij eenvoudig over de tweede nog werkende netwerkkaart laten lopen.

[basb]

Hmm was eergister toch wel heel blij dat op me werk alle servers sinds aantal weken op twee switches hingen. (twee atm boarden in een atm kast...)

1 van de boarden overleed totaal...

Moet je is bedenken wat er gebeurd was als een serverpark van circa 30 servers niet meer te bereiken is... oeps

Vandaar dat op tweakers en alles wat meer dan een paar servers heeft sowieso alle switches dubbel uitvoerd

[serkoon]

Mooi dat Tweakers.net redundant wordt. Ik vroeg me alleen af wanneer Trueserver aan de beurt is?

[hennink]

Wat bedoel je? Qua netwerkstructuur naar externe netwerken of intern?

[serkoon]

Naar/van 'het internet'

[Floor-is]

TrueServer heeft op dit moment 7 uplinks naar het internet, in de komende week moeten hier nog 3 bijkomen, het lijkt mij dat dat vrij redudant is?

Je doelt misschien op een redundant uplink voor Tweakers naar de coreswitches van TrueServer, ook daar komt binnenkort verandering in.

[serkoon]

Mjah.. 7 lijntjes die allemaal op 1 router samenkomen is nog steeds vrij spoffig.

[Femme]

TrueServer heeft een redundante opstelling van dubbel uitgevoerd backbone routers (Juniper M20) en core-swiches (Extreme Networks Alpine).

[serkoon]

Nooit opgevallen dat bij een probleem op 'de router' de boel plat gaat?

Dat is wel merkwaardig voor een dubbele uitvoering lijkt me zo. Maar goed, niemand heeft het door

Edit: redundantie != cold standby

[Verwijderd]

Ja, maar dat is niet zomaar een routertje, en volgens mij zitten daarin ook nog wel een aantal beveiligingen. (Dubble voedingen? )

[Femme]

Volgens mij is de redundante opstelling nog niet zo lang voor alle klanten in gebruik. Er zijn al een aantal keren router en switch upgrades gedaan zonder merkbare downtime, dus kennelijk doen die dingen hun werk wel.

[Verwijderd]

Wat nou als er een switch uit vliegt

[TimMer]

Dan nemen de andere switches het over. Mag aannemen dat er meerdere switches aan T.net hangen, anders was het niet zo snel hé?

[iNSaNe-oNe]

In het plaatje op de 2e pagina van dit mooie verhaal, kan ik echt toch maar opmaken dat er 2 switches in het geheel hangen. Als nu bijvoorbeeld de onderste op het plaatje eruit knalt, kun je dag zwaaien naar de databaseconnectie. Hoeveel load-balancers er ook met het internet verbonden zijn, die enkele SPOFs (Single Point Of Failure), zijnde de switches die in een niet-redundante opstelling zijn geplaatst, zorgen ervoor dat T.net niet volledig functioneert als er een switch uitknalt.

Jammer, crew! Ook een redundant netwerk-ontwerp verhoogt de availability! Is daar ook al eens naar gekeken?

[Femme]

Op zich moet het niet zo'n probleem zijn om de load balancers ieder op een eigen switch te hangen die ook ieder een eigen uplink hebben naar de core switch van TrueServer. De web- en databaseservers hebben allemaal een verbinding op zowel de eerste als tweede switch. Met wat scriptwerk in PHP zou het mogelijk moeten zijn om de database queries over de juiste switch te sturen als er eentje dood is.

Kees weet vast wel of dit wel of niet mogelijk is?

[Bolk]

Als ik het goed heb kent het T.net serverpark 2 switches

Een zeer interresant stukkie text die al weer heel wat meer duidelijk maakt

Toppie

[buum]

Als je een oplossing met firewalls wilt gaan gebruiken, heb je theoretisch nog vier switches nodig. Foundry heeft hier heel mooi speelgoed voor, waarbij je met bijv. FW-1 (Checkpoint) ertussen een HA-cluster creeert en waarbij de Foundry's zorgen voor de load-balancing. Dat is dan op zowel de firewalls als op de onderliggende infra (webservers, database-servers).

Ziet er ongeveer zo uit:


I-netI-Net
| |
Foundry ---------- Foundry
| |
Firewall Firewall
| |
Foundry ---------- Foundry
| |
\ /
Webservers

edit:
Darn, de lay-out wordt verkl**t

[iNSaNe-oNe]

Zoals op de eerste pagina van deze review wordt vermeld:

De hardwarematige oplossingen van bedrijven als Cisco, BigIP en Foundry Networks hebben als voordeel dat zij snel geïmplementeerd kunnen worden, veel mogelijkheden hebben en gebruiksvriendelijk zijn. Helaas zijn deze loadbalancers erg duur. Denk hierbij aan bedragen van 10.000 tot soms wel 25.000 dollar.

Het lijkt me dus dat hiernaar is gekeken, maar zoals wordt opgemerkt is dat nogal prijzig voor een 'hobbyisten-club' als T.net die het vooral van sponsoring moet hebben.

[buum]

Yep, da's wel waar. Ik zeg echter niet dat het met deze apparatuur zou moeten, het gaat mij om de infra. Dit is een voorbeeld dat ik ken uit de praktijk. Het zou bijvoorbeeld kunnen met de bestaande switches en met twee FreeBSD IPF firewalls.

[Help!!!!]

gaaf hoor! tweakers serverpark wordt steeds professioneler. mooi verhaal. altijd leuk om te lezen over het serverpark. Zeker als je niet zo in de website/server hoek zit leer je ook weer ns wat bij.

keep up the good work!

[Robino]

Ben ik het helemaal mee eens. Zeer interessant artikel om door te lezen. En altijd leuk om te weten wat er achter t.net draait

[Juup]

Laten we hopen dat t.net hiermee wat beter bereikbaar wordt. Ik weet niet waar het aan ligt maar de laatste tij heb ik in 10% van de gevallen geen verbinding met t.net terwijl andere sites gewoon werken.

[Femme]

Dit ligt blijkbaar aan je eigen provider. Ik kan me niet herinneren dat ik de laatste maanden problemen heb gehad om t.net te bereiken. Tijdens de stroomuitval op TeleCity zijn we eventjes uit de lucht geweest, maar verder draait alles voor zover ik weet prima.

[Juup]

Hmmm mijn 'provider' (TU/e) zegt dat het aan de site ligt

[Tjark]

Op dit moment heb ik hetzelfde.
Pingen naar andere sites (in NL en buiten) loopt continue door, maar naar t.net krijg ik af en toe time out's.