PDA

Bekijk Volledige Versie : Webhosting full redudant



Jethro
09/03/08, 03:34
Beste,

Voor een belangrijke website wil ik zoveel mogelijk redundantie opzetten. Het idee is om in 2 verschillende datacenters en verschillende netwerken een server te plaatsen. Op deze servers draait deze website.
Nu maken deze websites gebruikt van een mysql database. Deze zal dus continue identiek moeten zijn op allebei de locaties.

Nu zit ik alleen met het volgende. De dns staat naar bijv. locatie nummer 1. Nu gaat daar stroom / netwerk / server stuk en zou de dns gelijk naar de server op locatie 2 moeten verwijzen. We zitten dan alleen met een dns update die toch wel even kan duren denk ik.

Verder wil ik dat dit allemaal volledig automatisch gaat.

Iemand goeie ideeën of tips voor mij hoe dit het beste aan te passen.

Pur
09/03/08, 11:39
Beste,

Voor een belangrijke website wil ik zoveel mogelijk redundantie opzetten. Het idee is om in 2 verschillende datacenters en verschillende netwerken een server te plaatsen. Op deze servers draait deze website.
Nu maken deze websites gebruikt van een mysql database. Deze zal dus continue identiek moeten zijn op allebei de locaties.

Nu zit ik alleen met het volgende. De dns staat naar bijv. locatie nummer 1. Nu gaat daar stroom / netwerk / server stuk en zou de dns gelijk naar de server op locatie 2 moeten verwijzen. We zitten dan alleen met een dns update die toch wel even kan duren denk ik.

Verder wil ik dat dit allemaal volledig automatisch gaat.

Iemand goeie ideeën of tips voor mij hoe dit het beste aan te passen.

(Global) load balancing is de key. Als je al de moeite neemt om 2 servers op 2 verschillende lokaties/netwerken op te hangen kan dat er ook nog wel bij :) En is bovendien dus realtime.

En als dat onwenselijk is, of niet betaalbaar.. Waarom niet gewoon de DNS entries naar beide bakken verwijzen. Dan heb je bij uitval maar ~ 50% van je verkeer wat kwijt raakt tot de DNS geprogageerd is.

Mikey
09/03/08, 11:43
En als dat onwenselijk is, of niet betaalbaar.. Waarom niet gewoon de DNS entries naar beide bakken verwijzen. Dan heb je bij uitval maar ~ 50% van je verkeer wat kwijt raakt tot de DNS geprogageerd is.

round robin, een a-record met twee ips.

mdf
09/03/08, 14:18
Als je het echt goed aan wilt pakken ga je al snel praten over global load balancing en een dedicated lijntje tussen de 2 dc's om je data synchroon te houden.
Mocht je meer informatie willen over hoe je zoiets opzet dan ben je welkom om een pm te sturen.

Mark17
13/03/08, 16:35
Is de website eventueel aan te passen? Zo ja dan kun je alle update en insert querys dubbel uitvoeren en eventueel als de andere server niet bereikbaar is in een bestand opslaan dat uitgevoerd wordt zodra die server weer bereikbaar is.

Enige waar je mogelijk mee zit is dat keys en dergelijke problemen gaan geven (is afhankelijk van de site/setup wel af te vangen).

Met wat script werk en 2 A-records is het dus wel af te vangen.

crazycoder
13/03/08, 17:30
Ligt ook aan het doel van de website, als er bijv. een winkel op draait dan wil je niet op 2 verschillende databases de orders accepteren. Als je voorraden bijhoud wil je dat ook niet op 2 verschillende databases doen.
Ik weet daarom ook niet of roundrobin de beste oplossing is.

Voordat er allerlei meningen/ideen geventileerd worden lijkt het mij beter om te vragen wat het doel van de website is. Winkel? veiling? Informatie?
En wat te denken van afbeeldingen.. prop je die in de database of op het filesystem..

Jethro
15/03/08, 19:23
Het gaat om een website waarvan alleen database informatie veranderd.
Er worden wel account geregisteerd en betalingen verwerkt.

Plaatjes of andere zaken zijn niet zo belangrijk. Ik kan deze ook bij aanpassingen
naar elke server uploaden dat is geen probleem.

Ik ben zelf ook flink aan het lezen en denk dat ik het volgende nodig heb.

global loadbalancing ( hier hoor ik graag ervaringen over en hoe mensen dit opgezet hebben en welke software / hardware er gebruikt word ).

En een oplossing om de mysql servers gelijk te houden. Ook als er een offline is geweest dat hij zich automatisch weer update.

royen99
15/03/08, 20:45
MySQL (multi-master) replicatie, voor zowel de website als DNS.
Altijd beide (of zelfs meer) volledig (realtime) in sync. Bij uitval van 1, wordt direct geupdate zodra deze weer online komt.

