Persistent netwerk filesystem

[Boudewijn]

Hoihoi

Ik ben momenteel bezig met het opzetten van een copie van een bestaande mailserver.
Hierop gebruik ik maildir, dus niet 1 heel grote file per user met daarin alle mail.

Nu wil ik deze machine dus gebruiken als hot backup voor de primaire machine.
Hiervoor is het belangrijk dat beide belangrijke daemons (de MTA, postfix en de IMAP server , dovecot) bij de mail-store kunnen.

Nu kan ik wel een NFS share maken (via een SSH tunnel, het moet op internet blijven draaien...), echter is het dan zo dat als de server plat gaat (als in: niet bereikbaar is) de mailstore ook niet meer te vinden is.
Gevolg is dat de client ook de pineut is. Omgedraaid is dat niet het geval, omdat de server niet afhankelijk is van de client.

Een alternatief dat ik heb bedacht is vanaf beide hosts elke minuut rsyncen, maar dat lijkt me een vrij lmpe oplossing. Ook domdat ik het dan op applicatieniveau op ga lossen.

Weet iemand hier een goede oplossing voor?

Samba en NFS heb ik hierom al afgeschreven.

Mijn doel is dus een netwerkFS dat ook blijft werken nadat de verbinding met de andere host is weggevallen. Het is helemaal mooi als beide machines daarna weer kunnen syncen...

[Verwijderd]

Meerdere servers met DRBD in combinatie met GFS2 of OCFS2, of een vergelijkbare oplossing.

[Verwijderd]

Eigenlijk zijn er maar 2 veel gebruikte oplossingen:

1) Een mailcluster gaan bouwen met Heartbeat, DRBD etc etc. Dat werkt perfect maar wil je het goed doen dan is dit een niet eenvoudig klusje. Lees ook dit: http://readlist.com/lists...stfix-users/13/67961.html

2) Een backup mailserver configuren. Dit is erg eenvoudig te configureren en werkt perfect. Voorbeeldje: http://samat.org/node/con...act_as_a_backup_mx_server

Op mijn werk gebruiken we methode 1. Een heel zwaar mailcluster (heartbeat, loadbalancing etc etc) met 3 postfix frontend servers en 2 postfix backend servers.

[Boudewijn]

2: Tsja dat is een secundaire MX. Dat is er al.
Echter als de zaak uitvalt, dan is er geen toegang meer tot de bestaande mailstore.

Dat is gewoon onhandig.

1: Tikje overkill vrees ik, daarom zocht ik een oplossing op FS niveau.

[Rainmaker]

Ik zou ook "gewoon" gaan voor GFS2. Lijkt me echt de beste oplossing.

Een echte hobby oplossing die ik ooit gebruikt heb is het block device van de secondary via iscsi aanbieden aan de 1e server, en op de 1e server een software RAID1 zetten, die write-mostly en een flinke writeback had op de remote server.

*edit: haha, DRDB is dus gewoon deze oplossing. Wist helemaal niet dat dit bestond

[ Voor 12% gewijzigd door Rainmaker op 09-07-2009 00:31 ]

[Boudewijn]

Hmmm ja dan is dat mischien wel een goed plan om eens mee te gaan werken.


Nadeel van raid is dat ik complexiteit introduceer die ik in het FS zelf weg had willen abstraheren.

Snap trouwens niet dat niemand dit zelfde probleem heeft, maar goed .


Ik vraag me atm wel af in hoeverre die oplossing met iscsi trouwens echt veilig gaat zijn.

[Rainmaker]

Boudewijn schreef op donderdag 09 juli 2009 @ 00:47:
Hmmm ja dan is dat mischien wel een goed plan om eens mee te gaan werken.


Nadeel van raid is dat ik complexiteit introduceer die ik in het FS zelf weg had willen abstraheren.

Snap trouwens niet dat niemand dit zelfde probleem heeft, maar goed .


Ik vraag me atm wel af in hoeverre die oplossing met iscsi trouwens echt veilig gaat zijn.

Nou ja, DRBD gebruikt geen echte iscsi, maar ik bedoelde meer dat het deel van "delen van block device en dat in RAID zetten", overeen kwam met mijn hobby oplossing.

Ik blijf je aanraden om GFS2 te gebruiken in combinatie met OpenAIS o.i.d. (Redhat cluster suite)

Je hebt namelijk met DRBD geen echte failover van je applicatie, alleen van je block device. Je moet bij DRBD daarnaast nog iets van heartbeat gebruiken om applicatie failures te zien en op te vangen.

