Linux DFS voor Webplatform

[raymonvdm]

Ik probeer hier een platform te maken met de volgende onderdelen


- Loadbalancer
- Webserver 1
- Webserver 2
- MySQL server

Nu is de loadbalancer geen probleem, maar ik zit met de data voor de webservers. Ik wil eigenlijk geen gebruik maken van een centrale storage want dan is er weer een Single Point of Failure

Nu kun je in Windows gebruik maken van DFS, maar wat is hiervoor de beste oplossing voor onder linux.

Ik wil eigenlijk alleen de WWWroot syncen maar wel op een dusdanige manier dat het bij het uploaden van content niet uitmaakt op welke frontend de client zit. De wwwroot staat "gewoon" op een ext3 partitie net als het os van de machine.

[TigerMooD]

Als de data op de website niet heel regelmatig veranderd zou je misschien simpelweg via Rsync elke paar minuten de data kunnen syncen?

Of denk ik nou weer te makkelijk voor jou situatie?

[raymonvdm]

Ik ben al bezig om te kijken naar rsync en dat lukt wel om te syncen. Maar op beide frontends kan data verwijderd en aangemaakt worden. Ik moet dus ook beide kanten op syncen.


En daarmee kan ik nu syncen van A naar B, maar als ik op A iets verwijder dan blijft het bestand staan op B. Daarnaast is het best zo dat een bestand ook op B verwijderd kan worden en dan natuurlijk ook op A moet verdwijnen.


Ik ben nu aan het kijken naar OpenAFS

[ Voor 45% gewijzigd door raymonvdm op 18-11-2010 15:53 ]

[Rmg]

Is openAFS niet wat je zoekt? een distributed filesystem voor linux http://www.openafs.org/

[Rolfie]

Is je MySQL database ook niet een SPOF?

Wat je eventueel kan doen, afhankelijk hoeveel data je hebt,
Plaats je data op locatie C, en laat dat repliceren naar A en B. Alles wordt dan vanuit C gedaan, dus dat is je master.

[ACM]

Wordt OpenAFS nog ontwikkeld? Wow

Wellicht is DRDB ook wat voor je.

[raymonvdm]

Nadeel is alleen dat je met DRBD een Master (RW) en een slave hebt (R) dit.


Het idee is om 2 redundante webservers die ook standalone kunnen werken zonder een shared storage.

[axis]

raymonvdm schreef op donderdag 18 november 2010 @ 13:48:
Ik ben al bezig om te kijken naar rsync en dat lukt wel om te syncen. Maar op beide frontends kan data verwijderd en aangemaakt worden. Ik moet dus ook beide kanten op syncen.

Clustered filesystems kunnen je meer kopzorgen geven dan ze oplossen.

Ik zou als ik jou was kijken naar je bedrijfsprocessen. Ik zou kijken of je naar de architectuur kunt waarbij je 1 master node hebt (die alle updates/deletes doet) en slave node(s), die alleen data lezen. En dan rsyncen van master naar slave(s). Of wellicht kun je wel alle muteerbare data juist in je database stoppen of iets dergelijks.

[DGTL_Magician]

ACM schreef op donderdag 18 november 2010 @ 22:18:
Wordt OpenAFS nog ontwikkeld? Wow

Wellicht is DRDB ook wat voor je.

Ieks. Als er iets is waar ik veel gezeik mee heb gehad is het dat wel.
Op dit moment ben ik meer een fan van GlusterFS, maar al met al blijven het een beetje hobby-bob oplossingen.

[Bastiaan V]

DGTL_Magician schreef op vrijdag 19 november 2010 @ 20:38:
[...]

Ieks. Als er iets is waar ik veel gezeik mee heb gehad is het dat wel.
Op dit moment ben ik meer een fan van GlusterFS, maar al met al blijven het een beetje hobby-bob oplossingen.

en wat zit er onder glusterFS dan ? (DRBD zou prima als block dev. onder gluster kunnen werken ;-) )

raymonvdm schreef op vrijdag 19 november 2010 @ 11:35:
Nadeel is alleen dat je met DRBD een Master (RW) en een slave hebt (R) dit.


Het idee is om 2 redundante webservers die ook standalone kunnen werken zonder een shared storage.

dit is al een tijdje niet meer zo.

Ik heb al een aantal productie clusters draaien in master-master configuratie (met GFS en OCFS als filesystem)

[ Voor 34% gewijzigd door Bastiaan V op 27-11-2010 18:05 ]

[_JGC_]

Mja, wat sommige mensen vergeten met DRBD is dat ze een cluster filesystem moeten draaien, en niet XFS, Reiser of ext3/4 over master-master DRBD gooien. Veel mensen maken die fout en roepen dan dat DRBD kut is.
Overigens, als ik zo zie wat de ervaringen van Tweakers.net zijn met OCFS... dan zou ik niet staan te springen om dat te implementeren.

