1. Projektbeschreibung

1.1 Ausgangssituation

Ein Startup-Unternehmen möchte für ihre Arbeit ein hochverfügbares Server-Cluster haben, welches bei einem unvorhergesehenen Ausfall, die einzelnen VMs/Container auf einem anderen Server neustartet und so den Betrieb gewährleistet. Hierfür soll wenig bis kein Datenverlust entstehen. Da der Kunde in Zukunft wachsen möchte, muss eine leicht erweiterbare Infrastruktur entstehen, welche über einen dezentralen Speicher verfügt, um die Migration der Server während eines Ausfalls, zu ermöglichen.

1.2 Zielsetzung

Das Zusammenstellen von drei identischen Servern für das hochverfügbare Server-Cluster. Bei der Zusammenstellung muss vor allem die Auswahl des Speichers, Arbeitsspeichers und Netzwerkkarten berücksichtigt werden, da diese essenziell für die Hochverfügbarkeit sind. Dem Kunden werden auf dem Cluster zwei Domänencontroller und ein Fileserver erstellt, damit dieser über eine zentrale Authentifizierung und Datenspeicherung im Netzwerk verfügt.

1.3 Projektumfeld

Das Projekt wird in einer Laborumgebung in dem Betrieb der Projektbeteiligten durchgeführt. Hier wird die geplante Konfiguration realisiert und in Tests auf mögliche Problemszenarien in der Produktionsumgebung geprüft und optimiert.

1.4 Projektphasen / Zeitplanung

2. Projektplanung

2.1 Analysephase

Für die Erstellung eines Server-Clusters wird als Erstes ein Hypervisor benötigt, welcher die virtuellen Maschinen beherbergt. Die nächste Voraussetzung ist ein dezentraler Speicherort, welche für alle Nodes des Clusters verfügbar ist. Ein dezentraler Speicher soll in diesem Aufbau dafür sorgen, dass der Ausfall eines zentralen Speichers, wie ein NAS, nicht für den Ausfall aller Server sorgt. Somit muss eine Lösung gefunden werden. Die Wahl fällt hierbei auf den Hypervisor Proxmox Virtual Environment. Dieser Hypervisor hat eine solche dezentrale Speicherlösung, welche Ceph heißt, implementiert. Als nächster Schritt wird analysiert, welche Hardware für die virtuellen Maschinen und Ceph benötigt wird, um die Konfiguration der Server-Hardware abzuschließen und mit der Einrichtung zu beginnen. Um die Ermittlung der Server-Hardware durchführen zu können, müssen wir klären, wie viele Benutzer auf die Domänen-Controller und den File-Server zugreifen sollen. Der Kunde beschäftigt 17 Mitarbeiter, von denen alle auf die Server zugreifen müssen. Die zwei Domänencontroller werden auch als DNS-Server verwendet, was die Ressourcenanforderungen abändert. Da die beiden Server bei 17 Mitarbeiter nicht viele Anfragen verarbeiten müssen, werden nicht viele Hardware-Ressourcen in Anspruch genommen. Als nächstes muss bedacht werden, dass das Betriebssystems Windows Server 2025 auf den virtuellen Maschinen verwendet wird und dieses lizenziert sein muss. Jeder CPU-Kern eines Servers und jeder Benutzer, welcher auf den Server zugreift, muss lizenziert sein. Die Zusammenstellung der Lizenzen und Server werden in der Konzeptionsphase erläutert.

2.1.1 Kostenanalyse

Zur Vollständigkeit werden jedoch symbolische Materialkosten sowie die realen Lizenzkosten aufgeführt, um den wirtschaftlichen Rahmen des Projekts nachvollziehbar darzustellen. Alle Preise verstehen sich als Wortmann-Vertriebspreise (VP, Stand Oktober 2025).

2.1.1.1 Hardwarekosten:

2.1.1.2 Softwarekosten:

2.1.1.3 Dienstleistungen:

2.1.1.4 Gesamtkosten:

Damit ergeben sich Gesamtkosten von 5.535,36 € netto bzw. 6.587,02 € brutto für die Softwarelizenzen. Die Hardwarekosten werden mit 3080,00 € netto und 3.665,20 € veranschlagt. Die Dienstleisungskosten belaufen sich auf 15.480 € netto und 18.421,20 € brutto, sodass der gesamte Projektwert bei 24.095,36 € netto und 28.673,48 € brutto liegt.

2.2 Konzeptionsphase

