Browse Tag: GlusterFS

Migrationsstrategie vom alten QNAP TS-412 zum GlusterFS

Nachdem ich jetzt mehrere Wochen mit dem GlusterFS rumgespielt habe, und auch reichlich Erkenntnise sammeln konte; wird es Zeit die Daten von meinem alten QNAP TS-412 zum GlusterFS zu verschieben.

Das klingt auf den ersten Moment sehr einfach, ist aber durch einige Randbedingungen nicht ganz so trivial, wie es klingt.

Vorraussetzungen/Bedarfsbeschreibung:

  • im QNAP stecken 4x 4TB HDD, die sollen im GlusterFS zum Einsatz kommen
  • ich habe nicht beliebig viel Geld, will also nur gerade soviel hinzu kaufen, wie umbedingt notwendig. 😉
  • die neue SpeicherkapazitĂ€t soll 7x 4TB sein
  • ich spendiere zwei spare HDDs

Sehen wir uns den bisherigen QNAP TS-412 im Detail an.

Ausgangssituation, die bisherige Datensenke

Das Zielbild im GlusterFS soll wie folgt sein.

Zielbild der neuen Datensenke

In meinem selbstgebauten GlusterFS Chassis sollen zukĂŒnftig 9 active Nodes stecken und ein spare Node (Brick), fĂŒr den Fall das ich mal einen defekten Node durchtauschen muss. Die oben rechts hell grau hinterlegten Nodes sollen die beiden redundanten Nodes darstellen, ist nur zur Visualisierung (im GlusterFS kann und will man, in dem von mir angestgrebten Dispersed-Modus, die Funktion nicht direkt pro Node festlegen). Diese beiden Nodes mĂŒssen von vorherein also immer anwesend sein. Der Spare Brick kommt spĂ€ter, wenn der ganze GlusterFS lĂ€uft und dient nur als Cold-Spare, sollte einer der Nodes die GrĂ€tsche machen.

Jetzt kommt die erste TĂŒcke eines GlusterFS im Dispersed-Modus: die Anzahl der Nodes ist nicht VerĂ€nderbar! Ich kann also nicht zur Laufzeit von 7 dispersed Nodes und 2 redundand Nodes auf sagen wir 10 dispersed Nodes und 2 redundand Nodes skalieren. Was geht ist, dass man neben einen dispersed GlusterFS einen weiteren (baugleichen) GlusterFS stellt und daraus einen Distributed Dispersed macht, aber die Gedanken an solches Konstrukt sind mir noch zu weit in der Ferne.. 🙂

Was wiederum geht, ist die HDDs in einem Dispered GlusterFS zu vergrössern, wobei immer die kleinste HDD die Menge des zur VerfĂŒgung stehenden Speichers angibt. Also in einem GlusterFS mit 7 x 4TB HDD dispersed + 2 x 4TB HDD replicated errechnet sich der Speicher nach den dispersed Nodes, entsprechend 7 x 4TB = 28TB.

Jetzt zeigt sich mein Dilemma, theoretisch brĂ€uchte ich neben den 9 x Odroid-HC2 ja nur 5 x 4TB HDDs kaufen, um die Ziel BestĂŒckung zu erhalten. Doch wohin in der Phase des Umbaus mit den Daten?

Da es ist unwarscheinlich ist, dass ich diese HDDS fĂŒr die Dauer von 1-2 Monaten kostenlos geliehen bekomme, muss ich mich diesem Problem anders nĂ€hern…

Zum GlĂŒck habe ich aus der vorherigen BestĂŒckung des QNAP TS-412 noch 4 x 2TB HDD rumliegen. Fand diese immer fĂŒr zu schade zum Wegwerfen, haben ja auch mal Geld gekostet!! Daraus ergibt sich folgende Option zu BestĂŒckung.

Schritt 1 des neuen GlusterFS

