Migration eines Virtualisierungsservers der Syscon Systemberatung AG |
IPA 2019 |
03.04.2019 - 23.04.2019 |
Kandidat: Lukas Bischoff |
Kandidat Lukas Bischoff T +41 76 203 74 12 G +41 44 910 50 10 M shadicfan1991@gmail.com | Betrieb (=Durchführungsort) Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 |
Verantwortliche Fachkraft Egil Rüefli Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 T +41 78 767 84 04 M e.rueefli@rafisa.ch | BerufsbildernIn/Lehrfirma Ruedi Wegelin Rafisa Informatik GmbH Bernstrasse 88, PLZ 8953 T +41 76 555 05 55 M r.wegelin@rafisa.ch |
Hauptexperte Adrian Spahn T +41 78 688 51 52 M adi@adi-net.ch | Nebenexperte Henry Wild T +41 76 375 92 92 M h.wild@sunrise.ch |
1x Dell-Server (PowerEdge R520)
1x Firewall (vorkonfiguriert)
1x Office Switch, unmanaged
1x Image-Datei der Xen-VM krokodil.syscon.ch auf einem USB-Stick
1x Arbeitsplatzrechner mit Windows 10 (vor der IPA eingerichtet)
Programmiersprache: Bash
Startblock 8, KW14: 01.04.2019 – 05.04.2019
IPA-Durchführung: 01.04.2019 – 03.05.2019
Einreichung bis: 01.03.2019
In einer Testumgebung soll anhand der Migration einer ausgewählten Xen-VM ein Migrationskonzept entwickelt werden. Die Xen-VM steht dem Kandidaten als Image-Datei auf einem USB-Stick zur Verfügung. Sie soll auf den Ziel-Server (Proxmox-Server) migriert werden. Die zu migrierende VM ist krokodil.syscon.ch, es handelt sich dabei um einen der beiden DNS-Server der Firma Syscon. Die Gesamtmigration wird erst nach der IPA durchgeführt. Folgende Unteraufgaben sind zu lösen:
- Dokumentation des IST-Zustandes. Dem Kandidaten steht dafür ein Root-Zugang auf dem Xen-Server zur Verfügung:
IPERKA ist eine Projektmethode, die bei Anwendung in einem Projekt eine strukturierte Vorgehensweise bevorzugt.
IPERKA steht für:
Informieren
Planen
Entscheiden
Realisieren
Kontrollieren
Auswerten
Diese Methode hat folgende Vorteile:
Der Speicherort meiner Dokumentation befindet sich auf OneDrive. Dadurch kann ich nicht nur von überall auf die Doku zugreifen und sie bearbeiten, sondern es speichert mir alle Änderungen, die ich vornehme, automatisch in der Cloud ab. Zudem sind die Dokumente auf OneDrive meiner Fachkraft freigegeben.
Sollte OneDrive nicht verfügbar sein, sind die Dokumente auch auf meinem USB-Stick verfügbar.
Für jeden Arbeitstag habe ich einen Ordner erstellt, in dem sich eine neue Version des Dokuments befindet. Hierzu die Ordnerstruktur auf OneDrive…:
…und dieselbe Ordnerstruktur auf meinem USB-Stick:
TAG 1 | |
Datum | Mi, 03.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Systeminformationen des Xen-Servers erfasst und definiert (IST) Informationen der Netzwerkumgebung der Firma Syscon erfasst und daraus einen Netzwerkplan erstellt. Testumgebung aufgebaut Proxmox installiert Evaluation RAID (Vorarbeit) RAID konfiguriert |
Aufgetretene Probleme | Keine |
Reflexion | Das einzig Aufwändige beim Definieren der Systeminformationen war, die Protokolle bestimmter Ports in der Konfigurationsdatei der Firewall herauszufinden (Kapitel 6.1.2.4), wofür ich sehr tief durchs Internet graben musste. Obwohl das Realisieren gemäss Zeitplan erst später vorgesehen wäre, habe ich dies bereits heute während dem Dokumentieren durchgeführt. Zu diesem Zweck habe ich vorgängig das RAID evaluiert, dokumentiert wird das später. Beim Aufbau der Testumgebung sieht der Raum nach dem Verlegen der Server nicht nur viel sauberer aus, sondern ich habe auch etwas Gewicht verloren. |
Wissensbeschaffung | https://www.techrepublic.com/article/set-up-ethernet-aliases-in-linux/ https://www.webopedia.com/quick_ref/portnumbers.asp https://www.fastmail.com/help/technical/ssltlsstarttls.html |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Ja |
TAG 2 | |
Datum | Do, 04.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Systeminformationen des Proxmox-Servers erfasst und definiert (SOLL) L3-Netzwerkdiagramm des Proxmox-Servers erstellt (SOLL) RAID und Proxmox-Storage evaluiert und dokumentiert |
Aufgetretene Probleme | Keine |
Reflexion | Bei der Erstellung des Netzwerkplans musste ich meiner Fachkraft nach den Informationen über bestimmte Netzwerkgeräte (u.a. Firewalls) fragen. Ansonsten gab es keine Stolpersteine. |
Wissensbeschaffung | https://www.aja.com/pdf/support/RAID_Cheat_Sheet.pdf https://pve.proxmox.com/wiki/Storage https://en.wikibooks.org/wiki/QEMU/Images |
Beanspruchte Hilfe | Informationen über die betriebliche Firewall von der Fachkraft bezogen. |
Zeitplan eingehalten | Ja |
| TAG 3 ||
Datum | Di, 09.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Testumgebung dokumentiert RAID dokumentiert Proxmox dokumentiert |
Aufgetretene Probleme | Keine |
Reflexion | Am ersten Tag habe ich abweichend vom Zeitplan bereits die Testumgebung und den Server eingerichtet und habe zudem die notwendigen Screenshots gemacht. Heute habe ich alles sauber dokumentiert. |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Ja |
| TAG 4 ||
Datum | Mi, 10.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Migration der Xen-VM von Hand |
Aufgetretene Probleme | Die VM startet in Proxmox nicht. |
Problemlösung | Noch keine gefunden. |
Reflexion | Mit Hilfe eines Tutorials habe ich die manuelle Migration durchgeführt. Die migrierte VM habe ich dann in Proxmox versucht zu starten, was aus unerklärlichen Gründen leider nicht funktioniert hat. Dennoch habe ich noch einen ganzen Tag Zeit, um das Problem zu lösen. |
Wissensbeschaffung | https://blog.filippo.io/converting-a-partition-image-to-a-bootable-disk-image/ |
Beanspruchte Hilfe | Ein passendes Tutorial mit meiner Fachkraft zu finden. |
Zeitplan eingehalten | Ja |
| TAG 5 ||
Datum | Do, 11.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Systeminformationen des Proxmox-Servers erfasst und definiert (SOLL) L3-Netzwerkdiagramm des Proxmox-Servers erstellt (SOLL) RAID und Proxmox-Storage evaluiert und dokumentiert |
Aufgetretene Probleme | Die VM startet in Proxmox nicht. Die VM bekommt keine Pakete von der Repository. |
Problemlösung | Eine VM in Proxmox erstellen und diese durch das Image ersetzen. Die archivierte Repository in /etc/apt/sources.list kopieren und die obsoleten auskommentieren. |
Reflexion | Die Migration konnte trotz der Probleme gemäss Zeitplan durchgeführt werden. Dennoch konnte ich dank den Problemen einige neue Sachen lernen, u.a. archivierte Repositories in Debian. |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Ja |
| TAG 6 ||
Datum | Mo, 15.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Erstellung eines Bash-Skripts für die automatisierte Migration. |
Aufgetretene Probleme | Keine |
Reflexion | Basierend auf den Befehlen, die ich während der manuellen Migration verwendet habe, konnte ich die meisten davon im Prinzip auf das Skript übertragen. Natürlich brauchte es einige Workarounds (z.B. Programme, die Benutzerinteraktion erfordern), um bestimmte Befehle in einem Skript zum Laufen zu bringen, aber dank einiger Linux-Tricks, die meine Fachkraft mir beigebracht hat, war es nicht schwer, die Migration mittels Skript zu automatisieren. |
Wissensbeschaffung | https://superuser.com/questions/1003760/what-does-eof-do |
Beanspruchte Hilfe | Tipps und Tricks von meiner Fachkraft. |
Zeitplan eingehalten | Ja |
| TAG 7 ||
Datum | Di, 16.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Migrationsplanung für die Gesamtmigration aller VMs erstellen |
Aufgetretene Probleme | Keine |
Reflexion | In Absprache mit dem Kunden konnte ich entnehmen, wie er sich die Migration vorstellt und erstellte die Planung der Gesamtmigration auf Basis seiner Bedarfe. |
Wissensbeschaffung | https://www.thomas-krenn.com/de/wiki/Link_Aggregation_und_LACP_Grundlagen http://www.linfo.org/runlevel_def.html |
Beanspruchte Hilfe | Absprache mit dem Kunden (meine Fachkraft) was seine Bedürfnisse für die Migration sind. |
Zeitplan eingehalten | Ja |
| TAG 8 ||
| TAG 9 ||
Datum | Do, 18.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Auswertung der Ergebnisse Glossar schreiben |
Aufgetretene Probleme | Keine |
Reflexion | Die Einhaltung des Zeitplans und die Erreichung der IPA-bezogenen Ziele habe ich in der Dokumentation ausgewertet. Danach habe ich ein Glossar mit alle in der Dokumentation aufgeführten Fachbegriffe erstellt. |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Ja |
| TAG 10 ||
Datum | Di, 23.04.2019 |
Arbeitszeit | 08:00-17:00 |
Ausgeführte Aufgaben | Reflexion schreiben |
Aufgetretene Probleme | Keine |
Reflexion | Da es nicht vieles gab, was ich aus der praktischen Arbeit dazulernte, habe ich die Reflexion basierend auf das geschrieben, was ich von der IPA auf persönlicher Ebene gewonnen habe. Einschliesslich, wie man sich während der Arbeit nur auf das was vor einem liegt konzentriert, um seine Kapazität effektiv nutzen zu können und sich so zu organisieren, dass man weder unter- noch überfordert wird. |
Wissensbeschaffung | Keine |
Beanspruchte Hilfe | Keine |
Zeitplan eingehalten | Ja |
Die Firma Syscon Systemberatungs AG verfügt über einen Server im Internet (ozelot.syscon.ch), auf welchem für eigene Dienste aber auch für externe Kunden virtuelle Maschinen (VMs) zur Verfügung gestellt werden. Die Basis für die VMs bildet die Community-Version der Virtualisierungsplattform Xen. Der X4100-Server von Sun ist inzwischen 10-jährig und sowohl von der Kapazität als auch von der Leistung her nicht mehr ausreichend. Es wurde deshalb beschlossen, auf eine neuere Hardware zu migrieren.
Neben der Migration auf eine neue Hardware soll auch die Virtualisierungsplattform auf das leichter zu verwaltende, KVM basierte Proxmox VE umgestellt werden. Dabei sind verschiedene Herausforderungen zu meistern. Bei den Xen-VMs handelt es sich ausnahmslos um Linux-Maschinen, die als LVM-Raw-Block-Devices mit einem Root- sowie einem Swap-Device aufgebaut sind. Das Root-Device verfügt weder über eine Partitionstabelle noch über einen MBR. Die VMs werden mit Hilfe des Xen-eigenen Bootloaders (PyGrub) gestartet. Damit sie in der Proxmox-Umgebung gebootet werden können, müssen die Raw-Block-Devices zunächst mit einer Partitionstabelle, einem MBR sowie einem eigenen Bootloader versehen werden. Zusätzlich müssen alle Xen-spezifischen Anpassungen in den VMs rückgängig gemacht werden.
Für die Migration werden folgende Schritte durchgeführt:
Mit der neuen Hardware kann die Firma Syscon Systemberatungs AG von einer exponentiell höheren Systemleistung und einer einfacheren Benutzeroberfläche profitieren, während die Kundenzufriedenheit durch eine bessere VM-Performance erhöht wird.
Die Firma Syscon Systemberatungs AG verfügt über einen produktiven Server mit verschiedenen VMs auf der Basis der Virtualisierungslösung Xen. Dieser Server soll auf eine neue Hardware migriert werden.
Der Layer 2-Switch ist im Netzwerkplan nicht angegeben.
Die Systeminformationen habe ich durch Eingabe der folgenden Befehle abgerufen:
| Bezeichnung | Sun Fire X4100 |
Standort | Genossenschaft Dreieck Serverraum UG1 Ankerstrasse 11 |
OS | Xen 4.0.1 |
CPU | 2x Dual Core AMD Opteron 275 @ 2,2 GHz |
Memory | 12 GB DDR @ 400 MHz |
Disks | 2x 600 GB |
RAID-Controller | Symbios Logic SAS1064 PCI-X Fusion-MPT SAS |
RAID-Level | RAID 1 |
Partitionierung | /dev/sda1; 200 MB, Linux (Boot) /dev/sda2; 2 GB, Linux Swap /dev/sda3; 20 GB, Linux /dev/sda4; 578 GB, Linux LVM |
Netzwerk-Interfaces | 4x Intel Corporation 82546EB Gigabit Ethernet Controller |
Ansprechperson für alle VMs und des Xen-Servers | Egil Rüefli egil.ruefli@syscon.ch |
Inhalt von /etc/network/interfaces.
Die Interfaces mit einem Doppelpunkt sind sogenannte Aliases.
Mit Aliases kann man mehrere IP-Adressen einer einzigen Netzwerkkarte zuweisen.
Mit /etc/hosts kann man Rechnernamen in IP-Adressen auflösen, wenn kein Nameserver im lokalen Netzwerk vorhanden ist.
Die Datei /etc/network/if-up.d/iptables verwendet Skripts, um die Firewall unter Linux zu konfigurieren. Es wird auch für Portforwarding verwendet. Über die Ports habe ich die Dienste herausgefunden und als Kommentar dokumentiert.
Nach dem Starten der VM mit «xl create /etc/xen/krokodil.syscon.ch.cfg» wird der Verwaltungszugriff auf die VM durch den folgenden Befehl gewährt:
Jetzt müssen wir nur noch die ID unserer VM herausfinden. Dies machen wir mit dem Befehl «xm list»:
Mit der erlangten ID können wir nun Zugriff auf die entsprechende VM erhalten:
Die Konsole kann durch Drücken von Ctrl + ] verlassen werden, oder Ctrl + 5, wenn wir Putty verwenden.
Dieses Vorgehen gilt für alle VMs.
Wenn wir unserer VM eine andere IP-Adresse, eine andere MAC-Adresse, mehr Arbeitsspeicher usw. zuweisen wollen, können wir die Datei /etc/xen/<DomU>.cfg, oder in diesem Fall /etc/xen/krokodil.syscon.ch.cfg verwenden, um eventuelle Änderungen vorzunehmen:
Auf dem Originalserver wurde ein Raw-Image der VM krokodil.syscon.ch erstellt. Dazu wurde zunächst ein verschlüsselter Zugriff auf dem Server via SSH eingerichtet.
Mit dem Befehl «lvscan» können wir den Standort der zu migrierenden VM finden:
Für dieses Logical Volume erzeugen wir einen Snapshot:
Mit dem Befehl «dd» können wir nun ein Image aus dem Snapshot erstellen:
Wie in der Aufgabenstellung vermerkt, wurde mir dieses Image auf einem USB-Stick zur Verfügung gestellt.
krokodil-root.img: Linux rev 1.0 ext3 filesystem data, UUID=b3db1946-6314-461e-9d13-b6f89dfbf86c (large files) |
Es handelt sich um ein ext3-formatiertes Raw-Image. Dieses Image sollte sich direkt mit dem mount-Befehl einbinden lassen.
Von der Beschäftigung mit Xen ist bekannt, dass Xen die Partitionen anders benennt als Proxmox. Die Benennung der Partitionen, die während des Systemstarts eingebunden werden, befinden sich in «etc/fstab». Der Befehl «cat /mnt/etc/fstab» zeigt folgenden Inhalt:
# # <file system> <mount point> <type> <options> <dump> <pass> proc /proc proc defaults 0 0 devpts /dev/pts devpts rw,noexec,nosuid,gid=5,mode=620 0 0 /dev/xvda1 none swap sw 0 0 #/dev/xvda2 / ext3 sync,errors=remount-ro 0 1 /dev/xvda2 / ext3 errors=remount-ro 0 1 |
In Zeile 7 wird die Root-Partition eingebunden, in Zeile 5 die Swap-Partition. Die Partitionsbezeichnungen «xvda1» und «xvda2» müssen für Proxmox angepasst werden, da dieser anstatt «xvdx» die Bezeichnung «sdx» verwendet.
Die nächste und letzte Datei, an der wir Änderungen vornehmen müssen, ist inittab.
Diese Datei bestimmt, was passiert, wenn ein System neu gestartet wird oder gezwungen wird, den Runlevel (Zustand des Systems) zu wechseln.
Untenstehend ist der Ausschnitt, an dem Änderungen vorgenommen werden müssen:
In Xen wird die merkwürdige Abkürzung «tty» (=Terminal) durch «hvc» ersetzt. Diese muss wieder auf «tty1» geändert werden.
Der Serververantwortliche bestätigte mir, dass jede VM dieselben Xen-spezifischen Änderungen aufweist.
Folgend sind die Spezifikationen des PCs, der mir zur Verfügung gestellt wurde:
Bezeichnung | HP p6-2210ezm |
Standort | Serverraum 2. OG Bernstrasse 88 |
OS | Windows 10 Enterprise 2016 LTSB |
CPU | Quad Core Intel Core i5-2320 @ 3,0 GHz |
Memory | 8 GB @ 800 MHz |
Disks | 1x 120 GB |
Bezeichnung | Dell PowerEdge R520 |
Standort | Serverraum 2. OG Bernstrasse 88 |
OS | Proxmox 5.3-2 |
CPU | Quad Core Intel Xeon E5-2407 @ 2,2 GHz |
Memory | 64 GB @ 1'600 MHz |
Disks | 4x 300 GB |
RAID-Controller | Symbios Logic MegaRAID SAS 2208 |
RAID-Level | RAID 5 (In Kapitel 8 evaluiert) |
Partitionierung | /dev/sda1; 1 MB, BIOS Boot /dev/sda2; 512 MB, EFI System /dev/sda3; 836 GB, Linux LVM; /dev/pve/swap (8 GB) /dev/pve/root (96 GB) /dev/pve/data (702 GB) |
Netzwerk-Interfaces | 2x Broadcom Limited NetXtreme BCM5720 Gigabit Ethernet |
Inhalt von /etc/network/interfaces.
Ports: 20 (SSH), 53 (DNS)
Dienste: DNS
Der Verwaltungszugang erfolgt über das Webinterface. Nach dem Starten der VM greift man auf das Terminal mit der Schaltfläche «Console» zu:
Da drei Personen im gleichen Raum arbeiten, muss das Netzwerk im Projektumfeld so eingerichtet sein, dass sich unsere Geräte nicht gegenseitig beeinträchtigen. Mit anderen Worten, der Umbau des Netzwerks wird verhindern, dass eines unserer Geräte eine IP-Adresse zugewiesen bekommt, die bereits vergeben ist.
Um dies zu realisieren, wird jedem von uns eine eigene DMZ (Demilitarized Zone) in jeweils einem anderen Subnetz zugewiesen. Um das Umfeld übersichtlich zu gestalten, werden auch jedes Gerät und jedes Netzwerkkabel entsprechend etikettiert.
Hardware:
Software:
Gemäss Zeitplan:
Datum | Meilenstein (gem. IPERKA) |
03.04.2019 | Kapitel «Informieren» abgeschlossen. |
04.04.2019 | Kapitel «Planen» abgeschlossen. |
04.04.2019 | Kapitel «Entscheiden» abgeschlossen. |
16.04.2019 | Kapitel «Realisieren» abgeschlossen. |
17.04.2019 | Kapitel «Kontrollieren» abgeschlossen. |
23.04.2019 | Kapitel «Auswerten» abgeschlossen. |
Zur Erfolgskontrolle werden folgende Schritte durchgeführt:
In diesem Kapitel werden die folgenden Schwerpunkte evaluiert, um die Anforderungen des SOLL-Zustandes zu erfüllen:
Ein RAID (Redundant Array of Independent Disks) dient dazu, die Zuverlässigkeit und Leistung der Daten zu erhöhen. Wenn Festplatten zusammen in einem RAID-Array laufen (abhängig vom RAID-Level), können die Laufwerke redundante Kopien der Daten speichern und/oder die Lesegeschwindigkeit erhöhen, indem sie kleinere Blöcke von Daten auf mehrere Laufwerke verteilen.
Ein paar der wichtigsten RAID-Levels sind:
RAID 0:
Die Daten werden über eine Reihe von Laufwerken verteilt, um die Leistung zu erhöhen. Dies geschieht dadurch, dass zwei Platten mithilfe von RAID 0 im Prinzip kombiniert werden, was die Anzahl der IOPS (Input/Output Operations Per Second) in der Regel* verdoppelt.
RAID 0 sichert die Daten wie andere Arrays nicht, also wenn ein einzelnes Laufwerk ausfällt, gehen alle Daten auf dem Array verloren.
*Das Schlüsselwort hier ist „up to“: Aufgrund der Art des Stripings und der Datenausrichtung, wenn sich die zufällig aufgerufenen Sektoren überwiegend auf einer einzigen Festplatte befinden, endet man mit viel niedrigeren IOPS.
RAID 1
Alle Daten auf einem Laufwerk werden parallel auf jedes andere Laufwerk im Array kopiert. RAID 1 bietet die doppelte Leserate, aber die Schreibgeschwindigkeit eines einzelnen Laufwerks.
RAID 01 (ist nicht dasselbe wie RAID 10)
Es werden zwei oder mehr RAID 0-Arrays erstellt, die jeweils über ein übergeordnetes RAID 1-Array gespiegelt werden (bei RAID 10 wäre es umgekehrt). Gemäss Definition erfordert diese Konfiguration mindestens 4 Laufwerke.
RAID 5
Bietet sowohl Sicherung als auch erhöhte Leistung. Zusätzlich kann ein RAID 5-Array weiterhin normal arbeiten, wenn eines seiner Laufwerke ausfällt. Die Leistungsgeschwindigkeit des Arrays wird reduziert, bis das ausgefallene Laufwerk ausgetauscht wird, aber es würde kein Datenverlust auftreten. Dieses Array benötigt mindestens 3 Laufwerke.
RAID 6
Ähnlich wie RAID 5 bietet RAID 6 sowohl Sicherung als auch erhöhte Leistung. Zudem kann ein RAID 6-Array bei Ausfall von bis zu zwei seiner Laufwerke weiterarbeiten. Hierfür sind mindestens 4 Laufwerke notwendig.
Bilder: https://www.aja.com/pdf/support/RAID_Cheat_Sheet.pdf
| Gewichtung | RAID 0 | RAID 1 | RAID 01 | RAID 5 | RAID 6 |
Erhöhte Leistung | KO-Kriterium | Ja | Nein | Nein | Ja | Ja |
Ausfallsicherheit | KO-Kriterium | Nein | Ja | Ja | Ja | Ja |
Die Gewichtungen wurden vorgängig vom Kunden festgelegt.
Kriterium | Gewichtung | RAID 5 | RAID 6 | Total RAID 5 | Total RAID 6 |
Leistung | 6 | 6 | 6 | 36 | 36 |
Ausfallsicherheit | 6 | 6 | 8 | 36 | 48 |
Kapazität | 8 | 8 | 6 | 64 | 48 |
Total | | | | 136 | 132 |
Skala: 0-10
Obwohl RAID 5 und RAID 6 sehr ähnlich sind, erwies sich RAID 5 letztendlich als die bessere Option, da es im Gegensatz zu RAID 6 nur ein Laufwerk als Redundanz verwendet anstelle von zwei.
Wenn es bspw. mindestens zehn Laufwerke im RAID gegeben hätte, dann hätte ich RAID 6 als die bessere Option angesehen, da ein Ausfall mehrerer Festplatten im Gegensatz zu RAID 5 kein so grosses Problem dargestellt hätte.
Die folgenden Schwerpunkte werden bei jedem Speicherformat ausgewertet:
Ähnlich wie bei der RAID-Evaluation scheiden zuerst die Formate aus, die unsere KO-Kriterien nicht erfüllen. Diesmal jedoch treten die restlichen Konkurrenten in einem Geschwindigkeitstest an, da die Geschwindigkeit der Hauptfaktor in der Bewertung sein wird. Bevor wir aber die Speicherformate evaluieren, hier noch ein kurzer Überblick über die wichtigsten Eigenschaften der jeweiligen Formate:
QEMU Image Format (qcow):
qcow ist ein Dateiformat für Disk-Image-Dateien, das von QEMU, einem gehosteten Monitor für virtuelle Maschinen, verwendet wird. Es steht für «QEMU Copy On Write» und verwendet eine Strategie zur Optimierung des Festplattenspeichers, die die Zuweisung von Speicherplatz verzögert, bis er tatsächlich benötigt wird. Es gibt zwei Versionen des Formats: qcow und qcow2.
Raw Disk Image:
Ein Raw Disk Image enthält eine exakte, sektorweise Kopie einer einzelnen Partition oder Festplatte.
VMware Image (vmdk):
vmdk (kurz für Virtual Machine Disk) ist ein Dateiformat, das Container für virtuelle Festplattenlaufwerke beschreibt, die in virtuellen Maschinen wie VMware Workstation oder VirtualBox verwendet werden.
LVM:
Unter Linux ist der Logical Volume Manager (LVM) ein Gerätezuordnungsziel, das die logische Datenträgerverwaltung für den Linux-Kernel bereitstellt.
LVM-Thin:
LVM weist normalerweise Blöcke zu, wenn ein Volume erstellt wird. LVM-Thin weist stattdessen Blöcke zu, wenn sie geschrieben werden. (Ähnlich wie bei QEMU.) Dieses Verhalten wird Thin Provisioning genannt.
ZFS:
ZFS ist ein kombinierter Dateisystem- und logischer Volume-Manager, entwickelt von Sun Microsystems. ZFS ist skalierbar und bietet umfassenden Schutz vor Datenkorruption, Unterstützung hoher Speicherkapazitäten, effiziente Datenkompression, Snapshots und Copy-on-Write-Klone, kontinuierliche Integritätsprüfung, automatische Reparatur und kann sehr präzise konfiguriert werden.
| Gewichtung* | QEMU Image Format | Raw Disk Image | VMware Image | LVM | LVM-Thin | ZFS |
Storage-Typ | | dir | dir | dir | lvm | lvmthin | zfspool |
Format | | qcow2 | raw | vmdk | lvm | lvmthin | zfs |
Level | | file | file | file | block | block | file |
Snapshots | KO-Kriterium | ja | nein | nein | ja | ja | ja |
Auf HW-RAID | KO-Kriterium | ja | ja | ja | ja | ja | nein |
Thin Provision | KO-Kriterium | ja | nein | nein | nein | ja | Ja |
Quelle: https://pve.proxmox.com/wiki/Storage
*Die Gewichtung richtet sich nach den Bedürfnissen der Migration.
Die Leistung der beiden prominentesten Speicherformate habe ich bereits vor der IPA (siehe Vorarbeiten) mit einem Programm namens Fio (Flexible I/O Tester) getestet. Mit Fio können Geräte wie Festplatten oder SSDs bezüglich ihrer Geschwindigkeit getestet werden, indem ein vom User definierter Workload ausgeführt und Performance-Daten gesammelt werden.
Für die Performance-Messung wurde auf einem Proxmox-Host-System je eine 20 GB grosse virtuelle Platte im qcow2-Format bzw. als LVM-Thin-Image angelegt und mit folgendem Befehl getestet:
–randrepeat=1 | Der Zufallsgenerator erzeugt vergleichbare Patterns für alle Requests. |
–ioengine=libaio | libaio ist die Library zum Absetzen paralleler I/O-Requests. |
–iodepth=64 | Anzahl der parallelen Requests. |
–direct=1 | Pagecache wird umgangen. |
–name=perftest | Name des Tests. |
–filename=/dev/pve/vm-100-disk-0 | Disk oder File, in das geschrieben wird (hier ein LVM-Thin-Image. |
–size=1G | Grösse des zu schreibenden und zu lesenden Patterns. |
–readwrite=randrw | Zugriffsmethode; hier ein gemischter, zufälliger Workload. |
–rwmixread=75 | 75% des Workloads Schreibzugriffe, 25% Lesezugriffe (vgl. den Wert io= in untenstehenden Resultaten. |
Hier sind die Resultate des Tests:
QEMU Image Format:
LVM-Thin:
io | Gibt die Menge der insgesamt durchgeführten I/O an. |
aggrb | Die gesamte Bandbreite über alle Prozesse/Geräte. |
minb/maxb | Zeigt die minimale/maximale gemessene Bandbreite an. |
mint/maxt | Zeigt die kürzesten und längsten Testzeiten an. |
Dem aggregierten Wert aggrb= kann man entnehmen, dass LVM-Thin sowohl beim Lesen als auch beim Schreiben viermal so schnell ist wie QEMU. Da wäre LVM-Thin ja ein durchaus fleissiger Schriftsteller! Was für einen Einfluss diese Leistung auf unsere Evaluation haben wird, sehen wir in der folgenden Präferenzmatrix.
Wiederum hier wurden die Gewichtungen vorgängig mit dem Kunden zusammen festgelegt:
Kriterium | Gewichtung | QEMU Image Format | LVM-Thin | Total QEMU Image Format | Total LVM- Thin |
Performance | 8 | 2.5 | 10 | 20 | 80 |
Portabilität | 4 | 6 | 4 | 24 | 16 |
Einfachheit | 4 | 8 | 4 | 32 | 16 |
Total | | | | 76 | 112 |
Skala: 0-10
Die Entscheidung fällt klar auf LVM-Thin.
Nr. | Arbeitspaket | Dauer | Starttermin | Endtermin |
1 | Vorbereitung | 2 Tage | 03.04.2019 | 05.04.2019 |
2 | IST Serverspezifikationen erfassen und definieren | 1 Tag | 03.04.2019 | 04.04.2019 |
3 | IST L3-Netzwerkdiagramm erstellen | 1 Tag | 03.04.2019 | 04.04.2019 |
4 | SOLL Serverspezifikationen definieren | 1 Tag | 04.04.2019 | 05.04.2019 |
5 | SOLL L3-Netzerkdiagramm erstellen | 1 Tag | 04.04.2019 | 05.04.2019 |
6 | Evaluation | 1 Tag | 04.04.2019 | 05.04.2019 |
7 | RAID und Proxmox Storage evaluieren | 1 Tag | 04.04.2019 | 05.04.2019 |
8 | Durchführung | 5 Tage | 09.04.2019 | 17.04.2019 |
9 | Aufbau der Testumgebung | 1 Tag | 09.04.2019 | 10.04.2019 |
10 | Server aufsetzen, RAID konfigurieren | 1 Tag | 09.04.2019 | 10.04.2019 |
11 | Xen-VM von Hand migrieren | 2 Tage | 10.04.2019 | 12.04.2019 |
12 | Bash-Skript für die automatisierte Migration erstellen | 1 Tag | 15.04.2019 | 16.04.2019 |
13 | Migrationsplanung für die Gesamtmigration aller VMs erstellen | 1 Tag | 16.04.2019 | 17.04.2019 |
14 | Kontrollieren | 1 Tag | 17.04.2019 | 18.04.2019 |
15 | Testszenario erstellen | 1 Tag | 17.04.2019 | 18.04.2019 |
16 | Tests durchführen | 1 Tag | 17.04.2019 | 18.04.2019 |
17 | Auswerten | 2 Tage | 18.04.2019 | 23.04.2019 |
18 | Ergebnisse auswerten | 1 Tag | 18.04.2019 | 19.04.2019 |
19 | Reflexion schreiben | 1 Tag | 23.04.2019 | 23.04.2019 |
Um während der IPA in meinem eigenen Subnetz arbeiten zu können, wurden ich und meine Kollegen beauftragt, unsere Testumgebung folgendermassen anzupassen:
Der Server ganz oben ist derjenige, mit dem ich arbeite. Dieser ist mit einem unmanaged Switch verbunden, der wiederum mit der Firewall verkabelt ist und so eine DMZ bildet.
Folgend sind die IP-Adressen aller Nodes aufgeführt:
Netzwerk | 192.168.20.0 |
Firewall / Gateway | 192.168.20.1 |
ozelot.syscon.ch | 192.168.20.20 |
Mit den evaluierten RAID-Levels und Proxmox Storages haben wir festgestellt, dass die Verwendung von LVM-Thin als primäre Option und die Einrichtung unserer Laufwerke mit RAID 5 unsere beste Wahl ist (siehe Kapitel 8). Die Begründung lautet wie folgt:
Mit LVM-Thin (Thin Provisioning) profitieren wir zunächst einmal davon, dass wenn wir bei der Erstellung unserer VMs davon ausgehen, dass wir 5 GB einer VM zuweisen und das System nur 2 GB verwendet, stehen die verbleibenden 3 GB im sogenannten Thin Pool frei zur Verfügung. Das bedeutet zum Beispiel, wenn ich 15 GB Speicherplatz zur Verfügung habe und jeweils 5 GB für 3 Clients reserviere, hätte ich mit ziemlicher Sicherheit immer noch Platz für einen vierten Client, da der von den anderen 3 Clients ungenutzte Speicher für die Erstellung eines vierten Clients verwendet werden kann und somit nicht als verschwendeter Speicher gilt.
Zudem ist LVM-Thin, wie die Performance-Tests bei der Evaluierung gezeigt haben, recht schnell. Zwar schlägt Raw die anderen immer noch um ein Mehrfaches, aber auch LVM-Thin ist keineswegs langsam.
Was das RAID betrifft, legte ich den Fokus sowohl auf Kapazität als auch auf Zuverlässigkeit, weshalb ich RAID 5 den anderen RAID-Levels vorzog. RAID 6 war ziemlich nah dran, da es sich nur geringfügig von RAID 5 unterscheidet, aber da RAID 5 nur ein Laufwerk für die Redundanz anstelle von zwei verwendet - was bei vier Laufwerken meiner Meinung nach nicht wirklich vonnöten ist - gibt es uns mehr Speicherplatz zur Verfügung.
Durch Drücken von Ctrl + R während des Bootvorgangs gelangen wir zum RAID-Controller.
Untenstehend sehen wir unsere Laufwerke als unkonfiguriert, was darauf hindeutet, dass unsere Festplatten von unserem Server korrekt erkannt werden und somit bereit sind, für ein RAID konfiguriert zu werden.
Dies geschieht durch Auswahl des RAID-Controllers und der Option «Create New VD (Virtual Disk)»:
Hierdurch wird das folgende Menü geöffnet. Hier wählen wir RAID 5 als unseren RAID-Level, wählen jede unserer Festplatten aus und schliessen die Konfiguration mit «OK» ab:
Nun, noch nicht ganz. Wie das System uns mitteilt, wird empfohlen, zuerst die logischen Laufwerke zu initialisieren:
Diese Option finden wir unter «Advanced Settings»:
Und wie folgt, ist unsere RAID-Konfiguration somit abgeschlossen:
Für die Installation von Proxmox verwenden wir ein bootfähiges USB-Laufwerk, auf dem sich die neueste Version des Installations-Images befindet.
Folgend ist die Netzwerkkonfiguration des Systems. Den Rest der Installation belassen wir bei den Standardeinstellungen.
Nach Drücken von «Install» soll es nur ein paar wenige Minuten dauern…:
Et voila. Schon ist unser Server einsatzbereit:
Zunächst habe ich auf Google verschiedene Anleitungen gefunden. Zusätzlich habe ich noch den Link zu einer Anleitung von meiner Fachkraft bekommen:
https://blog.filippo.io/converting-a-partition-image-to-a-bootable-disk-image/
Da das von meiner Fachkraft gefundene Tutorial am hilfreichsten erschien, habe ich es für die Migration verwendet.
Folgende Schritte sind enthalten:
Nach sorgfältiger Durchführung des Tutorials stellte sich heraus, dass die Anleitung an die Migration angepasst werden musste, damit die VM in Proxmox funktionieren kann (siehe Kapitel 9.4.2). Ich bin eigentlich froh darüber, denn wenn die VM auf Anhieb funktioniert hätte, wäre die IPA ja zu einfach gewesen.
Zunächst brauchen wir vor der ersten Partition einen Bereich von 1 MB zur Aufnahme von einem MBR und einem Bootloader. Mit dem folgenden Befehl erzeugen wir zu diesem Zweck ein kleines Image, das nur aus Nullen besteht:
Dieses hängen wir hinter dem Original-Image mit einem Programm namens «pv» an:
Mit «fdisk» erstellen wir nun eine Partitionstabelle…:
…und geben nacheinander folgende Parameter ein:
Daraus ergibt sich ein Image mit der zu migrierenden Xen-VM und einer leeren, bootfähigen Partition, in der wir gleich anschliessend einen Bootloader installieren werden.
Theoretisch könnten wir den Bootloader bereits jetzt installieren, aber nach gründlichen Tests stellte sich heraus, dass wir zusätzlich noch ein paar Schritte durchführen müssen, damit die VM einwandfrei funktionieren kann.
Zunächst einmal, anstatt das Image mit der Xen-VM zu migrieren und daraus eine Proxmox-VM zu erzeugen, machen wir es umgekehrt und erstellen zuerst die Proxmox-VM im Webinterface gemäss den Angaben in Kapitel 6.1.2.6 und ersetzen deren Inhalt später durch das Image:
Da wir den Inhalt der Proxmox-VM über das Terminal ersetzen, anstatt ein Installationsimage zu verwenden, wählen wir «Do not use any media»:
Die Xen-VM ist ca. 8 GB gross, also runden wir die Grösse der Proxmox-VM auf 10 GB:
Der Xen-VM wurde bisher ein Kern zugeordnet, also weisen wir ihr auch hier einen Kern zu:
Das Gleiche gilt auch für den Arbeitsspeicher:
Die neue VM wird an die interne Bridge vmbr0 angeschlossen. Die restlichen Netzwerkeinstellungen lassen wir so, wie sie sind:
Abschliessend bestätigen wir die Erstellung mit «Finish»:
Zusätzlich wollen wir der VM noch eine Swap-Disk anlegen, welche wie bei einer Auslagerungsdatei in Windows als Reserve für den Arbeitsspeicher dient. Für dies erstellen wir eine neue virtuelle Hard Disk mit der Grösse von 2 GB:
Da ich keine Möglichkeit gefunden habe, eine Swap-Disk mithilfe des Webinterfaces zu erstellen, machen wir dies stattdessen mit dem Terminal. Zunächst müssen wir herausfinden, wo Proxmox die virtuellen Hard Disks anlegt. Nach einer einfachen Google-Suche stellte sich heraus, dass sich die Disks in /dev/pve befinden:
Mit «mkswap» verwandeln wir die 2 GB grossen Disk in eine Swap-Disk:
Nach der Erstellung der Proxmox-VM können wir jetzt dieses durch unser Image ersetzen. Dies machen wir wiederum mit dem Kopierbefehl «dd»:
Jetzt kommen wir endlich zum Teil, wo wir den Bootloader installieren können. Hierfür müssen wir die VM zunächst in die Partition zerlegen, die wir im vorherigen Kapitel mit «fdisk» erstellt haben, um sie mountbar zu machen. Dies machen wir mit einem Programm namens «kpartx»:
Nun mounten wir die zerlegte Partition in den Mount-Punkt /mnt…:
…und installieren abschliessend den Bootloader mit dem folgenden Befehl:
Anders als bei anderen Virtualisierungsplattformen verfügt Xen über eine eigene Methode um VMs zu betreiben. Damit unsere VM also auf Proxmox laufen kann, müssen wir Änderungen in den folgenden Konfigurationsdateien vornehmen:
Ausgenommen von /boot/grub/grub.cfg erfolgt eine Änderung, indem wir mit «nano» die jeweiligen Werte anpassen:
Für /boot/grub/grub.cfg verwenden wir den Befehl «grub-mkconfig», da es sich hier um eine komplette Neukonfiguration des Bootloaders handelt.
Die fstab-Datei listet alle verfügbaren Festplattenpartitionen und andere Arten von Dateisystemen auf und gibt an, wie sie während des Bootvorgangs gemountet werden sollen.
Geändert wird das in Rot:
Ersetzt wird «xvda1» durch «sdb» und «xvda2» durch «sda1»:
Um die Änderungen zu übernehmen, drücken wir Ctrl + O und Ctrl + X.
Diese Datei definiert drei Elemente für den init-Prozess:
Sobald alle Einträge in /etc/inittab für das Runlevel ausgeführt wurden, ist der Bootvorgang abgeschlossen und man kann sich anmelden.
Folgend ist nur der Teil dargestellt, der geändert werden muss. Diese Änderung muss vorgenommen werden, da Xen und Proxmox zwei unterschiedliche Terminals/Serial Consoles verwenden:
Ersetzt wird «hvc0» zu «tty1»:
resolv.conf wird verwendet, um den DNS des Systems zu konfigurieren.
Da der DNS-Dienst der VM während der Migration nicht funktionsfähig ist und wir im nächsten Schritt einen Zugang zum Internet benötigen, ersetzen wir «127.0.0.1» (localhost) vorübergehend durch «8.8.8.8» (DNS-Server von Google):
Nach der Migration stellen wir den Wert zurück auf localhost, damit der DNS-Dienst wie üblich funktionieren kann.
- /boot/grub/grub.cfg
Xen verwendet einen speziellen Bootloader namens «PyGrub», den Proxmox nicht unterstützt. Änderungen am Bootloader werden mit dem Befehl «grub-mkconfig» übernommen, aber da grub-mkconfig auf Konfigurationsdateien angewiesen ist, die auf dem laufenden System vorhanden sind, müssen wir sie ebenfalls mounten:
Danach machen wir einen chroot in unseren Mount-Punkt, um uns die Konfiguration des Bootloaders zu ermöglichen:
Als nächstes müssen die Paketlisten aktualisiert werden, damit wir die neueste Version des Bootloaders installieren können. Hierzu ist beim Ausführen des Befehls «apt-get update» folgende Fehlermeldung aufgetreten:
Dazu konnte ich nur die Stirn runzeln. Mit dem Internet verbinden kann ich ja, wieso funktioniert jetzt «apt-get update» nicht?
Folglich hat mir meine Fachkraft darauf hingewiesen, dass der Support von Debian Wheezy, auf was sich die VM basiert, ausgerechnet während der IPA eingestellt wurde. Und tatsächlich, wie https://wiki.debian.org/DebianWheezy bekanntgibt, wurde Wheezy vor kurzem ins Archiv verschoben.
Für uns heisst das also, dass wir die archivierte Repository in /etc/apt/sources.list kopieren und die anderen Repositories auskommentieren müssen, damit wir wieder Zugriff auf die Pakete bekommen:
Nun können wir die Konfiguration des Bootloaders durchführen:
Mir ist gerade aufgefallen, dass uns der Kernel noch fehlt, also installieren wir ihn gleich auch:
Zuletzt umounten wir alles, was wir für die Konfiguration brauchten, setzen die Zerlegung der VM zurück, und schon sind wir fertig:
Um den erfolgreichen Start der VM zu demonstrieren, hier ein paar Screenshots dazu:
Zu guter Letzt müssen wir die Netzwerkeinstellungen entsprechend unserem Netzwerkplan anpassen. Dazu logge ich mich mit den von meiner Fachkraft übermittelten Login-Daten ein:
Mit «nano /etc/network/interfaces» gelangen wir zur Konfigurationsdatei für die Netzwerkeinstellungen. Die Zeilen, die wir ändern müssen, sind rot markiert:
Basierend auf dem Netzwerkplan ersetzen wir die aktuelle IP-Adresse durch «192.168.20.21», den Gateway durch «192.168.20.1» und die Netzwerkmaske durch «255.255.255.0»:
Dann übernehmen wir die Änderungen durch Drücken von Ctrl + O und Ctrl + X und schon ist die Migration vollbracht.
Da die Ausfallzeit des Servers während der Gesamtmigration aller VMs so gering wie möglich sein sollte, wäre es sinnvoll, ein Skript zu erstellen, das die zeitaufwendige Arbeit für uns um einiges leichter macht.
Die meisten Befehle während der manuellen Migration können direkt in das Skript kopiert werden, aber es gibt einige Dinge, die einen Workaround erfordern, damit sie in einem Skript funktionieren:
Die Lösungen dieser Probleme sind wie folgt:
Zeile 32: Dies ist der Befehl, mit dem Proxmox eine VM erstellt. «qm help» gibt eine Liste von Parametern an, die je nach Bedarf angepasst werden können. Basierend auf den Werten, die ich der VM während der manuellen Migration gegeben habe, habe ich die Werte im Skript in gleicher Weise angepasst.
Zeile 21/77: Um ein interaktives Programm innerhalb eines Shellskripts ohne Benutzerinteraktion auszuführen, wird ein sogenanntes Heredoc (oder Here document) verwendet. Die allgemeine Form für ein Heredoc ist «EOF (End-of-File), wobei die Shell den « Operator als Anweisung zum Lesen von Inputs interpretiert, bis sie eine Zeile mit dem angegebenen Trenner findet. (In diesem Fall EOF, das durch alles Mögliche ersetzt werden kann. Bspw. «Tomate oder «Salatsauce.)
Zeilen 59-66/85: Üblicherweise hätte ich den Befehl «echo» verwendet, um die Zeilen in den Konfigurationsdateien anzupassen, allerdings ist das Problem, dass «echo» nur entweder Text hinzufügt oder den gesamten Inhalt der Konfigurationsdatei durch den angegebenen Text ersetzt, anstatt nur die Zeilen zu ersetzen, die angepasst werden müssen. Hier kommt «sed» (stream editor) zur Rettung. Ein 45-jähriges Unix-Programm, das Text zeilenbasiert transformiert und dabei eine einfache, kompakte Programmiersprache verwendet.
Nun ist die Frage, wie starten wir das Skript überhaupt? Bevor wir dies tun können, müssen wir zuerst die Rechte zum Ausführen des Skripts zuweisen:
Zum Ausführen des Skripts geben wir diesen einfachen Befehl ein:
Um zu zeigen, dass die VM lauffähig ist und der User sich einloggen kann, hier noch einmal ein Screenshot dazu:
Vier Testfälle werden von 13:00 bis 15:30 nacheinander in jeweils 30 Minuten ausgeführt; 15 Minuten für die Durchführung des jeweiligen Tests und 15 Minuten für das Dokumentieren der Ergebnisse:
Testfall Nr. | 13:00 | 13:15 | 13:30 | 13:45 | 14:00 | 14:15 | 14:30 | 14:45 | 15:00 | 15:15 |
1 | | | | | | | | | | |
2 | | | | | | | | | | |
3 | | | | | | | | | | |
4 | | | | | | | | | | |
5 | | | | | | | | | | |
Kurzbeschreibung | Testen, ob der Server auf eine Anfrage antwortet und ob auf das Webinterface zugegriffen bzw. ob man sich einloggen kann. | |||
Hilfsmittel | Windows Test-PC, CMD, beliebiger Browser | |||
|
||||
Voraussetzungen: | ||||
Der Server ist eingeschaltet. Der Server ist über Ethernet korrekt angeschlossen. Proxmox ist auf dem Server installiert. | ||||
|
||||
Schritt | Vorgehen | Erwartetes Resultat | OK | |
1 | Überprüfen, ob der Server richtig angeschlossen ist. | Die LEDs der Ethernet-Ports blinken grün. | |
|
2 | «ping 192.168.20.20» in CMD eingeben. | Der Test-PC kann den Server anpingen. | |
|
3 | «192.168.20.20:8006» im Browser eingeben. | Das Webinterface wird angezeigt. | |
|
4 | «root» und «Password1» im Login-Fenster eingeben. | Der User «root» kann sich im Webinterface einloggen. | |
Kurzbeschreibung | Es wird getestet, ob der Zugang auf Proxmox verschlüsselt ist. (HTTPS, SSH) | |||
Hilfsmittel | Windows Test-PC, Putty, beliebiger Browser | |||
|
||||
Voraussetzungen: | ||||
Der Server ist eingeschaltet und ist über Ethernet korrekt angeschlossen. Proxmox ist auf dem Server installiert, HTTPS ist aktiviert und der Open-SSH Server ist installiert. | ||||
|
||||
Schritt | Vorgehen | Erwartetes Resultat | OK | |
1 | «192.168.20.20:8006» im Browser eingeben. | «https://...» erscheint in der URL und in der Adresszeile befindet sich das Verschlüsselungssymbol. Durch Anklicken des Symbols ist ersichtlich, dass es sich hier um ein inoffizielles Zertifikat speziell für Proxmox handelt. | |
|
2 | «192.168.20.20» in Putty eingeben. | Das Login-Fenster wird angezeigt. | |
|
3 | Mit «root» und «Password1» einloggen. | Das Terminal wird angezeigt. | |
Kurzbeschreibung | Einzelne Abschnitte des Skripts werden getestet. | |||
Hilfsmittel | Windows Test-PC, Putty, Webinterface | |||
|
||||
Voraussetzungen: | ||||
Der Server ist eingeschaltet und ist über Ethernet korrekt angeschlossen. Der Test-PC kann den Server anpingen. | ||||
|
||||
Schritt | Vorgehen | Erwartetes Resultat | OK | |
1 | Die IP-Adresse «192.168.20.20» in Putty eingeben. | Der Test-PC kann sich mit dem Server via Putty verbinden. | |
|
2 | Die Login-Daten «root» und «Password1» eingeben. | Der User kann sich mit «root» und «Password1» in den Server einloggen. | |
|
3 | «cd /home/lukas» in die Kommandozeile eingeben und mit «nano auto-migration.sh» den Skript via Texteditor aufmachen. | Das Skript wird angezeigt. | |
|
4 | Alle Befehle ausser den ersten paar bis «EOF» auskommentieren. Die Variablen so lassen wie sie sind. Mit Ctrl + O die Änderungen übernehmen und mit Ctrl + X den Texteditor verlassen. Mit «./auto-migration.sh» das Skript ausführen und mit «ls» die Inhalte des Ordners anzeigen. | Eine Image-Datei mit dem Namen «new-krokodil.syscon.ch-root.img» wird angezeigt. | |
|
5 | Das Skript wieder mit «nano auto-migration.sh» aufmachen und alle Befehle ausser «qm create …» bis «mkswap …» auskommentieren. Die Variablen stets unkommentiert lassen. Mit Ctrl + O und Ctrl + X das Skript schliessen und auf das Webinterface zugreifen. | Eine VM mit der ID «100» wird angezeigt. | |
|
6 | Das Skript nochmals aufmachen und alle Befehle ausser «dd if=/$IMGPATH/$IMGNEW …» bis «done» auskommentieren. Das Skript ausführen, mit «./auto-migration.sh» das Skript ausführen und mit «ls /dev/mapper» die Inhalte des Ordners anzeigen. | Die Partition «pve-vm–100–disk–0p1» ist sichtbar. | |
Schritt | Vorgehen | Erwartetes Resultat | OK |
7 | Alle Befehle ausser «mount /dev/mapper …» bis «echo …» im Skript auskommentieren. Das Skript ausführen und «less /mnt/etc/fstab» eingeben. | Folgende Zeilen sind in der Konfigurationsdatei ersichtlich: /dev/sdb none swap sw 0 0 #/dev/sda1 / ext3 sync … /dev/sda1 / ext3 … | |
8 | Mit der Taste q zurück zur Kommandozeile gelangen und «less /mnt/etc/inittab» eingeben. «/tty1» eintippen um den gesuchten Eintrag schneller zu finden. | «tty1» ist markiert. | |
9 | Das gleiche mit folgenden Konfigurationsdateien machen: /mnt/etc/resolv.conf /mnt/etc/apt/sources.list | In /resolv.conf ist folgende Zeile ersichtlich: nameserver 8.8.8.8 In /sources.list ist folgende Zeile ersichtlich: deb http://archive.debian.org/ … | |
10 | Zurück ins Skript gelangen und alle Befehle ausser «mount -t proc …» bis «EOF» auskommentieren. Das Skript ausführen. | Die Meldung «Installation finished. No error reported.» wird angezeigt. | |
11 | Das Skript aufmachen und alle Befehle ausser «sed ‘s/8.8.8.8/127.0.0.1/’ …» bis «sed ‘s/255.0.0.0/255.255.255.0’ …» auskommentieren. Das Skript ausführen und den Befehl «less /mnt/etc/resolv.conf» eingeben. | Folgende Zeile ist ersichtlich: nameserver 127.0.0.1 | |
12 | Mit der Taste q zurück auf die Kommandozeile gelangen und «less /mnt/etc/network/interfaces» eingeben. | Die IP-Adresse ist 192.168.20.21, der Gateway 192.168.20.1 und die Netzmaske 255.255.255.0. | |
13 | Das Skript aufmachen und alle Befehle ausser «umount $MOUNTPOINT/proc» bis «kpartx -d …» auskommentieren. Die Befehle «ls /mnt» und «ls /dev/mapper» eingeben. | Das Verzeichnis /mnt ist leer und die Partition «pve-vm–100–disk–0p1» ist nicht mehr sichtbar. | |
14 | Alle Befehle im Skript wieder unkommentieren. In das Webinterface einloggen, auf die VM und dann auf «Console» klicken. Die VM starten. | Die VM ist am Laufen und der Anmeldebildschirm wird angezeigt. | |
Kurzbeschreibung | Es wird überprüft, ob die Testumgebung richtig aufgebaut ist und ob alle Geräte die vorgesehenen Hostnames/FQDNs und IP-Adressen haben. | |||
Hilfsmittel | Windows Test-PC, CMD, Proxmox-Terminal (Bildschirm & Tastatur), Webinterface | |||
|
||||
Voraussetzungen: | ||||
Der Server ist eingeschaltet und ist über Ethernet korrekt angeschlossen. Die VM wurde via Skript oder von Hand migriert und ist auf dem Webinterface sichtbar. | ||||
|
||||
Schritt | Vorgehen | Erwartetes Resultat | OK | |
1 | Auf dem Test-PC «ipconfig» in CMD eingeben. | Der Test-PC hat die IP-Adresse 192.168.20.40. | |
|
2 | Auf das Webinterface zugreifen und die VM starten. Mit den von der Fachkraft übermittelten Login-Daten in die VM einloggen und die Befehle «ip addr show» und «hostname -f» eingebeben. | Die VM hat die IP-Adresse 192.168.20.21 und die FQDN krokodil.syscon.ch. | |
|
3 | Zum Proxmox-Terminal rübergehen und die Befehle «ip addr show» und «hostname -f» eingeben. | Der Proxmox-Server hat die IP-Adresse 192.168.20.20 und die FQDN ozelot.syscon.ch. | |
Kurzbeschreibung | Es wird getestet, ob der DNS-Dienst auf der VM funktioniert. | |||
Hilfsmittel | Windows Test-PC, Webinterface | |||
|
||||
Voraussetzungen: | ||||
Der Server ist eingeschaltet und ist über Ethernet korrekt angeschlossen. Die VM wurde via Skript oder von Hand migriert und ist auf dem Webinterface sichtbar. | ||||
|
||||
Schritt | Vorgehen | Erwartetes Resultat | OK | |
1 | Auf das Webinterface zugreifen und mit den Login-Daten der Fachkraft in die VM einloggen. Mit dem Befehl «dig @localhost www.google.ch» den DNS-Dienst testen. | Der DNS kann die IP-Adressen von Google herauslesen. | |
Abgesehen von den wenigen Malen, in denen ich zu voreilig war und Dinge im Voraus erledigt habe, die erst später fällig gewesen wären, ist alles völlig reibungslos verlaufen. Es gab nie eine Teilaufgabe, für die ich entweder zu viel oder zu wenig Zeit für die Durchführung geschätzt habe, sodass ich jeweils am Ende vom Tag mindestens eine Stunde für die Reflexion der Arbeit einplanen konnte. Die Ungeduld bei der frühzeitigen Installation des Servers nehme ich jedoch als Lektion, um bei zukünftigen Projekten nicht vorschnell zu werden und mich immer am Zeitplan zu halten.
Ich kann mit Sicherheit sagen, dass alle zu Beginn gesetzten Ziele und Meilensteine mühelos erreicht wurden. Zudem konnte ich auch persönliche Ziele wie die Steigerung meiner Effizienz verfolgen, indem ich mich stets nur auf die Aufgaben konzentrierte, die am jeweiligen Tag fällig waren. Zu diesem Zweck habe ich eine persönliche Eisenhower-Matrix verwendet, in der ich jeden Morgen vor Arbeitsbeginn notierte, was ich tagsüber genau tun muss, welche Dinge zu einem späteren Zeitpunkt eingeplant werden können und welche Dinge ich an meine Fachkraft delegieren kann.
Das Einzige, womit ich nicht zufrieden bin, ist dass ich den Zugriff auf Proxmox gemäss der Aufgabenstellung nicht verschlüsseln konnte. Ich habe alles ausprobiert, von der Verwendung von Let's Encrypt bis hin zur Erstellung von Skripts, aber da es Dutzende von Firewalls im Netzwerk gibt, durch die das Zertifikat geleitet werden muss, gab es so oder so keine Möglichkeit, dass es hätte funktionieren können.
Ansonsten bin ich sehr davon überzeugt, dass ich jedes andere Kriterium erfüllen könnte.
Da ich viele Themen der PA bereits während meines 3-monatigen Praktikums erlernt habe, lernte ich während der eigentlichen IPA kaum etwas Neues, aber konnte stattdessen auf der persönlichen Ebene vieles gewinnen. Darunter:
Was ich aus der Praxisarbeit in Bezug auf die Ausübung von Effizienz, Konzentration usw. gewinnen konnte, kann meiner Meinung nach nur weiter und weiter verbessert werden. Mit der Zeit bemerkte ich zudem immer mehr die Bedeutung der Projektmethode IPERKA, die wirklich nützlich sein kann, um genau die Dinge im Auge zu behalten, die direkt vor einem liegen. Mit anderen Worten, man verbringt die Zeit nicht damit, über die Vergangenheit nachzudenken oder sich um die Zukunft zu sorgen, sondern konzentriert sich stattdessen nur auf das Jetzt, sodass man in kürzerer Zeit mehr erreichen kann. Aber natürlich kann dies nicht nur in einem Projekt, sondern auch in allen Aktivitäten des täglichen Lebens angewendet werden.
Abgesehen von dem, was ich bereits während des Praktikums gelernt habe, konnte ich viel darüber lernen, wie man seine Fähigkeiten optimal einsetzt, um so effizient und produktiv wie möglich zu arbeiten. Dank dessen hatte ich keinerlei Probleme, die Ziele der PA zu erfüllen, den Zeitplan einzuhalten und hatte zudem genügend Reservezeit pro Tag, um auf Rechtschreibfehler zu prüfen, die Grafiken und Tabellen visuell zu gestalten und so weiter. Natürlich gab es ein paar unerwartete Probleme während der PA, aber es gab nichts, das mich aus dem Gewicht halten liess.
Zusammenfassend bin ich sehr zufrieden, wie die IPA herauskam.
An dieser Stelle möchte ich mich bei allen bedanken, die die IPA so zusammengestellt haben, dass sie mir eine gute Einführung in die wichtigsten Aspekte der Virtualisierung ermöglicht hat, was mir bisher schon immer an meinen IT-Kenntnissen gefehlt hat. Darüber hinaus, da es mir auch einen tiefen Einblick in Linux gab und ich im Grunde genommen ein gutes Erlebnis mit dem Betriebssystem hatte, fange ich langsam an zu verstehen, warum viele Linux gegenüber Windows bevorzugen.
Disk Performance mit Fio messen:
https://www.unixmen.com/how-to-measure-disk-performance-with-fio-and-ioping/, Zugriff am 01.04.2019 um 10:00 Uhr.
Fio Outputs:
https://tobert.github.io/post/2014-04-17-fio-output-explained.html, Zugriff am 01.04.2019 um 10:12 Uhr.
IPERKA:
http://c-jacob.ch/iperka/iperka.pdf, Zugriff am 01.04.2019 um 11:16 Uhr.
Ethernet Aliases in Linux einrichten:
https://www.techrepublic.com/article/set-up-ethernet-aliases-in-linux/, Zugriff am 03.04.2019 um 10:33 Uhr.
Liste von Well-Known Ports:
https://www.webopedia.com/quick_ref/portnumbers.asp, Zugriff am 03.04.2019 um 13:12 Uhr.
SSL Mailserver Ports:
https://www.fastmail.com/help/technical/ssltlsstarttls.html, Zugriff am 03.04.2018 um 15:42 Uhr.
RAID Cheat Sheet:
https://www.aja.com/pdf/support/RAID_Cheat_Sheet.pdf,Zugriff am 04.04.2019 um 11:17 Uhr.
Dokumentation Proxmox-Storage:
https://pve.proxmox.com/wiki/Storage, Zugriff am 04.04.2019 um 12:58 Uhr.
Mehr über qcow2-Storage:
https://en.wikibooks.org/wiki/QEMU/Images, Zugriff am 04.04.2019 um 14:22 Uhr
Anleitung Migration Xen-VM zu Proxmox:
https://blog.filippo.io/converting-a-partition-image-to-a-bootable-disk-image/, Zugriff am 10.04.2019 um 09:02 Uhr
Was macht EOF in einem Skript:
https://superuser.com/questions/1003760/what-does-eof-do, Zugriff am 15.04.2019 um 10:49 Uhr.
Link Aggregation Grundlagen:
https://www.thomas-krenn.com/de/wiki/Link_Aggregation_und_LACP_Grundlagen, Zugriff am 16.04.2019 um 15:03 Uhr.
Was ist ein Runlevel:
http://www.linfo.org/runlevel_def.html, Zugriff am 16.04.2019 um 15:59 Uhr.
Alias | Mit Aliases kann man in der Konfigurationsdatei etc/network/interfaces mehrere IP-Adressen einer einzigen Netzwerkkarte zuweisen; z.B. eth:0, eth:1 etc. |
Block-Storage | Ein Block, manchmal auch «physischer» Datensatz genannt, ist eine Folge von Bytes oder Bits, die normalerweise eine ganze Anzahl von Datensätzen (oder Blöcken) enthält und eine maximale Länge, eine Blockgrösse aufweist. Die so strukturierten Daten gelten als «blocked». Der Prozess des Einfügens von Daten in Blöcke wird Blocking genannt, während Deblocking der Prozess des Extrahierens von Daten aus Blöcken ist. |
Fio | Fio (Flexible IO Tester) ist ein Werkzeug zum Messen von IO-Performance. Mit Fio können Devices wie Festplatten oder SSDs auf ihre Geschwindigkeit getestet werden, indem ein vom User definierter Workload ausgeführt und Performance-Daten gesammelt werden. |
fstab | Die fstab-Datei listet alle verfügbaren Festplattenpartitionen und andere Arten von Dateisystemen auf und gibt an, wie sie während des Bootvorgangs initialisiert werden sollen. |
inittab | Diese Datei definiert drei Elemente für den init-Prozess: Das Standard-Runlevel Welche Prozesse gestartet, überwacht und neu gestartet werden sollen, wenn sie beendet werden Welche Massnahmen zu ergreifen sind, wenn das System in ein neues Runlevel eintritt. Sobald alle Einträge in /etc/inittab für das Runlevel ausgeführt wurden, ist der Bootvorgang abgeschlossen und man kann sich anmelden. |
iptables | Die Firewall von Linux. Wird auch für Port-Forwarding verwendet. |
LVM | Unter Linux ist der Logical Volume Manager (LVM) ein Gerätezuordnungsziel, das die logische Datenträgerverwaltung für den Linux-Kernel bereitstellt. |
LVM-Thin (Thin Provisioning) | LVM weist normalerweise Blöcke zu, wenn ein Volume erstellt wird. LVM-Thin Pools weist stattdessen Blöcke zu, wenn sie geschrieben werden. Dieses Verhalten wird Thin Provisioning genannt. (Siehe Kapitel 9.1.1) |
PyGrub | Xens eigene Version des Grub2-Bootloaders. |
qcow | qcow ist ein Dateiformat für Disk-Image-Dateien, das von QEMU, einem gehosteten Monitor für virtuelle Maschinen, verwendet wird. Es steht für „QEMU Copy On Write“ und verwendet eine Strategie zur Optimierung des Festplattenspeichers, die die Zuweisung von Speicherplatz verzögert, bis er tatsächlich benötigt wird. Es gibt zwei Versionen des Formats: qcow und qcow2. |
Raw Disk Image | Ein Raw Disk Image enthält eine exakte, sektorweise Kopie einer einzelnen Partition oder Festplatte. |
resolv.conf | Unter Linux wird resolv.conf verwendet, um den DNS des Systems zu konfigurieren. |
Runlevel | Ein Runlevel ist eine voreingestellte, einstellige Integer-Zahl, die den Betriebszustand eines von init verwalteten Linux- und Unix-ähnlichen Betriebssystems definiert, z.B.: 0 – System halt. 1 – Single user … 6 – Reboot etc. |
Snapshot | Ein Snapshot ist der Zustand eines Systems zu einem bestimmten Zeitpunkt. Der Begriff wurde als Analogie zur Fotografie definiert. Sie kann sich auf eine tatsächliche Kopie des Zustands eines Systems oder auf eine von bestimmten Systemen bereitgestellte Fähigkeit beziehen. |
Swap | Ähnlich wie beim Paging unter Windows wirkt eine Swap-Partition oder -Datei wie ein Überschuss im Arbeitsspeicher. Wenn der Speicher vollständig gefüllt ist, werden alle zusätzlichen Anwendungen von der Swap-Partition oder -Datei anstelle vom Speicher ausgeführt. |
vmdk | VMDK (kurz für Virtual Machine Disk) ist ein Dateiformat, das Container für virtuelle Festplattenlaufwerke beschreibt, die in virtuellen Maschinen wie VMware Workstation oder VirtualBox verwendet werden. |
Xen | Xen ist ein Typ-1-Hypervisor. Im Vergleich zu Konkurrenten wie Proxmox ist dieser nicht KVM-basiert (Kernel-based VM; eine Virtualisierungslösung, die den Linux-Kernel in einen Hypervisor verwandelt). |
ZFS | ZFS ist ein kombinierter Dateisystem- und logischer Volume-Manager, entwickelt von Sun Microsystems. ZFS ist skalierbar und bietet umfassenden Schutz vor Datenkorruption, Unterstützung hoher Speicherkapazitäten, effiziente Datenkompression, Snapshots und Copy-on-Write-Klone, kontinuierliche Integritätsprüfung, automatische Reparatur und kann sehr präzise konfiguriert werden. |