[Serverpark] netwerk structuur?

[EntonoX]

Hallo allemaal,

Wat?
Ik heb een vraag over wat nu de beste netwerkstructuur is voor ons te realiseren netwerk. Even een korte uitleg:

Doel
Wij willen een serverpark bij een colocatie realiseren. De service die draait op deze servers is een online PHP aplicatie waar gebruiker kunnen inloggen en de applicatie kunnen gebruiken. De gegevens die gebruikt worden in de online applicatie komen uit een MySQL database. De gegevens die in de database worden geplaatst zijn afkomstig van meetstations welke via internet hun gegevens doorgeven. Elk meetstation geeft om de 5 minuten zijn gegevens door via internet aan de MySQL database (dit gebeurt via een PHP script). De hoeveelheid meetstations is nu nog relatief klein (20 stuks) maar kan in de toekomst best vele malen groter worden (500 á 1000 stuks)

Idee?
Zelf had ik het idee om 2 ip adressen te nemen waarbij achter IP1 een load balancer + database server hangt en achter IP2 een load balancer + webserver voor de applicatie. Beide verbonden met een switch zodat de webserver intern de database server kan benaderen. Is dit een goede structuur of zijn er betere/optimalere te verzinnen? ik heb een schetsje gemaakt wat ik precies bedoel.



Tevens bevatten de DB servers en de Webservers hun eigen backup functies.

