Hochverf ugbarkeitsclusters
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Abschlussprüfung Sommer 2021
Fachinformatiker für Systemintegration
Dokumentation zur betrieblichen Projektarbeit
Hochverfügbarkeitsclusters
Virtualisierungscluster via Proxmox
”
VE“
Aufbau eines Hochverfügbarkeitsclusters auf basis der
Open-Source-Virtualisierungsplattform Proxmox VE
Abgabetermin: Düsseldorf, den 01.05.2020
Prüfungsbewerber:
Florian David Janowski
Carl-Severiong Str. 7
40595 Düsseldorf
Ausbildungsbetrieb:
Mediadesign Hochschule für Design und Informatik GmbH
Werdener Straße 4
40227 DüsseldorfInhaltsverzeichnis
1 Abkürzungsverzeichnis 1
2 Einleitung 2
3 Projektbeschreibung 2
3.1 Projektumfeld und Motivation . . . . . . . . . . . . . . . . . . . . . . . . 2
4 Projektziele 2
4.1 Sachziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.2 Kostenziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
4.3 Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.3.1 Qualitätsziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.4 Ist-Zustand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.5 Soll-Konzept . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
4.6 Abweichungen gegenüber dem Projektantrag . . . . . . . . . . . . . . . . 3
4.7 Prozessschnittsellen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.7.1 Personen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4.7.2 Projektablaufplan . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
5 Projektplanung 5
5.1 Personalplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.1.1 Sachmittelplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.2 Kostenplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
5.3 Wirtschaftlichkeitsanalyse . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.4 Amortisationdauer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.5 Zeitplanung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6 Projektdurchführung 9
6.1 Entscheidungsfindung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
6.2 Beschreibende Arbeitsschritte . . . . . . . . . . . . . . . . . . . . . . . . . 10
6.2.1 Vorbereitung: DNS-Einträge für die Namensauflösung . . . . . . . 10
6.2.2 Bootbarer USB-Stick mit Proxmox VE . . . . . . . . . . . . . . . . 10
6.2.3 BIOS/EFI Konfiguration . . . . . . . . . . . . . . . . . . . . . . . 11
6.2.4 Installation von Proxmox VE 6.2 . . . . . . . . . . . . . . . . . . . 11
6.2.5 Erstellung des Proxmox Clusters . . . . . . . . . . . . . . . . . . . 13
6.2.6 CEPH Cluster Erstellensc . . . . . . . . . . . . . . . . . . . . . . . 13
6.2.7 Migration von VMs . . . . . . . . . . . . . . . . . . . . . . . . . . 15
6.3 Validierung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7 Projektabschluss 17
7.1 Projektübergabe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
27.2 Soll/Ist Vergleich . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.2.1 Sachziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2.2 Kostenziele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2.3 Zeitziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.2.4 Qualitätsziel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.3 Projektfazit/Reflexion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
31 Abkürzungsverzeichnis
CLI Command Line Interface
DNS Domain Name System
HTTP Hypertext Transfer Protocol
HTTPS Hypertext Transfer Protocol Secure
ICMP Internet Control Message Protocol
IP Internet Protocol
LAN Local Area Network
LDAP Lightweight Directory Access Protocol
NAT Network Address Translation
OS Operating System
SSH Secure Shell
SSL Secure Sockets Layer
VM Virtuelle Machine
HTML Hypertext Markup Language
AMD-V AMD Virtualization
NVMe NVM Express
FQDN Fully Qualified Domain Name
OSD Object Storage Node
CRUSH Controlled Replication Under Scalable Hashing
12 Einleitung
Diese Dokumentation wurde im Rahmen der betrieblichen Projektarbeit der Berufsaus-
bildung zum Fachinformatiker bis für System Integration erstellt das Projekt beinhaltet
die Konzeption und Konfiguration von einem Hochverfügbarkeitsclusters auf Basis von
Proxmox. Ziel dieses Projektes ist es, die Lehrinhalte der Ausbildung zu vertiefen und
ein realitätsnahes Projekt umzusetzen. Dabei sollen sowohl fachliche als auch soziale
Kompetenzen gefördert werden
3 Projektbeschreibung
3.1 Projektumfeld und Motivation
Das Projektumfeld ist die Mediadesign Hochschule für Design und Informatik GmbH
(in den folgenden Abschnitten mit MD.H abgekürzt) ist eine private Universität mit
Standorten in Düsseldorf, München und Berlin.
Die MD.H bietet folgende Studiengänge im Bachelor Studium an, Media Design, Game
Design, Digital Film Design-Animation/VFX, Fashion Business. Unter anderem können
Studenten auch ihren Master in Design Management machen.
Dieses Projekt wird im Standort Düsseldorf vollzogen welcher 313 Studenten beherbert,
in diesem Standort arbeiten 16 Mitarbeiter, darunter 4 ITler.
4 Projektziele
4.1 Sachziele
Ziel des Projektes ist es, dass alle vorhandenen VMs auf einem neuen hochverfügbarkeits
Cluster migriert werden.
4.2 Kostenziele
Für die Realisierung der Projektziele soll die bestehende Serverarchitektur erweitert
werden. Hierzu wird neue Server Hardware benötigt, die abgesehen von Kosten für auf-
gewendete Arbeitszeit und Sachmittel, sowie den gegenwärtigen Fixkosten des Server-
betriebs keine weiteren Mehrkosten verursachen sollte.
24.3 Zeitplanung
Für das Projekt sind unter Nichtberücksichtigung der Prozessschnittstellen 35 Arbeits-
stunden angedacht, davon sollten 7 Stunden in die Projektdokumentation fließen.
4.3.1 Qualitätsziel
Die vollständige und fehlerfreie Umsetzung der Sachziele sollen durch Test-fälle abge-
deckt werden. Dabei sind sowohl die vollständige Funktionalität als auch die sicherheits-
technischen Maßnahmen zu testen.
4.4 Ist-Zustand
Aktuell verwendet die MD.H ein stark veraltetes vShpere Cluster, diese wird seit Jahren
nicht mehr vom Hersteller unterstützt und erhält daher auch keine Sicherheitsupdates
mehr. Dazu ist aufgefallen, dass die Performance der einzelnen VMs so wie die der
Hostmaschinen/Servern degradiert. Auf diesem Cluster läuft aktuell das Haupt-E-Mail-
System (auf Exchange Basis) sowie der Haupt Domain Controller für die Verwaltung
und die Schule. Aufgefallen ist, dass einige der Host Maschinen zu zufälligen Zeiten
abstürzen. Dies führt dazu, dass Dienste wie E-Mail und Login Service für die Windows
Klienten nicht mehr dauerhaft verfügbar sind. Aus diesem Grund sind Mitarbeiter sowie
Studenten zeitweise nicht mehr arbeitsfähig.
4.5 Soll-Konzept
Ziel ist es eine Moderne und Zukunftssichere Virtualisierung Struktur zu erstellen, die
Leicht in der Handhabung und Administration ist, jedoch trotzdem eine Vielzahl an
Funktionen bietet. Um dies zu bewerkstelligen soll eine robuste und zuverlässige Open
Source Virtualisierung Lösung verwendet werden, diese soll über eine Webschnittstelle
(Web UI) auf HTML5/JavaScript Basis zum Einsatz kommen, hinzu kommt eine robuste
API um Automatisierungen bewerkstelligen zu können.
4.6 Abweichungen gegenüber dem Projektantrag
Die eigentliche Hardware, die für dieses Projekt gedacht war, konnte leider nicht recht-
zeitig geliefert werden. Hierzu wurden mir drei herkömmliche Computer gegeben, die ich
für das Projekt nutzen soll. Dennoch wird das Projekt wie hier in der Dokumentation
angegeben umsetzbar sein.
3Ungeraderem ist es nicht möglich zu dem Zeitpunkt die VM Migration durchzuführen
und zu Testen. Der aktuelle Cluster lüft zu instabile.
Um die Validierung des Clusters dennoch durchzuführen werden einige test VMs erstellt.
Diese variieren in der Datengröße um verschiedene VMs zu simulieren.
4.7 Prozessschnittsellen
4.7.1 Personen
Name Firma Abteilung Beschreibung
Sascha Mollberg Mediadesign Hochschule IT / CTO Ausbilder, Auftraggeber
Tabelle 1: Auflistung der Prozessschnittstellen
Herr Sascha Mollberg war maßgeblich Ansprechpartner bei der Konzeption und Um-
setzung des Projektes. Er unterstütze bei der Erarbeitung des Projektzieles und kann
durch seine tiefgreifendes Fachwissen Anregungen bei der Entscheidungsfindung, sowie
Hinweise auf mögliche Lösungswege bei der Projektumsetzung geben.
4.7.2 Projektablaufplan
Projektablauf
plan er-
stellen:
Gant
Diagramm
45 Projektplanung
5.1 Personalplanung
Name Tätichkeit Zeitaufwand
Florian David Janowski Mediadesign HochschuleProjektumsetzung, Azubi 35 Stunden
Sascha Mollberg Ansprechpartner, CTO, Projektübergabe, Projektumsetzung 4 Stunden
Tabelle 2: Personalplanung
5.1.1 Sachmittelplanung
Hardware Beschreibung
Drei Server Neue Hypervisor Hosts für den Cluster
Arbeitsplatz-PC System zur Projektumsetzung
Tabelle 3: Sachmittelplanung - Hardware
Software Beschreibung
Proxmox VE 6.2 Hypervisor Betriebssystem
Chrome/Firefox WebUI Zugriff
Windows Terminal SSH Zugriff für die Server
Windows 10 Pro Betriebssystem des Arbeitsplatz-PC
Tabelle 4: Sachmittelplanung - Software
Zusätzlich zu den genannten Sachmitteln standen für die Projektumsetzung die Räumlichkeiten
der MD.H zur Verfügung.
5.2 Kostenplanung
Die Kosten des Projektes setzen sich insgesamt aus drei Teilen zusammen, bei diesen
handelt es sich um Software, Personal und Hardware.
5Abgesehen von den Windows 10 Pro Lizenzen, die am Arbeitsrechner zur Ausführung
benötigt werden, handelt es sich bei den Software-Sachmitteln um frei verfügbare Open
Source-Software. Da die Windows-Lizenzen bereits auf allen Rechnern vorhanden sind,
kommen keine Softwarekosten auf.
Für die Personalkosten werden beim Auszubildenden im dritten Lehrjahr ein Bruttoge-
halt von 12.000 e pro Jahr bei 150 Arbeitstagen angenommen und beim Ausbilder und
CTO ein Bruttogehalt von 50.000 e pro Jahr bei jeweils 220 Arbeitstagen angenom-
men. Die Personalkosten belaufen sich also bei dem Projekt auf: 516 e (Siehe Tabelle
5), hierbei werden 35 Projektstunden, plus 4 für die Unterstützung sowie Abnahme
betrachtet.
e12000/Jahr/((150 ∗ 8)h/Jahr) = e10/h
e50000/Jahr/((150 ∗ 8)h/Jahr) = e41, 67/h
Beschreibung Stunden Stundensatz Gesamtkosten
Personalkosten Florain David Janowski 35h 10e 350e
Personalkosten Sascha Mollberg 4h 41,67e 166,68e
Summe: 516,68e
Tabelle 5: Personalkostenplanung
Hardware Kosten
Grundkonfiguration 2.323,00e
AMD EPYC 7302P Processor 403,00e
128 GB DDR4-3200 RAM 718,00e
Server-Mainboard mit AMD System-on-Chip und 10Gbit LAN 88,00e
1,6 TB SAS SSD Seagate Nytro 3531 2.500,00e
250 GB M.2 SSD Samsung 980 Pro 168,00e
Broadcom SAS 9300-4i Host-Bus-Adapter 25,00e
Montageschiene Easy-Mount 48,00e
High-efficiency redundantes Netzteil 109,00e
Pick-Up Gewährleistung 36 Monate 165,00e
Gesamtpreis 6.577,00e
Tabelle 6: Hardwarekosten für einen Server
6Die Hardwarekosten für einen Server belaufen sich Insgesamt auf 6.577,00e, die genaue
Zusammensetzung kann der Tabelle 6 entnommen werden. Dieses Projekt benötigt drei
dieser Server, damit kommen wir auf einen Hardwarepreis von: e19.731
P ersonalkosten + Hardwarekosten = P rojektkosten
e516, 68e + e19.731, 00 = e20.247, 68
Insgesamt belaufen sich die Kosten des Projektes also auf: e20.247, 68.
5.3 Wirtschaftlichkeitsanalyse
Durch eine neuere Virtualisierung, Struktur und Hardware werden die Ausfälle der wich-
tigsten Dienste vermieden, sowie die Entlastung der Mitarbeiter aufgrund weniger Sup-
portarbeit ,gewährleistet. Dies hat zur Folge ,dass alle Mitarbeiter und Studenten keine
E-Mail ausfälle und Datenverluste erleiden müsse. Somit soll der normale Arbeitstag
ohne mehrfache Telefonate zur Fehlerbehebung voranschreiten können.
5.4 Amortisationdauer
Wartung und Administration des Proxmox VE Clusters:
Projektaufwand: 20.247,68 e
Laufende Kosten pro Monat für die Wartung: 1950 e
Lauf endeKosten = Bearbeitungszeit × StundensatzdesM itarbeiters
1.500e = 150h × 10e/h
Wartung und Administration des veralteten vSphere Clusters:
Laufende Kosten pro Monat für die Wartung: 850 e
Lauf endeKosten = Bearbeitungszeit × StundensatzdesM itarbeiters
6.000e = 600h × 10e/h
Gewinn = AltesCluster − N euesCluster
4.500e = 6.000e − 1.500e
Amortisationsrechnung:
Amortisationszeit = Anschaf f ungskosten/Gewinn
Amortisationszeit = 20.247, 68e/(6.000e/M onat–1.500/M onat)
7Amortisationszeit = 4, 49M onat
Der neue Cluster würde sich schon nach knapp 5 Monaten lohnen.
5.5 Zeitplanung
Die folgende Tabelle zeigt die Soll-Zeitplanung des Projektes:
Projektplanung mit Zeitplanung in h h
Analyse 3
Durchführung einer Ist-Analyse 1
Durchführung einer Wirtschaftslichkeitanalyse 2
Konzeption 4
Planung der Serverhardware 1
Migration der Vorhandenen VMs ohne Downtime 1
Netzwerkinfrastruktur für die Hosts 1
Deployment der VMs 1
Realisierung 14
Serverhardware Einbau 1
Installation des Proxmox VE Hypervisors 1
Konfiguration für Proxmox VE 2
Cluster erstellen 2
VM Migration 8
Validierung 5
Ausfalltests 3
Hosts 1
Netzwerk 1
Festplatten 1
Erreichbarkeit 1
Dokumentation 9
Erstellung der Projektdokumentation 4.9
Erstellung des Benutzerhandbuchs 4.9
Summe: 35 h
Tabelle 7: Detaillierte Soll-Zeitplanung
86 Projektdurchführung
6.1 Entscheidungsfindung
Bei der Findung von einem Passenden Open Source Virtualisierung Software gab es
nur wenig Auswahl, die gefundenen Lösungen wurden auf folgende Aspekte untersucht.
Performance, Erweiterbarkeit, Flexibilität, Web Interface, Support, Nutzbarkeit, Doku-
mentation.
Diese wird in einer Skala von 1 bis 10 angegeben, wobei 1 sehr negativ und 10 sehr
positiv ist.
Kriterium Gewichtung in % Proxmox XCP-NG
Performance 40% 8 3,20 8 3,2
Flexibilität 5% 6 0,3 4 0,2
Support 5% 8 0,4 6 0,3
Dokumentation 20% 9 1,8 6 1,2
Interface 20% 5 1 4 0,8
Erweiterbarkeit 10% 6 0,6 6 0,6
Summe 100% - 7,3 - 6,3
Tabelle 8: Entscheidungsmatrix der Wahl der Virtualisierungs Software
Kurze Erläuterung zur Bewertung der einzelnen Kriterien:
• Beide Virtualisierungsplattformen haben eine sehr gute Online Dokumentation so
wie eine recht große Community. Proxmox hat hingegen zu XCP-NG eine größere
Community und bietet deutlich mehr Ansprechpartner und Hilfestellungen.
• Proxmox arbeitet mit Debian als Betriebssystem, diese ist in der MD.H bekannt.
XCP-NG hingegen nutzt CentOS7.
• Beide Virtualisierungsplattformen bieten eine sehr gute Performance und hingen
in kleinster weise einen hinterher.
• Beide Produkte bieten eine Web UI, Proxmox bringt diese von haus aus mit und
ist nach der Installation direkt nutzbar. XCP-NG hingegen braucht ein Programm,
das nur unter Windows funktioniert, dennoch kann man eine Web UI nachträglich
installieren.
96.2 Beschreibende Arbeitsschritte
6.2.1 Vorbereitung: DNS-Einträge für die Namensauflösung
Zunächst wurden die DNS-Einträge für die drei Server gesetzt. Dabei lösen die folgenden
Subdomains auf folgende Server auf.
• mdh-vm01.mediadesign.de
• mdh-vm02.mediadesign.de
• mdh-vm03.mediadesign.de
Dazu wird auf dem Windows DNS-Server drei neuen DNS-A-Records eingetragen. Damit
die VM Hosts via die interne Domain aufgerufen werden kann.
1 Add-DnsServerResourceRecordA \
2 - Name " mdh-vm01 " \
3 - ZoneName " mediadesign . de " \
4 - AllowUpdateAny \
5 - Ipv4Address " 192.168.172.31 "
6
7 Add-DnsServerResourceRecordA \
8 - Name " mdh-vm02 " \
9 - ZoneName " mediadesign . de " \
10 - AllowUpdateAny \
11 - Ipv4Address " 192.168.172.32 "
12
13 Add-DnsServerResourceRecordA \
14 - Name " mdh-vm03 " \
15 - ZoneName " mediadesign . de " \
16 - AllowUpdateAny \
17 - Ipv4Address " 192.168.172.33 "
Listing 1: Hinzufügen von DNS Einträgen
6.2.2 Bootbarer USB-Stick mit Proxmox VE
Dafür wird z.B. die Software Rufus verwendet, um die ISO auf ein USB-Stick zu bren-
nen, so wie die aktuelle Proxmox VE ISO. Zu den Zeitpunkt des Projektes ist dies die
Version 6.2.
Die Software Rufus wird genutzt, um den USB-Stick neu zu formatieren, auf dieser wird
dann das ISO Abbild geschrieben. Dabei ist zu beachten, dass dies alle Daten, die auf
dem USB-Stick vorahnden sind unwiderruflich löscht.
10Dazu wird im ersten Schritt sichergestellt, dass der richtige USB-Stick ausgewählt wur-
de, in meinem Fall ist das ein 32GB USB-Stick, der mehrere Partitionen aufwies. Nach
dem das sichergestellt wurde wir nun die Proxmox VE ISO ausgewählt. Das gescheit
in dem man auf dem Feld AUSWAHL“ drückt. Dort wählt man nun die Herunter-
”
geladen Proxmox VE ISO aus. Nachdem die ISO ausgewählt wurde, drückt man nun
auf START“, um den Vorgang zu starten. Dort taucht nun ein Fenster auf das euch
”
auffordern ein Modus für den Kopiervorgang zu wählen. Dort habe ich die empfehlende
Option genommen. Nach dem ich dies mit OK“ genehmigt habe wurde direkt mit dem
”
Formatieren begonnen sowie die ISO kopiert.
6.2.3 BIOS/EFI Konfiguration
Die Server müssen nun überprüft werden, ob diese die nötigen Einstellungen im BIOS/E-
FI besitzen. Hierzu muss im BIOS/EFI AMD-V aktiviert werden. Dies ermöglich es
Hardware nahe Virtualisierung. Dies ist wichtig, um gute Performance in den einzelnen
VMs zu erziehen.
Eine Virtualisierung ohne AMD-V ist möglich, aber dies führt dazu das jegliche VM
langsam ist.
6.2.4 Installation von Proxmox VE 6.2
Booten vom USB-Stick
Zum Installieren von Proxmox muss nun der vorbereitete USB-Stick in den Server hinein-
gesteckt werden, nach dem dies geschehen ist starten man den Server und wartet das er
Proxmox bootet. Dies sollte im Normalfall direkt geschehen so lange kein Betriebssystem
vorher auf eine HDD/SSD Installiert ist.
Installation
Nach erfolgreichem Booten wird einen die EULA angezeigt, diese bestätigt man und
fährt fort.
Als nächstes wird die HDD/SSD Ausgewählt auf die das Proxmox VE Installiert wer-
den soll. In meinem Fall ist dies eine 476GB große NVMe. Dort werden keine weiteren
Änderungen vorgenommen und fahren nun fort.
11Jetzt wird das Passwort für den Root Benutzer gesetzt, dies ist unser Administrations
Account. Wichtig hierbei ist es ein starkes Passwort zu wählen. Dazu wird noch eine E-
Mail-Adresse angegeben, um Error Meldungen zu erhalten. Diese ist unsere allgemeine
IT Düsseldorf E-Mail-Adresse.
Zur guter Letzt wird nun der FQDN, IP-Adresse, Gateway sowie der DNS Server ange-
geben.
FQDN mdh-vm01.mediadesign.de mdh-vm01.mediadesign.de mdh-vm01.mediadesign.de
IP-Adresse 192.168.178.31 192.168.178.32 192.168.178.33
Gateway 192.168.178.1 192.168.178.1 192.168.178.1
DNS 192.168.178.1 192.168.178.1 192.168.178.1
Tabelle 9: DNS Einträge der Server
Anschließend auf Next“ und Install“ drücken, damit wird nun Proxmox VE Installiert.
” ”
Wichtig ist das Schritt 7.2.3 – 7.2.4.2 müssen wir alle drei Server durchgeführt werden.
Prüfen der Installation
Nun muss geprüft werden, ob alle drei Server ansprechbar sind. Dies können wir mit
dem Tool ping“ in der PowerShell testen.
”
Ping out-
put als
Nachdem sichergestellt ist wurde das alle drei Server online sind können wir nun schau-
Script
en, ob wir auf das Web UI von Proxmox VE kommen, hierzu wird die Folgende URL
blog muss
verwendet.
hier rein
• https://mdh-vm01.mediadesign.de:8006
• https://mdh-vm02.mediadesign.de:8006
• https://mdh-vm03.mediadesign.de:8006
Dort wird en Proxmox VE Login fester auftauchen, dort wird der Benutzer root“ und
”
das bei der Installation gesetzt Passwort eingegeben.
126.2.5 Erstellung des Proxmox Clusters
Cluster Initialisierung und hinzufügen der Server
Um ein Cluster in Proxmox VE zu erstellen gibt es verschiedene Möglichkeiten. Eine
häufig genutzte Methode zur Erstellung des Clusters ist das Web UI. In diesem Fall wird
der Terminal basierte Methode mit Hilfe des SSH Protokolls gewählt.
Zunächst benötigen wir eine aktive Verbindung zu allen Servern.
1 ssh root@mdh - vm01 . mediadesign . de
2 ssh root@mdh - vm02 . mediadesign . de
3 ssh root@mdh - vm03 . mediadesign . de
Listing 2: SSH in den Server/Node
Zu Beginn müssen wir das Cluster Initialisieren. Dies wird üblicherweise auf dem ersten
Server durchgeführt. In meinem Fall ist dies der Server mdh-vm01. Das Cluster wird mit
einem Selbstgewählten Namen initialisiert. In diesem Fall MDH-CLUSTER.
1 pvecm create MDH - CLUSTER
Listing 3: Erstellung des VM Clusters
Nach der Initialisierung müssen nun alle anderen Server hinzugefügt werden. Für diesen
Cluster sind es die Server mdh-vm02 und mdh-vm03. Auf diesen beiden Servern muss
nun der folgende befehlt ausgeführt werden. Hiermit wird gesagt das ein Server dem
gerade erstellten Cluster beitreten soll. Hierbei muss der FQDN oder die IP-Adresse des
Servers eingegeben werden mit welchem das Cluster erstellt wurde.
1 pvecm create MDH - CLUSTER
Listing 4: Hinzufügen der Server/Nodes zum Cluster
6.2.6 CEPH Cluster Erstellensc
Installation von CEPH
CEPH ist ein verteiltes Storages System, mit diesem Cluster werden alle daten der VMs
automatisch an alle verfügbaren Nodes die in diesem CEPH Cluster sind übertragen.
Somit kann gewährleistet werden das bei einem Serverausfall die VMs auf den anderen
Nodes weiterhin mit minimaler Ausfallzeit laufen.
13Zunächst muss auf jedem Node CEPH installiert werden, hierzu wird im Web UI einer
der Server ausgewählt und auf den CEPTH gedrückt. Dort wird man aufgefordert CEPH
zu Installieren. [Siehe Bild: XXXXX]
Während der Installation muss ein Netzwerk ausgewählt werden worüber CEPH kom-
muniziert. Es wird von CEPH empfohlen eine separate NIC mit 40Gbit zu verwenden.
In meinem Fall wird dies über den selbe NIC laufen wie die allgemeine Netzwerkkom-
munikation. [Siehe Bild: XXXXX]
Hinzufügen von Monitoren
Ein Ceph Monitor ist ein Daemon bzw. ein System-Dienst, welcher sich um Status- und
Konfigurations-Informationen kümmert.
Hinzufügen von Managern
CEPH Manager sammeln Daten wie die Performance der Server, storage utilization
und mehr. Hierzu wird im gleichen Tab wie in 7.2.5.2.2 die Manager hinzugefügt, dies
geschieht für alle restlichen Nodes. [Siehe Bild: XXXXX]
Hinzufügen von OSDs
OSDs sind die wesentliche Speicher-Komponente des Clusters. OSDs bestehen aus ei-
nem Storage Device (z.B. HDD/SSD), einem Daten-System (z.B. ext4,btrfs) und einen
OSD Deamon. Der OSD Daemon ist ein Dienst, der die Clients mit den gespeicherten
Objekten versorgt.
Dieser Schritt muss nun auf allen Nodes ausgeführt werden. Hierbei ist zu beachten
das man alle Datenträger hinzufügt, dies sieht man im Dropdown Menü. [Siehe Bild:
XXXXX]
Erstellung CRUSH rules
CRUSH rules sind regeln die besagen z.b. welche arten von Festplatten z.B. SSD/HD-
D/NVMe zu einem Pool zusammengefasst. Durch die Methode wird nun ein Storage
von unterschiedlichen layern bereitgestellt, um je nach Bedarf ein passender Pool aus-
zuwählen. Ebenso verhindert diese Methode inkonsistente Geschwindigkeit beim Lesen
und Schreiben von daten.
Dieser Befehl muss nur auf einen der Server ausgeführt werden.
141 ceph osd crush rule create - replicated only - ssd default host ssd
2 ceph osd crush rule create - replicated only - hdd default host hdd
Listing 5: Erstellen der Crush rules
Erstellung der Pools
Ceph Pools sind logische Partition zum Speichern der Objekte. Dort werden die Daten
der VMs final gespeichert. Für das Projekt erstellen wir zwei Pools, der erste Pool wird
reiner HDD, und der zweite wird ein reiner SSD Speicher sein.
• Der HDD Speicher wird genutzt, um große Datenmengen zu speichern so wie Si-
cherungen der VMs zu erstellen. z.B Backups, Fileshare
• Der SSD Speicher wird genutzt, um Priorisierte Daten zu verarbeiten. z.B. Daten-
banken, RootFS der VMs.
Dieser schritt muss nur auf einem Node im Web UI durchgeführt werden. Hierzu wird
im Ceph Tab die Option Pools ausgewählt. [Siehe Bild: XXXXX]
Zuerst wird ein Name des Pools vergeben, in dem Fall wird zuerst der SSD Pool erstellt
und somit bekommt der Pool den Namen SSD. Nun wird die Size des Pools bestimmt,
dies bedeutet auf wie vielen Datenträgern eine Kopie der Daten liegt. Die Min. Size hin-
gegen sagt wie viele Datenträger mindestens online und verfügbar sein müssen bevor der
Pool als nicht mehr Lese und Schreiben fähig eingestuft wird, um den höchstmöglichen
Schutz der Daten zu schützen. Die Crush Rule hatten wir im vorherigen schritt schon
erstellt, diese wählen wir nun aus. In diesem Fall only-ssd. Die pgn um wird hierbei auf
Standard belassen.
Der obige schritt kann für die HDDs mit einem angepassten Namen durchgeführt werden.
Lediglich muss außer dem Namen noch die Crush Rule auf only-hdd gestell werden.
6.2.7 Migration von VMs
Wie ich bereits im abschnitt 4.6 gesagt hatte ist der aktuelle CLuster zu Instabile um
von dem aus VMs zu migrieren, unteraderem ist durch die aktuelle Home Office regelung
es mir nicht gestattet in den Ausbildungsbetrieb zu gehen.
156.3 Validierung
Bei der Validierung werden folgende Tests durchgeführt um zu Validieren das die Hoch-
verfügbarkeit des Clusters gewärt ist.
• Ausfalltests der Nodes (Stromausfall, Netzwerk)
• Netzwerk (Auslastung, Packetloss)
• Festplatten (Auslastung)
• CEPH Storage Geschwindigkeit (OSD/Festplatten Ausfall)
Ausfalltests
• Nach dem auschhalten eines Nodes haben die VMs 5 Minuten gebraucht um sich
auf die anderen Beiden Nodes zu migrieren.
• Nach dem Abschalten zweier nodes. Werden keine VMs mehr Migriert, da die
mindestanzahl von Zwei Nodes nicht mehr erfüllt werden, dies hat auch zu folge
dass das Ceph cluster den Pool sperrt.
• Beim abschalten der Netzwerke wurde das gleiche verhatlen vermekrt wie bei dem
Stromausfall.
Nach diesen Ergebnissen können wir rückschlüsse das der drei Node Cluster funktionert.
Bei diesem Cluster ist es wichtig zu merken das wir eine ausfallsicherit auf nur einem
Node haben. Wenn zwei Nodes ausfallen werden keine VMs mirgiert da die Nodes sich
nicht absprechen können.
Dies kann jedoch mit einem Zusätzlich Node oder einem Computer/Server der die ab-
sprache übernimmt überbrückt werden. Dies wird aber nicht vom Proxmox entwicler
team empfolhen.
Netzwerk
Um das Netzwerk zu testen wird das tool Iperf3 genutz, um alle drei Nodes zu be-
lasten werden auf diese ein Ubuntu LXD Container erstellt. Dieser Container enthält
das Progress Iperf3, diese werden als Clienten Konfiguriert und angewisen auf meinen
Arbeitsplatz-PC daten zu senden.
Hiermit wird eine Extreme last erzeugt, damit können wir die Leistung erkennen sowie
ob die Nodes Netzwerk Packages droppen.
• Bei einer Verbindung pro Node werden knapp 1Gbit empfangen und wurden 0
Packete Verloren.
16• Bei drei Verbindungen pro Node werden knapp 266Mbit empfangen und wurden
0 Packete Verloren.
Proxmox hat eine sehr Interligente verteilung der Netzwerklast, dies kann deutlich mit
einen bonding merherer netzwerkkarten gestiegen werden.
Hierzu ist es auch zu empfehlen ein egeies netzwerk für Cepth zu erstelln, diese sollte ein
eigenständiges Netwerk sein mit eigenstädigen Netzwerkkarten. Damit wird die leistung
von cepth enorm gestiegen wenn daten geschreieben und gelesen werden.
Festplatten
Bei einem Festplattenausfall wir man direkt von Ceph behnarrichtigt, in UI wird der
pool direkt als degraidert dargetellt. Nach einem Wechsel der HDD wurde es direkt wie-
der erkannt und Cepth hat direkt angefangen mit der wiederherstelltung.
CEPH Storage
• Datenübetrageung von 47.04Mbit/s.
• Übetragung von einer 120GB vm hat ungefähr 15min gebraucht.
In der aktuellen Konfiguration von dem Ceph Cluster werden die daten die gescheriben
werden mit knapp 47.04 MiB/s gesended. Dies ist für den regulären betrieb sehr wenig.
Ceph empfiehlt mindestens 10Gbit zu verwenden, allerdings sind 40Gbit zu empfehlen.
Damit haben wir dann eine serh schnelle verbindung um die daten ohne verluste und
ähnliches auf jeden Node zu übertragen.
7 Projektabschluss
7.1 Projektübergabe
Das Projekt wurde in einem Abschlussmeeting vorgestellt und an den Auftraggeber des
Projektes übergeben. Dabei wurde insbesondere die korrekte Funktionalität, sowie due
Maßnahmen in Bezug auf die Datensichereit und Performance besprochen. Insbesondere
die Notwendigkeit dies auf optimaler hardware umzusetzen.
7.2 Soll/Ist Vergleich
Im Hinblick auf die Zielsetung des Projektes wurden die Projektziehe mit geringen ab-
weichungen zur vollenden Zufriedenheit des Auftraggebers erreicht.
177.2.1 Sachziele
Die funktionen der Anforderung wurden iin vollen Maße umgesetzt. Bei der verwendeten
hardware gab es wie in 4.6 Abweichungenen gegenüber dem Projektantrag abweichungen
die die resultate verfälschen.
7.2.2 Kostenziele
Das Kostenziel wurde erreicht. Für die gesamte Projektumsetzung wurde aufkostenfreie
OpenSource-Software gesetzt, so dass mit Ausnahme des personellen Aufwan-des keine
Kosten für Lizenzgebühren oder Hardwarebeschaffungen auftraten.
7.2.3 Zeitziel
Die Zeitplaung wurde erreicht, es gab keine abweichungen.
7.2.4 Qualitätsziel
Der gesetze Qualitätsziel wurde erreicht, die Datasicherheit sowie die Stabilität wurde
gewleistet.
7.3 Projektfazit/Reflexion
Das projekt war meines erwartes eine sehr gute aufgabe im Hinblick auf due Thematiken
der Ausbildungzeit. Während des projektes musste einige Themenbereiche im prakti-
schen Umfang angewendet werden (DNS, SSH, Bash, Virtualisierung Datenschutz und
Datensichereit). Dieses Projekt gab mir einen tiefen einblick die Vielzahl wichtiger Vir-
tuallsierungsprozese und migration von vorhanden servern/Vms. Alles in allem bin ich
mit dem Projektergebnis sehr zufrieden und hoffe, dass ich mich in Zukunft durch weitere
Aufgaben im Bereich der Virtualisierung weiter in der Thematik vertiefen kann.
18Sie können auch lesen
