Vugas

Das war auch mein Bauchgefühl. Entweder parallel andere Arbeitspakete abarbeiten oder die Initialisierung über Nacht laufen lassen. Genau das habe ich vorgebracht und meine Bedenken deutlich gemacht. Sie wurden mit dem Verweis auf Erfahrungen aus früheren Projekten abgeräumt. Falls der Antrag abgelehnt wird, habe ich ja sieben Tage Nachfrist, mit Hinweisen des Ausschusses. Damit hätte ich genau das in der Hand, was mir aktuell im Betrieb fehlt. Unschön aber kein Weltuntergang. Dass ich hier wenig Spielraum habe, ist mir bewusst. Ich bin leider auf den Betrieb angewiesen und kann die Entscheidung nicht überstimmen. Firmenpolitik trifft es ganz gut. Ich glaube anhand der Situation kann man sich die Stimmung fast schon vorstellen und ich muss meine Gedanken zum Ausbildungsbetrieb nicht weiter kommentieren.

Kurzes Update: Ich habe die Fassung mit der Plattformevaluation heute meinen Projektbetreuern vorgelegt. Die wurde direkt abgelehnt. Begründung: Das sei ein komplett anderes Projekt als das ursprünglich abgestimmte. Unterstützen würden sie das nicht – weder mit Arbeitszeit noch mit Zugriff auf die nötigen Informationen. Der ursprüngliche Scope, also der Aufbau der Testumgebung, sei für 40 Stunden umfangreich genug. Damit ist die Sache für mich entschieden. Einen Antrag einzureichen, für den mir der Betrieb die Unterstützung verweigert, bringt mir nichts. Ich bleibe beim alten Scope. Euer Feedback ist trotzdem nicht verloren. Drin geblieben sind: die Schutzbedarfs- und Datenschutzbetrachtung (2 h in Phase 1), keine vorweggenommenen Analyseergebnisse mehr, der Zeitplan auf Arbeitspaketebene mit 18 h Realisierung und 8 h Doku – und neu eine ausdrückliche Liste "Projektinhalt / nicht Projektinhalt", damit im Fachgespräch nicht als Erstes danach gefragt wird. Zwei Fragen hätte ich noch: 1. Zählen bei den 40 Stunden nur meine eigenen Stunden? Wenn ich mit einem Kollegen zwei Stunden eine Abnahme mache – sind das zwei oder vier? Ich lese § 20 FIAusbV so, dass es um meine Prüfungszeit geht, also zwei. Im Betrieb wurde mir das anders gesagt. 2. Wie behandelt ihr Wartezeiten bei automatisierten Vorgängen? Eine RAID-Initialisierung läuft z.B. rund neun Stunden. Ich würde nur Anstoßen und Kontrolle rechnen und in der Zeit am nächsten Arbeitspaket weitermachen. Oder erwartet ihr die Wartezeit sichtbar im Plan? Danke euch.