Um die benötigte Rechenleistung zu ermitteln, werden zuerst die Hardwareanforderungen an die verwendeten Betriebssysteme betrachtet. Da es sich in dem Umfang des Projektes ausschließlich um Windows Server 2025 Standard handelt lassen sich die Hardwareanforderungen an das Betriebssystem leicht zusammenstellen. Die Betriebssysteme werden mit grafischer Oberfläche installiert und benötigen laut Microsofts offiziellen Angaben mindestens einen 64-Bit Prozessor mit einer Taktrate von 1,4GHz, eine Arbeitsspeicher-Größe von 1024 MB und eine Festplattenkapazität von 32GB. Wenn wir nun die Anforderungen an einen Domänencontroller mit einbeziehen, ändert sich die Konfiguration nicht um einen großen Wert. Jedoch sollten die zugewiesenen Ressourcen für die virtuellen Maschinen großzügiger zugewiesen werden, um eine reibungslose Nutzererfahrung zu gewährleisten und den Geschäftsablauf nicht zu verlangsamen. Den Domänen-Controllern werden je zwei CPU-Kerne, 4GB RAM und 50GB Festplattenkapazität zugewiesen. Der File-Server wird mit denselben Ressourcen ausgestattet, jedoch wird noch eine weitere Festplatte mit einer Kapazität von 100GB für Daten hinzugefügt. Diese Festplatte ist getrennt von der 50 GB Boot-Festplatte, damit die Festplatte, auf der das Betriebssystem installiert ist, nicht mit Daten beschrieben und vollständig gefüllt wird, da sonst der Server nicht mehr funktionsfähig sein wird. Der letzte Teil, der bei der Planung der Hardware berücksichtigt werden muss, sind die Anforderungen, die durch Ceph entstehen. Da es aktuell noch keine größere Infrastruktur ist, lässt sich Ceph mit 1-2 GB RAM und niedrigerer CPU-Last bedienen. Es muss jedoch beachtet werden, dass die CPUs genug Leistung übrighaben, sollte die Infrastruktur in Zukunft wachsen. Bei dem Arbeitsspeicher sollte auch beachtet werden, dass genug zur Verfügung steht oder, dass dieser erweitert werden kann, wenn er zu knapp werden sollte.

3. Projektdurchführung

3.1 Vorbereitung der Infrastruktur

Zuallererst wird bei den drei Nodes jeweils eine weitere 1TB Festplatte verbaut. Somit existieren nun auf jeder Node die Bootplatte mit einer Bootpartition und eine 1 TB Festplatte für den Ceph-Speicher. Außerdem wird ein Bootmedium in Form eines USB-Sticks mit der PVE9.0-1 Installations-ISO mit Rufus vorbereitet. Diese Version wird gewählt, da dies die aktuellste Version, zum Zeitpunkt der Projektdurchführung, ist, die mit Debian 13 auch eine moderne Basis bietet. Im Anschluss zur Vorbereitung der Nodes wird die Verkabelung gesteckt. Die Nodes werden jeweils untereinander über zwei der drei bereits verbauten Netzwerkkarten direkt verbunden, die dritte Netzwerkkarte wird mit einem Switch verbunden. Auch der Management-Ethernet-Port jeder Node wird mit demselben Switch verbunden. An dem Switch wird zusätzlich ein Router mit einem zum Öffentlichen Netz verbundenen WAN-Port angeschlossen. Der Router ermöglicht den Servern somit eine Verbindung zum Internet. Das vom Router ausgestrahlte Wifi-Netzwerk wird von den Laptops genutzt, um den Verkabelungsaufwand bei der Einrichtung zu minimieren und den Zugriff auf die Server zu ermöglichen. Bei dem Router wird der DHCP-Adressbereich von 192.168.1.100-192.168.1.199 festgelegt, der Rest des /24er Netzes soll den Statischen Adressen für Nodes, VMs und Netzwerkgeräten dienen.

3.2 Konfiguration von Proxmox

3.2.1 Grundkonfiguration der Nodes

Wie in 3.1 bereits beschrieben, wird Proxmox auf einer Festplatte, welches als sogenannter Boot-Drive verwendet wird, installiert. Hierbei wurden die von Proxmox vorgegebenen Partitionen beibehalten. Als nächstes müssen die verschiedenen Einstellungen innerhalb des Installations-Assistenten angepasst werden. Hier müssen einige Punkte beachtet werden. Die einzelnen Server, auch genannt Nodes, müssen einen eindeutigen Namen erhalten, an welchem man die Node erkennen kann. Außerdem muss die Namensgebung eine zukünftige Erweiterung des Server-Clusters mit Nodes, bzw. eindeutigen Namen, ermöglichen. Da diese Namen auch in dem Netzwerk idealerweise eindeutig sein müssen, werden die Nodes nach dem folgenden Schema benannt: PVE+Node-Nummer. PVE steht für den in dem Projekt verwendeten Hypervisor, Proxmox Virtual Environment. Daran lässt sich sofort erkennen, um was für ein System es sich handelt. Die darauffolgende Node-Nummer sorgt für eine eindeutige Identifizierung. Die drei Nodes, die im Projekt verwendet werden, erhalten somit die Namen PVE01, PVE02 und PVE03. Die führende Null soll hierbei eine übersichtlichere Darstellung in Auflistungen ermöglichen, falls es mehr als 9 Nodes in Zukunft geben sollte. Anschließend kommen kurze Einstellungen, für die Sprache und das Tastaturlayout. Hier wird bei für das Tastaturlayout “Deutsch” und für die Sprache “Englisch” ausgewählt. Die Auswahl für Englisch geschieht hierbei, um möglichst effizient mit der Dokumentation von Proxmox zu arbeiten, da diese größtenteils in Englisch vorliegt. Danach wird ein Administrator-Benutzer für die einzelnen Nodes erstellt. Zum Schluss erfolgt die Netzwerkkonfiguration für das Management-Interface der Nodes. Das Management-Interface wird verwendet, um die Server über das Webinterface oder per SSH zu verwalten. Die Grundkonfiguration ist somit abgeschlossen und die Einrichtung des Proxmox-Clusters kann beginnen.