Vraag
Hoe kan ik het server netwerk het beste opzetten zodat ik het vullen van de database en de gebruiker applicatie gescheiden houdt en dus zorg dat de online applicatie lekker soepel blijft lopen? kan dit ook met 1 IP of is het beter voor de toekomst om direct 2 IP`s te nemen en deze structuur te volgen?

Wie kan mij een beetje in de richting helpen?

[Supermario16]

Misschien stomme vraag, maar je gebruikt nu 2 loadbalancers? Wat heb je hieraan als je per lb maar 1 verbinding hebt? (en er dus geen load te balancen is?)

[Nitroglycerine]

Het idee van een loadbalancer is dat die machine de aanvragen over de machines die erachter liggen kunnen verdelen. Aangezien je in jouw situatie slechts 1 webserver achter iedere loadbalancer wil laten hangen, gaat het idee van load balancing niet op, en zijn ze dus overbodig.

Er vanuit gaande dat beide webservers dezelfde site laten zien, kun je dus het beste het volgende doen:

code:

internet -> loadbalancer -> switch -> webserver 1
                                   -> webserver 2

De mysql servers moeten enkel aanspreekbaar zijn via de webserver, dus indien beide webservers een 2e ethernet aansluiting hebben, zou ik ze daarachter hangen. Echter, als beide database servers dezelfde databases voorzien, dan zou ik slechts 1 db server nemen. Je kunt wel gebruik maken van 2 db servers waarbij je de databases over de servers verspreid (3 hier, 2 daar etc), maar niet dezelfde db's op 2 machines, want dan ga je te maken krijgen met synchronisatie e.d. , en dat levert nogal eens problemen op.

[soulrider]

voer je switch ook minstens dubbel uit.

anders heb je weinig aan je loadbalancers (de switch is single-point of failure en congestion)

met een goed spnning tree protocol voorkom je round-routes.

en full mesh aansluiten.

code:

  Internet
  |        |
  L1      L2
  | \   / |
  |  \ /  |
  |   X   |
  |  / \  |
  | /   \ |
  S1     S2
.....

(L1 & L2 = load balancers, S1 & S2 = switches)
en dan fully meshed verder naar je servers (elke server aan elke switch)

of zoals hier boven al aangeven: dit kan je doortrekken naar je servers, en achter die server een soortgelijke 'meshing' richting je database-servers, heb je zelfs die szitches niet echt meer nodig, enkel heeft dan elke webserver 4 nic's nodig, en elke databse server 2,
nu is het voor elke server 2 nic,s, 1 nic per switch en 1 siwtch/loadbalancer
(met 3 loadbalancers -> 2 of 3 switches)

ps met 2 ip-connectie's zou je tussen je internet-connectie's en loadbalancers switchen/routers moeten zetten
met als resultaat ->
redundant internet --(bundeling van aanvragen mbv routers/switches)----> redundante loadbalancers ---(switches)---> redundante servers
maar dit is van toepassing als je echt veel trafiek verwacht en downtime nefast is voor je toepassing.

op't net zijn er zo verschillende constructie's vindbaar met elk hun eigen voor en nadelen
(hoe verder men gaat hoe duurder en vaak ook overkill het wordt)

[ Voor 57% gewijzigd door soulrider op 09-02-2007 12:57 ]

[CyBeR]

De constructie nu is een beetje vreemd. De enige reden om twee load balancers te gebruiken is redundancy, want een enkele load balancer kan dit ook prima aan. Als je voor redundancy gaat is je switch dubbel uitvoeren ook geen slecht idee. Congestion is met goede kwaliteit switches tegenwoordig geen probleem meer, die switchen alles gewoon wirespeed.

Bovendien: werkt je app nu al met twee database servers? Want dat voor elkaar krijgen is nog lastiger dan je zou denken, zeker in een load-balanced opstelling.

[EntonoX]

CyBeR schreef op vrijdag 09 februari 2007 @ 12:41:
De constructie nu is een beetje vreemd. De enige reden om twee load balancers te gebruiken is redundancy, want een enkele load balancer kan dit ook prima aan. Als je voor redundancy gaat is je switch dubbel uitvoeren ook geen slecht idee. Congestion is met goede kwaliteit switches tegenwoordig geen probleem meer, die switchen alles gewoon wirespeed.

Bovendien: werkt je app nu al met twee database servers? Want dat voor elkaar krijgen is nog lastiger dan je zou denken, zeker in een load-balanced opstelling.

Het is ook nog maar een schets en idee. De hardware moet allemaal nog aangeschaft worden dus er is op dit moment nog niets aanwezig voor de nieuwe situatie

Waar het mij om gaat is dat ik straks veel dataverkeer krijg wat alleen bedoeld is voor de database. En om ervoor te zorgen dat de online applicatie een goede snelheid blijft houden dacht ik om het verkeer op te splitsen in twee verbindingen. één verbinding voor al het verkeer naar de database en één verbinding voor de online applicatie naar gebruiker en vice versa.

[Arno]

Zet je tweede LB ook in als WS, dan heb je er daar drie van, dan is de standby LB ook nog eens nuttig

Ik heb samen met BOOTZ vorig jaar een vergelijkbaar systeem opgezet met twee LB's (waarvan een standby), twee WS's en twee DB/file servers

[EntonoX]

Arno schreef op vrijdag 09 februari 2007 @ 13:28:
Zet je tweede LB ook in als WS, dan heb je er daar drie van, dan is de standby LB ook nog eens nuttig

Ik heb samen met BOOTZ vorig jaar een vergelijkbaar systeem opgezet met twee LB's (waarvan een standby), twee WS's en twee DB/file servers

Ah. ok. dat is inderdaad een idee. Maar mijn meeste zorg is eigenlijk het dataverkeer naar de database server. Omdat ik dus geen gebruikers gegevens laat aanvullen maar dit automatisch gebeurt dus veel dataverkeer.

[CyBeR]

EntonoX schreef op vrijdag 09 februari 2007 @ 13:21:
[...]


Het is ook nog maar een schets en idee. De hardware moet allemaal nog aangeschaft worden dus er is op dit moment nog niets aanwezig voor de nieuwe situatie

Waar het mij om gaat is dat ik straks veel dataverkeer krijg wat alleen bedoeld is voor de database. En om ervoor te zorgen dat de online applicatie een goede snelheid blijft houden dacht ik om het verkeer op te splitsen in twee verbindingen. één verbinding voor al het verkeer naar de database en één verbinding voor de online applicatie naar gebruiker en vice versa.

Mja, maar tenzij je een nieuwe flickr.com aan het bouwen bent gaat je load balancer niet onder de indruk zijn van het verkeer Het enige wat een load balancer doet is packets doorsturen, dat kunnen ze zonder al te veel moeite op gigabit-snelheid.

Twee load balancers is prima, maar zorg dan dat 't een redundant setup is en niet een setup waarbij de helft uit kan vallen en dat je dan belangrijke functionaliteit kwijt bent.

[4VAlien]

EntonoX schreef op vrijdag 09 februari 2007 @ 13:21:
[...]


Het is ook nog maar een schets en idee. De hardware moet allemaal nog aangeschaft worden dus er is op dit moment nog niets aanwezig voor de nieuwe situatie

Waar het mij om gaat is dat ik straks veel dataverkeer krijg wat alleen bedoeld is voor de database. En om ervoor te zorgen dat de online applicatie een goede snelheid blijft houden dacht ik om het verkeer op te splitsen in twee verbindingen. één verbinding voor al het verkeer naar de database en één verbinding voor de online applicatie naar gebruiker en vice versa.

Met 1000 meetstations en updates per 5 minuten heb je 3,3 updates per seconde, zijn die updates inderdaad zo groot dat dit je vermoedelijk een hele lijn gaat kosten? Als het inderdaad blokken data van meer dan 1MB zijn dan zou ik me meer zorgen maken om opslagcapaciteit

[EntonoX]

4VAlien schreef op vrijdag 09 februari 2007 @ 13:40:
[...]


Met 1000 meetstations en updates per 5 minuten heb je 3,3 updates per seconde, zijn die updates inderdaad zo groot dat dit je vermoedelijk een hele lijn gaat kosten? Als het inderdaad blokken data van meer dan 1MB zijn dan zou ik me meer zorgen maken om opslagcapaciteit

Updates zijn niet groot, ik schat zo`n 2Kb aan data per update maximaal. Probleem is dat in worst case zo`n 1000 meetstations tegelijk proberen hun data te verzenden en dan wordt het een beetje druk op de lijn. In dat geval ga je dus vertraging krijgen en die vertraging wil ik niet of nauwelijks merken in mn online applicatie.

De database servers wil ik wel voldoende opslag capaciteit geven dus dat is niet echt een probleem.

[4VAlien]

1000 simultane requests houden de database wel even bezig, de vertraging komt dan niet eens zozeer door je verbinding alswel door de SQL server die het even druk heeft, 1000*2KB kan wel in een seconde door je aansluiting heen neem ik aan.

[EntonoX]

4VAlien schreef op vrijdag 09 februari 2007 @ 14:01:
1000 simultane requests houden de database wel even bezig, de vertraging komt dan niet eens zozeer door je verbinding alswel door de SQL server die het even druk heeft, 1000*2KB kan wel in een seconde door je aansluiting heen neem ik aan.

Dat moet wel lukken, Maar is het verstandig om dit dan via één verbinding te doen? de webserver krijgt dan de taak om de applicatie te draaien en de taak om de database te vullen wanneer een meetstation zijn data verzend. Dit allemaal via één lijn. Ik weet niet of je dan wat gaat merken in snelheid van de applicatie?

[GSteven]

In mijn ogen wordt het probleem wat te complex aanzien. Mijn eerste idee gaat er van uit dat de webserver/applicatieserver enkel SELECT's uitvoert op die ene database. Ik zou echter gaan opteren om MySQL ook op de webserver te installeren en de "originele" databaseserver te gaan repliceren. Repliceren via een intern netwerk dan wel te verstaan.

Via één internet aansluiting laat je de databasesever vullen. Intern zal hij gaan repliceren naar de webserver. De webserver voert enkel SELECT statements uit op zichzelf. De gebruikers loggen in via internetlijn 2.

Op deze manier wordt het verkeer toch heel wat verspreid? Of denk ik als amateur in de verkeerde richting?

[CyBeR]

EntonoX schreef op vrijdag 09 februari 2007 @ 14:15:
[...]


Dat moet wel lukken, Maar is het verstandig om dit dan via één verbinding te doen? de webserver krijgt dan de taak om de applicatie te draaien en de taak om de database te vullen wanneer een meetstation zijn data verzend. Dit allemaal via één lijn. Ik weet niet of je dan wat gaat merken in snelheid van de applicatie?

Wel, je had 't over een colocated server. Ik denk dat je je om de snelheid van de lijn niet heel snel zorgen hoeft te maken. De betere coloboeren geven je tegenwoordig als je een rack huurt een gigabit lijn, en als je in shared colo zit heb je ook 100mbit tot je beschikking. Eer dat vol zit ben je wel een paar andere schaalproblemen verder.

[EntonoX]

CyBeR schreef op vrijdag 09 februari 2007 @ 14:54:
[...]


Wel, je had 't over een colocated server. Ik denk dat je je om de snelheid van de lijn niet heel snel zorgen hoeft te maken. De betere coloboeren geven je tegenwoordig als je een rack huurt een gigabit lijn, en als je in shared colo zit heb je ook 100mbit tot je beschikking. Eer dat vol zit ben je wel een paar andere schaalproblemen verder.

dat is waar. Dus het beste is dan om voorloppig voor één lijn te gaan met daarachter een webserver en database server apart. eventueel met meerdere webservers icm loadbalancing?

[CyBeR]

Juist.

En nogmaals, ik weet niet in hoeverre je app nu al rekening houdt met load balanced webservers en databases, maar daar zitten ook nog wat punten in om rekening mee te houden. Bijvoorbeeld je PHP sessies. Als je dat verkeerd doet krijg je de situatie dat als je inlogt op de ene server, dat de volgende request bij de andere server uitkomt en dat die geen idee heeft van dat je ingelogd was.

Idem database: het meest robuuste qua syncen is een master/slave gebeuren. Maar dan moet je dus zorgen dat je alleen naar je master schrijft en alle reads verdeelt over de beide servers. Als je je db echt wilt load balancen moet je dus twee kanten uit syncen, en daar zitten ook weer wat haken en ogen aan, zoals autogenerated ID's die dan opeens op beide servers tegelijk aangemaakt kunnen worden en dan dus een conflict opleveren.

't is allemaal te overkomen hoor, maar je moet er wel goed over nadenken

[Verwijderd]

Voor de DB servers denk ik dat het verstandig is om elk meetpunt zijn data naar beide databaseservers te laten sturen. Op deze manier creëer je niet heel veel wel meer dataverkeer (18 GB per maand per DBserver bij 1000 meetpunten, 2KB per update, elke 5 minuten updaten), maar je hebt wel redundantie. Via de andere netwerkpoorten in je DB servers kunnen de webservers dan weer de informatie opvragen en naar de gebruiker sturen. (loadbalancing over de DB servers én de webservers?).

[ Voor 68% gewijzigd door Verwijderd op 09-02-2007 15:26 ]

[EntonoX]

CyBeR schreef op vrijdag 09 februari 2007 @ 15:03:
Juist.

En nogmaals, ik weet niet in hoeverre je app nu al rekening houdt met load balanced webservers en databases, maar daar zitten ook nog wat punten in om rekening mee te houden. Bijvoorbeeld je PHP sessies. Als je dat verkeerd doet krijg je de situatie dat als je inlogt op de ene server, dat de volgende request bij de andere server uitkomt en dat die geen idee heeft van dat je ingelogd was.

Idem database: het meest robuuste qua syncen is een master/slave gebeuren. Maar dan moet je dus zorgen dat je alleen naar je master schrijft en alle reads verdeelt over de beide servers. Als je je db echt wilt load balancen moet je dus twee kanten uit syncen, en daar zitten ook weer wat haken en ogen aan, zoals autogenerated ID's die dan opeens op beide servers tegelijk aangemaakt kunnen worden en dan dus een conflict opleveren.

't is allemaal te overkomen hoor, maar je moet er wel goed over nadenken

De applicatie gebruikt (nog) geen sessie`s. Dit omdat het loginsysteem gebaseerd is in combinatie met mysql, ook de informatie die de gebruiker nodig heeft komt allemaal uit de sql database. Enige informatie die doorgegeven wordt gebeurd via POST. Dus vrij standaard allemaal.