FĂŒr den ersten Schritt benötige ich also 9 x Odroid-HC2 (zu je ~65€ = 585€) und zusĂ€tzlich 5 x 4 TB HDDs (zu je ~190€ = 950€). Zusammen nicht ganz billig die Datensenke, aber dafĂŒr sollte die nĂ€chste Jahre/Jahrzehnte ruhe sein bei der Frage, wohin mit den ganzen Filmen aus den Mediatheken der öffentlich rechtlichen Fernsehsender.

ZurĂŒck zu meinem Dilemma. Mit der BestĂŒckung des GlusterFS in Schritt 1 mit den alten 2TB HDDs ist die SpeicherkapazitĂ€t also 7 x 2TB = 14TB

Also genau 2TB kleiner das was ich benötige… knurr…

Und hier geht der Eiertanz dann auch los.

Ich kann also nachdem ich Schritt 1 aufgesetzt habe die Daten von JBOD1 oder JBOD2 im ganzen von alt nach neu verschieben. Nehmen wir jetzt einfach mal JBOD2 und verschieben dann die Daten auf der GlusterFS.

Dann sollte nach dem Kopieren der Daten, von der initial zur VerfĂŒgung gestandenen SpeicherkapazitĂ€t 14TB – 8TB = 6TB, also noch 6TB vorhanden sein. Ich kann dann also JBOD2 auflösen und die HDD3 und HDD4 aus dem QNAP TS-412 ziehen, platt machen und durch diese beiden gebrauchten 4TB HDDs den Gluster ein StĂŒck umbauen – also folgendes Szenario ist das Ziel fĂŒr Schritt 2.

Schritt 2, nach dem Auflösen von JBOD2

Durch das Verschieben der zwei HDDs sind jetzt zwei kleine HDDs frei geworden, also 2 x 2TB HDDs. Diese brauchen wir im nÀchsten Datenverschiebezyklus.

Jetzt sind in JBOD1 noch bummelig 8TB auf 6TB unter zu bringen, was natĂŒrlich nicht geht..

Die Krux aus dieser Situation ist, dass ich 6 TB auf das GlusterFS kopiere und die verbleibenden 2TB auf eine der beiden ĂŒbrig gebliebenen 2 TB HDDs. Wenn dann die letzten beiden 4TB HDDs in der QNAP TS-412 frei sind, kommt Schritt 3 des Umbaus.

Zielzustand ist erreicht

Nachdem 3 Umbau ist der Zielzustand erreicht und die Daten von der ĂŒbrig gebliebenen 2TB HDD werden auch auf das GlusterFS kopiert.

…Tadaa…

Soweit zu meiner Planung – ob es klappt, ich werde berichten.

Installing GlusterFS on Odroid-HC2

Das GlusterFS lebt davon, dass es unterscheiden kann welches VerĂ€nderung im Filesystem zu welchem Zeitpunkt, auf welchem Node zu erst stattgefunden hat. Andernfalls könnte es ja nicht die AktualitĂ€t beurteilen. Aus diesem Grund ist es, laut Anleitung, sehr wichtig ein durchgehend zeitsynchrones Setup zu pflegen. An der Installation und Nutzung von NTP fĂŒhrt also kein Weg vorbei. Also zu erst mal NTP installieren und aktivieren.

---
- name: All hosts install ntp
  hosts: glusterfs
  become: yes
  
  tasks:
    - name: install ntp
      pacman:
        name: ntp
        update_cache: yes

Und ausrollen, mittlerweile traue ich mich es auch gleich auf den ganzen Node-Stapel auszurollen.

[ansible@barney ~]$ ansible-playbook ntp.yml

PLAY [All hosts install ntp] *******************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]

TASK [install ntp] *****************************************************************************************************************************************
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]

PLAY RECAP *************************************************************************************************************************************************
192.168.2.xx               : ok=2    changed=1    unreachable=0    failed=0   
192.168.2.xx               : ok=2    changed=1    unreachable=0    failed=0   
192.168.2.xx               : ok=2    changed=1    unreachable=0    failed=0   
192.168.2.xx               : ok=2    changed=1    unreachable=0    failed=0   
192.168.2.xx               : ok=2    changed=1    unreachable=0    failed=0   
192.168.2.xx               : ok=2    changed=1    unreachable=0    failed=0   

