2 servers high availability setup

[floorcula]

Hey,

Momenteel draait mijn website op 1 server. Ik heb nog ergens een vps'je welke het over kan nemen maar de site wordt nu te groot om zo maar even om te zetten en bovendien zou dat handmatig gaan. Omdat ik bang ben dat er ooit een keertje wat kapot gaat aan server 1 heb wil ik er nog een server bijkopen en
het zooitje dan zo configureren dat dit niet meer zo gemakklijk offline gaat als er een service uitvalt. Bovendien wil ik er ook graag wat snelheidswinst uit halen door de load naar de php/mysql backend te verdelen mits beide servers online zijn natuurlijk

Ik heb al gedacht aan virtualisatie maar de snelheid daarvan bevalt me niet en de kosten nog minder. Mijn grootste zorg is hardware uitval op dit moment. Het datacenter is vlak bij mij in de buurt, goedkoop en betrouwbaar. Daarom wil ik daar graag daar een tweede server plaatsen. Mocht het echt mis gaan dan heb ik op 2 locaties backups van de server (hoera synology).

Op die server draait nginx (icm php-fpm) en mysql

Mijn idee was om de 2 servers te mirroren met unision/lsyncd voor de bestanden en 2-weg mysql replication met 2 master servers voor de database.

Beide servers zouden een privaat ip adres krijgen en samen 1 publiek ip adres delen.

Vervolgens wil ik met heartbeat en ucast in de gaten houden of machine a nog wel werkt. Als dat niet het geval is moet machine b het publieke ip adres overnemen van machine a

Nu zit ik met een paar conceptuele vraagjes waar jullie hopelijk meer vanaf weten dan ik

1. Zie ik dit verkeerd en is er een betere manier ?
2. Ik zou ook graag de load tussen de 2 machines willen verdelen. Dat kan nginx heel gemakkelijk door 2 backend servers te configureren via de private ip adressen. Maar hoe ga ik er mee om als server a of server b er mee stopt. Dan werk namelijk ook 1 van de prive ip adressen niet meer. - dit blijkt nginx met een simpele config zelf af te kunnen handelen !
3. Zou het werken om meer dan 1 miljoen foto's met unison en lsyncd gesynchroniseerd te houden ?
4. De jongen van het datacenter riep. Pas op voor de ARP cache als je het ip adres van de andere server overneemt maar ik kan daar op internet weinig over terugvinden (wel wat een ARP cache is maar niet dat het problemen zou geven in dit geval). Komt dat omdat het ook geen probleem is en dat ucast dit allemaal afhandelt of zie ik het verkeerd en is het wel een probleem ?

Heel erg bedankt voor het inzicht dat jullie me zouden kunnen geven !

[ Voor 4% gewijzigd door floorcula op 19-09-2012 09:22 ]

[Varienaja]

Een active-active cluster is moeilijk. Ik heb zelf een active-passive cluster gebouwd, en daarin spiegel ik de data van de database (en eventueel al het andere wat op beide locaties gelijk moet zijn) met drbd. In mijn geval hebben we 10GBit glas tussen de servers, maar drbd kan je prima ook zo configureren, dat het met een lagere bandbreedte werkt.

Je moet alle services met heartbeaker/pacemaker doen: een publiek IP-adres delen; de database starten/stoppen; het filesysteem waarop de gespiegelde data staat mounten/unmounten, en de webserver starten/stoppen.

Bereid je voor op een vrolijk stukje inleren als je Linux-HA nog niet kent!

[floorcula]

Hi Thx voor je antwoord, ik ga het sowieso eerst met 2 vitrulele machines testen achter mn eigen buro. Ik moet je bekennen dat ik het wel leuk vind om zoiets te leren :-)

ik heb ook naar drbd gekeken maar dat is denk ik voor mij niet zo spannend omdat er niet zo veel bestanden wisselen. Sessies gebruik ik niet, en er worden niet meer dan een paar foto's per minuut ge-upload. Bovendien worden de foto's door nginx via backsteam opgehaald en ge-cached dus zelfs als het niet synchroon loopt is het niet eens zo spannend.

Je zegt dat een active-active cluster moeilijk is. Waarom is een active-active cluster moeilijk ? Wat zou het probleem zijn met mijn opstelling ?

[Rob Coops]

Met jouw opstelling is het grote probleem van een active active cluster wie de load gaat verdelen...

Als server 1 de load moet verdelen dan is dat een kritiek punt in de opstelling want gaat het ding dood dan heb je een probleem als server 2 dat werk doet is het het zelfde verhaal. Als je er een load balancer voor hangt dan heb je ook weer het probleem wat als de load balancer faalt...

