Dies ist eine alte Version des Dokuments!
Inhaltsverzeichnis
Konzept neue Plattform
Dokumentenname | PFM_Konzept |
Autor | Thomas Bader |
Status | Erster Entwurf, bereit zur Diskussion |
Letzte Änderung | 20.09.2015 |
Übersicht
Die Dienste werden mit virtualisierten Maschinen bereitgestellt. Dazu werden zwei physische Server als Cluster konfiguriert.
Komponenten des Clustering
Die Konfiguration des Clusters erlaubt den Failover von virtuellen Maschinen sowie der Storage. Dazu müssen unterschiedliche Komponenten konfiguriert werden.
cman
cman ist der Cluster-Manager und dient hauptsächlich als Quorum-Provider. Er prüft ob die Voraussetzungen für den Betrieb gegeben sind und start/stoppt den Cluster.
Bei trash.net sind weniger als 3 Nodes im Cluster. Deshalb kann der Betrieb nicht per Quorum realisiert werden. Der Cluster-Manager wird deshalb den Cluster ohne Prüfung von Vorbedingungen starten.
corosync
Durch corosync wird die Basisfunktionalität des Clusters realisiert. Per Multicast tauschen die Nodes Heartbeats untereinander aus und individuelle Services des Clusters werden automatisch gestoppt oder gestartet.
Der Austausch der Heartbeats ist kritisch. Wenn dieser nicht sichergestellt ist und sich beide Cluster-Nodes nicht mehr „sehen“, dann werden beide Nodes versuchen sämtliche Dienste bei sich zu starten und zu failovern. Dies führt dazu, dass beide Nodes alle virtuellen Maschinen bei sich lokal starten, diese parallel laufen und auf die Storage schreiben, und anschliessend keine Zusammenführung der Daten mehr möglich ist. Um dies zu verhindern sind im Cluster zwei Massnahmen implementiert:
- Die Heartbeats werden zusätzlich auch per RS232-Link übertragen, um bei Problemen mit den Netzwerkinterfaces keinen Failover im Cluster auszulösen
- Mit Fencing können die Nodes sich gegenseitig abschalten, sofern nicht automatisch behebbare Probleme auftreten
DRBD
Mit DRBD werden drei Block-Devices als Mirror zwischen den Maschinen synchronisiert:
- Ein Mirror dient als Shared-Storage um die Konfiguration/Skripte des Clusters abzulegen
- Ein Mirror dient als Basis für Clustered-LVM, um eine Volume-Group für virtuelle Maschinen der Node 1 abzulegen
- Ein Mirror dient als Basis für Clustered-LVM, um eine Volume-Group für virtuelle Maschinen der Node 2 abzulegen
Jede Node hat jeweils ihre eigene Volume-Group aktiv. Sobald eine Node ausfällt, wechselt übernimmt sie VG und virtuelle Maschinen der anderen Node.
Netzwerk
Der Uplink zum Internet wird über einen Switch bereitgestellt. Er stellt deshalb einen single-point of failure. Weitere Verbindungen sind als Crosslink zwischen den Nodes realisiert. Ein Link dient der Synchronisation der Storage und ein Link dient dem Cluster-Management. Ein weiterer Link ist als 802.1q-Trunk umgesetzt und erlaubt den Aufbau von privaten Netzen zwischen virtuellen Maschinen. Die IPMI-Interfaces der beiden Server werden über Kreuz mit Crosslinks verbunden.
Zone | Interface | Typ |
---|---|---|
Internet (rot) | eth0 | Link der beiden Cluster-Nodes an den Switch im Internet |
Storage (grau) | eth1 | Cross-Link zwischen beiden Nodes für Replikation der Storage |
Back-Channel (gelb) | eth2 | Cross-Link zwischen beiden Nodes für das Cluster-Management |
LAN | eth3 | Cross-Link zwischen den beiden Nodes für private Netze, als 802.1q-Trunk |
trash.net private net (grün) | vbr1, eth3.1 | VLAN als privates Netz von trash.net |
beliebige Netze | vbrXXX, eth3.XXX | beliebige private Netze für Kunden |
IPMI | eth4 | Cross-Link, jede Node zum IMPI der anderen Node |
RS232 | ttyS0 | serieller Cross-Link, für Cluster-Management |
Storage
Pro Node wird ein RAID-Array auf lokalen Disks betrieben. Diese werden wie folgt partitioniert:
Partition | Filesystem | Mountpoint | Nutzung | Replikation |
---|---|---|---|---|
1 | etx4 | / | Root-Filesystem der Node | n |
2 | swap | - | Swap pro Node | n |
4 | ext4 | /var | var-Filesystem der Node | n |
5 | ext4 | /local | lokale Datastorage der Node | n |
6 | DRBD | - | Shared-Storage zwischen den Nodes | y |
7 | DRBD | - | PV für die Volume-Gruppe der Node 1 | y |
8 | DRBD | - | PV für die Volume-Gruppe der Node 2 | y |
Über DRBD werden die folgenden Mirrors eingerichtet:
Mirror | Partition | Filesystem | Mountpoint | Nutzung |
---|---|---|---|---|
0 | 6 | GFS2 | /shared | Shared-Storage zwischen den Nodes |
1 | 7 | Clustered-LVM | - | PV für die Volume-Gruppe der Node 1 |
2 | 8 | Clustered-LVM | - | PV für die Volume-Gruppe der Node 2 |
Virtuelle Maschinen
Host | OS | Nutzung | Cluster Node | Failover |
---|---|---|---|---|
stinky | ? | Shell-Server | Node 1 | n |
tbd | ? | Shell-Server | Node 2 | n |
knox | ? | secondary DNS | Node 2 | n |
tbd | ? | primary DNS | Node 1 | n |
Fileserver | ? | NFS-Server | Node 1 | y |
Anmerkung: nicht alle virtuellen Maschinen sind mit einem Failover ausgestattet. Sofern ein Dienst bereits auf Applikationsebene redundant ist (DNS), dann muss kein Failover auf Ebene der Virtualisierung realisiert werden.