[ansible@barney ~]$ 

Der nĂ€chste Schritt ist also NTP Server fĂŒr die interne Uhr der Gluster-Nodes zu nutzen. Ich hab mir folgendes Playbook zusammen geschrieben.

---
- name: Build NTP config
  hosts: glusterfs
  become: yes
  
  tasks:
    - name: Stop service ntpd, if started
      service:
        name: ntpd
        state: stopped

    - name: delete orginal config
      file:
        path: /etc/ntp.conf
        state: absent

    - name: Touch on /etc/ntp.conf
      file:
        path: /etc/ntp.conf
        state: touch
        mode: "u=rw,g=r,o=r"

    - name: insert ntp.conf
      blockinfile:
        path: /etc/ntp.conf
        block: |
          #Associate to PTB's NTP pool
          server 0.arch.pool.ntp.org
          server 1.arch.pool.ntp.org
          server 2.arch.pool.ntp.org
          server 3.arch.pool.ntp.org

          # By default, the server allows:
          # - all queries from the local host
          # - only time queries from remote hosts, protected by rate limiting and kod
          restrict default kod limited nomodify nopeer noquery notrap
          restrict 127.0.0.1
          restrict ::1

          # Location of drift file
          driftfile /var/lib/ntp/ntp.drift

    - name: Start service ntpd, if not started
      service:
        name: ntpd
        state: started

    - name: Enable service ntpd, and not touch the state
      service:
        name: ntpd
        enabled: yes

    - name: set timezone to Europe/Berlin
      timezone:
        name: Europe/Berlin

Ein Kontrolle, mit einigen Minuten abstand zum ausgefĂŒhrten Playbook, zeigt auch, dass die NTP Server erreicht werden. Leider war es mir nicht möglich die Zeitserver der PTB in Deutschland zu nutzen. Auf deren Website standen zwar die FQDNs, welche aber weder auf NTP Anfragen noch auf Ping reagierten..

[ansible@GFS1 ~]$ ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
+217.79.179.106  192.53.103.108   2 u   38   64  177   12.028   -1.624   5.113
+eta.h6g-server. 205.46.178.169   2 u   39   64  177   15.882   -0.296   5.146
*89.163.128.33 ( 192.53.103.104   2 u   37   64  177   13.343   -6.665   5.282
+mx.pingless.com 130.149.17.21    2 u   35   64  177    8.285   -6.129   4.892
[ansible@GFS1 ~]$ 

Die Uhrzeit sollte also ĂŒber alle Nodes dann Synchron sein, nachdem ich das Playbook auf alle Gluster Nodes geworfen habe. Was ich gleich mal mache.

[ansible@barney ~]$ ansible-playbook ntp-config.yml

PLAY [Build NTP config] ************************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]

TASK [Stop service ntpd, if started] ***********************************************************************************************************************
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
changed: [192.168.2.xx]
ok: [192.168.2.xx]

TASK [delete orginal config] *******************************************************************************************************************************
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]

TASK [Touch on /etc/ntp.conf] ******************************************************************************************************************************
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]

TASK [insert ntp.conf] *************************************************************************************************************************************
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]

TASK [Start service ntpd, if not started] ******************************************************************************************************************
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]

TASK [Enable service ntpd, and not touch the state] ********************************************************************************************************
ok: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]

TASK [set timezone to Europe/Berlin] ***********************************************************************************************************************
ok: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]
changed: [192.168.2.xx]

PLAY RECAP *************************************************************************************************************************************************
192.168.2.xx               : ok=8    changed=5    unreachable=0    failed=0   
192.168.2.xx               : ok=8    changed=6    unreachable=0    failed=0   
192.168.2.xx               : ok=8    changed=6    unreachable=0    failed=0   
192.168.2.xx               : ok=8    changed=6    unreachable=0    failed=0   
192.168.2.xx               : ok=8    changed=6    unreachable=0    failed=0   
192.168.2.xx               : ok=8    changed=6    unreachable=0    failed=0   