hostlogic.nl
16/03/08, 00:58
Global loadbalancing en daarbij mysql replicatie over twee gescheiden locaties is niet alleen duur om op te zetten, maar ook duur in onderhoud. Realiseer je goed dat het grootste deel van storingen wordt veroorzaakt door menselijke fouten... Verwacht dus geen wonderen van een redundante oplossing.

De eerste stap in dit soort trajecten zou een kosten-baten analyse moeten zijn. Je maakt hiermee voor de klant inzichtelijk hoe hoog de kosten van bijvoorbeeld 1 uur downtime zijn (gemiste bestellingen, image schade e.d.). Op basis daarvan ga je kijken welke maatregelen je kunt nemen om dat uur downtime te voorkomen en dus of de kosten van die maatregelen opwegen tegen de kosten van de downtime.

Natuurlijk is het technisch gezien een hele leuke uitdaging om een extra 9 aan je beschikbaarheid toe te kunnen voegen (want daar praten we over het algemeen over bij zulke oplossingen), maar vaak bereik je meer als je eerst de verwachtingen van de klant goed afzet tegen de realiteit.

Jethro
16/03/08, 02:07
Vanavond bezig geweest met het opzetten van een mysql multi master replication.

Moet zeggen dat dit tot nu toe er goed uit ziet. Er draaien nu 2 servers met mysql 5
en de database word netjes in sync gehouden. Ook als er 1 uit gaat zodra deze weer online
komt dan syncen ze meteen weer. ( dit ga ik de komende tijd verder testen en uit werken )

Wat betreft de global loadbalancing ben ik een beetje van terug gekomen na het lezen van het volgende artikel : http://www.tenereillo.com/GSLBPageOfShame.htm

Graag hoor ik van mensen of hun andere ervaringen hebben :)

hostlogic.nl
16/03/08, 12:56
Je zou eens kunnen zoeken naar de term anycast. Volgens mij wordt dat op die pagina waarnaar je linkt omschreven als "BGP Host Route Injection". Wordt volgens mij gebruikt voor veel root-server clusters en bijvoorbeeld www.opendns.com. Maar ik betwijfel of deze techniek echt geschikt is voor webservers.

Randy
16/03/08, 13:15
Je zou eens kunnen zoeken naar de term anycast. Volgens mij wordt dat op die pagina waarnaar je linkt omschreven als "BGP Host Route Injection". Wordt volgens mij gebruikt voor veel root-server clusters en bijvoorbeeld www.opendns.com. Maar ik betwijfel of deze techniek echt geschikt is voor webservers.

AnyCast is veel te duur om op te zetten. Van de week het een en ander nagezocht voor een klant waar ik gedetacheerd zit. Dan kom je beter weg met MySQL replicatie. Maar denk eraan: Het is net als raid en beschermd je niet tegen menselijke fouten.
Wil je goed, snel en goedkoop, zet dan gewoon je server neer in een netwerk / datacentrum dat niet om de maand problemen heeft. Neem een goede server met zoveel mogelijk redundant onderdelen en plaats in je rack nog eens een eigen UPS.

Jethro
16/03/08, 15:55
Voor de DNS heb ik het volgende bedacht.

TTL zo laag mogelijk zetten.
Standaard 2 records in de DNS zetten bijv.

website.extensie 1.1.1.1
website.extensie 2.2.2.2

Zodra bijv. locatie 1.1.1.1 offline gaat past de server op locatie 2.2.2.2 de dns aan en verwijderd het 1.1.1.1 record. Zodra de locatie weer online komt dan voegt hij het a record weer toe aan de DNS en dit verhaal visa versa.

Zinvol of niet ? Ik was namelijk aan het testen hiermee en merkte dat toen ik allebei de a-records in de DNS had staan en ik haalde 1 server offline dat ik met geen mogelijkheid naar de andere server verwezen werd. ( browser gesloten - ipconfig /flusdns gedaan enzv ) Toen ik de record voor server 1 weghaalde werkte het binnen een paar seconden en werd ik naar server 2 gestuurd ( getest vanaf huis ).

Dat van mysql begrijp ik ook dat het net raid is. Foutje op server 1 word gelijk naar server 2 doorgestuurd. Daarom worden er natuurlijk ook backups gemaakt. Omdat alle betalingen ( denk aan iDeal ) continue door gaan word er elk uur een backup van de database gemaakt en naar een aparte server weg geschreven. Op deze manier heb ik backups van een week oud en dan van elke uur van de dag van deze week.

Wido
17/03/08, 12:20
Ok, maar denk eens aan het volgende: Wanneer besluit je dat een machine dood is?