3.2.2 Einrichtung des Proxmox-Clusters

Um ein hochverfügbares Cluster mit Proxmox Virtual Environment zu bilden, wird zwingend ein Cluster benötigt. Aber was genau ist ein Server Cluster? Ein Cluster ist ein Verbund aus Servern, welcher sich die anfallende Arbeitslast untereinander aufteilt und diese somit effizient verarbeitet. In diesem Projekt ist die Arbeitslast die zwei Domänencontroller und der Fileserver. Dessen Erstellung und Konfiguration in den folgenden Kapiteln beschrieben wird. Um das Cluster unter Proxmox Virtual Environment zu erstellen, kann man sowohl die Konsole (SSH) oder auch die Weboberfläche nutzen. Da es deutlich intuitiver ist die Weboberfläche zu verwenden, wird diese in dem Projekt zur Cluster-Bildung genutzt. Bei Proxmox werden verschiedene Faktoren für die Clusterbildung vorausgesetzt. Diese Faktoren umfassen folgende Punkte:

• Alle Nodes des Clusters müssen einander über UDP über die Ports 5405-5412 erreichen können
• Alle Nodes des Clusters müssen ein identisches Datum und eine identische Uhrzeit haben.
• Alle Nodes müssen einander auf Port 22 per TCP (SSH) erreichen können
• Es müssen drei Nodes für die Hochverfügbarkeit vorhanden sein.

Die identischen Zeiteinstellungen sind sehr kritisch in der Cluster-Konfiguration und spielen im späteren Verlauf auch eine wichtige Rolle, da sich Ceph auch stark auf eine identische Zeit verlassen muss. Eine asynchrone Zeit führt zu Zeitüberschreitungen in der Weboberfläche bis hin zum vollständigen Ausfall von Ceph. Dies würde einen vollständigen Stillstand des Systems bedeuten. Somit muss vor der Erstellung des Clusters beachtet werden, dass eine synchone Zeit besteht, alle Nodes einander unter den benötigten TCP- und UDP-Ports erreichen können und dass die einzelnen Nodes über den korrekten Hostname und die gewünschte Management-IP-Adresse verfügen. Letzteres kann nach der Erstellung des Clusters nicht abgeändert werden. Sollten die zuvor genannten UDP-Ports nicht freigegeben sein, kann das von Proxmox verwendet Corosync nicht ordnungsgemäß arbeiten. Corosync ermöglicht die Kommunikation unter den Nodes und ist wichtig, um den Ausfall einer Node feststellen zu können. Nachdem sichergestellt ist, dass alle Nodes korrekt eingestellt und erreichbar sind, kann die Cluster-Erstellung starten. Dazu meldet man sich in der Weboberfläche einer beliebigen Node, welche ein Teil des Clusters werden soll, an. Dort wählt man unter dem Punkt “Datacenter” die Option “Cluster”. Nun wird die Schaltfläche “Create Cluster” ausgewählt. Daraufhin erscheint ein Fenster, in welchem man einen Cluster-Namen festlegt. Dieser muss auch wieder eindeutig sein, um identifizieren zu können, um was für ein Cluster es sich handelt. Es ist wichtig zu beachten, dass der Name des Clusters nach der Erstellung nicht erneut abgeändert werden kann. Bei der Durchführung dieses Projektes, wurde der Cluster-Name “Projekt” verwendet. Nachdem das Cluster nun auf einer Node erstellt wurde, können die restlichen Nodes hinzugefügt werden. Dazu muss von der Node, auf welchem das Cluster erstellt wurde, unter Datacenter -> Cluster die sogenannte “Join Information” kopiert werden. Dies ist eine alphanumerische Folge, welche benötigt wird, um einem Proxmox-Cluster beizutreten. Nun meldet man sich auf der Weboberfläche der restlichen Nodes an und fügt dort unter den Cluster-Einstellungen und “Join Cluster” die “Join Information”, welche zuvor kopiert wurde ein. Anschließend wird der Beitritt in das Cluster durch ein Administrator-Konto, welches zuvor bei der Installation von Proxmox erstellt wurde, bestätigt. Das Cluster ist nun erstellt.

3.2.3 Konfiguration von Peer to Peer Verbindungen für Ceph