Danke euch – die beiden Klarstellungen haben bei mir den Knoten gelöst. @charmanta dass die Schutzbedarfsanalyse in der Prüfungsordnung steht und Zulassungskriterium ist, war mir schlicht nicht klar. Ich hatte nur in der Handreichung unserer IHK gefunden und daraus den falschen Schluss gezogen. Danke für die Korrektur. Und der Punkt, dass ein "konstruiertes" Evaluationsprojekt kein Problem ist, weil die Fragestellung zählt und nicht die Umsetzung, war genau mein Denkfehler. @cortez dein Beispiel mit "technisch die Lösung, aber Schulungskosten fressen den Vorteil auf" hat es endgültig klar gemacht: Das ist ja ein Ergebnis, kein Scheitern. Ich habe den Antrag entsprechend gedreht. Das Thema lautet jetzt: "Evaluation alternativer Virtualisierungsplattformen als Entscheidungsgrundlage für die künftige Servervirtualisierung, praktisch verifiziert auf einer vom Produktivnetz getrennten Testumgebung mit definiertem Notfallbetrieb." Die Umgebung ist damit nicht mehr das Ziel, sondern das Werkzeug – sie bleibt aber als Ergebnis bestehen, weil wir sie ohnehin brauchen. Was sich konkret geändert hat: - Die Plattformfrage ist jetzt die Problemstellung, nicht ein Auswahlschritt nebenbei. Die Ist-Analyse nennt beides und verknüpft es: Wir können die Frage nicht beantworten, weil uns genau die Umgebung fehlt, in der man das risikofrei täte. - Die Ergebnisoffenheit steht wörtlich im Antrag, inklusive der Möglichkeit, dass sich ein Umstieg wegen Schulungs- und Migrationsaufwand nicht rechnet. Dazu die Abgrenzung, dass die Entscheidung über eine tatsächliche Umstellung bei der Abteilungsleitung liegt und nicht Projektinhalt ist. - Die Wirtschaftlichkeit ist jetzt der Plattformvergleich über einen mittelfristigen Zeitraum – Lizenz- und Supportkosten, Schulungsaufwand, Aufwand für die Übernahme bestehender VMs. Projektkosten laufen als zweite Ebene mit (Vor- und Nachkalkulation). - Phase 1 heißt "Analyse und Bewertung" und hat 12 von 40 Stunden. Neu ist ein Meilenstein: Empfehlung ausarbeiten und dem Projektbetreuer zur Freigabe vorstellen. Phase 3 ist entsprechend auf 11 Stunden geschrumpft, weil nur noch die gewählte Plattform ausgerollt wird. Zur Schutzbedarfsanalyse: Beim Durchdenken ist mir aufgefallen, dass mein eigenes Konzept da einen echten Datenschutzaspekt hat, den ich vorher übersehen hatte. Im Notfallbetrieb spiele ich Produktivsysteme mit personenbezogenen Daten auf Hardware zurück, auf der im Regelbetrieb Azubis mit weitreichenden Rechten arbeiten. Daraus folgen Zugriffsbeschränkung bei der Umschaltung, Verschlüsselung der Datastores – und vor allem ein Verfahren für den Rückweg: Die Produktivdaten müssen sicher gelöscht sein, bevor wieder Testbetrieb läuft. Den Rückweg hatte ich vorher überhaupt nicht bedacht. ===================================================================== PROJEKTANTRAG (Fassung 6, anonymisiert) ===================================================================== 1. THEMA Evaluation alternativer Virtualisierungsplattformen als Entscheidungsgrundlage für die künftige Servervirtualisierung, praktisch verifiziert auf einer vom Produktivnetz getrennten Testumgebung mit definiertem Notfallbetrieb. 1.1 Geplanter Bearbeitungszeitraum 12.10.2026 – 13.11.2026 (40 Stunden) 2. PROJEKTBESCHREIBUNG 2.1 Unternehmensbeschreibung Mein Ausbildungsbetrieb ist Distributor für Druckersupplies und Speichermedien und gehört zu einer europäischen Unternehmensgruppe mit gruppenweit über 1.000 Beschäftigten und mehr als 1,2 Milliarden Euro Jahresumsatz. 2.2 Ausgangssituation (Ist-Analyse) Die IT-Abteilung verfügt über keine vom Produktivbetrieb getrennte Testumgebung. Neue Systeme und Konfigurationen werden auf Bestands-Produktivsystemen erprobt und teilen sich Rechenleistung, Speicher und Netzwerk mit dem Produktivbetrieb; Fehlkonfigurationen wie IP-Adresskonflikte oder falsch zugeordnete VLANs schlagen unmittelbar auf produktive Dienste durch. Insbesondere Auszubildende können Systeme nicht eigenständig aufsetzen, ohne den Produktivbetrieb zu gefährden. Zusätzlich fehlt eine Ausweichkapazität: Fällt die produktive Virtualisierungsumgebung aus, steht kein Cluster bereit, auf dem kritische Systeme kurzfristig weiterlaufen könnten. Zugleich steht die Virtualisierungsbasis mittelfristig zur Disposition: Nach der Übernahme von VMware durch Broadcom haben sich Lizenzmodell und Kosten grundlegend verändert. Ob VMware die richtige Basis bleibt, lässt sich derzeit nicht beantworten – es fehlt eine Umgebung, in der Alternativen ohne Risiko erprobt werden könnten. Gleichzeitig lagern mehrere ungenutzte Server (HP ProLiant DL360), Ethernet- und SAN-Switches sowie Speichersysteme im Bestand, mit denen sich eine solche Umgebung ohne Neuanschaffung aufbauen lässt. 2.3 Projektziel (Soll-Konzept) Das Projekt beantwortet die Frage, ob VMware vSphere mittelfristig die richtige Basis der Servervirtualisierung bleibt oder ob eine Alternative vorzuziehen wäre. Bewertet werden VMware vSphere, Microsoft Hyper-V und Proxmox VE hinsichtlich Lizenz-, Schulungs- und Betriebskosten, Aufwand für die Übernahme vorhandener VMs, Eignung als Notfallziel sowie Unterstützung der Bestandshardware. Das Ergebnis ist ausdrücklich offen und kann ebenso lauten, dass ein Umstieg technisch möglich, wegen Schulungs- und Migrationsaufwand aber mittelfristig unwirtschaftlich ist. Die Entscheidung über eine tatsächliche Umstellung der Produktivumgebung trifft die Abteilungsleitung und ist nicht Gegenstand des Projekts. Bewertungsgrundlage ist eine eigens aufgebaute, vom Produktivnetz getrennte Umgebung, auf der die Kandidaten praktisch erprobt werden. Sie bleibt nach Projektende als Testumgebung bestehen – ausdrücklich auch für Auszubildende, die dort Fehler machen dürfen – und soll im Störfall zusätzlich als Ausweichplattform dienen. Beides zugleich ist ein Zielkonflikt: Eine Umgebung, auf der bewusst experimentiert wird, erfüllt nicht die Anforderungen an ein Notfallsystem. Aufgelöst wird er über zwei definierte Betriebsmodi mit dokumentierter Umschaltprozedur: - Regelbetrieb (Testmodus): freier Zugriff für Auszubildende, Testsysteme belegen die Ressourcen, Umgebung vollständig isoliert. - Notfallbetrieb: Zugriff wird auf die Administratoren reduziert, Testsysteme werden abgeschaltet und geben Ressourcen frei, die Kernsysteme werden über eine kontrolliert hergestellte Netzverbindung aus dem Air-Gap-Backup zurückgespielt. Für die Umschaltung wird eine Zielzeit (Recovery Time Objective, RTO) festgelegt und in Phase 4 praktisch dagegen gemessen. Schutzbedarf und Datenschutz: Zu Projektbeginn wird der Schutzbedarf beider Modi ermittelt. Gewicht hat dabei der Notfallbetrieb: Dort gelangen produktive Systeme mit personenbezogenen Daten auf eine Umgebung, die im Regelbetrieb Auszubildenden offensteht. Daraus folgen Zugriffsbeschränkung bei der Umschaltung, Verschlüsselung der Datastores und ein Verfahren zur sicheren Löschung der Produktivdaten vor Rückkehr in den Testbetrieb. Als Rahmenbedingung gibt der Betrieb vor, ausschließlich vorhandene Hardware wiederzuverwenden. Neben der Plattformbewertung liegen die fachlichen Schwerpunkte bei mir: - Betriebsmodus- und Umschaltkonzept: Ausarbeitung beider Modi, der Umschaltprozedur und des Rollenkonzepts, das beide Modi abbilden muss. - Auslegung der Umgebung: Auswahl der Hardware aus dem Bestand sowie Netz-, Storage- und Redundanzkonzept auf Basis des ermittelten Schutzbedarfs. Wirtschaftlichkeit: Kern ist der Kostenvergleich der drei Plattformen über einen mittelfristigen Zeitraum – Lizenz- und Supportkosten, Schulungsaufwand sowie Aufwand für die Übernahme bestehender VMs. Dazu kommen Kostenvor- und -nachkalkulation des Projekts mit Soll-Ist-Vergleich; gegengerechnet wird die vermiedene Neuanschaffung einer vergleichbaren Umgebung. 2.4 Projektumfeld Das Projekt entsteht in der IT-Abteilung meines Ausbildungsbetriebs; sie ist zugleich interner Auftraggeber und späterer Betreiber. Betrieblicher Ansprechpartner ist mein Projektbetreuer. Anwender sind Auszubildende der Abteilung (eigenständiges Aufsetzen und Testen von Systemen), Betreiber die Administratoren. Aufgebaut wird die Hardware in einer Lagerhalle am Standort. Prozessschnittstellen: Einstieg über Auftrag und Anforderungen der IT-Abteilung samt Freigabe der Bestandshardware; während der Durchführung Abstimmung mit dem Projektbetreuer zu Standort, Stromversorgung und Rollenkonzept; Ausstieg über die Übergabe an die IT-Abteilung inklusive Einweisung und Betriebshandbuch. Abgrenzung: Die Umgebung bleibt netzseitig isoliert; eine dauerhafte Anbindung an das Produktivnetz ist ebenso wenig Projektinhalt wie eine Migration der Produktivumgebung selbst – die Plattformbewertung erfolgt ausschließlich für die neu aufzubauende Umgebung. Eigenleistung: Bewertung, Planung, Konfiguration, Test und Dokumentation führe ich eigenständig durch; Kollegen sind nur an den genannten Freigaben beteiligt. 2.5 Projektphasen mit Zeitplan Phase 1 – Analyse und Bewertung (12,0 h) Ist-Analyse und Anforderungsaufnahme mit der IT-Abteilung 1,0 h Schutzbedarfs- und Datenschutzbetrachtung beider Betriebsmodi 2,0 h Evaluation der Plattformen: Nutzwertanalyse und praktische Erprobung 6,0 h Kostenvergleich der Plattformen und Kostenvorkalkulation 2,0 h Empfehlung ausarbeiten und dem Projektbetreuer vorstellen (Freigabe) 1,0 h Phase 2 – Planung (4,0 h) Betriebsmodus- und Umschaltkonzept inkl. RTO-Zielvorgabe 2,0 h Netz-, Storage- und Rollenkonzept 1,0 h Test- und Abnahmekonzept 1,0 h Phase 3 – Realisierung (11,0 h) Hardware-Aufbau, Verkabelung, Firmware-/iLO-Stand 2,5 h Switch- und Speicherkonfiguration (VLANs, RAID-Verbund, LUNs) 2,5 h Hypervisor der gewählten Plattform auf beiden Hosts einrichten 2,0 h Management-Instanz ausrollen, Cluster und Datastores anlegen 2,0 h Rollenkonzept und Umschaltprozedur umsetzen 2,0 h Phase 4 – Test und Qualitätssicherung (4,0 h) Funktionstests nach Testkonzept 1,0 h Notfallumschaltung und Wiederherstellung gegen RTO-Ziel messen 2,0 h Abnahme mit dem Auftraggeber 1,0 h Phase 5 – Projektabschluss (7,0 h) Projektdokumentation erstellen 5,0 h Kostennachkalkulation und Soll-Ist-Vergleich 1,0 h Übergabe, Einweisung und Reflexion 1,0 h Puffer für unvorhergesehenen Aufwand 2,0 h GESAMT 40,0 h 3. DOKUMENTATION DER PROJEKTARBEIT Die Projektdokumentation erfolgt als prozessorientierter Projektbericht im Portable Document Format (PDF) und beschreibt Ausgangssituation, Zielsetzung, Umsetzung, Tests, Ergebnisse und Nutzen. Als Anlagen sind vorgesehen: Nutzwertanalyse und Kostenvergleich der Plattformen, die Schutzbedarfs- und Datenschutzbetrachtung, Kostenvor- und -nachkalkulation, die Umschaltprozedur für den Notfallbetrieb, das Abnahmeprotokoll sowie die Offenlegung eingesetzter Werkzeuge mit Künstlicher Intelligenz (KI) gemäß Vorgabe der IHK. ===================================================================== Eine Frage bleibt mir noch: Reichen 6 Stunden für die eigentliche Evaluation, wenn ich Kostenvergleich (2 h) und Schutzbedarf (2 h) separat ausweise? @charmanta du hattest 6-8 für die Evaluation genannt – ich bin unsicher, ob du damit den ganzen Block gemeint hast oder die reine Nutzwertanalyse mit praktischer Erprobung. Danke nochmal fürs Dranbleiben, das hat das Projekt spürbar besser gemacht.

