Door Arjen van der Meijden

Lead Developer

Loadbalancing bij Tweakers.net

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)

Wijzig sortering
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?
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.
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?
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 :)
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.
3. Replication toch niks geworden?
4. Ik geef geen reply vanwege je antwoord op punt 1 :P
6. Das dus geen loadbalancing :)
Rick, je baalt gewoon dat jij geen beheerder meer bent van al dit moois :P
3. Replication staat uit (volgens mij... ooit eens van Femme gehoord op GoT)
Had Rick niet zelf besloten ermee te kappen ?
(tijdgebrek ?????)
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.
Anoniem: 56116
@Floor-is23 mei 2002 13:12
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.
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).
- 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?
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... :P
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: 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.
Anoniem: 7678
23 mei 2002 18:30
[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!!
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 :)
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.
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 ;)
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?
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).
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! :))
Anoniem: 14762
23 mei 2002 10:03
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... :?
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.
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 :)
Mooi dat Tweakers.net redundant wordt. Ik vroeg me alleen af wanneer Trueserver aan de beurt is?
Wat bedoel je? Qua netwerkstructuur naar externe netwerken of intern?
Naar/van 'het internet'
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. :)
Mjah.. 7 lijntjes die allemaal op 1 router samenkomen is nog steeds vrij spoffig.
TrueServer heeft een redundante opstelling van dubbel uitgevoerd backbone routers (Juniper M20) en core-swiches (Extreme Networks Alpine).
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
Anoniem: 35417
@serkoon26 mei 2002 15:12
Ja, maar dat is niet zomaar een routertje, en volgens mij zitten daarin ook nog wel een aantal beveiligingen. (Dubble voedingen? :? )
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.
Anoniem: 34861
22 mei 2002 21:28
Wat nou als er een switch uit vliegt }>
Dan nemen de andere switches het over. Mag aannemen dat er meerdere switches aan T.net hangen, anders was het niet zo snel hé? :z
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? :)
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?
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
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
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. :)
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.
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! :)
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 :)
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.
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.
Hmmm mijn 'provider' (TU/e) zegt dat het aan de site ligt ;)
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.

Kies score Let op: Beoordeel reacties objectief. De kwaliteit van de argumentatie is leidend voor de beoordeling van een reactie, niet of een mening overeenkomt met die van jou.

Een uitgebreider overzicht van de werking van het moderatiesysteem vind je in de Moderatie FAQ

Rapporteer misbruik van moderaties in Frontpagemoderatie.



Op dit item kan niet meer gereageerd worden.


Nintendo Switch (OLED model) Apple iPhone SE (2022) LG G1 Google Pixel 6 Call of Duty: Vanguard Samsung Galaxy S22 Garmin fēnix 7 Nintendo Switch Lite

Tweakers vormt samen met Hardware Info, AutoTrack, Gaspedaal.nl, Nationale Vacaturebank, Intermediair en Independer DPG Online Services B.V.
Alle rechten voorbehouden © 1998 - 2022 Hosting door True

Tweakers maakt gebruik van cookies

Tweakers plaatst functionele en analytische cookies voor het functioneren van de website en het verbeteren van de website-ervaring. Deze cookies zijn noodzakelijk. Om op Tweakers relevantere advertenties te tonen en om ingesloten content van derden te tonen (bijvoorbeeld video's), vragen we je toestemming. Via ingesloten content kunnen derde partijen diensten leveren en verbeteren, bezoekersstatistieken bijhouden, gepersonaliseerde content tonen, gerichte advertenties tonen en gebruikersprofielen opbouwen. Hiervoor worden apparaatgegevens, IP-adres, geolocatie en surfgedrag vastgelegd.

Meer informatie vind je in ons cookiebeleid.

Sluiten

Toestemming beheren

Hieronder kun je per doeleinde of partij toestemming geven of intrekken. Meer informatie vind je in ons cookiebeleid.

Functioneel en analytisch

Deze cookies zijn noodzakelijk voor het functioneren van de website en het verbeteren van de website-ervaring. Klik op het informatie-icoon voor meer informatie. Meer details

janee

    Relevantere advertenties

    Dit beperkt het aantal keer dat dezelfde advertentie getoond wordt (frequency capping) en maakt het mogelijk om binnen Tweakers contextuele advertenties te tonen op basis van pagina's die je hebt bezocht. Meer details

    Tweakers genereert een willekeurige unieke code als identifier. Deze data wordt niet gedeeld met adverteerders of andere derde partijen en je kunt niet buiten Tweakers gevolgd worden. Indien je bent ingelogd, wordt deze identifier gekoppeld aan je account. Indien je niet bent ingelogd, wordt deze identifier gekoppeld aan je sessie die maximaal 4 maanden actief blijft. Je kunt deze toestemming te allen tijde intrekken.

    Ingesloten content van derden

    Deze cookies kunnen door derde partijen geplaatst worden via ingesloten content. Klik op het informatie-icoon voor meer informatie over de verwerkingsdoeleinden. Meer details

    janee