Misschien is het verstanding om als eerste gewoon alleen de webservers te load balancen en met één enkele database server te werken in het begin. Uitbreiden naar meerdere database servers is altijd mogelijk denk ik?

[Verwijderd]

EntonoX schreef op vrijdag 09 februari 2007 @ 15:52:
[...]


De applicatie gebruikt (nog) geen sessie`s. Dit omdat het loginsysteem gebaseerd is in combinatie met mysql, ook de informatie die de gebruiker nodig heeft komt allemaal uit de sql database. Enige informatie die doorgegeven wordt gebeurd via POST. Dus vrij standaard allemaal.

Misschien is het verstanding om als eerste gewoon alleen de webservers te load balancen en met één enkele database server te werken in het begin. Uitbreiden naar meerdere database servers is altijd mogelijk denk ik?

Misschien is het handig om achter elke webserver een database server te hangen (beide met meerdere lan poorten) en dan dus elk meetpunt zijn info te laten versturen naar beide DB servers (wat ik al zei in m'n vorige post). De gebruikers laat je dan loadbalancen over de webservers...

[squaddie]

Ik kan het mis hebben, maar het lijkt erop dat te snel en te veel in oplossingen wordt gedacht. Daar ben ik zelf ook een aantal malen mee op mn plaat gegaan en in mijn opinie is dit een zeer typische valkuil voor een ICTer. Ik ben natuurlijk niet betrokken bij het project, maar zijn de eisen danwel wensen al vastgelegd waaraan dit project moet gaan voldoen? Hierop lopen zoveel projecten in het honderd, omdat iedereen een andere oplossing in gedachte heeft.
Ik noem een paar die zo maar even bij me opkomen:
- Aan wat voor uptime moet worden gedacht, zowel de databasekant als de gebruikerskant? Best effort, 90%, 99% en als een storing is hoe lang een onderdeel platliggen, het maakt een redelijk verschil in oplossing en bijbehorende kostenplaatje.
- Als de meetstations hun meetgegevens niet kunnen afleveren, gaan ze verloren of worden ze alsnog verzonden als database weer bereikbaar is.
- Wat zijn de performance eisen?
- Hoeveel gebruikers gaan tegelijk gebruik maken van dit systeem en wat is (verwachtte) gemiddelde belasting op het systeem per gebruiker.
- Hangt een beetje samen met de vorige vraag, maar wat de is databasebelasting, specifiek verhouding soort queries. Hebben we het over 80% selects en 20% inserts, etc.
- Ik heb de laatste ontwikkelingen van mysql niet helemaal gevolgd, maar mysql kan zo ver ik weet niet omgaan met twee "master" servers die inserts doen op een en dezelfde tabel. Dat houdt wel in dat je geen loadbalancing kan doen op je DB-servers met loadbalancers.

Op basis van de huidige gevens vind ik het erg lastig een goede oplossing te geven, 50.000 euro kapot gooien kan iedereen, maar het is natuurlijk een beetje zonde als 10.000 euro voldoende was geweest.

Om toch een idee te geven zou ik gaan voor de opstelling van soulrider, waarbij via LB1 de gegevens van meetstations binnenkomen en via LB2 de gebruikers, bij een storing kan je vrij makkelijk schakelen en in de normale situatie zitten beide groepen verkeer elkaar niet in de weg. Verder zou ik een master-slave database constructie bouwen, waarbij de master de inserts, etc doet en de slave de selects. Dan zijn beide groepen weer gescheiden van elkaar en bij een storing kan je afhankelijk van je structuur vrij snel overschakelen/bouwen naar de andere server. En daarnaast een aantal webservers afhankelijk van de belasting.

[EntonoX]

squaddie schreef op vrijdag 09 februari 2007 @ 16:35:
Ik kan het mis hebben, maar het lijkt erop dat te snel en te veel in oplossingen wordt gedacht. Daar ben ik zelf ook een aantal malen mee op mn plaat gegaan en in mijn opinie is dit een zeer typische valkuil voor een ICTer. Ik ben natuurlijk niet betrokken bij het project, maar zijn de eisen danwel wensen al vastgelegd waaraan dit project moet gaan voldoen? Hierop lopen zoveel projecten in het honderd, omdat iedereen een andere oplossing in gedachte heeft.
Ik noem een paar die zo maar even bij me opkomen:
- Aan wat voor uptime moet worden gedacht, zowel de databasekant als de gebruikerskant? Best effort, 90%, 99% en als een storing is hoe lang een onderdeel platliggen, het maakt een redelijk verschil in oplossing en bijbehorende kostenplaatje.
- Als de meetstations hun meetgegevens niet kunnen afleveren, gaan ze verloren of worden ze alsnog verzonden als database weer bereikbaar is.
- Wat zijn de performance eisen?
- Hoeveel gebruikers gaan tegelijk gebruik maken van dit systeem en wat is (verwachtte) gemiddelde belasting op het systeem per gebruiker.
- Hangt een beetje samen met de vorige vraag, maar wat de is databasebelasting, specifiek verhouding soort queries. Hebben we het over 80% selects en 20% inserts, etc.
- Ik heb de laatste ontwikkelingen van mysql niet helemaal gevolgd, maar mysql kan zo ver ik weet niet omgaan met twee "master" servers die inserts doen op een en dezelfde tabel. Dat houdt wel in dat je geen loadbalancing kan doen op je DB-servers met loadbalancers.

Op basis van de huidige gevens vind ik het erg lastig een goede oplossing te geven, 50.000 euro kapot gooien kan iedereen, maar het is natuurlijk een beetje zonde als 10.000 euro voldoende was geweest.

Om toch een idee te geven zou ik gaan voor de opstelling van soulrider, waarbij via LB1 de gegevens van meetstations binnenkomen en via LB2 de gebruikers, bij een storing kan je vrij makkelijk schakelen en in de normale situatie zitten beide groepen verkeer elkaar niet in de weg. Verder zou ik een master-slave database constructie bouwen, waarbij de master de inserts, etc doet en de slave de selects. Dan zijn beide groepen weer gescheiden van elkaar en bij een storing kan je afhankelijk van je structuur vrij snel overschakelen/bouwen naar de andere server. En daarnaast een aantal webservers afhankelijk van de belasting.

Hier heb je helemaal gelijk in, top!

Omdat er nu nog weinig is gerealiseerd mbt. het serverpark zijn de eisen ook globaal vastgesteld, maar deze worden zeker uitgewerkt en op papier gezet zodat echt duidelijk is wat de functionele eisen worden van het serverpark.
Tevens ben ik het met je eens over de verdeling van het verkeer zoals eerder is aangegeven door soulrider, waarschijnlijk gaat het dan ook zoiets worden. Het gescheiden houden van de groepen spreekt mij ook wel erg aan en is ook het overzichtelijkst denk ik.

Alvast bedankt voor jullie meedenken!

[CyBeR]

squaddie schreef op vrijdag 09 februari 2007 @ 16:35:
- Ik heb de laatste ontwikkelingen van mysql niet helemaal gevolgd, maar mysql kan zo ver ik weet niet omgaan met twee "master" servers die inserts doen op een en dezelfde tabel. Dat houdt wel in dat je geen loadbalancing kan doen op je DB-servers met loadbalancers.

Dat kan wel tegenwoordig. Beide db's zijn dan zowel master als slave. Maar zoals ik al zei heb je dan dus de mogelijkheid dat je dezelfde keys tegelijk genereert op twee verschillende database servers. Daar moet je voor uitkijken.

[Arno]

Ik heb niet al te beste ervaring met MySQL replicatie, ging behoorlijk stuk

[EntonoX]

Ok, mensen even een update.

We zijn nu de eisen aan het opstellen en hebben al in grote lijnen bepaald wat er gevraagd wordt van het netwerk:

we hebben 2 soorten request;
1) de klant request welke verbinding maakt met de website voor het gebruik van de online applicatie;
2) de request van de meetstations.

Onder request wordt verstaan het ophalen van een pagina of afhandelen van een php script.

we hebben het één en andere berekend en komen op de volgende cijfers uit;
1) applicatie request ~ 19.200 pageviews/dag (voornamelijk html/php/sql)
2) meetstation request ~ 480.000 pageviews / dag (voornamelijk 2 php scripts)

De verhouding tussen het dataverkeer wat gegenereerd wordt ligt op 50% / 50% (meetstation request / applicatie request). Dit komt omdat de appliactie request meestal groter zijn dan de meetstation requests terwijl er toch meer meetstation request zijn. Uiteraard zijn deze gegevens berekend in het "worst-case scenario".

Nu hadden wij de volgende netweropzet in gedachten (mede dankzij jullie ideeen)



Vraag
1) Is deze netwerkopzet juist? we streven naar goede redundantie en kunnen eigenlijk geen downtime gebruiken.

2) Dit is meer een beheerders vraag. Op dit moment beheren we de website voornamelijk met phpadmin en webmin. Mijn vraag is of dit ook mogelijk is in dit netwerk? wat is het meest voor de hand liggend om te gebruiken voor het onderhouden van de loadbalancers/webservers/mysql server?
Ik wil alles eigenlijk op afstand kunnen beheren.

Alvast bedankt voor jullie tips!

[Bl@ckbird]

De router / internetlijnen is een single point of failure.

Waar je ook naar kunt kijken is naar meerdere regionale databases en één main-database.
- De meetstations sturen hun data naar de regionale database. (bursty netwerkverkeer)
- De regionale databases sturen hun data naar de hoofd-database. (grote chunks data)

[EntonoX]

Bl@ckbird schreef op zondag 25 februari 2007 @ 22:10:
De router / internetlijnen is een single point of failure.

Waar je ook naar kunt kijken is naar meerdere regionale databases en één main-database.
- De meetstations sturen hun data naar de regionale database. (bursty netwerkverkeer)
- De regionale databases sturen hun data naar de hoofd-database. (grote chunks data)

Dat klopt wat je zegt van de router, daar moeten we nog even naar kijken. Tevens is deze hele opzet nog allemaal theoretisch.

Wat bedoel je met regionale databases? dat we twee aparte databaseservers maken, één voor de normale applicatie data en één voor de meetstation data?

[Bl@ckbird]

Als je veel bursty verkeer verwacht van een groot aantal meetstations, dan kun je dit verdelen over een aantal databases.

1000 Meetstations loggen naar 3 "regionale" databases.
Deze 3 databases loggen hun data naar een hoofd-database die de applicatie bedient.

De regionale databases wil je enigszins dicht bij de meetstations plaatsen.
(Vanwege de hoeveelheid dataverkeer.)
Het verkeer tussen de regionale database en de hoofd database bestaat uit grote brokken info, welke makkelijk te comprimeren is. Je kunt ook spelen met de tijdsintervallen. Meetstations kunnen zeer regelmatig hun updates versturen, terwijl je de tijdsintervallen tussen de databases wat ruimer neemt.

Of je een distributed model wil toepassen, ligt aan hoe schaalbaar je dit wil maken.
En als je een distributed model wil toepassen, kun je met een enkele database beginnen, maar in je ontwerp moet je er wel rekening meer houden, dat je kunt opschalen naar meerdere databases.

Voorbeeld:
Bovenstaand idee heb ik van een software pakket voor netwerkmanagement.
Zie deze PDF, pagina 2.

In dit voorbeeld loggen netwerkdevices naar een syslog server. Deze info wordt daarna opgeslagen in een SQL database. Deze synchroniseert vervolgens met de hoofd database. Per vestiging wordt er bijvoorbeeld een regionale database geplaatst, om netwerkmanagement verkeer af te vangen van die specifieke vestiging. De regionale database is mbv. een encrypte VPN verbinding gekoppeld met de hoofdlokatie, waar zich de hoofd database bevindt.

Dit softwarepakket mag je vergeten, maar de architectuur is ongeveer hetzelfde.

[Verwijderd]

je zegt dat er rond de 1000 meetstations elke 5 minuten een 2kb http-post sturen. deze wordt middels een insert in een mysql database gestopt. je kunt aan de meetstations zelf niks veranderen of in iedergeval is dat niet wenselijk.

maar krijg je dan niet elke 5 minuten een burst van request en dan weer 4 minuten niks? worden de meetstations ge-sychoniseerd op tijd? of loopt de 1 een paar seconden voor en de andere een paar seconden achter?.

mischien is het een idee om alle meetstations op de database server te laten uitkomen en de gebruikers naar de webserver te sturen. de bottleneck zal niet de 12000 http-post request per uur die je krijgt zijn maar eerdere het probleem dat ze in burst om de 5 minuten komen. een oude P3 kan nog makkelijk 12000 page-views per uur aan oftewel 200 per minuut maar geen 1000 per minuut.

ik neem aan dat de meetstations niet direct een reply verwachten, mischien kun je dit in php oplossen door het script nadat deze de informatie heeft ontvangen eerste een tijdje te laten sleepen en dan pas de werkelijke insert richting de database te sturen.

voorbeeldje:

PHP:

 $data = $_POST["data"];
 
 set_time_limit(300);
 sleep(rand(30, 240));
 
  //mysql stuff hier, insert $data en dump $data als het niet lukt.

dit zorgt er voor dat het script eerst slaapt tot ergens tussen de 30seconden en de 4 minuuten voordat het contact opneemt met de database en de werkelijke insert doet. op deze manier zou zelfs een oude P3 nog de informatie van 1000 meetstations op kunnen nemen. je moet alleen dan wel apache instellen met veel child spawns zodat deze de 1000 inkomende http-post request kunnen opnemen. en je zult voldoende geheugen moeten hebben.

ook kun je goed gebruik maken van mysql_pconnect zodat de php-scripts de verbinding met elkaar delen zodat dus het aantal connecties richten de mysql-backend gelijk is aan het aantal apache child spawns en niet het aantal php scripts.

stel dus dat je apache instelt met 20 child spawns. dan worden de 1000 request verdeelt over die 20 oftewel 50 request per child. die 50 childs delen dan dus 1 connectie met de mysql database en daarover worden dan dus 50 inserts verstuurd ergens tussen de 30seconden tot 4 minuten na de eerste http request binnenkwam. de database wordt zo niet overspoeld en hoef je je dus al niet meer druk te maken en moeilijk gaan doen met loadbalancers etc.

ook zag ik in je nieuwe grafiek dat je nog altijd 2 ips gebruikt. ook dit is erg onnodig tenzij je de ene voor de meet sations wil gebruiken en de andere voor de website. ook over de bandwijdte hoef je je niet druk te maken. colo's leveren niet meer lager dan 100mbit en je zult aardig je best moeten doen om dat vol te krijgen.

dus ik zou de inkomende http-request van de meetstations scheiden van de website. omdat deze voorspelbaar en aan andere eisen voldoet dan de website. evt zou je dan de andere database server als slave kunnen opstellen en de website laten connecten naar de slave terwijl de meetstations hun output elke 5 minuten naar de webserver op de database machine sturen. je kunt dan je webserver machine inrichten voor bezoekers van de website en daar kan een loadbalancer mischien nog een uitkomst bieden maar voor die 1000 meetstations met hun 2kb http-post request is dat gewoon overkill.

[EntonoX]

@Blackbird:

Het is inderdaad een idee om de twee database zo te scheiden. Merendeel van het database verkeer is het verkeer van de meetstations.

Verwijderd schreef op maandag 26 februari 2007 @ 01:00:
je zegt dat er rond de 1000 meetstations elke 5 minuten een 2kb http-post sturen. deze wordt middels een insert in een mysql database gestopt. je kunt aan de meetstations zelf niks veranderen of in iedergeval is dat niet wenselijk.

Ja dat klopt.

maar krijg je dan niet elke 5 minuten een burst van request en dan weer 4 minuten niks? worden de meetstations ge-sychoniseerd op tijd? of loopt de 1 een paar seconden voor en de andere een paar seconden achter?.

De meetstations worden geinstalleerd in het veld en zullen eigenlijk nooit tegelijk hun data gaan versturen. Zodra het meetstation geinstalleerd wordt gaat de software 5 minuten meetgegevens verzamelen en daarna versturen. Je zult dus gewoon verspreid dataverkeer gaan krijgen en niet echt bursts aan grote datahoeveelheden. MAAR ik ben uitgegaan van een worst-case geval, zodat ik wel weet dat de servers het aan kunnen.

mischien is het een idee om alle meetstations op de database server te laten uitkomen en de gebruikers naar de webserver te sturen. de bottleneck zal niet de 12000 http-post request per uur die je krijgt zijn maar eerdere het probleem dat ze in burst om de 5 minuten komen. een oude P3 kan nog makkelijk 12000 page-views per uur aan oftewel 200 per minuut maar geen 1000 per minuut.

Dat is inderdaad een idee waar ik zelf ook al over had nagedacht.

ik neem aan dat de meetstations niet direct een reply verwachten, mischien kun je dit in php oplossen door het script nadat deze de informatie heeft ontvangen eerste een tijdje te laten sleepen en dan pas de werkelijke insert richting de database te sturen.
dit zorgt er voor dat het script eerst slaapt tot ergens tussen de 30seconden en de 4 minuuten voordat het contact opneemt met de database en de werkelijke insert doet. op deze manier zou zelfs een oude P3 nog de informatie van 1000 meetstations op kunnen nemen. je moet alleen dan wel apache instellen met veel child spawns zodat deze de 1000 inkomende http-post request kunnen opnemen. en je zult voldoende geheugen moeten hebben.

De meetstations krijgen wel een reply terug, ze sturen hun data naar het script en vervolgens doet het script een aantal controle`s (ook mysql selects) en wordt de data weggeschreven in de database. Vervolgens wordt een melding teruggegeven met een aantal instellingen voor het meetstation. Overigens is dit dataverkeer ook weer enkele bytes.