Um Ceph verwenden zu können, wird eine dedizierte Netzwerkverbindung benötigt. Diese haben wir zum Anfang des Projektes gebaut. Wie in 3.1 beschrieben, ist jede Node durch eine Peer-to-Peer-Verbindung mit jeder Node verbunden. Diese Netzwerkverbindungen werden ausschließlich für Ceph benutzt, damit eine Verbindung vorhanden ist, welche die volle Bandbreite für den Datenverkehr nutzen kann. Somit verlangsamt Ceph keinen anderen Netzwerkverkehr und kein anderer Netzwerkverkehr verlangsamt Ceph. Außerdem müssen keine weiteren Switches für die Verkabelung von Ceph beschafft werden. Um diese Peer-to-Peer-Verbindung richtig nutzen zu können, müssen die verwendeten Ports untereinander verstehen, dass sie in einem netzwerktechnischen Loop gesteckt wurden. Sollte dies nicht eingerichtet werden, würde Datenverkehr sich dauerhaft im Kreis drehen, bis alle Netzwerkkarten vollständig ausgelastet sind und unausweichlich zu einem vollständigen Ausfall aller Server führen. Um dies zu verhindern, wird ein SDN, ein Software Defined Network, definiert. Dies ermöglicht eine flexiblere Konfiguration für die Netzwerkadapter, welche auch in der Zukunft, ohne größeren Aufwand, erweitert werden kann. Hierzu werden pro Hosts zwei dedizierte Netzwerkkarten für das SDN verwendet. Dazu muss auf der Weboberfläche unter “Datacenter” zu der Option “SDN” navigiert werden. Hier werden nun von jedem Host die Netzwerkkarten zu dem SDN hinzugefügt und mit einer logischen IP-Adresse versehen. Eine logische IP-Adresse bedeutet in diesem Fall, dass den beiden verwendeten Netzwerkkarten pro Host, jeweils eine einzige IP-Adresse zugwiesen wird. Der Adressbereich, welcher für das SDN verwendet wird, ist 172.31.255.0/24. Die Node-Nummer bestimmt hierbei den wird des vierten Oktetts. Somit bekommt die Node 1 die IP-Adresse 172.31.255.1, die Node 2 die 172.31.255.2 und die Node 3 die 172.31.255.3 zugewiesen. Nun ist das SDN eingerichtet. Sollte eine Node ausfallen, erkennt das SDN dies und kann den Netzwerkverkehr über eine andere Node weiterleiten. Beispielsweise kann Node 1, wenn die Direktverbindung zu Node 2 ausfällt, seinen Datenverkehr über Node 3 routen, um weiterhin mit Node 2 kommunizieren zu können und das Ceph-Cluster am Laufen zu halten.

3.3 Installation von Ceph

Zur Bereitstellung des verteilten Speichersystems wird Ceph auf allen beteiligten Servern installiert. Zunächst werden die Repositories auf den einzelnen Nodes angepasst, um den Download der benötigten Installationspakete zu ermöglichen. Dabei wird sichergestellt, dass alle Systeme auf die aktuellen und stabilen Paketquellen zugreifen können. Ein wesentlicher Vorbereitungsschritt besteht darin, die Systemzeit auf allen Servern zu synchronisieren. Dies erfolgt über den Network Time Protocol (NTP)-Dienst. Eine einheitliche Zeitbasis ist zwingend erforderlich, da Ceph auf einer zeitbasierten Kommunikation zwischen den Nodes beruht. Unterschiedliche Zeitstempel könnten zu Replikationsfehlern oder Dateninkonsistenzen führen, wodurch das gesamte System funktionsunfähig werden kann. Anschließend wird das Ceph-Installationspaket heruntergeladen. Nachdem die Installation des Ceph-Paketes abgeschlossen ist, kann unter einer beliebigen Node mit der Installation gestartet werden. Nun muss festgelegt werden, was für Ceph-Monitors und Ceph-Manager existieren sollen. In diesem Projekt wurde jede Node als Monitor als auch als Manager konfiguriert. Ein Ceph-Monitor ist eine Komponente innerhalb des Ceph-Speichersystems. Seine Aufgabe ist es einen Überblick über den Zustand von Ceph zu behalten und Anfragen von Clients entgegenzunehmen. Die Monitors in dem Ceph-Clustern kümmern sich um die verschiedenen Verzeichnisse, sogenannte “Maps”. Diese Maps teilen mit, wie der Status des Ceph-Clusters ist und wo sich Daten befinden. Ein Ceph-Cluster muss über mindestens drei Nodes verfügen, um hochverfügbar zu sein. Die Ceph-Manager sind für die Verwaltung und Sammlung von Leistungsmetriken zuständig. Es ist in dieser Umgebung sinnvoll, alle Nodes als Manager zuzuweisen. Nur eine Node ist als Manager aktiv. Sollte der primäre Manager ausfallen, wird eine weitere Node aus dem Standby geholt und zum aktiven Manager aufgestuft. Nun müssen nur noch die Netzwerkinterfaces angegeben werden, welche von Ceph für das Speichernetzwerk verwendet werden sollen. Diese sind die Interfaces, welche als SDN zuvor in 3.2.3 erstellt wurden.

3.3.1 Einrichtung von Ceph Pool

