Redudantie webservers

[mbr99]

Hoi allen,

We hebben een webserver hangen extern op een co-locatie achter een firewall. De site heeft altijd 1 ip-adres gehad waarop de site benaderbaar was. Wij willen naar een situatie toe dat als de NIC1 uit zou vallen, dat NIC2 het overneemt. Inmiddels hebben wij een 2e lijn liggen met een ander publiek IP-adres, die verbonden aan een 2e firewall, geheel gescheiden.

Het gaat fout met het gateway probleem op Windows 2003 server. Je kunt geen 2e gateway instellen. NIC 1 heeft 10.0.0.1 als gateway en NIC2 de 10.0.1.1 (beide sub C). Laten we de G leeg op NIC1, luistert de site prima naar de website via NIC2, en andersom ook. Maar beide G's invullen, gaat fout. Dan pakt hij er 1, geen idee of dit willekeurig gaat overigens.

Heeft er iemand praktijk ervaring mee hoe je dit het beste kunt aanpakken?

[JMW761]

bonding/trunking moet je gaan gebruiken.

Maar dat moet je host wel ondersteunen (ofwel hun switch)

Idee is dus dat je beide links actief gaat gebruiken, en dat alles up blijft zodra 1 van de links uitvalt (danwel poort (switch/server) dan wel kabel defect.

[leuk_he]

Wikipedia: Round robin DNS

Echter als er een interface down gaat zul je zelf (/automatisch) de dns moeten aanpassen en dan nog blijkt dat het ip gecached word gedurende enige tijd.

Wil je een hogere uptime hebben zul je echter ook meer webservers op meer lokaties moeten hebben, niet enkel 1 server met meer meer connecties.

[ Voor 5% gewijzigd door leuk_he op 13-07-2009 18:20 ]

[Seth4Chaos]

mbr99 schreef op maandag 13 juli 2009 @ 16:19:
Heeft er iemand praktijk ervaring mee hoe je dit het beste kunt aanpakken?

Niet met windows , maar kan je wel vertellen hoe het in theorie kan.

Zoals hierboven al gezegt werd moet je denken aan bonding / Link aggragation (802.3ad), het mooiste is als je switch dit ondersteund. dan kan je active-active doen en heb je dus op twee draadjes die virtueel 1 draadje voorstelt. Trek je er 1 uit dan gaat de server en switch automatisch verder op het andere draadje.

Mocht je switch dit niet ondersteunen kan je voor active-passive kiezen, dat houd in dat als je het ene (active) draadje eruit trekt de server automatisch het andere draadje activeert. Geeft je waarschijnlijk een downtime van enkele honderde milli-seconden maar dan draai je weer. Kan je vervolgens nog kiezen wat er moet gebeuren als het eerste draadje weer terug komt (actief worden of die als bacup gebruiken).

Hoe je dit moet instellen kan ik je alleen vertellen met Linux maar dat draai je niet dus schiet het niet op. Je weet nu iig waar je naar moet zoeken op Google.

[jvanhambelgium]

mbr99 schreef op maandag 13 juli 2009 @ 16:19:
Hoi allen,

We hebben een webserver hangen extern op een co-locatie achter een firewall. De site heeft altijd 1 ip-adres gehad waarop de site benaderbaar was. Wij willen naar een situatie toe dat als de NIC1 uit zou vallen, dat NIC2 het overneemt. Inmiddels hebben wij een 2e lijn liggen met een ander publiek IP-adres, die verbonden aan een 2e firewall, geheel gescheiden.

Het gaat fout met het gateway probleem op Windows 2003 server. Je kunt geen 2e gateway instellen. NIC 1 heeft 10.0.0.1 als gateway en NIC2 de 10.0.1.1 (beide sub C). Laten we de G leeg op NIC1, luistert de site prima naar de website via NIC2, en andersom ook. Maar beide G's invullen, gaat fout. Dan pakt hij er 1, geen idee of dit willekeurig gaat overigens.

Heeft er iemand praktijk ervaring mee hoe je dit het beste kunt aanpakken?

Kan perfect hoor, je moet gewoon wel effe een andere "metric" meegeven hé !
Vb NIC1 (is de primaire) en die geef je metric 1 en NIC2 (standby) geef je metric 10 ofzo.

De "default route" bij NIC2 zal niet gebruikt worden zolang NIC1 operationeel is.

Maar in de praktijk gaat de NIC niet zoveel stuk hoor. Je moet mischien overwegen om met een load-balancer te werken met daarachter 2 webserver (met dezelfde content) om gehele server-uitval vb op te vangen.

[mbr99]

Allen dank voor het meedenken!

[mbr99]

Dit klinkt eenvoudig. Je kan dus probleemloos op beide nic's een gateway invullen (ondanks de melding die je daarop krijgt) zolang je de prio (metric) in de volgorde naar keuze instelt?

jvanhambelgium schreef op maandag 13 juli 2009 @ 19:15:
[...]


Kan perfect hoor, je moet gewoon wel effe een andere "metric" meegeven hé !
Vb NIC1 (is de primaire) en die geef je metric 1 en NIC2 (standby) geef je metric 10 ofzo.

De "default route" bij NIC2 zal niet gebruikt worden zolang NIC1 operationeel is.

Maar in de praktijk gaat de NIC niet zoveel stuk hoor. Je moet mischien overwegen om met een load-balancer te werken met daarachter 2 webserver (met dezelfde content) om gehele server-uitval vb op te vangen.

[TrailBlazer]

Je lost natuurlijk maar een heel klein stukje redundantie op door er een 2e nic in te hangen. Er kan natuurlijk veel meer stuk gaan dan dat. Ik zou eerder denken aan 2 redundante loadbalancers/firewalls/servers. Dit is IMHO de enige manier om het echt goed redundant te krijgen.

[mbr99]

Klopt. Dat hebben we ook staan zoals ik in het eerste bericht al schreef, 2 lijnen, 2 firewalls, 2 switches, maar de servers staan niet 'dubbel'. Loadbalancers en mirror servers is natuurlijk een nog mooiere oplossing maar ligt niet in de lijn van het budget vrees ik.

TrailBlazer schreef op dinsdag 14 juli 2009 @ 08:52:
Je lost natuurlijk maar een heel klein stukje redundantie op door er een 2e nic in te hangen. Er kan natuurlijk veel meer stuk gaan dan dat. Ik zou eerder denken aan 2 redundante loadbalancers/firewalls/servers. Dit is IMHO de enige manier om het echt goed redundant te krijgen.

[brid]

loadbalancing kun je ook door windows 2003 servers zelf laten doen
Weet alleen niet of dat kan bij je externe lokatie.

http://www.lockergnome.co...g-in-windows-server-2003/

[Verwijderd]

mbr99 schreef op maandag 13 juli 2009 @ 16:19:
Hoi allen,

We hebben een webserver hangen extern op een co-locatie achter een firewall. De site heeft altijd 1 ip-adres gehad waarop de site benaderbaar was. Wij willen naar een situatie toe dat als de NIC1 uit zou vallen, dat NIC2 het overneemt. Inmiddels hebben wij een 2e lijn liggen met een ander publiek IP-adres, die verbonden aan een 2e firewall, geheel gescheiden.

Het gaat fout met het gateway probleem op Windows 2003 server. Je kunt geen 2e gateway instellen. NIC 1 heeft 10.0.0.1 als gateway en NIC2 de 10.0.1.1 (beide sub C). Laten we de G leeg op NIC1, luistert de site prima naar de website via NIC2, en andersom ook. Maar beide G's invullen, gaat fout. Dan pakt hij er 1, geen idee of dit willekeurig gaat overigens.

Heeft er iemand praktijk ervaring mee hoe je dit het beste kunt aanpakken?

Even heel simpel hoor maar kun je die 2 nic's niet teamen? goedkoop en efficient.

[Verwijderd]

leuk_he schreef op maandag 13 juli 2009 @ 18:20:
Wikipedia: Round robin DNS

Dit moet je dus echt nooit toepassen voor webservers of andere servers!!! Dit kan je alleen veilig toepassen voor mailservers.

[TrailBlazer]

Ja want google is ook gek.

[Verwijderd]

Verwijderd schreef op woensdag 15 juli 2009 @ 09:15:
[...]


Dit moet je dus echt nooit toepassen voor webservers of andere servers!!! Dit kan je alleen veilig toepassen voor mailservers.

voor webservers is dit een hele valide manier hoor. simpele maar effectieve loadverdeling (maar geen redundantie), maar in dit geval niet zinvol aangezien we het hebben over een webserver met 2 ip's en niet 2 webservers.

verder eens dat je niet zoveel redundant kan krijgen als je maar op 1 webserver draait en als je 2 internet connecties hebt, deze niet moet afleveren op de webservers maar netwerkapparatuur daarvoor moet balancen.

[Verwijderd]

jvanhambelgium schreef op maandag 13 juli 2009 @ 19:15:
[...]


Kan perfect hoor, je moet gewoon wel effe een andere "metric" meegeven hé !
Vb NIC1 (is de primaire) en die geef je metric 1 en NIC2 (standby) geef je metric 10 ofzo.

De "default route" bij NIC2 zal niet gebruikt worden zolang NIC1 operationeel is.

Maar in de praktijk gaat de NIC niet zoveel stuk hoor. Je moet mischien overwegen om met een load-balancer te werken met daarachter 2 webserver (met dezelfde content) om gehele server-uitval vb op te vangen.

Zelfs dan is het nog steeds gedoemd om te mislukken. het gaat je met deze opzet niet lukken om het dns-nic1 ip continue te gebruiken tot nic1 eruit ligt en dan "heel internet" opeens van de dnsnaam-nic2 ip te voorzien.

[jvanhambelgium]

Verwijderd schreef op woensdag 15 juli 2009 @ 16:31:
[...]


Zelfs dan is het nog steeds gedoemd om te mislukken. het gaat je met deze opzet niet lukken om het dns-nic1 ip continue te gebruiken tot nic1 eruit ligt en dan "heel internet" opeens van de dnsnaam-nic2 ip te voorzien.

Yups, je hebt gelijk hoor, maar dat is natuurlijk een probleem dat je met een load-balancer moet opknappen.
Of op Layer2 met link-bonding oid. Maar dat moet de colo-provider dan weer willen voorzien.

Het is altijd wel wat ;-)