ook kun je goed gebruik maken van mysql_pconnect zodat de php-scripts de verbinding met elkaar delen zodat dus het aantal connecties richten de mysql-backend gelijk is aan het aantal apache child spawns en niet het aantal php scripts.

stel dus dat je apache instelt met 20 child spawns. dan worden de 1000 request verdeelt over die 20 oftewel 50 request per child. die 50 childs delen dan dus 1 connectie met de mysql database en daarover worden dan dus 50 inserts verstuurd ergens tussen de 30seconden tot 4 minuten na de eerste http request binnenkwam. de database wordt zo niet overspoeld en hoef je je dus al niet meer druk te maken en moeilijk gaan doen met loadbalancers etc.

Dat klinkt interessant! ik gebruik nu de normale mysql_connect. Ik zal zo gelijk even de pconnect opzoeken. Goede tip!

ook zag ik in je nieuwe grafiek dat je nog altijd 2 ips gebruikt. ook dit is erg onnodig tenzij je de ene voor de meet sations wil gebruiken en de andere voor de website. ook over de bandwijdte hoef je je niet druk te maken. colo's leveren niet meer lager dan 100mbit en je zult aardig je best moeten doen om dat vol te krijgen.

dus ik zou de inkomende http-request van de meetstations scheiden van de website. omdat deze voorspelbaar en aan andere eisen voldoet dan de website. evt zou je dan de andere database server als slave kunnen opstellen en de website laten connecten naar de slave terwijl de meetstations hun output elke 5 minuten naar de webserver op de database machine sturen. je kunt dan je webserver machine inrichten voor bezoekers van de website en daar kan een loadbalancer mischien nog een uitkomst bieden maar voor die 1000 meetstations met hun 2kb http-post request is dat gewoon overkill.

