GlusterFS

Aus Vosp.info
Version vom 24. Januar 2014, 21:06 Uhr von HK (Diskussion | Beiträge) (CT doppelt starten)
(Unterschied) ← Nächstältere Version | Aktuelle Version (Unterschied) | Nächstjüngere Version → (Unterschied)
Wechseln zu:Navigation, Suche

Allgemein

GlusterFS ein Clusteraufsatz für Dateisysteme wie ext4 oder xfs.
Damit bekommen wir die Möglichkeit, einen RAID-1 Speicher mit mehreren Computer herzustellen.
GlusterFS bieten noch mehr Möglichkeiten, die an dieser Stelle nicht behandelt werden.

Ziel

Glusterfs-Server, die auch ihre eigenen Clienten sind.
Das dient als Grundlage für ein HA-System.

Beispiel:

  • Computer 1 und Computer zwei stellen ein Gluster Volume bereit, dass sie selber gemountet haben.
  • Auf Computer 1 wird ein Webserver ausgeführt, der eine Homepage bereit stellt, deren Daten im Gluster Volume liegen.
  • Computer 1 fällt aus.
  • Auf Computer 2 wird ein Webserver gestartet. Dieser greift auf die selben Daten zu.
  • Fehlt: IP-Switching von einem Webserver zum nächsten.

Sicherheit

Die Server werden mit openvpn verbunden.
Dieser Tunnel stellt die verschlüsslte Verbindung bereit, über die die Gluster-Nodes ihre Daten austauschen.

Herausforderung / Nerviges Problem

Bisher lauschen der Server und der Client auf allen Adressen.
Billiger Hack: Firewall.

Installation

apt-get install glusterfs-server

gluster-client wird automatisch mit installiert.

Configuration Cluster

In unserem Beispiel haben wir zwei Server mit zwei IPs:
node-1: 10.8.0.1
node-2: 10.8.0.2

node-1# gluster peer probe 10.8.0.2

Damit wird ein gluster Cluster bestehend aus node-1 und node-2 erzeugt.

Erzeugen eines Volumes

Vorarbeitungen auf allen Nodes

Es wird ein beliebiges Verzeichniss bereit gestellt.
Beachten: Die Daten in den Verzeichnissen dürfen nach dem Start des Volumes nur noch über den gluster-clienten bearbeitet werden.

Beispiel (auf allen Nodes ausführen):

node-<1 & 2># mkdir /gluster_export/brick_1

Erzeugen des Volumes

Die folgenden Befehle können auf einer beliebigen node des Clusters ausgeführt werden.

node-<beliebig>: gluster volume create gluster_test replica 2 transport tcp 10.8.0.1:/gluster_export/brick_1 10.8.0.2:/gluster_export/brick_1

Das Ergebniss des vorherigen Kommandos prüfen

gluster volume info 
Volume Name: gluster_test
Type: Replicate
Status: Created
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: 10.8.0.1:/gluster_export/brick_1
Brick2: 10.8.0.2:/gluster_export/brick_2

Dann das Volume starten

gluster volume start gluster_test

Nochmal prüfen

gluster volume info
Volume Name: gluster_test
Type: Replicate
Status: Started <= Der Unterschied zu vorher
Number of Bricks: 2
Transport-type: tcp
Bricks:
Brick1: 10.8.0.1:/gluster_export/brick_1
Brick2: 10.8.0.2:/gluster_export/brick_2

Mounten des Volumes

Mounten per /etc/fstab.
Der ausgewählte Server ist nur der Einstiegspunkt.
Gemountet wird mittels des Volumennamens.

vim /etc/fstab

Eingetragen wird folgende Zeile

10.8.0.1:/gluster_test /gluster_test_import glusterfs defaults,_netdev 0 0

Beachten:

Beachten: Die Daten dürfen nur noch über den <MOUNT POINT> bearbeitet werden!
Im Rettungsfall ist natürlich alles erlaubt, was hilft.

Tests

OpenVZ in KVM

  • Zwei KVM-Maschinen per openvpn verbunden für glusterfs und andere interne Kommunikation.
  • Sie befinden sich im selben Netzwerksegment.
  • Zwei glusterfs Volumes
    • Eins für die Config, zu mounten unter /vz/conf
    • Eins für die Container, zu mounten unter /var/lib/vz

Install

  • Auf beiden Maschinen
vim /etc/apt/sources.list.d/openvz.list

Eintrag in die neue Datei einfügen

deb http://download.openvz.org/debian wheezy main

Öffentlichen Schlüssel des Repos holen und in den apt-schlüsselbund aufnehmen.

wget http://ftp.openvz.org/debian/archive.key
apt-key add archive.key
apt-get update
apt-get install linux-image-openvz-amd64 vzctl vzdump
  • Maschinen mit dem OpenVZ-Kernel starten.
  • Am besten den alten Kernel löschen oder aus der grub.cfg raus werfen. (chmod 700 grub.cfg!!)

Das template selbst erstellen (debootstrap) , von openvz dowloaden oder oder.
Wie's beliebt.

Test mit zwei CTs und Webserver

Voraussetzungen
  • Container befinden sich im selben Netzwerksegment.
  • Erstellt werden zwei Container mit lighttpd als webserver (es geht auch ein CT)
  • Die default-Seiten mit IDs versehen, z.b. Containernamen
  • Beide Seiten aufrufen.
  • CT auf dem einen Host stoppen und auf dem anderen Host starten
  • Seite reloaden, bis sie wieder erreichbar ist
Ergebnisse
  • Es geht.....aber sehr langsam, siehe Performance

Abschalten eines Hosts

  • Abschalten eines KVM-Hosts
Ergebnisse
  • Es geht.....aber sehr langsam


Performance

Test lokal
root@cluster-2:~# time dd if=/dev/zero of=/tmp/100MBfile bs=1024 count=102400
102400+0 Datensätze ein
102400+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 0,382552 s, 274 MB/s

real    0m0.386s
user    0m0.020s
sys     0m0.343s
Test glusterfs
root@cluster-2:~# time dd if=/dev/zero of=/etc/vz/conf/100MBfile bs=1024 count=102400
102400+0 Datensätze ein
102400+0 Datensätze aus
104857600 Bytes (105 MB) kopiert, 9,34309 s, 11,2 MB/s

real    0m9.354s
user    0m0.124s
sys     0m1.629s
Fazit

Beschissene Performance, wahrscheinlich in dieser Form unbenutzbar.

Probleme

CT doppelt starten
  • Ein CT lässt sich auf beiden Hosts gleichzeitig starten. Das darf nicht passieren!
  • Lockfiles müssen auch ein glusterfs-Volume bekommen
  • Augenscheinlich liegen die Infos über laufende CTs in /proc/vz. Glusterfs fällt damit flach.
glusterfs mountet beim Start nur erstes/ein Volume

Workaround:

vim /etc/rc.local

Dort eintragen (vor exit 0)

mount -a

Funktioniert HK