Ik heb 2 jaar geleden nog eens getest met OpenAFS, werkte op zich goed, maar je replication is readonly. Als je de applicatie daarop aanpast is het op zich niet zo'n heel groot probleem.

[CyBeR]

Glusterfs kan gewoon met een lokaal filesystem eronder draaien en is voor dit soort setups eigenlijk ideaal. In mirror mode zetten en gaan met die banaan.

[B-Man]

CyBeR schreef op dinsdag 30 november 2010 @ 17:43:
Glusterfs kan gewoon met een lokaal filesystem eronder draaien en is voor dit soort setups eigenlijk ideaal. In mirror mode zetten en gaan met die banaan.

Maar actieve auto-heal bij uitval zit er nog steeds niet in, toch? (wel passief, bij request van file controle of die file op alle mirrors beschikbaar is)

[CyBeR]

B-Man schreef op maandag 13 december 2010 @ 08:23:
[...]

Maar actieve auto-heal bij uitval zit er nog steeds niet in, toch? (wel passief, bij request van file controle of die file op alle mirrors beschikbaar is)

Klopt zover ik weet, maar dat maakt niet echt uit toch? Duurt 't een momentje langer de eerste keer dat je een file request van een mirror die uitgevallen was.

[B-Man]

CyBeR schreef op maandag 13 december 2010 @ 13:24:
[...]


Klopt zover ik weet, maar dat maakt niet echt uit toch? Duurt 't een momentje langer de eerste keer dat je een file request van een mirror die uitgevallen was.

Nou, ik vind het nogal een risico. De scenario's die ik bekeken heb gebruikten 2 mirrors; Dat betekent dat je na het vervangen van een van de mirrors na uitval handmatig een auto-heal moet triggeren. Met andere woorden: alle bestanden in je filesystem aanraken omdat je anders bij uitval van de andere server dataverlies hebt (los van een eventuele backup, uiteraard).

Ik volg GlusterFS al een paar jaar, maar heb het vanwege dit soort zaken nog nooit in productie uitgerold. Los van het aantal bugs wat in de begindagen boven kwam drijven.

[CyBeR]

B-Man schreef op maandag 13 december 2010 @ 16:48:
[...]

Nou, ik vind het nogal een risico. De scenario's die ik bekeken heb gebruikten 2 mirrors; Dat betekent dat je na het vervangen van een van de mirrors na uitval handmatig een auto-heal moet triggeren. Met andere woorden: alle bestanden in je filesystem aanraken omdat je anders bij uitval van de andere server dataverlies hebt (los van een eventuele backup, uiteraard).

even een ls -lR draaien is genoeg daarvoor. kun je automatiseren als je wilt..

[silentsnake]

B-Man schreef op maandag 13 december 2010 @ 16:48:
[...]

Nou, ik vind het nogal een risico. De scenario's die ik bekeken heb gebruikten 2 mirrors; Dat betekent dat je na het vervangen van een van de mirrors na uitval handmatig een auto-heal moet triggeren. Met andere woorden: alle bestanden in je filesystem aanraken omdat je anders bij uitval van de andere server dataverlies hebt (los van een eventuele backup, uiteraard).

Ik volg GlusterFS al een paar jaar, maar heb het vanwege dit soort zaken nog nooit in productie uitgerold. Los van het aantal bugs wat in de begindagen boven kwam drijven.

Als je applicatie zo belangrijk dat je moet "auto-healen" dan bouw je je infrastructuur daar ook voor, en ga je geen houtje touwtje oplossingen bouwen lijkt me.

Bijvoorbeeld: Koop een Red Hat subscriptie, laat consultancy binnenhalen en bouw een cluster met een cluster filesysteem waar je zaken als distributed filesystems niet eens nodig heb. En als je geen redhat wilt dan heb je altijd nog andere bedrijven (denk Novell of Sun / Oracle) die ook clustering aanbied.

Als je bang bent dat je SAN een SPOF is dan kan je altijd nog een SAN to SAN copy gebruiken naar een 2e SAN, desnoods nog in een 2e datacenter. Wat HBAtjes er aan hangen en je kan een failover doen naar je andere SAN. Sowieso is een SAN zo resilient als het maar kan en het enige echte risico is dat je datacentrum ontploft.

Maar goed, hierboven hangt ook een kostenplaatje aan van een paar ton. Is je applicatie toch niet zo belangrijk? Kijk dan naar een practisch concept, zoals master-slave setup met rsync. Dat maakt je leven een heel stuk makkelijker Twee kanten op repliceren is gewoon lastig en kan een heleboel ellende geven.