Nachdem nun Ceph-Monitors und Ceph-Manager eingerichtet wurden, kann ein Speicherpool erstellt werden. Hierzu werden die zuvor eingebauten Festplatten, welche für Ceph eingeplant wurden, verwendet. Auf den Festplatten müssen OSDs initialisiert werden. OSD steht für Object Storage Daemon und ist ein Prozess, welcher für das Lesen und Schreiben von Daten, dem Überprüfen der Datenintegrität und für die Datenreplikation verantwortlich ist. Er stellt sicher, dass die Daten stets verfügbar und in ausreichender Menge repliziert werden. Nachdem die OSDs initialisiert wurden, kann ein Speicherpool erstellt werden. Dazu wird unter einer beliebigen Node bei den Ceph-Einstellungen unter “Pool” dieser eingerichtet. Die Einstellungen werden hierbei auf den Standardoptionen gelassen. Somit wurde ein Block-Speicherpool erstellt, welcher auf allen Nodes verfügbar ist. Es wird ein Block-Speicher verwendet, da in dem Pool vorerst nur VM-Disks gespeichert werden. Dies wird vor allem aus Performance-Gründen verwendet. Ein File-Storage würde viel Leistung verbrauchen, ohne einen Mehrwert für VM-Disks zu bieten. Nun wird mit der Einrichtung der virtuellen Maschinen fortgefahren.

3.4 Einrichtung von Virtuellen Maschinen

3.4.1 Download von Iso-Dateien

Zur Vorbereitung der Installation werden die erforderlichen Installationsdateien für das Betriebssystem heruntergeladen. Dabei handelt es sich um die ISO-Datei von Windows Server 2025 sowie das Treiberpaket „VirtIO“, das für die Integration virtueller Hardwarekomponenten benötigt wird. Die Windows-Server-ISO dient als Grundlage für die Installation des Betriebssystems auf den virtuellen Maschinen. Das VirtIO-Treiberpaket stellt sicher, dass das Betriebssystem während und nach der Installation Zugriff auf die virtuellen Laufwerke und Netzwerkadapter erhält. Durch die Einbindung dieser Treiber wird eine optimale Performance und Kompatibilität der virtuellen Maschinen innerhalb der Virtualisierungsumgebung gewährleistet.

3.4.2 Zuordnung der Ressourcen zu VMs

Für die im Projekt eingesetzten virtuellen Maschinen werden die benötigten Hardware-Ressourcen festgelegt, um eine stabile und performante Systemumgebung zu gewährleisten. Die Ressourcenverteilung erfolgt in Abhängigkeit von der jeweiligen Funktion der Server. Der Domänencontroller DC01 erhält 4 GiB Arbeitsspeicher, 2 CPU-Kerne sowie eine virtuelle Festplatte mit 50 GiB Speicherplatz. Die gleiche Konfiguration wird für den zweiten Domänencontroller DC02 verwendet, um eine gleichwertige Leistungsfähigkeit und Replikationsgeschwindigkeit sicherzustellen. Der Dateiserver FS01 wird mit 8 GiB Arbeitsspeicher und 2 CPU-Kernen ausgestattet. Zur Trennung von System- und Datenpartition werden ihm zwei virtuelle Festplatten zugewiesen: eine Systemdisk mit 50 GiB und eine Datendisk mit 100 GiB für die Speicherung der Unternehmensdaten und Freigaben. Diese Ressourcenzuteilung stellt sicher, dass alle Systeme ausreichend Leistung für ihre Aufgabenbereiche besitzen und eine stabile Domänen- und Dateiverwaltung gewährleistet ist.

3.4.3 Installation von Betriebssystem auf VM

Auf der zuvor erstellten virtuellen Maschine wird das Betriebssystem Windows Server 2025 installiert. Während der Installation werden die grundlegenden Systemeinstellungen wie Sprache, Zeitzone, Tastaturlayout und Partitionsschema festgelegt. Anschließend erfolgt die Zuweisung einer statischen IP-Adresse, um eine eindeutige Identifikation innerhalb des Netzwerks zu gewährleisten. Nach Abschluss der Installation werden die notwendigen Laufwerks- und Netzwerktreiber installiert, um die volle Funktionalität der virtuellen Hardware sicherzustellen. Die Treiberinstallation erfolgt über die vom Virtualisierungssystem bereitgestellten Integrationsdienste, wodurch die Kommunikation zwischen Host und Gastbetriebssystem optimiert wird. Abschließend wird das System über Windows Update auf den aktuellen Stand gebracht und überprüft, ob alle Komponenten ordnungsgemäß erkannt und funktionsfähig sind. Damit ist die virtuelle Maschine betriebsbereit und dient als Grundlage für die nachfolgende Einrichtung des Domänencontrollers.

3.4.4 Zuordnung der Serverrollen