Als deze poort 80 niet meer open heeft staan? Of als een PHP-script geen OK meer geeft tegen je monitoring?

Wat ik meer bedoel, hoe complexer je de boel maakt, hoe meer er fout kan gaan.

In principe zou ik gokken op 1 goed netwerk en 2 servers die beide redundant stroom hebben en via aparte switches naar de routers lopen.

Hier kan je via DRBD en Heartbeat een hele mooie setup maken.

Het beschermd je alleen nog steeds niet tegen het niet goed meer functioneren van een service. "httpd" kan dan nog wel draaien, maar wie zegt dat deze intern nog goed functioneert?

Wat ik alleen wil zeggen, hoe complexer, hoe meer er fout kan gaan. 1 enkele server met goede hardware kan hele goede uptimes halen. Sync de data realtime naar een tweede server via DRBD en doe desnoods de failover handmatig, want zó vaak vallen servers nu ook weer niet uit.

Jesperw
17/03/08, 13:52
Ik ben ook absoluut voor een handmatige failover. Het zal niet de eerste keer zijn dat er een server hikt, de failover in werking is en ze op dat moment allebei de baas zijn en ruzie krijgen. ;)

hostlogic.nl
17/03/08, 14:11
Ik ben ook absoluut voor een handmatige failover. Het zal niet de eerste keer zijn dat er een server hikt, de failover in werking is en ze op dat moment allebei de baas zijn en ruzie krijgen. ;)

Een split-brain heet dat... Daarvoor heeft heartbeat op een linux een techniek genaamd stonith ingebouwd (shoot the other node in the head). Als er twijfel is of een cluster node wel of niet down is, wordt de betreffende node uitgezet (via bijvoorbeeld een apc) voordat de standby node de resources opstart.

Mikey
17/03/08, 14:28
Een split-brain heet dat... Daarvoor heeft heartbeat op een linux een techniek genaamd stonith ingebouwd (shoot the other node in the head). Als er twijfel is of een cluster node wel of niet down is, wordt de betreffende node uitgezet (via bijvoorbeeld een apc) voordat de standby node de resources opstart.

Wij hebben hier goede ervaringen mee, aangezien het soms voor kwam dat ze beide master waren en het pas weer werkte op moment een van de twee een hup kreeg. Overigens passen wij het toe en worden we op de hoogte gesteld zodat we 1. op de hoogte zijn (duh) en 2. het weer handmatig online brengen zodat we na kunnen lopen of de active standby weer echt standby gaat en de daadwerkelijke master zijn taken vervolgd.

Jethro
17/03/08, 14:51
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.

Het gaat mij er alleen om dat als bijv. locatie 1 offline is dat zijn a-record uit de dns verdwijnt totdat locatie 1 weer terug online komt. ( zie mijn eerdere post hierover. Toen ik het record verwijderd had kwam ik vanaf huis wel op de 2de server terecht )

Dit lijkt mij de beste oplossing ( naast GSLB met zijn hoge kosten ).

Wido
17/03/08, 14:54
Ok, maar wie gaat beslissen wie er offline is? Wie gaat het A-record weg halen? Aan wie laat je dat over?

Stel je doet dit vanaf je primaire DNS-server, wat nou als door een netwerk issue deze locatie A niet meer kan bereiken, dan wordt locatie A uit de DNS gegooid terwijl er niets mis is met locatie A.

Of nog erger, locatie A en B zijn beide online, maar de primaire DNS-server heeft een probleem en gooit zowel locatie A als B uit de DNS, dan wat?

bami82
17/03/08, 15:00
Al verander je het A record, kunnen je klanten/bezoekers nog steeds last hebben van cache.

