Du må være registrert og logget inn for å kunne legge ut innlegg på freak.no
X
LOGG INN
... eller du kan registrere deg nå
Dette nettstedet er avhengig av annonseinntekter for å holde driften og videre utvikling igang. Vi liker ikke reklame heller, men alternativene er ikke mange. Vær snill å vurder å slå av annonseblokkering, eller å abonnere på en reklamefri utgave av nettstedet.
  22 5980
Trigonoceps occipita
vidarlo's Avatar
Donor
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
Trigonoceps occipita
vidarlo's Avatar
Trådstarter Donor
Sitat av tore- Vis innlegg
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
Vis hele sitatet...
Det vert brukt via smb + nfs. Så den biten er grei.

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
Sist endret av tore-; 15. november 2016 kl. 22:05. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
▼ ... over en måned senere ... ▼
Trigonoceps occipita
vidarlo's Avatar
Trådstarter Donor
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.
Trigonoceps occipita
vidarlo's Avatar
Trådstarter Donor
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)
  smb_panic(): calling panic action [/usr/share/samba/panic-action 14600]
[2017/01/02 15:26:25.525850,  0] ../source3/lib/util.c:808(smb_panic_s3)
  smb_panic(): action returned status 0
[2017/01/02 15:26:25.525926,  0] ../source3/lib/dumpcore.c:318(dump_core)
  dumping core in /var/log/samba/cores/smbd
[2017/01/02 15:26:25.733371,  0] ../source3/modules/vfs_glusterfs.c:257(vfs_glus
ter_connect)
  marine: Initialized volume from server localhost