[ansible@barney ~]$ 

Nachdem nun die Uhrzeit klar ist, geht es weiter mit dem aktivieren des GlusterfS Daemon, ohne welchen ein GlusterFS nicht funktioniert.

DafĂŒr habe ich mir folgendes Playbook ausgedacht.

---
- name: Start GlusterFS Daemon
  hosts: glusterfs
  become: yes
  
  tasks:
    - name: Start GlusterFS Daemon, if not started
      service:
        name: glusterd
        state: started

    - name: Enable GlusterFS Daemon service, and not touch the state
      service:
        name: glusterd
        enabled: yes

Dieses Playbook lief ebenfalls durch ohne Fehlermeldungen. Ich hab mit den GlusterFS Boardmitteln mal lokal auf Node GFS2 probiert, ob die anderen Nodes im Gluster-Service erreichbar sind.

[ansible@GFS2 ~]$ sudo gluster peer probe gfs1
peer probe: success. 

[ansible@GFS2 ~]$ sudo gluster peer probe gfs2                    
peer probe: success. Probe on localhost not needed

[ansible@GFS2 ~]$ sudo gluster peer probe gfs3
peer probe: success. 

[ansible@GFS2 ~]$ sudo gluster peer probe gfs4
peer probe: success. 

[ansible@GFS2 ~]$ sudo gluster peer probe gfs5
peer probe: success. 

[ansible@GFS2 ~]$ sudo gluster peer probe gfs6
peer probe: success. 

[ansible@GFS2 ~]$ 

Auf allen Nodes wurde der GlusterFS Daemon erfolgreich gestartet. Da ich von Hause aus sehr mistrauisch bin, habe ich den selben Test nach einem reboot ebenso nochmal durchgefĂŒhrt. Das Ergebnis war das selbe.

Nachdem also der GlusterFS Daemon sauber lĂ€uft, geht es daran die einzelnen Nodes als Peers per Playbook bekannt zu machen. Das Playbook dafĂŒr habe ich wie folgt formuliert.

---
- name: Start GlusterFS Daemon
  hosts: glusterfs
  become: yes
  
  tasks:
    - name: Create a trusted storage pool
      gluster_peer:
            state: present
            nodes:
                 - GFS1
                 - GFS2
                 - GFS3
                 - GFS4
                 - GFS5
                 - GFS6

Beim Ausrollen ist mir aufgefallen, dass es scheinbar nur notwendig ist, es gegen einen GlusterFS Node laufen zu lassen, da dieser dann wohl die Peers untereinander informiert. Anders kann ich mir das erfolgreiche Setup trotz der vielen Fehlermeldungen nicht recht erklÀren. Sei es drum, das Playbook ist durchgelaufen.

[ansible@barney ~]$ ansible-playbook gluster-peers.yml 

PLAY [Start GlusterFS Daemon] ******************************************************************************************************************************

TASK [Gathering Facts] *************************************************************************************************************************************
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]
ok: [192.168.2.xx]

TASK [Create a trusted storage pool] ***********************************************************************************************************************
fatal: [192.168.2.xx]: FAILED! => {"changed": false, "msg": "peer probe: failed: GFS1 is either already part of another cluster or having volumes configured\n", "rc": 1}
fatal: [192.168.2.xx]: FAILED! => {"changed": false, "msg": "peer probe: failed: GFS1 is either already part of another cluster or having volumes configured\n", "rc": 1}
fatal: [192.168.2.xx]: FAILED! => {"changed": false, "msg": "peer probe: failed: GFS1 is either already part of another cluster or having volumes configured\n", "rc": 1}
fatal: [192.168.2.xx]: FAILED! => {"changed": true, "msg": "peer probe: failed: GFS3 is either already part of another cluster or having volumes configured\n", "rc": 1}
fatal: [192.168.2.xx]: FAILED! => {"changed": false, "msg": "peer probe: failed: GFS1 is either already part of another cluster or having volumes configured\n", "rc": 1}
changed: [192.168.2.xx]
        to retry, use: --limit @/home/ansible/gluster-peers.retry

