PDA

Bekijk Volledige Versie : Rendundant maken van server



xtreme2490
11/12/04, 17:44
Kan iemand mij uitleggen hoe ik men webserver/mailserver rendundant kan maken zodat wanneer deze faalt , de andere onmiddellijk kan overnemen ?

Alvast bedankt

Triloxigen
11/12/04, 18:32
2 mailservers draaien op 2 verschillende servers
2 MX records instellen met beide een andere prioriteit

xtreme2490
11/12/04, 18:42
en webserver ?

Detonator
11/12/04, 19:04
Voor een redundante webserver zou je een loadbalancer (hardware) ervoor moeten zetten die het traffic 'doorgeeft' aan de server die up is.

Je zou ook zelf een intelligent stukje software kunnen draaien op de bijbehorende DNS-server (aparte fysieke server), die het IP-adres van de website(s) aanpast zodra de hoofdwebserver down is. Met hele lage TTL-values in de DNS Zones, bijv. 10-60 sec. Maar dit werkt ook niet echt perfect ivm. DNS-caching bij ISP's.

maxnet
11/12/04, 19:28
Bij een webserver maakt het uit wat voor sites er op draaien.

Op het moment dat er een database aan hangt die door de bezoekers van de site aangepast kan worden, wordt het vrij ingewikkeld.

In het kort: indien het type database MySQL is, en er AUTO_INCREMENT velden in de tabellen zitten kan je het wel vergeten.
Het is vrij lastig om dit redudant te maken, zonder het risico te lopen op corruptie.

Draaien er alleen sites op zonder database, of waar je de database structuur zelf in de hand hebt, dan kan je inderdaad met loadbalancers of DNS failover werken.
Een aantal DNS hosters (zoals zoneedit) bied dit ook aan.