Tenminste, ik zit er net een half uurtje over te lezen, ik heb er geen echte ervaring mee.

[Boudewijn]

Nou de hele zaak is al gevirtualiseerd, dus de VM's worden gewoon gecopieerd en van een nieuw IP voorzien.
Als de zaak plat mocht gaan gooi ik wat DNS records om en draait alles weer.
Dus applicatie failover is niet direct nodig.

Het gaat puur om die datastore.

[Verwijderd]

Zo.

code:

postfix server 1 --
                         |---- datastore op san/raid array met clustered file system
postfix server 2 --

En hier waarom je een clustered filesystem nodig hebt want daar kom je niet onderuit:

Wikipedia: Shared disk file system

[_JGC_]

Desnoods kan je nog overstappen op een mailserver met replication support. Cyrus kan dit sinds 2.3. Heb er zelf nog niet mee gewerkt omdat mijn distributie nog geen serieuze 2.3 pakketjes heeft, en ik in 3 jaar tijd nog maar 2x een mailserver down heb gehad.

[Verwijderd]

Als je inderdaad echte failover wilt moet je kijken naar DRBD, Hartbeat, etc.

Een simpelere oplossing zou kunnen zijn: rsync

Werkt ook over ssh en kan erg snel 2 directories syncen met minimale bandwijdte en roundtrips. Zelf gebruik ik het voor backups maar een hot-standby in sync houden is feitelijk elke paar minuten een backup maken. Je zou een simpel scriptje kunnen gebruiken met een lock-file dat voorkomt dat 2 scripts tegelijk draaien en dat via cron elke zoveel minuten aanroepen.

Voordelen:
simpel, fysiek gescheiden, geen medewerking van de active server nodig, werkt over ssh, snel, zeker meet veel kleine bestanden en minimale bandwijdte. Je hot-standby kan tevens je backup server zijn en je script kan tevens als je hartbeat fungeren en meteen actie ondernemen als je active niet meer reageert.

Nadelen:
minder complex hoewel dat ook een voordeel kan zijn. Je mist wel dingen zoals IP fallover en alle andere features die Linux Clusters bieden. Kleine verhoging van je server-load hoewel dat erg zal meevallen denk ik. Niet 100% realtime waardoor je een paar minuten werk mist afhankelijk van hoevaak je sync'd.

Als je puur een oude mail server als hot-standby wilt inzetten is Linux Cluster met shared block-devices mischien wel erg overkill. Een simpel rsync script werkt net zogoed/mischien wel beter. Linux Cluster is handig voor active-active systemen waar je tot op de seconde fail-over wilt hebben zonder dat clients ook maar iets merken.

Edit:
Topic start niet helemaal goed gelezen, zie nu dat je rsync al had bedacht.

Vergeet niet dat DRBD, Hartbeat, etc aka Linux Cluster ook op aplicatie nivo werken. Je zult moeten afwegen of dat je de extra features nodig hebt maar zelf denk ik hoe complexer het geheel hoe makkelijker het breekt.

Aangezien je VM's gebruikt: LVM snapshot's mischien een idee?

[ Voor 11% gewijzigd door Verwijderd op 11-07-2009 06:33 ]

[Boudewijn]

Op welk gebied zouden LVM snapshots me helpen? De 'partitie' (nu nog een NFS mount naar een VM) is ongeveer 100gb met alles erop en eraan tourwens.

Die paar minuten aan data kwijt zijn is naar maar een acceptabel risico.

Desnoods kan je nog overstappen op een mailserver met replication support. Cyrus kan dit sinds 2.3. Heb er zelf nog niet mee gewerkt omdat mijn distributie nog geen serieuze 2.3 pakketjes heeft, en ik in 3 jaar tijd nog maar 2x een mailserver down heb gehad.

Dat kan, maar dan mag ik diezelfde oplossing nog eens uitvinden voor bijvoorbeeld mijn databases (even heel kort door de bocht) of mijn webserver. Ik heb liever een toepassingsagnostische oplossing


IP failover is een pre, alhoewel ik waarschijnlijk die IP adressen gewoon kan laten routeren naar mijn 2e machine. Dus dat zou ook opgelost moeten zijn.

CPU en memory resources: emerge 2x2 cores met 16gb mem. Dat ene rsync scriptje zet geen zoden aan de dijk.

Ik ga denk ik toch maar eens spelen met een rsync achtige setup, eens kijken of dat een beetje wil blijven werken.

En inlezen in heartbeat, maar ik gok dat ik daar gewoon te weinig tijd voor heb

[ Voor 3% gewijzigd door Boudewijn op 11-07-2009 15:37 ]