PLAY RECAP *************************************************************************************************************************************************
192.168.2.xx               : ok=2    changed=1    unreachable=0    failed=0   
192.168.2.xx               : ok=1    changed=0    unreachable=0    failed=1   
192.168.2.xx               : ok=1    changed=0    unreachable=0    failed=1   
192.168.2.xx               : ok=1    changed=0    unreachable=0    failed=1   
192.168.2.xx               : ok=1    changed=0    unreachable=0    failed=1   
192.168.2.xx               : ok=1    changed=0    unreachable=0    failed=1   

[ansible@barney ~]$

Aber wie bereits geschrieben geht es den Peers gut, denn die Abfrage des Glsuer Peer Status sieht richtig gut aus. Einmal auf GFS:

[ansible@GFS1 ~]$ sudo gluster peer status
Number of Peers: 5

Hostname: GFS2
Uuid: a8e86d86-d13d-45d6-97a1-b46619a4dfea
State: Peer in Cluster (Connected)

Hostname: GFS3
Uuid: a9696e90-0707-4de4-8430-479e7d3af8ac
State: Peer in Cluster (Connected)

Hostname: GFS4
Uuid: e01c2d0a-6491-4250-b531-5895be4788f0
State: Peer in Cluster (Connected)

Hostname: GFS5
Uuid: c26b3841-ff62-456a-b1d9-8e2842291535
State: Peer in Cluster (Connected)

Hostname: GFS6
Uuid: 67604b4f-85ba-47d5-96e4-a9dee66569ae
State: Peer in Cluster (Connected)

[ansible@GFS1 ~]$ 

Und einmal zur Sicherheit auch noch auf GFS6:

[ansible@GFS6 ~]$ sudo gluster peer status
Number of Peers: 5

Hostname: GFS1
Uuid: 48851509-5126-4d70-918d-841fc185ce21
State: Peer in Cluster (Connected)

Hostname: GFS2
Uuid: a8e86d86-d13d-45d6-97a1-b46619a4dfea
State: Peer in Cluster (Connected)

Hostname: GFS3
Uuid: a9696e90-0707-4de4-8430-479e7d3af8ac
State: Peer in Cluster (Connected)

Hostname: GFS4
Uuid: e01c2d0a-6491-4250-b531-5895be4788f0
State: Peer in Cluster (Connected)

Hostname: GFS5
Uuid: c26b3841-ff62-456a-b1d9-8e2842291535
State: Peer in Cluster (Connected)

[ansible@GFS6 ~]$ 

Die Peers sehen sich und haben eine Verbindung untereinander. Weiter geht es mit dem eigentlichen interessanten Teil, das Aufsetzen des Node ĂŒbergreifenden GlusterFWS Volumes.

Leider gelingt mir dieses zur Zeit nicht mit Ansible, was eigentlich sehr schade ist – da ich es umbedingt nutzen wollte. Auf der anderen Seite ist es nicht notwendigerweise mit Ansible einfacher, da die gesammte GlusterFS Konfiguration nur auf einem Node erfolgt und der verteilt es dann an die anderen Node Clustermember. Hier jetzt also die Zeilen zum Aufsetzen des GlusterFS Volumes auf der Bash von gfs1:

[ansible@GFS1 ~]$ sudo gluster volume create GV0 disperse 4 redundancy 2 transport tcp gfs1:/export/sda1 gfs2:/export/sda1 gfs3:/export/sda1 gfs4:/export/sda1 gfs5:/export/sda1 gfs6:/export/sda1 force 
volume create: GV0: success: please start the volume to access data

[ansible@GFS1 ~]$ 

Da mich nach so einem Befehl immer brennend die Auswirkung interessiert, hier die Kontrolle des Ergebnis.

[ansible@GFS1 ~]$ sudo gluster volume info
 
