GlusterFS che non riesce a montare all'avvio con Ubuntu 14.04

In precedenza ho chiesto di installare GlusterFS all'avvio di un server Ubuntu 12.04 e la risposta era che questo era buggy nel 12.04 e lavorato in 14.04. Curioso l'ho dato una prova su una macchina virtuale che funziona sul mio computer porttile e nel 14.04 ha funzionato. Poiché questo è stato critico per me, ho deciso di aggiornare i miei server in esecuzione fino al 14.04 solo per scoprire che GlusterFS non sta installando volumi localhost automaticamente.

Questo è un server Linode e fstab ha questo aspetto:

  • Ubuntu resolv.conf, non andare al nameserver successivo?
  • Replica di un server web linux
  • "Imansible utime: descrittore di file difettoso" quando si aggiorna ubuntu 8.04 a 10.04
  • Come ottengo rsyslogd per registrare un FQDN di un server anziché il suo nome host breve?
  • Come strappare un server Linux distro al core?
  • SSH riavviare e uccidere istanze?
  • # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 /dev/xvda / ext4 noatime,errors=remount-ro 0 1 /dev/xvdb none swap sw 0 0 /dev/xvdc /var/lib/glusterfs/brick01 ext4 defaults 1 2 koraga.int.example.com:/public_uploads /var/www/shared/public/uploads glusterfs defaults,_netdev 0 0 

    Il process di avvio ama così (intorno alla parte di assembly in networking, che sono l'unico fallimento):

      * Stopping Mount network filesystems [ OK ] * Starting set sysctls from /etc/sysctl.conf [ OK ] * Stopping set sysctls from /etc/sysctl.conf [ OK ] * Starting configure virtual network devices [ OK ] * Starting Bridge socket events into upstart [ OK ] * Starting Waiting for state [fail] * Stopping Waiting for state [ OK ] * Starting Block the mounting event for glusterfs filesystems until the [fail]k interfaces are running * Starting Waiting for state [fail] * Starting Block the mounting event for glusterfs filesystems until the [fail]k interfaces are running * Stopping Waiting for state [ OK ] * Starting Signal sysvinit that remote filesystems are mounted [ OK ] * Starting GNU Screen Cleanup [ OK ] 

    Credo che il file di registro /var/log/glusterfs/var-www-shared-public-uploads.log contiene l'indizio principale del problema, in quanto è l'unico che è veramente diverso da questo server in cui il assembly non funziona, e il mio server virtuale locale, where è:

     [2014-07-10 05:51:49.762162] I [glusterfsd.c:1959:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.5.1 (/usr/sbin/glusterfs --volfile-server=koraga.int.example.com --volfile-id=/public_uploads /var/www/shared/public/uploads) [2014-07-10 05:51:49.774248] I [socket.c:3561:socket_init] 0-glusterfs: SSL support is NOT enabled [2014-07-10 05:51:49.774278] I [socket.c:3576:socket_init] 0-glusterfs: using system polling thread [2014-07-10 05:51:49.775573] E [socket.c:2161:socket_connect_finish] 0-glusterfs: connection to 192.168.134.227:24007 failed (Connection refused) [2014-07-10 05:51:49.775634] E [glusterfsd-mgmt.c:1601:mgmt_rpc_notify] 0-glusterfsd-mgmt: failed to connect with remote-host: koraga.int.example.com (No data available) [2014-07-10 05:51:49.775649] I [glusterfsd-mgmt.c:1607:mgmt_rpc_notify] 0-glusterfsd-mgmt: Exhausted all volfile servers [2014-07-10 05:51:49.776284] W [glusterfsd.c:1095:cleanup_and_exit] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_transport_notify+0x23) [0x7f6718bf3f83] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_clnt_notify+0x90) [0x7f6718bf7da0] (-->/usr/sbin/glusterfs(+0xcf13) [0x7f67192bbf13]))) 0-: received signum (1), shutting down [2014-07-10 05:51:49.776314] I [fuse-bridge.c:5475:fini] 0-fuse: Unmounting '/var/www/shared/public/uploads'. 

    Lo stato del volume è:

     Volume Name: public_uploads Type: Distribute Volume ID: 52aa6d85-f4ea-4c39-a2b3-d20d34ab5916 Status: Started Number of Bricks: 1 Transport-type: tcp Bricks: Brick1: koraga.int.example.com:/var/lib/glusterfs/brick01/public_uploads Options Reconfigured: auth.allow: 127.0.0.1,192.168.134.227 client.ssl: off server.ssl: off nfs.disable: on 

    Se eseguo mount -a dopo l'avvio, il volume viene montato correttamente:

     koraga.int.example.com:/public_uploads on /var/www/shared/public/uploads type fuse.glusterfs (rw,default_permissions,allow_other,max_read=131072) 

    Un paio di file di log correlati mostrano questo:

    /var/log/upstart/mounting-glusterfs-_var_www_shared_public_uploads.log :

     start: Job failed to start 

    /var/log/upstart/wait-for-state-mounting-glusterfs-_var_www_shared_public_uploadsstatic-network-up.log :

     status: Unknown job: static-network-up start: Unknown job: static-network-up 

    ma sul mio server di prova, mostra esattamente lo stesso, quindi, non credo che questo sia rilevante.

    Qualche idea che cosa è sbagliato adesso?

    Aggiornamento : Ho provato il cambiamento di WAIT_FOR dalla networking statica alla networking e non funzionava ancora, ma tutti i messaggi [falliti] all'avvio spariscono. Questi sono i contenuti dei file di registro in queste condizioni:

    /var/log/glusterfs/var-www-shared-public-uploads.log contiene:

     wait-for-state stop/waiting 

    /var/log/upstart/wait-for-state-mounting-glusterfs-_var_www_shared_public_uploadsstatic-network-up.log contiene:

     start: Job is already running: networking 

    /var/log/glusterfs/var-www-shared-public-uploads.log contiene:

     [2014-07-11 17:19:38.000207] I [glusterfsd.c:1959:main] 0-/usr/sbin/glusterfs: Started running /usr/sbin/glusterfs version 3.5.1 (/usr/sbin/glusterfs --volfile-server=koraga.int.example.com --volfile-id=/public_uploads /var/www/shared/public/uploads) [2014-07-11 17:19:38.029421] I [socket.c:3561:socket_init] 0-glusterfs: SSL support is NOT enabled [2014-07-11 17:19:38.029450] I [socket.c:3576:socket_init] 0-glusterfs: using system polling thread [2014-07-11 17:19:38.030288] E [socket.c:2161:socket_connect_finish] 0-glusterfs: connection to 192.168.134.227:24007 failed (Connection refused) [2014-07-11 17:19:38.030331] E [glusterfsd-mgmt.c:1601:mgmt_rpc_notify] 0-glusterfsd-mgmt: failed to connect with remote-host: koraga.int.example.com (No data available) [2014-07-11 17:19:38.030345] I [glusterfsd-mgmt.c:1607:mgmt_rpc_notify] 0-glusterfsd-mgmt: Exhausted all volfile servers [2014-07-11 17:19:38.030984] W [glusterfsd.c:1095:cleanup_and_exit] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_transport_notify+0x23) [0x7fd9495b7f83] (-->/usr/lib/x86_64-linux-gnu/libgfrpc.so.0(rpc_clnt_notify+0x90) [0x7fd9495bbda0] (-->/usr/sbin/glusterfs(+0xcf13) [0x7fd949c7ff13]))) 0-: received signum (1), shutting down [2014-07-11 17:19:38.031013] I [fuse-bridge.c:5475:fini] 0-fuse: Unmounting '/var/www/shared/public/uploads'. 

    Aggiornamento 2 : Ho anche provato questo nel file upstart:

     start on (started glusterfs-server and mounting TYPE=glusterfs) 

    ma il computer non è riuscito ad avviarsi (non so perché ancora).

  • Quanti dati Linux legge sul boot medio?
  • Come eseguire script non privilegiati da rc.local all'avvio del sistema?
  • Come elencare i servizi / demoni avviati al boot _and_ controllare il loro ordine di caricamento
  • Perché il mio dispositivo iscsi causa che il mio server CentOS non riesca ad avviare?
  • Come utilizzare systemd-firstboot.service?
  • Easy Bootloader per azionamenti del pollice del USB
  • 5 Solutions collect form web for “GlusterFS che non riesce a montare all'avvio con Ubuntu 14.04”

    Sono riuscito a fare questo lavoro attraverso una combinazione di risposte in questo thread e questo: GlusterFS non riesce a montare sul boot

    Come per @Dan Pisarski modifica /etc/init/mounting-glusterfs.conf per leggere:

     exec start wait-for-state WAIT_FOR=networking WAITER=mounting-glusterfs-$MOUNTPOINT 

    Come per @ dialt0ne cambiare /etc/fstab da leggere:

     [serverip]:[vol] [mountpoint] glusterfs defaults,nobootwait,_netdev,backupvolfile-server=[backupserverip],direct-io-mode=disable 0 0 

    Funziona per me ™ su Ubuntu 14.04.2 LTS

    Ho eseguito lo stesso problema su AWS su ubuntu 12.04. Ecco alcune cose che puoi fare che hanno funzionato per me:

    • aggiungere altri tentativi di recupero nel tuo fstab

    Ciò consente di riprovare il server volfile mentre la networking non è disponibile.

    • aggiungere un server volfile di backup nel tuo fstab

    Ciò consentirà di montare il filesystem da un altro membro del server gluster se il primario è disatteso per qualche motivo.

    • aggiungere nobootwait nel tuo fstab

    Ciò consente all'istanza di continuare l'avvio mentre questo file system non è montato.

    Una voce di esempio dal mio attuale fstab è:

    10.20.30.40:/fs1 /example glusterfs defaults,nobootwait,_netdev,backupvolfile-server=10.20.30.41,fetch-attempts=10 0 2

    Non ho provato questo il 14.04, ma funziona bene per le mie 12.04 istanze.

    È un bug

    Questo è veramente un bug (la networking statica non è un lavoro, è un segnale di evento).

    Inoltre, l'utilizzo del lavoro di networking come suggerito in altre risposte non è la soluzione più corretta.

    Quindi, ho creato questo rapporto di bug e ho inviato una patch a questo problema.

    Come soluzione, puoi applicare la mia soluzione proposta (alla fine di questa risposta) e utilizzare l'opzione _netdev nel tuo fstab.

    Una spiegazione migliore è mostrata anche sopra, ma è ansible saltare questa spiegazione se vuoi.

    Spiegazione

    Questo è un bug nel mounting-glusterfs.conf . Può aumentare 30 secondi non necessari nello scaricamento in un server Ubuntu, o addirittura bloccare il process di avvio.

    A causa di questo errore, il process di mountall pensa che il mount non fosse riuscito (vednetworking "errori di assembly errati" in /var/log/boot.log ). Quindi, quando non utilizza flag nobootwait / nofail in /etc/fstab , il bug può bloccare il process di mount (e anche il process di avvio). Quando si utilizzano flag nobootwait / nofail , il bug aumenta il tempo di avvio in circa 30 secondi.

    Il bug è causato dagli errori seguenti:

    • Non c'è bisogno di aspettare che la networking sia in su. L' _netdev stesso ha la bandiera di mount _netdev che riprova il mount each volta che viene visualizzata un'interface;
    • Tuttavia, è necessario attendere il demone del server GlusterFS (per i mount che utilizzano localhost);
      • Questo è stato implementato in un vecchio impegno nel progetto a monte GlusterFS. Tuttavia, questo commit è stato sovrascritto;
    • È sbagliato utilizzare l' wait-for-state upstart per attendere un segnale. È usata per aspettare un lavoro. static-network-up è un segnale di events e non un lavoro;
      • Questo è il motivo per cui viene registrato il "lavoro sconosciuto: networking statica";
    • È sbagliato, quando si attende un process da avviare, non passando WAIT_STATE=running env var perché non è l'impostazione predefinita in wait-for-state .

    Soluzione

    /etc/init/mounting-glusterfs.conf :

     author "Louis Zuckerman <me@louiszuckerman.com>" description "Block the mounting event for glusterfs filesystems until the glusterfs-server is running" instance $MOUNTPOINT start on mounting TYPE=glusterfs task script if status glusterfs-server; then start wait-for-state WAIT_FOR=glusterfs-server WAIT_STATE=running \ WAITER=mounting-glusterfs-$MOUNTPOINT fi end script 

    PS: Utilizza anche l'opzione _netdev nel tuo fstab.

    Mi sono imbattuto in questo modo e voglio predicare questa risposta con l'affermazione che non sono un esperto in questo settore per cui è ansible una soluzione migliore per questo!

    Ma il problema sembra essere che lo static-network-up sia un evento, non il nome di un nuovo lavoro. Tuttavia, lo script wait-for-state pnetworkingnde che un nome di lavoro venga passato come valore WAIT_FOR. Così, l'errore di "lavoro sconosciuto" come hai scoperto in precedenza.

    Per risolvere il problema, ho cambiato /etc/init/mounting-glusterfs.conf, cambiando:

     exec start wait-for-state WAIT_FOR=static-network-up WAITER=mounting-glusterfs-$MOUNTPOINT 

    in:

     exec start wait-for-state WAIT_FOR=networking WAITER=mounting-glusterfs-$MOUNTPOINT 

    la creazione di reti è il nome di un lavoro effettivo (/etc/init/networking.conf) e credo che il lavoro che emette tipicamente la networking statica.

    Questa modifica ha funzionato per me su Ubuntu 14.04.

    Grazie per la spiegazione dettagliata, credo di capire molto di più. La soluzione più recente è quasi funzionante. I problemi (in realtà uno, dal momento che il primo implica il secondo):

    • le parti locali ( 127.0.0.1:/share ) ancora non montate
    • mounted TYPE=glusterfs mai soddisfatto, quindi i servizi che dipendono dal montato TYPE=glusterfs stato TYPE=glusterfs

    /etc/fstab :

     127.0.0.1:/control-share /mnt/glu-control-share glusterfs defaults,_netdev 0 0 

    /etc/init/mounting-glusterfs.conf : copia dall'alto

    /etc/init/salt-master.conf :

     description "Salt Master" start on (mounted TYPE=glusterfs and runlevel [2345]) stop on runlevel [!2345] limit nofile 100000 100000 ... 

    La quota locale deve essere montata a mano, o da un certo automatismo, il master di sale deve essere avviato manualmente dopo tutti i riavvolgimenti.

    Notato più tardi: lo script WAIT sopra in mount-glusterfs … blocca l'intera procedura di avvio, sembra che lo stato glusterfs-server non raggiunge l'esecuzione.

    Suggerimenti per Linux e Windows Server, quali Ubuntu, Centos, Apache, Nginx, Debian e argomenti di rete.