Oh en zoals een van de bovenburen zei .. je MySQL is een grotere SPOF dan je storage

[Bastiaan V]

silentsnake schreef op woensdag 15 december 2010 @ 14:26:
[...]


Als je applicatie zo belangrijk dat je moet "auto-healen" dan bouw je je infrastructuur daar ook voor, en ga je geen houtje touwtje oplossingen bouwen lijkt me.

Bijvoorbeeld: Koop een Red Hat subscriptie, laat consultancy binnenhalen en bouw een cluster met een cluster filesysteem waar je zaken als distributed filesystems niet eens nodig heb. En als je geen redhat wilt dan heb je altijd nog andere bedrijven (denk Novell of Sun / Oracle) die ook clustering aanbied.

Als je bang bent dat je SAN een SPOF is dan kan je altijd nog een SAN to SAN copy gebruiken naar een 2e SAN, desnoods nog in een 2e datacenter. Wat HBAtjes er aan hangen en je kan een failover doen naar je andere SAN. Sowieso is een SAN zo resilient als het maar kan en het enige echte risico is dat je datacentrum ontploft.

Maar goed, hierboven hangt ook een kostenplaatje aan van een paar ton. Is je applicatie toch niet zo belangrijk? Kijk dan naar een practisch concept, zoals master-slave setup met rsync. Dat maakt je leven een heel stuk makkelijker Twee kanten op repliceren is gewoon lastig en kan een heleboel ellende geven.

Oh en zoals een van de bovenburen zei .. je MySQL is een grotere SPOF dan je storage

ach, mysql kan prima in een active-active cluster draaien, en wat raden ze daar aan als storege ? DRBD

De 'oplossing' (meer een lading buzzworden van de gemiddelde sales knakker NOFIof gaat het tegenwoordig zo slecht met de rhce-ers ?) die jij neerzet is normalieter een _beetje_ overkill voor een omgeving met 2 webservers ....

Ik zou echt kijken naar een drbd oplossing met eventueel ook mysql hier op.

[B-Man]

silentsnake schreef op woensdag 15 december 2010 @ 14:26:
[...]


Als je applicatie zo belangrijk dat je moet "auto-healen" dan bouw je je infrastructuur daar ook voor, en ga je geen houtje touwtje oplossingen bouwen lijkt me.

Bijvoorbeeld: Koop een Red Hat subscriptie, laat consultancy binnenhalen en bouw een cluster met een cluster filesysteem waar je zaken als distributed filesystems niet eens nodig heb. En als je geen redhat wilt dan heb je altijd nog andere bedrijven (denk Novell of Sun / Oracle) die ook clustering aanbied.

Als je bang bent dat je SAN een SPOF is dan kan je altijd nog een SAN to SAN copy gebruiken naar een 2e SAN, desnoods nog in een 2e datacenter. Wat HBAtjes er aan hangen en je kan een failover doen naar je andere SAN. Sowieso is een SAN zo resilient als het maar kan en het enige echte risico is dat je datacentrum ontploft.

Maar goed, hierboven hangt ook een kostenplaatje aan van een paar ton. Is je applicatie toch niet zo belangrijk? Kijk dan naar een practisch concept, zoals master-slave setup met rsync. Dat maakt je leven een heel stuk makkelijker Twee kanten op repliceren is gewoon lastig en kan een heleboel ellende geven.

Oh en zoals een van de bovenburen zei .. je MySQL is een grotere SPOF dan je storage

You're preaching to the choir

SPOFs uitsluiten heeft altijd een prijs ja, ik kijk dan ook niet naar gluster voor mijn werkprojecten. Echter: ik vind dat als je een mirrorfunctie aanbied het nogal een gemis is als je handmatig je cluster moet repareren. Immers: dit zou prima automatisch moeten kunnen verlopen in 99% van de gevallen.

Een oplossing die tussen een redundant san en (bijvoorbeeld) glusterfs inligt is een openfiler cluster of een nexenta cluster. Dat zijn zaken waarop sowieso fatsoenlijke support te krijgen is.

-- oh en vwb ontploffende datacenters: toevallig heb ik (o.a.) wat servers hangen bij Interconnect. Toevallig knalde daar verleden week de stroom ook uit. Toen bleek maar weer eens dat ook partijen als cheap tickets e.d. maar op 1 locatie hosten. Geografisch gescheiden hosting is schijnbaar toch te duur voor veel bedrijven.

[ Voor 8% gewijzigd door B-Man op 21-12-2010 12:30 ]

[CyBeR]

