Onderwerp: Opstelling met hoge uptime garantie

Oorspronkelijk geplaatst door Tim.Bracquez

Vergeet wel niet je sessions etc, best lastig als er uitval is en je zit met een vol winkelmandje dat je dan ineens helemaal moet herbeginnen... (als voorbeeld)

Bij een goed opgezette load-balanced omgeving, worden je sessies centraal opgeslagen (NFS of database). Daarnaast kun je bij een dubbel uitgevoerde load-balancer ook connection states laten synchroniseren, waardoor een standby load-balancer gewoon alle connecties overneemt. Dit zit volgens mij standaard in CARP en LVS.

Welke oplossing(gen) zijn er mogelijk als je niet alle eieren in hetzelfde provider/datacentrum mandje wilt leggen? Oftewel machine 1 moet in een ander datacentrum en een ander netwerk staan dan machine 2.

Oorspronkelijk geplaatst door bami82

Bovendien moeten primary en secondary dns dezelfde records hebben.

Wie bepaalt dat primary en secondary dezelfde records moeten hebben? Hebben records bij gebruik van de PowerDNS geobackend (http://en.wikipedia.org/wiki/PowerDN..._and_Wikimedia) identieke primary en secondary records?

Oorspronkelijk geplaatst door cj0

Welke oplossing(gen) zijn er mogelijk als je niet alle eieren in hetzelfde provider/datacentrum mandje wilt leggen? Oftewel machine 1 moet in een ander datacentrum en een ander netwerk staan dan machine 2.

Als je geen eigen AS heb , kom je al snel uit op dns failover (dit kan bijvoorbeeld met een cisco global site-selector etc).

Wij hebben dit ook laatst gebouwd voor een klant , in elk datacenter een (authorized) dns server , en de A records daarop verwijzen naar de servers in dat DC.

Mocht iemand dus een dns lookup doen en het dc is niet bereikbaar dan zal hij automatisch de andere DNS server van ons proberen.

Je moet echter nog wel de servers zelf monitoren , anders kan het zijn dat een webserver niet werkt maar het DC gewoon te bereiken is.

Wij monitoren de servers , en bij uitval wordt er binnen de seconden een script gerunt wat de A records op de DNS server update of verwijderd voor de uitgevallen server.

Bovenstaande is slechts de oplossing in grote lijnen , hiernaast moet je kijken naar de TTL's van de dns servers en nog wat andere 'truukjes' om het helemaal goed te krijgen.

Oorspronkelijk geplaatst door ewoutz

Als je geen eigen AS heb , kom je al snel uit op dns failover (dit kan bijvoorbeeld met een cisco global site-selector etc).

Wij hebben dit ook laatst gebouwd voor een klant , in elk datacenter een (authorized) dns server , en de A records daarop verwijzen naar de servers in dat DC.

Maar dan houdt je toch altijd het probleem van DNS-Caching, of ben ik nu gek?

Het een sluit het ander niet uit.
Maar je hebt gelijk, als ik besluit TTL's te negeren, zoals een aantal ISP's doet, dan werkt het niet.

Dit kan zeker voor een laag budget ook gerealiseerd worden door middel van bijv. 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...

Mocht je kiezen voor het Windows besturingssysteem, dan kun je alles out-of-the-box realiseren zonder 3th party software. Network Load Balancing, failover clustering, SQL replication, IIS replication en File replication. Het is redelijk eenvoudig op te zetten en het werkt perfect. Het werkt met minimaal 2 en maximaal 32 nodes per cluster. Een NAS of SAN is niet nodig.

@Diedx
DNS-Caching is inderdaad nog een probleem, maar je zou voor één lookup 2 A records terug kunnen geven, de meeste browsers proberen eerste het eerste IP adres, en als dat niet lukt het tweede IP adres. Dus voor een http gebaseerde omgeving kan de DNS methode een oplossing zijn.

Carp en MS Windows vallen in mijn beleving niet onder hoge beschikbaarheid, omdat beide oplossingen alleen functioneren als alle machines zich in hetzelfde netwerk bevinden, en dat betekent doorgaans hetzelfde gebouw.