Den virtuellen Serverrn DC01 und DC02 werden die Serverrollen „Active Directory-Domänendienste (AD DS)“ sowie „DNS-Server“ zugewiesen. Die Rolle der Domänendienste ermöglicht die zentrale Verwaltung von Benutzern, Computern und Sicherheitsgruppen, welche zur Konfiguration und Durchsetzung der Zugriffsberechtigungen innerhalb der Unternehmensstruktur dienen. Durch die zusätzlich installierte DNS-Server-Rolle übernehmen beide Server die Namensauflösung innerhalb der Domäne und stellen damit sicher, dass alle Netzwerkressourcen zuverlässig adressiert werden können. Dem virtuellen Server FS01 wird die Rolle „Datei- und Speicherdienste“ zugewiesen. Diese ermöglicht die effiziente Verwaltung von Freigaben, Speicherpfaden und Berechtigungen innerhalb der zentralen Ordnerstruktur. Damit ist FS01 für die Speicherung und Bereitstellung der Unternehmensdaten verantwortlich und bildet die Grundlage für die Netzlaufwerksanbindungen der Benutzer.

3.5 Einrichtung der virtuellen Maschinen

3.5.1 Konfiguration von Domänencontrollern

3.5.1.1 Initialisierung von DC01

Der Server DC01 dient als zentraler Domänencontroller und übernimmt die Verwaltung von Benutzern, Computern und Netzwerkressourcen. Auf dem vorbereiteten Windows Server wird die Rolle „Active Directory Domain Services (AD DS)“ installiert. Anschließend wird der Server zur neuen Domäne „projekt.local“ heraufgestuft. Der NetBIOS-Name der Domäne lautet „PROJEKT“. Nach der erfolgreichen Einrichtung werden die ersten Domänenbenutzerkonten erstellt, um eine zentrale Anmeldung und Verwaltung zu ermöglichen. Zur effizienten Rechtevergabe werden anschließend Sicherheitsgruppen eingerichtet und die Benutzer den jeweiligen Gruppen zugeordnet. Dadurch wird eine strukturierte und skalierbare Zugriffsverwaltung innerhalb der Domäne gewährleistet.

3.5.1.2 Kopplung von DC01 und DC02

Der Server DC02 wird der bestehenden Domänenstruktur hinzugefügt, um eine Replikation mit DC01 sicherzustellen. Dadurch werden alle Verzeichnisdaten, einschließlich Benutzerkonten, Gruppenrichtlinien und Sicherheitsinformationen, synchron auf beiden Domänencontrollern vorgehalten. Dies gewährleistet eine hohe Ausfallsicherheit und stellt sicher, dass sich Benutzer auch bei einem Ausfall eines Controllers weiterhin im Netzwerk anmelden können. Die Synchronisierung zwischen DC01 und DC02 erfolgt bidirektional, sodass Änderungen an der Konfiguration oder an den Benutzerobjekten automatisch auf beiden Systemen übernommen werden. Auf diese Weise bleibt die gesamte Domänenkonfiguration konsistent, und die Domäne projekt.local ist dauerhaft funktionsfähig und redundant abgesichert.

3.5.2 Konfiguration von Datenserver

Der Server FS01 dient als zentraler Daten- und Fileserver innerhalb der Domänenstruktur. Er ist in die Domäne „projekt.local“ eingebunden und nutzt die durch den Domänencontroller bereitgestellten Authentifizierungs- und Berechtigungssysteme. Dadurch wird sichergestellt, dass Zugriffe auf freigegebene Ressourcen ausschließlich über die definierten Benutzer- und Gruppenrichtlinien erfolgen. Auf FS01 wird die Serverrolle „Datei- und Speicherdienste“ installiert. Anschließend werden die benötigten Freigaben und Verzeichnisstrukturen eingerichtet. Alle freigegebenen Ordner befinden sich auf dem Laufwerk D:, welches als zentrales Datenlaufwerk dient. Innerhalb dieses Laufwerks werden separate Unterordner für die jeweiligen Abteilungen und Funktionsbereiche erstellt. Die Zugriffsrechte auf diese Freigaben werden über die zuvor im Active Directory angelegten Sicherheitsgruppen gesteuert. Benutzer erhalten dadurch ausschließlich Zugriff auf die für sie relevanten Datenbereiche. Durch diese Konfiguration ist eine strukturierte, sichere und skalierbare Verwaltung der Unternehmensdaten gewährleistet.

3.6 High Availability

3.6.1 Hinzufügen der VMs zum HA

Um die VMs dem HA hinzuzufügen, geht man im Proxmox UI unter Datacenter auf die Einstellung HA. Dort wird dann unter Ressourcen „Add“ gewählt. Hier werden einem schon die zur Verfügung stehenden VMs angezeigt und diese werden hier einfach ausgewählt. Hier können auch noch Max Restart (die erlaubte Anzahl der Neustarte der VM auf einer Node) und Max Relocate (die erlaube Anzahl an Neustarten auf neuen Nodes) diese Einstellungen haben wir auf Standard (1) gelassen. Zudem kann der Request State auswählt werden, das ist der Zustand, der von der VM erwartet wird, wenn diese auf eine neue Node migriert wird. In diesem Projekt wird „started“ gewählt, da die VM direkt wieder starten soll, nachdem sie auf die neue Node migriert wird.

3.6.2 HA Affinity Ruleset