[lamko]

Als je snel resultaat wilt boeken is er een geweldig boek waar ook drdb en heartbeat aan de orde komt.
Pro Ubuntu Server Administration van Sander van Vugt

Hier heb ik super veel van geleerd en wordt op een echte praktijk manier uitgelegd met goeie voorbeelden.
En nee dit is geen reclame het is echt een geweldig boek. als je er geen zin in hebt om het boek te kopen.
Kun je m ook vast wel ergens illegaal downloaden als pdf alleen dit zou ik niet doen. het zijn n dikke 400 pagina's en die ga je echt niet achter je computer lezen. En het geld is het boek meer dan waard.

[Verwijderd]

Veel databases bieden al ondersteuning voor replication en vinden het denk ik ook niet leuk als rsync in hun database files gaat lopen spelen ivm met cached tables etc. Check de docs van MySQL5 bijvoorbeeld.

Voor Webservers is rsync juist weer heel erg geschikt. Gewoon je webroot en Apache config file's rsyncen en als er een verandering in je Apache config file's was doe je gewoon een /etc/init.d/httpd restart onder debian om de boel in sync te krijgen. Als je active dan wegvalt update je je netwerk config en kun je weer gaan.

Linux Cluster biedt dit ook allemaal maar is in mijn mening gewoon wat overkill hiervoor.Een simpel scriptje dat een rsync uitvoert en als rsync faalt met ping een simpel testje doet en dan met ip het virtuele ip overneemt en de nieuwe active wordt werkt denk ik heel goed voor statische web/mail toepassingen maar schiet natuurlijk erg tekort voor bijvoorbeeld een WoW realm server met tienduizenden clients waarvoor Linux Cluster is ontworpen.

[Boudewijn]

Docey, ik weet het, van die DBs.

Echter zijn er bij mij wat meer dingen die net zoals mijn mailserver die replicatie willen (subversion bijvoorbeeld, en wat FTP dingetjes).

clustering is echt zwaar overkill nu ik er wat meer over lees.
Ik vermoed dus dat het inderdaad rsync gaat worden.

WoW enzo doe ik niet nee, maar het subnet moet ook gerouteerd worden.... dus IP overname moet ik wel even uitkiezen (ucarp ga ik daar gewoon voor gebruiken denk ik).

[Verwijderd]

Blizzard gaat het ook niet leuk vinden als jij een WoW server voor tienduizendman gaat draaien

Zoals ik al zei inderdaad lijkt mij Linux Cluster overkill. Ook voor FTP servers is rsync perfect. SVN weet ik zo niet zeker maar ik denk dat SVN repo's perfect via rsync zijn te sync'en. Geweldig eigenlijk die rsync tool.

Ik heb ook eens wat onderzoek gedaan naar Linux Clusters en eigenlijk werkt het ook op applicatie nivo. Elke app die niet helemaal diskbased is gaat ook via DRBD net zohard onderuit als met rsync. Het is eigenlijk inherent aan de computer architectuur die uitgaat van een exclusieve virtuele geheugen addressruimte dat dit zo moeilijk is om dit niet op een applicatie specifieke manier op te lossen.

Eigenlijk moet je een soort DRBD maar dan voor het geheugen van je server hebben iets dat met VM's nu mischien wel mogelijk is voor hot-standby maar voor active-active setups zullen applicaties toch echt moeten worden herschreven met het idee dan hun virtuele geheugen niet exclusieve is. Iets dat vele databases immidels al hebben gedaan om redenen van load-balancing/performance zodat master-master setups mogelijk zijn.

[DaRoot]

lamko schreef op zaterdag 11 juli 2009 @ 19:45:
Als je snel resultaat wilt boeken is er een geweldig boek waar ook drdb en heartbeat aan de orde komt.
Pro Ubuntu Server Administration van Sander van Vugt

Hier heb ik super veel van geleerd en wordt op een echte praktijk manier uitgelegd met goeie voorbeelden.
En nee dit is geen reclame het is echt een geweldig boek. als je er geen zin in hebt om het boek te kopen.
Kun je m ook vast wel ergens illegaal downloaden als pdf alleen dit zou ik niet doen. het zijn n dikke 400 pagina's en die ga je echt niet achter je computer lezen. En het geld is het boek meer dan waard.

Redelijk off-topic in dit geval (wel bezig met DRDB, maar (nog) geen specifieke vragen), maar thanks voor de tip! goed boek!

[lamko]

Toevallig heb ik het boek vandaag nog gebruikt om wat info er op na te slaan.