Teil 1 - Umfeld und Ablauf

1 Projektorganisation und Aufgabenstellung

1.1 Personen und Adressen

1.2 Aufgabenstellung

Aufbau einer Windows-Deployment-Umgebung

1.2.1 Ausgangslage

In der Rafisa Informatik GmbH werden zurzeit 50 Lernende der Fachrichtungen Applikationsentwicklung, ICT-Fachmann/Fachfrau, Systemtechnik und Betriebsinformatik zu InformatikerInnen EFZ ausgebildet. Neben dem regulären Ausbildungsbetrieb bietet die Rafisa auch Eignungsabklärungen, Arbeitstrainings, Vorbereitungen für eine Informatik-Ausbildung sowie Bewerbungs- und Job-Coachings an.

Im Zuge dieser Tätigkeiten müssen immer wieder frische PC-Arbeitsplätze eingerichtet werden. Einmal im Jahr - in den Sommerferien - werden alle Lernenden-PC's neu aufgesetzt. Als Basis für die Neuinstallation dient ein Standard-Image, welches mittels Clonezilla einzeln und von Hand aufgespielt wird. Um die Effizienz dieses Prozesses zu erhöhen, wurde beschlossen, eine automatisierte Deploymentlösung zu evaluieren.

1.2.2 Detaillierte Aufgabenstellung

Auf der Basis des Windows Deplyoment Services (WDS) soll eine Lösung für das Deployment der Windows-Standard-Images aufgebaut und evaluiert werden. Die Implementatierung der Lösung erfolgt nach der IPA. Die gesamte Serverlandschaft der Rafisa basiert auf der Virtualisierungslösung Proxmox VE. Für die Deployment-Server muss deshalb eine Proxmox-Umgebung aufgebaut werden. Folgende Unteraufgaben sind zu lösen:

Zur Verfügung stehende Mittel:
1x Dell-Server (PowerEdge R410), 1x Office Switch unmanaged
1x Firewall (vorkonfiguriert), 2x Arbeitsplatzrechner für den Staging-Test
1x Windows Notebook für Tests (vorkonfiguriert), 1x externe Festplatte für Image-Backups

1. Erfassung des IST-Zustandes
- Dell-Server: Bezeichnung, CPUs, Memory, Disks, Raid-Controller, Netzwerk-Interfaces
- HW der Arbeitsplatzrechner für Staging: Bezeichnung, CPUs, Memory, Disks, Netzwerk Interfaces
- Netzplan des Lernenden-Netzwerkes (Server, Switches, Drucker, keine PCs) (I1)

2. Erfassung des SOLL-Zustandes:
- Netzplan der Testumgebung
- Einbettung der Deploymentlösung im Netzplan des Lernenden-Netzwerkes (s. Aufgabe 1)
- Beschreibung der Vorgaben für das Standard-Image für das Deployment der Lernenden-PCs (Software, Partitionierung)

3. Evaluation des 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, ZFS
- Vergleichen Sie mindestens bezüglich folgender Kriterien: Performance, Thin Provisioning, Portability, Snapshots, Block-Storage, File-Storage, Stabilität, Komplexität
- KO-Kriterien sind: Snapshot, Thin Provisioning, Stable, keine Interferenzen mit HW-Raid
- die Performance-Tests können vor der IPA durchgeführt werden, sollen aber dokumentiert sein

4. Prozessbeschrieb der Deploymentlösung
- Alle Elemente der Deploymentlösung sind identifiziert und beschrieben
- Das Zusammenspiel der einzelnen Elemente ist vollständig verstanden

5. Aufbau der Proxmox-Basis
- Firewall (Adressierung vorgegeben und dokumentiert)
- Office-Switch unmanaged
- Proxmox-Server: OS: aktuelle Proxmox VE-Distribution, IP-Adresse für Verwaltung fix ; Hostname: srv-zh-pxmx-01; FQDN: srv-zh-pxmx-01.rafisa.intern; Raid-Level selbst gewählt, begründet; Partitionierung: Schema selbst gewählt, begründet; Proxmox-Storage: selbst gewählt, begründet, Netzwerk-Konfiguration für alle VMs vorbereitet (I5)
- 2 Arbeitsplatzrechner für Staging-Tests

6. Einrichten der virtuellen Server und der Deployment-Lösung
1. AD-Server (I2)
- OS: Windows Server 2016, Domain: rafisa.intern, Hostname: srv-zh-ad-01, Adressierung fix, DNS-Server: alle Server eingetragen, DHCP-Server: Gateway, DNS-Server und PXE-Server verteilt, Adresspool selbst gewählt, Konto für Deployment-User eingerichtet
2. Deployment-Server:
-Windows Server 2016, Domain: rafisa.intern, Hostname: srv-zh-ds-01, Adressierung fix, Deploymentumgebung dokumentiert (Shares, Tools)
3. Anforderungen an Deploymentlösung (I6):
- Es wird ein Windows 10 Enterprise Standard-Image erstellt (Software: gemäss Standardvorgaben Rafisa, dokumentiert, Partitionierung selbst gewählt)
- Die PCs müssen via PXE Boot aufgesetzt werden können
- Das Aufsetzen muss vollständig automatisiert ablaufen (Benutzereingaben sind begründet)
- Das Standard-Image existiert als Offline-Media für die manuelle Installation (auf Boot-Stick)
- Für das Deployment wird Multicasting genutzt
- Die 2 aufgesetzten PCs sind in der Domäne, alle Programme sind aufgesetzt

7. Backuplösung (I7)
Die VM des Deployment-Servers soll vor und nach jeder Änderung des Images auf eine externe Festplatte gespeichert werden. Dafür ist ein Automounting der externen USB
Festplatte auf dem Linux-Proxmox-Server einzurichten. Das Restore der VM soll getestet werden.

Dokumentationen
- Dokumentationen zur Erfassung des IST- sowie des SOLL-Zustandes (1/2)
- Evaluation Proxmox-Storage (3)
- Prozessbeschrieb der Deployment-Lösung (4)
- Deploymentumgebung (Shares, Tools)
- User-Anleitung für das Aufsetzen der PCs (Deployment) (6)
- Beschreibung des Standard-Images (Software, Partitionierung, Login-Users) (6)

Tests (mindestens)
- DHCP-Server funktioniert
- DNS-Server funktioniert
- PXE-Boot funktioniert
- Multicasting funktioniert
- Aufgesetzte PCs sind in der Domain, Login als admin funktioniert
- Installation per Offline-Media funktioniert
- Backup funktioniert, Restores funktionieren

Mittel und Methoden
1x Dell-Server (PowerEdge R410)
1x Office Switch unmanaged
1x Firewall (vorkonfiguriert)
2x Arbeitsplatzrechner für den Staging-Test
1x Windows Notebook für Tests (vorkonfiguriert)
1x externe Festplatte für Image-Backups
Linux, Windows, AD

Neue Lerninhalte
Proxmox Storage Formate, Proxmox Backup / Restore, MDT Konfiguration

Arbeiten in den letzten 6 Monaten
Test-IPA: Migration von Windows Servern und einem Apache Webserver
Proxmox Linux
Windows 2016 Server
Windows 10 Enterprise
Linux Debian

1.3 Mittel und Methoden

1x Dell-Server (PowerEdge R410)
1x Office Switch unmanaged
1x Firewall (vorkonfiguriert)
2x Arbeitsplatzrechner für den Staging-Test
1x Windows Notebook für Tests (vorkonfiguriert)
1x externe Festplatte für Image-Backups
Linux, Windows, AD

1.4 Durchführungsblock

1.5 Vorkenntnisse

• Windows Server 2016
• Windows 10 Enterprise
• Linux Proxmox Server

1.6 Vorarbeiten

Performance Tests Proxmox Storage zusammen mit dem Kandidat Lukas Bischoff.

2 Projektaufbauorganisation

Die Prüfungsexperten bilden zusammen mit dem Fachverantwortlichen der Ausbildung und dem Kunden den Auftraggeber. Zusammen sind sie für die Formulierung der Aufgabenstellung und Benotung der Projektarbeit zuständig.

2.1.1 Personen

Ausbildner: Egil Rüefli
Lernender: Leon Tschudi

2.1.2 Rollen

Projektleiter: Leon Tschudi
Auftraggeber, Kunde: Egil Rüefli

2.1.3 Aufgaben