We hebben de opstelling hier zo gemaakt dat het verkeer via twee verschillende routers en netwerk providers het gebouw binnen komt, de load balancers zijn ook redundant uitgevoerd en natuurlijk de servers ook... op die manier kun je voorkomen dat je een probleem hebt met welk onderdeel dan ook dat faalt nu heb jij neem ik aan niet het budget dat een erg grote multinational heeft dus dat is denk ik overkill voor jouw setup.

Als je een active-passive setup wilt gebruiken dan moet je je af vragen of je dat in het zelfde data center wilt doen. Immers als je data center om welke reden dan ook faalt... je maakt in 1 data center dan ook nooit een disaster recovery oplossing maar alleen een high availability oplossing.

Voor een HA opstelling is het inderdaad van belang om de bestanden in sync te houden. Welke software het best is hier voor hangt erg af van de site zelf. Als je erg veel statisch bestanden hebt is het van belang dat je simpel weg eens in de zo veel tijd de nieuwe bestanden op de primaire server vind en die naar de backup server kopieert. Afhankelijk van hoe belangrijk de bestanden zijn kun je dat zelfs maar eens per week doen met een simpel scriptje dat alle bestanden jonger dan een week vind en die even naar de andere server weg schrijft daar heb je niet noodzakelijkerwijs speciale software voor nodig. Als het van belang is dat je een zo recent mogelijke recovery point objective (RPO) hebt (de tijds delta tussen de primaire en secondaire server) dan is het wel verstandig om daar aparte software bij te zoeken.

Voor de rest is inderdaad het overhevelen van een IP van machine 1 naar machine 2 iets dat niet altijd zonder horten of stoten gaat. Omdat machines die met deze servers kletsen nu eenmaal een IP to MAC tabel (ARP tabel) bijhouden en dus best wel eens op die manier in de problemen zouden kunnen komen. Nu denk ik dat je dit stukje even moet lezen om te weten waarom je hier op moet letten: http://en.wikipedia.org/w...rotocol#ARP_announcements

Voor de rest zou ik zeggen veel plezier met het in lezen in het linux HA gebeuren het is niet altijd even makkelijk afhankelijk van hoe veer je wilt gaan. Ik ben toevallig een van de mensen die de linux code hier voor geschreven heeft tegen gekomen en dat verklaart meteen een heleboel wel een aardige man trouwens al is hij soms wat lastig te volgen

[fredkroket]

Rob Coops schreef op donderdag 20 september 2012 @ 13:05:
We hebben de opstelling hier zo gemaakt dat het verkeer via twee verschillende routers en netwerk providers het gebouw binnen komt, de load balancers zijn ook redundant uitgevoerd en natuurlijk de servers ook... op die manier kun je voorkomen dat je een probleem hebt met welk onderdeel dan ook dat faalt nu heb jij neem ik aan niet het budget dat een erg grote multinational heeft dus dat is denk ik overkill voor jouw setup.

2 DSL verbindingen geeft ook een stukje schijn vertrouwen. Wel eens meegemaakt dat er gegraven werd rond het pand... Toen hadden we gewoon 2 niet werkende DSL-verbindingen. Beide van een andere partij.

Je zou dan ook echt moeten zorgen dat je aan 2 fysiek gescheiden systemen hangt en dat je verbinding ook echt op verschillende plaatsen het gebouw binnen komt.

[ Voor 9% gewijzigd door fredkroket op 20-09-2012 13:14 ]

[Bjornski]

Is het niet goedkoper en een heel stuk makkelijker om met een of twee VPSen op een redundant servercluster te draaien?

Bijvoorbeeld;

• één backend-vps voor mysql, eventueel opslag van foto's, etc...
• één (of een paar als de load te groot wordt) webservers + een (virtuele) loadbalancer

In dat geval is je hardware redundant. Als er een host faalt, start je VPS gewoon weer op een andere host op.
Als de software faalt, plaats je een snapshot of backup terug.

Mijn bedrijf heeft bovengenoemde setup draaien op twee sans, zonder single point of failure. Er zijn genoeg bedrijven die je op een dergelijke setup een VPSje willen verhuren, tegen een fatsoenlijk bedrag (lager dan de kosten die jij maakt voor je colo + aanschaf en afschrijving van je servers + kosten voor beheer).

Over ARP cache;
De ARP tabel is de tabel die elk apparaat dat IP verkeer verstuurd bijhoudt, met daarin informatie over welk IP adres hoort bij welk MAC adres. Als een apparaat IP verkeer wil verzenden naar een IP adres, dan stuurt dat apparaat eerst een broadcast; "Wie heeft IP adres a.b.c.d., meldt je bij d.e.f.g.h.".