Dus jouw voorstel is om één Ip verbinding te maken. Maar hoe kan ik het verkeer dan zo optimaal mogelijk scheiden tussen de website request en de meetstation request? Beide komen binnen op één IP en zul je dus moeten scheiden door middel van een loadbalancer of router/switch?

[Verwijderd]

oke, het is dus wel een gelijdelijk patroon. dan kan die random sleep er ook wel uit.

let wel op dat je met pconnect dus de verbinding deelt. dit kan een security probleem zijn waarbij scripts wachtwoorden van elkaar kunnen lezen via sql-query history etc. maar dat is hier geen probleem.

ook snap ik niet wat je bedoelt met dat je maar 1 ip hebt? elke machine in je colo krijgt een internet ip-addres wat direct opvraagbaar is van buiten de colo. ik neem aan dat je geen NAT wil gaan doen in je router waar ik ook het nut niet van zie omdat het om een handje computers gaat. switches zijn wel handig i.v.m intern dataverkeer tussen master/slave database machine etc.

stel je hebt 5 machines:
1) master database machine = 207.208.209.51 db1.eenwebsite.nl
2) slave databse machine = 207.208.209.52 db2.eenwebsite.nl
3) load balancer = 207.208.209.53 www.eenwebsite.nl
4) webserver = 207.208.209.54 web1.eenwebsite.nl
5) webserver = 207.208.209.55 web2.eenwebsite.nl