Der Projektleiter ist für die komplette Realisierung und Dokumentation der IPA zuständig
Der Auftraggeber ist für die Formulierung des Auftrages zuständig.

2.1.4 Verantwortung

Die Realisierung der IPA liegt allein in der Verantwortung des Lernenden.

2.1.5 Projektorganigramm

3 Vorgehen

3.1 Projektmethode IPERKA

IPERKA ist eine Projektmethode und steht für:

Informieren: Sich über etwas eine Übersicht verschaffen. Informationen aus dem Internet suchen. Quellenangaben nicht vergessen. Bilder sollten ebenfalls mit einer Quelle verzeichnet sein. Informationen gut veranschaulichen und wenn nötig gleich erklären. Tatsachen und Umstände definieren und sich Gedanken über eine Umsetzung machen.

Planen: Mit den recherchierten Informationen ein notwendiges Konzept für ein Thema (Dienst, Teilauftrag) planen. Die Planung sollte immer einen günstigen Fall bevorzugen und falls möglich mehrere Alternativen zu einer bereits geplanten bzw. gegebenen Umsetzung bieten.

Entscheiden: Aufgrund der Planung und deren Möglichkeiten wird hier entschieden, wie die Umsetzung erfolgen sollte. Dabei ist auf eine Präferenzmatrix zu verweisen, welche es dem Betrachter erlaubt, Entscheidungen gut nachzuvollziehen. Die Umsetzung sollte einen günstigen Fall bevorzugen.

Realisieren: In diesem Schritt werden getroffene Entscheidungen umgesetzt. Bei der Realisierung sollten getroffene Entscheidungen bzw. mögliche Vorgehensweisen (Planung) beachtet werden und Umgesetztes sollte dokumentiert werden in einer gut verständlichen, korrekten Fachsprache.

Kontrollieren: Die umgesetzte Arbeit wird kontrolliert. Mögliche Konfigurationen bzw. Einstellungen, welche nicht dem günstigsten Fall entsprechen, sollten diesem angepasst werden. (Testing)

Auswerten: Hier wird schliesslich dokumentiert, was alles kontrolliert und angepasst wurde. Es wird sozusagen praktisch untermauert, dass (möglichst) alle Konfigurationen dem Idealfall entsprechen und entsprechend dokumentiert sind. Bei der Auswertung werden das Projekt bzw. der Projektverlauf als Ganzes beurteilt. Hier sind auch Rezension bzw. Verbesserungsvorschläge nennenswert.

3.2 Dokumentation

Alle sicherheitskritischen Dokumente werden auf OneDrive archiviert und meinem Berufsbildner freigegeben. Jeden Tag sollen Snapshots der Arbeit auf die externe USB Disk gesichert werden.

4 Zeitplan

5 Arbeitsprotokoll

| TAG 2 ||

| TAG 3 ||

| TAG 4 ||

| TAG 6 ||

| TAG 7 ||

| TAG 8 ||

| TAG 9 ||

| TAG 10 ||

Teil 2 - Projekt

6 Kurzfassung IPA-Bericht

Kurze Ausgangssituation

In der Rafisa Informatik GmbH werden zurzeit 50 Lernende der Fachrichtungen Applikationsentwicklung, ICT-Fachmann/Fachfrau, Systemtechnik und Betriebsinformatik zu InformatikerInnen EFZ ausgebildet. Neben dem regulären Ausbildungsbetrieb bietet die Rafisa auch Eignungsabklärungen, Arbeitstrainings, Vorbereitungen für eine Informatik-Ausbildung sowie Bewerbungs- und Job-Coachings an.

Im Zuge dieser Tätigkeiten müssen immer wieder frische PC-Arbeitsplätze eingerichtet werden. Einmal im Jahr - in den Sommerferien - werden alle Lernenden-PC's neu aufgesetzt. Als Basis für die Neuinstallation dient ein Standard-Image, welches mittels Clonezilla einzeln und von Hand aufgespielt wird. Um die Effizienz dieses Prozesses zu erhöhen, wurde beschlossen, eine automatisierte Deploymentlösung zu evaluieren.

Umsetzung

Auf der Basis des Windows Deployment Services (WDS) wurde eine Lösung für das Deployment der Windows-Standard-Images aufgebaut und evaluiert. Es wurde ein RAID nach den Vorgaben der beschriebenen Evaluierung konfiguriert. Die Virtualisierungsumgebung Proxmox wurde daraufhin nach den Vorgaben aufgesetzt. Es wurden zwei virtuelle Server erstellt. Die VM srv-zh-ad-01 wurde installiert. DHCP, DNS und AD wurden darin konfiguriert. Es wurde ein Deployment Admin erstellt, mit welchem sich Clients beim Deployment anmelden können. Die VM srv-zh-ds-01 wurde konfiguriert. Dabei wurden WDS und MDT installiert und konfiguriert. Beide Server wurden in die Domain rafisa.intern aufgenommen. Eine Backup / Restore Lösung wurde evaluiert und konfiguriert. Der PXE Boot wurde getestet. Es wurde ein Standard Image erstellt, welches erfolgreich verteilt werden konnte. Das Testing wurde daraufhin erfolgreich durchgeführt.

Ergebnis

Die Deployment Lösung konnte erfolgreich nach den Vorgaben meiner Aufgabenstellung realisiert werden. Es wurde ein umfangreiches Testkonzept erstellt. Die Bereiche AD Server, WDS Server und Backup / Restore wurden getestet. Jegliche, darin beschriebene Tests wurden durchgeführt und waren erfolgreich. Damit kann die Deployment Lösung nach Abschluss der IPA produktiv eingesetzt werden.

7 Informieren

7.1 Proxmox VE

Proxmox VE ist eine auf Debian basierende Open-Source-Virtualisierungsplattform zum Betrieb von virtuellen Maschinen mit einer Web-Oberfläche. Die Umgebung basiert auf QEMU mit der Kernel-based Virtual Machine (KVM).

Durch die Verwendung einer Web-Oberfläche wird das Erstellen und Nutzen von VMs erleichtert. Auch Backups können somit einfach getätigt werden. Weiters können Cluster von mehreren PVE-Hostsystemen gebildet werden welche gemeinsam verwaltet werden. Zwischen solchen können virtuelle Maschinen ausgetauscht werden. Dies ermöglicht den Aufbau von Hochverfügbarkeitsclustern.

Eine großartige Eigenschaft von PVE ist, dass alle möglichen Pakete des Debian-Projekts mittels dem Debian Package Manager (dpkg) und dem darauf aufbauenden Advanced Packaging Tool (apt) auf dem Proxmox Server nachinstalliert werden können. Auch die Verwaltung und Aktualisierung von Proxmox-Paketen erfolgt über eigene Repositories. Der Veröffentlichungszyklus von PVE liegt bei etwa zwei bis vier Monaten. Die Virtualisierungs-Plattform Proxmox VE wird von der Wiener Proxmox Server Solutions GmbH entwickelt und betreut.

7.2 Funktionsprinzip von WDS:

7.2.1 WDS und MDT

Die Aufgabe besteht darin, einen auf den Windows Deployment Services (WDS) basierenden Deployment-Server aufzusetzen und zu testen. WDS wird unter Windows 2008/12/16 verwendet, um Windows-Images im .wim-Format über das Netzwerk zu verteilen. Die Verteilung der Images erfolgt mit Hilfe eines Preboot Execution Environments (PXE), über das eine Miniatur-Version von Windows, das sogenannte Preinstallation Environment (PE) geladen wird.

Während WDS nur für die Verteilung von Images zuständig ist, hilft das Microsoft Deployment Toolkit (MDT) auch beim Design und dem Anlegen von Betriebssystem-Images mit Hilfe von Task Sequences und Rules (s. Glossar). MDT verfügt über keinen eigenen Deployment-Mechanismus. Ähnlich wie WDS lässt sich ein Preinstallation Environment, bei MDT Lite Touch genannt, erzeugen. Dieses kann aber durch MDT nicht über das Netzwerk verteilt werden. Deshalb besteht die optimale Lösung darin, WDS und MDT zu kombinieren.

7.2.2 Funktionsweise des Deployment Systems