Veel ISP's proberen de hoeveelheid ARP aanvragen (en dus broadcasts) te beperken door maximaal eens in de zoveel tijd hun coreswitches ARP aanvragen te laten doen. 15 minuten schijnt min of meer gangbaar te zijn.

Stel je voor, de coreswitch van je provider heeft net zijn ARP tabel ververst en vlak daarna gaat je primary node stuk. De secundary node neemt het IP over, maar die coreswitch is daar pas 15 minuten later achter.
In de tussentijd is er geen verkeer mogelijk naar dat IP.
Is wel op te lossen met "gratuitous ARP", of door simpelweg ook een virtueel MAC adres te gebruiken, maar het wordt er niet makkelijker op.

[floorcula]

Bjornski schreef op donderdag 20 september 2012 @ 13:22:
Is het niet goedkoper en een heel stuk makkelijker om met een of twee VPSen op een redundant servercluster te draaien?
....

Het probleem wat ik daar mee heb ik dat de performance vaak slecht is op belangrijke tijdstippen. ik heb heel wat goedkope en dure vps boeren geporbeert maar nog nergens de performance gehaald die ook maar in de buurt kwam van mijn eigen server (8 core snelle intel, 8 GB geheugen)

[b][message=38959593,noline]
Over ARP cache;
De ARP tabel is de tabel die elk apparaat dat IP verkeer verstuurd bijhoudt, met daarin informatie over welk IP adres hoort bij welk MAC adres. Als een apparaat IP verkeer wil verzenden naar een IP adres, dan stuurt dat apparaat eerst een broadcast; "Wie heeft IP adres a.b.c.d., meldt je bij d.e.f.g.h.".

Veel ISP's proberen de hoeveelheid ARP aanvragen (en dus broadcasts) te beperken door maximaal eens in de zoveel tijd hun coreswitches ARP aanvragen te laten doen. 15 minuten schijnt min of meer gangbaar te zijn.

Stel je voor, de coreswitch van je provider heeft net zijn ARP tabel ververst en vlak daarna gaat je primary node stuk. De secundary node neemt het IP over, maar die coreswitch is daar pas 15 minuten later achter.
In de tussentijd is er geen verkeer mogelijk naar dat IP.
Is wel op te lossen met "gratuitous ARP", of door simpelweg ook een virtueel MAC adres te gebruiken, maar het wordt er niet makkelijker op.

Thx, dat maakt het duidelijker ! Heel fijn !!
Ik vind max 15 minuten offline in geval van een server crash acceptabel maar ik was idd al met GARP aan het stoeien.

[floorcula]

Rob Coops schreef op donderdag 20 september 2012 @ 13:05:
Met jouw opstelling is het grote probleem van een active active cluster wie de load gaat verdelen...

Als server 1 de load moet verdelen dan is dat een kritiek punt in de opstelling want gaat het ding dood dan heb je een probleem als server 2 dat werk doet is het het zelfde verhaal. Als je er een load balancer voor hangt dan heb je ook weer het probleem wat als de load balancer faalt...