[TrailBlazer]

Verwijderd schreef op woensdag 15 juli 2009 @ 16:31:
[...]


Zelfs dan is het nog steeds gedoemd om te mislukken. het gaat je met deze opzet niet lukken om het dns-nic1 ip continue te gebruiken tot nic1 eruit ligt en dan "heel internet" opeens van de dnsnaam-nic2 ip te voorzien.

Dat werkt prima hoor. Cisco noemt dit een Global site selector die polled continue beide ip's en geeft op DNS queries voor een bepaalde hostname enkel ip's uit die alive zijn.

[jvanhambelgium]

@Trailblazer,

Als je natuurlijk zo'n GSS ervoor zet hé. Maar hij heeft gelijk als hij zegt dat zonder enige load-balancer what-so-ever deze oplossing wat mank werkt ;-)
Met enige gepruts op een bind-doos kan dat wel opgelost worden natuurlijk (vb met een ping scriptje dat bij no-reply effe de dns-file aanpast)

Onze datacenters gebruiken ACE-modules op onze 6500-core voor klanten die zo'n prutsen willen.

[Verwijderd]

Verwijderd schreef op woensdag 15 juli 2009 @ 16:25:
[...]


voor webservers is dit een hele valide manier hoor. simpele maar effectieve loadverdeling (maar geen redundantie), maar in dit geval niet zinvol aangezien we het hebben over een webserver met 2 ip's en niet 2 webservers.