Hier ist das Funktionsprinzip von WDS zu sehen. Der Client sucht sich nach drücken der F12 Taste über das Netzwerk einen DHCP Server. Letzterer gibt die IP Adresskonfiguration und die Adresse des WDS Servers an den Client weiter. Der Client bootet daraufhin die LiteTouch Umgebung, mit welcher eine einfache OS Verteilung möglich ist. In dieser LiteTouch Umgebung wird nach den auf dem WDS Server festgelegten Regeln der Client aufgesetzt. Eine automatische Anmeldung am WDS Server kann ebenfalls hinterlegt werden. Um WDS realisieren zu können, werden sowohl ein DHCP- als auch ein AD Server benötigt. Ich habe mich für MDT entschieden, da es benutzerfreundlicher ist als die manuelle Konfiguration mittels Answer Files. In dieser IPA ist es nicht von Nöten, eine ZTI (zero touch installation) zu konfigurieren, daher brauche ich mich nicht mit SCCM zu befassen. Benutzereingaben während der Lite Touch Installation müssen begründet sein. Zum Beispiel ist das manuelle vergeben eines Hostnamens eine mögliche Benutzereingabe während der PXE-basierten Installation.

7.3 Multicast vs Unicast

Multicast stellt in der Telekommunikation eine Nachrichtenübertragung von einem Punkt zu einer Gruppe dar und ist daher eine Form der Mehrpunktverbindung. Unicast stellt in der Telekommunikation die Adressierung einer Nachricht an einen einzigen Empfänger dar.

Multicast bietet beim Deployment den grossen Vorteil, dass eine Image Datei im Netzwerk nur einmal übertragen werden muss. Dabei melden sich die Clients alle bei der Multicast Session an. Clients, welche sich inmitten der Multicast Übertragung dazugesellen, müssen am Ende der Übertragung den ersten Teil der Übertragung mitgeteilt bekommen.

MDT bietet die Option an, Multicast zu aktivieren. Dadurch wird die Multicast Einstellung automatisch den Windows Bereitstellungsdiensten (WDS) hinzugefügt.

7.4 Netzplan des Lernenden-Netzwerks

Hier ist der IST Netzwerkplan der Rafisa GmbH aufgelistet. Gemäss Aufgabenstellung sind hier die Geräte in meinem Testnetzwerk ersichtlich. Auf den folgenden Seiten sind die detaillierten Spezifikationen ersichtlich. Im Plan sind die Hostnames der Geräte angegeben. Der FQDN des Lernenden Netzwerkes ist rafisa.local.

In der folgenden Tabelle sind die Server aufgelistet:

Die folgende Tabelle enthält die Netzwerkgeräte:

Untenstehend sind die Drucker aufgelistet

7.5 HW Spezifikationen der eingesetzten Rechner

7.5.1 Ermittlung der Spezifikationen

Mit dem Linux Betriebssystem grml können die HW Spezifikationen ermittelt werden. Grml ist eine seit Januar 2005 existierende, auf Debian basierende Linux-Distribution und läuft vorrangig als Live-System. Dieses Betriebssystem kann mit folgenden Befehlen das ermitteln von HW Informationen erleichtern.

dmidecode -t processor #Prozessor Infos

dmidecode -t memory #Memory Infos

hdparm -I /dev/sda #Disk

lspci #Netzwerkkarte (PCI Geräte)

7.5.2 Spezifikationen des Dell Servers

Nachfolgend sind die Spezifikationen meines Servers aufgelistet. Dieser Server bildet die Grundlage für meine Virtualisierungsplattform.

7.5.3 Spezifikationen des Arbeitsplatz Rechners

Nachfolgend liste ich die Spezifikationen des Computers auf, mit welchem ich meine Dokumente verfasse und meine Server konfiguriere.

7.5.4 Spezifikationen der Rechner für das Staging

Hier sind die Spezifikationen der beiden Arbeitsplatzrechner aufgelistet, welche ich für das Staging verwende.

8 Planen

8.1 Erstellen der Arbeitspakete / Projektziele

Hier werden meine Aufgabenstellung bzw. die dadurch geforderten Tätigkeiten in einzelne Schritte zerlegt:

8.2 Netzplan der Testumgebung

Nachfolgend ersichtlich ist der Netzwerkplan meiner Test Umgebung. Die einzelnen Details zu den Objekten sind anschliessend tabellarisch aufgelistet.

| Hostnames | IP Adresse | Funktion | Zugang | Schnittstellen |

8.3 SOLL Netzwerkplan

Dieser Netzwerkplan zeigt die Einbettung des Deployment Servers im Lernenden Netzwerk der Rafisa. Die Details zu den Geräten können unter dem Kapitel 6 eingesehen werden. Der Deployment Server läuft als virtuelle Maschiene auf srv-zh-pxmx-01. Der Proxmox Server ist per Gigabit Ethernet an die Testumgebung angebunden. Mit Hilfe von Multicasting wird der gesamte Backbone mit nur einem zu sendenden Deployment-File belastet. Alle Switches sind miteinander per Gigabit Uplinks verbunden.

8.4Vorgaben für das Standard Image

Das Standardimage der Rafisa GmbH ist bewusst sehr einfach gehalten. Es besteht nur aus einer Partition. Als Software sind nur ein Office Paket und verschiedene Webbrowser installiert. Softwaretechnische Anpassungen dieses Images werden je nach Anforderung der verschiedenen Abteilungen manuell vorgenommen.

Folgende Anwendungen müssen im Image vorhanden sein:

Als Standarduser des Referenz Image ist der Nutzer Administrator vorhanden.

Für das Einrichten des Standard Image und das anschliessende Capturing wird eine zusätzliche VM eingerichtet (pxe-test-clt). Dies wird zwar in der Aufgabenstellung nicht gefordert, erleichtert allerdings das Erstellen von Screenshots.

8.5 Backup Planung

Für das Backup müssen zunächst die Rahmenbedingungen (Datenmenge, Transferzeiten, Aufbewahrungsfrist, Sicherungsperiodizitäten und applikatorische Vorgaben) abgeklärt werden. Aus der Aufgabenstellung geht hervor, dass die VM des Deployment Servers vor und nach jeder Änderung des Images auf eine externe Festplatte gespeichert werden soll. Der ganze Vorgang wird manuell durchgeführt. Die theoretische Geschwindigkeit von USB 2.0 beträgt 480Mb/s. Unter realistischen Bedingungen erreicht man maximal 320Mb/s. Wenn wir davon ausgehen, dass die VM srv-zh-ad-01 etwa 50 GB und die VM srv-zh-ds-01 ca. 100GB gross ist, dann kommt man für das Backup auf eine Gesamtdatenmenge von ca. 150GB. Die Datenmenge wird dadurch reduziert, dass lvm-thin die virtuelle Festplatte dynamisch wachsen lässt. Bei unserer Schätzung unten gehen wir deshalb von einem Maximalvolumen aus, denken aber dass das Backup aufgrund lvm-thin weniger Zeit braucht. Mit dem Online-Download-Speed-Calculator lässt sich berechnen, dass bei einer Datenmenge von 150GB und einem Speed von 320 Mb/s ca. 1 Stunde und 7 Minuten Transferzeit anfallen werden.

Quelle. https://superuser.com/questions/317217/whats-the-maximum-typical-speed-possible-with-a-usb2-0-drive

Quelle : https://www.download-time.com/

Die Rahmenbedingungen sind folgende:

• Datenmenge: ca. 150GB (VM des WDS Servers + Images + VM des AD Servers)
• Transferzeiten: ca. 1 Stunde und 7 Minuten
• Aufbewahrungsfrist: vor und nach jeder Veränderung des Images wird ein Backup der VM durchgeführt. Die ältesten Kopien werden jeweils gelöscht.
• Sicherungsperiodizitäten: vor und nach jeder Veränderung des Images wird eine Sicherung der VM durchgeführt.
• applikatorische Vorgaben: Es soll eine automount extension für Proxmox installiert werden.

9 Entscheiden

9.1 Evaluation RAID Level

Für die Raid-Konfiguration stehen 4 HDDs à 146GB zur Verfügung (s. Kapitel 6.2). Für meine Arbeit wird der folgende Platz benötigt (Schätzung):

| Objekt | Platzbedarf [GB] |

Der Raid-Controller bietet folgende RAID-Levels an: 0, 1, 5 und 10. RAID 10 bietet schnelleres Lesen und Schreiben von Daten als RAID 5, da keine Parität verwaltet werden muss. Raid 1 (Mirroring) ist mit 4 Platten nicht sinnvoll. Die KO-Kriterien sind damit:

