Dotaz: glusterfs + nfs ganesha

[Jan Potac]

Pomoci glusterfs se mi podarilo na 1 stanici vytvorit oddil slozeny z oddilu na dalsich stanicich. Novy oddil nazvany gfs jsem pripojil do /gfs. Nyni bych rad tento novy oddil zpristupnil pomoci nfs ganesha i na zbyvajici stanice. Nasel jsem dokumentaci a nejake navody, ale nedari se mi nfs ganesha uspesne spustit. Zkusil jsem nasdilet jiny adresar a vse funguje, ale bohuzel ne gluster. Muj export export_scratch.nfsv.conf pripojen k ganesha.conf:

EXPORT
{     # Export Id (mandatory, each EXPORT must have a unique Export_Id)
      Export_Id =2;
      # Exported path (mandatory)
      Path = "/gfs";
      # Exporting FSAL           
      FSAL
      {
          name = GLUSTER;
          hostname="10.4.32.100";
          volume="gfs";
      }
      Access_type = RW;
      Disable_ACL = true;
      Squash="No_root_squash";
      # Pseudo Path (required for NFS v4)
      Pseudo="/gfs";
      Protocols = "3", "4" ;
      Transports = "UDP","TCP";
      SecType = "sys";

V logu se nachazeji nasledujici chyby, ale nedari se mi je vyresit.

ganesha.nfsd-30764[main] fs_read_recov_clids_impl :CLIENT ID :EVENT :invalid clid format: node0
ganesha.nfsd-30764[main] fs_read_recov_clids_impl :CLIENT ID :EVENT :invalid clid format: node0
ganesha.nfsd-30764[main] glusterfs_create_export :FSAL :EVENT :Volume gfs exported at : '/'
ganesha.nfsd-30764[main] glusterfs_get_fs :FSAL :CRIT :Unable to initialize volume. Volume: gfs
ganesha.nfsd-30764[main] mdcache_fsal_create_export :FSAL :MAJ :Failed to call create_export on underlying FSAL GLUSTER
ganesha.nfsd-30764[main] fsal_cfg_commit :CONFIG :CRIT :Could not create export for (/gfs) to (/gfs)
ganesha.nfsd-30764[main] config_errs_to_log :CONFIG :CRIT :Config File (/etc/ganesha/exports/export_scratch.nfsv.conf:8): 1 validation errors in block FSAL
ganesha.nfsd-30764[main] config_errs_to_log :CONFIG :CRIT :Config File (/etc/ganesha/exports/export_scratch.nfsv.conf:8): Errors processing block (FSAL)
ganesha.nfsd-30764[main] config_errs_to_log :CONFIG :CRIT :Config File (/etc/ganesha/exports/export_scratch.nfsv.conf:1): 1 validation errors in block EXPORT
ganesha.nfsd-30764[main] config_errs_to_log :CONFIG :CRIT :Config File (/etc/ganesha/exports/export_scratch.nfsv.conf:1): Errors processing block (EXPORT)
ganesha.nfsd-30764[main] lower_my_caps :NFS STARTUP :EVENT :CAP_SYS_RESOURCE was successfully removed for proper quota management in FSAL
ganesha.nfsd-30764[main] lower_my_caps :NFS STARTUP :EVENT :currenty set capabilities are: = cap_chown,cap_dac_override,cap_dac_read_search,cap_fowner,cap_fsetid,cap_kill,cap_setgid,cap_setuid,cap_setpcap,cap_linux_immutable,cap_net_bind_service,cap_net_broadcast,cap_net_admin,cap_net_raw,cap_ipc_lock,cap_ipc_owner,cap_sys_module,cap_sys_rawio,cap_sys_chroot,cap_sys_ptrace,cap_sys_pacct,cap_sys_admin,cap_sys_boot,cap_sys_nice,cap_sys_time,cap_sys_tty_config,cap_mknod,cap_lease,cap_audit_write,cap_audit_control,cap_setfcap,cap_mac_override,cap_mac_admin,cap_syslog,cap_wake_alarm,cap_block_suspend,cap_audit_read+ep
ganesha.nfsd-30764[main] nfs_Init_svc :DISP :CRIT :Cannot acquire credentials for principal nfs

Mate s tim nekdo zkusenosti? Diky.

 

Odpovědi

[X]

Mas Gluster RPMs (>= 3.10) a Ganesha RPMs (>= 2.5)?

[Jan Potac]

Přílohy:

• gluster.png (98293 bytů)
• ganesha.png (83566 bytů)

Gluster je ve verzi 9.3 (z repozitare Filesystems) a ganesha 3.5

[X]

Muzes vyzkouset minimalni konfigraci z Gitu?

[Jan Potac]

Přílohy:

• ganesha.log (5451 bytů)
• export_scratch.nfsv.conf (527 bytů)

Vyzkouseno. Jen jen jsem prejmenoval testvol na me gfs. Log ukazuje stejne chyby, na ktere se mi nedari najit reseni.

[Jan Potac]

Jeste me napadlo pridat vypis gluster volume info

marincluster-N0:~ # gluster volume info
 
Volume Name: gfs
Type: Distribute
Volume ID: 728a6954-1886-4b9d-8dc9-181ee02348d3
Status: Started
Snapshot Count: 0
Number of Bricks: 4 
Transport-type: tcp
Bricks:
Brick1: 10.4.32.100:/gluster/brick
Brick2: 10.4.32.101:/gluster/brick
Brick3: 10.4.32.102:/gluster/brick
Brick4: 10.4.32.103:/gluster/brick
Options Reconfigured:
nfs.disable: on
transport.address-family: inet
storage.fips-mode-rchecksum: on

[X]

nfs.disable: on

Ha! Mas mit off.. mimo jine. ;)

