Onderwerp: Webhosting full redudant

De tip van mysql master master replication was een goeie tip. Ben hiermee aan de slag gegaan en dat werkt nu goed.

Als iemand een betere oplossing voor het DNS verhaal heeft dan hoor ik dat graag.
Niemand hoeft als het zo belangrijk voor deze of gene is alles gratis te vertellen maar een goeie tip of een full oplossing is welkom. Ik heb nooit gezegd dat ik nergens voor wil betalen.
Maar ook dat ben ik nog niet tegen gekomen.

Dus als mensen tegen betaling wel willen helpen hoor ik het graag. Graag dan ook vermelden wat de ervaring is en wat mijn voordeel hierin is.

Daarnaast denk ik dat het nu aardig voor elkaar is. Zowel IE als FF switchen automatisch van server als ik apache stop op een server. ( getest op meerde pc's / locaties nu )
Dat dit niet werkt met oude browsers heb ik niet getest en vind ik ook niet zo interessant eigenlijk.

Maar goed mocht iemand een betere oplossing hebben dan hoor ik het graag.

Oorspronkelijk geplaatst door Mikey

Ik weet heel zeker dat dit met oudere versie van browsers niet werkt. Daar werd naar willekeur een a record gebruikt.

Ik gok dat mijn testen zo rond 2003/2004 hebben plaatsgevonden, zoals reeds vermeld werkte dit wel in IE en niet in mozilla-based browsers.

Oorspronkelijk geplaatst door Mikey

Daarbij vind ik het vreemd dat een browser kan bepalen wanneer een server niet te bereiken is. Kun je daarvoor timeout oid aangeven ?

Er zijn verschillende scenarios te bedenken, even 2:
- eerste server wordt geprobeerd, duurt langer dan 30 seconden tot de eerste response, probeer 2e server, etc.
- alle servers worden tegelijk geprobeerd, de 1e om te reageren 'wint' en de rest van de connecties wordt afgebroken

Ik heb verder geen idee hoe ze het gedaan hebben (wellicht wachten ze de volledige connection time-out af)

Groeten,

Martin

Oorspronkelijk geplaatst door Jethro

Uhm ? misschien mis ik iets maar als er niets aan de hand is mogen ze allebei in deze situatie van mij de baas zijn. De mysql servers houden elkaar toch op de hoogte van de wijzigingen en als een van de locaties offline gaat en weer terug komt dan updaten ze elkaar met de laatste veranderingen.

Dat is niet altijd even simpel.

Een van de problemen zijn tabellen met AUTO_INCREMENT velden.
Stel de verbinding tussen de 2 servers ligt even plat, ze spelen beide voor master, en beide voegen een recordje toe aan dezelfde tabel.
Dan heb je plotseling 2 records met hetzelfde nummer.

Om dit te voorkomen kan je bij MySQL instellen dat de ene server alleen even nummers gebruikt en de andere oneven.
De code en het databaseontwerp van de website moet er dan wel op gericht zijn dat de nummers niet opeenvolgend zijn.
Maakt je webshop bijvoorbeeld facturen aan, dan mag je voor het factuurnummer geen auto_increment gebruiken, want dan zijn de nummers niet opeenvolgend.

Oorspronkelijk geplaatst door galious

Ik gok dat mijn testen zo rond 2003/2004 hebben plaatsgevonden, zoals reeds vermeld werkte dit wel in IE en niet in mozilla-based browsers.

Ik heb nooit echt met browser getest, wel om visueel beeld te krijgen om het daadwerkelijke resultaat te krijgen. Vermoedelijk zijn we rond dezelfde periode aan de gang geweest, wat ik daarvan weet is dat op de prompt pingen een fiasco was. 4 verschillende ips 50% offline, en je had niet per definitie een werkende te pakken. Misschien dat men dit langzaam aan het veranderen is geweest. Zal hier tzt ook weer eens mee gaan testen .

Oorspronkelijk geplaatst door galious

Er zijn verschillende scenarios te bedenken, even 2:
- eerste server wordt geprobeerd, duurt langer dan 30 seconden tot de eerste response, probeer 2e server, etc.
- alle servers worden tegelijk geprobeerd, de 1e om te reageren 'wint' en de rest van de connecties wordt afgebroken

een kleine aantekening :
DNS has no way of detecting physical failure e.g. when the hard disk on server2 (www2) fails. As requests come in for www.yourcompany.com, the DNS will continue to forward one out of every three requests to www2 - which will fail. Effectively, 33% of all requests to www.yourcompany.com are now connecting to a black hole. This is an improvement over having just one web server and having all the requests being lost due to a hardware failure, but only to a certain degree.

Verder is misschien RFC 2782 (SRV RR) vergelijkbaar met prio's voor mx records alleen dan voor protocollen / services

[QUOTE=Mikey;950585]Ik heb nooit echt met browser getest, wel om visueel beeld te krijgen om het daadwerkelijke resultaat te krijgen. Vermoedelijk zijn we rond dezelfde periode aan de gang geweest, wat ik daarvan weet is dat op de prompt pingen een fiasco was. 4 verschillende ips 50% offline, en je had niet per definitie een werkende te pakken. Misschien dat men dit langzaam aan het veranderen is geweest. Zal hier tzt ook weer eens mee gaan testen .[/QUOTE=Mikey;950585]
Klopt ping, haalt dan ook de DNS-info op en pikt 1 IP. Ligt dit eruit dan krijg je jouw resultaat.

Oorspronkelijk geplaatst door Mikey

een kleine aantekening :
DNS has no way of detecting physical failure e.g. when the hard disk on server2 (www2) fails. As requests come in for www.yourcompany.com, the DNS will continue to forward one out of every three requests to www2 - which will fail. Effectively, 33% of all requests to www.yourcompany.com are now connecting to a black hole. This is an improvement over having just one web server and having all the requests being lost due to a hardware failure, but only to a certain degree.

Klopt ook. Je browser werkt dan ook niet op DNS niveau. Ze halen de DNS-info op en proberen 1-voor-1 of allemaal tegelijk of een deel tegelijk de IP-adressen die volgens DNS toegewezen zijn. Pas in deze 2e stap, dus /na/ het ophalen van de DNS gegevens kan een browsers zien of een server up of down is. Let wel: DNS kan in 1 response meerdere IP-adressen teruggeven.

Interessant weetje: Het aantal van 13 root-servers is ook niet toevallig: er kunnen tot 13 IP-addressen 'veilig' worden teruggeven in het 512 bytes tellende DNS-response.

groeten,

Martin

Oorspronkelijk geplaatst door maxnet

Dat is niet altijd even simpel.

Een van de problemen zijn tabellen met AUTO_INCREMENT velden.
Stel de verbinding tussen de 2 servers ligt even plat, ze spelen beide voor master, en beide voegen een recordje toe aan dezelfde tabel.
Dan heb je plotseling 2 records met hetzelfde nummer.

Om dit te voorkomen kan je bij MySQL instellen dat de ene server alleen even nummers gebruikt en de andere oneven.
De code en het databaseontwerp van de website moet er dan wel op gericht zijn dat de nummers niet opeenvolgend zijn.

Hoeft niet enkel even/oneven.. dit zou anders niet werken als je meer als 2 masters heb. MySQL heeft bv ook hiervoor:

Code:

auto_increment_increment = 10
auto_increment_offset = 2

Bij gebruik van bovenstaande krijgt het 1ste record, id 2, de volgende 12, dan 22.. etc.
Overigens volledig transparant aan je (php/perl etc) code.

Oorspronkelijk geplaatst door maxnet

Maakt je webshop bijvoorbeeld facturen aan, dan mag je voor het factuurnummer geen auto_increment gebruiken, want dan zijn de nummers niet opeenvolgend.

Mag niet ? Onzin.. ok, de nummers zijn niet opeenvolgend.. Afgezien van dat dat feit is daar verder niets tegen.

Ik wil iedereen bedanken voor zijn bijdrage.

Ik heb nu een werkende test omgeving die doet wat ik wil. De komende week ga ik deze zwaarder belasten en verder testen.

Mochten er mensen / bedrijven zijn die een betere oplossing hebben dan mogen deze altijd contact opnemen ( en nee niet alles hoeft gratis )

Oorspronkelijk geplaatst door royen99

Mag niet ? Onzin.. ok, de nummers zijn niet opeenvolgend.. Afgezien van dat dat feit is daar verder niets tegen.

Heb altijd begrepen dat de belastingdienst daar niet zo blij mee was, omdat het dan makkelijker is te "vergeten" bepaalde facturen te boeken.

Zie ook:

http://www.belastingdienst.nl/zakeli...2/ob02-41.html
http://www.belastingdienst.nl/zakeli...2/ob02-62.html

Kijk eens naar ucarp:

Je hebt een master en een slave server. Op beide servers is de data steeds hetzelfde door bijvoorbeeld rsync te gebruiken. De slave server pingt als het ware de master server met een configureerbaar interval. Als de slave server "merkt" dat de master onbereikbaar is zal het IP adres van de netwerkkaart in de slave server worden verandert naar het IP van de master server, waardoor alle requests etc. automatisch bij de slave server aankomen.

Alles gebeurt via bashscripts, dus in feite zijn alle acties bij een storing mogelijk (sms sturen, mailtje sturen, bepaald programma runnen etc.).

Denk erom dat de servers op deze manier wél in hetzelfde netwerk moeten staan, en dat komt de redundantie niet echt ten goede...