'
Synkronisering av filsystem
Har to bokser som skal ha synkronisert ein partiosjon (/srv/foo)
Det er ikkje viktig at det er sanntidsreplikering, og det er i utgangspunktet einvegs synkronisering, som ein litt utvida backup (jada, er klar over forskjell mellom backup og mekanisk replisering). Ei (enkel) løysing er å køyre nattleg rsync i cron. Ein hake her er at det er stort datavolum (20TB) og treg linje. Kor mykje som vert endra i døgnet er litt ukjent, men i utgangspunktet bør 100Mb link holde til å synce nattleg. Eit alternativ er å køyre t.d. Gluster for å synce. Fordelen då er at write vert synkronisert begge vegar, og at det skjer kontinuerleg, og ikkje kunn nattleg. Er det folk som har erfaringer med replisering av den typen? |
Ville valgt å kjøre rsync. Enkelt og tilforlatelig når første backup er unnagjort. Etter det så blir det kun overført filer som er endret siden sist. det er vel tvilsomt om alle 20TB er nye data? Altså kan mengden data som skal skrives over kan være alt fra null til 20TB. Når du har tatt første kjøring, så kan du jo sjekke logger og se over en uke eller to hvor mye data som går per døgn.
Slik jeg ser det så vil live update ha potensiale for endel uforutsette hendelser, og når jeg drev med slikt så forsøkte jeg som default å kjøre rsync om natten. Stabilt og enkelt. |
Ville tippet rsync med delta, for å bytte CPU-tid mot overføringsvolum.
Jeg tar da utgangspunkt i å anta at dette dreier seg om store filer, og når du sier at det er ukjent hvor mye som er endret, tar jeg en sjangse og gjetter på at det er mindre endringer innad i filene enn det er nye filer. Men du må nok prøve deg litt frem for å få det helt optimalt. Kode:
rsync --checksum --inplace --no-whole-file |
Jeg ville ikke valgt rsync, da du må gjennom hele filsystemet hver gang for å sjekke etter endringer. Det vil ta ganske god tid på store datamengder og fører til unødvendig mye IO. Men dette høres ut som en ypperlig oppgave for DRBD. For disaster recovery er det ypperlig med et primary:secondary-oppsett.
|
Jeg ville valgt GlusterFS for dette, enkelt og sette opp, enkel arkitektur.
Har du noe erfaring med det, og hva er det som evt. gjør at du ikke velger Gluster ? |
Du er vel avhengig av en consensus node for at GlusterFS skal fungere optimalt, eller støtter den å gå o read-only hvis man mister tilkoblingen? GlusterFS er strengt tatt bare multi-primary drbd med distribuert locking på filsystemet. Alltid skummelt.
|
Det er du, men så lenge volumet aldri blir montert på den andre siden ville jeg ikke vært beskymret. Det er selvsagt ikke optimalt.
Han kan installere GlusterFS på en ledig node som er lokalt til /svr/foo, melde den inn i clusteret og ikke tildele/opprette noen volum der. Da fungerer den som en quorum node. Ressursbruken vil være minimal. Btw OP, hvordan bruker du filene under /srv/foo i dag ? Du må mounte volumet for bruk enten via nfs/smb/glusterfs |
Sitat:
Korleis handterer gluster file locking? Vil det gå bra om en i framtida utvider til tre noder der alle har rw-tilgang? Eg antar det bør støtte det, men kjekt å få litt input fra folk med hands on-erfaring, før eg bruker tredve timer på å lese :) Haken med rsync er, som vegardx er inne på, massive IO-behov, sjølv om ingenting er endra. Det er småkjipt, og kjem fort i konflikt med nattlige backuper. |
Ja det går greit å utvide med flere noder live, uten nedetid. Men kan være greit å sjekke arkitekturen litt nøyere før du gjør noen større endringer.
Eksempel på noe som kan være greit å vite: Oppretter du et volum med replica 2 (aka. mirror), så har du et filshare som finnes på server A og B. Hvordan replikering fungerer, er avhengig av klientprotokollen som brukes mot volumet. Brukes NFS, går du direkte mot server A (eller B), da er det gluster som er ansvarlig for overføre endringen til den andre serveren. Men, bruker du GlusterFS, blir klienten ansvarlig for å skrive en endring til begge nodene, samtidig (http://www.slideshare.net/openstacki...-and-openstack - slide #19) Du kan jo teste Gluster gratis fra Red Hat via AWS: https://engage.redhat.com/aws-test-drive-201308271223 - hvis jeg ikke tar feil er det med docs/tutorial, så da går ting litt fortere Hva med lsyncd? https://github.com/axkibe/lsyncd |
Endte opp med GlusterFS med georeplication.
Georep var ein tanke knotete å få sett opp skikkelig, men til gjengjeld er glusterfs skalerbart herfra til månen og tilbake. Optimalt sett hadde det vore kjekt å køyrt replication, og ikkje georep, men med 100Mb-link ser det ut til å bli i knappaste laget for skriveoperasjoner, samt at ved mange småfiler tar det tid å sjekke status. |
Så. Samba skar seg. Bigtime.
For det første inkluderte ikkje samba-vfs-modules i debian gluster-støtte (glusterfs.so), som gir samba direkte tilgang til gluster, uten å gå via NFS eller FUSE, som ser ut til å vere lite egna på grunn av ytelse (gir ca. 5MB/s, mot hardware som uten å svette takler 200MB/s). Kompilerte samba på nytt på debian-vis, med glusterfs på. Fekk då glusterfs.so som eg antok. Det fungerte imidlertid relativt dårleg - samba gikk på trynet så det sang etter når eg forsøkte å besøke sharen. Kode:
[2017/01/02 15:26:25.487324, 0] ../source3/lib/util.c:800(smb_panic_s3) Eg har i utgangspunktet veldig lite lyst til å bruke pakker som ikkje kjem fra debian, eller i det minste har source frå debian sine repositories, ettersom det gjer vedlikehold meir slitsomt... Nokon som har opplevd liknande problem med debian Jessie? |
Vet ikke om dette er lurt men, hva med å mounte cluster svaret lokalt på site A via Fuse, og så dele dette svaret ut via samba?
Noe ekstra overhead blir det, men det burde være litt CPU og minne. Fra hvilken site deler du fra/til? Har ingen erfaring med Debian, så lite jeg kan bistå med der. |
Sitat:
Om nokon har tips til performance tuning så har eg forsåvidt ingen prinsipielle innvendinger mot å gå den vegen - så lenge ytelsen kjem opp på minst en halv gigabit. Det er "levelig" inntil eg får forska meir på samba... :) Sitat:
|
Sitat:
Hvordan er ytelsen ved å lese rett fra fra monterte fuse-volumet, lokalt ? Hvordan har du satt opp volumet og smb ? Finner dette fra Red Hat sin dok (https://access.redhat.com/documentat...ide/index.html - seksjon 7.3) : Kode:
The following configuration items have to be implemented before using SMB with Red Hat Gluster Storage. |
Sitat:
Sitat:
Skal få testa resten av det du skreiv, takk for tips. Har sett gjennom lista du tipsa om, og det samme skjer. Glusterloggen indikerer at samba får tilgang, så i utgangspunktet haller eg mot at det er problem i samba, og ikkje gluster som gjer at samba går på tygga. |
Kan du sende innholdet til smb.conf?
|
Det er ikkje smb.conf som er problemet.
Har fått nøsta litt, og kompilerte samba frå scratch (4.5.3). Det ser enkelt og greit ut som debian sin samba er litt for gammal til å snakke fornuft med ny GlusterFS. Så held på å debianizere samba 4.5.3 no... Etter å ha nøsta meir i det, så ser det ut som sambaversjonen som er i debian (4.2.14) snakker Gluster 3.3 Når eg installerte gluster brukte eg gluster sine repositories, altså gluster 3.9. Det var gjerne idiotisk av meg, men tankegangen var at når utgjevar tilbyr oppdaterte pakker i repos, og ein så stor aktør som Redhat er med på laget, så er det antakeleg liten risiko. Vel. Sånn utover at protokollen er ung og endrer seg kjapt. Det var ei setning i gluster-vfs-loggen i samba som fekk meg til å tenke: Kode:
[2017-01-02 14:26:25.695049] I [MSGID: 114057] [client-handshake.c:1437:select_server_supported_programs] 0-marine-client-0: Using Program GlusterFS 3.3, Num (1298437), Version (330) Med samba 4.5.3 fungerer Gluster ypperleg mot Samba, og problemet er per se løyst. |
Finner du noe RDMA støtte? Bør kunne tygge unna det aller meste av båndbredde en klarer å hive på det.
|
Sitat:
|
Enda et alternativ er å bruke ZFS og overføre med send/receive. Du får da overført kun delta, men slipper å traversere filsystemet slik som rsync gjør. Ulempen er at du må installere kernel-modul, men det er lett og ingen ekstra jobb i ved oppgraderinger pga. DKMS.
|
Sitat:
Debian er jeg ikke godt kjent med, mener du Debian etch releasen ? |
Sitat:
|
Pakkene i debian stable er ofte utdaterte.
Jeg hadde mye trøbbel en gang når jeg kjørte debian og skulle ha inn noe fra tredjepart, jeg måtte kompilere den ene avhengigheten etter den andre for å få riktig versjon. Etter det har jeg brukt testing og der er pakkene mer oppdatert og jeg har ikke hatt problemer med at noe er utdatert der. I stretch er det nå samba 4.5.2: https://packages.debian.org/stretch/samba |
Alle tidspunkt er GMT +2. Klokken er nå 13:10. |