Danke euch beiden – die Kritik sitzt, und ich nehme sie an. Zum Kontext: Ich hatte mich an einem Antrag orientiert, der bei unserem Ausschuss so durchging. Das erklärt die flache Struktur, rechtfertigt sie aber nicht. @cortez tez zu deiner Frage "Was ist es denn jetzt?" – die war der wunde Punkt, und ich habe sie mir vorher nicht ehrlich genug gestellt. Antwort: Primär eine Testumgebung. Der Notfallbetrieb ist ein Zusatznutzen, kein zweites gleichrangiges Ziel. Der Widerspruch bleibt damit natürlich bestehen – eine Umgebung, auf der Azubis absichtlich Sachen kaputt machen dürfen, ist kein Notfallsystem. Statt das zu verschweigen, steht der Zielkonflikt jetzt offen im Antrag und wird über zwei definierte Betriebsmodi aufgelöst: - Regelbetrieb: freier Zugriff für Azubis, Testsysteme belegen die Ressourcen, Umgebung vollständig isoliert. - Notfallbetrieb: Zugriff auf die Administratoren reduziert, Testsysteme werden abgeschaltet und geben Ressourcen frei, Kernsysteme kommen über eine kontrolliert hergestellte Verbindung aus dem Air-Gap-Backup zurück. Dafür gibt es eine dokumentierte Umschaltprozedur und ein RTO-Ziel, das in der Testphase praktisch dagegen gemessen wird. Das ist aus meiner Sicht die eigentliche Ingenieurleistung im Projekt – deutlich mehr als die Kleinkram-Entscheidungen, die du zu Recht zerlegt hast. Was sich sonst geändert hat: - @charmanta a Evaluation der Virtualisierungsplattform jetzt mit 6 Stunden statt 2, und nicht mehr nur Nutzwertanalyse, sondern mit praktischer Erprobung. Bewertungskriterium ist unter anderem der Aufwand, vorhandene VMs zu übernehmen. - Schutzbedarfsanalyse für Test- und Notfallbetrieb ist drin. Die liefert gleich die fachliche Begründung für die zwei Modi, hängt also nicht als Pflichtübung daneben. - VLAN-Nummernkreis, RAID-Level und Storage-Anbindung habe ich zu einem Punkt zusammengefasst. Die als drei eigenständige Entscheidungen zu verkaufen war Blödsinn, das hast du sauber auseinandergenommen. - Kostenvorkalkulation und Nachkalkulation mit Soll-Ist-Vergleich statt einer einmaligen Betrachtung. Zum Vorschlag, die Migration weg von VMware zum eigentlichen Thema zu machen: Der Punkt leuchtet mir fachlich völlig ein, gerade wegen der Lizenzsituation seit Broadcom. Bei uns ist das aber perspektivisch und nicht akut – niemand plant gerade eine Ablösung. Ein reines Migrationsprojekt wäre bei uns deshalb konstruiert, und im Fachgespräch würde genau das auffliegen. Ich habe stattdessen den Weg gewählt, die Plattformfrage in der isolierten Umgebung ernsthaft zu evaluieren – da lässt sie sich risikofrei beantworten, bevor sie akut wird. Falls ihr das für einen faulen Kompromiss haltet, sagt es gern deutlich. Zwei Fragen hätte ich noch: 1. Trägt das Betriebsmodus- und Umschaltkonzept als fachlicher Kern, oder ist auch das für eure Begriffe noch zu dünn? 2. @charmanta zur Schutzbedarfsanalyse: In der Handreichung unserer IHK kommen die Wörter Datenschutz, Schutzbedarf und Sicherheit kein einziges Mal vor. Ich habe sie trotzdem eingeplant, weil sie inhaltlich passt. Ist das bei euch fester Bestandteil der Bewertung, oder hängt das am jeweiligen Ausschuss? Den überarbeiteten Antrag im Volltext stelle ich gern rein, wenn ihr nochmal draufschauen wollt – ich wollte euch nicht direkt wieder drei Seiten vor die Nase setzen.