Ik ben zelf DNS admin dus ik weet wel een beetje waarover ik praat

De 2 hoofdredenen waarom DNS load balancing sucked:

1) DNS kan niet monitoren of een server up of down is.
2) DNS is niet op de hoogte van de daadwerkelijke load op een server.

[TrailBlazer]

Dan heb je de verkeerde DNS loadbalancer. Cisco GSS kan dat allemaal wel doen namelijk.

[DiedX]

Verwijderd schreef op donderdag 16 juli 2009 @ 13:32:
1) DNS kan niet monitoren of een server up of down is.
2) DNS is niet op de hoogte van de daadwerkelijke load op een server.
3) De DNS TTL hoeft niet gehonoreerd te worden door de provider van de bezoeker.

[TrailBlazer]

tja uit de RFC's

TTL a 32 bit signed integer that specifies the time interval
that the resource record may be cached before the source
of the information should again be consulted. Zero
values are interpreted to mean that the RR can only be
used for the transaction in progress, and should not be
cached. For example, SOA records are always distributed
with a zero TTL to prohibit caching. Zero values can
also be used for extremely volatile data.

bron

SHOULD This word, or the adjective "RECOMMENDED", mean that there
may exist valid reasons in particular circumstances to ignore a
particular item, but the full implications must be understood and
carefully weighed before choosing a different course.