de meetstations sturen hun http-post data naar db1.eenwebsite.nl. de bezoekers van de website gaan naar www.eenwebsite.nl waar de load-balancer hun doorverbindt naar web1.eenwebsite.nl of web2.eenwebsite.nl of later als het nodig mocht blijken web3.eenwebsite.nl of web4.eenwebsite.nl etc.

de website verbindt vervolgens naar db2.eenwebsite.nl waar een replica mysql server draait welke om de zoveel tijd zich synchroniseerd met de master op db1.eenwebsite.nl. zodoende zal bijvoorbeeld bij een overload op de website alleen db2.eenwebsite.nl neergaan en blijven de meetstations updaten naar db1.eenwebsite.nl. zodra db2.eenwebsite.nl het weer doet is deze meteen weer up-to-date.

ook moet je je afvragen hoe groot de werkelijke bezoekers aantallen zijn? als dit niet zo hoog ligt zou je zelfs de replica mysql-server en website op 1 machine kunnen draaien en dan is die load-balancer ook niet meer nodig. je kunt dan later altijd nog makkelijk uitbereiden door eerst de mysql-server naar een aparte machine te plaatsen en als dat nog niet helpt kun je een 2e webserver er bijhangen met load-balancer. door een goeie dns in te zetten kun je dit bijna geheel transpant doen en dat is wel zo kost efficient.