Erst einmal vielen Dank an euch drei. Das Feedback war deutlich, aber genau deshalb hilfreich. Vor allem der Punkt, dass ich unter 2.3 seitenlang erkläre, was alles vorgegeben ist, und direkt danach behaupte, die Entscheidungen lägen bei mir, hat gesessen. Beim Nochmallesen ist mir das selbst peinlich aufgefallen. Ich habe den Antrag daraufhin komplett überarbeitet. Was sich geändert hat: 1. Die Plattformwahl ist jetzt Projektinhalt statt Ausschluss. Der Satz, mit dem ich den Hyper-V-Vergleich als "nicht Projektinhalt" abgeräumt habe, ist raus. Stattdessen wird die Plattform in Phase 1 per Nutzwertanalyse bewertet. Das habe ich vorher mit meinem Ausbildungsbetreuer abgestimmt – vorher stand VMware faktisch als Vorgabe im Raum, das ist jetzt geklärt. 2. Die lange Vorgaben-Passage ist auf einen Satz geschrumpft. Als echte Rahmenbedingung bleibt nur, dass ausschließlich vorhandene Hardware wiederverwendet wird. 3. Weil die Entscheidungen erst im Projekt fallen, nimmt der Antrag ihre Ergebnisse nicht mehr vorweg. iSCSI, RAID 6 und die konkrete Servergeneration standen vorher schon als Fakt drin – das war unlogisch und ist jetzt raus. 4. Zeitplan auf Arbeitspakete heruntergebrochen, jedes mit Stunden. Auf die Frage nach den 18 Stunden Realisierung gibt es jetzt eine Antwort. 5. Deutlich gekürzt: von fünf auf drei Seiten. Ist-Analyse und Soll-Konzept sind auf Antragsniveau zusammengestrichen, die ausführliche Fassung wandert in die Doku. 6. Neu dazugekommen sind ein Wiederherstellungstest aus dem Backup als Nachweis der DR-Fähigkeit, eine explizite Reflexion in Phase 5 und ein Zeitpuffer. Hier die neue Fassung (Namen und Betrieb habe ich rausgenommen und die Formatierung für das Forum angepasst): ===================================================================== PROJEKTANTRAG ZUR BETRIEBLICHEN PROJEKTARBEIT (IHK) ===================================================================== Ausbildungsberuf: Fachinformatiker für Systemintegration Ausbildungsbetrieb: [Betrieb], Abteilung Informationstechnik (IT) Auftraggeber: IT-Abteilung (intern) 1. THEMA DER PROJEKTARBEITKonzeption, Bewertung und Aufbau einer vom Produktivnetz getrennten Virtualisierungsumgebung zur Erprobung neuer Systeme auf Hypervisor- und VM-Ebene sowie als Desaster-Recovery-Ausweichplattform für die Produktivsysteme, unter Wiederverwendung vorhandener Server-Hardware. 1.1 Geplanter Bearbeitungszeitraum12.10.2026 – 13.11.2026 (gesamter Bearbeitungszeitraum, 40 Stunden) 2. PROJEKTBESCHREIBUNG2.1 UnternehmensbeschreibungMein Ausbildungsbetrieb ist Distributor für Druckersupplies und Speichermedien und gehört zu einer europäischen Unternehmensgruppe mit gruppenweit über 1.000 Beschäftigten und mehr als 1,2 Milliarden Euro Jahresumsatz. 2.2 Ausgangssituation (Ist-Analyse)Die IT-Abteilung verfügt über keine vom Produktivbetrieb getrennte Testumgebung. Neue Systeme und Konfigurationen werden auf Bestands-Produktivsystemen erprobt und teilen sich Rechenleistung, Speicher und Netzwerk mit dem Produktivbetrieb; Fehlkonfigurationen wie IP-Adresskonflikte oder falsch zugeordnete VLANs schlagen unmittelbar auf produktive Dienste durch. Insbesondere Auszubildende können Systeme nicht eigenständig aufsetzen, ohne den Produktivbetrieb zu gefährden. Zusätzlich fehlt eine Ausweichkapazität: Fällt die produktive Virtualisierungsumgebung aus, steht kein Cluster bereit, auf dem kritische Systeme kurzfristig weiterlaufen könnten. Gleichzeitig lagern mehrere ungenutzte Server (HP ProLiant DL360), Ethernet- und SAN-Switches sowie Speichersysteme im Bestand. Sie bilden jedoch nur die physische Basis – welche Komponenten eingesetzt werden und welche Virtualisierungsplattform darauf läuft, ist im Projekt erst zu bewerten. 2.3 Projektziel (Soll-Konzept)Ziel ist eine eigenständige, vom Produktivnetz getrennte Virtualisierungsumgebung, auf der neue Systeme auf Hypervisor- und VM-Ebene erprobt werden können und die im Störfall als Ausweichplattform für essenzielle Produktivsysteme dient. Die Wiederherstellung erfolgt aus dem bestehenden Air-Gap-Backup: Im Störfall wird kontrolliert eine physische Netzverbindung hergestellt und zurückgespielt, im Regelbetrieb bleibt die Umgebung isoliert. Als Rahmenbedingung gibt der Betrieb vor, ausschließlich vorhandene Hardware wiederzuverwenden. Die fachliche Ausgestaltung liegt bei mir; zu treffen und zu begründen sind: - Virtualisierungsplattform: Nutzwertanalyse u. a. zu VMware vSphere, Microsoft Hyper-V und Proxmox VE – Kriterien: Eignung als Desaster-Recovery-Ziel für die bestehenden Workloads, Lizenz- und Kostensituation, Hardware-Unterstützung, vorhandenes Know-how. - Hardware-Auswahl: Server, Switch und Speichersystem aus dem Bestand nach Plattformkompatibilität, Leistung und Energieeffizienz. - Storage-Anbindung: Nutzwertanalyse iSCSI gegenüber Fibre Channel (FC), einschließlich der Frage, welche Komponenten vollständig im Bestand vorhanden sind. - Storage-Redundanz: Festlegung des RAID-Levels; bei Bestandsplatten gleichen Alters ist der Ausfall mehrerer Platten ein reales Risiko. - Netzdesign: eigenständiges VLAN-Konzept in separatem Nummernkreis, angelehnt an das Schema des Produktivnetzes – wiedererkennbar und zugleich eindeutig unterscheidbar. - Rollen- und Berechtigungskonzept: so ausgelegt, dass Auszubildende eigenständig arbeiten können, ohne die Umgebung als Ganzes zu gefährden. - Testkonzept: Abnahmekriterien einschließlich Wiederherstellungstest aus dem Air-Gap-Backup als Nachweis der Desaster-Recovery-Fähigkeit. Wirtschaftlichkeit: Den Projektkosten – im Wesentlichen 40 Stunden Arbeitszeit und laufende Stromkosten – steht die vermiedene Neuanschaffung einer vergleichbaren Test- und Notfallumgebung gegenüber (Wiederbeschaffungswert im unteren fünfstelligen Eurobereich), dazu vermiedene Betriebsstörungen und verkürzte Ausfallzeiten im Störfall. Die Kosten-Nutzen-Betrachtung entsteht in Phase 1. 2.4 ProjektumfeldDas Projekt entsteht in der IT-Abteilung meines Ausbildungsbetriebs; sie ist zugleich interner Auftraggeber und späterer Betreiber. Betrieblicher Ansprechpartner ist mein Projektbetreuer. Anwender sind Auszubildende der Abteilung (eigenständiges Aufsetzen und Testen von Systemen), Betreiber die Administratoren. Aufgebaut wird die Hardware in einer Lagerhalle am Standort. Prozessschnittstellen: Einstieg über Auftrag und Anforderungen der IT-Abteilung samt Freigabe der Bestandshardware; während der Durchführung Abstimmung mit dem Projektbetreuer zu Standort, Stromversorgung und Rollenkonzept; Ausstieg über die Übergabe an die IT-Abteilung inklusive Einweisung und Betriebshandbuch. Abgrenzung: Die Umgebung bleibt netzseitig isoliert; eine dauerhafte Anbindung an das Produktivnetz ist ebenso wenig Projektinhalt wie eine Migration der Produktivumgebung selbst – die Plattformbewertung erfolgt ausschließlich für die neu aufzubauende Umgebung. Eigenleistung: Planung, Konfiguration von Switch, Hosts, Storage und Management-Instanz sowie Test und Dokumentation führe ich eigenständig durch; Kollegen sind nur an den genannten Freigaben beteiligt. 2.5 Projektphasen mit ZeitplanPhase 1 – Analyse und Konzeption (7,0 h) Ist-Analyse und Anforderungsaufnahme mit der IT-Abteilung 1,5 h Nutzwertanalyse Virtualisierungsplattform 2,0 h Nutzwertanalyse Storage-Anbindung (iSCSI/Fibre Channel) 1,5 h Auswahl der Hardware aus dem Bestand 1,0 h Kosten-Nutzen-Betrachtung 1,0 h Phase 2 – Planung (4,5 h) Netz- und VLAN-Konzept 1,5 h Storage- und RAID-Konzept 1,0 h Rollen- und Berechtigungskonzept 1,0 h Test- und Abnahmekonzept 1,0 h Phase 3 – Realisierung (14,5 h) Hardware-Aufbau, Verkabelung, Firmware-/iLO-Stand 2,5 h Switch-Konfiguration (VLANs, Uplinks, Storage-Netz) 2,0 h Speichersystem einrichten (RAID-Verbund, LUNs, Targets) 2,5 h Hypervisor auf beiden Hosts installieren und grundkonfigurieren 2,5 h Management-Instanz ausrollen, Cluster und Datastores anlegen 3,0 h Rollen- und Berechtigungskonzept umsetzen 2,0 h Phase 4 – Test und Qualitätssicherung (5,0 h) Funktionstests nach Testkonzept 2,0 h Wiederherstellungstest aus dem Air-Gap-Backup (DR-Nachweis) 2,0 h Abnahme mit dem Auftraggeber 1,0 h Phase 5 – Projektabschluss (7,0 h) Projektdokumentation erstellen 5,0 h Übergabe und Einweisung der IT-Abteilung 1,0 h Soll-Ist-Vergleich, Reflexion und Fazit 1,0 h Puffer für unvorhergesehenen Aufwand 2,0 h GESAMT 40,0 h 3. DOKUMENTATION DER PROJEKTARBEITDie Projektdokumentation erfolgt als prozessorientierter Projektbericht im Portable Document Format (PDF) und beschreibt Ausgangssituation, Zielsetzung, Umsetzung, Tests, Ergebnisse und Nutzen. Als Anlagen sind vorgesehen: die Nutzwertanalysen zu Virtualisierungsplattform und Storage-Anbindung, die Kosten-Nutzen-Betrachtung, eine Netz- und Storage-Übersicht, das Test- und Abnahmeprotokoll sowie die Offenlegung eingesetzter Werkzeuge mit Künstlicher Intelligenz (KI) gemäß Vorgabe der IHK. ===================================================================== Drei Punkte, bei denen ich noch unsicher bin: 1. Reicht die Plattformbewertung in dieser Form als Eigenleistung, oder wirkt eine Nutzwertanalyse mit 2 Stunden zu dünn für etwas, das jetzt sogar im Thema steht? 2. Phase 3 mit 14,5 Stunden für Hardware-Aufbau, Switch, Storage, zwei Hosts, Management-Instanz mit Cluster und Rollenkonzept – ist das realistisch oder zu knapp kalkuliert? Ich könnte den Puffer reduzieren oder Phase 1 etwas abgeben. 3. Ich habe den Abschnitt "verwendete Hard- und Software" komplett gestrichen, weil die Auswahl ja erst im Projekt getroffen wird und eine Liste das Ergebnis vorweggenommen hätte. Fehlt euch das, oder ist das so schlüssiger? Danke fürs Drüberschauen.