Unter den HA Node Affinity Rules werden 3 Rules erstellt. Diese definieren welche VM standardmäßig auf welcher Node laufen sollen. In unserem Fall wird eine Rule mit vm:102 (FS01) auf Node PVE03, eine mit vm:101 (DC02) auf PVE02 und eine mit vm:100 (DC01) auf PVE01 erstellt. Dadurch werden die VMs nach einem Ausfall automatisch wieder auf die ursprüngliche Node zurück migriert. In dem zweiten Reiter HA Resources Affinity Rules gibt es die Möglichkeit VMs statisch zu separieren. Hierzu wird eine Rule erstellt, die verhindert, dass die zwei DCs auf einer Node landen, was zu Konflikten führen würde. Hierzu müssen nur die zwei VMs als HA Ressources ausgewählt werden und als Affinity „keep seperate“. Hier könnte man auch „keep together“ wählen, wodurch die VMs dann immer auf die gleiche Node migriert werden würden.

3.7 Testphase

Da es sich bei diesem Projekt, um einen hochverfügbaren Server-Cluster handelt, befasst sich die Testphase mit den verschiedenen Szenarien, die auftreten können. Diese werden zuerst ermittelt und anschließend getestet, um sicherzugehen, dass das Cluster den verschiedenen Ausfällen standhalten kann. Die wesentlichen Komponenten, die bei einem Server ausfallen können, sind der Server selbst, seine Netzwerkverbindung oder seine Speicher. In unserem Fall sind die Netzwerkverbindungen, die Verbindungen zum Management-Netzwerk der Nodes, welche einen sogenannten “Heartbeat” senden. Dieser Heartbeat, signalisiert den anderen Nodes des Clusters, dass die Node erreichbar und funktionsfähig ist. Sollte dieser durch den Verlust der Netzwerkverbindung nicht mehr vorhanden sein, wird die Node im Cluster als “dead” erkannt und wird nicht mehr für den Betrieb genutzt. Jegliche Prozesse, die auf der Maschine liefen, werden dann auf die restlichen Server übertragen, um die Verfügbarkeit zu gewährleisten. Nun kommen wir zu den Problemen eines Speicherausfalls. Das Speichermedium in diesem Projekt ist das Ceph-Cluster, welches über eine Full-Mesh-Vernetzung mit von allen Nodes erreichbar ist. Dies bedeutet, dass jede Node mit jeder Node verbunden ist. Kommen wir zum ersten Ausfall-Szenario, der Ausfall einer Direktverbindung einer Node zur nächsten. Da es sich, um ein Full-Mesh-Netzwerk handelt, ist dies kein Problem. Gehen wir davon aus, dass die Direktverbindung von Node 1 zu Node 2 ausgefallen ist. Node 1 wird diesen Ausfall erkennen und eine alternative Route zu Node 2 suchen. Node 3 hat noch eine Verbindung zu Node 2 und Node 1. Das erkennt Node 1 und schickt die Pakete über Node 3 an Node 2. Somit besteht noch eine Verbindung und Ceph kann weiterhin arbeiten. Sollten alle Pfade zu einer Node ausfallen, wird der Speicher auf der ausfallenden Node eingefroren, um Datenverlust zu vermeiden. Der Speicher bleibt so lange eingefroren, bis die Verbindung zum Ceph-Cluster wieder besteht. Bei einem getesteten Stromausfall einer Node, hat es ca. 3 Minuten gedauert, bis das Cluster die ausgefallene Node als funktionsuntüchtig markiert und die virtuellen Maschinen neu verteilt hat. Der Test, welcher die Redundanz der Ceph-Netzwerkverbindungen testen sollte, funktionierte ohne eine bemerkbare Umschaltzeit. Das Cluster lief ohne Probleme weiter und meldete keine Probleme. Auch das Wiederherstellen der getrennten Verbindung sorgte für keine merkbare Umschaltzeit.

4. Fazit

4.1 Soll-Ist-Vergleich

Im Soll war die Erwartung, am Ende des Projektes ein funktionierendes Proxmox-Cluster mit hochverfügbarem Ceph-Speicher zur Verfügung zu stellen. Hier sollten mindestens zwei virtuelle Maschinen gehostet werden, ein Domänencontroller und ein Datenserver. Das System soll so konfiguriert werden, dass die VMs bei einem Ausfall automatisch auf eine andere Node verschoben werden, ohne dass ein manuelles Eingreifen nötig ist. Dadurch soll sichergestellt werden, dass sowohl AD-Funktionalitäten wie anmelden auf Rechnern, Zugriffskontrolle und Benutzerverwaltung verfügbar, als auch die gesamten Produktivdaten abrufbar bleiben, damit der laufende Betrieb nicht beeinträchtigt wird. Nach Abschluss des Projektes wurde folgender Stand erreicht. Es wurde ein funktionales Proxmox-Cluster mit einem hochverfügbaren Ceph-Speicher erstellt, hier müssen aufgrund von langsamer LAN-Verbindung und Festplattengeschwindigkeit kleine Einbußen vernommen werden, diese sind aber nicht gravierend und kaum merkbar. Die zwei VMs wurden übertroffen, da zwei VMs mit Domaincontrollern erstellt wurden, welche immer auf jeweils einer Node laufen, um auch hier eine Hochverfügbarkeit zu erreichen. Der Datenserver wurde ebenso auf einer weiteren VM erstellt. Bei dem Ausfall einer Node werden die VMs dieser Node auf eine andere Node migriert und automatisch gestartet. Die zwei Domaincontroller werden immer so verteilt, dass sie nie auf derselben Node zusammenlaufen. Das Ziel der Hochverfügbarkeit wurde also erreicht und läuft wie geplant.