mguilmot
11/12/04, 19:32
drbd (http://drbd.org) / heartbeat (http://linux-ha.org)

maxnet
11/12/04, 19:40
Origineel geplaatst door mguilmot
drbd (http://drbd.org) / heartbeat (http://linux-ha.org)

Hoewel dit voor bestanden werkt, werkt het op het moment (nog) niet bij databases.

DRBD repliceert het bestandssysteem.
Databases als MySQL schrijven niet alle gegevens direct weg naar het bestandssysteem.

wv-
11/12/04, 20:35
Origineel geplaatst door maxnet


Hoewel dit voor bestanden werkt, werkt het op het moment (nog) niet bij databases.

DRBD repliceert het bestandssysteem.
Databases als MySQL schrijven niet alle gegevens direct weg naar het bestandssysteem.

Voor MySQL kan je MySQL replication gebruiken.

maxnet
11/12/04, 20:58
Origineel geplaatst door wv-

Voor MySQL kan je MySQL replication gebruiken.

Dat werkt niet op het moment dat er AUTO_INCREMENT velden in de tabel zitten.

Op het moment dat er op beide servers tegelijk een record aan dezelfde tabel wordt toegevoegd heb je plotseling 2 records met hetzelfde volgnummer.
Dan is je database corrupt en kapt de replicatie ermee (ervaring mee)
Deze situatie treed ook op als de verbinding tussen beide servers verbroken is, maar er nog wel bezoekers zijn die beide server kunnen bereiken.
Bijvoorbeeld bij een routeringsprobleem.

Als "oplossing" bieden recentere versies van MySQL de mogelijkheid om een nummerbereik op te geven.

Bijvoorbeeld:
server1 gebruikt de nummers 1-1.000.000 voor de auto nummering.
server2 gebruikt de nummers 1.000.001 - 2.000.000

Probleem hierbij is echter dat veel scripts er vanuitgaan dat de volgnummers opeenvolgend zijn en op basis daarvan de tabel sorteren (als in: ORDER BY id) en weergeven.
Dat gaat dan dus niet goed...

BartVB
11/12/04, 23:18
Met hele lage TTL-values in de DNS Zones, bijv. 10-60 sec. Maar dit werkt ook niet echt perfect ivm. DNS-caching bij ISP's. [/B]
Ieuw! Ik hoop dat je dit niet serieus meent? Een TTL in DNS voor x seconde is wel heel erg smerig :\

Het overpakken van een server die dood is gegaan kan je beter doen met het overpakken van het IP. De eenvoudigste manier om dat te doen is het MAC adres van de 2e server veranderen in het MAC adres van de PC die net overleden is. Op die manier lijkt het voor het netwerk net alsof de eerste PC gewoon in een andere poort van de switch is geprikt. Voordeel van die oplossing is dat er voor de buitenwereld (netwerktechnisch) niets veranderd behalve dan dat alle verbindingen weg zijn. Het lijkt dus een beetje op een reboot van de eerste server.

Grootste probleem is dan het gelijk houden van je twee servers maar daarvoor zijn voor de verschillende applicaties al erg handige dingen bedacht.

Overigens heb je helemaal geen probleem als je een fileserver gebruikt, op die manier pakt de tweede server gewoon de shares over van de eerste server, draait wat consistency checks ivm het crashen van server 1 en draaien maar.

Kijk eens naar:

http://www.linuxvirtualserver.org/

of zoek op 'high availability linux'.

Norman
28/02/05, 01:41
Origineel geplaatst door maxnet


Dat werkt niet op het moment dat er AUTO_INCREMENT velden in de tabel zitten.

Op het moment dat er op beide servers tegelijk een record aan dezelfde tabel wordt toegevoegd heb je plotseling 2 records met hetzelfde volgnummer.
Dan is je database corrupt en kapt de replicatie ermee (ervaring mee)
Deze situatie treed ook op als de verbinding tussen beide servers verbroken is, maar er nog wel bezoekers zijn die beide server kunnen bereiken.
Bijvoorbeeld bij een routeringsprobleem.

Als "oplossing" bieden recentere versies van MySQL de mogelijkheid om een nummerbereik op te geven.

Bijvoorbeeld:
server1 gebruikt de nummers 1-1.000.000 voor de auto nummering.
server2 gebruikt de nummers 1.000.001 - 2.000.000

Probleem hierbij is echter dat veel scripts er vanuitgaan dat de volgnummers opeenvolgend zijn en op basis daarvan de tabel sorteren (als in: ORDER BY id) en weergeven.
Dat gaat dan dus niet goed...


Volgens mij kun je dit toch oplossen door de nieuwe cluster functie sinds versie 4 van MySQL ?

Even een ander vraagje nog, welke cp's bieden ondersteuning/werken met dit soort opstellingen ?
Met dit soort opstelling, bedoel ik een fallback opstelling zoals vermeld op bijvoorbeeld linuxvirtualserver....
(load-balancer -> servers met fallback en centrale storage)
In het bijzonder weet iemand of Directadmin hiermee werkt en zou die een kleine globale toelichting willen geven over hoe ?

maxnet
28/02/05, 02:17
Origineel geplaatst door Norman

Volgens mij kun je dit toch oplossen door de nieuwe cluster functie sinds versie 4 van MySQL ?


Een MySQL cluster lost het AUTO_INCREMENT probleem inderdaad op, zolang je over een opstelling beschikt waar genoeg servers (min. 3) in zitten.

Het vervelende is dat MySQL clusters zaken als FULLTEXT indexen niet ondersteunen, en er een limiet aan de grootte van records zitten.
Zie: http://dev.mysql.com/doc/mysql/en/mysql-cluster-limitations-in-4-1.html

Hierbij geldt dus --net als bij MySQL replicatie-- dat het prima te gebruiken is zolang je de db tabelstructuur zelf kan bepalen. Maar als je klanten dit zelf doen is het niet bruikbaar.

luser
28/02/05, 02:54
Ik heb al goede ervaringen gedaan met gewoon het gebruik van een klein NAS systeem (1U bakkie van lacie ofzow), gewoon zorgen dat de uid's/gid's van beide systemen het zelfde zijn, databases etc plaats je op de NAS en via een serialkabeltje checkt de backup of de main up is of niet, gaat deze down neemt ie gewoon het ip over.

EDIT: urltje http://www.lacie.com/products/product.htm?pid=10176

EDIT2: Je kan ook altijd zelf een servertje bouwen (persoonlijk hou ik niet zo van windows oplossingen :D)

Norman
28/02/05, 11:56
ik zat ook misschien te denken aan een 4U supermicro bak met Open-E NAS..

Maxnet: hoe raad je dan aan de SQL server redudant te maken ?
Er staat overigens wel bij LVS etc, dat de applicatie geen ondersteuning hoeft te hebben voor cluster/failover dat deze er niks van merkt?

dotnetjunkie
28/02/05, 20:09
Is Windows 2003 server met MS SQL een optie?
Die is nl. perfect redundant te maken, op een wijze die met MySQL vooralsnog niet kan...

galious
28/02/05, 21:10
Voor Linux/BSD is PostgreSQL bij mijn weten ook volledig redundant te maken. Als een andere DB tenminste kan. (Ik neem even aan dat er op dit platofrm gebleven moet worden).

MySQL is vrij lastig volledig redundant te maken. Alhoewel het volgens mij wel mogelijk moet zijn met wat slimme scripts en twee (of meer) verbindingen tussen de servers.

Aloha,

Martin

Norman
28/02/05, 23:23
mja ik hou voorlopig liever een LAMP opstelling.
Maar kan me zo nauwelijks voorstellen dat MySQL zo moeilijk zou zijn.
Ik lees me er nog even verder op in als ik de oplossing heb gevonden (of iemand anders komt ermee) dan geef ik het hier nog weer.

maxnet
28/02/05, 23:53
Origineel geplaatst door Norman

Maxnet: hoe raad je dan aan de SQL server redudant te maken ?


Zoals anderen reeds aangeven kan je dan beter een andere SQL server gebruiken i.p.v. MySQL.

Met MySQL is het simpelweg NIET mogelijk als je klanten zelf de db structuur bepalen en alle functionaliteit van MySQL willen gebruiken.

Indien je zelf het db ontwerp volledig in de hand hebt kan het wel.
Bij MySQL replicatie moet je er dan voor zorgen dat:

- er geen AUTO_INCREMENT velden gebruikt worden.

OF:

- er per server een AUTO_INCREMENT bereik wordt opgegeven.
Server 1: 1-1.000.000
Server 2: 1.000.001 - 2.000.000

Vervolgens moet je er in de scripts voor zorgen dat er nergens op basis van AUTO_INCREMENT velden gesorteerd wordt, maar dat hiervoor in de plaats bijvoorbeeld een timestamp wordt gebruikt.


Waar je replicatie overigens wel zonder problemen voor kan gebruiken is voor het maken van een live-backup van de gegevens.
Dit doen wij zelf ook, en op het moment dat we zeker weten dat de server plat ligt, schakelen we de DNS -HANDMATIG- over naar de backup server.

Maar een automatisch failover systeem in een ander datacenter gaat dus NIET zondermeer werken, omdat het zeer lastig is om te bepalen dat de andere server echt plat ligt en er geen sprake is van bijv. een routeringsprobleem ergens tussen de 2 servers.
Door DNS caching is het niet te vermijden dat bezoekers nog enige tijd proberen met de andere server verbinding te maken.
Als dat de bezoekers lukt, en je hebt bezoekers die via server 1 AUTO_INCREMENT recordjes toevoegen en je hebt bezoekers die via server 2 recordjes toevoegen, dan heb je een probleem.

Norman
01/03/05, 01:07
hmmm en what about MySQL Cluster ?
Ik heb even ingelezen het probleem van MySQL is inderdaad dat er nog geen master election systeem is dat maakt het zo dat je het met de hand moet verwijzen. (of zelf een script moet schrijven)

ben nu even aan het inlezen wat MySQL Cluster precies is en doet ....