| KO-Kriterium (Erfüllt: Ja/Nein) | RAID 0 | RAID 1 | RAID 5 | RAID 10 |

Nach Auswertung der KO-Kriterien bleiben also RAID 5 und RAID 10 als mögliche Kandidaten. Mit dem Fachverantwortlichen wurden vorgängig folgende Kriterien mit den jeweiligen Gewichten festgelegt:

Read-Performance [0-10]: 10

Nutzbarkeit des Festplattenspeichers [0-10]: 5

Der Seite https://www.cyberciti.biz/tips/raid5-vs-raid-10-safety-performance.htmlkann entnommen werden, dass RAID 10 gegenüber RAID 5 eine etwa doppelte Read-Performance aufweist. Bei RAID 5 können 3 Platten genutzt werden (3 x 146GB = 438GB), bei RAID 10 2 Platten (2 x 146 = 292GB).

Damit kann folgende Entscheidungsmatrix erstellt werden:

Die Entscheidung fällt auf RAID 10.

9.2 Evaluation Proxmox Storage

9.2.1 Die Proxmox Storage 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, Sektor Weise 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 Pools weist stattdessen Blöcke zu, wenn sie geschrieben werden. 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.

9.2.2 Vergleich der Storage Formate und Auswahl gemäss KO-Kriterien

9.2.3Performance Test mit Fio (Storage Formate qemu und lvm-thin)

Fio bezeichnet eine Abkürzung von “Flexible IO Tester”. Fio ist ein Werkzeug zum Messen von Input-Output-Performance. Geräte wie HDDs werden damit auf ihren Speed geprüft.

Dafür wird ein vom Benutzer festgelegter Workload ausgeführt und die anfallenden Performance-Daten ermittelt.

Zu Gunsten der Performance-Messung wurde bereits vor der IPA (s. Vorarbeiten) auf einem Proxmox-System eine je 20GB grosse virtuelle Disk im QCOW2-Format bzw. als LVM-Thin-Image angelegt und mit dem nachfolgend aufgeführten Befehl getestet:

- fio –randrepeat=1 –ioengine=libaio –direct=1 –name=perftest –filename=/dev/pve/vm-100-disk-0 –iodepth=64 –size=1G –readwrite=randrw –rwmixread=75  

Hier die Erläuterung folgender Parameter:

–randrepeat= 1

#Der Zufallsgenerator erzeugt ähnliche Patterns für jegliche Requests

–ioengine=libaio

#libaio ist eine Library zum ausführen paralleler I/O-Requests

–iodepth=64

#Summe der parallelen Requests

–direct=1

#Pagecache bypass

–name=perftest

#Bezeichnung des Tests

–filename=/dev/pve/vm-100-disk-0

#Disk oder Datei, in welche geschrieben werden kann (hier ein Thin-LVM-Image

–size=1G

#Grösse des zu schreibenden und zu lesenden Datenverkehrs (Patterns)

–readwrite=randrw

#Zugriffsvariante, hier, durchmischter, random Workload

–rwmixread=75

#75% des Workloads Schreibzugriffe, 25% Lesezugriffe (vgl. den Wert io= in nachfolgenden Ergebnissen.

Hier sind die Resultate des Tests. Der Wert aggrb= zeigt, dass LVM-thin fast 4 Mal zügiger ist als QEMU. Der Wert aggrb liegt bei LVM-thin bei beinahe 12MB/s. Bei QEMU liegt dieser nur bei ca. 3MB/s:

Diese Kriterien wurden vorab mit dem Fachverantwortlichen gewichtet:

• Performance [0-10]: 8
• Portabilität [0-10]: 4
• Einfachheit [0-10]: 4

Als nächsten Punkt baue ich aus den Resultaten meine Präferenzmatrix auf.

Präferenzmatrix für die beiden Storage-Formate QEMU und LVM-thin

Die Werte für die Einschätzung und Gewichtung liegen zwischen 0 und 10.

| Kriterium | Gewichtung | QEMU | LVM-Thin | QEMU gew. | LVM-Thin gew. |

Die Wahl fällt glasklar auf LVM-Thin.

10 Realisieren

10.1 RAID Konfiguration auf dem Dell PowerEdge R610 Server

Die Konfiguration des Servers startet mit dem Einrichten des RAID. Beim Start des Servers sollte rechtzeitig CTRL + R gedrückt werden, um in die RAID Konfigurationsoberfläche zu gelangen. Mit der Taste F2 werden die Konfigurationsoptionen angezeigt.

Hier ist die RAID Konfiguration ersichtlich. Die Entscheidung fiel auf RAID 10. Die Stripe Size des RAID Controllers ist auf dem Maximalwert von 64KB gesetzt worden. Kleine Stripe Sizes eignen sich gut für viele Zugriffe auf kleine Dateien, zum Beispiel bei einem Datenbankserver. Falls grosse Dateien sequenziell gelesen werden, sollte die Stripe Size möglichst gross sein.

10.2 Installation und Konfiguration von Proxmox

10.2.1 Basisinstallation von Proxmox

Zuerst wurde das Proxmox ISO Image in der Version 5.3.5 von der Seite https://www.proxmox.com/de/downloads heruntergeladen. Dieses wurde mit einem entsprechenden Programm auf einen USB Stick kopiert. Hier ist die Erstkonfiguration des Proxmox Servers ersichtlich. Als FQDN Hostname wurde «srv-zh-pxmx-01.rafisa.intern» gewählt. Damit entspricht die Einstellung den Vorgaben meiner Aufgabenstellung. Als IP Adresse wurde «192.168.30.10» gewählt. Ich habe mich bewusst für eine IP Adresse im unteren Bereich des Subnetzes entschieden, da im oberen Bereich, also ab 192.168.30.50 DHCP laufen wird. Als Subnetzmaske wurde eine standardmässige Subnetzmaske gewählt. Als DNS Server wurde die FW angegeben. Hier könnte problemlos auch der DNS von Google (8.8.4.4) angegeben werden.

10.2.2 Partitionierung des Proxmox Servers

Ich habe bei der Installation die Standardpartitionierung von Proxmox übernommen. Durch meine früheren Erfahrungen mit Proxmox weiss ich, dass der Default-Partitionierungs-Vorschlag von Proxmox vernünftig ist. Auf der Disk sda (RAID Volume) wurde eine kleine Boot Partition sda1 mit einem MB Grösse, eine EFI Bootpartition sda2 mit 512MB Grösse und eine Linux LVM Partition sda3 mit 271.8 GB Grösse erstellt. In dieser lvm Volume Group werden die folgenden weiteren lvm Volumes eingerichtet:

D
as erste swap lvm Volume ist der SWAP des Proxmox Servers. Das zweite hier ersichtliche Volume ist das Root-System des Proxmox Servers und das 3. Volume ist das thin-volume-group für das Erstellen der Festplatten für die VMs. Unten sieht man noch die HDDs der einzelnen VMs.

10.2.3 Proxmox Netzwerkkonfiguration

Für den Proxmox wurde die Default Konfiguration mit einer Bridge gewählt. Das entsprechende Config-File findet sich unter /etc/network/interfaces:

Mit dem Eintrag bridge_ports eno1 wird das Interface eno1 mit der virtuellen Bridge verbunden. Der Eintrag bridge_stp (Spanning Tree Protocol) definiert, ob im Falle von mehreren miteinander verbundenen Bridges ein eventueller Loop verhindert werden soll. Auf diesem Proxmox Server existiert allerdings lediglich eine Bridge. Deshalb kann der Eintrag auf dem standardmässigen Wert «off» belassen werden. Somit entsteht kein zusätzlicher Overhead. Der Parameter bridge_fd legt fest, wie lange es dauert, bis das der Bridge hinzugefügte Interface aktiv wird. Da das Spanning Tree Protocol ohnehin ausgeschaltet ist, kann das Interface sofort aktiv werden. Die drei weiteren Interfaces werden in dieser IPA nicht verwendet.

Quelle: https://wiki.debian.org/BridgeNetworkConnections

10.3 Unter Proxmox eine VM erstellen