4.2 Gewonnene Erkenntnisse

Bei der Durchführung des Projektes, wurde ein hochverfügbares Server-Cluster realisiert, welches über einen Ceph-Speicher verfügt. Der Ceph-Speicher wurde mit dem Gedanken integriert, dass dieser in Zukunft ohne Probleme erweitert werden kann. Während der Durchführung des Projektes wurde vor allem bemerkt, dass Ceph sehr abhängig von einer hohen Lese- und Schreibgeschwindigkeit, als auch von einer schnellen Netzwerkverbindung ist. Da sich unsere Realisierung nur mit einer moderaten Lese- und Schreib- als auch Netzwerkgeschwindigkeit umsetzen ließ, konnte dies auch in der Testphase deutlich bemerkt werden. Die Festplatten-bedingten Prozesse, welche auf den Ceph-Speicher zugreifen musste, waren sehr langsam und haben vor allem für lange Boot-Prozesse einer virtuellen Maschine nach dem Ausfall einer Node geführt. Bei der Erweiterung des Clusters in der Zukunft, sollten vor allem schnellere Festplatten, als auch Netzwerkkarten verwendet werden, da die aktuellen Geschwindigkeiten für größere Infrastrukturen nicht geeignet sind.

4.3 Ausblick

Als Ausblick auf die Zukunft besteht noch die Möglichkeit, die langsamen HDD-Festplatten durch schnellere SSDs zu ersetzen, eine schnellere LAN-Verbindung einzubauen und weiter benötigte VMs zu installieren die das Unternehmen benötigt.

5 Anhang

5.1 Kalkulationen

5.1.1 Hardwareausstattung des Clusters

Für den Projektaufbau wurde ein Hochverfügbarkeitssystem auf Basis von Proxmox VE 8 mit Ceph-Storage-Backend konzipiert. Als Basis werden dafür drei kostensparende Rechner verwendet. Die Hardware-Spezifikationen pro Host:

Die für das Projekt vorgesehenen Systeme sind speziell auf die Anforderungen des Kunden abgestimmt. Die gewählte Hardware bietet ausreichend Leistung für den praxisorientierten Aufbau eines kleinen, aber funktionsfähigen Clusters, der die zentralen Funktionen einer modernen Serverumgebung realitätsnah abbildet.

5.1.2 Ressourcenzuweisung an virtuelle Maschinen

5.1.3 Plausibilitätsprüfung der Ressourcen

Die Ressourcenzuteilung wurde so gewählt, dass die Umgebung realistisch und stabil bleibt, ohne überdimensioniert zu sein. Windows Server 2025 ist für den Betrieb kleiner Dienste (Active Directory, DNS, Datei- und Druckdienste) mit geringem CPU- und RAM-Bedarf ausgelegt. Die gewählten Werte gewährleisten einen stabilen Betrieb und sind wirtschaftlich sinnvoll. Die Netzwerkausstattung mit vier Gigabit-Ports pro Host ermöglicht die Trennung von Management-, Storage- und VM-Traffic, wodurch Ceph-Replikation, Cluster-Heartbeat und Client-Verkehr voneinander entkoppelt werden. Die gewählten Diskgrößen (50 GB für Domain Controller, 100 GB beim Fileserver) sind praxisgerecht: Windows benötigt etwa 20–25 GB für Systemdateien und Updates, sodass genügend Reserve vorhanden ist. Der Fileserver verfügt über eine zusätzliche Datenpartition (100 GB), um realistische Dateifreigaben und Sicherungsszenarien für den Kundenbetrieb zu simulieren.

5.1.4 Bewertung für den Kunden

Für den angenommenen Kunden mit 17 Benutzern ist diese Systemarchitektur technisch wie wirtschaftlich angemessen. Die Leistung genügt für einen stabilen Betrieb von Active Directory, DNS und zentralem Fileserver. Durch Ceph-Replikation und Proxmox-HA besteht eine hohe Ausfallsicherheit. Die Wiederverwendung vorhandener Hardware reduziert die Kosten erheblich und unterstreicht den wirtschaftlichen Charakter des Projekts.

5.1.5 Kurzfazit zur Hardware- und Ressourcenplanung

Trotz der Verwendung älterer Hardware erfüllt das System die Anforderungen eines kleinen Unternehmens vollständig. Durch die Kombination aus Proxmox-HA, Ceph-Replikation und einer bewusst schlanken Windows-Server-Architektur entsteht eine kosteneffiziente, stabile und skalierbare Lösung für zentrale IT-Dienste.

5.2 Zeitplan