Hallo zusammen, ich möchte mir gerne auch einmal externes Feedback einholen zu meinem Projektantrag. Intern läuft das bei uns leider nicht so rund. Meine größte befürchtung ist, dass ich das schon viel zu detailliert beschrieben habe und demnach der Antrag zu lang ist. Auch würde ich gerne wissen, ob der Zeitplan so überhaupt realistisch ist: 1. Thema der ProjektarbeitAufbau einer vom Produktivnetz abgekapselten Virtualisierungsumgebung auf Basis von VMware vSphere/vCenter zur direkten Erprobung neuer Systeme auf Hypervisor-/VM-Ebene sowie als Desaster-Recovery-Option für die Produktivsysteme, unter Wiederverwendung vorhandener Server-Hardware. 1.1 Geplanter Bearbeitungszeitraum12.10.2026 – 13.11.2026 (gesamter Bearbeitungszeitraum, 40 Stunden) 2. Projektbeschreibung2.1 Unternehmensbeschreibung** Hier ein generischer Text der mir so vom Ausbildungsbetrieb vorgeschrieben wurde ** 2.2 Ausgangssituation (Ist-Analyse)Neue Systeme, Anwendungen und Konfigurationen werden in der IT-Abteilung bislang ohne eine dedizierte, vom Produktivbetrieb getrennte Testumgebung eingeführt. Getestet wird dabei auf Bestands-Produktivsystemen in abgetrennten Netzwerkbereichen – dabei drohen Betriebsstörungen, Datenverlust und ungeplante Ausfallzeiten, denn die Tests laufen auf derselben physischen Infrastruktur und teilen sich Rechenleistung, Speicher und Netzwerk mit dem Produktivbetrieb. Fehlkonfigurationen – etwa IP-Adresskonflikte oder falsch zugeordnete VLANs – können so unmittelbar auf produktive Dienste durchschlagen. Vor allem Auszubildende haben aktuell keine Möglichkeit, Systeme eigenständig aufzusetzen und dabei auch Fehler machen zu dürfen, ohne den Produktivbetrieb zu gefährden. Zusätzlich verfügt die IT-Abteilung aktuell über keine Ausweichkapazität für den Fall eines Ausfalls der produktiven Virtualisierungsumgebung: Bei einem größeren Störfall stünde kein eigenständiges Notfall-Cluster zur Verfügung, auf dem kritische Systeme kurzfristig weiterbetrieben werden könnten. Gleichzeitig lagern im Unternehmen mehrere ungenutzte Server (HP ProLiant DL360 der Generationen 6 bis 9), mehrere Ethernet- und SAN-Switches (u. a. Cisco Catalyst 3560G und Fibre-Channel-Switches) sowie verschiedene Netzwerkspeicher (Network Attached Storage, NAS; u. a. Thecus N8800SAS und HP MSA 2040), deren Wiederverwendung zusätzliche Anschaffungskosten erspart. Die Auswahl der konkret einzusetzenden Komponenten aus diesem Bestand ist Teil des Projekts. Diese Hardware bildet dabei nur die physische Basis; die eigentliche Virtualisierungsumgebung (Hypervisor-Schicht) darauf muss im Projekt erst noch aufgebaut werden. 2.3 Projektziel (Soll-Konzept)Ziel ist das Schaffen einer eigenständigen Virtualisierungsumgebung (Hypervisor-Struktur), auf der neue Systeme und Programme unabhängig vom Produktivbetrieb direkt auf Hypervisor-/VM-Ebene gestartet und getestet werden können. Die Umgebung ist vollständig vom Produktivnetz getrennt und übernimmt zugleich die Funktion einer Desaster-Recovery-Option: Im Ernstfall können auf ihr essenzielle Systeme der Produktivumgebung ausweichsweise weiterbetrieben werden. Die Wiederherstellung erfolgt dabei über das bestehende, netzseitig getrennte Backup (Air-Gap-Backup): Im Störfall wird kontrolliert eine physische Netzverbindung hergestellt, die essenziellen Systeme werden aus dem Backup auf die neue Umgebung zurückgespielt und dort weiterbetrieben. Im Regelbetrieb bleibt die Umgebung vollständig isoliert. Vorgabe des Ausbildungsbetreuers und der Abteilungsleitung ist dabei, vorhandene, aktuell ungenutzte Hardware wiederzuverwenden sowie auf VMware als Virtualisierungsplattform zu setzen. Beides ist als Rahmenbedingung gesetzt: Wiederverwendung, weil die Server bereits im Bestand sind und keine Neuanschaffung nötig ist; VMware, weil im Unternehmen bereits entsprechendes Know-how vorhanden ist und die Produktivsysteme selbst ebenfalls auf VMware laufen. Zwar ließen sich VMware-basierte VMs grundsätzlich auch auf andere Plattformen übertragen, das erfordert im Ernstfall jedoch zusätzliche Konvertierungsschritte und schafft Reibungspunkte, die weitere Komplikationen einbringen können – bei einer plattformgleichen Umgebung können die Workloads dagegen ohne Anpassung übernommen werden. Innerhalb dieser Rahmenbedingungen liegen die wesentlichen fachlichen Entscheidungen bei mir: • Hardware-Auswahl: Auswahl der einzusetzenden Komponenten aus dem Gerätebestand – u. a. Entscheidung für die DL360 Gen9 als neueste verfügbare Servergeneration (ESXi-Kompatibilität, Leistung und Energieeffizienz gegenüber Gen6–Gen8). • Storage-Anbindung: Entscheidung für iSCSI statt Fibre Channel (FC), da die für FC benötigten Komponenten (u. a. passende SFP-Module) nicht vollständig im Bestand vorhanden sind und Mehrkosten verursachen würden; die Bewertung beider Varianten erfolgt per Nutzwertanalyse in Phase 1. • Storage-Redundanz: Konfiguration des NAS im RAID-6-Verbund, sodass der gleichzeitige Ausfall von bis zu zwei Festplatten ohne Datenverlust toleriert wird – bei Bestandsplatten gleichen Alters ein relevantes Risiko. • Netzdesign: eigenständiges VLAN-Konzept, angelehnt an das Schema des Produktivnetzes, jedoch in einem separaten Nummernkreis – so bleibt die Umgebung für Administratoren wiedererkennbar und zugleich eindeutig vom Produktivnetz unterscheidbar. • Rollen- und Berechtigungskonzept: wird von mir eigenständig ausgearbeitet und umgesetzt. Die Versionswahl von ESXi/vCenter ist durch die Kompatibilität der Bestandshardware und die vorhandenen Lizenzen weitgehend vorgegeben und wird in der Dokumentation nachvollziehbar begründet. Wirtschaftlichkeit: In Phase 1 wird eine Kosten-Nutzen-Betrachtung erstellt. Den Projektkosten – im Wesentlichen 40 Stunden Arbeitszeit sowie die laufenden Stromkosten der Server – steht die vermiedene Neuanschaffung einer vergleichbaren Test- und Notfallumgebung (zwei Server, Switch, Storage; Wiederbeschaffungswert im unteren fünfstelligen Eurobereich) gegenüber. Hinzu kommt schwer bezifferbarer, aber wesentlicher Nutzen: vermiedene Betriebsstörungen durch Tests auf Produktivsystemen sowie eine Notfallreserve, die ungeplante Ausfallzeiten im Störfall verkürzt. 2.4 ProjektumfeldDas Projekt entsteht in der IT-Abteilung **des Unternehmens**; sie ist zugleich interner Auftraggeber und späterer Betreiber der Umgebung. Betrieblicher Ansprechpartner und Projektbetreuer ist **Ausbilder**. Nutzerkreis: Auszubildende der IT-Abteilung als primäre Anwender (eigenständiges Aufsetzen und Testen von Systemen), Administratoren der IT-Abteilung als Betreiber. Standort: Die Hardware wird final in Halle 3 im Lager am Standort Kamp-Lintfort aufgebaut. Prozessschnittstellen: • Einstieg: Auftrag und Anforderungen durch die IT-Abteilung; Freigabe der Bestandshardware zur Wiederverwendung. • Während der Durchführung: Abstimmung mit dem Projektbetreuer zu Standort, Stromversorgung und Rollenkonzept. • Ausstieg: Übergabe an die IT-Abteilung inkl. Einweisung und Betriebshandbuch. Abgrenzung: Die Umgebung ist bewusst netzseitig isoliert; eine Anbindung an das Produktivnetz ist nicht Gegenstand des Projekts. Die Bewertung der Virtualisierungsplattform erfolgt auf VMware-Basis; eine mögliche spätere Migration in Richtung Microsoft Hyper-V ist strategischer Zukunftskontext, jedoch nicht Projektinhalt. Eigenleistung: Planung, Konfiguration (Switch, Hosts, Storage, vCenter) sowie Test und Dokumentation führe ich eigenständig durch. Kollegen sind nur an der Freigabe zu Standort, Stromversorgung und Rollenkonzept beteiligt (s. Prozessschnittstellen). 2.5 Projektphasen mit ZeitplanPhase 1 – Analyse & Konzeption (7h) • Ist-Analyse und Anforderungen klären • Soll-Konzept erstellen (Plattform, Netz, Storage) • Wirtschaftlichkeit und Plattformwahl bewerten Phase 2 – Planung (4h) • Hardware- und Zeitplanung • Netz- und Storage-Planung • Rollenkonzept planen Phase 3 – Realisierung (18h) • Einrichtung der Hosts • Einrichtung Switch • Einrichtung Storage • Cluster und Rollenkonzept umsetzen Phase 4 – Test & Qualitätssicherung (5h) • Testkonzept erstellen • Funktionstests durchführen • Abnahme mit dem Auftraggeber Phase 5 – Projektabschluss & Dokumentation (6h) • Übergabe und Einweisung der IT-Abteilung • Projektdokumentation erstellen • Soll-Ist-Vergleich und Fazit Gesamt: 40h 3. Dokumentation der ProjektarbeitDie Projektdokumentation erfolgt als prozessorientierter Projektbericht im Portable Document Format (PDF) und beschreibt Ausgangssituation, Zielsetzung, Umsetzung, Tests, Ergebnisse und Nutzen. Vorgesehene Anlagen: • Kosten-Nutzen-Betrachtung (Wirtschaftlichkeit) • Netz- und Storage-Diagramme, Cluster-Übersicht • Screenshots der Konfiguration • Testprotokolle/Abnahmeprotokoll • Kurzes Betriebs-/Übergabehandbuch für die IT-Abteilung • Offenlegung eingesetzter Werkzeuge mit Künstlicher Intelligenz (KI) gemäß Vorgabe der IHK 4. Verwendete Hard- und Software (Auswahl)• Hardware: 2× HP ProLiant DL360 Gen9 (Bestand); Thecus N8800SAS als iSCSI-Storage im RAID-6-Verbund (Bestand); Cisco Catalyst 3560G als Layer-3 (L3)/VLAN-Switch (Bestand) • Software: VMware ESXi, VMware vCenter Server Appliance (VCSA), HPE iLO/Firmware-Tools