Im Bild unten ist ersichtlich, mit welchen Einstellungen die VM srv-zh-ds-01 konfiguriert wurde. Der VM wurden 2 Prozessorkerne und 2GB Arbeitsspeicher zugewiesen. Dies stellt ein guter Mittelwert dar. Als Name der VM wurde der Hostname des virtuellen Servers angegeben. Als Anschluss der virtuellen Festplatte wurde SATA gewählt. Es stehen ausserdem die Optionen SCSI und IDE zur Verfügung. Mit der Option SCSI findet Windows die virtuelle Festplatte aufgrund fehlender Treiber nicht. Die Option IDE führt zu einer etwas langsamen VM. Deshalb habe ich mich für SATA entschieden. Als Netzwerkkarte verwende ich das virtuelle Modell Intel E1000. Damit funktioniert das Deployment problemlos.

10.4 Installation und Konfiguration der VM: Server 2016-AD (DHCP, DNS)

10.4.1 Basisinstallation

Für den AD Server ist eine Festplattengrösse von 50GB vorgesehen. Dies reicht gut, da der AD Server lediglich als DHCP Server und zur Authentifizierung dient, allerdings nicht als Dateiserver.

10.4.2 Grundkonfiguration des Servers

In den Systemeinstellungen wird der Hostname des Servers festgelegt. Dabei entspricht der Wert srv-zh-ad-01 den Vorgaben meiner Aufgabenstellung.

Hier ist die Netzwerkkonfiguration des AD Servers zu sehen. Der AD Server bekommt die IP Adresse 192.168.30.15 und ist damit dem DHCP Bereich nicht im Weg. Als Subnetzmaske wird die standardmässige Subnetzmaske gewählt. Als Gateway gebe ich die FW an. Als bevorzugten DNS Server gebe ich die IP Adresse des Servers selbst an. Dazu gebe ich als alternativen DNS Server die IP Adresse des Google DNS an.

10.4.3 AD Konfiguration

Die AD Konfiguration des virtuellen Servers srv-zh-ad-01 kann im Server Manager unter «Rollen und Features» eingestellt werden. Dort wird die Option «Active Directory Domänendienste» zur Installation ausgewählt.

Der nächste Schritt ist die Konfiguration des AD. Zuerst wird der Server zu einem Domänencontroller hinaufgestuft. Dazu muss der Name der Stammdomäne nach Vorgabe meiner Aufgabenstellung angegeben werden.

Als nächster Schritt muss das DSRM Kennwort angegeben werden. Zur Vereinfachung wird immer dasselbe Passwort verwendet, in diesem Fall das allgemeine Administratorpasswort. Nach der AD Installation ist ein Neustart erforderlich. Danach kann das AD konfiguriert werden.

10.4.4 DHCP Konfiguration

Nachdem das AD eingerichtet wurde, ist der nächste zu tätigende Schritt die DHCP Installation und Konfiguration.

Dazu wird im Server Manager unter «Rollen und Features hinzufügen» der Punkt «DHCP-Server» ausgewählt.

Nachdem DHCP erfolgreich installiert wurde, kann mit der Konfiguration begonnen werden. Im Server Manager unter Tools wird dafür «DHCP» ausgewählt.

Es öffnet sich ein neues Fenster. Man klickt auf IPv4 und wählt «neuer Bereich» aus.

Danach werden Namen und eine Beschreibung des Bereichs angegeben und der Adressbereich festgelegt, in welchem DHCP tätig ist (192.168.30.50 bis 192.168.30.180).

Als nächstes werden die Leasedauer, die Adresse des Standardgateways und die des DNS Servers festgelegt. Jetzt ist DHCP einsatzbereit.

Nun wird der DHCP Server dafür vorbereitet, den PXE Boot zu ermöglichen. Dazu wird unter denn DHCP Einstellungen auf «Serveroptionen» geklickt und der Eintrag «Hostname des Startservers» ausgewählt. Schliesslich wird der Hostname des Startservers angegeben. (srv-zh-ds-01).

Als nächster Schritt vor der Konfiguration des WDS Servers wird das AD konfiguriert. Es muss ein WDS-Administrator erstellt werden, mit welchem man sich beim Deployment Server anmelden kann. Die Funktion dieser Anmeldung setzt voraus, dass der Deployment Server an der Domain angemeldet ist.

Zuerst wird im Server Manager unter «Tools» die Konfigurationsoberfläche «Active Directory Benutzer und Computer» geöffnet. Dann wird auf den Namen der Stamm-Domain geklickt und «Neu»  «Organisationseinheit» ausgewählt. Man gibt der Organisationseinheit (OU) den Namen Deployment-Users. In dieser OU wird der Nutzer WDS Administrator erstellt. (wds.root).

Um den Nutzer in der entsprechenden OU zu erstellen, wird mit der rechten Maustaste auf die OU geklickt und «Neu»  «Benutzer» ausgewählt.

Hier ist der Anmeldename des Nutzers zu sehen (wds.root@rafisa.intern)

Es ist wichtig, die Option «Kennwort läuft nie ab» zu wählen, da der Deployment User für automatisierte Prozesse verwendet wird. Es ist daher unpraktisch und kann unvorhersehbare Folgen haben, dem Deployment User ein Passwort zu geben, welches ablaufen würde.

Als nächsten Schritt fügt man den Benutzer in dessen Optionen den Administratoren hinzu, damit dieser die vollständigen Berechtigungen der Domän hat.

Schliesslich ist die Konfiguration der VM bzw. des Servers srv-zh-ad-01 abgeschlossen.

10.5 DNS Konfiguration

Hier werde ich meine DNS Konfiguration veranschaulichen. Die beiden virtuellen Server r-zh-ad-01 und r-zh-ds-01 wurden automatisch dem DNS Server hinzugefügt. Ich musste nur meinen Proxmox Server manuell hinzufügen.

10.6 Installation und Konfiguration der VM: Server 2016-WDS (MDT)

10.6.1 Basisinstallation

Der Deployment Server benötigt eine 2. Partition, um Images speichern zu können (WDS Share).

Es wurde eine 100GB grosse Harddisk erstellt und es sind 40GB davon für das Betriebssystem vorgesehen. Dir restlichen 60GB dienen der 2. Partition.

10.6.2 Grundkonfiguration des Servers

Hier ist der Hostname zu sehen, welcher dem WDS Server gegeben wurde. Dieser entspricht den Vorgaben meiner Aufgabenstellung.

Im unteren Bild ist die Netzwerkkonfiguration des WDS Servers zu sehen. Als IP Adresse habe ich 192.168.30.17 festgelegt. Diese ist bewusst im unteren Bereich des Subnetzes, um dem DHCP Server nicht in den Weg zu kommen. Als Subnetzmaske habe ich die standardmässige Maske genommen. Als Gateway gebe ich die FW an. Damit die Anmeldung an der Domain funktioniert, wurde als primärer DNS Server die Adresse von srv-zh-ad-01 genommen. Damit die Auflösung öffentlicher DNS Anfragen funktioniert, habe ich als sekundären DNS Server die IP des Google DNS Server angegeben.

Als nächster Schritt wird der Server srv-zh-ds-01 der Domain rafisa.intern hinzugefügt. Dieser Schritt ist sehr wichtig, damit sich der Deployment User an der Domain anmelden kann.

10.6.3 Download und Installation von MDT

MDT dient der einfachen Konfiguration von OS Deployments. Es umfasst zwei Komponenten. Das eigentliche Microsoft Deployment Toolkit sowie die ADK Komponenten.

Nun wird jegliche für MDT vorausgesetzte Software heruntergeladen und installiert. Die nötige Software mit den Deployment Rules wurde bereits in einem Ordner auf dem IPA Stick hinterlegt. Es muss also lediglich der Inhalt jenes Ordners auf das Laufwerk D:\ des Servers srv-zh-ds-01 kopiert werden.

Anschliessend kann mit der Installation der einzelnen Softwarekomponenten begonnen werden. Es ist von Vorteil, darauf zu achten, dass alle Softwarepakete auf dem Laufwerk D:\ installiert werden. Dies dient auch dem einfachen Überblick über den Speicherort der Deployment Files sowie der Softwarekomponenten. Als Installationspfad für Windows ADK ist «d:\Program Files (x86)\Windows Kits\10\» gewählt worden. Die PE Komponente von Windows ADK bzw. für MDT wurde am selbigen Ort installiert. Als Installationsstandort von MDT wurde die Partition D:\ angegeben.

10.6.4 WDS Konfiguration

Nun können im Server Manager unter «Rollen und Features» die Windows Bereitstellungsdienste installiert werden.