Dat is juist het mooie, server 1 deelt een ip adres met server 2. Op beide servers draait nginx die de upstream verzoeken (dus de php pagina's) naar beide server verdeelt. nginx is dus altijd maar vanaf het publieke ip adres beschikbaar (server 1 default). Als server 1 crashed dan neemt server 2 automatisch het ip adres van server 1 over en draait het zooitje weer door.

Als je een active-passive setup wilt gebruiken dan moet je je af vragen of je dat in het zelfde data center wilt doen. Immers als je data center om welke reden dan ook faalt... je maakt in 1 data center dan ook nooit een disaster recovery oplossing maar alleen een high availability oplossing.

Je hebt gelijkt! Dat is de beste manier om redundant te zijn. Ik ben alleen meer op zoek naar een soort active/active oplossing (omdat ik dat leuk vind en omdat ik het anders zonde vind van mijn extra server capaciteit). Het dc is (voor de oplossing op dit specifieke stukje probleem) mijn zorg niet. Ik ga er nu even van uit dat het dc blijft werken. Zijn er problemen binnen het dc dan heb ik altijd nog een cold backup die (met wat handwerk) vrij snel in een ander dc weer aan de praat is. Ik moet dan alleen even aan de dns draaien en de laatste bestanden syncen,

Voor de rest is inderdaad het overhevelen van een IP van machine 1 naar machine 2 iets dat niet altijd zonder horten of stoten gaat. Omdat machines die met deze servers kletsen nu eenmaal een IP to MAC tabel (ARP tabel) bijhouden en dus best wel eens op die manier in de problemen zouden kunnen komen. Nu denk ik dat je dit stukje even moet lezen om te weten waarom je hier op moet letten: http://en.wikipedia.org/w...rotocol#ARP_announcements

Thx, ga ik direc doen ! Ik heb hier nu 2 vm's draaien waarbij het eea vlekkeloos werkt. Dus ik stop host a en binnen 10 secs staat host b online met het ip adre van host a. Volgende stap wordt dus inventariseren of dat in het dc ook zo gemakkelijk gaat.

Voor de rest zou ik zeggen veel plezier met het in lezen in het linux HA gebeuren het is niet altijd even makkelijk afhankelijk van hoe veer je wilt gaan. Ik ben toevallig een van de mensen die de linux code hier voor geschreven heeft tegen gekomen en dat verklaart meteen een heleboel wel een aardige man trouwens al is hij soms wat lastig te volgen

Haha dat geloof ik graag. Thx voor je bericht en je tijd !

[Bjornski]

floorcula schreef op vrijdag 21 september 2012 @ 14:00:
[...]

Het probleem wat ik daar mee heb ik dat de performance vaak slecht is op belangrijke tijdstippen. ik heb heel wat goedkope en dure vps boeren geporbeert maar nog nergens de performance gehaald die ook maar in de buurt kwam van mijn eigen server (8 core snelle intel, 8 GB geheugen)

[...]

Voor de kosten van twee snelle 8-core machines met relatief snelle storage + kosten voor de uurtjes die je nodig hebt om het redundant te maken, kun je een of twee hele stoere VMs een hele lange tijd laten draaien die qua performance waarschijnlijk rondjes rennen om jouw 8-core machine.

Veel (vooral grotere-) VPS boeren over-provisionen wel ja en dat merk je ook. Vooral over-provisioning van geheugen leidt tot vertraging en toch zie ik dat nog verbasingwekkend veel gebeuren om me heen.

Maar, zoals alles in de IT:

Our VPSes are Fast, Reliable and Cheap. Pick any two.

Mocht je nog een alternatief willen testen; stuur me even een DM.

[ Voor 0% gewijzigd door Bjornski op 26-09-2012 22:24 . Reden: Beetje late reactie. Sorry! ]

[Gomez12]

Bjornski schreef op donderdag 20 september 2012 @ 13:22:
Is het niet goedkoper en een heel stuk makkelijker om met een of twee VPSen op een redundant servercluster te draaien?
...
Is wel op te lossen met "gratuitous ARP", of door simpelweg ook een virtueel MAC adres te gebruiken, maar het wordt er niet makkelijker op.

GARP of virtual MAC adress moet veelal je hoster wel weer ondersteunen en dat doen de meeste hosters weer niet op het low-end segment.

Dat is een veel grotere reden (imho) om voor iets als VPS'en te gaan qua HA on the cheap. Je hebt er ook meewerking van buiten je eigen server voor nodig en dat zit er veelal niet in bij de low-end hosters terwijl de VPS-boeren dit allemaal al voor hun zelf geregeld hebben en je daar gewoon mee kan liften.

Enige wat je VPSen goed moet aftekenen is wat er wel / niet mag gebeuren bij onderhoud / calamiteiten. Ik weet nog een situatie dat VPS 1 gemoved werd van een machine die in onderhoud ging en toen terecht kwam op dezelfde machine als VPS 2 en toen klapte van die machine de hardware, daar zat die persoon dan met zijn HA-setup die compleet down was, die VPSen mochten niet op dezelfde machine staan behalve als er onderhoud was stond er in de kleine lettertjes

[floorcula]

Hey Dank jullie voor de opmerkingen !

Ik heb ondertussen toch de tweede server in de dc gehangen, aan elkaar gekoppeld en voorlopig draait het als een zonnetje. Het configureren en het uitzoeken vind ik juist leuk om te doen en daarmee leer ik weer een heleboel bij. Dat is ook wat waard :-)


Ik zal jullie advies toch ook eens opvolgen en op zoek gaan naar een goede VM hoster. Ik blijf sceptisch daarover want zoals vermeld, ik heb al heel wat ervaring vanuit met werk met zowel dure als goedkope vps hosters die op een gegeven moment altijd hun beloftes niet nakomen (en dan vraag ik echt niet zo veel, gewoon een snelle machine zonder gezeur !)