bron
kortom als ze de TTL negeren zijn het gewoon prutsers want dan gaan ze er blijkbaar mee akkoord dat de gebruiker iets niet kan bereiken
Maar vaak in organisaties waar zoiets speelt weten ze dit soort dingen wel op internet is het wel wat anders ja.

[Verwijderd]

TrailBlazer schreef op donderdag 16 juli 2009 @ 14:39:
Dan heb je de verkeerde DNS loadbalancer. Cisco GSS kan dat allemaal wel doen namelijk.

Ik gebruik de "de facto standaard dns software" ontwikkelt door het internet systems consortium: bind

Wat Cisco allemaal kan interesseert me geen ruk, ik ga van afsproken standaarden (RFC's) uit.

[TrailBlazer]

Wie zegt dat die Cisco zich niet aan die RFC houdt dan. MS DNS voldoet ook prima naar mijn mening beetje kortzichting om het af te serveren omdat het niet van het ISC afkomt
Hee kijk wie er bij de members staan van het ISC
https://www.isc.org/about/members
Cisco.

[Verwijderd]

TrailBlazer schreef op donderdag 16 juli 2009 @ 15:30:
Wie zegt dat die Cisco zich niet aan die RFC houdt dan. MS DNS voldoet ook prima naar mijn mening beetje kortzichting om het af te serveren omdat het niet van het ISC afkomt
Hee kijk wie er bij de members staan van het ISC
https://www.isc.org/about/members
Cisco.

1) Laat mij maar een RFC zien waarin Cisco GSS beschreven staat. Ik wens je veel succes

2) Je probeert duidelijk dingen recht te praten die krom zijn en dat begint een beetje vermoeiend te worden. Ik heb duidelijk aangeven dat loadbalancing d.m.v. afgesproken DNS standaarden niet de way to go is. Normaal gesproken is dit bij iedereen met een beetje kennis van zaken bekend vanwege de door mij genoemde nadelen. En maar blijven doorzagen over Cisco GSS .......

P.s. dit is het laatste wat ik er over zeg.

[TrailBlazer]

Het enige wat jij erover zegt is dit.

Verwijderd schreef op donderdag 16 juli 2009 @ 13:32:
[...]


Ik ben zelf DNS admin dus ik weet wel een beetje waarover ik praat

De 2 hoofdredenen waarom DNS load balancing sucked:

1) DNS kan niet monitoren of een server up of down is.
2) DNS is niet op de hoogte van de daadwerkelijke load op een server.

Beide redenen zijn op te vangen met een device wat dit wel kan.
Uit de RFC die ik reeds gequote had

Zero values can also be used for extremely volatile data.

Waarom zit dit dan in de RFC en waarom zou je er dan alsnog geen gebruik van mogen maken?

Dit is natuurlijk geen manier om een discussie te voeren dit is gewoon een troll

Normaal gesproken is dit bij iedereen met een beetje kennis van zaken bekend vanwege de door mij genoemde nadelen.