Da die für das Deployment benötigten Rollen und Softwarekomponenten vorhin installiert wurden, fährt man nun mit der Konfiguration von WDS fort. Testmässig kann man ein Windows Image bereitstellen, um zu überprüfen, ob der PXE Boot über WDS erfolgreich gestartet werden kann. Um mit der Konfiguration von WDS zu starten klickt man im Server Manager unter Tools auf den Eintrag «Windows Bereitstellungsdienste». Es öffnet sich ein neues Fenster. Man klickt mit der rechten Maustaste auf den FQDN-Hostnamen des WDS Servers und wählt «Server konfigurieren» aus. Es öffnet sich der Assistent zum Konfigurieren der Windows Bereitstellungsdienste. Da der Server srv-zh-ds-01 in einem vorherigen Schritt bereits in die AD aufgenommen worden ist, kann man hier «Eigenständiger Server» als Option wählen.

Hier wird als Remoteinstallationsordner erneut ein Pfad auf dem Laufwerk D:\ angegeben. Darin werden alle Pre-Boot Images wie Beispielsweise ein LiteTouch Boot File gespeichert.

Als nächstes wird festgelegt, dass der WDS Server jeglichen Client Computern antworten soll, da es in dieser Umgebung nicht von Nöten ist, für den PXE Boot zugelassene Computer per MAC Adresse einzuschränken.

10.6.5 MDT (Deployment Share) konfigurieren

Als nächstes kann man MDT konfigurieren. Zunächst öffnet man die Deployment Workbench. Diese dient der Konfiguration des Deployment Prozesses.

In der geöffneten Deployment Workbench Oberfläche klickt man mit der rechten Maustaste auf die Option «Deploymet Shares» und wählt «New Deployment Share» aus. Im DeploymentShare werden das LiteTouch Image gespeichert, nachdem die Konfiguration in MDT abgeschlossen wurde.

Schliesslich öffnet sich ein neuer Konfigurationsassistent. Es muss erneut ein Pfad angeben werden. Es wird wieder darauf geachtet, dass sich der angegebene Pfad auf dem Laufwerk D:\ befindet. Als nächstes muss der Freigabename des DeploymentShare angegeben werden. Es wird der Standardwert übernommen. Dann folgt die Beschreibung des Deployment Share. Auch hier wird der Einfachheit halber der Standardwert übernommen und die Konfiguration fortgesetzt.

Als nächstes zeigt der Wizzard eine Zusammenstellung einiger Optionen. Die Option «Ask if a computer backup should be performed» legt fest ob Daten des Computers, welchen man deployen möchte, zuerst noch gesichert werden sollten. Dies ist in meiner IPA nicht von Nöten, ich entferne daher das Häkchen. Ein Product Key muss hier nicht angegeben werden. Auch das Administrator Passwort wird erst später angegeben. Der Capture Prozess wird später über eine seperate Task Sequence eingeleitet. BitLocker, also Laufwerkverschlüsselung wird in meiner IPA nicht benötigt. Man entfernt somit alle Häkchen, da jene Konfigurationen später über eine Task Sequence erledigt werden. und fährt fort. Schliesslich ist der Deployment Share erstellt worden.

10.6.6 Deployment Rules / Multicast konfigurieren

Um das Deployment nun automatisieren zu können, müssen Rules angegeben werden. Diese definieren, wie die PXE Installation ablaufen soll. Zum Beispiel kann die automatische Anmeldung des Clients an der Domain konfiguriert werden. Oder es kann festgelegt werden, ob die finale Zusammenfassung nach erfolgreichem Deployment angezeigt werden soll. Um die Rules festzulegen, klickt man auf den Deployment Share und dann auf Eigenschaften.

In der Registerkarte «General» der MDT Eigenschaften aktiviert man zuerst Multicast.

Als nächstes wechselt man zur Registerkarte «Rules» und kopiert die bereits erstellten Rules aus dem Text File dorthin. Ausserdem muss für eine erfolgreiche Anmeldung des PXE Clients am Server die bootstrap.ini Datei angepasst werden. Nun wird auf «Edit Bootstrap.ini» geklickt. Danach können die definierten Einstellungen eingefügt werden.

Es müssen Rules für 2 Szenarien erstellt werden. Rules für das Deployment (Verteilen des OS Image) und Rules für das Capturing. Capturing ist das Erfassen einer Referenz Computer Umgebung für das Erstellen des Thick Images

10.6.7 Deployment Rules

Folgende Deployment Rules sind auf dem Server konfiguriert. Ich habe für jede dieser Optionen herausgesucht, was jene bedeuten.

10.6.8 Capture-Rules

Die Capture-Rules definieren wie das Image auf den Server gespeichert wird. Die Capture-Rules auf dem Server sind die folgenden:

10.6.9 Betriebssystem importieren (MDT)

Nun wird das Betriebssystem Windows 10 importiert. Hierfür sollte in der Deployment Workbench mit der rechten Maustaste auf Operating System geklickt und «Import Operating System» gewählt werden.

Als nächstes kann «Full set of source files» ausgewählt werden, da zunächst einfach ein standardmässiges Windows verteilt wird.

Nun kann der Pfad des Installationsmediums angegeben und mit dem Import der Windows Images fortgefahren werden. Als nächstes muss noch der Name des Zielverzeichnisses angegeben der Import des OS gestartet werden.

10.6.10 Task Sequence erstellen

I
n der Task Sequence werden Prozesse definiert, die während des Deployments oder des Capturings nacheinander abgearbeitet werden. Als Input Parameter dieser Prozesse dienen die vordefinierten Rules. Um das standardmässige Deployment von Windows konfigurieren zu können, muss nun eine neue Task Sequence erstellt werden. Dort sind einige Angaben erforderlich. Insgesamt werden 3 Task Sequences erstellt:

Ich habe 3 Task Sequences erstellt:

• Basic-Deployment

Nur Windows installieren

* Capture-Process

Softwareumgebung eines Clients als Image speichern

(erfordert das Anpassen der Rules)

* Reference-Image-Deployment (Deployment with Software)

Standardimage mit SW installieren

Folglich wird beispielhaft gezeigt, wie eine Task Sequence bezüglich des Basic Deployments erstellt wird. In der Microsoft Deployment Workbench von MDT kann nun mit der rechten Maustaste auf «Task Sequence» geklickt und «New Task Sequence» ausgewählt werden.

Es öffnet sich ein neues Fenster. Der Task Sequence kann eine ID, einen Namen und einen Kommentar angegeben werden. Schliesslich fährt man mit der Konfiguration der Task Sequence fort. Auf der nächsten Seite wird die standardmässige Option «Standard Client Task Sequence» gewählt.

Als nächstes kann das vorher in MDT aufgenommene Betriebssystem (Windows 10) ausgewählt werden. Danach kann ein Product Key angegeben werden. In diesem Falle wird kein Product Key angegeben und zur nächsten Seite gewechselt. Nun wird der Name des Benutzers, der Name der Organisation und die Standardhomepage für Internet Explorer angegeben. Als nächstes gibt man das standardmässige Administratorpasswort an und bestätigt dieses. Schliesslich folgt eine kurze Übersicht über die zu konfigurierenden Optionen. Es wird bestätigt. Schliesslich wurde die Task Sequence erstellt.

10.6.11 Deployment Share aktualisieren und LiteTouch Image hinzufügen

Nun ist die Erstkonfiguration des MDT Deployment Shares abgeschlossen. Als nächstes kann der Deployment Share aktualisiert werden. Dadurch wird ein LiteTouch Image erstellt, welches WDS hinzugefügt werden kann. Um den Deployment Share zu aktualisieren, wird mit der rechten Maustaste auf den Deployment Share geklickt und «Update Deployment Share» ausgewählt. Es öffnet sich ein Assistent. Die standardmässigen Optionen werden übernommen und der Prozess wird fortgesetzt.

Schliesslich wurden die benötigten Images erstellt. Im Verzeichnis D:\DeploymentShare\Boot und befindet sich nun ein 64 Bit LiteTouch Image.

In der Oberfläche Windows Bereitstellungsdienste (WDS) muss nun der Assistent zum Hinzufügen eines neuen Start-Images gestartet werden. Um den Assistenten zu starten klickt man unter WDS mit der rechten Maustaste auf Startabbilder und wählt «Startabbild hinzufügen» aus.