ook vraag ik me af of die 19.200 pageviews per dag wel klopt. dat is ongeveer 0.88 pageview per seconden uit gaan van 6uur effectief. een enkele webserver met replica-mysql server op de zelfde machine haalt dat nog wel. zeker als je een beetje stevig beestje koopt. dual dual-core opteron zou makkelijk 4-10 pageviews per seconden doen. waarschijnlijk nog wel meer.

mijn advies zou zijn om met 2 servers te beginnen. een wat simpelere master server waar de meetstations op uitkomen en een wat stevigere webserver waar de bezoekers op uitkomen. en dan gewoon schalen met het aantal bezoekers want de configuratie die ik hierboven noem met 5 aparte machines doet makkelijk 50.000 pageviews en daar kom jij nog niet eens bij in de buurt. kijk maar op wat voor hardware tweakers draait en die doen 220.000 pageviews per dag.

[ Voor 2% gewijzigd door Equator op 02-03-2007 09:10 ]

[EntonoX]

@Docey:

dank voor de duidelijke info! mijn ervaring met colocatie gaat tot nu toe maar tot enkele servers, dus vandaar dat ik ook nog het een en ander moet leren hierover. Maar je uitleg is duidelijk. Het idee van loadbalancing spreekt mij wel aan mede vanwege toekomstige uitbreidbaarheid en de zekerheid bij uitval van een webserver

