Data mirroring

[ju5t]

Een paar jaar terug heb ik eens gekeken naar het mirroren van data (zonder rsync) met wat volgens mij NFS was. Alleen kan ik me niet precies herinneren of het nu NFS was of niet. Ik wil 1 map tussen 2 servers synchroniseren (misschien meerdere mappen in de toekomst) en het liefste realtime. Nu kunnen we een SAN verbinden aan de twee servers maar dat is niet wat ik wil.

Zit ik nu in de verkeerde richting met NFS?

[Rinse Kloek]

NFS is een methode om een Filesystem te exporteren via het netwerk naar een ander systeem (Network File System). Je kan het gebruiken om bijvoorbeeld een data map op twee verschillende webservers te mounten zodat ze altijd dezelfde data serveren. In feite mirror je de data niet, maar verwijs je altijd naar dezelfde plek.

[Wido]

csync2? Daar kan het opzich wel mee.

[avanmessen]

Kijk eens naar DRBD ? Hiermee kan je real-time data
van een partitie replicaten tussen twee servers bvb.
Deze partitie kan je dan via NFS beschikbaar maken
via het netwerk.

http://www.drbd.org

DBRD en csync2 zijn beide produkten van LINBIT.

[ju5t]

Ik denk dat DRDB de lading niet helemaal dekt. We willen een paar directories synchroniseren en met DRDB moeten we deze gaan mounten als aparte partities, als ik het goed begrijp. Maar misschien mis ik een configuratie optie. Csync2 lijkt beter te passen. Maar om de een of andere reden krijg ik csync2 niet aan de gang. Statisch compilen met een sqlite source werkt niet en csync kan ook de geinstalleerde library niet vinden. Nu lijken er wat problemen te zijn met sqlite3 en csync2, maar een oplossing heb ik nog niet gevonden. Misschien dat iemand een idee heeft?

# rpm -qa | grep "sqlite"
python-sqlite-1.1.7-1.2.1
sqlite-3.3.6-5
sqlite-devel-3.3.6-5

En:

# ls -ltr /usr/lib/*sqlite*
-rwxr-xr-x 1 root root 386480 Sep 19  2009 /usr/lib/libsqlite3.so.0.8.6
lrwxrwxrwx 1 root root     19 Aug 11 09:17 /usr/lib/libsqlite3.so.0 -> libsqlite3.so.0.8.6
lrwxrwxrwx 1 root root     19 Aug 12 02:41 /usr/lib/libsqlite3.so -> libsqlite3.so.0.8.6

De output van config.log

configure:3287: checking for sqlite_exec in -lsqlite
configure:3317: gcc -o conftest -g -O2   conftest.c -lsqlite  -lrsync  >&5
/usr/bin/ld: cannot find -lsqlite
collect2: ld returned 1 exit status
configure:3323: $? = 1

Moet dat geen sqlite3 zijn?

Het gaat trouwens om een CentOS 5.6 VM. Verschillende versies van csync2 geven hetzelfde probleem.

[Wido]

Is er geen RPM voor csync2?

Ik heb csync gewoon onder Ubuntu geïnstalleerd en draaiend.

Ik denk inderdaad dat csync niet tegenover sqlite3 wil compilen, wellicht even met de Makefile spelen?

[ju5t]

Er is wel een RPM maar deze geeft dezelfde meldingen. Ook de rsync library kan niet gevonden worden. Misschien dat we toch maar terug moeten vallen op rsync. We gebruiken het alleen om webfiles te synchroniseren zover ik weet. Ik heb ook gelezen over FAM, is dat iets wat interessant kan zijn en heeft iemand hier al iets mee draaien?

Ik ben niet erg bekend met Makefiles trouwens, dus daar brand ik voor nu m'n vingers maar niet aan.

[systemdeveloper]

Je kunt DRBD gebruiken, dat mirrored inderdaad partities (harde partities of lvm) en je moet het dan inderdaad mounten. Met heartbeat (& co) kun je zo tegens een leuke failover maken, waarom mirror je anders tenslotte
Wij gebruiken het als een goedkope oplossing om data op een snelle raid 0 te zetten en de boel live te laten syncen naar een raid5 systeem zodat geen data verloren gaat als de raid 0 het begeeft.

Je kunt ook gluster gebruiken om een cluster fs te maken over 2 machines met een replicatecount van 2. Ook die data mount je overigens. Hier gebruiken we het om webserverdata te kunnen schalen en te mounten via een virtueel ip door een x aantal identieke webservers.

De *sync oplossingen zijn meestal niet live en vaak het 'probleem' dat ze in elke run complete bestanden syncen (of binaire mysql onderdelen). Leuk voor een backup, minder leuk als 'mirror', imho.