Schliesslich fährt man mit der Einrichtung des Start Images fort. Auf der nächsten Seite können der Abbildname sowie die Abbildbeschreibung angegeben werden. Die Standardwerte können übernommen und der Vorgang fortgesetzt werden. Schliesslich wird das Image dem Server hinzugefügt. Nun kann die erste, automatisierte PXE-Installation bereits getestet werden.

10.7 PXE Client aufsetzen (Referenz-Client-Computer)

Um mit dem Installationsvorgang über PXE zu starten, sollte zuerst eine VM unter Proxmox erstellt werden. Sie sollte über eine 50GB grosse virtuelle Harddisk verfügen. Das folgende Bild zeigt, dass der Client den WDS Server und dessen Images nach Auswahl der Option PXE-Boot erfolgreich gefunden hat. Das vorhin auf WDS hinterlegte LiteTouch Image des Deployment Toolkit kann nun gestartet werden.

10.8 Softwareinstallation auf Client und Capture Prozess

10.8.1 Software Installation

Als nächstes folgt die Software Installation auf dem Client. Danach kann mit dem Capture-Prozess begonnen werden. Es sollte sich überlegt werden, welche Software das Standardimage enthalten soll.

Folgende Anwendungen sollen auf dem Referenz Computer installiert sein:

Hier ist ersichtlich, dass die aufgelisteten Programme auf dem Client ins talliert wurden.

10.8.2 Deinstallation der Windows Apps

Nun müssen alle vorinstallierten Windows Apps per PowerShell deinstalliert werden.
Hierfür müssen folgende Befehle ausgeführt werden:

Quelle:

https://social.technet.microsoft.com/Forums/en-US/58200c26-bc8b-4563-9a97-71bca4bd009c/sysprep-fails-on-microsoftlanguageexperiencepackhu-on-windows-10-build-1803?forum=win10itprosetup

10.8.3 Capturing

Beim Capturing wird die Softwareumgebung des Referenz Computers mitsamt dem Windows 10 Betriebssystem als Image auf den Server hochgeladen, um dieses später an Clients verteilen zu können.

Um mit dem Capture Prozess des Referenz Computers fortzufahren, müssen nun einige Punkte beachtet werden:

• Der Client muss von der Domain abgemeldet werden
• Als Template für die Capture Task Sequence muss «Sysprep and Capture» gewählt werden.
• Auf dem Server müssen die Deployment Rules durch die Capture Rules ersetzt werden
• Der Capture Prozess wird über den Deployment Share auf dem laufenden Client gestartet und kann viel Zeit in Anspruch nehmen

Zunächst wird der Client aus der Domain entfernt. Dies kann in den erweiterten Systemeinstellungen erledigt werden.

Benötigte Software wurde auf dem Client installiert. Der Client ist nun nicht mehr in der Domain. Ausserdem wurden alle vorinstallierten Windows Apps entfernt. Auf dem Server wurde eine Task Sequence für den Capture Prozess erstellt. Es wurden die Deployment Rules in den Rules eingetragen. Nun kann auf dem Client in das DeploymentShare Verzeichnis des Servers gewechselt werden. Dort wird unter Scripts der Deployment Prozess gestartet.

Hier ist zu sehen, dass der Capture-Prozess nun gestartet werden kann. Die Umgebung des Clients wird als Image auf den Server hochgeladen und kann später wieder verteilt werden. Zur späteren Verteilung wird eine neue Standard Client Task Sequence erstellt und als OS das während des Capture Prozesses auf den Server hochgeladene Windows IBS Image (*.wim-File) ausgewählt.

10.9 Erstellen des Offline-Media

Um das Offline Medium (USB Stick) erstellen zu können, wird unter MDT auf «Advanced Configuration» geklickt und dann mit der rechten Maustaste auf «Selection Profiles». Danach kann «New Selection Profile» gewählt werden.

Es öffnet sich ein neues Fenster. Nun kann der Name des Profils sowie ein Kommentar angegeben werden. Schliesslich kann fortgefahren werden.

Hier sollte darauf geachtet werden, nur das benötigte OS Image zu wählen und nicht einfach alle Betriebssysteme.

Hier ist der Speicherort des Offline Media anzugeben. Ausserdem sollte das vorhin erstellte Selection Profile gewählt werden. Schliesslich sollte der New Media Wizzard abgeschlossen werden.

Als nächstes gilt es, das erstellte Media auszuwählen und die Eigenschaften des Media zu öffnen. Es müssen nun noch die Deployment Rules eingefügt werden.

Nun ist das Einrichten des Offline Media fast abgeschlossen. Als nächsten Schritt muss das Media nun erstellt werden. Dazu klickt man unter «Media» auf «Update Media Content». Durch den Befehl «Update Media Content» wird eine ISO Datei erstellt, mit welcher später ein bootbarer USB Stick erstellt werden kann. Es empfiehlt sich, die ISO auf einen physikalischen Computer zu kopieren, um auf diesem mit Rufus einen Boot Stick erstellen zu können.

10.10 Deployment

Der Deployment Prozess an sich ist beschrieben in der User Anleitung im Anhang. Im Testing Teil ist das Deployment ausführlich getestet worden.

Folgende Benutzerinteraktionen sind notwendig:

• Start des Client Computers und drücken von F12 für den Start des PXE-Boot-Vorgangs.
• Auswählen des Tastaturlayouts.
• Der PC-Hostname muss angegeben werden.

In der Rafisa gibt es Mitarbeiter unterschiedlicher Herkunft. Diese haben alle unterschiedliche Ansprüche bezüglich der Wahl des Tastaturformates. Deswegen ist es sinnvoll, dass die Einstellung des Tastaturformates manuell angegeben werden muss. Ausserdem muss der Host-Name des zu installierenden Clients manuell angegeben werden. Dieser muss entsprechend nach den Namensrichtlinien der Rafisa vergeben werden.

10.11 Proxmox Backup

10.11.1 Vorbereiten der Backupdisk

Die Backupdisk wird an einen USB2-Port angeschlossen. Mit dem Befehl dmesg wird die Disk ermittelt:

[621718.440644] sd 3:0:0:0: [sdb] Attached SCSI disk

Die angeschlossen Disk ist /dev/sdb. Zunächst werden die vorhandenen Partitionen mit fdisk gelöscht, danach eine neue Partition erstellt und schliesslich mit mkfs.ext3 /dev/sdb1 als Ext3 formatiert:

cfdisk /dev/sdb

m kfs.ext3 /dev/sdb1

Die Backup-Platte ist jetzt vorbereitet.

10.11.2 USB-Automounter für Proxmox installieren (Putty)

Als nächstes wird aus einer fremden Quelle der PVE-Automounter installiert, damit die USB Disk nach dem Anschliessen automatisch erkannt und gemountet wird. Zuerst werden die entsprechenden Pakte-Quellen (Repositories) in /etc/apt/sources.list eingetragen

echo „deb https://apt.iteas.at/iteas stretch main“ > /etc/apt/sources.list.d/iteas.list

Anschliessend wird mit apt-get update und apt-get install pve5-usb-automount das Automount-Paket installiert. Nach der Installation wechselt man in die Proxmox-GUI.

===== =====Hier ist zu sehen, dass die USB Festplatte (usb-sdb1) automatisch eingebunden wird, sobald man diese einsteckt.

10.11.3 Backup durchführen

Um das Backup durchzuführen wechselt man auf die Proxmox GUI und klickt auf die zu sichernde VM.

Danach klickt man auf «Backup» und wählt «Backup now» aus.

==== ======== ======== ======== ======== ======== ====



A ls nächstes wird unter Storage die USB Festplatte ausgewählt. Als Modus wird der standardmässige Snapshot ausgewählt. Storage beschreibt das Medium, auf welchem das Backup gesichert werden soll. Hier wird die eingebundene USB Festplatte als Medium ausgewählt. Unter Mode wählt man, wie gewährleistet wird, dass das Backup auf konsistente Daten zurückgreifen kann. Dabei kann die VM entweder mit shutdown heruntergefahren werden oder mit suspend in einen Ruhemodus versetzt werden. Andernfalls kann mit Snapshot ein Backup des aktuell ausgeführten Systems getätigt werden. Ich habe mich für die Snapshot Option entschieden, da diese den Vorteil einer Konsistenz bietet und man während des Backups weiter arbeiten kann. Bei der Kompression stehen gzip und lzo zur Verfügung. LZO ist schneller als gzip. Gzip bietet eine höhere Kompressionsrate an. LZO habe ich gewählt, da es einen guten Kompromiss zwischen Geschwindigkeit und Kompressionsrate darstellt.