Volume Name: GV0
Type: Disperse
Volume ID: a917ef77-f247-4460-a3bb-bf4a7cb1fad9
Status: Created
Snapshot Count: 0
Number of Bricks: 1 x (4 + 2) = 6
Transport-type: tcp
Bricks:
Brick1: gfs1:/export/sda1
Brick2: gfs2:/export/sda1
Brick3: gfs3:/export/sda1
Brick4: gfs4:/export/sda1
Brick5: gfs5:/export/sda1
Brick6: gfs6:/export/sda1
Options Reconfigured:
transport.address-family: inet
nfs.disable: on

[ansible@GFS1 ~]$

Solange das Volume nur angelegt (Created) ist, findet noch keine Replikation zwischen den Nodes statt. DafĂŒr muss das Volume erst gestartet werden.

[ansible@GFS1 ~]$ sudo gluster volume start GV0  
volume start: GV0: success
[ansible@GFS1 ~]$

Anschließend Ă€ndert sich der Status von Created zu Started. Jetzt sollte das GlusterFS Volume erreichbar sein.

[ansible@GFS1 ~]$ sudo gluster volume info
 
Volume Name: GV0
Type: Disperse
Volume ID: a917ef77-f247-4460-a3bb-bf4a7cb1fad9
Status: Started
Snapshot Count: 0
Number of Bricks: 1 x (4 + 2) = 6
Transport-type: tcp
Bricks:
Brick1: gfs1:/export/sda1
Brick2: gfs2:/export/sda1
Brick3: gfs3:/export/sda1
Brick4: gfs4:/export/sda1
Brick5: gfs5:/export/sda1
Brick6: gfs6:/export/sda1
Options Reconfigured:
transport.address-family: inet
nfs.disable: on

[ansible@GFS1 ~]$ sudo gluster volume status
Status of volume: GV0
Gluster process                             TCP Port  RDMA Port  Online  Pid
------------------------------------------------------------------------------
Brick gfs1:/export/sda1                     49152     0          Y       1746 
Brick gfs2:/export/sda1                     49152     0          Y       916  
Brick gfs3:/export/sda1                     49152     0          Y       678  
Brick gfs4:/export/sda1                     49152     0          Y       681  
Brick gfs5:/export/sda1                     49152     0          Y       671  
Brick gfs6:/export/sda1                     49152     0          Y       679  
Self-heal Daemon on localhost               N/A       N/A        Y       1767 
Self-heal Daemon on GFS2                    N/A       N/A        Y       937  
Self-heal Daemon on GFS3                    N/A       N/A        Y       699  
Self-heal Daemon on GFS4                    N/A       N/A        Y       702  
Self-heal Daemon on GFS5                    N/A       N/A        Y       692  
Self-heal Daemon on GFS6                    N/A       N/A        Y       700  
 
Task Status of Volume GV0
------------------------------------------------------------------------------
There are no active volume tasks
 
[ansible@GFS1 ~]$ 

Ich hab das GlusterFS Volume GV0 mal probeweise gemountet. Das geht sehr einfach von einem anderen Linux Arch, welcher nicht als Peer defineriert sein muss. Okay, ich habe jetzt auch keine Security features aktiviert. Was wichtig ist, dass der Client der in den GlusterFS mounten möchte die Nodes per DNS genauso auflösen können muss, wie die GlusterFS Peers untereinander. Dann geht das mounten auch recht einfach von der Hand.

[eric@Wintermute ~]$ sudo mount -t glusterfs gfs6:GV0 /media/GV0/

[eric@Wintermute ~]$ df -aH /media/GV0
Dateisystem    GrĂ¶ĂŸe Benutzt Verf. Verw% EingehĂ€ngt auf
gfs6:GV0         10T    111G  9,9T    2% /media/GV0

[eric@Wintermute ~]$ ls -la /media/GV0/
insgesamt 4
drwxr-xr-x  3 root root   24  1. Apr 20:10 .
drwxr-xr-x 10 root root 4096  1. Apr 21:13 ..

[eric@Wintermute ~]$ 

Ich hoffe, ich konnte etwas Licht in das GlusterFS Thema bringen.

:o)