Jethro
17/03/08, 15:17
@wido Hier ben ik nog mee bezig om te kijken wat de beste oplossing is. Ik zit te denken om elke server de andere te controleren of deze nog online is. Mocht dit niet zo zijn dan past de server de DNS aan via een API ofzo op de DNS server. Daarnaast wil ik SIM ( http://rfxnetworks.com/sim.php ) draaien op welke server zodat deze zelf httpd / mysqld controleerd en deze indien nodig herstart.

@bami82 browser cache valt weinig aan te doen. Ik kan moeilijk invloed uit oefenen op een browser natuurlijk. DNS cache probeer ik zoveel mogelijk te voorkomen dmv de ttl enzv zo laag mogelijk te houden.

bami82
17/03/08, 15:20
Ik bedoel dns cache uiteraard en dat los je niet helemaal op met de ttl ben ik bang.

Wido
17/03/08, 15:20
@wido Hier ben ik nog mee bezig om te kijken wat de beste oplossing is. Ik zit te denken om elke server de andere te controleren of deze nog online is. Mocht dit niet zo zijn dan past de server de DNS aan via een API ofzo op de DNS server. Daarnaast wil ik SIM ( http://rfxnetworks.com/sim.php ) draaien op welke server zodat deze zelf httpd / mysqld controleerd en deze indien nodig herstart.Ja, maar HOE controleer je of iets online is?

Ga je een hele controle doen of de services intern ook nog goed draaien of wat?

Daarnaast, wat als de connectie tussen server A en B weg valt, omdat er even een route uit ligt, dan gaan ze beide elkaar uit de DNS gooien omdat ze elkaar niet kunnen bereiken.

Als mysqld of httpd nog draait op je systeem betekend het ook niet per definitie dat deze ook nog correct en naar behoren functioneert.

galious
17/03/08, 15:25
Zinvol of niet ? Ik was namelijk aan het testen hiermee en merkte dat toen ik allebei de a-records in de DNS had staan en ik haalde 1 server offline dat ik met geen mogelijkheid naar de andere server verwezen werd. ( browser gesloten - ipconfig /flusdns gedaan enzv ) Toen ik de record voor server 1 weghaalde werkte het binnen een paar seconden en werd ik naar server 2 gestuurd ( getest vanaf huis ).
Met welke browser heb je getest?

in een ver verleden ook eens mee getest, conclusie toendertijd:

IE loopt de IP-adressen in volgorde af, totdat er eentje een response geeft; Mozilla probeert alleen het eerste IP-adres. Oftewel voor een fail-over niet geschikt.

Ook het omlaag zetten van de TTL is niet geschikt aangezien DNS-cache zich hier niet altijd aan houdt.


Groeten,

Martin

Jethro
17/03/08, 16:09
Ik denk dat ik van het weekend niet helemaal wakker was.

Ben nu weer aan het testen met 2 x A record naar elke server en als ik httpd stop op server 1 en de pagina refresh word ik zo doorgestuurd naar server 2. Dit met zowel IE als FF.

Als het zo makkelijk is dan ga ik niets maken voor het aanpassen van DNS want dan is het goed zo. Komt iemand niet op server 1 dan gaat hij vanzelf naar server 2.

RobinJB
17/03/08, 16:15
Als dat echt zo makkelijk is, dan ga ik dat direct ook even doen.

Mikey
17/03/08, 16:25
Ik weet heel zeker dat dit met oudere versie van browsers niet werkt. Daar werd naar willekeur een a record gebruikt. Daarbij vind ik het vreemd dat een browser kan bepalen wanneer een server niet te bereiken is. Kun je daarvoor timeout oid aangeven ?

Round robbin wordt door hotmail veelvuldig toegepast op MX records, echter zou ik dat zelf nooit als failover op A records willen hebben voor websites. YMO

Pinocchi
17/03/08, 16:32
Wat betreft de dns cache, veel providers (adsl, kabel, e.d.) houden zich niet aan de ttl als die erg laag is. Ze houden deze zelf tenminste 24 uur vast en soms nog wel langer. Jij kunt dan wel je dns aangepast hebben, maar dat wil niet zeggen dat deze bij de provider ook aangepast is zo snel.

Jethro
17/03/08, 16:34
Zijn er ook nog mensen met oplossingen ipv alleen maar met commentaar dat iets NIET werkt ?

Ik open een topic omdat ik opzoek ben naar oplossingen maar die komen erg weinig naar voren.

Mikey
17/03/08, 16:47
Tot nu toe zie ik maar paar pogingen van je met wat je zelf hebt gedaan, wachten totdat iemand een complete oplossing je schoot in werpt kan iedereen. Er zullen genoeg partijen zijn die je tegen betaling zeer mooie oplossingen op weten te leveren, echter zal er niemand zijn die een complete blik in zijn eigen keuken geeft. Wees blij met de feedback die je ontvangt, ondanks dat iemand aangeeft dat dat niet werkt. Hoef je dat in ieder geval niet meer zelf te proberen ....

Jethro
17/03/08, 17:54
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.

galious
17/03/08, 17:55
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.


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

maxnet
17/03/08, 18:45
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.

Mikey
17/03/08, 18:48
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 :).



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 :)

galious
18/03/08, 11:21
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.


[QUOTE=Mikey;950585]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

royen99
18/03/08, 11:39
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:


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.



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.

Jethro
18/03/08, 13:29
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 )

maxnet
18/03/08, 18:30
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/zakelijk/omzetbelasting/ob02/ob02-41.html
http://www.belastingdienst.nl/zakelijk/omzetbelasting/ob02/ob02-62.html

Serve-xs
18/03/08, 21:32
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...