B-Man schreef op dinsdag 21 december 2010 @ 12:27:
[...]
-- oh en vwb ontploffende datacenters: toevallig heb ik (o.a.) wat servers hangen bij Interconnect. Toevallig knalde daar verleden week de stroom ook uit. Toen bleek maar weer eens dat ook partijen als cheap tickets e.d. maar op 1 locatie hosten. Geografisch gescheiden hosting is schijnbaar toch te duur voor veel bedrijven.

Yep. Om precies te zijn: de kosten tegen de baten op laten wegen is heel moeilijk. Uitval van een DC is namelijk niet superveelvoorkomend.

[TheNephilim]

Wij hebben hier gewoon een NFS fileserver, de files syncen we hiervanaf naar de webservers. Dus als je fileserver uitvalt, heb je inderdaad geen mogelijkheid meer om te syncen, maar dat is dan niet nodig. Dus een soort van semi-single-point of failure.

Zoals hier mensen zeggen, met een leuke RAID 5 ben je al best een eind. Je MySQL zal waarschijnlijk een groter probleem zijn, wat spof betreft.

[Bastiaan V]

Bernardo schreef op dinsdag 21 december 2010 @ 15:49:
...

Zoals hier mensen zeggen, met een leuke RAID 5 ben je al best een eind. Je MySQL zal waarschijnlijk een groter probleem zijn, wat spof betreft.

en dit dan ?

[lammert]

Er bestaat ook zoiets als een 2-way rsync, en het heet unison, plain en simpel. Lijkt in jouw situatie een stuk makkelijker dan distributed filesystems etc.

http://www.cis.upenn.edu/~bcpierce/unison/

Zit in ieder geval in de standaard ubuntu en debian repositories.

[TheNephilim]

Bastiaan V schreef op dinsdag 21 december 2010 @ 19:40:
[...]


en dit dan ?

MySQL Cluster is inderdaad een leuke oplossing, maar voor ons niet relevant geweest. De kosten waren te hoog en MySQL Cluster was vooral goed bij High Availability. De performance zal vast goed wezen, maar kostentechnisch was het efficiënter voor ons om gewoon replicatie te gebruiken. Alle "belangrijke" read-requests gaan gewoon naar de master en minder belangrijke dingen lezen we vanaf de slaves.

Dus we combineren eigenlijk een beetje van non-replicatie en replicatie.

[CAPSLOCK2000]

lammert schreef op woensdag 22 december 2010 @ 21:02:
Er bestaat ook zoiets als een 2-way rsync, en het heet unison, plain en simpel. Lijkt in jouw situatie een stuk makkelijker dan distributed filesystems etc.

http://www.cis.upenn.edu/~bcpierce/unison/

Zit in ieder geval in de standaard ubuntu en debian repositories.

Dit moet je hebben . Veel simpeler en betrouwbaarder dan clusterachtige dingen.

[Egbert]

glusterfs zou de uitgelezen oplossing moeten zijn voor dit probleem. Sinds de nieuwe versie 3.1 begin ik er ook enig vertrouwen in te krijgen. Deze automatiseert alles voor je, zodat je geen foute maakt, en een geteste configuratie gebruikt. Ik gebruikt het nog niet overigens, alleen als testje.
Voordeel van glusterfs: als het toch niet blijkt te werken, is het vaak maar één linkje (of mount bind) om ervoor te zorgen dat de files direct benaderd worden.

De huidige manier waarop ik dit soort dingen doe:
twee servers, met ieder twee drbd partities, die de servers onderling syncen. In een active-passive mode is op elke server één van de drbd partities actief. De ene server exporteert die partitie via nfs, de andere server gebruikt de partitie om de mysql databestanden op op te slaan. Heartbeat op beide servers zorgt voor fail over van het mysql en nfs ip in geval van uitval/storing van een server.
Dit werkt perfect en feilloos bij mij (de afgelopen 5 jaar, verschillende setups).

[Guru Evi]

Nexenta heeft een plugin voor zfs replicatie autocdp. Je kunt altijd shared storage gebruiken als alles dubbel uitgevoerd is.

[B-Man]

Hmm, ik lees net (op de frontpage) dat ubuntu in 11.04 ondersteuning krijgt voor OpenStack. Dus ik ff kijken wat dat voor iets is, en wat blijkt: het is een platform voor het opzetten van een private cloud met redundant storage. Dat laatste is interessant voor dit topic lijkt me. Details: http://www.openstack.org/projects/storage/

Het lijkt erop dat dit storage platform in productie gebruikt wordt door o.a. Rackspace.

[Verwijderd]

ubuntu heeft toch al 11.10 server?

had even gekeken maar zie niks op de homepagina staan..


ook wel handig Installing OpenStack Compute on Ubuntu
http://docs.openstack.org...dmin/content/ch03s02.html