10.11.4 Restore durchführen

Falls das Backup auf einen Datenträger durchgeführt wurde, kann man dieses nun wiederherstellen.

Ich gehe davon aus, dass ein Backup vorhanden ist. Nun kann einfach ein neuer Proxmox Server aufgesetzt werden. Danach kann man die Erweiterung PVE-Automounter installieren. Anschliessend kann man einfach die USB Festplatte am Proxmox Server anschliessen. Die externe Harddisk sollte dann in der Proxmox GUI ersichtlich sein. Dann wechselt man auf die USB Festplatte und wählt «Restore» aus.

11 Kontrollieren

11.1 Testziele

Im Testing werden die wichtigsten Funktionen in 3 Bereiche aufgeteilt und getestet:

1. Funktionen des AD Servers
2. Funktionen des Deployment Servers
3. Backup / Restore

11.2 Testinfrastruktur

Alle Tests werden von dem IPA Notebook durchgeführt. Es wird eine https-Verbindung auf das GUI des Virtualisierungsservers hergestellt (https://192.168.30.10:8006). Um das Testing innerhalb des Subnetzes der virtuellen Testumgebung durchführen zu können, wurde ein virtueller Windows 10 Client aufgesetzt (pxe-test-clt). Die Tests werden über das Konsolen-GUI der einzelnen VMs durchgeführt.

11.3 Testbeschreibungen

In den 3 Bereichen sollen folgende Tests durchgeführt werden.

11.3.1 Funktionen des AD Servers

11.3.2 Funktionen des Deployment Servers

11.3.3 Backup / Restore

11.4 Testprotokoll

Bei allen Tests wird folgendes Protokoll eingesetzt:

Die Beschreibung enthält eine Definition des Testzieles. Beim Vorgehen wird nachvollziehbar beschrieben, wie beim Testing vorzugehen ist. Danach werden die Testvoraussetzungen und das erwartete Resultat konkretisiert. Als Fehlerklasse ist OK / NICHT OK einzutragen. Am Schluss werden aufgetretene Fehler und Bemerkungen festgehalten.

11.5 Testing: Durchführung und Ergebnisse

| Testfall Nr. | 01 |

| Testfall Nr. | 02 |

| Testfall Nr. | 03 |

| Testfall Nr. | 04 |

| Testfall Nr. | 05 |

| Testfall Nr. | 06 |

| Testfall Nr. | 07 |

| Testfall Nr. | 08 |

| Testfall Nr. | 09 |

| Testfall Nr. | 10 |

| Testfall Nr. | 11 |

| Testfall Nr. | 12 |

12 Auswerten

Im Testing wurden drei grosse Bereiche getestet:

• AD Server
• Deployment Server
• Backup / Restore

An dieser Stelle werde ich noch einmal kurz die Resultate meiner Tests zusammenfassen:

| Test der Funktionalität des Deployment Servers |||

| Test der Funktionalität von Backup / Restore / Transferzeit |||

Alle Tests, bis auf den letzten waren erfolgreich. Damit ist die technische Realisierung meiner IPA durchaus erfolgreich verlaufen.

13 Schlusswort

Ich bin zufrieden mit dem Ergebnis meiner IPA. Ich konnte viel dazu lernen. Die Realisierung meiner Arbeit war nicht immer einfach. Am Tag 4 meiner IPA hatte ich vor, eine Konfiguration abzuändern, was dazu geführt hat, dass ich die komplette technische Realisierung wiederholen musste. Dies hat mich daran erinnert, dass es wichtig ist, immer Backups zu tätigen. Schlussendlich konnte ich die Realisierung dennoch erfolgreich abschliessen. Das nächste Mal hüte ich mich davor, versuchstechnische Änderungen an einem System vorzunehmen, ohne vorhin eine Sicherung durchgeführt zu haben.

14 Quellenverzeichnis

WDS: https://de.wikipedia.org/wiki/Windows_Deployment_Services

MDT: https://de.wikipedia.org/wiki/Microsoft_Deployment_Toolkit

WDS Aufbau: http://webcache.googleusercontent.com/search?q=cache:http://techthoughts.info/mdt-with-wds-integration-overview/

RAID 10: https://www.acronis.com/de-de/articles/whats-raid10-and-why-should-i-use-it/

Offline Media: https://www.vkernel.ro/blog/creating-an-offline-mdt-deployment-media

Quellen für PVE-Automount: https://apt.iteas.at/

Spanning Tree in einer virtuellen Bridge: https://wiki.debian.org/BridgeNetworkConnections

IPERKA: http://c-jacob.ch/iperka/iperka.pdf

Powershell Befehle: https://social.technet.microsoft.com/Forums/en-US/58200c26-bc8b-4563-9a97-71bca4bd009c/sysprep-fails-on-microsoftlanguageexperiencepackhu-on-windows-10-build-1803?forum=win10itprosetup

Linux OS grml : https://de.wikipedia.org/wiki/Grml

USB 2.0 Speed in der Realität: https://superuser.com/questions/317217/whats-the-maximum-typical-speed-possible-with-a-usb2-0-drive

Online-Download-Speed-Calculator: https://www.download-time.com/

RAID Performance Vergleich: https://www.cyberciti.biz/tips/raid5-vs-raid-10-safety-performance.html

Capture Prozess: https://theitbros.com/capture-windows-10-reference-image/

Testing: http://www.hermes.admin.ch/onlinepublikation/index.xhtml?element=ergebnis_testkonzept.html

15 Glossar

Teil 3 – Anhang

16 Weitere Materialien

16.1 Benutzeranleitung für das Aufsetzen eines Clients

Um einen Client mittels PXE (MDT) aufsetzen zu können, muss man zuerst überprüfen, ob der Client bzw. der Zielcomputer den Netzwerk Boot unterstützt. Manche tragbare Computer wie Notebooks oder Tablets (beispielsweise Surface) haben keinen integrierten LAN Anschluss mehr und unterstützen daher auch keinen PXE-Boot. Desktop PCs hingegen sollten den PXE-Boot in über 90% der Fälle unterstützen.

Beim Start eines Clients ist darauf zu achten, was nach erfolgreichem POST auf dem Bildschirm angezeigt wird. In vielen Fällen muss man lediglich F12 drücken, um den Netzwerkboot-Vorgang zu starten. Manchmal muss man den PXE-Boot über den Bootmanager auswählen. Dies ist je nach Computerhersteller unterschiedlich.

N
achdem als Boot Medium PXE ausgewählt wurde, sucht der Client mittels DHCP nach einem Startserver. Findet der Client einen Startserver, wird dessen FQDN und die IP-Adresse angezeigt. Nun muss man erneut F12 drücken, um den Start des Netzwerk-Boots zu bestätigen.

Auf der nächsten Seite kann man nun zwischen den Startabbildern wählen, welche unter WDS hinterlegt wurden. Man wählt das MDT Startabbild (Lite Touch Windows PE) und bestätigt anschliessend mit Enter.

N
un lädt der Client das Boot Image vom Netzwerk herunter und startet anschliessend die Lite Touch PE Umgebung.

Schliesslich ist die Lite Touch PE Umgebung gestartet. Man wählt als Tastaturformat de-ch aus und klickt anschliessend auf «Run the Deployment Wizard to install a new OS»

Nun kann man auswählen, welche Aufgabe ausgeführt werden soll. Ich habe verschiedene Aufgaben erstellt.

* Basic-Deployment

Nur Windows installieren

* Capture-Process

Softwareumgebung eines Clients als Image speichern

(erfordert das Anpassen der Rules)

* Reference-Image-Deployment (Deployment with Software)

Standardimage mit SW installieren

In der Regel sollte man die Aufgabe «Final Deployment-Process» auswählen. Damit wird ein Client mit dem Standardimage aufgesetzt und automatisch an die Domain angemeldet.

Schliesslich klickt man auf «weiter», sofern man mit der Auswahl zufrieden ist.

Auf der nächsten Seite muss man lediglich den Hostnamen des neuen Rechners angeben.

Die Informationen zum Beitritt in die Domain sind bereits durch MDT Rules festgelegt worden. Schliesslich klickt man auf «weiter».

Nun klickt man auf «starten» und der Deployment Prozess kann beginnen.