Ik heb net even de Colo-boer benaderd en standaard krijg ik 1 switchpoort en 20 IP adressen waarbij zelf een eigen switch dien op te hangen. Hoe zou jou opzet er dgrafisch uitzien? misschien dat je een schetsje kunt maken voor me? dan ben ik helemaal gelukkig!

[ Voor 13% gewijzigd door EntonoX op 26-02-2007 14:05 ]

[Verwijderd]

ik heb even een Visio drawing gemaakt van het verhaal hierboven. inclusief de 3 verschillende uitbereidings stappen, welke machine welke ip en welke dns krijgt en een voorbeeldje van de hardware waar je aan zou kunnen gaan denken.

rapidshare zipje: http://rapidshare.com/files/18505370/EntonoX.zip.html

ik heb er ook de png printjes bij gestopt mocht je geen visio2002 hebben anders kun je visio speler van de microsoft website downloaden om het bestand te bekijken.

[EntonoX]

*Oops te laat

Ik heb zelf ook even een globaal tekeningetje gemaakt.



Bedoel je deze opzet Docey? (ja dus) De aanvragen van de website worden doorgestuurd naar de loadbalancer welke deze verdeeld over webserver 1 & webserver 2. De webservers doen hun database queries op de MySQL slave server.
De meetstations connecten direct met de database server waar dus ook een apache op draait met het PHP script voor het invoegen van data. Is dit verstandig trouwens? of maakt dat niet uit.

De MySQL slave wil ik eventueel ook inzetten als backup server. Bedankt voor het erbij zetten van de systeemeisen!

[ Voor 6% gewijzigd door EntonoX op 27-02-2007 10:42 ]

[Verwijderd]

dat inderdaad wat ik bedoel.

de slave is in uiterste gevalen een backup server. omdat deze dus een replica van de master server is, mocht de master onverhoop verloren gaan dan kan de master worden opgebouwed van de replica die de slave nog heeft.

verder zou ik de master machine een raid1 zetten en een journaling filesysteem zoals ext3. in de slave kun je dan gewoon een raid0 draaien want mocht die kapot gaan dan wordt die weer hersteld vanuit de master server.

ik kwam uit op het volgende kwa storage eisen:
1000stations /5minuten = 200 request per minuut
*60 = 12000 request per uur
*24 = 288000 request per dag
*365dagen = 105120000 request per jaar
* 2048bytes per request = 215285760000 bytes per jaar
/1024 = 210240000 kilobytes per jaar
/1024 = 205312,5 megabyte per jaar
/1024 = 200,5 gigabyte per jaar aan informatie.

oftewel als je bijvoorbeeld voor 2x 500gb schijven gaat heb je voor ongeveer 2,5jaar aan storage en daarnaast kun je met compressie er zeker nog wel een jaar aan vast knopen. meetdata kun je erg goed comprimeren dus daar kan gzip zich nog wel op uitleven. in de slave database kun je dan bijvoorbeeld 2x 250gb seagate barracuda's 7200.10 zetten in raid0.

verder moet je van elk systeem regelmatig een image maken van het systeem en die op dvd met de nodige tools zetten zodat je bij een systeem crash de dvd er in kan drukken en restoren maar.

ik zou klein beginnen met 2 servers, de init configuratie in mijn drawings. dan uitbereiden door de database server naar een eigen machine te verplaatsen. als je dan in je php-scripts zorgt dat deze connecten naar db2.eenwebsite.nl in plaats van localhost dan hoef je alleen de dns aan te passen en kun je je database zelfs naar de andere kant van de wereld verplaatsen zonder je scripts te hoeven aan te passen. en als dat dan nog niet genoeg is kun je een load balancer plaatsen en 1 extra webserver. je kan dan telkens 1 extra webserver er bij plaatsen om zo aan je nood te voldoen.

dus niet meteen met 4-5 machines en 20.000 euro van wal steken maar klein beginnen en uitbereiden waanneer de bezoekers aantallen stijgen.

ik denk dat je de initieele configuratie voor nog geen 5.000 euro is te realiseeren. 1500 euro voor de db1.eenwebsite.nl machine en 2500 euro voor de www.eenwebsite.nl machine = 4000 euro, hou je nog 1000euro over voor de switch en andere kabel zooi en heb je hele mooi start om mee te beginnen.

[ Voor 0% gewijzigd door Equator op 02-03-2007 10:58 ]

[EntonoX]

Perfect!

Ik denk dat ik deze opzet ga realiseren, even de nodige documentatie in orde maken en dan moet het allemaal gaan lukken!

Bedankt voor het meedenken Docey!

[Verwijderd]

graag gedaan.