[Jan Potac]

Jo, to jsem zkousel. Ale nejsem si moc jist, ze to mam byt off, kdyz chce byt pouzito nfs ganesha. Pri prepnuti do stavu 'off' to hlasi:

Gluster NFS is being deprecated in favor of NFS-Ganesha Enter "yes" to continue using Gluster NFS (y/n)

A i s timto ('off') nastavenim nfs-ganesha hlasi stejne chyby.

A navody na glusterfs + nfs ganesha maji vsude

nfs.disable on

treba zde

Ja si myslim, ze v tom bude jiny hacek:)

[Aleš Kapica]

Jasně že jo, protože nfs.disable off jasně říká, že se má deaktivovat vypnutí použití NFS serveru, který jede přes jádro. Jenže ten jede na každém stroji extra, což sebou přináší dost nepříjemná překvapení, když se data sdílená přes GlusterFS nestíhají synchronizovat.

Ganesha jede v userspace, proto se to vypnutí musí aktivovat. Měla co si vzpomínám několik záludných háčků, ovšem největší problém byl výkon. Stíhala s bídou obsloužit jen třetinu strojů. A to byl důvod proč šla k ledu.

[Aleš Kapica]

Měla co si vzpomínám několik záludných háčků,…

O kterých se dokumentace jaksi nezmiňovala. Týkaly se právě konfigurace, a co bylo nejhorší, ta nebyla konzistentní ani mezi verzemi. Což je problém na který naráží nyní i tazatel.

[Jan Potac]

Problem jsem vyresil tak, ze jsem gluster oddil pripojil primo v /ets/fstab na kazdem stroji

10.4.32.100:/gfs /mnt/scratch glusterfs defaults,_netdev,backupvolfile-server=10.4.32.100,xlator-option=transport.address-family=inet 0 0

Zatim to vypada, ze to nejak funguje napric vsemi stroji. Musim to trochu otestovat nez to uznam za fungujici. Prvne jsem mel predstavu, ze oddil pripojim pomoci nfs-client, proto muj puvodni dotaz. Ale pokud toto reseni bude fungovat, necham to tak. Jsem zvedav.

[Want]

Každopádně by to mělo komunikovat pokud možno na samostatné, oddělené síti. To nfs se využívá pro připojení zařízení co v ní nejsou.

[Aleš Kapica]

V jiné diskuzi jsem zmínil infrastrukturu, postavenou nad sheepdogem. Už neexistuje, tak ji mohu popsat. Byly to dva fyzické stroje, fungující jako nody pro sheepdog. Virtuály, postavené na CoreOS spouštěl pacemaker – vždy přes localhost. Protože blokové zařízení bez clustrového FS nemůže používat paralelně víc zařízení, sdílely se data právě přes glusterfs. Díky tomu s nimi mohly pracovat jak virtuální, tak hostitelské stroje.

Datová komunikace sheepdogu probíhala odděleně, přes samostatný interface, propojený napřímo, mimo switch. S největší pravděpodobností někdo po přestěhování blbě zapíchnul kabely. A protože netušil jak to funguje začal zmatkovat. Přitom je stačilo zapíchnout správně a srovnalo by se to samo.

[Ruža Becelin]

Bylo by mozne to detailneji popsat v blogu?

Diky

[Aleš Kapica]

Je to zbytečné. Jak jsem zjistil, sheepdog už není součástí žádné distribuce a kód se nedá zkompilovat. Vyžadovalo by to hlubší revizi, což je nad rámec mého zájmu. Binární balík se jinak zdá funkční, protože má jen minimální závislosti.

[Ruža Becelin]

Oki, np

[Aleš Kapica]

Nakonec to nebyla taková trága, takže jsem se toho sheepdogu ujal a forknul původní repo. Zkompilovat to už jde. Mám v plánu takový menší pokus. Otázkou je, bude-li sheepdog fungovat nad NFS. V zásadě by s tím neměl být problém a pokud by tomu tak skutečně bylo, dávalo by to zajímavé možnosti.

[Ruža Becelin]

Pekne

Ted se dole divam, ze dole je (c) od NTT, to by leccos vysvetlovalo

Jestli budu mit chvilku, zkusim to prohnat testlabem, kde mam RPM distra, jestli to pujde zkompilovat...

[Want]

Zkompilovat to jde. Testoval jsem s corosyncem ale lepší by to bylo se zookeperem. Mimochodem sheepdog by měl fungovat i přes ipv6.