*** Error in `/usr/sbin/smbd': free(): invalid pointer: 0x00007fd00a57a110 ***
[2017/01/02 15:26:25.733991,  0] ../lib/util/fault.c:78(fault_report)
  ===============================================================
[2017/01/02 15:26:25.734019,  0] ../lib/util/fault.c:79(fault_report)
  INTERNAL ERROR: Signal 6 in pid 14618 (4.2.14-Debian)
  Please read the Trouble-Shooting section of the Samba HOWTO
[2017/01/02 15:26:25.734035,  0] ../lib/util/fault.c:81(fault_report)
  ===============================================================
[2017/01/02 15:26:25.734048,  0] ../source3/lib/util.c:788(smb_panic_s3)
  PANIC (pid 14618): internal error
[2017/01/02 15:26:25.735203,  0] ../source3/lib/util.c:899(log_stack_trace)
  BACKTRACE: 29 stack frames:
   #0 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(log_stack_trace+0x1a) [0x7fd0069
e3efa]
   #1 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(smb_panic_s3+0x20) [0x7fd0069e3f
e0]
   #2 /usr/lib/x86_64-linux-gnu/libsamba-util.so.0(smb_panic+0x2f) [0x7fd00869ce
5f]
   #3 /usr/lib/x86_64-linux-gnu/libsamba-util.so.0(+0x2407f) [0x7fd00869d07f]
   #4 /lib/x86_64-linux-gnu/libpthread.so.0(+0xf8d0) [0x7fd0088be8d0]
   #5 /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37) [0x7fd00508b067]
   #6 /lib/x86_64-linux-gnu/libc.so.6(abort+0x148) [0x7fd00508c448]
   #7 /lib/x86_64-linux-gnu/libc.so.6(+0x731b4) [0x7fd0050c91b4]
   #8 /lib/x86_64-linux-gnu/libc.so.6(+0x7898e) [0x7fd0050ce98e]
   #9 /lib/x86_64-linux-gnu/libc.so.6(+0x79696) [0x7fd0050cf696]
   #10 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x12ac65) [0x7fd008271
c65]
   #11 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x12bb64) [0x7fd008272
b64]
   #12 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(make_connection_smb2+0x
62) [0x7fd008273882]
   #13 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(smbd_smb2_request_proce
ss_tcon+0x664) [0x7fd0082873c4]
   #14 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(smbd_smb2_request_dispa
tch+0x9d8) [0x7fd008282118]
   #15 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(+0x13bd18) [0x7fd008282
d18]
   #16 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(run_events_poll+0x171) [0x7fd00
6a04081]
   #17 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(+0x4a2f7) [0x7fd006a042f7]
   #18 /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x8d) [0x7fd00540543d]
   #19 /usr/lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7fd0054055db]
   #20 /usr/lib/x86_64-linux-gnu/samba/libsmbd-base.so.0(smbd_process+0x718) [0x7fd0082715d8]
   #21 /usr/sbin/smbd(+0xadd0) [0x7fd008cf9dd0]
   #22 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(run_events_poll+0x171) [0x7fd006a04081]
   #23 /usr/lib/x86_64-linux-gnu/libsmbconf.so.0(+0x4a2f7) [0x7fd006a042f7]
   #24 /usr/lib/x86_64-linux-gnu/libtevent.so.0(_tevent_loop_once+0x8d) [0x7fd00540543d]
   #25 /usr/lib/x86_64-linux-gnu/libtevent.so.0(tevent_common_loop_wait+0x1b) [0x7fd0054055db]
   #26 /usr/sbin/smbd(main+0x17e5) [0x7fd008cf65e5]
   #27 /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fd005077b45]
   #28 /usr/sbin/smbd(+0x76e4) [0x7fd008cf66e4]
[2017/01/02 15:26:25.735365,  0] ../source3/lib/util.c:800(smb_panic_s3)
  smb_panic(): calling panic action [/usr/share/samba/panic-action 14618]
[2017/01/02 15:26:25.771036,  0] ../source3/lib/util.c:808(smb_panic_s3)
  smb_panic(): action returned status 0
[2017/01/02 15:26:25.771112,  0] ../source3/lib/dumpcore.c:318(dump_core)
  dumping core in /var/log/samba/cores/smbd
GlusterFS rapporterer ikkje om problemer, og det funker knall via fuse - utover lav hastighet...

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.
Trigonoceps occipita
vidarlo's Avatar
Trådstarter Donor
Sitat av tore- Vis innlegg
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?
Vis hele sitatet...
Det funker. Men på maskinvare som greier >150MB/s lokalt (fra disk som ikkje er i bricken til bricken) gir samba-deling av glusterfs (Fuse og nfs) ca. 3-5MB/s. Det er ikkje morsomt en gang, når filene stortsett er 10-15GB.

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...
Noe ekstra overhead blir det, men det burde være litt CPU og minne. Fra hvilken site deler du fra/til?
Vis hele sitatet...
Har glusterfs med ein brick, som er geo-replisert til ein anna brick. Volumet er ikkje replica, ettersom det funker dårlig med så høg latency som det vil få når ting er utplassert.
Sist endret av vidarlo; 3. januar 2017 kl. 09:05.
Sitat av vidarlo Vis innlegg
Har glusterfs med ein brick, som er geo-replisert til ein anna brick. Volumet er ikkje replica, ettersom det funker dårlig med så høg latency som det vil få når ting er utplassert.
Vis hele sitatet...
Forstår jeg riktig at du forsøker å dele volumet fra lokal site, der det ikke er replikert?

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.
Run gluster volume set VOLNAME stat-prefetch off to disable stat-prefetch for the volume.
Run gluster volume set VOLNAME server.allow-insecure on to permit insecure ports.
NOTE
This allows Samba to communicate with brick processes even with untrusted ports.
Edit the /etc/glusterfs/glusterd.vol in each Red Hat Gluster Storage node, and add the following setting:
option rpc-auth-allow-insecure on
NOTE
This allows Samba to communicate with glusterd even with untrusted ports.
Restart glusterd service on each Red Hat Gluster Storage node.
Run the following command to verify proper lock and I/O coherency.
# gluster volume set VOLNAME storage.batch-fsync-delay-usec 0
To verify if the volume can be accessed from the SMB/CIFS share, run the following command:
# smbclient -L <hostname> -U%
For example:
# smbclient -L rhs-vm1 -U%
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.17]

     Sharename       Type      Comment
     ---------       ----      -------
     IPC$            IPC       IPC Service (Samba Server Version 4.1.17)
     gluster-vol1    Disk      For samba share of volume vol1
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.17]

     Server               Comment
     ---------            -------

     Workgroup            Master
     ---------            -------
To verify if the SMB/CIFS share can be accessed by the user, run the following command:
#  smbclient //<hostname>/gluster-<volname> -U <username>%<password>
For example:
# smbclient //10.0.0.1/gluster-vol1 -U root%redhat
Domain=[MYGROUP] OS=[Unix] Server=[Samba 4.1.17]
smb: \> mkdir test
smb: \> cd test\
smb: \test\> pwd
Current directory is \\10.0.0.1\gluster-vol1\test\
smb: \test\>
When a volume is started using the gluster volume start VOLNAME command, the volume is automatically exported through Samba on all Red Hat Gluster Storage servers running Samba.
To be able to mount from any server in the trusted storage pool, repeat these steps on each Red Hat Gluster Storage node. For more advanced configurations, refer to the Samba documentation.
Open the /etc/samba/smb.conf file in a text editor and add the following lines for a simple configuration:
[gluster-VOLNAME]
comment = For samba share of volume VOLNAME
vfs objects = glusterfs
glusterfs:volume = VOLNAME
glusterfs:logfile = /var/log/samba/VOLNAME.log
glusterfs:loglevel = 7
path = /
read only = no
guest ok = yes
Hvis du ikke har konto der mener jeg du får en gratis ved å registrere deg her: https://developers.redhat.com/
Trigonoceps occipita
vidarlo's Avatar
Trådstarter Donor
Sitat av tore- Vis innlegg
Forstår jeg riktig at du forsøker å dele volumet fra lokal site, der det ikke er replikert?
Vis hele sitatet...
Nei, det er montert fra samme host som har brick'en. Altså mount -t glusterfs localhost::/foobar
Sitat av tore- Vis innlegg
Hvordan er ytelsen ved å lese rett fra fra monterte fuse-volumet, lokalt ?
Vis hele sitatet...
Har ikkje testa spesifikt på det, men tida for å kopiere inn data og iostat indikerer en plass rundt 150-180MB/s write og ~200MB/s read. Kjapp test med dd if=/dev/zero of=test bs=1G count=100 indikerer ca. 145MB/s, som er innafor. Det er uansett *milevis* over dei 3-5MB/s som er observert via samba...

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.
Sist endret av vidarlo; 3. januar 2017 kl. 12:59. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Kan du sende innholdet til smb.conf?
Trigonoceps occipita
vidarlo's Avatar
Trådstarter Donor
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)
I utgangspunktet har jo den der severity I, altså information. Det er ingen warnings eller errors i den loggen. Men antakeleg har ein eller anna funksjon endra seg nok til at ting kræsjer.

Med samba 4.5.3 fungerer Gluster ypperleg mot Samba, og problemet er per se løyst.
Sist endret av vidarlo; 3. januar 2017 kl. 21:38. Grunn: Automatisk sammenslåing med etterfølgende innlegg.
Finner du noe RDMA støtte? Bør kunne tygge unna det aller meste av båndbredde en klarer å hive på det.
Trigonoceps occipita
vidarlo's Avatar
Trådstarter Donor
Sitat av |d13m0b Vis innlegg
Finner du noe RDMA støtte? Bør kunne tygge unna det aller meste av båndbredde en klarer å hive på det.
Vis hele sitatet...
For Gluster-Gluster-sync finst det. Men det er forsåvidt mindre interessant i noverande situasjon
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.
Sist endret av larstobi; 4. januar 2017 kl. 09:16.
Sitat av vidarlo Vis innlegg
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.

[...]

Med samba 4.5.3 fungerer Gluster ypperleg mot Samba, og problemet er per se løyst.
Vis hele sitatet...
Bra det løste jeg da. Jeg hadde et alternativt forslag ved å opprette et vanlig smb-share som pekte til det lokale glusterfs mount-pointet. Men du har jo fått løst det så

Debian er jeg ikke godt kjent med, mener du Debian etch releasen ?
Trigonoceps occipita
vidarlo's Avatar
Trådstarter Donor
Sitat av tore- Vis innlegg
Debian er jeg ikke godt kjent med, mener du Debian etch releasen ?
Vis hele sitatet...
Jessie Versjonsnummera over referer til samba og gluster-versjoner.
<?php echo 'VIF'; ?>
datagutten's Avatar
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