| **Migration eines Virtualisierungsservers der Syscon Systemberatung AG** | | {{ipa_lb2019_html_246ded58da4c54a4.png?793x1269 }} | | **IPA 2019** | | 03.04.2019 - 23.04.2019 | | Kandidat: Lukas Bischoff | \\ \\ ====== Teil 1 – Umfeld und Ablauf ====== ====== 1 Projektorganisation und Aufgabenstellung ====== ===== 1.1 Personen und Adressen ===== | **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 | ===== 1.2 Mittel und Methoden ===== 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 ===== 1.3 Durchführungsblock ===== Startblock 8, KW14: 01.04.2019 -- 05.04.2019\\ IPA-Durchführung: 01.04.2019 -- 03.05.2019\\ Einreichung bis: 01.03.2019 ===== 1.4 Aufgabenstellung ===== 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: * Xen-Server: Bezeichnung, Standort, OS, CPUs, Memory, Disks, RAID-Controller, RAID-Level, Partitionierung, Netzwerk-Interfaces, Netzwerk-Konfiguration %%(/%%etc/network/interfaces) & iptables-Konfiguration * L3-Netzwerkdiagramm des Xen-Servers sowie aller virtueller Maschinen: Internet-Anbindung, Hostnames, Subnetze, Netzwerkadressen und Subnetzmasken, Ports und Dienste auf den VMs, Verwaltungszugänge auf den VMs, Ansprechpersonen * Dokumentation der Erstellung der Image-Datei der Xen-VM krodokil.syscon.ch\\ \\ \\ - Dokumentation des SOLL-Zustandes * Proxmox-Server: Bezeichnung, OS, CPUs, Memory, Disks, RAID-Controller, RAID-Level, Partitionierung, Netzwerk-Interfaces, Netzwerk-Konfiguration * L3-Netzwerkdiagramm der Testumgebung: Internet-Anbindung, Hostnames, Subnetze, Netzwerkadressen und Subnetzmasken, Ports und Dienste auf der VM, Verwaltungszugang auf der VM\\ \\ \\ - Evaluation des geeigneten Proxmox-Storage * Für die Proxmox-VMs bieten sich verschiedene Storage-Typen an, evaluieren Sie die geeignete * Vergleichen Sie mindestens qcow2, raw, vmdk, Thin LVM, LVM * Vergleichen Sie mindestens bezüglich folgender Kriterien: Performance, Thin Provisioning, Portability, Snapshots, Block-Storage, File-Storage, Stabilität * Die Performance-Tests können vor der IPA durchgeführt werden, sollen aber dokumentiert sein - Aufbau der Testumgebung * Firewall (bereits vor IPA konfiguriert): Adressierung soll dokumentiert werden * Office Switch unmanaged * Proxmox-Server: * OS: aktuelle Proxmox VE-Distribution, IP-Adresse fix, selbst bestimmt * Hostname: ozelot * FQDN: ozelot.syscon.ch * RAID-Level selbst gewählt, begründet * Partitionierung: Schema selbst gewählt * Proxmox-Storage: selbst gewählt, begründet * Zugänge alle verschlüsselt (SSH, HTTPS) * Windows Test-PC: Um die Konfiguration zu prüfen steht ein Arbeitsplatzrechner mit Windows 10 zur Verfügung (vorgängig vorbereitet, soll dokumentiert werden) - Migration der VM von Hand * Analyse der Image-Datei der Xen-VM krokodil.syscon.ch: * Art des Images * Filesystem * Kernel * OS * Bootloader * Xen-spezifische Anpassungen\\ \\ \\ * Aufbereiten des VM-Image: * Partitionierung * MBR * Bootloader * Xen-spezifische Anpassungen rückgängig machen * Erzeugen einer Proxmox-VM mit Hilfe des aufbereiteten VM-Images\\ \\ \\ - Automatische Migration * Es soll ein Bash-Skript erstellt werden, mit welchem die unter 5. Realisierte Migration automatisiert werden kann\\ \\ \\ - Migrationsplanung für die Gesamtmigration aller VMs. Es soll ein Grobkonzept für die Gesamtmigration aller VMs ausgearbeitet werden: * Das aktuelle System wurde analysiert * Die neuen Bedürfnisse sind abgeklärt * Die zu migrierenden Daten sind vollständig erkannt * Allfällige Datenkonversionen sind abgeklärt * Der Migrationsprozess ist festgehalten * Der «Point of no Return» ist zweckdienlich definiert * Das Fallback-Szenario (oder «Plan B») ist festgelegt - Dokumentationen: * Aufbereiten des VM-Image: * Partitionierung * MBR * Bootloader * Xen-spezifische Anpassungen rückgängig machen * Erzeugen einer Proxmox-VM mit Hilfe des aufbereiteten VM-Images * Dokumentation der Erstellung der Image-Datei der Xen-VM krokodil.syscon.ch * L3-Netzwerkdiagramme IST- und SOLL-Zustand * Erfassung Xen-Server (IST) und Proxmox-Server (SOLL) * Evaluation des Proxmox-Storage * Installationsanleitung Proxmox VE * Beschreibung der manuellen Migration * Kommentierter Code des Migrationsskripts * Grobkonzept Gesamtmigration\\ \\ \\ - Tests: * Testumgebung ist aufgebaut, alle Geräte haben die vorgesehenen Hostnames und IP-Adressen * Das migrierte System funktioniert einwandfrei, DNS-Ports sind freigeschaltet * Verschlüsselung der Zugänge auf Proxmox ===== 1.5 Vorkenntnisse ===== * Einführung in Xen-Server während des 3-monatigen Praktikums * Arbeit mit Proxmox-Server ===== 1.6 Vorarbeiten ===== * Firewall ist vorkonfiguriert * Test-PC ist vor IPA bereitgestellt * Xen-VM-Image von krokodil.syscon.ch liegt auf USB-Stick vor * Performance-Tests der LVM-Storage durchgeführt zusammen mit dem Kandidaten Leon Tschudi * Word-Vorlage für die IPA erstellt * Projektmethode IPERKA zusammengefasst und als Vorlage an \\ \\ ====== 2 Vorgehen ====== ===== 2.1 Projektmethode IPERKA ===== IPERKA ist eine Projektmethode, die bei Anwendung in einem Projekt eine strukturierte Vorgehensweise bevorzugt. IPERKA steht für: **I**nformieren\\ **P**lanen\\ **E**ntscheiden\\ **R**ealisieren\\ **K**ontrollieren\\ **A**uswerten Diese Methode hat folgende Vorteile:  * Die Projektphasen sind leicht zu merken, da der Name IPERKA aus den Anfangsbuchstaben der entsprechenden Phasen besteht: Informieren, Planen, Entscheiden, Realisieren, Kontrollieren und Auswerten. * Diese Methode fördert den methodischen und strukturellen Ansatz, da die einzelnen Aktivitäten leicht den entsprechenden Projektphasen zugeordnet werden können. * Oftmals wird zu wenig geplant und zu früh realisiert. IPERKA legt grossen Wert auf die Planung. Erst wenn ein solides Konzept erarbeitet und die Entscheidung darüber getroffen ist, welche Lösungsvariante umgesetzt wird, sollte mit der Realisierung begonnen werden. * Oft wird davon ausgegangen, dass das notwendige Wissen im Projektteam bereits vorhanden ist. Die Phase «Informieren» beinhaltet beispielsweise auch, dass sich alle die notwendigen Kenntnisse über das Thema des Projekts aneignen. * Eine Auswertung des Projekts ist ebenfalls Teil des strukturierten Ansatzes. Am Ende blickt man auf das Projekt zurück, wertet die Erfahrungen aus und zieht Lehren für zukünftige Projekte ähnlicher Art. ===== 2.2 Dokumentation ===== ==== 2.2.1 Backup ==== 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. ==== 2.2.2 Versionierung ==== Für jeden Arbeitstag habe ich einen Ordner erstellt, in dem sich eine neue Version des Dokuments befindet. Hierzu die Ordnerstruktur auf OneDrive...: {{ipa_lb2019_html_c1eef4bfe5b16a5b.png?604x386}}...und dieselbe Ordnerstruktur auf meinem USB-Stick: {{ipa_lb2019_html_1e6a1f7a27ddfc29.png?604x282}}\\ \\ ====== 3 Zeitplan ====== {{ipa_lb2019_html_8fb62b62554f2039.png?604x506}}\\ \\ ====== 4 Arbeitsjournal ====== | //**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.techrepublic.com/article/set-up-ethernet-aliases-in-linux/]]__ __[[https://www.webopedia.com/quick_ref/portnumbers.asp|https://www.webopedia.com/quick_ref/portnumbers.asp]]__ __[[https://www.fastmail.com/help/technical/ssltlsstarttls.html|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://www.aja.com/pdf/support/RAID_Cheat_Sheet.pdf]]__ __[[https://pve.proxmox.com/wiki/Storage|https://pve.proxmox.com/wiki/Storage]]__ __[[https://en.wikibooks.org/wiki/QEMU/Images|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/|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|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|https://www.thomas-krenn.com/de/wiki/Link_Aggregation_und_LACP_Grundlagen]]__ __[[http://www.linfo.org/runlevel_def.html|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**// || | //**Datum**// | Mi, 17.04.2019 | | //**Arbeitszeit**// | 08:00-17:00 | | //**Ausgeführte Aufgaben**// | Testszenario erstellen Tests durchführen und dokumentieren | | //**Aufgetretene Probleme**// | Keine | | //**Reflexion**// | Gemäss den Vorgaben in der Aufgabenstellung habe ich folgende Testfälle erstellt und nach einem Zeitplan (siehe Kapitel 10.1.1) durchgeführt: Das Webinterface kann zugegriffen werden und der Login funktioniert. Die Testumgebung ist richtig aufgebaut und alle Geräte haben die richtigen Hostnames/IP-Adressen. Die migrierte VM funktioniert einwandfrei. Der DNS-Dienst der VM funktioniert. Die Ergebnisse und die benötigten Schritte für die Durchführung der jeweiligen Tests sind dokumentiert. Als Zusatz habe ich versucht, Proxmox mit einem offiziellen Zertifikat zu verschlüsseln, jedoch vergeblich. Meine Fachkraft riet mir, nicht zu viel Zeit mit etwas zu verbringen, das gemäss der Aufgabenstellung nicht notwendig ist, also folgte ich seinem Rat. \\ Das jetzige Zertifikat sieht folgendermassen aus, was nach Ansicht meiner Fachkraft durchaus reicht: {{ipa_lb2019_html_8b17363b7b245931.gif}} \\ | | //**Wissensbeschaffung**// | Keine | | //**Beanspruchte Hilfe**// | Keine | | //**Zeitplan eingehalten**// | Ja | \\ \\ | //**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 | \\ \\ ====== Teil 2 – Projekt ====== ====== 5 Kurzfassung IPA-Bericht ====== ===== 5.1 Ausgangssituation ===== 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. ===== 5.2 Umsetzung ===== Für die Migration werden folgende Schritte durchgeführt: * Erfassen und Definieren des IST- und SOLL-Zustandes * Evaluation RAID-Level und Proxmox-Storage * Aufsetzung des Proxmox-Servers * Migration der Xen-VM von Hand * Ein Bash-Skript für die automatisierte Migration erstellen * Eine Migrationsplanung für die Gesamtmigration aller VMs erstellen * Testszenario erstellen und durchführen ===== 5.3 Ergebnis ===== 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. \\ \\ ====== 6 Informieren ====== ===== 6.1 IST-Zustand ===== 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. ==== 6.1.1 L3-Netzwerkplan ==== {{ipa_lb2019_html_5bb035b5f88dc204.png?605x339}}Der Layer 2-Switch ist im Netzwerkplan nicht angegeben. ==== 6.1.2 Dokumentation Xen-Server ==== === 6.1.2.1 Systeminformationen === Die Systeminformationen habe ich durch Eingabe der folgenden Befehle abgerufen: - dmidecode system #Enthält eine Kurzbeschreibung des Systems, dessen Hardware und andere nützliche Informationen wie Seriennummern  -      - cat /proc/cpuinfo #Beschreibt die Eigenschaften des Prozessors im Detail -      - lspci #Listet alle PCI-Geräte auf   -    - fdisk -l #Listet alle Partitionstabellen auf   -      - parted -l #Listet alle Festplatten und deren Grössen in Bytes auf.   -        - mpt-status -i 2 #Ermittelt den RAID-Status   -    - xm info #Infos über Xen-Version   \\ | 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 | \\ \\ === 6.1.2.2 Konfiguration der Network-Interfaces === Inhalt von /etc/network/interfaces. Die Interfaces mit einem Doppelpunkt sind sogenannte Aliases.\\ Mit Aliases kann man mehrere IP-Adressen einer einzigen Netzwerkkarte zuweisen. - # This file describes the network interfaces available on your system   - # and how to activate them. For more information, see interfaces(5).   -    - # The loopback network interface   - auto lo   - iface lo inet loopback   -    - # The primary network interface   - #allow-hotplug eth0   - #iface eth0 inet dhcp   - auto eth0   - iface eth0 inet **static**   -         address 62.12.167.102   -         netmask 255.255.255.240   -         network 62.12.167.96   -         broadcast 62.12.167.111   -         gateway 62.12.167.97   -    - auto eth0:0   - iface eth0:0 inet **static**   -         address 62.12.167.103   -         netmask 255.255.255.240   -         network 62.12.167.96   -         broadcast 62.12.167.111   -         gateway 62.12.167.97   -    - auto eth0:1   - iface eth0:1 inet **static**   -         address 62.12.167.104   -         netmask 255.255.255.240   -         network 62.12.167.96   -         broadcast 62.12.167.111   -         gateway 62.12.167.97   -    - auto eth0:2   - iface eth0:2 inet **static**   -         address 62.12.167.101   -         netmask 255.255.255.240   -         network 62.12.167.96   -         broadcast 62.12.167.111   -         gateway 62.12.167.97   -    - auto eth0:3   - iface eth0:3 inet **static**   -         address 62.12.167.106   -         netmask 255.255.255.240   -         network 62.12.167.96   -         broadcast 62.12.167.111   -         gateway 62.12.167.97   === 6.1.2.3 Hosts-File des Xen-Servers === Mit /etc/hosts kann man Rechnernamen in IP-Adressen auflösen, wenn kein Nameserver im lokalen Netzwerk vorhanden ist. - 127.0.0.1       localhost   - 127.0.1.1       ozelot.syscon.ch        ozelot   -    - # The following lines are desirable for IPv6 capable hosts   - ::1     ip6-localhost ip6-loopback   - fe00::0 ip6-localnet   - ff00::0 ip6-mcastprefix   - ff02::1 ip6-allnodes   - ff02::2 ip6-allrouters   - 10.0.0.13       pfau.syscon.ch pfau   - 10.0.0.16       viper.syscon.ch viper   - 10.0.0.18       kolab.syscon.ch         kolab   - 10.0.0.20       krokodil.syscon.ch      krokodil   - 10.0.0.80       verkehr2.kalkbreite.net verkehr2   - 10.0.0.90       sbs.syscon.ch   - 10.0.0.91       psol.syscon.ch          psol   - 10.0.0.100      biber01.syscon.ch       biber01         biber           biber.syscon.ch   === 6.1.2.4IP-Tables des Xen-Servers === 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. - #!/bin/sh   -    - # kolab.syscon.ch (Groupware Server)   - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 25 -j DNAT --to 10.0.0.18:25 #SMTP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 80 -j DNAT --to 10.0.0.18:80 #HTTP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 110 -j DNAT --to 10.0.0.18:110 #POP3 - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 143 -j DNAT --to 10.0.0.18:143 #IMAP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 443 -j DNAT --to 10.0.0.18:443 #HTTPS - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 465 -j DNAT --to 10.0.0.18:465 #SMTPS  - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 587 -j DNAT --to 10.0.0.18:587 #MSA  - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 993 -j DNAT --to 10.0.0.18:993 #IMAPS  - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.101 --dport 995 -j DNAT --to 10.0.0.18:995 #POP3S  -    - #krokodil.syscon.ch (DNS-Server)   - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 --dport 53 -j DNAT --to 10.0.0.20:53 #DNS - iptables -A PREROUTING -t nat -p udp -d 62.12.167.104 --dport 53 -j DNAT --to 10.0.0.20:53 #DNS -    - #sbs.syscon.ch (Demo SBS)   - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 --dport 443 -j DNAT --to 10.0.0.90:443 #HTTPS - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 --dport 80 -j DNAT --to 10.0.0.90:80 #HTTP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.102 --dport 2222 -j DNAT --to 10.0.0.90:22 #SSH -    - #pfau.syscon.ch (Webserver Plone)   - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.102 --dport 22 -j DNAT --to 10.0.0.13:22 #SSH - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.102 --dport 443 -j DNAT --to 10.0.0.13:443 #HTTPS - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.102 --dport 80 -j DNAT --to 10.0.0.13:80 #HTTP -    - #ozelot.syscon.ch (Xen-Dom0)   - iptables -A INPUT -d 62.12.167.102 -p tcp --dport 223 -j ACCEPT   -    - #verkehr2.kalkbreite.net (Webserver Kalkbreite)   - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 --dport 25 --src 62.12.167.96/28 -j DNAT --to 10.0.0.80:25 #SMTP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 --dport 223 -j DNAT --to 10.0.0.80:22 #SSH - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.104 --dport 8223 -j DNAT --to 10.0.0.80:80 #HTTP -    - #biber.syscon.ch (Mailserver + Webserver)   - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 21 -j DNAT --to 10.0.0.100:21 #FTP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 25 -j DNAT --to 10.0.0.100:25 #SMTP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 80 -j DNAT --to 10.0.0.100:80 #HTTP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 110 -j DNAT --to 10.0.0.100:110 #POP3 - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 143 -j DNAT --to 10.0.0.100:143 #IMAP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 443 -j DNAT --to 10.0.0.100:443 #HTTPS - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 465 -j DNAT --to 10.0.0.100:465 #SMTPS - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 587 -j DNAT --to 10.0.0.100:587 #MSA - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 993 -j DNAT --to 10.0.0.100:993 #IMAPS - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 995 -j DNAT --to 10.0.0.100:995 #POP3S - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.103 --dport 8080 -j DNAT --to 10.0.0.100:8080 #HTTPS (Verwaltungsinterface des Mail-Servers) -    - #viper.syscon.ch (Webshop Magento)   - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.106 --dport 80 -j DNAT --to 10.0.0.16:80 #HTTP - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.106 --dport 22 -j DNAT --to 10.0.0.16:22 #SSH -    - #psol.syscon.ch (Syscon SBS fuer Kunden)   - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.106 --dport 2222 -j DNAT --to 10.0.0.91:22 #SSH - iptables -A PREROUTING -t nat -p tcp -d 62.12.167.106 --dport 443 -j DNAT --to 10.0.0.91:443 #HTTPS -    - ### Port Forwarding SNAT ###   - iptables -t nat -I POSTROUTING -s 10.0.0.100 -j SNAT --to 62.12.167.103   - iptables -t nat -I POSTROUTING -s 10.0.0.20 -j SNAT --to 62.12.167.104   - iptables -t nat -I POSTROUTING -s 10.0.0.18 -j SNAT --to 62.12.167.101   - iptables -t nat -I POSTROUTING -s 10.0.0.16 -j SNAT --to 62.12.167.106   === 6.1.2.5 Verwaltungszugang auf der VM === 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: - xm console    Jetzt müssen wir nur noch die ID unserer VM herausfinden. Dies machen wir mit dem Befehl «xm list»: - root@ozelot:/etc/xen# xm list - Name                                        ID   Mem VCPUs      State   Time(s) - Domain-0                                     0  2920     4     r----- 385241.5   - biber01.syscon.ch                           45  1024     2     -b----  27914.7   - demo.syscon.ch                              42   512     2     -b----   9646.6   - kolab.syscon.ch                             46  1024     2     -b----  11971.0   - krokodil.syscon.ch                           4   512     1     -b----   7556.2   - pfau.syscon.ch                              49  2048     2     -b----   2659.3   - psol.syscon.ch                              35  1024     1     -b----  48735.7   - verkehr2.kalkbreite.net                     47  1024     2     -b----   1959.8   - viper.syscon.ch                             36   512     2     -b---- 169966.5   Mit der erlangten ID können wir nun Zugriff auf die entsprechende VM erhalten: - xm console 4 Die Konsole kann durch Drücken von Ctrl + ] verlassen werden, oder Ctrl + 5, wenn wir Putty verwenden. Dieses Vorgehen gilt für alle VMs. === 6.1.2.6 Konfigurations-File der DomU ‘krokodil.syscon.ch’ === Wenn wir unserer VM eine andere IP-Adresse, eine andere MAC-Adresse, mehr Arbeitsspeicher usw. zuweisen wollen, können wir die Datei /etc/xen/.cfg, oder in diesem Fall /etc/xen/krokodil.syscon.ch.cfg verwenden, um eventuelle Änderungen vorzunehmen: - #   - # Configuration file for the Xen instance krokodil.syscon.ch, created   - # by Xen-tools 4.2 on Thu Mar 31 17:25:48 2011.   - #   -    - #   - #  Kernel + memory size   - #   -    -    - bootloader = %%'/%%usr/lib/Xen-default/bin/PyGrub'   -    - vcpus       = '1'   - memory      = '512'   -    - #   - #  Disk device(s).   - #   - root        = %%'/%%dev/xvda2 ro'   - disk        = [   -                   'phy:/dev/vg0/krokodil.syscon.ch-root,xvda2,w',   -                   'phy:/dev/vg0/krokodil.syscon.ch-swap,xvda1,w',   -               ]   -    -    - #   - #  Physical volumes   - #   -    -    - #   - #  Hostname   - #   - name        = 'krokodil.syscon.ch'   -    - #   - #  Networking   - #   - vif         = [ 'ip=10.0.0.20,mac=00:16:3E:1D:86:58' ]   -    - #   - #  Behaviour   - #   - on_poweroff = 'destroy'   - on_reboot   = 'restart'   - on_crash    = 'restart'   ==== 6.1.3 Erstellen des VM-Images auf dem Originalserver ==== 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: - ACTIVE            %%'/%%dev/vg0/krokodil.syscon.ch-root' [8.00 GiB] inherit   Für dieses Logical Volume erzeugen wir einen Snapshot: - lvcreate -L5G -sn snap-krokodil.syscon.ch-root /dev/vg0/krokodil.syscon.ch-root - - #-L[Grösse] = Grösse des Snapshots   - #-s = Snapshot erstellen   - #-n = Name des Snapshots   Mit dem Befehl «dd» können wir nun ein Image aus dem Snapshot erstellen: - dd **if**=/dev/vg0/snap-krokodil.syscon.ch-root of=/Xenbkp/krokodil.syscon.ch-root.img   Wie in der Aufgabenstellung vermerkt, wurde mir dieses Image auf einem USB-Stick zur Verfügung gestellt. \\ \\ ==== 6.1.4 Analyse des VM-Images ==== - Der USB-Stick mit dem Raw-Image wird an einem USB 2.0 Port mit «mount /dev/sdb1 /mnt» eingebunden. - Das Raw-Image «krokodil.syscon.ch-root.img» wird ins Verzeichnis /home/lukas kopiert und danach der Stick mit dem Befehl «umount /dev/sdb1» ausgehängt. - Der Befehl «file krokodil.syscon.ch-root.img» zeigt: | 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. - Das Raw-Image wird gemountet mit «mount /home/lukas/krokodil.syscon.ch-root.img /mnt». - Um eine VM in Proxmox starten zu können, braucht es einen MBR, eine Partitionstabelle und einen Bootloader. ==== 6.1.5 Xen-spezifische Anpassungen ==== 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: | #     #                     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: - 1:2345:respawn:/sbin/getty 38400 hvc0   - #2:23:respawn:/sbin/getty 38400 tty2   - #3:23:respawn:/sbin/getty 38400 tty3   - #4:23:respawn:/sbin/getty 38400 tty4   - #5:23:respawn:/sbin/getty 38400 tty5   - #6:23:respawn:/sbin/getty 38400 tty6   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. ==== 6.1.6 Windows Test-PC ==== 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  | \\ \\ \\ \\ ====== 7 Planen ====== ===== 7.1 SOLL-Zustand ===== ==== 7.1.1 L3-Netzwerkplan Testumgebung ==== {{ipa_lb2019_html_df048459701faa27.png?605x290}}==== 7.1.2 Dokumentation Proxmox-Server ==== === 7.1.2.1 Systeminformationen  === | 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 | \\ \\ === 7.1.2.2 Konfiguration der Network-Interfaces des Proxmox-Servers === Inhalt von /etc/network/interfaces. - auto lo   - iface lo inet loopback   -    - iface eno1 inet manual   -    - auto vmbr0   - iface vmbr0 inet **static**   -         address 192.168.20.20   -         netmask 255.255.255.0   -         gateway 192.168.20.1   -         bridge_ports eno1   -         bridge_stp off   -         bridge_fd 0   -    - iface eno2 inet manual   === 7.1.2.3 Konfiguration der Network-Interfaces von krokodil.syscon.ch === - auto lo   - iface lo inet loopback   -    - #Siehe SOLL-Netzwerkplan - auto eth0   - iface eth0 inet **static**   -  address 192.168.20.21   -  gateway 192.168.20.1   -  netmask 255.255.255.0   === 7.1.2.4 Ports und Dienste auf der VM === Ports: 20 (SSH), 53 (DNS) Dienste: DNS === 7.1.2.5 Verwaltungszugang auf der VM === Der Verwaltungszugang erfolgt über das Webinterface. Nach dem Starten der VM greift man auf das Terminal mit der Schaltfläche «Console» zu: {{ipa_lb2019_html_1709604dad584069.gif|Picture 1}}===== 7.2 Projektumfeld ===== 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. ===== 7.3 Benötigte Ressourcen (Hardware und Software) ===== Hardware: * Server * Firewall * Switch * PC Software: * Microsoft Office * Putty ===== 7.4 Meilensteine ===== 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. | \\ \\ ===== 7.5 Kontrolle Erreichung SOLL-Zustand ===== Zur Erfolgskontrolle werden folgende Schritte durchgeführt: - IST-Zustand im Zeitplan eintragen - IST-IST Vergleich: ein Vergleich der Ausgangssituation mit der aktuellen Situation ermitteln. Sind die Arbeitspakete realistisch verteilt? - SOLL-IST Vergleich: ein Vergleich der aktuellen Situation mit der gewünschten Situation ermitteln. Bin ich im Zeitplan richtig? \\ \\ ====== 8 Entscheiden ====== In diesem Kapitel werden die folgenden Schwerpunkte evaluiert, um die Anforderungen des SOLL-Zustandes zu erfüllen: * RAID-Level * Proxmox-Storage ===== 8.1 Evaluation RAID-Level für Proxmox Server ===== 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. {{ipa_lb2019_html_b52407999af11a6d.png?340x174}}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. {{ipa_lb2019_html_a428223bcb7e1f9.png?340x173}}**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. {{ipa_lb2019_html_18c4dbc8445a278c.png?416x183}}**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. {{ipa_lb2019_html_f14f2d6995223594.png?340x223}}**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|https://www.aja.com/pdf/support/RAID_Cheat_Sheet.pdf]]//__ ==== 8.1.1 KO-Kriterien ==== | \\ | 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 | \\ \\ \\ \\ \\ \\ ==== 8.1.2 Präferenzmatrix für RAID 5 und RAID 6 ==== 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. ===== 8.2 Evaluation Proxmox-Storage ===== Die folgenden Schwerpunkte werden bei jedem Speicherformat ausgewertet: * Unterstützt das Format Snapshots? * Funktioniert das Format bei einem RAID? * Unterstützt das Format Thin Provisioning? Ä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|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: - fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=random_read_write.fio --bs=4k --iodepth=64 --size=1G --readwrite=randrw --rwmixread=75 | **--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: - READ: io=785812KB, aggrb=3302KB/s, minb=3302KB/s, maxb=3302KB/s, mint=237971msec, maxt=237971msec     - WRITE: io=262764KB, aggrb=1104KB/s, minb=1104KB/s, maxb=1104KB/s, mint=237971msec, maxt=237971msec   LVM-Thin: - READ: io=785812KB, aggrb=11757KB/s, minb=11757KB/s, maxb=11757KB/s, mint=66836msec, maxt=66836msec     - WRITE: io=262764KB, aggrb=3931KB/s, minb=3931KB/s, maxb=3931KB/s, mint=66836msec, maxt=66836msec     | **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. ==== 8.2.1 Präferenzmatrix der beiden Storage-Formate QEMU und LVM-Thin ==== 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. ===== 8.3 Erstellen der Arbeitspakete ===== | 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 | \\ \\ \\ \\ ====== 9 Realisieren ====== ===== 9.1 Aufbau der Testumgebung ===== Um während der IPA in meinem eigenen Subnetz arbeiten zu können, wurden ich und meine Kollegen beauftragt, unsere Testumgebung folgendermassen anzupassen: {{ipa_lb2019_html_d14cc5e39aaeb8cb.gif|IMG_20190314_0948012.jpg}}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 | \\ \\ ==== 9.1.1 Proxmox-Server ==== 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. ===== 9.2 RAID konfigurieren auf dem Proxmox Server ===== 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)»: {{ipa_lb2019_html_a8b7397bb7a9c055.gif|02_RAID2.jpg}}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: {{ipa_lb2019_html_bc68aff86f2ab80b.gif|04_RAID2.jpg}}Nun, noch nicht ganz. Wie das System uns mitteilt, wird empfohlen, zuerst die logischen Laufwerke zu initialisieren: {{ipa_lb2019_html_80390081ed298070.gif|05_RAID2.jpg}}Diese Option finden wir unter «Advanced Settings»: {{ipa_lb2019_html_6c11b62a1f49cbfe.gif|07_RAID2.jpg}}Und wie folgt, ist unsere RAID-Konfiguration somit abgeschlossen: {{ipa_lb2019_html_128772d7f1bd2d9.gif|08_RAID2.jpg}}===== 9.3 Proxmox Grundinstallation ===== 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. {{ipa_lb2019_html_7ab8eed7e24520d4.gif|08_Installation.png}}Nach Drücken von «Install» soll es nur ein paar wenige Minuten dauern…: {{ipa_lb2019_html_96f6744356ef3b44.gif|09_Installation.png}}Et voila. Schon ist unser Server einsatzbereit: {{ipa_lb2019_html_a6ef184fa22d4262.gif|13_Installation.png}}===== 9.4 Migration der VM von Hand ===== 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/|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: - Anlegen von Partitionstabelle und MBR (Master Boot Record) - Anlegen des Bootloaders - Xen-spezifische Anpassungen rückgängig machen 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. ==== 9.4.1 Anlegen von Partitionstabelle und MBR ==== 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: - dd **if**=/dev/zero of=/home/lukas/**new**-krokodil.syscon.ch-root.img count=1 bs=1MiB   Dieses hängen wir hinter dem Original-Image mit einem Programm namens «pv» an: - apt install -y pv - - pv krokodil.syscon.ch-root.img >> **new**-krokodil.syscon.ch-root.img \\ \\ Mit «fdisk» erstellen wir nun eine Partitionstabelle…: - fdisk **new**-krokodil.syscon.ch-root.img   …und geben nacheinander folgende Parameter ein: - n #neue Partition   - p #primäre Partition   - 1 #Partitionsnummer   -    - #Die Sektorgrössen lassen wir bei den Standardwerten, die ext-Signatur wird nicht gelöscht.   -    - a #Partition bootbar machen   - w #Änderungen übernehmen   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. ==== 9.4.2 Anlegen des Bootloaders ==== 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: {{ipa_lb2019_html_9e857f9ee965e643.gif|Grafik 21}}\\ \\ Da wir den Inhalt der Proxmox-VM über das Terminal ersetzen, anstatt ein Installationsimage zu verwenden, wählen wir «Do not use any media»: {{ipa_lb2019_html_4bd29bab86c9eb1c.gif|Grafik 22}}Die Xen-VM ist ca. 8 GB gross, also runden wir die Grösse der Proxmox-VM auf 10 GB: {{ipa_lb2019_html_f218250e94649fc.gif|Grafik 5}}\\ \\ Der Xen-VM wurde bisher ein Kern zugeordnet, also weisen wir ihr auch hier einen Kern zu: {{ipa_lb2019_html_3e7dbf5e576ccfaf.gif|Form1}}Das Gleiche gilt auch für den Arbeitsspeicher: {{ipa_lb2019_html_caea6fcb76665acf.gif|Grafik 28}}\\ \\ \\ \\ Die neue VM wird an die interne Bridge vmbr0 angeschlossen. Die restlichen Netzwerkeinstellungen lassen wir so, wie sie sind: {{ipa_lb2019_html_bdf78ab0fd7a9b76.gif|Grafik 725775938}}Abschliessend bestätigen wir die Erstellung mit «Finish»: {{ipa_lb2019_html_26b991305b7d5eb8.gif|Grafik 9}}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: {{ipa_lb2019_html_64d764090d055982.gif|01_Swap.JPG}}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: - root@ozelot:/home/lukas# ls /dev/pve   - root  swap  vm-100-disk-0  vm-100-disk-1   Mit «mkswap» verwandeln wir die 2 GB grossen Disk in eine Swap-Disk: - root@ozelot:/home/lukas# mkswap /dev/pve/vm-100-disk-1   - Setting up swapspace version 1, size = 2 GiB (2147479552 bytes)   - no label, UUID=9a38f80c-a083-47be-8b30-4fe026985f0a   Nach der Erstellung der Proxmox-VM können wir jetzt dieses durch unser Image ersetzen. Dies machen wir wiederum mit dem Kopierbefehl «dd»: - dd **if**=/home/lukas/**new**-krokodil.syscon.ch-root.img of=/dev/pve/vm-100-disk-0   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»: - apt install -y kpartx   -      - kpartx -a /dev/pve/vm-100-disk-0 - #-a = Legt die Partition in /dev/mapper. Partitionen, die mit kpartx zerlegt wurden, nennt man auch «device maps» oder «device mappings» Nun mounten wir die zerlegte Partition in den Mount-Punkt /mnt...: - mount /dev/mapper/pve-vm--100--disk—0p1 /mnt \\ \\ ...und installieren abschliessend den Bootloader mit dem folgenden Befehl: - grub-install --target=i386-pc --recheck --debug --boot-directory=/mnt/boot /dev/mapper/pve-vm--100--disk--0   ==== 9.4.3 Xen-spezifische Anpassungen rückgängig machen ==== 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: * /etc/fstab * /etc/inittab * /etc/resolv.conf * /boot/grub/grub.cfg Ausgenommen von /boot/grub/grub.cfg erfolgt eine Änderung, indem wir mit «nano» die jeweiligen Werte anpassen: - nano /mnt// Für /boot/grub/grub.cfg verwenden wir den Befehl «grub-mkconfig», da es sich hier um eine komplette Neukonfiguration des Bootloaders handelt. - /etc/fstab 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: - # /etc/fstab: static file system information.   - #   - #                   - 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 Ersetzt wird «xvda1» durch «sdb» und «xvda2» durch «sda1»: - # /etc/fstab: static file system information.   - #   - #                   - proc            /proc           proc    defaults        0       0   - devpts          /dev/pts        devpts  rw,noexec,nosuid,gid=5,mode=620 0  0   - /dev/sdb none swap sw 0 0   - #/dev/xvda2 / ext3 sync,errors=remount-ro 0 1   - /dev/sda1 / ext3 errors=remount-ro 0 1 Um die Änderungen zu übernehmen, drücken wir Ctrl + O und Ctrl + X. \\ \\ \\ \\ === 9.4.3.2 /etc/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. 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: - 1:2345:respawn:/sbin/getty 38400 hvc0   - #2:23:respawn:/sbin/getty 38400 tty2   - #3:23:respawn:/sbin/getty 38400 tty3   - #4:23:respawn:/sbin/getty 38400 tty4   - #5:23:respawn:/sbin/getty 38400 tty5   - #6:23:respawn:/sbin/getty 38400 tty6   Ersetzt wird «hvc0» zu «tty1»: - 1:2345:respawn:/sbin/getty 38400 tty1  - #2:23:respawn:/sbin/getty 38400 tty2   - #3:23:respawn:/sbin/getty 38400 tty3   - #4:23:respawn:/sbin/getty 38400 tty4   - #5:23:respawn:/sbin/getty 38400 tty5   - #6:23:respawn:/sbin/getty 38400 tty6   - /etc/resolv.conf resolv.conf wird verwendet, um den DNS des Systems zu konfigurieren. - domain syscon.ch   - search syscon.ch   - nameserver 127.0.0.1   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): - domain syscon.ch   - search syscon.ch   - nameserver 8.8.8.8   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: - mount -t proc proc /mnt/proc    -    - mount -t sysfs sys /mnt/sys    -    - mount -o bind /dev /mnt/dev   Danach machen wir einen chroot in unseren Mount-Punkt, um uns die Konfiguration des Bootloaders zu ermöglichen: - chroot /mnt 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: - root@ozelot:/# apt-get update     - Ign http:%%//%%ftp.ch.debian.org wheezy Release.gpg     - Ign http:%%//%%ftp.ch.debian.org wheezy Release     - Err http:%%//%%ftp.ch.debian.org wheezy/main Sources     -   404  Not Found [IP: 129.132.53.171 80]     - Err http:%%//%%ftp.ch.debian.org wheezy/contrib Sources     -   404  Not Found [IP: 129.132.53.171 80]     - Err http:%%//%%ftp.ch.debian.org wheezy/non-free Sources     -   404  Not Found [IP: 129.132.53.171 80]     - Err http:%%//%%ftp.ch.debian.org wheezy/main amd64 Packages     -   404  Not Found [IP: 129.132.53.171 80]     - Err http:%%//%%ftp.ch.debian.org wheezy/contrib amd64 Packages     -   404  Not Found [IP: 129.132.53.171 80]     - Err http:%%//%%ftp.ch.debian.org wheezy/non-free amd64 Packages     -   404  Not Found [IP: 129.132.53.171 80]   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|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: - root@ozelot:/# nano /etc/apt/sources.list   -    -   GNU nano 2.2.6         File: /etc/apt/sources.list   -    - deb http://archive.debian.org/debian wheezy main   -    - #deb http://httpredir.debian.org/debian/ wheezy main contrib non-free   - #deb-src http://httpredir.debian.org/debian/ wheezy main contrib non-free   -    - #deb http://security.debian.org/ wheezy/updates main contrib non-free   - #deb-src http://security.debian.org/ wheezy/updates main contrib non-free   Nun können wir die Konfiguration des Bootloaders durchführen: - apt-get update    -    - apt-get -y install grub2-common    -    - grub-mkconfig -o boot/grub/grub.cfg   Mir ist gerade aufgefallen, dass uns der Kernel noch fehlt, also installieren wir ihn gleich auch: - apt-get -y install linux-image-amd64   -    - exit #Beendet chroot   Zuletzt umounten wir alles, was wir für die Konfiguration brauchten, setzen die Zerlegung der VM zurück, und schon sind wir fertig: - umount /mnt/proc      -      - umount /mnt/sys      -      - umount /mnt/dev      -      - umount /mnt      -      - kpartx -d /dev/pve/vm-100-disk-0     Um den erfolgreichen Start der VM zu demonstrieren, hier ein paar Screenshots dazu: {{ipa_lb2019_html_1b40b7cc29b33ff8.gif|03_Migration.PNG}}{{ipa_lb2019_html_61d30ea8982d6ac6.gif|04_Migration.PNG}}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: {{ipa_lb2019_html_8e94fe3ae05d56f0.gif|Form2}}Mit «nano /etc/network/interfaces» gelangen wir zur Konfigurationsdatei für die Netzwerkeinstellungen. Die Zeilen, die wir ändern müssen, sind rot markiert: {{ipa_lb2019_html_d385a24e72140330.gif|Picture 1}}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»: {{ipa_lb2019_html_a0666e7ed3c74dd3.gif|Form3}}Dann übernehmen wir die Änderungen durch Drücken von Ctrl + O und Ctrl + X und schon ist die Migration vollbracht. ===== 9.5 Automatisierte Migration ===== 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 Erstellung einer VM in Proxmox (statt auf dem Webinterface) * Die Bedienung von interaktiven Programmen (fdisk, chroot, etc.) * Das Ersetzen von bestimmtem Text in Konfigurationsdateien (anstatt mit nano) 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 <> $IMGPATH/$IMGNEW       -        - #Erstellt eine Partitionstabelle. EOF (End-of-File) gibt an, ab welcher Stelle keine Inputs im interaktiven Programm mehr gelesen werden sollen       - fdisk $IMGPATH/$IMGNEW < $MOUNTPOINT/etc/apt/sources.list     -      - #Übernimmt /proc, /sys und /dev von Proxmox       - mount -t proc proc $MOUNTPOINT/proc       - mount -t sysfs sys $MOUNTPOINT/sys       - mount -o bind /dev $MOUNTPOINT/dev       -        - #Setzt die gemountete Partition als Root-Verzeichnis, installiert darin den Kernel und konfiguriert den Bootloader       - cat < so kurz wie möglich halten * Migration in der Nacht durchführen (Aktivität auf den Servern v.a. zu Bürozeiten (GMT+1)) **Probleme:** * Nur USB1-Anschlüsse vorhanden (12Mbit/s) -> Kopie aller VMs auf Stick dauert bei 213GB 42h * Netzwerk-Konfiguration muss unter Proxmox noch angepasst werden * Skript ist nur für Migration von 1 VM, Variablen müssen für jede VM angepasst werden **Lösungsansätze:** * Kopie der Daten über das Gigabit-Netzwerk-Interface -> 30min * Auf Switch Link-Aggregation für die 4 Gigabit-Interfaces einschalten und Kopierprozesse parallel starten -> 7min * Skript mit For-Next-Bedingung auf alle VMs erweitern **Geplante Migrationsdauer:** Migration krokodil.syscon.ch (8 GB)\\ = 3min (gemäss Durchführung der Migration via Skript) Migration aller VMs (213 GB)\\ = 213 GB ÷ 8 GB = 26.625 * 3min = 79.875min ≈ **80min** \\ \\ **Schritte:** - Server vom Internet trennen - Internes Migrationsnetz aufbauen -> Port-Aggregation auf den Switches und den Servern - Alle VMs auf dem Xen-Server mit «xm shutdown» stoppen - dd-Kopien aller VMs über das Netzwerk - Xen-Server ausschalten - Migrationsskript für alle VMs ausführen - Netzwerkkonfiguration für Proxmox anpassen - Alle VMs starten - Tests durchführen - Server mit Internet verbinden -> Point of no return **Fallback-Szenario:** Bei Problemen kann die Migration vor Punkt 10 abgebrochen und der Xen-Server wieder gestartet werden. \\ \\ ====== 10 Kontrollieren ====== ===== 10.1 Testszenario ===== ==== 10.1.1 Umfeld ==== Die Tests werden alle am Arbeitsplatz durchgeführt. Es müssen also keine Ressourcen mehr beschafft werden, da ich nur meinen PC und eine SSH-Verbindung zum Proxmox-Server brauche: {{ipa_lb2019_html_ebd69201efb2c9e.png?425x233}}==== 10.1.2 Planung ==== 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// | \\ | \\ | \\ | \\ | \\ | \\ | \\ | \\ | \\ | \\ | \\ \\ | {{ipa_lb2019_html_a730261beb7b7683.gif |Form5}}\\ | Test durchführen | | \\ | \\ | | {{ipa_lb2019_html_40bee09bf8f125ca.gif |Form6}}\\ | Ergebnisse dokumentieren | \\ \\ ===== 10.2 Durchführung der Tests ===== ==== 10.2.1 Testfall Nr. 1 ==== | **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. | \\ | \\ \\ ==== 10.2.2 Testfall Nr. 2 ==== | **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. | \\ | ==== 10.2.3 Testfall Nr. 3 ==== | **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. | \\ | \\ \\ ==== 10.2.4 Testfall Nr. 4 ==== | **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. | \\ | \\ \\ ==== 10.2.5 Testfall Nr. 5 ==== | **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. | \\ | ===== 10.3 Ist der Zeitplan eingehalten? ===== 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. ===== 10.4 Ist das Ziel erreicht? ===== 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. \\ \\ ====== 11 Auswerten ====== ===== 11.1 Auswertung der Erfahrungen ===== 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: * Lernen, bei der Sache zu bleiben und die Versuchung zu vermeiden, sich von der Arbeit abzulenken. * Arbeitsschritte sinnvoll zu gestalten, so dass kein Tag unter- oder überarbeitet ist. * Die Aufgaben des Tages vor Arbeitsbeginn realistisch planen ===== 11.2 Gedanken über das Folgeprojekt ===== 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. ===== 11.3 Fazit und Reflexion ===== 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. ====== 12 Schlusswort und Danksagung ====== 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. \\ \\ ====== 13 Quellenverzeichnis ====== Disk Performance mit Fio messen:\\ __//[[https://www.unixmen.com/how-to-measure-disk-performance-with-fio-and-ioping/|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|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|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/|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|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|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|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|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|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/|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|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|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|http://www.linfo.org/runlevel_def.html]]//__, Zugriff am 16.04.2019 um 15:59 Uhr. \\ \\ ====== 14 Glossar ====== | //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. | \\ \\ \\ \\